Shadow IT is a symptom, not a crime

Every organisation past a certain size runs on software nobody approved: a spreadsheet that schedules the shifts, an Access database from 2014, a form somebody built over a weekend, a personal automation account holding a key to the finance system. This is usually described as a discipline problem. It is almost never a discipline problem.

It is a queue problem. Somebody needed a small system, the official route quoted months, and the work still had to happen this quarter. What they built was a rational response to the options in front of them.

Why it happens

It is worth being specific, because the reasons point at different fixes.

• The request is small and the process is not. A five-field register goes through the same intake, prioritisation and procurement as a core system, so it never reaches the top of any list.
• Nobody owns “small”. Large projects have sponsors. A tool that helps eleven people in one department has no one whose year is judged by whether it exists.
• The department has budget and a card. A subscription is an expense, not a project, and expenses do not require the platform team.
• The tools got good. Building something that works is genuinely within reach of a capable non-developer now. The barrier that used to enforce central IT by accident has gone.

None of these are solved by a policy stating that unapproved tools are forbidden. They are solved by shortening the queue — or by admitting the queue exists and giving people a supported way to build in the open.

The risks that are real, in order

Shadow IT risk registers tend to open with compliance and end with vague warnings about security. In practice, the failures that actually happen come in a fairly predictable order.

• One person understands it. The most common failure is not a breach. It is that Marit built it, Marit has left, and nobody can change the VAT rate.
• It is not backed up. A personal drive, a laptop, a free tier with no retention. The tool is fine until the day it is not, and there is no earlier version to go back to.
• Access does not end when employment does. The company account leaves with the offboarding checklist. The tool built on a personal login does not — and neither do the shared passwords three people know.
• Company data is in a personal account. Not the tool itself: the customer list inside it, sitting in something registered to an individual, outside every agreement your organisation has signed.
• Nobody can answer the regulator. When you are asked where personal data is processed and who has access, systems you do not know about are systems you cannot answer for. This is where the compliance concern is genuinely earned.
• It is quietly load-bearing. The one nobody notices until an audit: a spreadsheet that started as a convenience and is now the only record of something the business runs on.

Finding it without a witch hunt

You cannot govern what you cannot see, and you will not see it if the first move is an investigation. People conceal tools from auditors and volunteer them to colleagues. The framing decides which one you get.

• Run an amnesty, and say the word. Announce plainly that nobody is in trouble, that the goal is to keep what works, and that anything handed over gets backed up and supported. Then honour it, visibly, the first time somebody tests it.
• Ask what people built, not what they use. “What did you make to get your job done?” gets answers. “List your unapproved software” gets silence.
• Follow the expenses and the sign-ins. Card statements and your identity provider’s list of applications will show most of the subscriptions without anyone having to confess to them.
• Look for the shared logins. A password three people know is both a finding and a good conversation opener about what it is protecting.

Deciding what happens to each one

Once you have a list, most items sort quickly into four piles. The mistake is treating everything as though it belongs in the first.

• Adopt. It matters, it works, and it needs an owner, a backup and company sign-in rather than a rewrite. Most of the list ends up here.
• Rebuild. It matters and the current version genuinely cannot be secured — data in a personal account, or logic nobody can follow. Rebuild it properly, and keep the person who wrote it involved; they know the rules the software encodes.
• Retire. It solved a problem that no longer exists, or two people use it out of habit. Turn it off, with notice.
• Leave alone. A spreadsheet one person uses to organise their own work is not a system. Not everything needs governing, and hoovering up the harmless ones is how an amnesty loses its credibility.

Making the approved path the fast one

Everything above is cleanup. It comes back unless the underlying arithmetic changes, because the workaround only ever won on speed.

What changes the arithmetic is a supported way to build small systems that is genuinely quicker than the unsupported way — where company sign-in, hosting, backups and a record of who did what come as part of building it rather than as a review at the end. When the sanctioned route is the fast route, shadow IT stops being a policy problem and becomes an unattractive option.

That is the case Studio for business exists to make: departments get to build the tool they need, in an environment that already has single sign-on, managed hosting and an audit trail, so what they build is visible from the day it exists instead of the day it fails. But the principle holds whatever you use to do it — governance that is slower than the alternative is governance that is being routed around.