Business ownership, IT administration, and security oversight should all be part of the decision path. The business owner should justify need, IT should execute changes, and security should verify that access and audit requirements are met. Shared ownership prevents subscriptions from living outside the identity programme.
Why This Matters for Security Teams
SaaS renewal and revocation look like procurement tasks, but they are actually identity decisions. A subscription often carries API keys, OAuth grants, service accounts, and delegated access that outlive the business need if no one owns the offboarding step. NHIMG notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is why renewals can quietly turn into permanent access. The issue is not the contract date, but the identity residue left behind.
Security teams also need to treat SaaS renewal as part of lifecycle governance, not a standalone finance event. The Ultimate Guide to NHIs frames lifecycle control as central to reducing hidden access, while the OWASP Non-Human Identity Top 10 reinforces that unmanaged credentials are a common failure mode. In practice, many security teams encounter excessive access only after a renewal has already kept stale integrations alive for another term.
How It Works in Practice
The cleanest operating model is shared decision-making with clear handoffs. The business owner confirms whether the SaaS service still supports an active process, product, or team. IT administration validates what technical dependencies exist, including SSO links, SCIM provisioning, integration tokens, and service accounts. Security then reviews whether the SaaS footprint meets policy for access, logging, retention, and revocation.
This split matters because SaaS renewals often contain hidden NHI risk. A tool may be bought by one department, configured by another, and integrated by a third. If ownership is unclear, the renewal can preserve dormant tokens, shadow admins, and orphaned webhooks. Current guidance suggests treating renewal as an access review trigger: confirm who can still authenticate, what secrets remain valid, and whether revocation will break legitimate workflows. The NHI Lifecycle Management Guide is useful here because it ties approval, use, rotation, and retirement into one control chain, rather than letting each team optimise only its own step.
- Business owner: justify continued use and define the system of record for the service.
- IT administrator: execute renewal, deprovisioning, and technical cleanup.
- Security: verify least privilege, logging, revocation evidence, and exception handling.
Practically, renewal should not happen until the owner can prove business value and the administrator can show what identities the platform still holds. Where possible, use inventory from the Guide to the Secret Sprawl Challenge to identify where SaaS secrets and tokens are stored. These controls tend to break down in decentralised environments with no service catalog, because no single team can see all the embedded integrations that renewal keeps alive.
Common Variations and Edge Cases
Tighter renewal governance often increases operational overhead, requiring organisations to balance revocation safety against business continuity. That tradeoff becomes sharper for customer-facing SaaS, shared admin consoles, and tools that are embedded in CI/CD or workflow automation. Best practice is evolving, but there is no universal standard for whether security should veto renewals outright or only require compensating controls.
One common exception is low-risk, commodity SaaS with no internal integrations. In those cases, the business owner may still lead the renewal decision, but security involvement can be lighter if the platform never holds secrets or privileged data. The opposite is true for platforms that issue OAuth tokens, manage API access, or store machine credentials. NHIMG research shows that secret sprawl and weak rotation are persistent problems, which is why revocation should be explicit rather than assumed. For breach context, the Salesloft OAuth token breach shows how a SaaS compromise can turn into downstream access exposure.
Where contract ownership sits in procurement but technical ownership sits in IT, the safest model is a documented triad: business approves need, IT executes change, security verifies closure. That approach is especially important when the SaaS vendor is also a dependency for third-party integrations, because revocation can affect both internal users and external system-to-system trust.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | SaaS renewals often preserve stale non-human identities and unrevoked access. |
| NIST CSF 2.0 | PR.AA-05 | Identity and access lifecycle decisions must include revocation and validation. |
| NIST AI RMF | Governance requires accountable ownership for lifecycle and access decisions. |
Review SaaS renewals for orphaned tokens, service accounts, and excessive NHI permissions before approval.
