When someone leaves, the risk is in the accounts nobody listed.

The list that isn't a list

Most companies have an offboarding checklist. It covers the laptop, the badge, the email account and the main business systems. It rarely covers the things that actually cause trouble later.

Those tend to look like this. A shared login for a supplier's ordering portal that three people use. The company's social media account, registered to someone's personal phone number years ago. The domain registrar. The bank's payment approval token. A spreadsheet automation that emails the weekly numbers, built on the departing person's account, which stops the day it's disabled. A design tool subscription on their company card. Calendar invites they own for every recurring meeting in the department.

None of this is anyone's fault. It accumulates because people get work done. Offboarding is the moment you find out how much of the business was quietly running through one person's accounts.

So treat it as a short countdown, with a person responsible for each step, rather than a single moment when IT flips a switch. The order matters as much as the steps.

When notice is given

This is the most useful time in the whole process, and it's often wasted. The person is still here, still helpful, and still remembers what they set up.

Build the inventory. Start with what your systems can tell you: accounts in your single sign-on, if you have one, and groups the person belongs to. Then add what they can't: shared vaults in the password manager, recurring charges on the person's company card, vendor portals and supplier accounts, anything registered to their phone number or personal email. Then ask the person directly: "What did you set up that would stop working if your account disappeared?" You'll get answers no tool can give you.

List what they own, not just what they can reach. Files and shared folders. Recurring meetings. Automations, scheduled reports and integrations running under their name. API keys they created. Supplier and customer relationships where they're the named contact.

Assign a new owner to each item, and plan the handover with the people who'll inherit it.

A short handover conversation is worth booking for anything that runs on its own. Ask the departing person to show the new owner the weekly report, the supplier portal or the automation, and to explain what they do when it goes wrong. Ten minutes on a screen share now saves a long afternoon of reverse engineering later. Write down what you learn next to the item on the inventory, so the knowledge outlasts both people.

When a departure isn't voluntary, the timing changes. The inventory still matters, but it's built quietly beforehand and the access steps happen together, at the agreed moment. That's a decision for HR and leadership, and the workflow should support both paths.

The last day

Here the sequence is what protects you.

Transfer before you disable. Move file ownership, recurring meetings and automations to their new owners first. Some tools delete or orphan what a disabled user owned, and recovering it later is slow at best. Turn off the account first and you find out what it was doing by watching things break.

Then disable access in one sitting. Single sign-on account, email, the business systems that sit outside single sign-on, and the vendor portals on the inventory. Sign the person out of active sessions and revoke tokens and keys they created, rather than just changing a password and hoping.

Change the shared secrets they knew. Every shared login and every key on the inventory gets a new password or a new key, with the people who rely on it told in advance. We wrote about doing that without breaking things in rotate credentials like a cutover, not a chore.

Collect devices and set up forwarding. Decide where their email and phone messages go, and for how long, and add an automatic reply that tells customers and suppliers who to contact.

The day after

Something will have stopped working. The goal is to find it before a customer does.

Check the scheduled jobs and reports that ran overnight. Look at the shared inboxes and the forwarding address for messages that need a new home: supplier invoices, customer questions, renewal notices addressed to the person who left. Ask the people who inherited each item whether they can actually use it. A folder transferred without the right permissions is still a lost folder.

Customers and suppliers are part of this too. If the person was someone's main contact, tell those people who to talk to now, in a personal note rather than only an automatic reply. A supplier who keeps emailing a disabled address will eventually stop sending invoices anywhere useful, and a customer who gets silence may assume the worst.

Whatever broke, add it to the inventory template so the next departure catches it on day one.

Thirty days later

A month on, close the loop.

Confirm that licenses for tools the person used have been cancelled or reassigned, so you stop paying for seats nobody uses. Move any subscriptions billed to their company card onto a team card or cancel them. Remove the email forwarding when it's no longer needed. Handle the person's mailbox and files according to your retention policy, not by default. If you don't have one, our note on deciding the delete path before you store the record is a place to start.

Then record that the offboarding is complete, with who did what and when. If anyone ever asks whether access was removed, that record is the answer.

Automate the routing, keep a person on the judgment

A departure is a good candidate for automation because it's a chain of small, predictable tasks owned by different people, and the cost of a missed step shows up weeks later.

A useful offboarding workflow starts when HR records the leaving date. It creates a task for each system owner, with the person's accounts from the inventory attached. Each owner confirms when their step is done, in order, so ownership moves before access is removed. The workflow tracks what's still open and reminds the right person. Anything it can't handle, such as a tool that isn't on any list, goes to a named person with the context attached.

The same workflow should run in reverse when someone joins. If every new account is recorded as it's created, the inventory for their eventual departure builds itself.

That's the kind of work we do in business process automation: clear workflows with visible progress and explicit owners, where the exceptions land with a person instead of disappearing. If your offboarding lives in someone's memory, bring it to us and we'll map it with you.

Related work: WorkStep.