Offboarding is one of those controls that everybody believes they do and very few can evidence. The reason is that the visible part, disabling the email account, is quick and obvious, and the invisible part is a long tail of accounts nobody wrote down.
Left alone, that tail accumulates. Most organisations of any age are carrying live credentials belonging to people who left years ago, not through negligence but because nothing ever prompted anyone to look.
Why the identity provider is not the whole answer
If you use Google Workspace or Microsoft 365 with single sign-on, suspending the account does revoke a satisfying number of things at once. It is a genuinely good foundation and it creates a specific blind spot: everything not behind SSO feels covered when it is not.
The accounts outside it tend to be the ones a person signed up for themselves, with a work email address, because they needed something on a Tuesday. A monitoring tool. A design tool. A vendor portal. An AWS IAM user created before SSO was set up. Each one still works after the mailbox is gone, because the password lives in the vendor's system, not yours.
The checklist
Order matters. Do the high-privilege items first, because if a departure is unhappy, the first ten minutes are the ones that count.
Immediately
- Suspend the identity provider account. Suspend rather than delete, so the data survives.
- Revoke active sessions and refresh tokens. Suspension alone does not always kill a session that is already open, and this step is skipped more often than any other.
- Remove from the source control organisation, and check outside collaborator access separately.
- Remove cloud provider access: IAM users, access keys, console logins.
- Remove from the password manager, and note every shared entry they could read. Those are now rotation tasks.
- Remove access to production systems and databases, including any personal credentials that were never issued through a central system.
Same day
- Remove from every service on your vendor list. If you do not have such a list, building one is the task that makes this checklist completable.
- Transfer ownership of documents, repositories, calendars and any automation they owned.
- Rotate any API key or credential they created or could see. This is where having a record of where keys live stops being bureaucracy.
- Update on-call rotations, alert routing and escalation paths. An alert routing to a suspended account is an alert nobody receives.
- Remove building access, if that applies.
Within the week
- Set up mail forwarding or a shared mailbox for their address, so customer email does not bounce.
- Update anywhere their name or address is published: support pages, DNS contact records, the registrar, domain WHOIS, vendor account contacts.
- Check for automation running under their account: scheduled jobs, CI integrations, webhooks, scripts on a server.
- Record what you did and when. A dated note per departure is the evidence that turns a checklist into a control.
The things that are genuinely hard
Personal devices. If work email was on a personal phone, suspending the account usually stops new mail, but cached content may remain. What you can do about this depends on whether you have mobile device management and what your contracts say. Worth knowing your actual position rather than assuming.
Things they built that you did not know about. A script on a server, an integration wired up during a busy month, a scheduled export. These surface weeks later when they break. The mitigation is asking during the handover, which works better than any audit afterwards.
Shared accounts. There is no account to disable, so the only option is rotating the credential. Every shared login multiplies the work of every departure, which is the most persuasive reason to reduce them.
Their own knowledge. No checklist addresses this and it would be dishonest to imply otherwise. Contracts and professional norms carry this one, not technical controls.
The evidence an auditor actually wants
"We revoke access when people leave" is a claim. What converts it into a control is a record, and the record is cheap to produce if you make it part of the process rather than reconstructing it later.
One short entry per departure covers it: who left, their last day, the date each system was revoked, and who did it. Kept in whatever you already use for people records, it answers the question directly instead of requiring a paragraph of reassurance.
The useful side effect is that keeping the record forces the checklist to be completed. A list with no output gets half-done; a list that has to be filled in and filed gets finished. If you find yourself unable to complete the record honestly, that is the finding, and it is better discovered on an ordinary Tuesday than during a customer's security review.
Making it stick
The checklist that works is the one attached to a process that already happens. Offboarding is usually run by whoever handles people matters, not by engineering, and a list that lives in an engineer's notes will not be used.
Two things make the difference. Put the checklist wherever your departure process already lives, so it is encountered rather than remembered. And keep a completed, dated copy per departure: that record is what you show when someone asks how you manage access, and it is far more convincing than the policy itself.
Contractors and the accounts nobody opened a ticket for
Contractors are where offboarding most often fails, for a structural reason: there is frequently no leaving date. An engagement tails off, the invoices stop, and nobody triggers a process because nobody decided that today was the last day.
The access stays. Six months later the person has a live account and a laptop with your source code on it, and neither party has thought about it since the work finished.
Two habits fix most of this:
- Set an expiry when you grant the access, not when the work ends. Most systems support time-limited invitations, temporary group membership, or credentials with an end date. A contractor added with a ninety-day expiry is a contractor whose access closes itself if everyone forgets, which they will.
- Review external access quarterly. A short scheduled look at outside collaborators in source control, guest accounts in your identity provider, and anyone in a vendor console who is not staff. Fifteen minutes, and it catches what the departure process structurally cannot.
The same reasoning applies to anybody who was given access for one specific purpose: an auditor, an agency, a developer brought in for a migration. Access granted for a project should end with the project, and the only reliable way to achieve that is to decide the end date at the beginning.
Finding the ones already open
Before the next departure, look at the last few. For each person who has left in the past two years, check your main systems for their account. Most teams find at least one thing still live, and the most common finds are a source control collaborator entry, a vendor portal, and an API key created under their name.
It is an uncomfortable exercise and a short one. Finding three stale accounts is a much better outcome than not knowing, and it gives you a realistic starting point for the list.