Deprovisioning is the leaver half of identity lifecycle management: the work of stripping every access a person held the moment their employment or contract ends. It is the control most often skipped under time pressure, and the one auditors and attackers both go looking for first. The gap between a termination decision and the last revoked token is where orphaned accounts, unreviewed access, and quiet data loss live.
Deprovisioning is the reverse of onboarding. Where provisioning grants an identity the accounts, group memberships, licenses, and credentials a role needs, deprovisioning removes them when the role ends. It covers voluntary resignations, terminations, contract expiry, role changes that drop an entitlement, and the return of a vendor or contractor. The scope is not one account. A single employee typically holds a primary identity in a directory, dozens of downstream SaaS seats provisioned from it, at least one privileged or shared credential, personal access tokens, SSH keys, and membership in source control and CI systems. Deprovisioning is done only when every one of those is closed, disabled, or rotated, not when the HR record flips to terminated.
Nobody gets an error when an account is left active. The most common failure is the orphaned account: a login that still works after its owner is gone because no system was told to close it. Orphans appear when SaaS tools were signed up for outside single sign-on, when a contractor was never in the directory to begin with, when offboarding ran as a manual checklist and one line was missed, and when a shared or service credential the leaver knew was never rotated. Each orphan is standing access with no owner, no review, and no one who will notice it being used.
An orphaned account is standing access with no owner and no review. It is the door an attacker walks through weeks after the person is gone, and the finding an auditor opens with.
This is precisely the risk that access-removal controls exist to close: SOC 2 CC6.2 and CC6.3, which require access to be removed when it is no longer authorized, including on termination, ISO 27001:2022 A.5.18, which requires access rights to be removed in line with an access-control policy, and SOX IT general controls over access, which auditors test directly.
Revoking the directory account is the visible ten percent. The rest hides in systems that were provisioned from the identity but do not die with it:
Access that authenticates as something other than the person, a token, a key, a shared secret, is the category most often missed, because disabling the human account does nothing to it.
A manual offboarding checklist reacts to a human remembering to run it. That coupling is the weak point. The termination decision lives in an HR system or a manager's head, and every hour between that decision and the last revoked credential is exposure. Automated deprovisioning removes the human relay: the termination event in the system of record, an HR status change, a ticket, or a directory flag, becomes the trigger, and revocation fans out to every connected system without waiting for a person. The distinction that matters is not speed alone, it is that automation reacts to the event rather than to someone's memory of the event. A checklist that is thorough but runs a day late still leaves a day of standing access.
Automate joiner-mover-leaver| Manual deprovisioning | Automated deprovisioning | |
|---|---|---|
| Trigger | A person remembering to start a checklist after being told someone left | The termination event in the system of record fires revocation directly |
| Speed | Hours to days, bounded by working hours and human availability | Minutes, running the moment the event lands, day or night |
| Coverage | Only the systems on the checklist; anything outside SSO or off-list is missed | Every connected system in one fan-out; reconciliation flags what is not connected |
| Evidence | After-the-fact screenshots or ticked boxes; proves intent, not outcome | Append-only, timestamped, sealed record captured as each revocation runs |
| Failure mode | Silent. A skipped line leaves an orphaned account no one notices | Surfaced. A failed revocation is logged and retried, not lost |
An auditor, an incident responder, or a customer security review will ask for evidence: who was deprovisioned, when, which systems were touched, and confirmation that each revocation succeeded. If that evidence is a screenshot taken after the fact or a checkbox someone ticked, it proves intent, not outcome. Tamper-evident evidence means a record of each revocation, captured as it happens, that cannot be silently edited later: an append-only log, timestamps, the specific accounts and tokens closed, and a verifiable seal over the record. This is the difference between claiming access was removed and being able to demonstrate the posture. It is also what turns deprovisioning from an operational task into an audit-ready control under SOX IT general controls and ISO 27001:2022 A.5.18.
Turn access review into evidenceThe interval from the termination event to the last credential closed. This is the exposure window.
The percentage of a leaver's access the process actually reaches. Below 100% names how many orphans you create.
Active accounts with no valid owner, surfaced by reconciling the directory against each downstream system.
How often a triggered revocation completes versus fails silently, and the share of events with a sealed record.
Make the leaving event close the access, automatically.
Try the JML tool