What Is Shadow IT? Why the Real Risk Is What You Can’t See

Shadow IT is every device, app or online account staff use for work that IT never approved or even knew about. Most security advice treats it like a discipline problem: find the culprit, block the tool, remind everyone of the acceptable use policy. That approach mostly fails, and the UK’s National Cyber Security Centre (NCSC) says as much in its own guidance. The businesses that actually reduce their exposure treat shadow IT as a signal, not a crime.

What counts as shadow IT, in plain terms

It covers two things: devices your IT team never enrolled, and services it never approved. A personal phone checking work email is shadow IT. So is a smart speaker plugged in at someone’s desk, a spreadsheet living in three different personal Dropbox accounts, or an AI assistant fed a client’s confidential document because it answered a question faster than waiting for a colleague. None of these start as a security incident. They start as someone trying to get their job done.

Why “just ban it” does not work

Banning a tool assumes staff will simply stop needing what it gave them. They will not. They will find a quieter workaround instead, one further from IT’s view than the last. The NCSC’s guidance is blunt about this: shadow IT is rarely the result of malicious intent, and it usually points to staff struggling with the sanctioned tools or process for a specific task. Punish someone for admitting they used an unapproved app, and their team learns a clear lesson: do not admit it next time. Your visibility gets worse at exactly the moment you needed it to improve.

There is also a scale problem with banning things one at a time. IBM’s research suggests around 80% of employees use some form of unsanctioned technology, and roughly 38% of a typical business’s technology purchases are already chosen by business teams rather than IT. That is not a handful of rule-breakers. It is most of the organisation, responding rationally to slow processes and software that is genuinely easier to sign up for than to request.

Why the real risk is what you cannot see

An unsanctioned tool is not automatically dangerous. A missing entry on your asset register is. Once something sits outside your visibility, several things quietly stop happening. Patching stops. Monitoring stops. So does its inclusion in your attack surface management and testing scope. The NCSC frames the core problem well: once data leaves your sanctioned systems, you cannot be certain where it is, how it is processed, or where it ends up.

That blindness shows up in three ways that matter to a business, not just to IT:

• Compliance. Client data stored somewhere unassessed can breach GDPR obligations, with no audit trail to show otherwise.
• Breach severity. An unmanaged, unsegmented device gives an attacker a quieter route to move deeper into the network once they are in.
• Wasted spend. Paying for an approved tool while three teams also pay, individually, for an unsanctioned alternative is common, and nobody notices until someone finally counts.

What actually reduces it

Not a ban. A better default. Four things work together.

First, find out why the workaround exists before doing anything else. A missing feature and a two-week approval process need completely different fixes. Treating them the same wastes effort. Second, give staff a sanctioned option that is genuinely as easy as the one they found themselves. “Use the approved tool” only works if the approved tool does not cost them an afternoon. Third, shorten the distance between “I need a tool” and “I have a tool”. Every extra day in that gap is another day someone might solve it on their own. Fourth, put technical guardrails in place, such as device registration and network access controls, so unmanaged assets get flagged automatically instead of relying on someone noticing.

Discovery has to run alongside all of this. Network and asset scanning catches devices that connect without a matching record. A cloud access security broker flags traffic heading to unapproved cloud services. An external attack surface review, ideally paired with a scoped penetration test, finds the forgotten subdomain or the old test server nobody remembers standing up. A tester has no reason to trust your list of “known” systems any more than an attacker would.

Where the estate has grown unevenly for years, moving toward a zero trust approach matters more than any single ban, because it stops assuming a device is safe just because it is sitting inside your network.

What this means for how you scope a penetration test

Most testing scopes start from an asset list somebody wrote down months or years ago. If shadow IT has grown since then, the scope is already out of date before the test begins, and the report will confirm the health of systems you already knew about while missing the ones you did not. A better approach is to run a light discovery pass first, using logs, a network scan or an external attack surface review, and then let those findings widen the scope before the tester starts. It costs a little more time up front. It also means the report actually reflects the business as it runs today, not the business as the diagram describes it.

This matters more the longer it has been since your last review. A network that looked complete two years ago has almost certainly grown new corners since: a new SaaS tool here, a contractor’s laptop there, a test environment nobody switched off. None of that growth waits for your renewal date, so treating discovery as a one-off task rather than an ongoing habit is where most of the risk quietly accumulates.

Shadow IT and BYOD are not the same thing

Bring-your-own-device is a policy the business chooses, with rules attached. Shadow IT is what happens without that choice being made at all. Ironically, a well-designed BYOD policy is one of the more effective ways to shrink shadow IT, because it gives staff a sanctioned, secured way to use their own phone rather than leaving them to work around a policy that ignores how they actually operate day to day.

Frequently asked questions

Is shadow IT always a security incident?

No. Most of it is ordinary staff behaviour, not an attack. The risk comes from the blind spot it creates, not from bad intent.

Can a penetration test find shadow IT?

Often, yes, especially external engagements. Testers regularly turn up forgotten subdomains, unmanaged Wi-Fi access points or old servers precisely because they look for any reachable system rather than trusting an official inventory.

Does GDPR treat shadow IT differently to sanctioned systems?

Not explicitly, but the practical effect is worse. Your business still carries the compliance responsibility for personal data, and an unsanctioned tool usually means no audit trail and no assessment to fall back on.

What is shadow AI?

The same problem in newer clothes: staff pasting company or client data into public AI chatbots or unreviewed browser extensions. The NCSC treats it as part of the same shadow IT conversation, because the underlying risk is identical.

Should smaller businesses worry about this too?

Yes, arguably more so. Smaller organisations often have looser asset management and fewer dedicated IT staff, so a workaround is both easier to create and harder to spot.

Shadow IT will keep appearing for as long as approved processes are slower than the alternative. Fighting that with bans just pushes the problem further out of sight. Fighting it with visibility, faster sanctioned options and an honest picture of your real attack surface actually works. If you are not sure your last penetration test scope reflected what your business actually runs today, get in touch and we can help you find out.