Organisations can allow unapproved SaaS use when they have enough visibility to understand the data involved, the business purpose, and the control gaps. The decision should depend on whether the platform handles sensitive information, whether existing controls are adequate, and whether IT can still manage joiner and leaver access cleanly. Approval should follow risk, not habit.
How to decide whether “unapproved” SaaS is actually acceptable
The right question is not whether the app sits on a formal approved list, but whether the organisation can explain and control its use. If the business need is real, the data is understood, and the access path can be governed, limited, and reviewed, a temporary or scoped exception may be reasonable. If any of those are unclear, the app is a risk, not a convenience.
That decision should be anchored in data sensitivity, business purpose, and the control gap left by bypassing standard procurement or security review. A low-risk collaboration tool used for non-sensitive content is very different from a platform that handles customer records, source code, financial data, or regulated information.
Unapproved use becomes more defensible when IT and security can still enforce visibility into identity and access, understand who can sign in, and remove access cleanly when people change roles or leave. That same logic is why platform-specific breaches such as Salesloft OAuth token breach and BeyondTrust API key breach matter here: the exposure is rarely the app itself, but the credential path that makes the app usable.
What controls turn a tolerated exception into a manageable one
When organisations allow unapproved SaaS, they need compensating controls that preserve oversight. At minimum, the app should have a named business owner, a defined data classification boundary, a clear account lifecycle, and a documented exit plan if the service becomes too risky or too embedded. Without those basics, the exception quickly turns into shadow IT with no review point.
Practical control design should focus on three questions: can the organisation see what data is entering the platform, can it revoke access when needed, and can it keep the app from becoming a hidden integration hub? SaaS often accumulates third-party connectors, OAuth grants, and imported data faster than teams notice, so the approval standard should include integration risk, not just the user interface.
Where unapproved SaaS is allowed, it is sensible to require a tighter review for apps that store secrets, tokens, certificates, or other authentication material. Incidents such as the Dropbox Sign breach and Sisense breach show how one compromised service account or one exposed token can create a much wider access problem than the original application boundary suggests.
For data-governance discipline, teams can align exception handling with NIST Privacy Framework concepts and with baseline security control expectations in NIST SP 800-53 Rev. 5 Security and Privacy Controls. For apps that primarily raise credential, token, and access-path concerns, the OWASP Non-Human Identity Top 10 is a useful reference point for the failure modes to watch.
Risk and Threat Considerations
Unapproved SaaS is most dangerous when it creates a blind spot around data movement and access sprawl. The organisation may think it is allowing a small productivity tool, but the real exposure is often uncontrolled sharing, stale access, copied data, or third-party authentication paths that no one reviews.
Failure mechanism: Users adopt the app first, then connect it to corporate data or delegate access through tokens and integrations. If security teams cannot see those grants, they cannot reliably assess privilege, revoke access on departure, or detect when the service becomes an ungoverned data sink.
Impact: Sensitive information can leave approved controls without leaving the business process. Over time, the same exception can become an untracked dependency, a compliance problem, or a breach path if the service, its tenant, or one of its connected accounts is compromised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | Exception decisions should follow business risk and control gaps. |
| Recommendation — Use GV.RM to decide when SaaS exceptions are acceptable based on risk appetite and control coverage. | ||
| CIS Controls v8 | 6 — Access Control Management | Unapproved SaaS must still support user access governance and revocation. |
| Recommendation — Apply Control 6 to manage and revoke access paths for tolerated SaaS exceptions. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | SaaS access depends on trustworthy sign-in and identity assurance. |
| AAL — Authenticator Assurance Level | Exception handling depends on the strength of the sign-in method used. | |
| FAL — Federation Assurance Level | SaaS often relies on federated access that must be governed and revocable. | |
| Recommendation — Set assurance expectations for SaaS sign-in based on the sensitivity of the data and access involved. Require stronger authenticators when unapproved SaaS can reach sensitive information. Validate federation settings before allowing unapproved SaaS to connect to corporate identity. | ||
Practitioner Guidance
Decision rule: Allow the exception only when the app’s data class, user population, and access model are explicitly understood, and when the organisation can remove access without manual detective work. If any of those three are unknown, treat the app as provisional and require review before broad use.
What to verify: Confirm who owns the app, what data types it will process, whether it supports offboarding, and whether its sign-in and sharing model can be monitored centrally. If the app cannot support clean leaver handling, it should not be treated as a low-friction productivity exception.
Common mistake: Approving the tool because the business team is already using it. Adoption is not a control, and popularity is not a substitute for visibility, data classification, or revocation capability.
Practitioner takeaway: The approval decision should be based on whether the organisation can still govern the app after users start using it, not on whether the app feels harmless at the moment of request.
Related resources from NHI Mgmt Group
- How can organisations reduce data loss when employees use AI apps and shadow SaaS in the browser?
- How should security teams discover shadow SaaS and GenAI apps that employees use outside approved channels?
- What breaks when organisations only track approved SaaS apps and ignore shadow AI usage?
- How should security teams manage SaaS access when employees use both managed and unmanaged apps?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
