How should organisations govern SaaS sprawl across business units?

Why This Matters for Security Teams

saas sprawl is not just a procurement problem. It creates a fragmented identity surface where business units adopt tools faster than central teams can classify, control, or retire them. When ownership is unclear, dormant apps keep OAuth grants, API keys, and admin roles alive long after the original use case has changed. That is why governance needs to start with application accountability and lifecycle control, not periodic cleanup alone. The NIST Cybersecurity Framework 2.0 reinforces this kind of enterprise-wide governance discipline, while NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs ties that discipline to identity lifecycle realities across systems and services. For a wider risk lens, Top 10 NHI Issues shows how visibility gaps and credential drift compound over time. In practice, many security teams encounter the real exposure only after an app owner leaves, a department renews a subscription silently, or a compromised integration survives long past approval.

How It Works in Practice

Effective SaaS governance works best when organisations treat applications as managed identity-bearing assets, not just software subscriptions. That means each app should have a named business owner, a technical owner, an expiry or review date, and a recorded link to the systems and identities it can reach. Discovery from CASB, SSO logs, finance records, browser telemetry, and procurement data should be reconciled against the approved inventory on a fixed cadence. The goal is to close the gap between what is in use and what is sanctioned, then feed exceptions into remediation and offboarding workflows.

Practically, that requires three control layers:

• Ownership: assign accountability for each app, including renewal, risk acceptance, and decommissioning.
• Access: review who can administer the app, which connectors it uses, and what secrets or tokens it stores.
• Lifecycle: connect onboarding, change, and offboarding to joiner-mover-leaver processes so access changes when people and teams change.

For implementation standards, current guidance suggests using the NIST Cybersecurity Framework 2.0 as the governance backbone, then mapping discovery, inventory, and remediation to business ownership. If the organisation allows apps to spawn service accounts or third-party tokens, the app record should also reference the relevant NHI controls and any associated secrets manager entries. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because auditors will expect evidence that applications, identities, and exceptions are reviewed together, not as separate lists. These controls tend to break down in federated enterprises where each business unit can approve tools independently and central IT lacks authoritative telemetry from the SaaS stack.

Common Variations and Edge Cases

Tighter SaaS control often increases operational overhead, so organisations have to balance speed of adoption against the cost of review and remediation. That tradeoff is real in mergers, incubator teams, and regulated subsidiaries where local autonomy is part of the operating model. Best practice is evolving, but there is no universal standard for whether every app must be centrally approved before use or whether lower-risk tools can sit in a delegated catalog with compensating controls.

Two edge cases deserve special treatment. First, shadow IT that becomes mission-critical should be reclassified quickly, because a tolerated pilot can turn into an undocumented production dependency. Second, “single-purpose” integrations often carry disproportionate risk when they have broad API scopes or long-lived credentials; an app with one business purpose can still expose many systems. NHI Management Group’s Snowflake breach and BeyondTrust API key breach illustrate how exposed credentials and weak lifecycle discipline can amplify access far beyond the original app boundary. Organisations should also watch for SaaS tools purchased by one department but deployed as enterprise utilities, because those are the easiest to miss during renewals and the hardest to unwind after a control failure.

Related resources from NHI Mgmt Group

• How should organisations govern reusable digital identity across multiple services?
• How should teams govern AI systems that can combine data across business apps?
• How should security teams make NHI best practices usable across the business?
• How should security teams govern access across SaaS sprawl?