Shadow IT: How to Govern the Apps Your Employees Built Themselves

Somewhere in your business, a spreadsheet with seventeen tabs is doing the work of a £40,000 system. A sales rep built it. A formula breaks if anyone sorts column G. Nobody else fully understands it, and the rep is the only one who can fix it. This is shadow IT, and it is not a failure of discipline — it is what capable people do when the official tools don't keep up with the work.

The instinct, once a leadership team notices, is to ban it. That instinct is wrong, and it is also futile. Gartner found that 41% of employees are now "business technologists" — people outside the IT function who build technology or analytics capabilities for the business — and that 74% of technology purchases are funded, at least partly, by business units rather than IT (Gartner). The building has already happened. The only real question is whether you can see it, and whether you can take the reins before something you didn't know existed quietly fails.

Why your team built their own tools in the first place

Before you govern anything, it helps to be honest about why employees building their own tools became normal. They were not trying to undermine you. They were trying to get through Thursday.

Retool's 2026 build-vs-buy survey puts numbers to the motive. Among people who shipped tools outside IT oversight, 31% did it because building was faster, 25% because the existing SaaS didn't do what they needed, and 18% because the approval process was too slow (Retool). The same report found that 60% of builders created tools outside IT oversight in the past year, and — the detail most leaders miss — 64% of those unauthorised builders were senior managers. This is not a junior workaround problem. It is your most engaged people routing around friction you put in their way.

AI has poured petrol on this. With assistants that write working code from a sentence, 51% of builders have now shipped working software built with AI (Retool). The barrier to creating an internal app has collapsed. So the governance question for 2026 is no longer "how do we stop people building" — it is "how do we make sure the things they build don't become a liability we can't see."

The real risk isn't the app — it's that you can't see it

An employee-built tool is not inherently dangerous. A dangerous tool is one that holds up a critical process while remaining invisible to the people accountable for the business. The risk lives in the dark, not in the code.

Three exposures matter most when you think about how to govern shadow IT:

• Key-person dependency. When one person built it and only that person can maintain it, their resignation is a business continuity event. The "tool" leaves with them.
• Data and compliance drift. Unapproved tools may move data through personal cloud accounts or store it in places that breach GDPR — without the encryption, access control, or audit trail your approved systems carry (Nudge Security). Shadow IT is consistently named among the leading contributors to data breaches.
• Silent fragility. A spreadsheet macro or a no-code automation with no tests, no version history, and no owner can produce wrong numbers for months before anyone notices. Decisions get made on output nobody validated.

The newest layer is shadow AI — employees wiring company data into unapproved AI tools or building thin AI "wrappers" on top of platforms you did approve. As one 2026 governance analysis put it, the tools are inside the platforms you sanctioned, the people building them are your own staff, and the access they use is legitimate — so none of it passes through the checks designed to catch problems before production (Unite.AI). That is precisely why a ban fails: there is nothing to block at the perimeter. The work is already on the inside.

Step one: make the invisible visible

You cannot govern what you cannot list. The first move in any shadow IT governance programme is discovery — a deliberate, non-punitive inventory of every tool, spreadsheet, script, automation, and SaaS subscription the business actually runs on, regardless of who built it or whether it was approved.

Tone decides whether this works. If discovery feels like an audit hunting for offenders, people hide their best tools and you learn nothing. Frame it as the opposite: "Tell us what you built so we can protect it, support it, and make sure it doesn't fall on your shoulders alone." The unsanctioned spreadsheet a manager is quietly proud of is exactly the one you need to find — because it is usually load-bearing.

A practical discovery pass captures, for each tool: what it does, who built it, who depends on it, what data it touches, where that data lives, and what breaks if it stops. That last column is the one that tells you where the business is genuinely exposed. Treat shadow IT as feedback about where your official stack fell short — not as misbehaviour to be stamped out.

Step two: classify by risk and value, then decide

Once you have the list, resist the urge to act on all of it. Most of what you find will be harmless and can stay exactly where it is. The point of classification is to spend your attention only where it pays. Score each tool on two axes — how much the business depends on it, and how much risk it carries — and a clear decision falls out for each one.

• Low value, low risk — leave it. A personal tracker that helps one person stay organised needs no governance. Touching it only creates work and resentment.
• High value, low risk — adopt and document. A genuinely useful tool that's reasonably safe should be brought into the light: documented, given a named owner and a backup, and supported. You are not changing it, you are de-risking the knowledge.
• Low value, high risk — retire it. A tool nobody really needs that also moves sensitive data through a personal account is pure downside. Replace it with an approved path and switch it off.
• High value, high risk — rebuild it properly. The spreadsheet running your fulfilment, the script that reconciles payments, the automation your whole team has come to rely on. These earn a proper build: owned, tested, secure, documented, and not dependent on one person's memory.

This is also where tool sprawl gets resolved. When you map everything at once, you see the duplication — three teams paying for overlapping SaaS, two homemade tools doing nearly the same job. Sprawl drains budget, fragments data into silos, and erodes the visibility you need to respond when something breaks (TechTarget). The remedy is the same five-step rhythm IT teams use to consolidate any stack: define the goal, evaluate what exists, remove the redundant, centralise management, and train people on what remains. Consolidating unsanctioned internal apps into a few well-supported ones is usually where the quickest savings sit.

Step three: rebuild the few that hold the business up

For the high-value, high-risk tools, the honest answer is that the prototype did its job and now needs to become real software. The spreadsheet proved the workflow. The proof is valuable — it tells you exactly what to build, validated by the people who use it daily. What it shouldn't do is remain the production system.

Rebuilding shadow IT apps properly doesn't mean a sprawling enterprise platform. It means a small, owned application that does what the spreadsheet did, with the things a spreadsheet can't give you: access controls, a data store with backups, an audit trail, validation so bad input can't corrupt the numbers, and documentation so the next person isn't locked out. Crucially, the person who built the original should help shape the rebuild — they hold the domain knowledge, and folding them in turns a quiet risk into a supported asset rather than a turf loss.

The same discipline applies to AI-built tools. The convenience is real, but Retool found only 44% of builders thoroughly test AI-generated code before using it, while 8% deploy it with no changes at all (Retool). Govern citizen-developed apps the way you'd govern any code that touches money or customer data: review it, test it, and put a name against who maintains it.

Make it a rhythm, not a one-off

Shadow IT is not a mess you clean up once. As long as people are capable and your official tools have gaps, they will keep building — and you want them to, because that energy is where a lot of operational improvement comes from. The aim of a shadow IT policy and controls is to channel it, not choke it.

A workable policy is short and human. Define a fast, low-friction way for someone to register a tool they've built or want to build, so the default path is "tell us," not "hide it." Set a light bar for what needs review — anything touching customer data, money, or a process other people depend on. Run discovery on a cadence, perhaps quarterly, so the inventory never drifts more than a few months out of date. And close the loop the way good governance frameworks recommend: discover, educate on why it matters, engage with the teams to understand what they needed, and enable them with a secure, approved way to get it (Nudge Security).

Done this way, governance stops being a brake and starts being a relief. Your people keep solving their own problems. You keep the ability to see what the business runs on. And the spreadsheet with seventeen tabs becomes a documented, owned, properly built tool — instead of a resignation letter waiting to take a critical process with it.

If you can already name the two or three homemade tools that would hurt if they vanished, you don't need a year-long programme. You need to find them, decide which to keep, and rebuild the ones that matter — calmly, with the people who built them still in the room.