Almost every unapproved tool is somebody solving a real problem your platform did not. Treating that as a discipline issue guarantees the next one is better hidden.
Somebody in marketing has been using a file transfer service for eighteen months. Somebody in sales has a personal account on a note-taking tool that records client calls. Somebody in finance has a spreadsheet in a cloud account you have never heard of.
The reflex is to treat this as a compliance failure and respond with a policy and a block list. That response reliably produces one outcome: the next tool is harder to find.
Why it happens
The useful thing about that ordering is that four of the five causes are addressable by changing something other than people's behaviour. The sanctioned tool was worse, procurement was slower than the need, nobody knew there was an option, or a free tier removed every point at which somebody would have asked.
Starting from "people are circumventing our controls" leads to a response that does not touch any of those, which is why the problem recurs.
The risks, stated accurately
It is worth being precise, because overstating this loses credibility with the people you need to cooperate.
Data you cannot find. The real one. Client material in an account nobody knows about cannot be included in a subject access response, a legal hold, or an export when the person leaves. This is also the most likely way you find out: somebody resigns and a function stops working.
Access that outlives employment. A personal account is not in your offboarding process. The leaver keeps it, along with whatever is in it.
No contract. No data processing agreement, no security commitments, no notification obligation, no agreed exit. If it holds personal data, that is a regulatory problem independent of whether anything goes wrong.
Authentication outside your controls. Usually a personal email and a password, frequently reused, with no MFA and no conditional access.
Duplication and drift. Two versions of the truth, and the one your systems can see is the stale one.
What is usually overstated: the tools themselves. Most popular SaaS products are reasonably secure, often more so than things you run yourself. The risk is almost never that the vendor is bad. It is that you do not know the relationship exists.
Finding it
Three methods, in order of effort and effectiveness.
The expenses report. The highest yield and the least technical. Export twelve months of card and direct debit transactions and look for anything that resembles software. Most shadow IT is paid for by somebody with a corporate card, and there it is, in finance's own data.
Identity sign-in logs. Your identity provider records sign-ins to third-party applications using work accounts. Review the application list. Anything you do not recognise is a conversation.
Ask. A genuinely non-punitive survey: what tools do you use that IT did not provide, and what do they do for you? The results depend entirely on whether people believe the amnesty. Say so explicitly, mean it, and do not act punitively on the answers, or this method is unavailable to you for several years.
What to do when you find one
The second question is the important one, and the follow-up matters more than the migration. If an approved tool does the job and somebody did not know, that is a communication failure, and finding out why prevents the next ten instances. Usually the answer is that the approved option was mentioned once, two years ago, in an email.
The third outcome is the one organisations resist and should not. If three teams independently adopted the same tool, they have identified a gap in your platform more accurately than any requirements-gathering exercise would. Adopt it properly: a contract, a data processing agreement, single sign-on, an owner, and a place in the register. You have converted a risk into a capability and spent almost nothing.
Reducing the supply
Four changes that reduce new shadow IT more than any policy.
A fast lane in procurement. A lightweight path for small purchases, with a one-week turnaround and a named person who can say yes. Most shadow IT exists because the alternative was a six-week process.
Publish what is approved. A single page listing the approved tool for each common job, with a link to how to get it. Trivially cheap, and it addresses the cause nobody expects to be significant.
Fix the gaps people route around. If the approved file transfer cannot handle the file sizes people actually send, they will find something that can, and no policy will stop them.
Make asking easy. One address, a promise of a response within a stated time, and a culture where the answer is sometimes yes. If every request is refused, requests stop and adoption continues silently.
The policy, which should be short
A page. What needs approval, how to request it, what the turnaround is, and the explicit statement that if you are already using something unapproved, telling us now has no consequences.
That last clause is the one that determines whether the policy produces information or silence. Without it, you have a document that makes the problem invisible rather than smaller.
