The shadow IT problem isn’t the IT, it’s the shadow

The standard framing of shadow IT has not changed in a decade. Departments buy Software-as-a-Service (SaaS) tools without the IT team’s involvement, IT discovers them on a security review, controls are tightened, a new policy lands in the staff handbook, the cycle resumes. The framing assumes shadow IT is a behaviour to be policed. 

It is worth looking at the numbers before accepting that framing. Everest Group estimates shadow IT now accounts for 50% or more of total IT spend in large enterprises. IBM puts the share of employees who have acquired, modified or created technology without their IT team’s knowledge at 41%. The latest IBM cost-of-breach data attributes 35% of data breaches to shadow data, sitting in systems IT was not aware of. 

When half the IT spend and 41% of the workforce are operating outside the model, that is not a compliance issue. It is the model itself. 

What shadow IT is actually telling you 

Shadow IT is rarely an act of defiance. It is almost always a rational response to a delivery pathway the requester believes will not move at the speed of the need. A team finds a tool, the contract is signable on a corporate card, the setup is supposed to take an hour, and the alternative is a procurement and assurance cycle that, in their experience, takes months. The decision to bypass IT is not a choice between safe and risky. It is a choice between something that exists and something that might. 

The 50% number is not a measure of how naughty the workforce has become. It is a measure of the gap between what the IT operating model produces and what the business is actually trying to do. A small gap produces occasional shadow IT around the edges. A large gap produces 41% of the workforce. 

Why the policing response does not work 

When the response to a 50% shadow IT footprint is stronger controls, three things tend to happen. The controls catch the visible cases and miss the invisible ones, so the apparent shadow IT reduces while the actual figure does not. The next generation of shadow IT shifts to harder-to-detect categories, with shadow AI a particularly clear example. And the underlying gap, the reason the business went around IT in the first place, persists, because the controls treat the symptom rather than the cause. 

The harder version of the policing response is to centralise procurement, route every request through IT, and tighten the assurance cycle. This sometimes works for the short term, often increases the gap between IT and the business, and almost never reduces shadow IT in the long term. The business does not stop needing what shadow IT was getting it. 

The genuine risks are real 

None of this is to argue that the risks are imaginary. Shadow IT does create security gaps, regulatory exposure, fragmented licensing, integration debt and ownership problems. The IBM finding that 35% of breaches involve shadow data is not a soft number. The point is that those risks are downstream effects of the operating model gap, and they will reproduce themselves at whatever level the gap sustains. Closing them one tool at a time is endless work that does not converge. 

What an operating model that closes the gap looks like 

The interesting question is what changes when an IT operating model is designed to produce, deliberately and at speed, what shadow IT is trying to obtain. A few observations from the work. 

The first is that a procurement pathway for low-risk SaaS that completes in days rather than months removes most of the rational reason to go around it. That pathway needs to exist by design, with assurance proportionate to risk rather than uniform across categories. Most IT functions can run this. Few have set it up. 

The second is that the assurance done on shadow IT after the fact is often heavier than the assurance that would have been required before the fact, because the post-hoc review has to address everything the buyer skipped. A lighter, faster forward path is cheaper than a thorough retrospective one. The operating model can be designed for that. 

The third is that the integration, support and lifecycle questions raised in the standard shadow IT critique (who supports it, how it integrates, what happens on leaver provisioning) are real, and the fastest way to make sure they get answered is to make answering them part of the procurement pathway from the start, not a discovery to be made later. 

Final thought 

A rising shadow IT footprint is not a discipline problem to be solved with policy. It is a delivery problem the operating model is producing, and the operating model is the only place the problem can actually be fixed. The departments going around IT are not the failure. They are the diagnostic. 

The useful question is not how to reduce shadow IT. It is what an IT operating model would look like that produces what shadow IT is trying to obtain, by design, at the speed the business needs. Most organisations have not asked that question. Most could.