Compliance
IT Infrastructure

Joiner Mover Leaver Process: Why “Mover” Is Where It Breaks

Joiner Mover Leaver Process Why Mover Is Where It Breaks

Every company with more than a handful of employees runs some version of the joiner mover leaver process, whether or not anyone calls it that: new hires get accounts, departing employees lose them. What’s far less consistent is the middle step. A joiner-mover-leaver process usually handles the “joiner” and “leaver” ends reasonably well, because both have a clear trigger and a clean outcome — provision everything, or revoke everything. “Mover” is neither. It’s the promotion, the department transfer, the six-month project rotation — and it’s where access quietly accumulates instead of resetting. If you want to know how exposed your organization already is, a focused security audit will usually surface it within days.

This isn’t a niche edge case. Every promotion, lateral move, and manager change is a mover event, and most mid-sized organizations run through dozens of them a month without any formal process — compared to the handful of joiner and leaver events that get careful HR-IT coordination. This guide breaks down why “mover” is structurally harder than the other two stages, what actually happens when it’s ignored, and a practical playbook for closing the gap without adding headcount.

What Is the Joiner Mover Leaver Process?

The joiner mover leaver process (JML) is the identity lifecycle framework that governs how access is granted, changed, and removed as someone’s relationship with an organization evolves. It covers three stages: a joiner is provisioned with the access their new role requires; a mover has their access updated when their role, team, or responsibilities change; a leaver has all access revoked when they depart. It applies to employees, contractors, and increasingly to non-human identities such as service accounts and automation bots whose “role” changes as systems evolve.

JML isn’t an informal best practice — it’s a named control in the frameworks most enterprise buyers, auditors, and regulators already check against. The official ISO/IEC 27001:2022 standard defines identity lifecycle management (Annex A control 5.16) explicitly in joiner/mover/leaver terms, requiring that identities be uniquely assigned, maintained, and revoked as circumstances change. That’s not a technicality: an auditor asking “show me your JML process” is asking a specific, answerable question, and “we handle onboarding and offboarding” is only two-thirds of a real answer.

Why “Mover” Is the Piece Everyone Gets Wrong

Joiner and leaver both have something mover doesn’t: a single, unambiguous trigger and a single, unambiguous outcome. A joiner starts at zero access and gets granted a defined set. A leaver has every credential revoked, full stop. Both map cleanly to a checklist and, increasingly, to automation triggered directly from the HR system.

A mover has neither. The trigger itself is ambiguous — is a mover event a promotion, a lateral transfer, a temporary project assignment, a new manager, a change of office or region, or a contractor converting to full-time? All of the above, and most HRIS platforms record some of these cleanly and others not at all. And the correct outcome isn’t a clean grant or a clean revoke — it’s a diff: add what the new role needs, and remove what the old one no longer justifies. Skipping the second half is the default failure mode, because removing access nobody is currently complaining about feels like it can wait.

Joiner and leaver are events. Mover is a diff. Provisioning and deprovisioning are binary and easy to automate end-to-end. A mover event requires knowing both the old state and the new one, and acting on the difference — which is exactly the kind of reconciliation work that gets skipped when there’s no dedicated process forcing it.

NIST codifies this asymmetry directly. NIST SP 800-53‘s account management control family (AC-2) requires organizations to modify account authorizations specifically “when needed to reflect… changes in user job function” — not just at creation and termination. In practice, that modification step is the one most access-management tooling was never built to enforce automatically, because most identity platforms default to additive provisioning: granting a new role’s access is one click, but nothing forces the corresponding removal.

Joiner vs. Mover vs. Leaver: What’s Supposed to Happen

Laid side by side, the structural gap is obvious — mover is the only stage that requires knowing what to take away, not just what to add:

StageTypical TriggerWhat’s Supposed to HappenWhy It Usually Breaks Anyway
JoinerNew hire record in HRIS / offer acceptedProvision a defined access set matching the role, from a zero-access baselineRarely breaks — clear owner (IT/onboarding), clear checklist, easy to automate from HR data
MoverPromotion, transfer, project reassignment, manager change — often unrecorded or recorded lateAdd access the new role needs and remove access the old role no longer justifiesNo single clean trigger; removal step has no urgency and is routinely skipped
LeaverTermination date / resignation processed in HRISRevoke all access across every connected system, immediatelyMostly works when automated from HRIS; still fails for systems outside SSO scope
Joiner vs. Mover vs. Leaver: What’s Supposed to Happen
In the joiner-mover-leaver process, joiners and leavers get clean, single-event outcomes. Movers accumulate access from every role they've ever held unless something explicitly forces removal.

What Breaks When Mover Access Is Ignored

The reason “leaver” gets careful attention while “mover” doesn’t is largely optical. An ex-employee logging into company systems is an obvious, visible failure — the kind of story that ends up in a breach report, and it happens more often than most IT leaders assume: a Beyond Identity survey found 83% of former employees admitted to retaining access to at least one account from a past employer. That visibility is exactly why leaver processes get investment. A mover retaining old access is invisible by comparison: the person is still logged in every day, doing their job, just with more doors unlocked than their current role requires. Nothing about it looks wrong until someone asks the right question during an audit, or until that extra access is exactly what an attacker needed after compromising the account.

And credential compromise is still how most attackers get in and move around once they’re there. Verizon’s 2026 Data Breach Investigations Report found credential abuse present in roughly 39% of breach chains overall — meaning that once an attacker has a valid login, what that account can actually reach determines how far the incident spreads. An account carrying access from three roles ago has a proportionally larger blast radius than one scoped to its current job, regardless of whether the person behind it is trustworthy.

Unaddressed mover access also breaks quieter things: it’s a direct segregation-of-duties violation when someone who moved from finance operations into IT still holds their old approval rights, and it’s how people end up with standing access to tools that should have shrunk back to least privilege the day their role changed. It’s also a common source of shadow IT sprawl — a mover who picked up a new department’s SaaS tools during a transfer rarely has anyone checking whether the old department’s tools should be removed. None of this shows up as a single dramatic incident. It shows up as a slowly widening gap between what an access review finds and what the org chart says should be true, which is precisely the kind of thing that surfaces — expensively — the moment a SOC 2 or ISO 27001 auditor asks for evidence.

A 5-Step Mover Access Playbook

None of this requires new headcount or an enterprise IGA platform to fix. It requires treating mover access as a defined process with the same rigor as onboarding, rather than an informal request that IT handles when someone asks:

  1. Trigger the review from HR, not from IT noticing. Every role change, transfer, or manager update recorded in your HRIS should fire a mover-access review automatically — Microsoft-shop teams already licensing Entra ID Governance often own this capability without realizing it’s switched off.
  2. Diff before you grant. Pull the person’s current entitlements and compare them against the target role’s baseline before adding anything new. Granting first and “cleaning up later” is how the removal step quietly never happens.
  3. Set an explicit removal deadline for old access. Old-role access should have a hard expiry date the moment the mover event is recorded — not an open-ended “we’ll get to it,” which in practice means never.
  4. Route it through the same approval path as a new hire. A mover’s new manager should sign off on the new access, and the old manager (or system owner) should confirm the old access can be removed — not a one-sided Slack message to IT.
  5. Log the before-and-after state. Keep a record of exactly what changed and when, so a later SOC 2 or ISO 27001 audit can verify the process happened rather than just trusting that it did.

Common Mover Trigger Events (and What Usually Gets Missed)

Not every mover event looks like a mover event in your HRIS. These are the ones that most often slip through without triggering an access change at all:

Trigger EventAccess That Should ChangeWhat’s Commonly Missed
Promotion within the same teamNew approval rights, admin scopes, or budget systems addedOld peer-level access rarely gets scoped down once someone outranks it
Lateral move to a new departmentNew department’s tools and data added; old department’s fully removedRemoval step is skipped almost every time — nobody in the new department knows what to revoke
Temporary project assignmentProject-scoped access added with a defined end dateAccess is granted without an expiry and simply never revisited after the project ends
Manager change (no role change)Approval chains and delegated access reassigned to the new managerFrequently not treated as a mover event at all, since the person’s job didn’t change
Office or region relocationData-residency-scoped systems and region-specific tools updatedOverlooked outside regulated industries, but material under frameworks with data-locality rules
Contractor-to-employee conversionContractor-scoped access replaced with full employee entitlements under a new identity recordOld contractor account is often left active “just in case” alongside the new one
Common Mover Trigger Events (and What Usually Gets Missed)

Signs Your JML Process Only Covers Joiners and Leavers

Most teams don’t realize their joiner-mover-leaver process has a mover-shaped hole in it until an access review or audit forces the question. A few reliable tells that it’s already happening:

  • Your onboarding and offboarding checklists are documented, but there’s no equivalent checklist for role changes or transfers.
  • Nobody can answer “does this person’s access still match their current job?” without manually checking each system by hand.
  • Access requests tied to a promotion or transfer go through IT, but access removal tied to the same event doesn’t — or isn’t tracked at all.
  • People who’ve been at the company for years, and moved roles more than once, consistently show up as the most over-permissioned accounts in every review.
  • “They probably still need it” is the default answer whenever someone questions a mover’s old access, rather than a documented reason.

Not sure how many “movers” your org is quietly carrying?[cite: 1]

Gart Solutions helps IT and security teams design and run a joiner-mover-leaver process that actually covers the mover stage — from HRIS-triggered access reviews to audit-ready evidence for SOC 2 and ISO 27001.[cite: 1]

10+ Years in DevOps & Cloud
50+ Enterprise clients secured
4.9★ Clutch rating
IT & Access Security Audit Identity & Access Management Compliance Audit (SOC 2 / ISO 27001) Infrastructure Consulting DevSecOps
Get a Mover-Access Audit →[cite: 1]

You might also like

Roman Burdiuzha

Roman Burdiuzha

Co-founder & CTO, Gart Solutions · Cloud Architecture Expert

Roman has 15+ years of experience in DevOps and cloud architecture, with prior leadership roles at SoftServe and lifecell Ukraine. He co-founded Gart Solutions, where he leads cloud transformation and infrastructure modernization engagements across Europe and North America. In one recent client engagement, Gart reduced infrastructure waste by 38% through consolidating idle resources and introducing usage-aware automation. Read more on Startup Weekly.

FAQ

What is the joiner-mover-leaver (JML) process?

The joiner-mover-leaver process is the identity lifecycle framework covering how access is granted when someone joins an organization, changed when their role or team changes (mover), and fully revoked when they leave (leaver). It's a named control in frameworks like ISO/IEC 27001:2022 (Annex A 5.16) and is typically what an auditor is checking when they ask about identity lifecycle management.

Why is "mover" the hardest part of the joiner-mover-leaver process?

Joiner and leaver both have a single clear trigger and a clean binary outcome — grant everything, or revoke everything. Mover has no single clean trigger (a promotion, transfer, project assignment, or manager change can all count) and requires a diff, not a binary action: adding what the new role needs while removing what the old one no longer justifies. The removal half is what most often gets skipped.

How often should mover access be reviewed?

Ideally, immediately at the moment a role change is recorded in the HRIS, not on a fixed calendar alone. In addition to event-triggered reviews, a recurring quarterly access review catches mover events that weren't recorded cleanly or were missed entirely — the same cadence recommended for access reviews generally.

What happens if a mover's old access isn't removed?

Access accumulates across every role the person has ever held, widening the blast radius if that account is ever compromised, creating segregation-of-duties violations when old approval rights overlap with new ones, and typically surfacing as a finding during a SOC 2 or ISO 27001 audit when reviewers compare actual entitlements against the org chart.

Who should own the mover step in access management?

Ownership works best split three ways: HR triggers the event when a role change is recorded, the new manager approves the incoming access, and the old manager or system owner confirms the outgoing access can be removed. Leaving the mover step solely to IT — without HR triggering it or a manager confirming removal — is the most common reason it gets skipped.

How is a mover different from a leaver in identity lifecycle management?

A leaver event ends in a single clean outcome: every credential revoked, everywhere, at once. A mover event doesn't have an equivalent clean endpoint — the person keeps working, just under a different role, so "success" means the access set matches the new job exactly, which requires actively comparing old and new entitlements rather than simply granting or revoking everything.

What tools help automate the mover step of the joiner-mover-leaver process?

HRIS-triggered provisioning workflows (including native identity governance features many Microsoft 365 E5 customers already own via Entra ID Governance), access review automation platforms, and identity governance and administration (IGA) tools can all trigger and enforce mover-specific reviews. The common requirement across all of them is that the tool must compare old and new entitlements, not just grant new access on top of what's already there.
arrow arrow

Thank you
for contacting us!

Please, check your email

arrow arrow

Thank you

You've been subscribed

We use cookies to enhance your browsing experience. By clicking "Accept," you consent to the use of cookies. To learn more, read our Privacy Policy