Who should own SaaS access review and application retirement?

Why This Matters for Security Teams

SaaS access review and application retirement fail when ownership is ambiguous, because access decisions and application value decisions are not the same control. Business stakeholders know whether the app still supports a process, a contract, or a revenue stream. Technical owners know where dormant users, admin roles, service accounts, API keys, and OAuth tokens still exist. The risk is not theoretical: the Ultimate Guide to NHIs reports that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

That gap matters because SaaS retirement is often treated like a procurement cleanup task, while access review is treated like an IAM checklist item. In practice, those are linked events. If the business does not confirm the app is dead, technical teams keep renewing access. If technical teams do not remove machine credentials, the app can remain reachable long after the business has stopped using it. OWASP’s Non-Human Identity Top 10 is clear that unmanaged machine identities and secrets are a distinct exposure class, not a side effect of user access governance. In practice, many security teams discover the ownership gap only after an audit exception, a billing surprise, or a breach review, rather than through intentional lifecycle management.

How It Works in Practice

The cleanest operating model assigns dual accountability. Business owners approve whether the SaaS application still has a justified purpose, and technical owners execute the retirement and access removal steps. That division is important because each group sees different risk. A business owner can confirm whether the tool still supports operations, but they cannot reliably inventory dormant service accounts, embedded credentials, or integrations. Technical owners can remove those dependencies, but they should not decide unilaterally that a platform is no longer needed.

For access review, the review should cover both human and non-human access. That means users, privileged admins, support accounts, SSO entitlements, OAuth grants, service accounts, and any tokens or certificates tied to the application. The most common failure is stopping at user deprovisioning while leaving machine access in place. NHIMG’s NHI Lifecycle Management Guide emphasizes that lifecycle controls must include discovery, ownership, rotation, revocation, and offboarding, because a retired app can still be live through a forgotten integration.

• Business owner: confirms ongoing need, legal retention needs, and downstream process impact.
• Technical owner: inventories identities, secrets, integrations, and data flows before retirement.
• Security or IAM team: verifies revocation, logs evidence, and closes residual access paths.
• Platform or procurement team: aligns contract cancellation with technical shutdown and data deletion.

Best practice is evolving toward a formal retirement runbook with named approvers and an evidence trail. That runbook should include backup/export decisions, token revocation, certificate expiry checks, webhook disablement, and confirmation that third-party integrations cannot still authenticate. These controls tend to break down when SaaS tools are purchased by departments without central registration because no one team has a complete view of the application footprint.

Common Variations and Edge Cases

Tighter ownership often increases coordination overhead, requiring organisations to balance cleaner control against slower decommissioning. That tradeoff is real, especially in large SaaS estates where one application supports multiple departments or where a platform is embedded in automation workflows. In those cases, current guidance suggests a shared decision model with one accountable business owner and one accountable technical owner, rather than a committee with diffused responsibility.

There is no universal standard for this yet, but the practical rule is simple: if the question is “does the app still matter?”, the business owns the answer; if the question is “what access still exists?”, technical ownership owns the execution. This distinction matters most for apps with third-party OAuth connections, delegated admin roles, or long-lived API tokens, because those dependencies often outlive the original sponsorship. NHIMG breach research, including the 52 NHI Breaches Analysis, shows how often machine access persists after a human-initiated control failure. For high-risk SaaS, teams should require explicit sign-off that service accounts, secrets, and integrations have been removed before the application is marked retired.

Related resources from NHI Mgmt Group

• Who should own SaaS governance when access, licensing, and renewals overlap?
• How should security teams connect SaaS contract review to access governance?
• Why do SaaS environments create so much access review friction?
• Who should own access review decisions in an IAM programme?