A finance team counts 34 SaaS subscriptions. IT's list has 41. The actual number, once you look at what is running on the endpoints, is somewhere north of 90.
This is normal. Not good, but normal, and the gap is almost always in the same direction.
Some field notes on finding it and what to do about it.
The three places it hides
Paid and expensed. Shows up in card statements, usually under someone's name rather than a vendor category. Easiest to find, smallest problem.
Free tier, work email. Signed up in ninety seconds, never touched finance, might touch SSO if you are lucky. This is the biggest category by count.
Personal account, work data. The one that matters. Someone's own Dropbox or personal AI subscription with company material in it. No trace anywhere in your systems by design.
Expense data finds the first. Identity logs find some of the second. Only endpoint activity finds the rest, and even then you are seeing domains and applications rather than what went into them.
What the pattern usually means
Nine times in ten, shadow IT is a workaround, not a rebellion.
The approved tool is slow. The request queue is three weeks. The sanctioned option does not do the one thing this team needs. Somebody found something that worked and got on with their job.
Which is why the discovery exercise is more useful as a product signal than as a compliance sweep. If four separate teams independently adopted the same unapproved tool, that is not four policy violations. That is a specification for something you should be buying.
We have seen this land badly when it gets framed as an audit. People hide things faster than you can find them, and you lose the signal along with the tools.
Triage, not a purge
A rough sort that has held up:
Tools with no company data in them — diagramming, reading, personal productivity. Leave them alone. You have better things to do and the risk is negligible.
Tools with company data but low sensitivity — a project tracker, a shared doc for meeting notes. Bring them into procurement if enough people use them, otherwise leave them and note them.
Tools holding customer data, credentials, source code or anything regulated. This is the actual list. It is usually short — often single digits — and it is where all the risk lives.
Anything AI-adjacent where prompts might contain confidential material. Newer category, moves fast, worth its own conversation rather than lumping it in.
The value of the exercise is producing that third list. Everything else is inventory.
Why blocking mostly fails
Block the file-sharing tool and the file-sharing continues. It just moves to a personal laptop, or a personal account on the work laptop, or a phone.
You have not removed the behaviour. You have removed your visibility of it, which is worse than where you started, and you have confirmed for that team that IT is an obstacle to route around rather than a service to use.
The exception is real: a small set of categories where the risk is severe enough that you accept the displacement and block anyway. Keep that list short and be able to explain each entry. The longer the blocklist, the more of your organisation's ingenuity goes into defeating it — and people are very good at this.
Doing the discovery without wrecking trust
This is the part worth thinking about, because shadow IT discovery is where a lot of companies accidentally turn analytics into surveillance.
Look at aggregate application and domain usage across teams, not individual browsing histories. You are trying to find which tools are in use, which is an inventory question. You are not trying to find who used what, which is an investigation question and needs a much better reason than curiosity.
Tell people you are doing it and why. "We are building a picture of what software the company actually runs so we can buy the right things and secure the right things" is a reason people accept, and it is true.
And when you find the tool four teams adopted, buy it. That is what makes the next discovery exercise easy, because people stop hiding things from a function that occasionally gives them what they asked for.
The wider framing is in ethical employee monitoring; the collection-model question — how much you need to capture to answer a given question — is in the computer monitoring guide.
Where this sits relative to real security tooling
Activity metadata tells you which applications and domains are in use, at what volume, by which teams. That is enough for inventory, procurement and most of the triage above.
It does not tell you what data moved. If your question is whether customer records left the building, you need DLP, and no amount of app-usage data substitutes for it — see the UAM guide for where that line sits.
ProdView does the inventory half. App and domain usage across the fleet, aggregated by team, from metadata rather than content, with employees able to see their own data. Free for three seats, which is usually enough to discover that the number is bigger than anyone thought.