Security teams should start by building visibility into the tools employees are adopting, then map known applications against unknown ones. Next, review how users authenticate, what data each app can access, and whether internal policy reflects real employee behaviour. Where possible, add enforcement through alerts, access controls, and employee education so productivity gains do not create unmanaged exposure.
Why Bottom-Up SaaS Adoption Becomes a Security Problem
When employees adopt SaaS tools without procurement review, the issue is not simply shadow IT. The security team loses a clear view of what data is leaving the organisation, which identities are authenticating into those tools, and which integrations may silently extend access beyond the intended business use. The result is a control gap between policy, real work patterns, and actual data exposure. The NIST Cybersecurity Framework 2.0 is relevant here because the problem spans asset visibility, governance, and protection rather than a single technical control.
What makes this especially difficult is that bottom-up adoption usually begins as a productivity shortcut, not a malicious act. Teams may accept consumer-grade sign-up flows, grant broad OAuth permissions, or connect shared workspaces to internal content repositories before anyone has reviewed the risk. In practice, many security teams encounter unmanaged SaaS exposure only after an application has already accumulated sensitive data and normalised access patterns.
How to Bring Unapproved SaaS Under Control Without Blocking Useful Work
A useful response starts with discovery, but discovery alone is not enough. Security teams need to classify applications by business function, data sensitivity, authentication method, and integration depth. That means separating a low-risk collaboration tool from a service that can read mailboxes, files, tickets, or chat archives. The control question is not whether a tool is approved in principle, but whether it is operating with the level of access and oversight appropriate to the data it can reach.
Practical response usually works in layers:
- identify which applications are in use through logs, identity signals, browser telemetry, and user reports;
- distinguish sanctioned applications from unknown or duplicative ones;
- review what data each app can access and whether those permissions are still justified;
- check whether authentication is tied to a managed identity with enforceable offboarding;
- set a policy path for fast review, restricted use, or removal.
This is also where access governance matters. If users can approve third-party integrations with broad scopes, the organisation may have a data exposure problem even when the SaaS product itself is legitimate. The point is to reduce unreviewed trust boundaries, not to force every team into the same narrow toolset. The security team should pair enforcement with a clear intake route so employees are not incentivised to route around control just to get work done.
The guidance breaks down when the organisation cannot see authentication events, cannot inventory connected applications, or has no way to separate personal use from business use.
Common Failure Points When SaaS Use Grows Faster Than Governance
Tighter control often increases administrative overhead, so organisations must balance speed for employees against the need to prevent data from spreading into unmanaged systems.
One common failure is treating all unapproved SaaS as equally risky. A niche note-taking app and a file-sync platform do not present the same exposure. Another is assuming procurement approval equals security approval, when the real issue may be excessive permissions, weak identity assurance, or poor data segregation. Industry consensus is still uneven on how much user-driven adoption should be tolerated, but there is broad agreement that visibility, access review, and permission minimisation are the baseline.
Another edge case appears when a SaaS tool is introduced through a department, then becomes embedded across the business. At that point the problem is not just an exception, it is a de facto standard that may need formal assessment, contractual review, and stronger monitoring. Where employee productivity genuinely depends on the tool, the right response is often to contain and govern it rather than attempt an abrupt shutdown. For broader control design, the NIST Cybersecurity Framework 2.0 and the security control catalogue in NIST SP 800-53 Rev. 5 Security and Privacy Controls both provide a useful governance and protection lens.
Risk and Threat Considerations
Bottom-up SaaS adoption creates material exposure because data can move into systems that have not been reviewed for retention, sharing, authentication strength, or third-party access. The risk is not limited to one application. Once a tool is connected to email, files, chat, or customer systems, it can become a durable shadow channel for sensitive information.
Failure mechanism: Users often grant broad permissions during sign-up or through app marketplace integrations, and those permissions can persist long after the original need has passed. If offboarding, logging, or access review is weak, the organisation may lose the ability to see who can reach the data or revoke the path quickly.
Impact: Sensitive data may be exposed beyond policy intent, difficult to recover, or copied into external systems that are outside normal monitoring and incident response. The same pattern can also complicate legal hold, retention, and breach assessment because the organisation no longer has a clean inventory of where data resides.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.1 — Organizational Context | Bottom-up SaaS use is a governance and visibility problem. |
| ID.AM — Asset Management | Teams must discover what applications and data flows exist. | |
| PR.AA — Identity Management, Authentication, and Access Control | Unapproved tools often expand access through weak identity and permission checks. | |
| Recommendation — Define acceptable SaaS use and ownership for review and approval. Inventory SaaS applications and map the data they can access. Enforce managed authentication and least-privilege access for SaaS. | ||
| CIS Controls v8 | 6 — Access Control Management | Unmanaged SaaS creates excessive and unreviewed access paths. |
| 15 — Service Provider Management | Shadow SaaS introduces third-party exposure that needs oversight. | |
| Recommendation — Review and remove unnecessary SaaS access paths and permissions. Assess third-party SaaS risk before allowing business data sharing. | ||
Practitioner Guidance
What to prioritise: Start with the applications that can read, sync, or export corporate content, not the tools that merely duplicate convenience features. Those integrations create the fastest path from benign adoption to material exposure.
What to verify: Confirm whether each tool is tied to a managed identity, whether permission scopes match actual use, and whether the organisation can revoke access without relying on the end user. If any of those answers are no, treat the tool as a governance gap rather than a simple procurement miss.
Practitioner takeaway: The effective response is not to outlaw unsanctioned SaaS by default, but to make unreviewed data access visible, revocable, and hard to normalise.
Related resources from NHI Mgmt Group
- How should security teams respond when a trusted SaaS integration is found to be abusing OAuth access to CRM data?
- How should security teams govern browser extensions that access SaaS data?
- How should security teams respond to a data breach when access paths are unclear?
- How should teams respond when agentic access and data security look like separate programmes?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
