The departing employee: an IT offboarding checklist

Why this is the gap it is

Onboarding has an owner, a deadline and an obvious failure mode: if it goes wrong, someone cannot work and says so loudly on day one. Offboarding has none of those. If it goes wrong, nothing happens. Nobody complains. The account simply continues to exist, valid and unwatched, and the failure only surfaces months later during an audit, an insurance questionnaire, or an incident.

Which makes it a favourite finding. Dormant accounts with live credentials are attractive precisely because no one is monitoring them for unusual behaviour — there is no normal to deviate from. Most of the time the risk is not the departing employee at all. It is that their forgotten account becomes somebody else's front door.

The first hour

For a planned departure, this happens at the agreed time on the last day. For an unplanned one, it happens before the conversation, not after it.

• Block sign-in on the primary identity account. Block rather than delete — deleting immediately can take the mailbox and files with it, and you may need them.
• Revoke active sessions and refresh tokens. See below; this is the step most commonly missed.
• Reset the password and remove registered MFA methods, so a self-service reset cannot be used to walk the account back.
• Revoke application passwords, API keys and personal access tokens issued to them.
• Remove privileged roles first if they held any — administrator access is the one that turns a loose end into a serious problem.

Disabling the account does not end the session

This is the detail that surprises people, including technical people, and it is worth understanding rather than just following.

Modern cloud platforms do not check your password on every request. When you sign in, you receive a token that is valid for a period of time, and applications accept that token without re-consulting the directory. Disabling the account stops new sign-ins. It does not necessarily invalidate a token already issued and sitting in a browser, a phone app, or a mail client.

The practical effect is that someone whose account you disabled on Friday afternoon may still have a working mailbox on their phone that evening. The fix is to explicitly revoke sessions and refresh tokens as a separate action — it is a distinct control in Microsoft 365, Google Workspace and most major platforms, and it is not implied by disabling the account. If you do only one thing differently after reading this, do that one.

Devices, and the keys inside them

Retrieve company-owned hardware before the last day where you can, and do not reissue any device to a new starter until it has been wiped and re-enrolled.

Two details cause real trouble. First, disk encryption recovery keys: if a laptop's BitLocker or FileVault key was only ever held by the departing user, the device is a brick and the data on it is gone. Escrow keys to your management platform as a standing configuration, not as an offboarding step, because by then it is too late.

Second, personal devices. If the person read work email on their own phone, work data is still on it. What you can do about that was decided when they enrolled, which is the argument for choosing the BYOD model deliberately rather than discovering the limits on someone's last day. A managed app container makes this a single revocation. An unmanaged phone makes it a conversation.

Mailbox and files, without breaking a record

Resist the instinct to delete quickly. Business records, client correspondence and anything subject to a retention obligation or a live dispute may live in that mailbox, and deleting it can be considerably worse than leaving it.

The usual pattern: convert the mailbox to a shared mailbox or grant delegated access to the manager, set an auto-reply pointing correspondents at a current person, apply any retention or legal hold your obligations require, and transfer ownership of cloud files to the manager or team rather than letting them sit under an account you intend to remove.

Then set a date to actually finish. An offboarding that stops at "mailbox converted, we'll tidy it later" leaves a permanent shared mailbox nobody owns, which is its own quiet risk.

The access nobody wrote down

Everything above assumes you know what they had access to. This is where offboarding actually fails.

The identity platform covers what is behind single sign-on. What is not behind it tends to include: the SaaS tool a department bought on a card, the shared logins in a spreadsheet or an unmanaged password manager, the domain registrar, the bank and payment platforms, the ATO and government portals, the social media accounts, the code repositories and cloud consoles, the service accounts and automations they created under their own name, and third-party portals belonging to your suppliers and clients.

Two of those deserve particular attention. Automations built under a personal account — scripts, integrations, scheduled jobs — will break when the account is disabled, sometimes weeks later and rarely with an obvious cause; find them before you disable, not after. And access to client systems is the category most likely to embarrass you, because the person who has to be told is a customer.

The realistic way to build this list is not from memory. Pull it from what actually exists: your single sign-on application list, the expense records for software subscriptions, the password manager's shared vaults, and a direct question to the departing person's manager about what they used day to day.

When the departure is not friendly

A resignation on good terms and a dismissal are different operations and should be planned as such.

For a contested or high-risk departure, sequence matters: access is removed at the moment the conversation begins, not before it (which tips them off) and not after (which gives them a window). That requires HR and IT to coordinate on timing, which requires someone to have thought about it in advance.

Preserve rather than wipe. If there is any prospect of a dispute or an investigation, the mailbox, the device and the access logs are evidence, and the instinct to reset the laptop for the next starter destroys it. Take the device out of circulation and leave it alone until someone with standing says otherwise. Consider whether logging is enabled and retained for long enough to reconstruct what happened in the weeks before departure — that decision was also made long before today.

The fix is a process, not a longer checklist

Every organisation that has this problem already has a checklist somewhere. The checklist is not the missing piece. Three things are:

• A trigger that fires automatically. HR resignation or termination notifies IT as a matter of course, not when someone remembers. If your payroll or HR system can raise the ticket, let it.
• A named owner with a deadline, and a record of completion. "IT will handle it" is not an owner.
• A quarterly reconciliation between the current staff list and the active accounts across your major systems. This is the control that catches what the process missed, and it is the evidence an auditor or insurer actually wants to see.

Everything else gets easier the more systems sit behind single sign-on, because the number of places you have to remember to look goes down. Every application you bring behind SSO is an offboarding improvement as much as a login one.

Questions