Who should own approval and offboarding decisions in a mature IT service model?

Why This Matters for Security Teams

Approval and offboarding are not clerical steps. They are the control points that determine whether access was justified at creation and reliably removed when the need ends. When ownership is vague, approvals become rubber stamps and offboarding becomes a best-effort task hidden between teams. NHI Management Group’s NHI Lifecycle Management Guide treats lifecycle discipline as a core governance requirement, not an afterthought, and that framing matches how incidents usually unfold.

The practical risk is that the business knows the request, the application team knows the technical blast radius, and identity or security knows the policy. If any one of those groups owns the decision alone, the model breaks down: business may approve too broadly, app teams may lack governance context, and identity teams may not understand operational dependencies. Current guidance from the NIST Cybersecurity Framework 2.0 supports shared accountability across identity, asset, and governance functions rather than single-owner approval chains. In practice, many security teams encounter persistent access and delayed revocation only after an audit, a breach review, or a production outage has already exposed the gap.

How It Works in Practice

A mature IT service model usually assigns different decision rights to different parties. The business owner confirms that the access request supports a real operational need. The application owner validates whether the access is technically safe and whether the target system can tolerate it. The identity or security function enforces policy, ensures evidence exists, and prevents exceptions from becoming the default. That split is cleaner than a single approver because it matches how risk is distributed across the service lifecycle.

For approvals, the best practice is evolving toward three checks before access is granted:

• business justification, including purpose and duration
• technical validation of scope, privilege level, and system impact
• policy review for segregation of duties, JIT access, and exception handling

For offboarding, the same shared model should trigger revocation, not just a ticket closure. The owner of the business need confirms when the work is complete, the application owner confirms what must be removed, and identity or security verifies the credential or entitlement is actually disabled. That is especially important for NHIs because lifecycle failures are common; NHI Management Group’s Ultimate Guide to NHIs notes that only a small share of organisations have formal offboarding and revocation processes. The governance lesson is simple: ownership must cover both the request and the removal path, and the evidence trail should show who approved, who implemented, and who confirmed closure. These controls tend to break down in highly federated enterprises where shared services, delegated administration, and manual exception handling blur accountability.

Common Variations and Edge Cases

Tighter approval and offboarding governance often increases operational overhead, requiring organisations to balance control quality against service speed. That tradeoff becomes visible in environments with emergency access, outsourced operations, or cross-border support teams. In those cases, a rigid single approver model can stall legitimate work, while an overly broad shared model can dilute accountability.

There is no universal standard for this yet, but current guidance suggests using time-bound approvals, delegated approver matrices, and explicit offboarding triggers for each service class. For low-risk internal apps, a business owner and application owner may be enough if identity enforces the policy. For privileged or production access, identity or security should have veto authority and require stronger evidence. For NHIs, the same logic applies to service account, API keys, and automation identities, especially where Top 10 NHI Issues highlights recurring lifecycle and visibility failures. The important edge case is exception handling: emergency access should be logged, time-limited, and reviewed after the fact, otherwise temporary approval paths become permanent risk. Organisations that rely on one approver for both authorisation and revocation usually discover too late that no one truly owns the cleanup.

Related resources from NHI Mgmt Group

• Who should own access decisions when service management and IAM are connected?
• Who should own emergency access decisions in a policy-driven model?
• Who should own access decisions in a business-driven IGA model?
• Who should own OAuth app and service account cleanup?