Joiner, Mover, Leaver
The three events where access changes. Most organisations handle joiners well, movers badly, and leavers incompletely — and the gaps compound.
Procedure · 683 words
Access accumulates. Without a process at each of the three events, people end up with everything they have ever needed and nothing is ever removed.
Joiner
Usually the best-handled because someone is waiting and complaining.
The risk is over-provisioning. A role-based bundle granting every application is convenient and produces the unused-seat problem, plus access nobody needs.
A small universal set — email, chat, directory, whatever everyone genuinely uses — plus everything else on request.
Record what was granted and why, which makes the eventual review possible.
Assign the hardware in the same process, so the two registers stay aligned.
Mover
The worst-handled of the three, everywhere.
Someone changes role and gains new access. Almost nobody removes the old.
Over a career of internal moves, one person accumulates the access of four roles, which is how a support analyst ends up with finance system permissions.
The fix: treat a move as a leave and a join. Remove the previous role's access, grant the new role's, and let the person request anything they still need. This is unpopular and it is the only version that works.
A softer version: review the previous role's access thirty days after the move, with the new manager, and remove what is not needed. Less disruptive and it depends on the review actually happening.
Detect drift by comparing access against role peers. A person with substantially more applications than others in the same role has probably moved.
Leaver
Handled, and incompletely.
What is usually done: directory account disabled, email suspended, laptop requested back.
What is usually missed: applications outside single sign-on, OAuth grants, shared account credentials, external service accounts they registered, personal-account subscriptions billed to the company, ownership of applications and documents, and access to third-party systems belonging to partners or clients.
The offboarding checklist has its own note because the gaps are specific and enumerable.
Making the process actually run
Trigger from HR, not from a manager remembering. The joiner and leaver dates exist in a system already.
Automate what can be automated: directory, SSO applications, endpoint management.
Generate a task list for what cannot, with an owner and a deadline, per application, from the register.
This is the payoff for maintaining the register. An accurate application list per user turns offboarding from a memory exercise into a checklist.
Measure completion, not initiation. A leaver process started and abandoned halfway is the normal failure.
The measurement
Time from departure to complete access removal, per leaver.
Proportion of applications covered by automated deprovisioning.
Orphaned accounts found in the quarterly review, which is the audit of whether the process worked.
A rising orphan count means offboarding is failing somewhere specific, and the applications where the orphans appear tell you where.
Detecting movers nobody told you about
Internal moves frequently happen without a trigger reaching IT, and they are detectable from data you already hold.
Compare access against role peers. A person holding substantially more applications than others with the same job title has usually moved.
Watch for manager changes in the directory, which is the most reliable available signal.
Watch for cost centre changes, which finance sees before IT does.
Watch for a drop in usage of a set of applications, which frequently precedes the formal move.
Run the comparison quarterly and send the outliers to their current manager with a simple question: does this person still need these.
This finds accumulated access years old, and it is the only practical route in organisations where the mover process does not exist.
The provisioning bundle, sized properly
What a joiner receives automatically determines both the security posture and the licence bill.
The universal set: email, chat, directory, intranet, expenses. Things genuinely everyone uses.
The role set: a small addition per job family, defined with the business rather than assumed.
Everything else on request, through a path fast enough that nobody resents it.
Review the bundles annually against what cohorts of joiners actually use after three months.
Applications in a bundle that a third of joiners never open should not be in the bundle, and the measurement is available from your identity provider.