Shadow IT is any technology used for work that the people responsible for technology did not approve and often do not know about. A team buying a project tool on a personal card. A department running its operation out of a spreadsheet nobody has ever backed up. Someone forwarding work mail to a personal account because the official system is slow.
It is one of the oldest problems in corporate IT and it has been written about exhaustively. Most of what has been written is now partly obsolete, because the controls the entire discipline was built on assumed that adopting a tool involved installing, buying, or connecting something. The current version of the problem involves none of those, and that is the part this guide is actually about.
If you already know what shadow IT is and want the modern half, skip to what changed.
Why it happens, which is not what most guides say
The framing that dominates this topic treats shadow IT as a discipline problem: staff who ignore policy, and the answer is more policy and better enforcement. That framing has been available for twenty years and the problem has not gone away, which should tell you something.
Shadow IT is almost always a demand signal. Someone had work to do, the sanctioned path was too slow or did not exist, and they solved it. The tool they chose is usually a reasonable choice for the job, made by a competent person acting in good faith. That is why enforcement-first responses fail: you are trying to suppress a symptom of an unmet need, and the need is still there afterwards.
Three reliable causes, in rough order of how often they are the real one:
The sanctioned option does not exist. Nobody provided a tool for the job, so people found one. This is the most common and the easiest to fix.
The sanctioned option exists but is worse. It is slower, uglier, requires a ticket, or takes six clicks where the alternative takes one. Here the shadow tool is a review of your stack, and worth reading as one.
The approval path is the obstacle. Getting something approved takes weeks and produces no answer, so people stop asking. If you have never measured how long a request takes to answer, that number is probably your actual shadow IT policy.
The risks, ranked honestly
Not all shadow IT is dangerous, and treating it as uniformly dangerous is how IT loses credibility with the business. A designer using an unapproved font manager is not the same category of problem as customer data in an unvetted tool. Sorted by what actually causes damage:
Data leaving where you cannot follow it. The real one. Company or client information sitting in an account the company does not control, under terms nobody read, which cannot be retrieved when the person leaves.
Access that outlives the person. Shadow tools are rarely in the offboarding checklist because nobody knew they existed. The account stays live and connected after the employee is gone.
Regulatory exposure. Personal data processed in a tool with no agreement in place. Whether this is serious depends entirely on your jurisdiction and what data you handle.
Single points of failure nobody can see. The spreadsheet that runs a critical process, on one laptop, understood by one person. Rarely called shadow IT, and it is the same problem.
Duplicated spend. Real, usually the first thing finance notices, and the least important of the five.
What changed, and why the old controls miss it
Every classic shadow IT control has the same shape: catch the moment of adoption. Software asset management catches installs. Procurement review catches purchases. Network monitoring and CASB catch traffic to unsanctioned services. Endpoint control catches what runs on the machine.
Each of those assumes adoption is an event that leaves a trace. AI tools broke that assumption. A staff member opens a tab, pastes in a document, and gets value. Nothing was installed, nothing was purchased, no agent was deployed, and the destination is a widely used and entirely reputable domain that no sensible blocklist blocks.
Worse, the fastest-growing form of it involves no decision at all. Vendors keep switching AI features on inside software you already bought and already approved. The traffic goes to a domain on your allowlist. Nobody adopted anything. There is no moment to catch.
This is why shadow AI deserves separate treatment rather than being filed as a subcategory. The parent problem is one of unapproved adoption. The AI version is a problem of unapproved data flow, which your existing controls were never built to see. The detail is here: shadow AI, how to detect it, and what each method misses.
How to find shadow IT without buying anything
There is a large market of tools for this and most companies can get most of the way with things they already have. In cost order, cheapest first.
Ask, without threat. The most underrated method. If people believe the answer determines whether their tool gets taken away, you get nothing. If they believe it determines whether it gets paid for and supported, you get a list. Frame it as a procurement exercise, not an audit.
Expense and card data. Every paid tool is on somebody's card. Finance can produce this in an afternoon and it is the single highest-yield source for paid shadow IT. It sees nothing free, which is a large blind spot and a growing one.
Identity and single sign-on logs. Anyone who signed up with a work email is visible here, and this names people as well as tools. Misses personal-email signups entirely.
DNS and egress. Shows which services are being reached from the managed network. Misses mobile data, home working, and personal devices, which since 2020 is a much bigger gap than it used to be.
Browser extension inventory. Rarely checked, frequently alarming, and reachable through managed browser policy on most estates.
Vendor admin consoles. The only way to see AI features and integrations switched on inside tools you already own. Needs a person to keep checking, because vendors do not announce it in a way anyone reads.
Run the first four together and you have a defensible picture in about two days without a purchase order. Everything a paid discovery tool adds sits on top of that baseline rather than replacing it.
What to do once you can see it
Resist the instinct to shut it all down. Sort what you found into four buckets and treat them differently.
Adopt. It is a good tool solving a real problem. Buy it properly, move it to a company account, put it on the approved list, and tell the person who found it that they were right. This bucket buys you more future visibility than any control you could deploy, because it changes what happens the next time someone finds something.
Replace. The need is legitimate, the tool is not acceptable. You owe them a working alternative before you remove the one they have, not after.
Tolerate. Low risk, not worth the fight. Write down that you have consciously accepted it, so the decision is a decision rather than an oversight.
Remove. Genuinely unacceptable. Should be a small pile. If it is a large pile, something upstream in how you provide tools is broken.
Then close the loop that created the problem: publish a request route with a committed response time. The single most reliable predictor of how much shadow IT a company generates is how long it takes to get an answer when someone asks properly.
Shadow IT and shadow AI, side by side
| Classic shadow IT | Shadow AI | |
|---|---|---|
| What is unapproved | A tool or service | Where data goes, often in an approved tool |
| Adoption moment | Install, purchase or signup | Frequently none, a tab or a vendor update |
| Where you catch it | Procurement, network, endpoint | Expense and DNS catch some, the rest needs point-of-use visibility |
| Main risk | Access and continuity | Disclosure, and it is irreversible |
| Fix | Sanction the tool | Sanction the tool and define the data rules, because the tool alone decides nothing |
The last row is the practical difference. Approving a project management tool settles the question. Approving an AI tool settles almost nothing, because the risk is in what gets typed into it, which is why AI needs a written data rule where most shadow IT never did. That rule is a short document: the AI acceptable use policy template, and the decisions behind it if you would rather work it out from your own situation.
FAQ
Any technology used for work without approval or knowledge from the people responsible for technology. It covers unapproved SaaS subscriptions, personal accounts used for work data, unmanaged devices, browser extensions, spreadsheets running critical processes, and increasingly AI tools reached through a browser. It is usually created by competent people solving a real problem faster than the sanctioned route allowed, which is why treating it purely as a discipline problem rarely works.
In order of what actually causes damage: company or client data sitting in accounts the company does not control and cannot retrieve, access that survives an employee leaving because the tool was never in the offboarding process, regulatory exposure where personal data is processed with no agreement in place, undocumented single points of failure such as a critical spreadsheet on one laptop, and duplicated spend. Spend is usually noticed first and matters least.
Four methods that need no purchase. Ask staff directly, framed as procurement rather than audit so answers are honest. Review expense and card data, which catches every paid tool but nothing free. Check identity and single sign-on logs, which name both tools and people but miss personal-email signups. Review DNS and network egress, which misses mobile, home and personal devices. Run together they produce a defensible picture in about two days.
Classic shadow IT is an unapproved tool, and adoption leaves a trace through an install, a purchase or a signup that traditional controls were built to catch. Shadow AI is frequently unapproved data flow inside an already-approved tool, with no adoption moment at all, particularly when a vendor switches an AI feature on inside software you already own. Approving a conventional tool settles the question; approving an AI tool settles little, because the exposure is in what gets typed into it.
Rarely as a first move. Sort what you find into adopt, replace, tolerate and remove, and expect the remove pile to be small. A large remove pile indicates a problem with how tools are provided rather than with staff behaviour. Blocking without providing an alternative pushes the same activity onto personal devices and accounts, where there is no visibility at all. The most reliable predictor of how much shadow IT an organisation generates is how long it takes to get an answer when someone asks properly.