Who is accountable when a former employee still has access after leaving?

Accountability usually spans HR, IT, and the application owners, but the organisation is accountable if any one of them cannot execute the leaver workflow end to end. The key question is whether there is a single authoritative process for deprovisioning. Without that, responsibility fragments and access leakage becomes predictable.

Why This Matters for Security Teams

A former employee with lingering access is not just an HR offboarding miss. It is an identity lifecycle failure that turns a routine resignation into a standing access problem across email, SaaS, cloud, and privileged systems. The accountability question matters because deprovisioning is often split across ticketing, directory services, and application owners, so no single team sees the full blast radius. That fragmentation is exactly where access leakage persists.

NHIMG research shows how common this exposure is across identity estates: the Ultimate Guide to NHIs reports that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them. While that statistic is about NHIs, the operational lesson applies directly to leavers: if revocation is not authoritative and provable, stale access remains usable long after employment ends.

The OWASP Non-Human Identity Top 10 also highlights why identity sprawl becomes an exposure multiplier when credentials are not centrally governed. In practice, many security teams encounter lingering access only after an alert, audit finding, or misuse report, rather than through intentional leaver control.

How It Works in Practice

Accountability should follow the control point that can actually remove access end to end. In mature environments, HR triggers the event, IAM or directory services execute core deprovisioning, and application owners own any systems that do not inherit centralized identity controls. The organisation remains accountable if the workflow is incomplete, but operational ownership should be explicit so gaps do not hide between teams.

Best practice is to treat leaver handling as a lifecycle control, not a one-time checkbox. That means revoking active sessions, disabling primary accounts, removing group memberships, rotating shared secrets the leaver could know, and validating downstream application access. For privileged access, PAM should shorten exposure further by making elevated access time-bound and traceable. For cloud and DevOps environments, the same principle applies to tokens, keys, certificates, and service integrations that a departing employee may have configured or approved.

• Use a single authoritative source for termination events, usually HR, and automate propagation into IAM and PAM.
• Revoke human access, then check for indirect access through shared mailboxes, delegated admin roles, CI/CD variables, and API tokens.
• Require application owners to attest that their systems honour central deprovisioning or have compensating controls.
• Log each removal step so audits can prove when access was disabled and by whom.

The 52 NHI Breaches Analysis reinforces the broader pattern: identity failures rarely stay isolated to one system. NIST’s guidance on access control and zero trust supports continuous verification and least privilege, which aligns with zero trust architecture and the principle that access should be explicitly revalidated, not assumed to expire on its own. These controls tend to break down when offboarding depends on manual tickets across multiple business units because no system can prove the last mile of revocation.

Common Variations and Edge Cases

Tighter offboarding often increases operational overhead, requiring organisations to balance rapid lockout against business continuity and application complexity. That tradeoff becomes sharper when contractors, alumni, or joint-venture users share systems with employees, because the leaver decision may not map cleanly to a single identity class.

There is no universal standard for this yet, but current guidance suggests the organisation should define a primary owner for termination-triggered access removal and separate secondary owners for exceptions. For example, an employee may leave the company but still retain access to a customer support portal, a hardware lab, or a shared service account if those assets are not tied into the central identity plane. Those cases need explicit compensating controls, not informal exceptions.

Shared credentials are especially dangerous because one person’s departure can expose many accounts. If a leaver had access to secrets in code, CI/CD, or admin consoles, the correct response is not only to disable the user account but to rotate every secret that may have been known or cached. The strongest programs also require evidence that downstream dependencies were reviewed, not just that the directory entry was disabled.

Practitioners should interpret accountability as layered: HR owns the termination signal, IT owns execution, application owners own exceptions, and leadership owns the control design. When any layer is missing, responsibility does not disappear, but the risk becomes predictable and persistent.

Related resources from NHI Mgmt Group

• Who is accountable when a former employee still has SaaS access?
• Who is accountable when a former employee still has access after offboarding?
• Who is accountable when user access remains active after offboarding?
• Who is accountable when cloud access is not revoked after someone leaves?