Who should be accountable when SaaS access or renewals get out of control?

Why This Matters for Security Teams

When SaaS access and renewals drift without clear ownership, the risk is not just cost leakage. It becomes an identity governance problem, because orphaned subscriptions often map to stale entitlements, lingering tokens, and users who still can act long after the business case has ended. NHIM Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a useful reminder that unmanaged access tends to expand quietly before anyone notices.

Security teams often assume procurement will catch renewals, while procurement assumes the app owner will validate need, and IAM assumes someone else will confirm removal. That handoff failure is where SaaS sprawl becomes operational debt and eventually security exposure. The issue is especially serious when the SaaS platform uses API keys, service accounts, or delegated OAuth grants that persist across renewals. Guidance from the OWASP Non-Human Identity Top 10 aligns with this risk because identity lifecycle failure is usually the real control gap, not the license contract itself. In practice, many security teams encounter the problem only after a renewal passes, access remains active, and no one can prove who was responsible for turning it off.

How It Works in Practice

Accountability works best when it is explicit, documented, and tied to a control point that can approve, renew, or revoke access. The named application owner should own business justification, IAM should enforce the identity and entitlement controls, procurement should manage commercial renewal gates, and security should verify that access is removed when the service is no longer required. That division of labour is consistent with lifecycle governance in the NHI Lifecycle Management Guide, because renewal is not only a finance event. It is an access review event.

In practice, mature organisations create a renewal workflow that requires all of the following:

• A named owner attached to every SaaS application and every non-human credential used by that application.
• A recurring attestation step where the owner confirms active business need before renewal.
• Automatic escalation to IAM or security when the owner does not respond within the review window.
• Revocation steps for dormant apps, unused integrations, and expired approvals.
• Logging that shows who approved continuation, who validated usage, and who removed access.

For SaaS tools that issue tokens or API access, the problem is broader than user licences. The organisation must track secret material, delegated permissions, and service integrations as part of the same lifecycle. NHIMG’s Guide to the Secret Sprawl Challenge is relevant here because renewal sprawl often hides credential sprawl underneath it. Best practice is evolving toward continuous review rather than annual clean-up, especially where business teams can buy or extend software without a central technical gate. These controls tend to break down in decentralised SaaS buying environments because no single team sees the full picture of ownership, usage, and revocation.

Common Variations and Edge Cases

Tighter ownership controls often increase administrative overhead, requiring organisations to balance renewal discipline against the speed that business teams expect. That tradeoff is most visible in fast-moving departments, mergers, and shadow IT environments, where a rigid approval chain can push teams to bypass process entirely. Current guidance suggests that the answer is not to remove accountability, but to make it lightweight enough that people will actually use it.

There is also no universal standard for who owns every edge case. For example, a marketing platform with user seats may sit with a business owner, while a developer tool with OAuth scopes may need shared ownership between engineering and IAM. For agentic or automated SaaS use, the accountability question becomes even more important because an integration can keep renewing access independently of a human user. In those cases, the owner must account for the workload identity, not just the named employee. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful for this distinction, because lifecycle ownership must include both approval and termination. The practical test is simple: if no one can answer who revalidates need and who removes access, the account is already out of control.

Related resources from NHI Mgmt Group

• Who should own SaaS governance when access, licensing, and renewals overlap?
• What frameworks should IAM teams use for SaaS governance and access control?
• Who is accountable when annual privacy audits find access-control gaps?
• What do security teams get wrong about change management and access control?