The pricing approvals run from a spreadsheet on one analyst's personal drive. IT does not know it exists. When the analyst is on leave, the approvals wait, and nobody else knows which tab holds the current figures.
That spreadsheet is shadow IT. This piece defines the term, explains why it appears, sets out what it puts at risk, and recommends what to do about it.
What shadow IT is
Shadow IT is software a team runs without the knowledge or sign-off of IT. It grows beside the approved tools and fills the gaps they leave.
The common forms are familiar:
Spreadsheets used as operational databases.
Shared drives that hold the only copy of a record.
Personal scripts that automate a step the official tool does not cover.
SaaS subscriptions paid on a personal or team card.
Apps built with an AI model on a personal account, which vibe coding has made much quicker to produce.
None of these starts as a decision to bypass IT. A team finds a faster way to get the work done and uses it. Over time, the faster way carries weight: decisions are made from it, data lives in it, and the approved system becomes the secondary copy.
Why it appears
Shadow IT usually points to a gap, and there are three common ones.
The first is a tool that does not cover the work. If a step in the process is not handled by the approved system, someone handles it by hand. That manual step becomes a file, a script, or a process that nobody formally owns.
The second is a tool handed over without the context to use it. When a team is unsure what a tool is for or which decisions it owns, it fills the gap with whatever is to hand. A spreadsheet needs no onboarding, no permissions, and no explanation. Built well, used by nobody covers this pattern in detail.
The third is the queue. The approved route to a new tool runs through a backlog that moves slower than the work. The team builds its own version in the meantime, and the meantime becomes permanent.
A well-built tool that was not properly handed over can produce shadow IT as reliably as a poorly built one. The cause is rarely the people involved. The business moved faster than its approved tools did.
What it puts at risk
Shadow IT often works well in the short term. The risk builds slowly, and it sits where IT and security cannot see it.
Access
Shadow tools rarely sign people in through the company's identity provider. Access runs on shared links, shared passwords, or personal accounts. When someone leaves, their access to the file or the app does not end with their directory account.
Audit
Nobody records who changed what. If a figure in the pricing sheet is wrong, there is no history that shows when it changed or who changed it. For regulated work, that gap becomes an audit finding.
Data location
Customer or financial data in a personal drive or an unapproved SaaS tool sits outside the company's controls. It may also sit outside the required region, which turns a convenience into a data protection question.
Continuity
Many shadow tools depend on one person. They know the formulas, the order of the steps, and the exceptions. When that person is away or leaves, the process stops or runs on guesswork.
Conflicting numbers
The same data ends up in several places, maintained by different people. Two reports disagree, and the meeting is spent deciding which is right. What is tool sprawl covers this cost in more detail.
How to find it
Three signals are reliable:
The same data exists in more than one place, maintained by different people.
Decisions are made from a source outside the approved system.
A process stops when one named person is away.
The fastest way to find shadow IT is to ask the people doing the work. Ask what they open first in the morning, and what they would lose if their laptop disappeared. The answers are usually specific.
What to do about it
Start by asking why each shadow tool exists. What does the spreadsheet give the team that the approved tool does not: speed, clarity, flexibility, or familiarity? The answer points to a gap in the tool, in how it was introduced, or in how feedback reaches its owner.
Then there are three options for each one:
Retire it, when the approved tool can cover the work after a fix or a clearer handover.
Move it into a supported system, when the shadow tool carries a real process. Rebuild it with sign-in through the identity provider, roles, an audit trail, and a named owner.
Register it and leave it, when it is short-lived and touches no customer, financial, or personal data.
Our view
We recommend moving every shadow tool that carries a business process into a supported system, starting with those that touch customer or financial data. The reason is exposure: those tools hold the most sensitive data with the fewest controls. Banning them without a replacement sends the work somewhere even less visible.
The person who built the shadow tool knows the process better than anyone. They are the natural product owner for the supported version, and they keep the final say on how it works. We build with them, and add the access, the audit trail, and the deployment path the original never had. Four controls that make an internal tool safe to rely on sets out what the supported version needs.
