How does the Leaver Process work?

What the Leaver Process actually does

The leaver process is the offboarding workflow that removes access, recovers organisational assets, and transfers any active ownership before a departure becomes an operational gap. In practice, it combines identity actions, asset recovery, mailbox and file handling, and handover tasks so the organisation does not leave behind dormant access or unmanaged work.

It is usually triggered by an HR event or manager notification, then carried out across the systems where the person had access. The important point is not the label of the process, but that the organisation can identify what must be disabled, what must be preserved, and what must be reassigned without delay.

For teams building this as a repeatable control, the best starting point is a clear joiner-mover-leaver model that defines who owns the trigger, who approves exceptions, and which systems must be included. NHIMG’s Joiner-Mover-Leaver (JML) Guide covers the broader lifecycle pattern, while IAM and IGA Basics explains how provisioning, entitlement review, and revocation fit together.

What gets removed, revoked, or handed over

A sound leaver workflow usually disables or blocks accounts first, then revokes tokens, keys, and other authentication material that could still be used after departure. It also handles mailbox access, shared files, device returns, and any service ownership that would otherwise remain tied to the departed person.

The sequence matters because some access paths are easier to overlook than primary login accounts. Tokens, API keys, signing keys, delegated mailbox access, and connected application credentials can continue to function even when the main user account has been disabled, so the offboarding scope has to cover all active access paths, not just interactive login.

Where organisations automate this well, they connect HR status changes to deprovisioning and entitlement cleanup rather than relying on manual reminders. A practical reference point is SCIM and Automated Provisioning Guide, which focuses on automated provisioning and deprovisioning flows and the failure modes that appear when integrations are incomplete.

Why timing and ownership transfer matter

The leaver process is not finished when access is disabled. Ownership must move for the assets, systems, and work products the person controlled, otherwise teams inherit invisible dependency risk. That includes documents, repositories, cloud resources, admin roles, approval responsibilities, and any service or workflow the person was the named owner of.

Mailbox and file handling also need a deliberate policy. Organisations typically decide what must be preserved for legal, operational, or continuity reasons and what should be reassigned or deleted according to retention rules. If that decision is delayed, the business can end up with stranded data, broken workflows, or permissions that are left open because nobody wants to touch them.

The same lifecycle discipline applies to non-human access that the departing person may have created or controlled. NHI Lifecycle Management Guide and Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs both reinforce the same operational idea, when access exists beyond the person, offboarding has to account for what that person provisioned, not only what they personally used.

Risk and Threat Considerations

Leaver failure creates a straightforward but serious exposure: access that should have ended remains usable, and the organisation may not notice until after data has moved, credentials have been abused, or an account has been reused. The most common weakness is partial offboarding, where one system is closed but related credentials, shared tools, or delegated access are left active.

Failure mechanism: Offboarding is fragmented across HR, IT, security, and business owners, so revocation happens late or incompletely. If a departing user retains valid credentials, tokens, keys, or inherited access, the organisation has an avoidable post-departure attack window.

Impact: The result can include unauthorized access, data exposure, misuse of privileged functions, and loss of accountability for actions taken after departure. In high-trust environments, unrevoked signing keys or service credentials can also create broader integrity risk, not just account risk.

Practitioner Guidance

What to verify: Treat the leaver process as complete only when the last active access path is accounted for, not when one account has been disabled. Verify mailbox access, file access, shared group membership, privileged roles, API or signing credentials, and ownership transfer for any system the person administered.

Decision rule: If the person had access to production systems, customer data, source code, finance systems, or signing material, prioritise rapid revocation and blast-radius review before waiting for a full administrative cleanup. If the role is low risk, the same process still applies, but the evidence threshold can be lighter.

What good looks like: HR exit notification triggers a defined workflow, the access list is derived from authoritative sources, exceptions are recorded, and completion is confirmed quickly after departure. The organisation should be able to show who approved, what was removed, what was transferred, and what remains under watch.

Practitioner takeaway: A good leaver process is less about paperwork and more about closing every usable access path fast enough that departure does not become an exploitation opportunity.

Related resources from NHI Mgmt Group

• What breaks when joiner-mover-leaver flows are not tied to real work changes?
• What breaks when deprovisioning is not tied to the joiner-mover-leaver process?
• Why do access reviews matter if joiner-mover-leaver workflows already work?
• How should compliance teams build KYB so UBO checks and AML screening work as one process?