Security

Shadow IT is feedback: stop blocking it and start reading it

Ask almost anyone in this industry what to do about shadow IT and you get the same answer: find it, block it, write a policy forbidding it. We think that answer is wrong, and that it has been making estates less secure for a decade. Whether you look after IT for your own organisation or for clients, every unsanctioned app on the network is a message from your users. Blocking it is choosing not to read it.

The standard playbook fails on contact

The orthodox response to shadow IT is prohibition: an acceptable use policy, an application allowlist, a web filter, a stern email. It feels decisive, and on paper the problem goes away.

In practice the work the app was doing does not go away, because the deadline that drove someone to it does not go away. The work moves to a personal laptop, a personal Google account, a phone on 4G. You have not reduced shadow IT. You have reduced your visibility of it, which is the only lever you actually had.

The scale makes prohibition even less plausible. Gartner has put shadow IT at 30 to 40 per cent of IT spending in large organisations, and expects three quarters of employees to acquire, modify or build technology outside IT's oversight by 2027. You are not going to block a majority behaviour. You can only decide whether it happens where you can see it.

Every unsanctioned app is a requirements document

Here is the reframe that changes the whole conversation. Nobody adopts an unapproved tool for fun. Somebody risked a telling off, and often spent their own money, because the sanctioned stack failed them in a way they could not get fixed.

Marketing living in Canva tells you the design request process is too slow. A project team running itself on Trello tells you the official ticketing tool is too heavy for lightweight work. A free file-sending service in the expense reports tells you your sharing controls block a legitimate everyday need. That is user research, delivered free, with the strongest possible signal of intent: people worked around you to get it.

Treat those discoveries as violations and you teach people to hide their needs. Treat them as findings and you get a prioritised list of what to fix in your own stack.

The risk was never the app, it is the account

The security argument for blocking sounds robust until you look at what actually goes wrong. Most shadow apps are mainstream SaaS with perfectly serviceable security. The genuine dangers are all properties of unmanaged use, not of the software:

• No single sign-on or enforced MFA, so one phished password exposes company data.
• No backup and no retention, so the data is one cancelled free tier from gone.
• No offboarding. When the person leaves, the account and everything in it leaves with them, a failure mode we covered in our IT offboarding checklist.
• No inventory entry, so nobody patches it, reviews it or even knows to worry about it.

Every one of those risks is fixed by bringing the app under management, and made permanent by driving it underground. Prohibition does not remove the risk. It guarantees the risk stays in its worst configuration.

Discover first, and make amnesty mean it

You cannot triage what you cannot see, so the first real move is discovery, not policy. The signal is already sitting in systems you run: the software inventory your endpoint agent collects, the OAuth consent grants in your Microsoft 365 tenant, the recurring small charges in expense reports.

Then declare an amnesty, and mean it. Nobody gets punished for declaring a tool. Each discovery gets one of three honest outcomes: adopt it properly, behind SSO and MFA and in the asset register; replace it with something that meets the need it revealed; or, rarely, retire it, with a written explanation of the specific risk. If most conversations end in a ban, the declarations stop, and you are blind again within a quarter.

The root cause is the speed of your yes

The uncomfortable conclusion is that shadow IT is not a user behaviour problem. It is a service level problem, and it is yours. If the sanctioned route to a new tool is a form, a committee and a three week wait, while a credit card takes three minutes, the outcome is designed in. People are not going around IT because they are reckless. They are going around IT because IT is the slow path.

So measure your time to yes, and get it under a couple of days for low-risk requests. The teams with the least shadow IT are never the strictest ones. They are the fastest ones, because the sanctioned path wins on convenience, which is the only competition that was ever actually running.

Where this fits with Helios

The discovery step is the part tooling can genuinely shorten. The Helios agent already inventories installed software across every device it monitors, alongside patch state, antivirus and backups, so new and unexpected applications show up in the estate view rather than in an annual audit. With the Microsoft 365 integration connected, sign-in activity in the tenant adds the SaaS side of the picture. What you decide to adopt, replace or retire stays a human call. Helios just makes sure you are deciding from what is actually installed, not from what the policy says should be.