Offboarding: closing every door on the day someone leaves
Almost every organisation has an onboarding checklist. Far fewer have the reverse written down, and the reverse is where the risk sits. Onboarding failures are visible within an hour: someone cannot log in and says so. Offboarding failures are invisible by definition. An account that stays active after someone leaves does not complain.
Access removal is one of the few controls where timing is the whole control: the same account disabled three weeks later has had three weeks of exposure.
Disable in the identity provider first, then revoke live sessions and tokens, because disabling alone does not end a session already running.
The steps most often skipped are the shared credentials the leaver knew and the tools they signed up for themselves.
Why the day matters more than the week
The problem is rarely bad intent. It is that leaving is distributed across systems nobody owns together. HR closes the contract. A manager collects the laptop. IT disables the account, if IT was told. The SaaS tool the departing person signed up for two years ago is not on anybody's list, because nobody knew it existed.
Access removal is one of the few security controls where timing is the whole control. An account disabled the same day is a non-event. The same account disabled three weeks later has had three weeks of exposure, and in the meantime it has probably been used: for a forwarded mailbox, for a shared login someone still needed, or by an attacker who bought the credentials.
There is also a practical argument. The longer you wait, the harder it gets to work out what the person actually had. Their manager forgets. The person themselves is no longer available to ask. What could have been a fifteen-minute task becomes an investigation.
What to close, in order
The order below is deliberate. It closes the highest-value doors first, so that an interruption halfway through still leaves you in a defensible position.
- Identity first. Disable the account in your identity provider rather than deleting it. Disabling revokes access immediately while preserving the data and the audit trail. Deletion is a later decision, taken once you know what the mailbox and files need to become.
- Revoke active sessions and tokens. Disabling an account does not always end sessions already in progress. A phone with a live mail session can keep working for hours or days. Explicitly sign out all sessions and revoke refresh tokens.
- Reset anything shared. If the person knew a shared credential, that credential is now outside your control. Wi-Fi pre-shared keys, service account passwords, the alarm code, the door code, the shared admin login on a system that does not support individual accounts. This is usually the step that gets skipped, and it is usually the one that matters.
- Handle mail deliberately. Decide between a forward, a shared mailbox, and an out-of-office pointing to a colleague. Each has a different privacy footprint. Silently forwarding a former employee's mail to their manager is a decision with legal weight; make it consciously and record it.
- Remove privileged and external access. Admin roles, VPN, remote access, the client portals where your organisation logs in as a partner, the supplier systems where they were the named contact. External systems are the ones your identity provider cannot reach for you.
- Reclaim and wipe devices. Laptop, phone, tokens, keys. If the device is enrolled in management, trigger the wipe before it leaves the building, not after. For personal devices with company data, remove the company profile rather than wiping the device.
- Transfer ownership. Files, licences, domain registrations, code repositories, scheduled tasks running under their account. An automated job running under a disabled account is a service outage waiting for a quiet weekend.
The part most lists miss
Almost every offboarding list covers accounts and hardware. Three items are usually absent and cause most of the follow-up problems.
Licences. A disabled account often keeps consuming a paid licence. Nobody notices, because the invoice arrives at a different desk than the offboarding form. Over a few years this becomes a real number.
Documentation of what they knew. The person who understood why a firewall rule exists is leaving with that knowledge. A half-hour conversation before the last day, written down, is worth more than any exit interview.
The tools they signed up for. The subscription paid on a personal card, the account created with a personal email, the automation connected to a system nobody else can see. This is shadow IT surfacing at exactly the wrong moment, and it is the reason offboarding and IT inventory are the same problem.
Making it reusable
A checklist that lives in someone's head is not a checklist. Three things turn this into a process that survives staff changes:
- One trigger. HR notifying IT is the trigger. Not a manager mentioning it. Not the person's own email. One agreed signal, with an agreed lead time.
- One owner per step. Every line on the list has a name next to it, and a fallback name. Steps without an owner do not happen.
- A record that it happened. Not for bureaucracy, but because "we disabled the account on the third" is a sentence you want to be able to say with a date attached, especially if something surfaces later.
A quick test
Pick someone who left your organisation six months ago. Try to answer three questions without asking anyone:
- Is their account disabled, and on what date?
- Which external systems still list them as a user or a contact?
- What happened to the licences they held?
If those answers take more than a few minutes, the checklist is not the problem. The record is.
Offboarding is not a security project. It is a list, an owner, and a habit. The organisations that do it well are not the ones with the most tooling. They are the ones where the list exists on paper and somebody's name is next to every line.
Questions we get about this
The ones that come up most often once this is on the table.
Who should own offboarding, HR or IT?
HR owns the trigger and IT owns the execution. The failure is almost never that one of them refuses; it is that neither has agreed which signal starts the clock. Write down one trigger with one lead time, and give every step on the list a named owner and a fallback.
How long should we keep a former employee's mailbox and files?
Longer than most people expect, and it is a legal question before it is a technical one. Disable the account immediately, but keep the data until you know what your retention obligation is and whether anything in there is needed for an ongoing matter. Deleting on day one is the mistake that cannot be undone.
Can we review what someone did in their final weeks?
Reviewing access logs for security purposes is generally defensible. Targeted monitoring of one individual is a different matter with works council and privacy implications. Decide it as a policy in advance rather than case by case after someone resigns.
What if someone leaves on bad terms and we need to act within the hour?
That is the scenario your normal process should already cover. If the only way to disable someone quickly is to find the one person who knows the admin password, you do not have a process. You have a dependency.
Where this sits with us
The services this subject falls under.
Want to know what your last leaver can still reach?
We walk through your identity provider, your shared credentials and your external systems, and hand back the list of what is still open. Budget about half a day. You keep the checklist as something reusable.
Practical IT knowledge in your inbox
New guides on management, security and the workplace, written by the people doing the work. No sales talk, and you can unsubscribe in one click.