Security Basics: Building an Offboarding Checklist Before Someone Leaves
Most security conversations focus on what happens when something goes wrong from the outside. A quieter source of exposure is the moment a person leaves a team, changes roles, or stops handling a particular tool. Access that was granted for a reason tends to stay in place long after the reason has passed. An offboarding checklist turns that drift into a routine step. This article walks through a method small teams can use to find every place a departing person has a foothold, decide what to revoke, and make sure the business keeps control of the accounts it depends on. The goal is not to make any particular product safer on its own. It is to make your own access records accurate enough that you can act on them.
Start With an Inventory, Not a Memory
The first mistake most teams make is relying on memory to decide what a person had access to. Memory is incomplete, especially for tools that were set up quickly, used once, or handled by someone who has since moved on. A better starting point is a written inventory of every system the team uses, with a column for who holds administrative rights, who can invite or remove users, and where shared credentials are stored.
Build the inventory from places where access is actually recorded. Identity providers, single sign-on dashboards, and each vendor's user management page are the most reliable sources. Email invitations, shared spreadsheets, and chat messages are useful clues but should not be treated as the authoritative list. When you cannot find a user list for a tool, note that as a gap rather than assuming access is limited.
Keep the inventory in a form that someone other than its author can read and update. A plain document with one row per system is usually enough. The point is to make the next offboarding faster because the answers already exist.
Separate Personal Accounts From Shared Ones
Offboarding is simplest when every person has their own login. Problems arise with shared accounts, such as a single login used by a marketing group for a social platform or a common administrator account for a hosting dashboard. A departing employee who knows that password has effectively retained access, even if their individual account is disabled.
When you find shared logins, record who knows the credential and where it is stored. Then decide whether the account should be replaced with individual users, whose access can be removed cleanly, or whether the shared credential must be rotated as part of the departure. Rotating a shared password only helps if the new one is stored somewhere the departing person cannot reach and if every other tool using the old password is updated.
Keep a list of accounts that cannot be made individual, such as certain billing accounts or legacy integrations. These deserve the closest attention during any change in staffing.
Build a Revocation Order That Covers the Edges
When a person leaves, the order in which you revoke access matters. A reasonable sequence starts with the central identity system, because disabling a person there often cuts off many downstream logins at once. Next, review each individual tool that does not use central sign-in, since those accounts may still accept a local password. Then check for personal access tokens, API keys, deploy keys, and webhooks the person created, because these can persist independently of any login.
Do not forget devices and recovery paths. Phones enrolled for two-factor prompts, recovery email addresses, and personal backup codes can all keep an account reachable. Ask the departing person to confirm which devices hold authenticator apps or saved sessions, and check whether any recovery email on an admin account points to their personal address.
Finally, review what the person owned rather than merely used. Documents, shared folders, and scheduled jobs sometimes belong to an individual in the tool's records, which can cause problems if that individual's account is simply deleted. Transfer ownership before removing the account, and confirm the transfer by checking the resource afterward.
A Practical Offboarding Checklist
Use this sequence each time someone leaves or changes responsibilities. First, confirm the person's inventory entries and identify every system where they hold admin or invitation rights. Second, disable central sign-in and record the time it was done. Third, revoke or rotate any shared credentials they knew, and update the inventory to show the new holder. Fourth, remove API keys, tokens, and webhooks they created, after confirming nothing critical depends on them. Fifth, transfer ownership of documents, folders, and scheduled tasks to a named current employee. Sixth, check recovery emails and enrolled devices on admin accounts. Seventh, ask a second person to review the inventory for any system missed.
Keep a short log of each step with the date and the name of the person who completed it. The log is useful not because it proves anything dramatic, but because it lets you answer later questions about what was changed and when without reconstructing it from memory.
Run this checklist even for departures that feel friendly and low risk. Access problems rarely come from dramatic situations. They come from ordinary transitions where no one remembered a single shared password or a forgotten API key.