Offboarding should be shared across security, IT, and HR, because each team holds part of the decision. HR confirms separation timing, IT executes account changes, and security defines the access controls, monitoring, and retention rules. That collaboration matters because some accounts should be disabled, some retained, and some monitored before removal to avoid breaking business processes or leaving access open.
How ownership should work when offboarding decisions are split
Ownership should be explicit and shared by function, not by defaulting the whole process to one team. In offboarding, HR owns the people event, IT owns execution, and security owns the control logic that decides what is disabled, retained, monitored, or escalated. That split keeps the process fast without letting one team make retention decisions it is not qualified to make.
The practical issue is that account deletion is not always the right first move. Some accounts support legal retention, investigations, finance reconciliation, or business continuity, so the owner has to decide which systems are removed immediately and which are preserved under control. The Joiner-Mover-Leaver (JML) Guide and NHI Lifecycle Management Guide both reinforce that offboarding is a lifecycle decision, not a single deletion event.
Good ownership also means a clear decision path for exceptions. A leaver account that still backs a service, a delegated workflow, or a shared integration should not be handled the same way as a normal employee login. Security should define the retention rule, IT should preserve or revoke access as directed, and HR should confirm the separation date so timing is consistent across systems. IAM and IGA Basics is a useful reference point for that shared governance model, because it ties ownership to access review, entitlement control, and segregation of duties.
Why overlap matters in employee offboarding
Overlap matters because offboarding failures usually come from two opposite mistakes: removing access too aggressively, or leaving it in place too long. If nobody owns the retention decision, teams often choose the easiest path, which can break reporting, audit trails, scheduled jobs, or dependent applications. If nobody owns the removal path, stale access and dormant accounts remain open after separation.
That is why the owner needs to understand both the business purpose of the account and the technical consequences of its removal. HR can confirm employment status and timing, but HR should not decide whether a mailbox, token, key, or service-linked account must remain available. Security should define the access policy, and IT should execute the account state change in a way that is consistent across directories, SaaS, and downstream systems. Workforce Identity Security Guide and Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs are useful because they show how offboarding connects to provisioning, deprovisioning, and access governance rather than a single admin action.
Retention also needs rules for evidence and traceability. If an account is kept for a defined period, the team should know why it is retained, who approved that decision, and when it will be reviewed or removed. Without that, retention becomes indefinite “just in case” access, which defeats the purpose of offboarding.
How to assign practical ownership without creating delays
Use one accountable owner for the workflow and separate owners for the decision inputs. In practice, HR supplies the separation trigger, IT performs the technical changes, and security approves the access model, exceptions, and monitoring requirements. That is faster than trying to centralise every decision, because each team acts on the part of the process it can actually verify.
The useful test is whether the team making the decision can answer three questions: should this account be disabled now, retained for a defined reason, or monitored until final removal; what data or business process depends on it; and who signs off on the exception. If those answers are unclear, the process is too loosely owned. NHI Ownership and Accountability Guide and Top 10 NHI Issues both support the broader point that ownership and accountability have to be explicit, especially where accounts are shared, orphaned, or tied to business-critical processes.
Risk and Threat Considerations
Offboarding is a control point because the wrong ownership model can leave access open after separation or remove access before dependent systems are ready. The risk is not just policy failure, it is exposure from stale credentials, missed revocation, and unmanaged retained accounts that can still be used or abused.
Failure mechanism: When HR, IT, and security do not share a clear decision boundary, the organisation either disables too much too early or leaves accounts, tokens, or linked access in place too long. In both cases, the gap usually appears in the exception path, where no one is tracking ownership of retention, reactivation, or final deletion.
Impact: The result can be business interruption, audit findings, or unauthorized access that survives separation. At scale, the same weakness becomes orphaned access across many systems, making cleanup slower and making it harder to prove that offboarding was actually completed.
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 sets 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 | Offboarding requires timely revocation or retention of authenticators and secrets. |
| AC-2 — Account Management | Employee offboarding is fundamentally account disablement, retention, and removal governance. | |
| PS-4 — Personnel Termination | Employee separation timing drives offboarding execution and coordination. | |
| Recommendation — Revoke or rotate authenticators when leavers no longer need access. Define account lifecycle ownership and disable or remove accounts promptly. Coordinate termination triggers with access removal and evidence retention. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Access rights must be removed or adjusted when employment ends. |
| A.5.11 — Return of assets | Offboarding often includes recovery of accounts, credentials, and business assets. | |
| Recommendation — Review and revoke access rights as part of leaver handling. Recover organizational assets and credentials during separation. | ||
Practitioner Guidance
Ownership: Assign one process owner for offboarding, but keep decision ownership split by function. HR owns the employment event, IT owns execution, and security owns the access rule and exception policy.
What to verify: Before trusting the process, verify that every retained account has a documented reason, an approval owner, and a review or removal date. If those fields are missing, the account is not being retained under control.
Decision rule: If the account can still authenticate to a business system or supports a downstream dependency, treat it as a controlled exception rather than a routine deletion. If it no longer has a legitimate purpose, remove it promptly and confirm the revocation actually propagated.
Practitioner takeaway: Offboarding works best when ownership follows the decision, not the ticket. The key judgement is to separate the authority to approve retention from the authority to execute removal, then make both visible.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
