14 July 2026

Why Bad Onboarding Is the Real Cause of Messy Offboarding

Photo by Mikhail Nilov on Pexels

A resignation letter rarely causes the mess that follows it. The mess was built months earlier, in the first few weeks after that same person joined, when nobody was watching closely because there were a hundred other things to sort out.

A shared login here. A tool signed up for with a personal email because IT hadn't provisioned the proper one yet. A laptop used until the company one turned up and never quite retired. None of it feels like a decision at the time. By the time the person hands in their notice, it's just how things are, and unwinding it becomes someone else's problem.

This post looks at why a leaver's IT offboarding can take weeks instead of hours, the habits during onboarding that cause it, and what to fix, both for the next new starter and for the team you already have.

The pattern behind a messy exit

Done properly, offboarding is short. An account gets disabled in the identity system, which cuts off every connected tool in one move. The device is wiped or collected. Email forwards to a manager or becomes a shared mailbox. Client and project ownership moves to whoever's picking up the work. If a handover document already existed from onboarding, it gets filled in and filed.

Done badly, the same task stretches into weeks. Someone starts a list of every tool the person used, usually by asking the departing employee to help remember, since nobody else knows. A Notion workspace turns up that nobody in management had heard of. An Airtable base. A Loom account. All set up independently, all with the only password sitting in that person's own head or their personal password manager. The laptop is still at their house and there's no urgency on their side to return it. Weeks later, a card statement shows a renewal for a tool you thought had already been cancelled.

The National Cyber Security Centre's guidance on identity and access management describes this as a "joiners, leavers and movers" process: a formal policy for granting and revoking access as people join, change role, or leave. Where that process exists and was actually followed when someone joined, their departure is administrative. Where it didn't, every leaver becomes its own small investigation.

It's also exactly the kind of leftover access that turns into a real problem the moment a business switches on a tool like Microsoft 365 Copilot, since Copilot will happily search and summarise anything a stale permission still allows.

Four habits that turn a leaver into weeks of clean-up

Shared logins nobody wanted to pay to avoid

One login, several people, because buying a seat for everyone felt like an unnecessary cost at the time. It works fine until someone needs to leave. You can't remove one person's access without changing the password for the whole group, and the person who originally set the account up, and therefore knows the password, is often the one walking out the door.

Paying per seat has a real cost. Sharing logins has a cost too, it just arrives later, as the hours spent working out who else needs the new password and chasing them to update it everywhere they use it.

Personal phones and laptops that were only ever meant to be temporary

New starter's laptop hasn't arrived yet, so they use their own for a fortnight. The fortnight becomes permanent because nobody circles back to it. By the time they leave, that personal device holds company email, saved passwords and client files, and you have no way to remove any of it without their cooperation, because you never owned or enrolled the device in the first place.

A company-issued device, set up and managed from day one closes this gap, since access can be pulled remotely regardless of whether the device is sitting on a desk or has already left the building with someone who isn't answering calls.

Staff signing up for their own tools

A new hire needs a tool, IT hasn't provisioned it yet, so they sign up themselves with their work email. The account is now genuinely theirs. Nobody else can reset the password without alerting them, and until an invoice appears or the tool goes dark after they've left, you may not know it exists at all.

The fix is provisioning through a central system from the outset, so every new tool is connected to single sign-on before the first person logs in, rather than becoming shadow IT that surfaces months later.

Client relationships that live in one inbox

This one hits agencies, consultancies and any business built on individual client relationships hardest. A senior account handler leaves, and the history of that relationship, every preference, every half-finished thread, leaves with them, because it only ever existed in their personal mailbox.

From the client's side, it looks like your business forgot who they are. A shared mailbox, or a CRM where communication actually gets logged rather than left to memory, is a fairly small change that prevents a fairly large problem.

Cleaning up the team you already have

You can't retroactively onboard staff who joined years ago, but you can find out where the same four problems already exist and close them before the next departure, rather than waiting to discover them mid-exit.

Start with a device list. Who has what, whether it's company-owned or personal, and whether it's enrolled in any kind of management system. Most staff will confirm honestly what they're actually using for work, provided the question isn't framed as an accusation.

Follow the money for software. Three months of card statements, business cards specifically, will surface most of the tools nobody remembers approving. For each recurring charge, work out who owns the login and whether anyone else could get into it if that person left tomorrow.

Get client contact out of individual inboxes. Even something as simple as CC'ing a shared mailbox on client correspondence, with the expectation actually enforced rather than left as a suggestion, means a relationship survives the person who happened to manage it.

None of this needs new software. A spreadsheet and a few honest conversations covers most of it.

What proper onboarding actually includes

The habits above all trace back to the same root cause: onboarding treated as urgent admin to clear rather than a template worth setting up properly once. A version that holds up looks like this:

• Every account provisioned through one identity system, so nothing gets signed up for independently with a personal or work email that only the new starter controls.
• Every device enrolled in management before it's handed over, whether that's a laptop or a work phone, so access can be pulled remotely regardless of where the device physically is.
• A handover document started on day one, listing every system, client relationship and credential tied to that person, updated as things change rather than reconstructed from memory when they leave.

This is the same territory our managed IT support work covers as standard, along with keeping a proper record of devices, licences and access as part of ongoing IT documentation rather than something pieced together after the fact. If your current provider is only ever involved when someone resigns, that's a sign the relationship is set up the wrong way round.

Two months, not a big project

None of this needs to happen at once, and it doesn't need a fixed deadline tied to a specific resignation to get started.

In the first month, run the card-statement audit and build the device list described above, and flag anywhere access depends on a single person who could hand in their notice tomorrow.

In the second, move client communication into shared places for your highest-risk accounts, and write up the onboarding process you wish existing staff had gone through. Use it for the next new hire, and turn it into the handover template for everyone already on the team.

Most of this is a conversation and a spreadsheet, not a technology project. If you'd rather talk it through with someone who can set the identity and device side up properly, get in touch and we'll take it from there.