in one lineA shadow IT policy defines how new tools enter your environment; it works only when it is faster than going around it.
the numbers
- 48%of SaaS applications sit outside IT's managementProductiv State of SaaS, 2024
- 78%of people who use AI at work bring their own toolsMicrosoft & LinkedIn Work Trend Index, 2024
- 63%of organizations have no AI governance policyIBM Cost of a Data Breach, 2025
1what a shadow IT policy actually covers
A shadow IT policy is a set of rules and processes that govern how software, services, and integrations enter and exit your company's environment. At minimum it answers: who can approve a new tool, what must be reviewed before a tool is used with company data, and what happens when someone adopts a tool that did not go through that review.
An app approval process is the operational core. The policy describes who requests a tool, who reviews it, what the criteria are, and how long the review takes. If the review takes longer than it takes to sign up for a free account, the policy will be bypassed.
A shadow IT policy is separate from, and complementary to, an acceptable use policy. An acceptable use policy governs behaviour with existing tools. A shadow IT policy governs how new tools enter the environment.
2what happens when there is no process
Without a defined pathway for tool adoption, every employee who needs a solution that the current stack does not provide faces a choice: submit a request with no clear timeline and no guarantee of approval, or sign up for something that solves the problem today.
Most will solve the problem today, which is a rational response to an unclear process. Shadow IT is the aggregate outcome of those decisions.
A missing policy prevents only governed tool adoption. The tools arrive regardless. The difference is that without a policy, IT has no visibility and no opportunity to assess the risk before the tool is in use.
3what ungoverned tool adoption costs in practice
An environment without a shadow IT policy accumulates tools, access grants, and integrations that IT cannot review, audit, or revoke cleanly. The practical costs are visible in three places.
Security review gaps. Tools that bypass review may have poor security practices, broad OAuth scopes, or data handling terms that contradict your own policies. Without a review, you have no record that the tool was evaluated, and no owner to contact if the vendor is later breached.
Compliance exposure. GDPR requires a data processing agreement before a processor handles personal data on your behalf. A tool adopted outside the policy process will usually not have one. The legal exposure from this gap is not theoretical.
Offboarding complexity. Tools that entered outside the official process are often unknown to the person running offboarding. When the employee who adopted a tool leaves, the account may stay active indefinitely.
what it looks like when it goes wrong
Three ways this tends to go, each one taken from a real case.
- it happenedSalesloft / Drift, 2025howA chat tool's key into your CRM is stolen from the vendor.what leavessupport tickets, including passwords pasted into themwho ends up with itan extortion group working through hundreds of companies
- it happenedGitHub OAuth tokens, 2022howIntegration keys to your code host are stolen from the integration vendor.what leavesyour private code and the secrets inside itwho ends up with itattackers looking for the next door
- it happenedSisense, 2024howAn analytics vendor is breached and the keys it holds to your systems are copied.what leavesconnections straight into your datawho ends up with itwhoever holds the vendor's keys
4what works
Policies that survive contact with a growing company share a few design choices. The scope is explicit, covering SaaS tools, AI tools, browser extensions, integrations, and personal devices, but the review depth is tiered. A tool that touches no personal data, no company data, and no authentication can clear on a lightweight form; anything with IdP integration, personal-data processing, or AI model access gets the full security review. Teams take the fast track when one exists, and the slow track stays credible because it is reserved for the tools that genuinely warrant it.
Approval attached to roles rather than individuals is what makes the process durable: the intended owner requests, IT and a data owner review, a single named role approves. A process built on roles survives personnel changes; one built on individuals retires with them. A published approved list, kept as a living document showing every cleared tool, the conditions of its approval, and its internal owner, discourages duplicate requests and quietly advertises that the sanctioned path functions.
The offboarding hook closes the loop. Every approved tool carries an owner who is notified when its primary user leaves, which is how adoption and departure stop being separate systems. And because a new policy only governs future adoption, companies that get clean stay clean by pairing the policy with a discovery exercise that clears the accumulated backlog in parallel; the policy then keeps clean what discovery made clean.
on the record
your turn
what you can do about it
this week
Write a one-page path for adopting a new tool: who to tell, what to check.
Make it faster than signing up quietly.
go deeper
if you're not sure where to start
Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.
open the checklist →