Offboarding is a control, not a checklist

Ask a team how offboarding works and you'll usually get a document: a list of steps someone follows on a person's last day. Ask how they'd prove a specific person's access was fully removed six months ago, and the answer is usually a search through a ticket queue.

That difference — a process you follow versus a result you can demonstrate — is what separates a checklist from a control.

Why the checklist misses things

Offboarding checklists are written once, usually when the company is smaller, and they capture the systems that existed that day. Every tool adopted afterwards is added only if someone remembers. Nothing in the process forces a reconciliation against reality, so the checklist slowly drifts away from the actual set of systems that grant access.

The systems most likely to be missing share a trait: they were adopted by one team for one purpose, and they issue access independently of the identity provider. A cloud IAM user created for a migration. A monitoring account made during an incident. A payments dashboard someone needed once.

The two questions that make it a control

• Detection: does something compare your directory against every connected system, so a person marked inactive who still holds access anywhere becomes visible without anyone remembering to look?
• Confirmation: when access is removed, does something observe that it's actually gone — as opposed to recording that a person said they removed it?

Both questions have to be answered by a mechanism rather than a person's diligence. That's the entire difference. A checklist depends on someone remembering; a control fails loudly when it isn't followed.

A note on the confirmation half

It's tempting to solve this by giving a tool permission to revoke access directly — it would close the loop automatically. We deliberately don't, for two reasons.

The first is blast radius: a platform holding write credentials into every customer's cloud is a spectacularly attractive target, and a compromise of it would be worse than the problem it solves. The second is evidentiary. If the same system both performs a revocation and attests that it happened, it is vouching for its own work. An independent observation that the access is gone — collected on a later pass, from the system itself — is the stronger artifact, and it's the one an auditor is actually asking for.

Where to start this week

• List every system that can grant access independently of SSO. That list is almost always longer than the offboarding doc.
• Pick the last three people who left and check each system by hand. Whatever you find is your baseline.
• Automate the comparison before you automate anything else — detection first, because you can't confirm what you never detected.

See it on your own evidence

Bring a policy document to a 20-minute call and we'll map it across your frameworks live.

Keep reading