Accountability should sit with the identity governance owner, with HR, IT, and security each owning the steps they control. HR initiates the departure, IT executes technical removal, and security verifies that access is actually gone. The control fails when ownership is split but no one is responsible for final revocation evidence.
How identity offboarding should be owned across HR, IT, and security
Identity offboarding should have one accountable owner for the end-to-end process, but not one team doing every task. HR is usually the trigger, IT handles technical removal, and security confirms the access paths are actually closed. That split works only when a single identity governance owner is responsible for coordination, timing, and final evidence that revocation happened.
The practical reason for a single owner is that offboarding spans business process, system change, and control verification. If each team treats its part as “done” independently, the leaver can retain access in the gaps between ticket closure, account disablement, token expiry, and downstream system sync. The accountable owner has to manage the whole sequence, not just one handoff.
In mature operating models, the accountable role is often the identity governance or IAM function, because it can reconcile HR termination data, technical deprovisioning, and access review evidence into one workflow. That role does not replace HR, IT, or security, but it prevents the common failure mode where every team believes another team owns the final revoke-and-verify step. IAM and IGA Basics and Joiner-Mover-Leaver (JML) Guide are useful references for that operating split.
Why split ownership fails if no one owns the final revocation
Offboarding failures usually happen at the boundary between administrative intent and technical reality. HR can mark the employee as departed, IT can disable the primary account, and security can assume the workflow succeeded, yet service accounts, API keys, long-lived tokens, delegated access, shared credentials, or external application grants may remain active. The result is not a process gap in theory, but a live access path in practice.
Once an identity has left, the key control question is not whether a case was opened, but whether every access-bearing artifact tied to that identity was actually revoked or expired. That includes direct accounts, privileged elevation paths, secrets, sessions, and any connected systems that do not inherit revocation instantly. NHI Lifecycle Management Guide and Workforce Identity Security Guide both reinforce the need to treat offboarding as lifecycle control, not just account disablement.
For that reason, final revocation evidence matters as much as the removal action itself. A ticket, termination notice, or deactivation receipt is not enough unless someone verifies the authoritative systems and the downstream dependencies that actually enforce access. The accountable owner should be the role that can force closure when evidence is incomplete.
What good offboarding governance looks like in practice
Good governance makes the ownership model explicit in the workflow. HR owns the source event, IT owns technical execution, and security owns assurance that the access is gone. The identity governance owner owns the handoffs, the exception path, and the final closure criteria. That division is easiest to operate when there is a single workflow, a single record of truth, and a single person or function that can escalate unresolved revocation.
The strongest model is to define a decision rule for ambiguous cases: if the leaver had privileged, shared, federated, API-based, or non-expiring access, the case stays open until technical evidence confirms every material access path is closed. That is also where automation helps most, because it reduces delay, but automation still needs an owner who can spot when a downstream system failed to respond. Joiner-Mover-Leaver (JML) Guide and Identity Security Programme Guide support that operating-model view.
When organisations reach scale, the real question becomes whether the process can prove closure within a defined time window and across all connected systems. If it cannot, then offboarding is not merely slow, it is incomplete. Identity Security Posture Management (ISPM) Guide is relevant here because it treats dormant access, standing access, and unresolved identity findings as measurable posture issues.
Risk and Threat Considerations
Identity offboarding is a high-risk control point because delayed or incomplete revocation can leave an ex-employee, contractor, or compromised account with continuing access to systems, data, or secrets. The threat is not only misuse after departure, but also persistence through overlooked tokens, keys, federated sessions, and shared access paths that survive the primary account disablement.
Failure mechanism: The workflow treats a business departure as the same thing as technical revocation, so residual access remains in downstream applications, privileged paths, or identity-bearing material after HR, IT, or security has declared its part complete.
Impact: An attacker, former insider, or unauthorized user can retain or regain access, move laterally, or use stale credentials and tokens to continue activity without a visible active employee record.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Identity offboarding must revoke and expire credentials, tokens, and keys tied to the leaver. |
| AC-2 — Account Management | Offboarding is fundamentally account disablement, deletion, and status change across systems. | |
| IA-9 — Service Identification and Authentication | Leaver access often persists through service, workload, or non-human credentials that must also be removed. | |
| Recommendation — Revoke and expire authenticators tied to departed identities, then verify downstream removal. Disable, remove, or reassign accounts promptly and confirm the status in each authoritative system. Revoke service and workload authenticators when an identity's access is retired. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Offboarding requires timely removal and review of access rights when personnel leave. |
| Recommendation — Remove access rights on departure and retain evidence of timely revocation. | ||
| CIS Controls v8 | CIS-5 — Account Management | The topic is about ensuring departed users no longer retain access across systems. |
| Recommendation — Enforce timely deprovisioning and validate that departed users no longer authenticate. | ||
Practitioner Guidance
What to prioritise: Assign a single accountable owner for closure, then define exactly what counts as “offboarded” for each access type, including accounts, tokens, secrets, and delegated access. If the process cannot produce revocation evidence, it should not be treated as complete.
What to verify: Verify the termination trigger, technical disablement, downstream propagation, and final confirmation in systems that actually enforce access. The common mistake is assuming the ticket system is the control, when the control is the verified removal of access.
Practitioner takeaway: HR can initiate departure, IT can execute removal, and security can validate the outcome, but one identity governance owner must own the final closure condition or offboarding will fail at the handoff.
Related resources from NHI Mgmt Group
- How should security teams make NHI best practices usable across the business?
- Who is accountable when identity security controls fail across team boundaries?
- Who should own identity lifecycle automation decisions across IT, security, and HR?
- Who is accountable when identity security controls fail across IAM, PAM, and NHI programmes?