Shadow IT policy

what 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.

what 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.

what 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 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.