Someone resigns on a Friday. By Monday their laptop is in a drawer, their account is disabled, and everyone considers the matter closed. Six weeks later an invoice arrives for a seat that nobody is sitting in, or a former colleague still has a shared login to the analytics tool, and the matter turns out not to have been closed at all.

The gap is almost never carelessness. It is that offboarding is written as a checklist against the identity provider, and the identity provider only knows about the systems it was told about.

Start from the money, not the directory

The usual list is built by walking the SSO tenant. It misses everything bought on a card, everything with a shared login, and everything a team adopted before IT heard about it — which, in most companies, is a third of the stack.

A better first pass is the card statement and the accounts-payable ledger. Every recurring charge is a system somebody uses, and every system somebody uses is a door. Cross-reference that list against the directory and the difference is your shadow estate.

The order that matters

Work it in this order, because each step makes the next one safer:

1. Suspend, don't delete. Deleting an account destroys the audit trail and frequently the person's files with it. Suspend first; delete after the retention window.
2. Revoke sessions and tokens. Disabling an account rarely kills the active OAuth grants, the personal access tokens, or the API keys they generated. These outlive the account and are the ones that actually get abused.
3. Reassign ownership. Documents, dashboards, calendars, repositories, scheduled jobs, DNS records, on-call rotations. Anything owned by a suspended account is a future outage.
4. Rotate shared credentials. Any password in a vault the person could open is now a password they know. Rotate the vault items their group had access to, not just the ones they opened.
5. Reclaim the seats. Deprovisioning the account does not always cancel the billing. Many vendors keep charging for a disabled user until someone removes them from the plan.
6. Collect the hardware, then wipe it. In that order, and record the serial against the ticket.

The four that are always missed

Even careful teams tend to miss the same four:

• Personal access tokens and API keys in source control, CI, and internal tools. They authenticate as the person and survive the person.
• Third-party OAuth grants the person approved — a scheduling tool with calendar write access does not care that their account is suspended.
• Shared logins with no per-user identity at all. There is no account to disable, only a password to rotate.
• Anything with its own user list: the billing portal, the domain registrar, the bank, the CRM's admin panel. These are rarely wired to SSO and are exactly the systems you least want a former employee inside.

Make it evidence, not memory

Whatever the list is, the important property is that completing it produces a record. An access review six months later asks "who had access to what, and when was it removed" — and "we always do it" is not an answer an auditor accepts.

A ticket per departure with a timestamped line per system is the minimum. If the same list is what your access reviews read from, the review stops being a quarterly archaeology project and becomes a query.

The checklist above is the part you can do today with a spreadsheet. The part worth automating is the discovery — knowing which systems a given person could reach without having to remember them.

← All resources