A typical employee offboarding checklist is a page of items: collect the laptop and the badge, hold the exit conversation, process final pay, remove access. Each item is correct. The last one is the item that causes the trouble, because it hides a large piece of work behind four words.
Removing access sounds like a single task. In a company that has been running for a few years it is a search across dozens of systems, shared logins and connections that nobody has listed. The checklist does not fail for want of items. It fails because it cannot say where the person has access.
A person's access is not in one place. It sits in the main sign-in system, if you have one, and also in the tools that were set up before it existed, the ones that use their own logins. It sits in shared accounts whose password the person knows. It sits in tokens they created when they connected one tool to another, which keep working after the person is gone. It sits in a mailbox with forwarding rules, in a calendar that owns recurring meetings, in cloud storage folders only they can share, and in automations that run under their name.
Some of this you can see by looking at the person's profile. The rest you can only see if somebody has kept a register.
An access register is a plain table. One row for each place a person can sign in or act, with five columns: the system, the account, the role or permission level, the owner who approved it, and the date it was last used.
It is built from two sources. The first is the sign-in system, which lists the applications each person is assigned. The second is an inventory of everything outside it: tools with their own logins, shared accounts, tokens and keys. The second source is the one that is always missing, and building it once, with the heads of each department, takes a day or two.
The register pays for itself the first time somebody leaves. It also pays at onboarding, because the same table says what a new person in a given role should receive, and at review time, because rows that are never used are access to remove.
Closing everything on the last day is the common plan and the riskiest one, because some closures break things. A better order follows what depends on what.
Before the last day: move ownership. Records owned by the person, such as accounts, deals and projects, go to a named successor. Scheduled reports, automations and integrations that run under their identity are re-pointed to a service account or another owner. Shared folders are transferred. This is the step that most checklists leave out, and it is the one that prevents the Monday morning where a workflow fails because its owner no longer exists.
On the last day: suspend, do not delete. In the main sign-in system, suspend the account and end its sessions. Suspension is reversible and stops access at once. Deleting is neither, and it can take the person's records and workflows with it.
Then the tools outside the sign-in system. Work down the register: each system with its own login, each shared account, each token the person created. Revoke or rotate, and write the date beside the row.
Rotate what they knew. Any shared password, key or code that the person had access to changes on the last day. This is cheap and routinely skipped.
Redirect, then wait. Forward their mail to the manager or a shared address for a set period, with an automatic reply that names a contact. Keep the suspended account for thirty to ninety days before deleting, so that anything that fails because of it can be found and repaired.
Equipment and the people side. Collect the laptop, the phone and the badge. Final pay, benefits and the paperwork follow your policy and the rules where you operate, which differ by state and by country, so check them with your HR lead or adviser.
In many business systems, a record has an owner and a workflow has a run-as user. Delete the person and the record is orphaned or reassigned to a default, which may be an administrator who does not know it. A scheduled job that ran under their login stops, and nothing reports it. An integration that used their token returns an error every night from the day they left, and the first sign is a report that does not add up weeks later.
Suspension avoids all of that, and moving ownership first removes the dependency. That is why the order matters more than the length of the list.
Imagine a 90-person company where a sales manager leaves. The checklist is followed: laptop collected, main account deleted that afternoon. The manager had created the connection between the CRM and the marketing tool two years ago, using a personal login. On the next run, the sync fails. For three days, new leads from the marketing tool do not appear in the CRM. About forty leads wait, and one of them is a request for a quote that goes to a competitor.
With the register, the connection is a row: system, account, owner. It is marked "connected under a personal login, move to a service account before exit". Moving it takes twenty minutes the week before the last day, and the sync never stops.
Give it one owner, usually the person who runs IT or operations, and one trigger: whenever a system is added, a row is added. Treat that as part of buying the tool, the same way you would treat the invoice. A register that is rebuilt from scratch at each departure is a research project. One that is maintained is a table you read.
Ask department heads to confirm their rows twice a year. They know which tools their teams signed up for, and they are the only people who can tell you that a login used by three people is really used by one. The review is short, and what it finds is usually a shared account that should be individual or a tool nobody has opened since last winter.
Two figures are enough. The first is the time from the last day to the last access closed, which should be the same day for everything in the register. The second is the number of accounts found open after a departure by a later review, which should be zero and is rarely zero in the first year.
Pick the last person who left and look at what they could still reach a month after their last day. If the answer is a surprise, you have found the register's first rows. Write them down, and the same exercise for the next departure will take an hour. For the other end of the same lifecycle, see what goes wrong on day one on a spreadsheet and where the spreadsheet stops being free.
We start with a no-risk discovery: we build the access register from your sign-in system and an inventory of the tools outside it, show what the last three leavers could still reach, and propose the order of steps for your systems, and you pay for the discovery only if you go on. A build comes with a guaranteed estimate, so if we estimate low, we absorb the difference. After go-live, Managed Technical Operations keeps the register current and runs the review.
Know where a person has access before they leave, and offboarding becomes a routine.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
