Skip to main content
Back to blog
IT Support

Joiner, mover, leaver: the IT process most businesses only half do

Onboarding usually works because somebody complains if it does not. Offboarding usually fails because nobody does. Here is the process that closes the gap.

2026-08-176 min readBy Mohd Ahsan, Head of Managed Services
Consultant and client reviewing an IT roadmap across a table

Ask any business whether it has a leaver process and the answer is yes. Ask them to list everyone who left in the last year and check every system for live access, and the answer changes. This is the most reliable finding in any IT audit, and it is entirely fixable.

Why offboarding fails and onboarding does not

Onboarding has a complainant. If a new starter has no laptop on Monday, somebody escalates within the hour. Offboarding has none. Nobody notices that a former employee still has a live account, because the only person who would notice is the one who left.

That asymmetry is the whole problem, and it means offboarding has to be triggered by a process rather than by someone remembering.

Joiner

The requirement is that the person is productive on day one, which means the work happens before day one. Device ordered and staged, enrolled in management, encrypted. Account created with the correct group memberships rather than copied from a colleague, which is how permission sprawl starts. Multi-factor authentication enrolled during induction, not left for later. Access to the specific systems the role needs, granted from a role definition rather than a guess.

Agree a lead time with whoever hires, and hold each other to it. A device requested on Friday for a Monday start is not a process failure on IT.

Mover

This is the step almost nobody does, and it is where the worst access sprawl comes from. When someone changes role, access is added and almost never removed. After three internal moves an employee can hold permissions from every job they have had, which is a genuine risk and an audit finding waiting to happen.

Treat a role change as a leaver from the old role and a joiner to the new one. Remove first, then add.

Leaver

The list is longer than most businesses expect, which is exactly why it needs to be written down rather than remembered. Disable the account rather than deleting it, so data is preserved and can be handed over. Revoke active sessions and tokens, because disabling an account does not always end a session already running. Reset or remove multi-factor methods. Collect and wipe the device. Remove access from every SaaS application, which means having an inventory of them. Reassign shared mailbox and file ownership. Remove from VPN, cloud consoles and any code repository. Change any shared credential the person knew, which is an argument for not having shared credentials.

Do it on the leaving date, not when somebody remembers. For a resignation with notice, the date is known weeks in advance and can be scheduled.

Making it stick

The process only works if HR triggers it. IT does not reliably know that someone has resigned, and finding out through a farewell email is too late. A simple notification from HR to IT on hire, role change and resignation, with the effective date, closes most of the gap.

Then audit it. Quarterly, take the leaver list and check every system. The first time you do this you will find something live. That is normal, and it is the point of doing it.

What good looks like

A written checklist per stage. A trigger from HR rather than a memory. An inventory of every system access is granted to. A quarterly review that verifies rather than assumes. None of that is expensive; all of it is the difference between a process that exists on paper and one that works.

Talk to the team

Have a question about this topic?

If you would like help applying any of this to your environment, send us the specifics and an engineer will reply.