Who is accountable when deprovisioning fails after someone leaves?

Accountability sits with the governance process owner, even if the identity management platform executes the revocation. If offboarding is not triggered, approved, or verified through a governed workflow, the failure is not just technical. It is a lifecycle control gap that should be visible in audit evidence, ownership mapping, and exception reporting.

Why This Matters for Security Teams

deprovisioning failures are rarely just an IAM ticket problem. They expose whether an organisation has a real offboarding control, or only a technical revoke button with no accountable workflow. NIST’s Cybersecurity Framework 2.0 treats identity governance as an operational discipline, not a one-time admin action, and that is the right lens here. The practical risk is straightforward: a former employee, contractor, or service operator may still retain access to apps, secrets, data exports, or admin paths after exit.

NHIMG’s NHI Lifecycle Management Guide shows that lifecycle ownership must cover request, approval, provisioning, monitoring, and revocation as one governed chain. If any handoff is missing, the control fails even when the platform behaves as designed. That distinction matters because audit teams do not accept “the system should have revoked it” as evidence of accountability. The accountable party is the process owner who must ensure the offboarding path is triggered, validated, and recorded.

In practice, many security teams discover offboarding gaps only after access reviews, incident response, or a post-exit activity alert reveals that the revoked identity was still active.

How It Works in Practice

Accountability should be assigned to the governance process owner, while execution can sit with HR, IT, IAM, or platform operators depending on the control design. The important point is that technical revocation is only one step in a larger workflow. A sound offboarding process needs a clear trigger, an approval record, a revocation action, and a verification step that confirms access removal across systems, not just in the directory.

For human identities, that usually means tying employment status changes to identity events. For NHIs, the same logic applies to service accounts, API keys, tokens, certificates, and delegated agent credentials. The Ultimate Guide to Non-Human Identities emphasizes lifecycle control because revocation only works when asset owners know what must be removed, when, and from which systems. NIST CSF 2.0 also reinforces the need for documented ownership, policy enforcement, and evidence generation across identity controls.

• Define a named control owner for offboarding, not just a technical administrator.
• Link exit events to identity and access workflows through a governed trigger.
• Verify revocation across directory, SaaS, cloud, secrets managers, and privileged access tools.
• Record exception handling for delayed, partial, or failed revocation.
• Retain evidence showing who approved, who executed, and who verified the change.

When the workflow is mature, the question becomes less about “who clicked revoke” and more about who owned the end-to-end control outcome. The Top 10 NHI Issues research reflects the same operational reality: lifecycle gaps become security gaps when identity sprawl and weak ownership leave credentials active beyond their intended use. These controls tend to break down when offboarding depends on informal email requests, because no single system has authoritative confirmation that all downstream access has been removed.

Common Variations and Edge Cases

Tighter offboarding control often increases coordination overhead, requiring organisations to balance speed of exit processing against the need for verification and evidence. That tradeoff is real, especially in high-turnover environments, acquisitions, or contractor-heavy teams where identities may exist in multiple directories and shadow systems.

Best practice is evolving for mixed environments, but one principle is stable: if a former worker still has access through an orphaned app, cached token, shared secret, or delegated automation account, the failure belongs to the lifecycle owner even if the IAM platform ran as expected. This is especially true for NHIs because an employee’s departure may also require revoking bot credentials, API keys, CI/CD tokens, and agent permissions that were issued under that person’s sponsorship.

There is no universal standard for this yet, but current guidance suggests separating execution ownership from control accountability. That means service desk, IAM, HR, and application owners can each have tasks, while governance remains with the function that can prove the process worked. NHIMG’s DeepSeek breach and related research illustrate how quickly exposed credentials and lingering access can become exploitation paths once they are left unmanaged. In short, offboarding is not complete when the request closes; it is complete only when access removal is verified everywhere it matters.

Related resources from NHI Mgmt Group

• Who is accountable when automated deprovisioning does not happen after access review?
• Who is accountable when orphaned apps keep running after an employee leaves?
• Who is accountable when offboarding leaves access behind?
• Who is accountable when suspicious activity is discovered after deposits have already been accepted?