What are the key leaver process best practices?

What makes a leaver process effective?

A good leaver process is really an access-control change with a people workflow attached. The goal is to make departure actions predictable: remove the person’s ability to log in, end delegated access, transfer ownership, and preserve records before anything becomes an orphaned account, stale credential, or unresolved business dependency.

The practical test is simple: if the person can still act as the organisation after exit, the process is incomplete. That includes human accounts, shared access paths, application permissions, sessions, devices, and any automation or secrets they could still use. The process should start from a reliable leaver trigger and end only when access, ownership, and evidence handling are all closed out.

Leaver handling works best when it is built as a cross-functional control, not a one-team task. HR, identity, endpoint, application, and service owners all need the same event, the same timing expectation, and the same closure criteria. NHIMG’s Joiner-Mover-Leaver (JML) Guide is the most direct reference for structuring that lifecycle consistently.

Which access paths should be removed first?

Start with anything that can still authenticate or authorize action after the person leaves. That usually means SSO sessions, VPN access, privileged roles, API keys, SSH keys, service credentials, and delegated access in SaaS platforms. If the leaver had administrative or developer access, treat revocation and session invalidation as immediate rather than deferred.

Then work through the wider footprint: email forwarding, shared mailbox access, code repositories, CI/CD, cloud consoles, ticketing tools, document systems, and device enrollment. The process should not assume that a primary account is the only access path. Leavers often retain effective access through linked tokens, remembered sessions, role membership, or application-specific entitlements that sit outside the main directory.

Ownership transfer matters as much as revocation. When accounts, secrets, or data have no new owner, they tend to become dormant but still valid, which is exactly how orphaned access persists. A structured lifecycle view, like the one in IAM and IGA Basics, helps teams separate removal of access from reassignment of business responsibility.

How should you handle evidence, devices, and residual access?

Leaver process quality is often judged by what remains after the exit, not by the deprovisioning ticket alone. Return or wipe corporate devices, preserve relevant logs and records, and confirm whether the leaver had access to source code, secrets, regulated data, or other sensitive assets that require review. If the person handled high-trust material, evidence preservation should happen before any cleanup that might destroy useful traces.

Residual access checks are the difference between “account closed” and “environment secured.” Search for stale group membership, stray API credentials, forgotten local accounts, and third-party connections that survive normal offboarding. In many environments, the most important issue is not the original account but the credentials or keys that were issued during employment and never reclaimed. This is especially important for API keys and other long-lived secrets, which should be revoked and rotated rather than merely deprecated on paper.

The best leaver processes also verify that no handoff gap was created. If an application, cloud resource, or shared inbox lost its named owner, the control is not complete. SCIM and Automated Provisioning Guide is useful where offboarding needs to be consistent across multiple SaaS systems, because automation reduces the chance that a deprovisioning step is missed in one platform.

Risk and Threat Considerations

Leaver failures create a straightforward security exposure: access that should have ended remains available long enough to be used, abused, or quietly forgotten. The risk is highest when leavers had elevated privileges, production access, or secrets that can still authenticate outside the main identity system.

Failure mechanism: Revocation is partial, delayed, or disconnected from the systems where the leaver actually had access, so sessions, keys, shared accounts, and delegated permissions remain usable after departure.

Impact: An ex-employee, contractor, or compromised former account can retain the ability to read data, alter systems, exfiltrate code, or impersonate the organisation until the residual access is found and removed.

Practitioner Guidance

What to verify: Treat the leaver workflow as complete only when you can show revocation of active access, removal of privileged and delegated permissions, transfer of ownership, and evidence that any remaining credentials were rotated or invalidated.

Decision rule: If the leaver had access to production, source code, finance, customer data, or secrets, prioritise immediate access closure and blast-radius review before administrative clean-up. If the role was low-trust and tightly controlled, you can sequence non-critical handoffs after the access revocation is confirmed.

Common mistake: Teams often close the human directory account and assume the job is done. In practice, the missed items are usually sessions, application-specific entitlements, shadow accounts, forwarded mail, and credentials that were issued outside the core joiner-mover-leaver flow.

Practitioner takeaway: A strong leaver process is measured by how little effective access remains after departure, not by how quickly one account is disabled.

Related resources from NHI Mgmt Group

• What are the key Process Explorer best practices?
• What are the key Process Monitor best practices?
• What are the key Process Hazard Analysis (PHA) best practices?
• What are the key G7 Hiroshima Process best practices?