Joiner, mover, leaver is the name for everything that happens to a person's access between their first day and their last. It sounds like three processes. It works best as one, driven by one source of truth, with three events that each change access in a defined way.
Most teams handle joiners reasonably well, because a new hire who cannot log in complains. Leavers get attention because auditors test them. Movers, the people who change role, team, or manager, are where the process usually falls apart, and where access quietly accumulates for years.
This article covers how to structure the process, what each event needs, why movers are the weak point, where the process typically breaks, and what evidence each event should leave behind.
One process, three events
Each event has the same four parts:
A trigger. A change in the HR record: a hire with a start date, a change of role or department, a termination with an effective date.
A set of access changes. Derived from the role the person is entering or leaving, not decided ad hoc.
An approval. For anything beyond the role's defined access.
A record. Who changed what, when, and on whose authority.
The HR system is the right source of truth because it is where employment facts are recorded first and where the auditor will get the population. The identity provider is the right place to act, because group membership there drives access in every federated system. SSO as a compliance control explains why federation, on its own, does not finish the job in every application.
The roles themselves come from your role catalog. If you do not have one yet, least privilege in practice covers how to build it. Without defined roles, every joiner and mover becomes a judgment call, and judgment calls are hard to evidence.
Joiners: access approved before it exists
SOC 2 CC6.2 asks that users are registered and authorized before credentials are issued. ISO 27001:2022 Annex A 5.16 and 5.18 cover identity and access rights, and the people controls before them apply here too: 6.1 for screening before joining, and 6.2 for the terms and conditions of employment, which should state security responsibilities.
A joiner process that holds up:
The hire is recorded in HR with a role, a manager, and a start date.
Pre-start steps complete. Background checks where your policy and local law call for them, and a signed agreement covering security and confidentiality.
Birthright access is provisioned from the role, ideally automatically from the HR record through the identity provider.
Additional access goes through a request, approved by the system owner or manager, before it is granted.
First sign-in enforces MFA enrollment and policy acknowledgment.
Security awareness training is assigned with a due date.
Contractors need the same steps with one addition: an end date set when the account is created. A contractor account without an end date is the most likely account in your environment to outlive its purpose.
Movers: the event most processes miss
When someone changes role, they usually need new access. They rarely need to keep all of their old access. In practice, they get the new access, because they ask for it, and keep the old access, because nobody asks them to give it up. Repeat that over a few internal moves and you have an account with the combined permissions of four jobs.
NIST SP 800-53 Rev. 5 addresses this directly in PS-5 (personnel transfer), which asks you to review and confirm ongoing need for current access when someone is reassigned. ISO 27001:2022 Annex A 5.18 includes adjusting access rights on a change of role.
A mover process that works:
Trigger on the HR change. A change of title, department, or manager in the HR system creates a mover task. Manager-initiated emails are not a reliable trigger.
Grant the new role's access. From the role catalog, as for a joiner.
Set a transition window for the old access. People moving teams often need a few weeks to hand over. Agree the window and record it.
Remove the old role's access at the end of the window. Automatically where the identity provider allows it.
Ask the old manager to confirm that nothing else needs to be retained, and the new manager to confirm the new access is correct.
Leavers: the event auditors test hardest
Leaver handling is the most tested of the three, because the failure is the most visible: a former employee with live access. The standard to set, the removal runbook, and how auditors sample it are covered in offboarding that removes access the same day.
The point for this article is structural. If joiners and movers are driven from the HR record through the identity provider, the leaver event is the same mechanism run in reverse. Teams that build the leaver process separately, as a checklist owned by IT, tend to find it drifts from how access was granted in the first place.
Where the process breaks
The failures repeat across organizations of every size.
| Event | Common failure | What fixes it |
|---|---|---|
| Joiner | Access granted by copying another user | Provision from the role definition |
| Joiner | Approval recorded after access was granted | Grant only from an approved request |
| Mover | Old access never removed | HR-triggered task with a timed removal |
| Mover | Manager change not treated as a move | Trigger on manager and department fields |
| Leaver | HR tells IT late | Integration or automatic ticket from HR |
| Leaver | Contractor never offboarded | End date set at account creation |
| All | Non-federated apps handled from memory | Application inventory with an owner per app |
The last row is the one that undermines everything else. Every JML step that depends on someone remembering which apps a person had will eventually miss one.
A monthly reconciliation
The cheapest check on the whole process is a comparison you can run yourself. Once a month, export the list of active people from the HR system and the list of active accounts from the identity provider, and compare them. Every active account should belong to a current employee, a contractor with an unexpired end date, or a documented service account. Every current employee should have exactly one primary account.
Anything that does not match is either a JML failure or a gap in the HR record, and both are worth fixing before an auditor finds them. Keep each month's comparison and the fixes it produced. That record is evidence that the process is monitored, not only that it exists.
Evidence each event should leave
Auditors test joiners and leavers by sampling, and may also ask about movers. For each event, keep:
Joiners
- Not done:
HR record with role and start date
- Not done:
Approval for any access beyond the role, dated before the grant
- Not done:
Identity provider record of group assignments
- Not done:
Policy acknowledgment and training assignment
Movers
- Not done:
HR record of the change
- Not done:
Record of new access granted and old access removed, with dates
- Not done:
Manager confirmations
Leavers
- Not done:
HR termination record with effective date
- Not done:
Removal timestamps for each in-scope system
- Not done:
Device return or wipe record
For ISO 27001, these records support the access controls in Annex A 5.15 to 5.18 and the people controls in section 6 of Annex A.
How TrustLynce helps
TrustLynce continuous monitoring runs control checks against the HR, identity, and application systems you connect and routes failures to their owners. That surfaces gaps between the HR record and actual access while the period is running, rather than at sampling time.