What should organisations do when employees keep using unapproved SaaS tools?

Why employees keep reaching for unapproved SaaS, and why that becomes a control problem

Unapproved SaaS use is usually a signal that employees are trying to solve a real workflow gap, not simply evade policy. The security issue is that each unsanctioned app can introduce unmanaged data sharing, weak vendor assurance, inconsistent access control, and poor exit visibility. A policy-only response often pushes the behaviour underground, where risk is harder to observe and govern. For a broader control lens, organisations can map the issue to the control families in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where inventory, access, and monitoring discipline are weak. In practice, many security teams discover shadow SaaS only after a business unit has already embedded it into daily work.

How to reduce shadow SaaS without breaking day-to-day work

The practical answer is to treat unapproved SaaS as both a governance and usability issue. Start by identifying which tools are being adopted, which teams are using them, and what job they are doing better than the approved stack. If the approved estate does not meet the need, organisations should fix the capability gap before expecting compliance to improve. Where the app is genuinely risky, policy should be paired with technical controls such as SaaS discovery, conditional access, DNS or proxy enforcement, and procurement review so usage can be seen and managed.

Good practice is to separate low-risk convenience tools from high-risk data-handling tools. A lightweight note-taking app may need a different response from an unsanctioned file-sharing platform that processes customer information or credentials. The same is true for collaboration tools that create external sharing by default. Organisations should also make approval faster than workarounds: if the sanctioned route takes too long, employees will keep choosing the shortest path. A well-run approval process reduces friction while still preserving evidence, vendor review, and access oversight.

• Identify the business need behind the tool before deciding whether to block it.
• Publish approved alternatives that match the actual use case, not just the category.
• Use discovery data to find repeat offenders, redundant subscriptions, and data flows.
• Apply stronger controls where the tool touches sensitive data, external sharing, or account federation.

This approach breaks down when teams treat discovery as a one-time clean-up rather than an ongoing governance process.

When exceptions, edge cases, and enforcement choices need different handling

Tighter SaaS control often improves visibility and data protection, but it also increases operational overhead, so organisations have to balance convenience against assurance. The right response depends on the risk the tool creates and the job it performs. A low-impact productivity app used by a small team may justify a time-bound exception, while a tool that stores regulated data or supports customer workflows usually needs a much stricter decision.

One common edge case is “bring your own workflow” usage, where employees connect unapproved SaaS to approved identity or file systems. That can make the tool look legitimate while still bypassing procurement, vendor review, and data-handling rules. Another edge case is temporary use during a project or trial period, which often becomes permanent because nobody revisits the approval decision. Organisations should distinguish between tolerated convenience and formally accepted risk, because those are not the same governance state.

Practitioner takeaway: The strongest programmes do not start with blocking; they start with understanding why the shadow tool won, then decide whether to replace, approve, restrict, or retire it.

Risk and Threat Considerations

Unapproved SaaS creates material exposure because organisations usually lack full visibility into where business data, credentials, and shared content are being stored or forwarded. The risk is not limited to policy breach; it includes data leakage, unmanaged retention, weak vendor controls, and inconsistent offboarding when staff leave or projects end.

Failure mechanism: Shadow adoption bypasses procurement, security review, and access governance, so sensitive information can move into a service with unknown controls, weak auditability, or permissive external sharing. If the app is later connected to approved identity or storage systems, the organisation may inherit hidden trust relationships that are hard to unwind.

Impact: The likely consequences are loss of data visibility, weak incident response, duplicated subscriptions, and greater blast radius if an account, integration, or vendor account is compromised.

Practitioner Guidance

What to prioritise: Separate the business problem from the tool problem. If employees are using unapproved SaaS because the sanctioned option is poor or slow, fix that first or enforcement will be brittle.

What to verify: Confirm where the tool stores data, whether it supports external sharing, how access is revoked, and whether the business can export or delete content on demand. Those points determine whether the app is merely inconvenient or genuinely unsafe.

What good looks like: Security, procurement, and business owners can see which tools are in use, which are approved, and which are under review. Exceptions should be time-bound and tied to a named owner, not left as informal tolerance.

Common mistake: Treating all unsanctioned SaaS as equal. The response should scale with the sensitivity of the data, the strength of the vendor controls, and the degree of account integration.

Practitioner takeaway: Organisations usually get better control by making the approved path easier and the risky path more visible, rather than by trying to police every new app after the fact.

Related resources from NHI Mgmt Group

• Why do employees keep using unapproved AI tools even when policy forbids them?
• Why do employees keep using shadow IT even when organisations prefer approved tools?
• How should organisations govern AI usage when employees use unapproved tools?
• What should IAM teams do when employees keep using unsanctioned AI tools?