Joiner-Mover-Leaver Pack — Guide
- Version 1.0
- Updated
- Next review
Joiner-Mover-Leaver & Access Provisioning
Joiners get noticed, because they cannot work without access. Leavers get noticed in the audit. Movers are not noticed at all: they collect their new role’s access, keep the old, and after a few moves can do things no single job should allow. This pack runs every start, move and exit from the HR record, gives each role a standard set of access, and checks each month that what should have gone has gone. No identity platform is needed.
Is this for you?
This pack is for you if:
- a manager’s email is enough to get someone an account;
- people who change jobs keep the access they had before;
- you could not say today which systems hold accounts outside single sign-on.
Seven events, each with a clock
| Event | Starts from | Target |
|---|---|---|
| Joiner | The HR record, at least 5 working days before the start date | Access ready on day one, and never switched on before it |
| Non-employee joiner | The sponsor register, with a sponsor and an end date | As a joiner; access ends by itself on the end date, 12 months ahead at most |
| Mover | The HR record, with the move date | New role’s access from the move date; the old role’s gone the same day, or within 5 working days where a handover is recorded |
| Leaver | The HR record, or the sponsor | All access gone by the end of the last working day, local accounts included |
| Urgent or hostile leaver | The decision by HR or the line manager | All access gone within 60 minutes, and before the person is told |
| Non-employee end date | The sponsor register | Access expires at the end of that day, whether or not anyone remembers |
| Long absence | The HR record, for more than 30 days | Accounts suspended from the first day, restored on return |
Standard access comes from role profiles, approved once and then granted without further approval. Anything else needs the line manager and the system owner, and expires within six months. Nobody approves their own access, and whoever makes a change never approves it. Before any grant, everything the person will hold, including what they kept from an earlier role, is checked against the segregation-of-duties conflict matrix.
The service desk resets a password or a lost second factor only after checking the caller independently. For a password, use a call back to the number in the HR record, the line manager’s confirmation, or photo identification in person. For a lost second factor, use photo identification in person, or both the call back and the manager’s confirmation. Privileged access follows the Privileged Access Standard of the privileged access pack.
How it runs in practice
Take a distributor with 900 staff that adopted this process in July; seven role profiles cover 701 of its staff. In September it had nine joiners, five movers and nine leavers, and the month-end check on 1 October found three things. A payments officer who moved from accounts payable on 7 September still held the supplier bank details role, so one person could change a supplier’s bank account and approve the payment. The role went on 2 October; the Financial Controller found no bank detail change since the move. A warehouse team leader’s local warehouse system account went four working days after their last day, because the task reached a shared mailbox. The pallet network portal’s first full user list showed two orphaned accounts, disabled the same day. Each went to the access review as a finding. A contractor whose project ended on 25 September lost access at the end of that day, with nobody having to remember.
Start with these three
- Access Control Policy: the principles, approvals and timings for every system.
- Role-Based Access Profile Matrix: standard access for each role, built from what people already hold.
- Leaver Access Removal Checklist: every account, credential, token and item to remove or recover.
Your first month
| When | What to do | You’re done when |
|---|---|---|
| Week 1 | Agree with HR that the HR record triggers every change, and start a sponsor register for non-employees. | No account can be created without a record. |
| Week 2 | List every system that holds accounts, including those outside single sign-on, using card spend and sign-in logs. | Each has an owner and a line on the leaver checklist. |
| Week 3 | Build profiles for your largest roles from the access people already hold and use. | The roles with the most people have an approved profile. |
| Week 4 | Compare every system’s accounts with the HR record and the sponsor register. | Every orphaned account is disabled and raised as a finding. |
What to report
Report these each month to the security and IT leadership team:
| Measure | Target |
|---|---|
| Leavers removed on time | All |
| Orphaned accounts found | Zero |
| Movers with residual access | Zero |
| Non-standard access past expiry | Zero |
Every late leaver, mover with residual access and orphaned account goes to the access review as a finding; a pattern goes to the process owner with a fix and a date. Fewer leavers and orphans found at each review campaign shows the process works.
Everything in the pack
| Document | What it does | Format |
|---|---|---|
| Access Control Policy | Principles, approvals and timings for every system | Word |
| Joiner-Mover-Leaver Operating Procedure | Triggers, steps, timings and evidence for each event | Word |
| Role-Based Access Profile Matrix | Standard access for each role | Excel |
| Access Request & Approval Form | Non-standard access, its reason, approvals and expiry | Word |
| Leaver Access Removal Checklist | Everything removed or recovered on exit | Excel |
| Access Provisioning Log | Every grant, change and removal, with who approved it | Excel |
| Identity Lifecycle Responsibility Matrix | Who does what, event by event | Excel |
| Leaver Timeliness & Orphaned Account Report | The monthly check and its four measures | Excel |
Adapting it
- Small organisation: one person may run the service desk and the monthly check, but never approves what they grant. Start with profiles for your largest two or three roles.
- Regulated entity: NIS2 Article 21(2)(i) names human resources security and access control policies. DORA Article 9(4)(c) limits access to what approved functions require, and Delegated Regulation (EU) 2024/1774 Article 20 asks for a lifecycle process for identities and accounts.
- IT run by an outside provider: the provider makes the changes; you decide and keep the record. Agree removal times that meet the leaver target, and confirm each removal in the system.
Where it maps
- ISO/IEC 27001:2022: Annex A 5.16.
- NIST CSF 2.0: PR.AA-01.
- NIS2: Article 21(2)(i).
- DORA: Article 9(4)(c).
What changed
Each change to this pack's documents since it was published, newest first.Changes across all packs
Rewritten to the depth of the other CISO Times packs: the principles, the lifecycle events and who approves access now come before the rules; every rule names its evidence; the timings are gathered in one table with the shortcuts the policy rules out; each role lists what it answers for and does; the measures, exceptions and conflicts of duties are explained; and a worked example of the first quarter is added.
- Access Control Policy 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: each lifecycle event now has numbered steps with who does them, when and what they leave behind, and a worked example from the month; the conflict check on a mover's whole access, role profiles, resets, systems outside single sign-on and the monthly reconciliation are explained step by step; timing targets, escalation and the evidence kept are added.
- Joiner-Mover-Leaver Operating Procedure 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: the base and seven role profiles with their system owners' approvals and review dates, a matrix view, a conflict check of every profile and every mover's resulting access (JML-06), and the method for building profiles with the example's coverage.
- Role-Based Access Profile Matrix 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: the form now comes with when to use it, who approves, the route a request takes, guidance for each field and the decision in order; each part's fields carry hints; and two worked requests, one granted and one capped by a contractor's end date, and a request the conflict check stops, are added.
- Access Request & Approval Form 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: one row per leaver with the removal deadline JML-09 sets, one row per required removal with its confirmation in the system (JML-14), the full checklist by group, the month's JMM-01 with the results by system, the late removal and what went to the access review, and a signature block.
- Leaver Access Removal Checklist 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: every lifecycle event with its source record, approvers, maker, the deadline it sets and whether it was met, a record check for JML-04, JML-05, JML-07 and JML-14, the live non-standard rights with JMM-04, the lifecycle events, approvals and evidence, and a Summary by event with the example's three late entries.
- Access Provisioning Log 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: the sixteen activities with accountable and responsible roles named by formula, role holders with deputies and duty counts, who answers for each step of each lifecycle event, and a separation check that no role both approves access and makes the change (JML-05, P02 SOD-IT-01).
- Identity Lifecycle Responsibility Matrix 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: the four measures with three months, target, tolerance, status in P11's words and direction, the summary for the leadership team, what went to the access review and where the measures go, and the leavers, movers and orphaned accounts behind the figures, each checked against JML-08, JML-09 and JML-15.
Published. The guide and eight documents, at 1.0.