Who should decide whether identities are deactivated or deleted after offboarding?

The decision should be owned jointly by IAM, governance, legal, and audit stakeholders under a documented policy. The right choice depends on retention obligations, investigation needs, and whether the organisation must preserve identity evidence after access is removed. Clear ownership prevents inconsistent handling across applications and reduces compliance risk.

Why This Matters for Security Teams

offboarding is not just an access-removal task. It is a governance decision about whether an identity record should be preserved for auditability, legal hold, incident response, or deleted to reduce residual risk. If the wrong owner makes that call, one team may destroy evidence while another assumes records still exist. Current guidance suggests the decision must be explicit, documented, and tied to retention and investigation requirements.

That matters because identity state is often inconsistent across IAM, HR, applications, and logs. NHI Management Group’s NHI Lifecycle Management Guide treats lifecycle control as a security control, not an administrative afterthought. NIST SP 800-53 Rev. 5 also makes record retention and access enforcement separate control concerns, which means ownership should not default to a single operational team by habit.

In practice, many security teams encounter missing identity evidence only after an investigation, legal inquiry, or audit has already started, rather than through intentional offboarding design.

How It Works in Practice

The practical model is joint ownership with a clear decision path. IAM or identity engineering should execute the technical action, but governance, legal, privacy, and audit should define the policy that determines whether the identity is deactivated, retained in a dormant state, or deleted. The policy should state what data is preserved, for how long, who can approve exceptions, and which systems are authoritative for that decision.

For human accounts, deactivation is usually the first step because it preserves evidence while stopping access. Deletion is typically reserved for cases where retention obligations have expired and no business, legal, or investigative need remains. For NHIs, the same principle applies, but lifecycle handling is often tighter because secrets and tokens can remain valid after an account is visually “offboarded.” NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs notes that lifecycle failures are a common source of exposure. That is why deactivation, revocation, rotation, and deletion are separate actions, not synonyms.

A strong workflow usually includes:

• A documented offboarding policy with retention and deletion criteria.
• A named decision authority, usually a governance committee or control owner.
• Mandatory legal or audit review when records may be subject to hold.
• Technical execution by IAM to deactivate access and revoke secrets.
• Verification that downstream systems, replicas, and logs reflect the final state.

NIST SP 800-53 Rev. 5 reinforces this separation by requiring organisations to control access and manage records according to policy, rather than by ad hoc administrative judgment. These controls tend to break down when mergers, litigation holds, or SaaS application sprawl create multiple “source of truth” systems that do not share the same lifecycle state.

Common Variations and Edge Cases

Tighter offboarding controls often increase administrative overhead, requiring organisations to balance fast account closure against evidence preservation and regulatory retention. That tradeoff becomes sharper when legal, privacy, and security teams have different retention horizons or when an identity spans multiple applications.

One common variation is “deactivate now, delete later.” This is usually the safest default because it removes access while preserving records for a defined retention period. Another is immediate deletion for low-risk identities with no legal or audit dependency, but guidance is evolving here and there is no universal standard for the exact deletion window. Organisations should define their own criteria and keep them consistent.

Edge cases include contractor accounts, shared service identities, and NHIs used in CI/CD or integrations. These should not be handled as simple human offboarding cases, because the operational dependency may continue even after the person departs. The Top 10 NHI Issues research highlights how lifecycle failures, overuse, and poor visibility amplify risk when ownership is unclear. For control design, NIST SP 800-53 Rev. 5 helps anchor the decision in retention and access governance rather than convenience.

In practice, the cleanest answer is not “IAM decides” or “legal decides” alone. It is a policy-backed decision model where IAM executes, legal and audit constrain retention, and governance owns exceptions and sign-off.

Related resources from NHI Mgmt Group

• How do organisations decide whether to prioritise certificate automation before the next validity reduction?
• How should security teams decide whether to build authorization logic inside applications or externalize it to a centralized policy layer?
• How do security teams decide whether to prioritise NHI governance, workload identity protection, or identity threat detection first?
• How should organisations evaluate whether PAM is ready for hybrid environments that include both human and machine identities?