User Offboarding: 9 Proven Steps for Safer IT Access

Ask most small and mid-sized businesses how they handle a departing employee and you will hear a confident answer about disabling the mailbox. Ask the same question about the eleven other systems that person touched, and the confidence drains away. User offboarding is one of those processes that everyone assumes is covered because the obvious half of it is. The unglamorous half — the SaaS tools bought on a departmental card, the shared admin logins, the API keys, the VPN certificate, the supplier portal — is where access quietly survives long after someone has handed back their laptop.

This matters more than it used to. A modern SME estate is not one directory with a handful of servers behind it; it is a directory plus dozens of cloud services, several of which were never wired into single sign-on. Every one of those services is a place where user offboarding can fail silently. Nobody gets an alert when an account is not disabled. The failure only surfaces during an audit, a security incident, or an awkward conversation about a licence bill for someone who left eight months ago.

Why User Offboarding Is Where SME Security Quietly Fails

The structural problem is that user offboarding sits in the gap between HR and IT. HR knows the leaving date. IT knows the systems. Neither owns the join between the two, and in a smaller organisation there is rarely a formal identity governance platform to force the handoff. What exists instead is a checklist in a shared document, maintained by whoever last remembered to update it, executed by whoever happened to pick up the ticket.

Checklists like that decay in a very specific way. They are accurate for the systems that existed when the checklist was written, and blind to everything adopted since. A team signs up for a new project tool, a new design platform, a new monitoring service. None of those get retro-fitted into the user offboarding runbook, because adding them is nobody’s job. Two years later the runbook covers perhaps 60% of the estate, and the organisation has no way of knowing which 40% it is missing.

The second failure mode is timing. Offboarding is treated as an event that happens on the last day, when in practice risk is highest in the notice period and in the weeks afterwards. Access that persists after departure is the textbook definition of an orphaned account: a valid credential with no owner, no manager, and nobody watching it. Attackers like these accounts precisely because using one does not look like an intrusion. It looks like a normal login.

The third failure mode is that user offboarding is measured by completion, not by coverage. A ticket gets closed. Nobody asks whether closing it actually removed everything, because verifying that is far more work than doing it. The UK National Cyber Security Centre’s 10 Steps to Cyber Security guidance on identity and access management is blunt about the principle: accounts should be removed when they are no longer required, and access should be reviewed rather than assumed. The principle is uncontroversial. The staffing to sustain it is what SMEs are missing.

Joiner, Mover, Leaver: Offboarding Is Only One Third of the Job

It helps to put user offboarding in its proper frame. Identity practitioners talk about joiner-mover-leaver, or JML: the three lifecycle events at which someone’s access should change. Joiners get access provisioned. Movers get it changed. Leavers get it removed. Most organisations do the first well, because a new starter who cannot log in complains loudly on day one. The other two are silent, and silence is the enemy here.

Framing your process as JML rather than as user offboarding alone has a practical benefit: it stops you building a leaver runbook that quietly assumes everyone’s access was correct up to the moment they resigned. If a departing engineer accumulated three roles’ worth of permissions over five years, the user offboarding process now has to unwind all of it, and the person running the ticket has no idea what “all of it” means.

The other benefit is that joiners and leavers share a single source of truth. If you can define what a role should have on day one, you have also defined what to take away on the last day. Role-based access templates are not exotic identity governance; they are a spreadsheet that says a service desk analyst gets these eleven things and nothing else. That spreadsheet makes user offboarding a comparison rather than an investigation.

9 Proven Steps for User Offboarding That Actually Holds

None of what follows requires an enterprise identity platform. It requires a defined sequence, a named owner, and the discipline to run it the same way every time. This is the core of a user offboarding process that survives contact with a busy month.

1. Build the application inventory first

You cannot offboard from systems you have not written down. Start with an inventory of every application holding a user account: directory, email, finance, CRM, code repositories, cloud consoles, monitoring, VPN, ticketing, HR, supplier and client portals. Pull expense data and browser-extension or SSO telemetry to catch tools IT never provisioned. This inventory is the single highest-value artefact in user offboarding, and it is the one most SMEs skip.

2. Mark which systems are inside SSO and which are not

For every application, record whether disabling the directory account actually terminates access. Systems federated through single sign-on are handled by one action. Systems with local credentials are not, and those are the ones that leak. Splitting the inventory this way tells you exactly how much manual work each user offboarding event really involves.

3. Trigger from a real HR event, not an email

The process should start from a leaver record in the HR system, not from a manager remembering to message IT. Even a simple weekly export of upcoming leavers, checked against open offboarding tickets, closes the most common gap: the departure nobody told IT about until after it happened.

4. Disable before you delete

Disable the account, revoke active sessions and tokens, and reset the password — in that order — before deleting anything. Deletion destroys audit trail and sometimes data. Disabling is instant, reversible, and sufficient to stop access. Good user offboarding separates “stop access today” from “tidy up licences in thirty days”.

5. Kill the sessions and tokens, not just the password

This is the step most often missed. A disabled account with a live OAuth token, a valid refresh token, an active mobile session or a saved application password may still be functioning. Explicitly revoke sessions and app passwords in every major platform. A password reset alone does not achieve this in most cloud services.

6. Handle shared and service credentials explicitly

If the leaver knew a shared admin password, a Wi-Fi PSK, a break-glass account or a credential embedded in a script, that credential is now compromised for the purposes of user offboarding. Rotate it. This is the step that gets skipped because it inconveniences people who are still employed — which is exactly why it needs to be written into the runbook rather than left to judgement.

7. Deal with data and delegation before removal

Transfer mailbox and file ownership, convert the mailbox to shared or set up delegation, reassign tickets and calendar items, and check for automation the person owned: scheduled reports, integration accounts, alert routing that still points at their address. Broken automation discovered three weeks later is the usual sign this step was rushed.

8. Recover hardware, certificates and physical access

Laptops, phones, hardware tokens, door cards, and client-site credentials all belong in the same user offboarding record. Device certificates and MDM enrolments deserve particular attention: a wiped laptop that still holds a valid device certificate is a credential in a drawer.

9. Verify, then evidence it

Close the loop by re-checking the account in each system on the inventory and recording the result with a timestamp. Verification is what turns user offboarding from an intention into a control. It is also the only part of the process an auditor can actually test.

The SaaS Long Tail: Where User Offboarding Leaks Most

The systems that break user offboarding are almost never the big ones. Nobody forgets email. What gets forgotten is the analytics tool a marketing manager signed up for, the status page, the DNS registrar, the shared account at a courier or supplier, the design platform bought on a personal card and expensed. These sit outside SSO by definition, because they were adopted outside IT.

Two practical countermeasures work well at SME scale. The first is a quarterly reconciliation between finance data and the application inventory: any recurring charge that does not map to a known system becomes an inventory entry. The second is a licence-count check. If a tool bills per seat and the seat count exceeds current headcount for that team, you have found orphaned accounts without needing any specialist tooling.

It is also worth being honest about scope. A perfect user offboarding process across a genuinely unknown estate is not achievable. A good one across a documented estate, with a known and shrinking list of exceptions, is. The goal is a process where the gaps are named rather than hidden.

Movers Are Harder Than Leavers

Leavers are at least a discrete event with a date attached. Movers are worse, because a role change produces an addition and almost never a subtraction. The salesperson who moves into operations keeps CRM admin rights. The developer who moves to a customer-facing role keeps production database access. Nobody removes the old permissions, because removing access risks breaking something and nobody wants that call.

Over several years this accumulation — privilege creep — means your longest-serving and most trusted people hold the broadest access in the organisation. That is the opposite of least privilege as NIST defines it, and it makes any future user offboarding for those people a genuinely difficult project rather than a checklist.

The fix is a recertification cadence: at every role change, and at least annually for privileged accounts, the manager confirms line by line what access is still required. It is dull, repetitive work with no visible output when everything is fine — which is precisely why it needs a named owner rather than good intentions.

What Good User Offboarding Leaves Behind for an Auditor

If you are being assessed under Cyber Essentials, ISO 27001, SOC 2 or a client’s security questionnaire, you will be asked to demonstrate the control rather than describe it. In practice that means producing, for a sample of leavers, a record showing the departure date, the systems checked, who checked them, when, and the outcome for each.

A user offboarding process built around a ticket template does this almost for free: the ticket becomes the evidence. A process built around institutional memory produces nothing, and the organisation ends up reconstructing history under time pressure during an audit. The difference in effort between the two is roughly one well-designed template.

Keep the exception list visible too. If three systems cannot be automated and require a manual check, say so in writing, with the reason and the compensating control. Auditors respond far better to a documented, owned gap than to a process that claims complete coverage and cannot evidence it.

Staffing the Work: User Offboarding Needs a Named Owner

Every step above is achievable. The reason SMEs and their MSPs still fail at user offboarding is not capability — it is that the work is continuous, unglamorous and always less urgent than the ticket queue. It is the first thing dropped in a busy week and the last thing picked back up.

That makes it well suited to dedicated outstaffed capacity rather than to whoever is free. At OutsourceZA we place skilled South African IT engineers with UK and EU businesses and MSPs, typically at 40–60% of local cost, working the full UK business day rather than a night shift. South Africa’s timezone alignment matters here: access recertification and user offboarding involve chasing managers for confirmations, and that only works if your engineer is online when those managers are.

A dedicated engineer can own the application inventory, run the leaver reconciliation each week, drive the recertification cycle, and maintain the evidence trail — without pulling your senior people off client-facing work. Because outstaffed engineers are retained rather than rotated through like short-term contractors, the context they build about your estate stays with you. Our IT outsourcing and outstaffing services are structured for exactly this kind of sustained operational ownership, and we recruit from a deep local pool of engineers and analysts who are already familiar with MSP tooling — you can see the roles we hire for on our IT jobs page.

If user offboarding is currently a checklist nobody owns, the honest first move is not buying a platform. It is giving the process a name, an owner and an hour a week. Talk to us if you would like that owner to be someone who does it properly, at a cost that makes the maths work.

User Offboarding FAQs

How quickly should user offboarding be completed after someone leaves?

Access should be disabled on the final working day, ideally at a defined time agreed with HR, and for involuntary departures immediately before the conversation takes place. The remaining tidy-up — licence reclamation, data transfer, deletion — can follow over the next few weeks, provided the account is already disabled and sessions revoked.

Is disabling an account enough, or should it be deleted?

Disable first. Disabling stops access immediately while preserving audit history, mailbox contents and file ownership. Delete later, once data has been transferred and any retention obligations are met. Deleting straight away is the most common cause of avoidable data loss during user offboarding.

What is the difference between offboarding and access recertification?

User offboarding is event-driven: it happens because someone left. Access recertification is periodic: managers confirm that current staff still need the access they hold. You need both, because offboarding alone never corrects the permissions people accumulated while they were still employed.

Do small businesses really need a formal process for this?

Yes, though “formal” can mean a documented inventory and a ticket template rather than an identity governance suite. The smaller the team, the more access tends to be concentrated in a few people, which makes each departure more significant rather than less.

What about contractors and third parties?

They should be in the same user offboarding process, with an explicit end date recorded at the point access is granted. Third-party access is more likely to be missed because there is no HR leaver record to trigger the workflow — so the expiry date has to do that job instead.

Can user offboarding be fully automated?

Partly. SSO-federated systems can be handled automatically, and HR-triggered workflows remove the notification gap. But the SaaS long tail, shared credential rotation and manager confirmations still need a human. Automation reduces the volume of manual work; it does not remove the need for an owner.