Employee Offboarding Checklist Template
An audit of six departures found eleven accounts working after the last day. Every one was a local or shared credential.
Free download · No account needed
This pack builds one access matrix per role from your identity provider's application inventory, then classifies every row by how revocation actually happens: dies with the SSO identity, needs individual revocation, or is a shared credential somebody has to rotate. The provisioning checklist and the revocation log are both views of that matrix, so they cannot drift apart. You also get a provisioning standard by role and an offboarding procedure with confirmation built in. The day-one subset appears on the onboarding checklist. Rows get reassigned, not revoked, on a transfer: see the internal transfer pack.
A downloadable checklist cannot do this, because the list only exists in your identity provider and your card statement. In the worked example the role touched 41 applications and the checklist in use had 12 rows. The real finding was sharper: 23 of the 41 die when the identity is disabled, so only 18 need a human, and the old checklist covered 3 of those 18 while listing 9 that needed nothing at all. Adding rows would not have fixed it.
Written for people ops and IT leads who share offboarding and have never compared their checklist to the inventory. The second mechanism is confirmation: an account can be disabled and still work, because sessions survive and tokens issued to a personal phone keep refreshing. So revoked and confirmed are separate states with a name against the second. When somebody leaves, what they know leaves too, which is a role handover. Why they left in the first place is a separate question with its own pattern, answered by the exit interview programme.
What is in the pack
Access Matrix
One row per application, built from the identity provider export plus twelve months of software expense lines. The expense trail is what catches the tools that were never federated.
Revocation path classification
Every row marked SSO-federated, local credential or shared credential, so the count that matters is local plus shared rather than the row total.
Provisioning Checklist
A dated view of the matrix filtered to what the role needs first, with granted and confirmed as separate states and a named confirmer on each.
Revocation Log
Only the rows that need a human, each with an owner and a confirmation method. Federated applications get no line, because one identity disable resolves all of them.
Shared credential decisions
Four options with an owner and a dated window, because a rotation written as a task means telling four other people their saved login stopped working today.
Past-departure audit
Run before you use the space forwards. It takes about an hour and tells you how many accounts are live right now, and which category they sit in.
Provisioning Standard and Offboarding Procedure
By role, including the access the role explicitly does not get, so the next person asked for it knows the absence was a decision.
How it works
- 1
Send the inventory
The identity provider or SSO application export, plus software line items from expenses or a card statement for the last twelve months.
- 2
Get every row classified
Federated, local or shared, with unknowns counted separately and treated as local, because assuming federated is what leaves accounts live.
- 3
Audit the last six departures
Check every non-federated row against the people who already left. This produces the number that ends the argument about whether the work is worth doing.
- 4
Decide the shared rows
Rotate now, rotate by a named date, issue per-person access then retire, or accept and document. A decision with an owner, not a task.
Frequently asked questions
Why not just ask what applications the role uses?
Because the answer is the list of things somebody remembers provisioning, which is the artifact this pack replaces. The rows that produce exposure are the ones nobody would name: the reporting replica, the wiki that predates the current wiki, and the tool one person expensed at 39 a month that was never in the inventory.
Does disabling the SSO account not handle everything?
It handled 23 of 41 rows in the worked example, which is most of them and not all. The other 18 hold their own credentials or are shared logins, and they keep working indefinitely. Every one of the eleven accounts found live in the past-departure audit was in that group. None was federated.
Why is confirmation a separate state from revoked?
Because an account can be disabled and still work. Live browser sessions survive, group changes queue and get cached, and an OAuth grant on a personal phone keeps refreshing until the grant itself is revoked. All of those look correct from the admin console, so confirmation means somebody attempted access and it failed.
Why do shared credentials never get rotated?
Because the task is mis-specified. Rotating one means telling four other people their saved login stopped working, today, while one of them is at a customer site. So each shared row gets a dated decision made in advance instead, and the last-day procedure executes a decision rather than making one under pressure.
Is this a security project?
No, and keeping it small is why it gets finished. One pass over the inventory, two checklists, and a confirmation record. Standard account management practice covers service accounts alongside user accounts (CIS Control 5), and anything structural gets written down and handed to whoever owns identity.
When should access be cut relative to telling someone?
This pack does not answer that, deliberately. The timing depends on the circumstances of a specific departure and belongs to the manager, people ops and legal. The revocation log is written so it can be executed at whatever moment is chosen, and it carries no default.
What does the permanent fix look like?
Federating the local-credential rows. Nine of thirteen could be in the worked example, and every row moved stops needing a human at every future departure, which is the only change here that reduces work rather than organising it. The account management control family in NIST SP 800-53 is the reference. Departure paperwork sits in the compliance pack.
Find out how many accounts are live right now
Send the identity provider export and twelve months of software expense lines. The first thing back is the split by revocation path, and how many of the rows that need a human are on the checklist you use today.
Build my access matrix