Joiner-Mover-Leaver Operating Procedure
Defines the triggers, approvals, provisioning steps, timing targets and evidence for each identity lifecycle event.
Available soon
- Format
- Word
- Size
- 80 KB
- Length
- 29 pages
- Version
- 2.0
- Updated
What's inside
- Purpose
- Scope
- Roles
- Inputs and prerequisites
- The lifecycle events
- Who approves access
- Checking resulting access before a grant
- Building role profiles
- Password and sign-in resets
- Accounts outside single sign-on
- Monthly reconciliation
- Timing targets
- Escalation
- Records and evidence
- Worked example: what the September month end found
- Related documents
- Adapting this template
- Framework references
- Definitions
What changed
- 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.
- 1.0
Published.
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
Purpose
This procedure is the working routine behind the Access Control Policy. The policy states the rules JML-01 to JML-16; this procedure says who does what, in which order and by when, each time someone joins, moves, leaves or goes on a long absence, and each month when the records are checked against the systems.
It is written for the people who make the changes and the people who start them: HR, line managers, sponsors, the service desk and the administrators of systems with their own accounts. Each step names its owner, its time and what it leaves behind, so that a missed step shows up in the records and not in an incident.
Scope
This procedure covers:
- every lifecycle event in the HR record or the sponsor register, for employees and non-employees;
- every account those events touch: the directory account and single sign-on, every system connected to it, and every system with its own local accounts;
- password and second-factor resets by the service desk;
- finding systems outside single sign-on, and the monthly reconciliation of every in-scope system.
It does not cover privileged access. Privileged access, including administrator, emergency ("break-glass") and service accounts, follows the Privileged Access Standard of the Privileged Access Management pack. This pack sets no rule for it and puts no privileged access in a role profile. A leaver or mover who holds privileged access is handled by this pack's process, with the privileged steps the Privileged Access Standard sets. The Privileged Access Request, Elevation & Revocation Procedure of the Privileged Access Management pack sets the privileged steps a leaver or mover also needs. It does not cover the periodic review of access, which is the Access Review Campaign Operating Procedure of the User Access Review pack; this procedure hands its findings to that review.
Guidance — delete before approval
Each step's owner is a role. Write your own names, deputies and contact routes into the Identity Lifecycle Responsibility Matrix, so that a leaver on a Friday afternoon does not wait for one person.
Roles
Each role, what it does here, and the steps it takes part in. The Identity Lifecycle Responsibility Matrix sets who is responsible, accountable, consulted and informed for each activity.
Role | What they do in this procedure | Steps |
|---|---|---|
HR [[for joiner, mover and leaver data]] | Keeps the HR record, the only source of an employee's lifecycle events. | 1.1, 3.1, 4.1, 5.1, 7.1, 7.2, R2 |
Line manager [[each person's manager]] | Decides what their people need for the job, and tells HR at once of any change. | 1.2, 3.2, 3.3, 3.6, 4.6, 5.1, 5.4, 5.5, 7.2, 7.4 |
IT service desk [[internal service desk, or the managed IT provider's]] | Makes the changes the records call for, and never approves them. | 1.3, 1.4, 1.5, 1.6, 2.3, 2.4, 2.5, 2.6, 3.4, 3.5, 3.7, 4.2, 4.3, 4.4, 4.6, 4.7, 4.8, 5.2, 5.3, 5.4, 5.6, 6.1, 6.3, 6.5, 7.3, 7.5, R1, R2, R3, R4, R5, R6, R7 |
System owner [[the manager accountable for the system]] | Answers for who holds access to their system and what it lets them do. | R7 |
System administrator [[IT operations, or the supplier's support team]] | Makes changes in systems the service desk cannot reach. | 1.4, 2.3, 2.4, 3.5, 4.5, 4.8, 5.2, 6.3, 7.3, R1 |
Sponsor [[the line manager of the team a non-employee works for]] | Answers for the access of each non-employee they sponsor, from start to end date. | 2.1, 2.2, 4.1, 6.2, 6.4, 6.5 |
Process owner [[e.g. Head of IT, who owns the Access Control Policy]] | Owns this policy and the joiner-mover-leaver process, and answers for it working. | Decides escalations; receives process weaknesses |
Head of Information Security [[e.g. Head of Information Security]] | Checks that the process works, and reports where it does not. | 5.5, R8, R9 |
Campaign coordinator [[e.g. Information Security Manager]] | Runs the access review, and receives what the monthly check finds. | R8 |
The IT service desk and administrators make changes; line managers, sponsors and system owners approve them. Nobody does both for the same change (JML-05).
Inputs and prerequisites
Check each input before the first event is processed, and again whenever a system or profile changes.
Input | Check before starting | Held in |
|---|---|---|
HR event or sponsor register entry | The person, the event, its date, and the line manager or sponsor. Missing or wrong information is corrected at its source, never on the ticket. | HR record; sponsor register |
System inventory | Every system that holds accounts, with its owner, whether it uses single sign-on, and the named administrator for its local accounts. | [[System inventory]]; the profile matrix |
Role profiles | The current approved base and role profiles, with each system owner's approval. | Role-based access profile matrix |
Conflict matrix | The current version, to check resulting access before every grant. | Segregation of duties conflict matrix (P02) |
Approved non-standard requests | Both approvals, a business reason and an expiry, before anything outside a profile is granted. | Access request and approval form |
Leaver checklist | One line for each system with local accounts, each with a named administrator. | Leaver access removal checklist |
Provisioning log | Open to the service desk and administrators; one entry for every grant, change, suspension and removal. | Access provisioning log |
Systems and who makes the change
The service desk can reach every system connected to single sign-on through the directory. A system with its own accounts needs its named administrator for every grant and removal. (EXAMPLE)
System | Owner | Sign-in | Changes made by |
|---|---|---|---|
SYS-07 Directory and single sign-on (staff accounts) | Head of IT | Single sign-on | IT service desk |
SYS-06 Email and office apps (P06 SUP-005) | Head of IT | Single sign-on | IT service desk |
SYS-01 ERP (hosted; P06 SUP-004) | Chief Financial Officer | Single sign-on | ERP provider (P06 SUP-004), by service desk ticket, for roles inside the ERP |
SYS-02 Warehouse management system | Head of Logistics | Local accounts | Warehouse systems administrator |
SYS-05 Shared finance drive | Chief Financial Officer | Single sign-on | IT service desk (directory groups) |
SYS-08 Pallet network booking portal (P06 SUP-009) | Head of Logistics | Local accounts | Transport office administrator |
SYS-10 Freight rate comparison site | Head of Logistics | Local accounts | Transport office administrator |
Three of the 7 systems hold local accounts: SYS-02 warehouse management system, SYS-08 pallet network booking portal (P06 SUP-009) and SYS-10 freight rate comparison site. Each has a named line on the leaver checklist. Privileged systems (P14) are not listed. (EXAMPLE)
The lifecycle events
Every change starts from one of seven events (JML-01). Steps are numbered by event: 3.4 is the fourth step for a mover.
Event | Source | Target | Rules |
|---|---|---|---|
1. Joiner (employee) | HR record | Accounts created disabled no earlier than [[5]] working days before the start date, base and role profile ready, enabled on the start date. | JML-01, JML-03, JML-07 |
2. Joiner (non-employee) | Sponsor register | As an employee joiner; the account expires automatically at the end date, no more than [[12]] months ahead. | JML-01, JML-07, JML-10 |
3. Mover | HR record | New role's profile from the move date; old role's access removed on the move date, or within [[5]] working days where a handover is recorded. | JML-03, JML-06, JML-08 |
4. Leaver | HR record or sponsor register | All access removed by the end of the last working day; equipment and tokens recovered the same day. | JML-09 |
5. Urgent or hostile leaver | HR record | All access removed within [[60]] minutes of the decision, and before the person is told. | JML-09 |
6. Non-employee end date | Sponsor register | The account expires automatically at the end of the end date; an early end is a leaver the same day. | JML-10 |
7. Long absence | HR record | Accounts suspended from the first day of the absence; restored on the day of return, once the line manager confirms it. | JML-11 |
Joiner (employee)
Trigger: HR record: HR records the start date, job, department and line manager. Target: accounts created disabled no earlier than [[5]] working days before the start date, base and role profile ready, enabled on the start date.
JML-01 Every employee's account is created, changed, suspended and removed only from an event in the HR record, and every non-employee's only from the sponsor register. No account is created on a manager's request alone, and no account exists without a record in one or the other.
JML-03 Joiners and movers receive the base profile and their role profile without further approval. Each role profile has a named owner, is approved by the owner of every system in it, never contains a segregation-of-duties conflict or privileged access, and is reviewed every [[12]] months and after a reorganisation or a new core system.
JML-07 HR records a joiner at least [[5]] working days before the start date. Accounts are created disabled no earlier than [[5]] working days before it and enabled on the start date, never before. The first password or sign-in set-up is given only to the joiner, in person or through a channel checked against the HR record.
Steps:
Step | What to do | Who | When | Output |
|---|---|---|---|---|
1.1 | Record the joiner: start date, job, department and line manager (JML-01). | HR | At least [[5]] working days before the start date | HR record entry, with its date |
1.2 | Confirm which role profile the job needs. A job with no profile gets the base profile only; anything else is requested as non-standard access on the access request form (JML-03, JML-04). | Line manager | On receiving HR's notice | Profile named in the ticket |
1.3 | List the joiner's resulting access, the base profile and the role profile, and check it against the conflict matrix. A profile never holds a conflict, so a conflict here means the profile or the request is wrong: stop and ask the profile owner (JML-06). | IT service desk | Before any account is created | Check recorded on the ticket |
1.4 | Create the accounts, disabled: the directory account with the base and role profile groups, and every local account the profile needs, by ticket to the named administrator of each system (JML-07). | IT service desk; System administrator | No earlier than [[5]] working days before the start date | Accounts created and disabled |
1.5 | Enable the accounts on the start date. Give the first password or sign-in set-up only to the joiner, in person or through a channel checked against the HR record. The joiner enrols their own second factor (JML-07). | IT service desk | On the start date, never before | Joiner signed in; factor enrolled by the joiner |
1.6 | Log every grant with the request reference, the profile as the approval, who made it and when (JML-14). | IT service desk | The same day | Provisioning log entries |
EXAMPLE: the employee joiners of September 2026. Notice is working days from HR's record to the start date (at least [[5]]); created is working days before the start (no more than [[5]]).
Joiner | Role profile | Recorded | Start | Notice | Created | Enabled | JML-07 |
|---|---|---|---|---|---|---|---|
J-01 | RP-01 Warehouse operative | 21 Aug 2026 | 1 Sep 2026 | 7 | 5 before | 1 Sep 2026 | Met |
J-02 | RP-01 Warehouse operative | 21 Aug 2026 | 1 Sep 2026 | 7 | 5 before | 1 Sep 2026 | Met |
J-03 | RP-01 Warehouse operative | 28 Aug 2026 | 7 Sep 2026 | 6 | 5 before | 7 Sep 2026 | Met |
J-04 | RP-03 Customer service agent | 27 Aug 2026 | 7 Sep 2026 | 7 | 4 before | 7 Sep 2026 | Met |
J-05 | RP-06 Sales account manager | 3 Sep 2026 | 14 Sep 2026 | 7 | 4 before | 14 Sep 2026 | Met |
J-06 | RP-01 Warehouse operative | 17 Sep 2026 | 21 Sep 2026 | 2 | 2 before | 22 Sep 2026 | Not met |
J-07 | RP-07 Transport planner | 15 Sep 2026 | 28 Sep 2026 | 9 | 5 before | 28 Sep 2026 | Met |
J-04 shows the rule working: HR recorded the joiner on 27 Aug 2026, 7 working days ahead; the accounts were created disabled on 1 Sep 2026, 4 working days before the start, and enabled on 7 Sep 2026. J-06 did not: HR recorded the joiner two working days before the start date; the handheld account was ready on the second day. The service desk created the accounts the day the record arrived and enabled them as soon as they were ready, never before the start date. The late notice went to the process owner. (EXAMPLE)
Guidance — delete before approval
Agree with HR how a new start reaches the service desk. A start recorded late is the commonest reason a joiner borrows a colleague's account on day one, which breaks JML-02.
Joiner (non-employee)
Trigger: Sponsor register: the sponsor records the person, the reason and the end date. Target: as an employee joiner; the account expires automatically at the end date, no more than [[12]] months ahead. Rules: JML-01 and JML-07, quoted above, and:
JML-10 Every non-employee has a sponsor and an end date, recorded in the sponsor register before the account is created and no more than [[12]] months after the start. The account expires automatically at the end of that date. The sponsor is reminded [[10]] working days before, and only the sponsor can extend it, with a new end date. An engagement that ends early is a leaver the same day.
Steps:
Step | What to do | Who | When | Output |
|---|---|---|---|---|
2.1 | Record the non-employee in the sponsor register: who they are, who sponsors them, why, and the end date (JML-10). | Sponsor | Before any account is created; the end date no more than [[12]] months after the start | Sponsor register entry |
2.2 | Confirm the profile, or request the access needed as non-standard with an expiry no later than the end date (JML-03, JML-04). | Sponsor | With the register entry | Profile named, or approved request |
2.3 | Check the resulting access against the conflict matrix, then create the accounts disabled, as for an employee joiner (JML-06, JML-07). | IT service desk; System administrator | No earlier than [[5]] working days before the start date | Accounts created and disabled |
2.4 | Set every account to expire at the end of the end date: the directory account, and each local account whose system can expire accounts. Where a system cannot, put the end date on that system's line of the leaver checklist (JML-10). | IT service desk; System administrator | When the accounts are created | Expiry set and recorded |
2.5 | Enable the accounts on the start date and hand over the first sign-in as for an employee (JML-07). | IT service desk | On the start date, never before | Non-employee signed in |
2.6 | Log every grant, with the end date (JML-14). | IT service desk | The same day | Provisioning log entries |
EXAMPLE: the non-employee joiners of September 2026.
Joiner | Kind | Sponsor | Start | End date | Latest allowed | Access |
|---|---|---|---|---|---|---|
J-08 | Agency worker | Warehouse 1 manager | 14 Sep 2026 | 18 Dec 2026 | 14 Sep 2027 | RP-01 Warehouse operative |
J-09 | Contractor | Head of Logistics | 21 Sep 2026 | 29 Jan 2027 | 21 Sep 2027 | Base profile, and NS-2026-033 (SYS-01: Stock and purchasing reports (read)), expiring 29 Jan 2027 |
Both end dates are within [[12]] months of the start, the latest JML-10 allows. J-09's non-standard right expires on the end date itself, because JML-04 never lets non-standard access outlast the engagement. (EXAMPLE)
Mover
Trigger: HR record: HR records a new job, department or line manager, with the move date. Target: new role's profile from the move date; old role's access removed on the move date, or within [[5]] working days where a handover is recorded. Rules: JML-03, quoted above, and:
JML-06 Before any access right is granted or changed, the person granting it checks the person's resulting access, everything they will hold after the change including what they still hold from an earlier role, against the Segregation of Duties Conflict Matrix (P02 SD-03). A grant that would create a conflict is not made unless it has been accepted under P02 SD-04.
JML-08 A mover receives the new role's profile from the move date. The old role's access is removed on the move date or, where the old line manager records a handover, no later than [[5]] working days after it. Access still needed after that is requested as non-standard (JML-04).
Steps:
Step | What to do | Who | When | Output |
|---|---|---|---|---|
3.1 | Record the move: new job, department or line manager, and the move date (JML-01). | HR | As soon as the move is agreed, and before the move date | HR record entry |
3.2 | Record any handover: which old access is needed, and until when, no later than [[5]] working days after the move date (JML-08). | Line manager | Before the move date | Handover note on the ticket, or none |
3.3 | Confirm the new role profile (JML-03). | Line manager | Before the move date | Profile named in the ticket |
3.4 | List the mover's resulting access: the base profile, the new role profile and everything they still hold, from the provisioning log and each system. Check all of it against the conflict matrix, not only the new profile (JML-06). | IT service desk | Before anything is granted | Resulting access and check recorded |
3.5 | Replace the old profile with the new one: grant the new profile from the move date, and remove the old role's access that the new profile does not include (JML-08). | IT service desk; System administrator | On the move date; with a recorded handover, by the end of the handover window, no later than [[5]] working days after it | Old access removed, new access granted |
3.6 | Request anything still needed after the window as non-standard access, with both approvals and an expiry (JML-04). | Line manager | Before the window closes | Approved request, or the access removed |
3.7 | Confirm each removal in the system, then log it as complete (JML-14). | IT service desk | The same day as the removal | Provisioning log entries |
EXAMPLE: the movers of September 2026. The window ends on the move date unless the old line manager recorded a handover.
Mover | From | To | Move date | Handover | Window ends | Old access removed | JML-08 |
|---|---|---|---|---|---|---|---|
M-01 | RP-04 Accounts payable clerk | RP-05 Payments officer | 7 Sep 2026 | No | 7 Sep 2026 | 2 Oct 2026 | Residual access |
M-02 | RP-01 Warehouse operative | RP-02 Warehouse team leader | 1 Sep 2026 | No | 1 Sep 2026 | 1 Sep 2026 | Met |
M-03 | RP-03 Customer service agent | RP-06 Sales account manager | 14 Sep 2026 | Yes | 21 Sep 2026 | 18 Sep 2026 | Met |
M-04 | RP-07 Transport planner | RP-02 Warehouse team leader | 21 Sep 2026 | No | 21 Sep 2026 | 21 Sep 2026 | Met |
M-05 | RP-02 Warehouse team leader | RP-07 Transport planner | 28 Sep 2026 | No | 28 Sep 2026 | 28 Sep 2026 | Met |
M-03 recorded a handover, so the old access could stay until 21 Sep 2026, 5 working days after the move; it went on 18 Sep 2026. M-01 recorded none, so the window closed on the move date, 7 Sep 2026. The new profile was granted and the old one never removed: the mover request added the new profile and did not remove the old one, and the conflict check looked only at the new profile. The worked example at the end of this procedure follows the case through. (EXAMPLE)
Guidance — delete before approval
Make the mover request replace the old profile by default. A request that only adds access leaves the old role in place unless someone remembers to remove it, and nobody does.
Leaver
Trigger: HR record or sponsor register: HR records the last working day, or the sponsor ends the engagement. Target: all access removed by the end of the last working day; equipment and tokens recovered the same day.
JML-09 A leaver's access is removed from every system, including local accounts outside single sign-on, by the end of their last working day. For an urgent leaver it is removed within [[60]] minutes of the decision, and before the person is told. Equipment, badges, tokens and shared credentials are recovered or changed the same day, using the leaver checklist. Removed accounts are deleted after [[90]] days, once their data has been dealt with.
Steps:
Step | What to do | Who | When | Output |
|---|---|---|---|---|
4.1 | Record the last working day, and the contractual end date where later. For a non-employee the sponsor ends the engagement in the sponsor register (JML-01). | HR; Sponsor | As soon as the leaving date is known | HR record or sponsor register entry |
4.2 | Open the leaver checklist with one line per system the person's profile and non-standard access reach, local accounts included, and the equipment, badges, tokens and shared credentials they hold (JML-09, JML-12). | IT service desk | On receiving the record | Leaver checklist opened |
4.3 | Assign each local-account line to the named administrator of that system, never to a shared mailbox. | IT service desk | The same day | Each line assigned to a person |
4.4 | Disable the directory account, end its sessions on every device and remove it from its groups. Convert or delegate the mailbox to the line manager and remove forwarding rules (JML-09). | IT service desk | By the end of the last working day | Directory account disabled |
4.5 | Remove every local account on the checklist (JML-09). | System administrator | By the end of the last working day | Local accounts removed |
4.6 | Recover the laptop, phone, security token, badge and keys, or wipe devices remotely; change any shared password, safe code or alarm code the person knew (JML-09). | Line manager; IT service desk | The same day | Items recovered; credentials changed |
4.7 | Confirm each removal in the system and record its time on the checklist and in the provisioning log. A removal counts only when it is confirmed (JML-14). | IT service desk | The same day | Checklist complete, with times |
4.8 | Delete the removed accounts once their data has been dealt with (JML-09). | IT service desk; System administrator | After [[90]] days | Accounts deleted; log updated |
EXAMPLE: the planned leavers of September 2026. Each removal is the time it was confirmed in the system; a removal after the last working day is late.
Leaver | Role profile | Last day | Removals needed | Removed | JML-09 |
|---|---|---|---|---|---|
L-01 | RP-01 Warehouse operative | 4 Sep 2026 | SYS-07, SYS-02 | SYS-07 17:00 SYS-02 16:30 | Met |
L-02 | RP-02 Warehouse team leader | 11 Sep 2026 | SYS-07, SYS-02, SYS-08 | SYS-07 17:30 SYS-02 17 Sep 2026, 10:20 SYS-08 17:35 | Late on SYS-02 |
L-03 | RP-03 Customer service agent | 11 Sep 2026 | SYS-07 | SYS-07 17:15 | Met |
L-04 | RP-01 Warehouse operative | 18 Sep 2026 | SYS-07, SYS-02 | SYS-07 17:05 SYS-02 16:40 | Met |
L-08 | RP-01 Warehouse operative | 25 Sep 2026 | SYS-07, SYS-02 | SYS-07 17:20 SYS-02 16:55 | Met |
L-09 | RP-07 Transport planner | 30 Sep 2026 | SYS-07, SYS-02, SYS-08, SYS-10 | SYS-07 17:40 SYS-02 17:45 SYS-08 17:50 SYS-10 17:55 | Met |
L-02's directory account went on time, but the local warehouse system account was removed on 17 Sep 2026, 10:20, four working days late. The warehouse system removal task went to a shared site mailbox, not to the named administrator. The warehouse system's log shows no sign-in to the account after the last working day, and the badge was recovered on the day. (EXAMPLE)
Guidance — delete before approval
The directory account is the easy part. The leaver checklist exists for the systems single sign-on does not reach: list each one, with the person who removes its accounts.
Urgent or hostile leaver
Trigger: HR record: HR or the line manager decides the person leaves now, or is suspended. Target: all access removed within [[60]] minutes of the decision, and before the person is told. Rules: JML-09, quoted above.
Steps:
Step | What to do | Who | When | Output |
|---|---|---|---|---|
5.1 | Decide that the person leaves now, or is suspended, and tell the service desk before telling the person. Agree the time the person will be told (JML-09). | HR; Line manager | At the decision | Decision time recorded |
5.2 | Disable the directory account and end every session and token, and call the named administrator of each local-account system to remove those accounts at once. Disable; do not delete: the accounts may be evidence (JML-09). | IT service desk; System administrator | Within [[60]] minutes of the decision, and before the person is told | Every account disabled, with times |
5.3 | Confirm to HR that every account on the checklist is disabled. Only then is the person told. | IT service desk | Before the agreed time | Confirmation to HR |
5.4 | Recover equipment, badges and tokens at the meeting, and change shared credentials the person knew (JML-09). | Line manager; IT service desk | The same day | Items recovered; credentials changed |
5.5 | If misuse is suspected, keep the accounts and their logs unchanged, and report it as a security incident. | Line manager; Head of Information Security | At once | Incident reference, or none |
5.6 | Complete the leaver checklist as for any leaver. | IT service desk | The same day | Checklist complete, with times |
EXAMPLE: L-05, a sales account manager, on 23 Sep 2026.
Time | What happened | Against the procedure |
|---|---|---|
09:00 | HR decides the person leaves today and tells the service desk. | Step 5.1 |
09:35 | Every account disabled (SYS-07), sessions ended. | 35 minutes after the decision (limit [[60]]) |
10:00 | The person is told. Laptop, phone and badge recovered at the meeting. | 25 minutes after the last account was disabled |
Guidance — delete before approval
Agree a code word or a standard ticket type HR uses for an urgent leaver, so the service desk acts at once without asking why. The reason stays with HR.
Non-employee end date
Trigger: Sponsor register: the recorded end date arrives, or the sponsor ends the engagement early. Target: the account expires automatically at the end of the end date; an early end is a leaver the same day. Rules: JML-10, quoted above.
Steps:
Step | What to do | Who | When | Output |
|---|---|---|---|---|
6.1 | Remind the sponsor of the end date (JML-10). | IT service desk | [[10]] working days before the end date | Reminder sent |
6.2 | Decide: let the engagement end, or extend it with a new end date in the sponsor register, no more than [[12]] months ahead. Non-standard access is renewed only with the same approvals as the original request (JML-04, JML-10). | Sponsor | Before the end date | End confirmed, or new end date recorded |
6.3 | Let the accounts expire at the end of the end date. Remove the local accounts whose systems cannot expire them, from the leaver checklist (JML-09, JML-10). | IT service desk; System administrator | At the end of the end date | Accounts expired or removed, with times |
6.4 | If the engagement ends early, record the new end in the sponsor register; the person is a leaver that day (JML-10). | Sponsor | The day it ends | Register updated; leaver steps started |
6.5 | Recover equipment and badges, and complete the leaver checklist (JML-09). | Sponsor; IT service desk | The same day | Checklist complete |
EXAMPLE: non-employees whose recorded end date arrived in September 2026.
Leaver | Kind | Sponsor | End date | Removed | What happened |
|---|---|---|---|---|---|
L-06 | Agency worker | Warehouse 1 manager | 18 Sep 2026 | SYS-07 23:59 SYS-02 17:10 | The directory account expired automatically at the end date recorded at joining. |
L-07 | Contractor | Head of Logistics | 25 Sep 2026 | SYS-07 23:59 | The project ended on its recorded date without anyone telling HR or the service desk. The account expired automatically at the end of the day. |
For L-07, nobody told HR or the service desk, and it did not matter: the end date recorded at joining ended the access. That is what JML-10 is for. (EXAMPLE)
Long absence
Trigger: HR record: HR records an absence expected to last more than [[30]] days. Target: accounts suspended from the first day of the absence; restored on the day of return, once the line manager confirms it.
JML-11 The accounts of a person on a long absence (more than [[30]] days) are suspended from the first day of the absence, and restored on the day they return once the line manager confirms it. HR and the line manager may record a reason to keep a named access right during the absence.
Steps:
Step | What to do | Who | When | Output |
|---|---|---|---|---|
7.1 | Record the absence: first day and expected return, where it is expected to last more than [[30]] days (JML-11). | HR | Before the first day, or as soon as it is known | HR record entry |
7.2 | Record any named access right to keep during the absence, with the reason (JML-11). | HR; Line manager | Before the first day | Reason recorded, or none |
7.3 | Suspend the accounts: disable sign-in, and keep the accounts and their rights so they can be restored (JML-11). | IT service desk; System administrator | From the first day of the absence | Accounts suspended |
7.4 | On return, confirm the person is back in the same job. A different job is a move: follow the mover steps instead (JML-08, JML-11). | Line manager | On the day of return | Return confirmed |
7.5 | Restore the accounts and log the suspension and restoration (JML-11, JML-14). | IT service desk | On the day of return | Accounts restored; log entries |
EXAMPLE: A-01, a warehouse team leader, began parental leave on 14 Sep 2026, expected back on 15 Mar 2027. The accounts were suspended on 14 Sep 2026, the first day, and will be restored on the day of return once the line manager confirms it. (EXAMPLE)
Who approves access
Profile access needs no approval beyond the HR record (JML-03). Non-standard access, its renewal and a non-employee's extension are approved on the Access Request & Approval Form by the line manager or sponsor and the owner of the system or data, before anything is granted (JML-04). Access that would create a conflict is not granted unless it is accepted as an exception under P02 SD-04 (JML-06). Privileged, emergency and service account access follows the Privileged Access Request, Elevation & Revocation Procedure (JML-16). The Access Control Policy sets out every approval in full.
Checking resulting access before a grant
Before any access right is granted or changed, the person granting it checks the person's resulting access, everything they will hold after the change including what they still hold from an earlier role, against the Segregation of Duties Conflict Matrix (P02 SD-03). A grant that would create a conflict is not made unless it has been accepted under P02 SD-04. Resulting access means everything the person will hold after the change: the base profile, the new profile, any non-standard access, and whatever they still hold from an earlier role. Checking only what is being added is the mistake that lets a mover hold both sides of a conflict.
How to check:
Step | What to do | Who | When | Output |
|---|---|---|---|---|
C1 | List what the person holds now in every system, from the provisioning log and the system itself. | IT service desk | Before any grant | Current access list |
C2 | Add what the change grants, and strike out what it removes. | IT service desk | Before any grant | Resulting access list |
C3 | Check every pair of rights in the list against the Segregation of Duties Conflict Matrix. | IT service desk | Before any grant | Check recorded, with the matrix version |
C4 | No conflict: grant. A conflict: stop, and tell the line manager and the system owner. | IT service desk | At once | Grant, or the request stopped |
C5 | Separate the conflict by removing one of the two rights. Only a conflict that cannot be separated goes to P02 SD-04 as an exception. | System owner; Line manager | Before the grant | Right removed, or an approved exception |
EXAMPLE: M-01's resulting access on 7 Sep 2026, had the conflict check covered it. The two rights marked are the two duties of SOD-FI-01, rated High: "create or change suppliers and their bank details in the finance system" and "approve payments".
Access right | Where it comes from | Conflict |
|---|---|---|
SYS-07: Staff account and single sign-on | Base profile | |
SYS-06: Mailbox and office apps | Base profile | |
SYS-01: Payment run approval | New profile RP-05 | SOD-FI-01 |
SYS-05: Treasury folder | New profile RP-05 | |
SYS-01: Supplier invoice entry | Left over from RP-04 | |
SYS-01: Supplier master data, including bank details | Left over from RP-04 | SOD-FI-01 |
SYS-05: Accounts payable folder | Left over from RP-04 |
The new profile alone has no conflict, and neither has the old one: the conflict exists only in what the person holds after the move. Mover requests now replace the old profile by default (JML-08), and the conflict check covers the person's resulting access (JML-06). (EXAMPLE)
Building role profiles
Joiners and movers receive the base profile and their role profile without further approval. Each role profile has a named owner, is approved by the owner of every system in it, never contains a segregation-of-duties conflict or privileged access, and is reviewed every [[12]] months and after a reorganisation or a new core system. Build profiles from the access people already hold, without a role-mining project:
Step | Method |
|---|---|
P1 | List job roles from the HR record by the number of people in each. Start with the largest: a handful of roles usually covers most staff. |
P2 | For each role, take an extract of who holds what in each system and keep only the access that at least [[80%]] of the people in the role hold and have used in the last [[90]] days. |
P3 | Ask the owner of each system to strike out anything the role does not need for the job, in P07's sense of needed. |
P4 | Check the profile against the Segregation of Duties Conflict Matrix. A profile never contains both duties of a conflict (JML-03). |
P5 | Leave out privileged access. It follows the privileged access pack's Standard (JML-16). |
P6 | Name the profile owner, normally the head of the department that holds the role, and record each system owner's approval. |
P7 | Everything else a person in the role holds is non-standard: it gets an approval and an expiry (JML-04), or it is removed. |
P8 | Review each profile every [[12]] months. Non-standard access that most of a role has held for a year is a candidate to join the profile. |
EXAMPLE: the base profile and the seven role profiles, with the people in each role at 30 Sep 2026.
Profile | Owner | People | Access |
|---|---|---|---|
BP-00 Base profile | Head of IT | Everyone | SYS-07: Staff account and single sign-on SYS-06: Mailbox and office apps |
RP-01 Warehouse operative | Head of Logistics | 520 | SYS-02: Picker (handheld) |
RP-02 Warehouse team leader | Head of Logistics | 48 | SYS-02: Team leader: pick lists and stock moves SYS-08: Booking user |
RP-03 Customer service agent | Chief Operating Officer | 60 | SYS-01: Order entry and customer enquiry |
RP-04 Accounts payable clerk | Chief Financial Officer | 8 | SYS-01: Supplier invoice entry SYS-01: Supplier master data, including bank details SYS-05: Accounts payable folder |
RP-05 Payments officer | Chief Financial Officer | 3 | SYS-01: Payment run approval SYS-05: Treasury folder |
RP-06 Sales account manager | Sales Director | 40 | SYS-01: Customer accounts and price lists (read) SYS-01: Sales orders |
RP-07 Transport planner | Head of Logistics | 22 | SYS-02: Dispatch planning SYS-08: Booking user SYS-10: Rate search user |
The seven profiles cover 701 of about 900 staff (78%). Accounts payable clerk (RP-04) and payments officer (RP-05) are separate profiles because together they would hold both duties of SOD-FI-01. No profile holds privileged access (JML-16). (EXAMPLE)
Guidance — delete before approval
Start with the largest roles. Seven profiles covering about four in five staff is a good first year; the rest can stay on the base profile with non-standard access until a pattern shows.
Password and sign-in resets
The service desk resets a password or a multi-factor authentication factor only after checking the caller's identity independently of the call, by one of the identity checks below. Information the caller gives is never enough on its own. The person is told of every reset through a second channel. Resets of privileged accounts follow the Privileged Access Standard.
Reset identity checks
The service desk uses one of these checks, started by the service desk and never by the caller.
Check | How |
|---|---|
VM-01 Call back | End the call and call the person back on the number in the HR record, never on a number the caller gives. |
VM-02 Line manager confirms | Contact the person's line manager, as the HR record names them, through a channel the service desk starts, and have them confirm the request. |
VM-03 In person | The person comes to the service desk or a named site contact with photo identification, checked against the HR record. |
Never enough on its own: details a caller can know or find out: name, staff number, date of birth, manager's name, or an email sent from the account being reset.
Password and factor resets
Which check each reset needs:
Request | Required check |
|---|---|
Password, where the person's second factor still works | Self-service reset with the second factor. No call to the service desk is needed. |
Password, where self-service is not possible | One of VM-01, VM-02 or VM-03. |
Multi-factor authentication factor lost or replaced | VM-03, or VM-01 and VM-02 together. The new factor is enrolled by the person, never by the service desk on their behalf. |
Any reset of a privileged account | As the Privileged Access Standard sets. |
After a reset
- Tell the person through a second channel: their manager, or the contact details in the HR record.
- Check the account's recent sign-ins and mail rules for anything the person does not recognise.
- Record the check used, who made it and when in the ticket.
EXAMPLE: in September 2026 the service desk made 46 resets: 31 after VM-01 (call back), 9 after VM-02 (line manager confirms) and 6 after VM-03 (in person). 14 were second-factor resets. None was refused. Privileged resets are counted under the Privileged Access Management pack. (EXAMPLE)
Guidance — delete before approval
Callers who impersonate staff to get a password reset are a common way into an organisation. A service desk that always calls back on the number in the HR record defeats most of them; a service desk that accepts a date of birth defeats none.
Accounts outside single sign-on
Every system that holds accounts, including software bought with a card or signed up to with a work email address, is in the system inventory with an owner. Discovery runs every [[3]] months from card and expense spend, single sign-on and app-consent logs and the supplier register. Each system found is connected to single sign-on, or kept with its local accounts listed on the leaver checklist and in the reconciliation, or closed.
Discovering local accounts
Every [[3]] months, look in these places for systems nobody listed:
Source | What it reveals |
|---|---|
Card and expense spend | Software bought on a company card or claimed as an expense. |
Single sign-on and app-consent logs | Apps people signed in to, or granted access to, with their work account. |
Supplier register | Supplier portals and services with their own user accounts. |
Line managers, at the annual profile review | Tools their teams use that no list shows. |
Discovery decisions
Each system found gets one of three outcomes, decided with its owner:
Outcome | When it applies |
|---|---|
Connect to single sign-on | The system supports it. Its accounts then end when the directory account ends. |
Keep outside single sign-on | It cannot be connected and is needed. It gets an owner, its local accounts get a named line on the leaver checklist, and it joins the monthly reconciliation. |
Close | It is not needed, or duplicates an approved system. Data is exported or deleted and the accounts are closed. |
EXAMPLE: the discovery of 15 Sep 2026.
Found | System | Source | Outcome |
|---|---|---|---|
APP-01 | Design tool (Marketing) | Card and expense spend | Connect to single sign-on |
APP-02 | Freight rate comparison site (Logistics) | Card and expense spend | Keep outside single sign-on; now SYS-10, with a line on the leaver checklist |
APP-03 | Online survey tool (Customer service) | Card and expense spend | Close |
APP-04 | E-signature service (Finance) | Single sign-on and app-consent logs | Connect to single sign-on |
After connecting to single sign-on
Test removal with an approved test identity before treating the system as covered by the directory:
Test | Passes when |
|---|---|
Disable an approved test identity in the directory | Its next sign-in to the system is refused. |
End the test identity's sessions | An open session in the system ends, or ends within the session lifetime the system owner accepts. A blocked new sign-in does not prove this. |
Wait for the token lifetime | Any token or remembered device the system issued stops working. |
Look for local accounts left behind | Accounts created before the connection are removed or linked to single sign-on. |
Monthly reconciliation
Within [[3]] working days of each month end, every in-scope system's accounts are reconciled with the HR record and the sponsor register. An orphaned account is disabled within [[1]] working day of being found. Every late leaver, mover with residual access and orphaned account is raised as a finding with the access review coordinator (P07 AR-08), and a pattern goes to the process owner as a process weakness (P07 AR-11).
Step | What to do | Who | When | Output |
|---|---|---|---|---|
R1 | Take a complete account extract from every in-scope system, local and shared accounts included, as at the month end. | IT service desk; System administrator | First working day after month end | One extract per system, dated |
R2 | Take the HR record and the sponsor register as at the month end, with leavers, movers and absences in the month. | HR; IT service desk | First working day after month end | People list, dated |
R3 | Match every account to a current person or a named owner. List every account that matches nobody, and every shared account with no named owner. | IT service desk | Within the reconciliation time | Orphaned accounts listed |
R4 | For each leaver in the month, compare every removal time on the leaver checklist with the last working day. | IT service desk | Within the reconciliation time | Late leavers listed |
R5 | For each mover whose window closed in the month, check that the old role's access is gone from every system. | IT service desk | Within the reconciliation time | Movers with residual access listed |
R6 | List non-standard access past its expiry, neither removed nor renewed. | IT service desk | Within the reconciliation time | Expired access listed |
R7 | Disable each orphaned account, and ask the system owner to name an owner or confirm deletion. | IT service desk; System owner | Within [[1]] working day of finding it | Accounts disabled, with times |
R8 | Raise each late leaver, mover with residual access and orphaned account as a finding with the access review coordinator, and send any pattern to the process owner as a process weakness. | Head of Information Security; Campaign coordinator | With the report | Findings and weaknesses raised |
R9 | Report the four measures and the findings. | Head of Information Security | Within [[3]] working days of month end | Monthly report |
A system whose extract did not arrive is recorded as not reconciled. It is incomplete coverage, never a month with no findings.
Every late leaver, mover with residual access and orphaned account found is raised with the access review coordinator as a finding (P07 AR-08); a pattern is a process weakness (P07 AR-11). Between campaigns, this report finds what P07's ARM-03 ("Access that should not have existed") would otherwise find at the next campaign, so ARM-03 falling campaign on campaign is the evidence that this process works.
EXAMPLE: the reconciliation as at 30 Sep 2026, run on 1 Oct 2026, found two orphaned accounts:
Account | System | Last sign-in | Found | Disabled |
|---|---|---|---|---|
O-01: Personal account of a transport planner who left on 26 Jun 2026, before the process was adopted | SYS-08 Pallet network booking portal (P06 SUP-009) | 25 Jun 2026 | 1 Oct 2026 | 1 Oct 2026 |
O-02: Shared bookings account for Warehouse 2, set up by a former team leader, with no named owner. Replaced by personal booking accounts for the two team leaders who used it (JML-02). | SYS-08 Pallet network booking portal (P06 SUP-009) | 29 Sep 2026 | 1 Oct 2026 | 1 Oct 2026 |
What went to the access review:
Item | Raised as | Detail |
|---|---|---|
Mover M-01 | Finding (P07 AR-08) | Residual access and a High conflict (P02 SOD-FI-01), separated on 2 Oct 2026. |
Mover M-01 | Process weakness (P07 AR-11) | Mover requests added access and removed none. Owner: Head of IT; the change to the request is due 30 Oct 2026. |
Leaver L-02 | Repeat of P07 PW-01 | Warehouse system account removed four working days late. |
Orphaned accounts O-01 and O-02 | Findings (P07 AR-08) | Both on the pallet network portal, found on its first full user list; the portal joins P07's system inventory for the next campaign. |
The four measures, as at 30 Sep 2026: JMM-01 leavers removed on time, 8 of 9 (below target, within tolerance); JMM-02 orphaned accounts found, 2 (below target, within tolerance); JMM-03 movers with residual access, 1 (outside tolerance); JMM-04 non-standard access past expiry, 0 of 17 live (on target). (EXAMPLE)
Timing targets
Each step above carries its own time. The Access Control Policy gathers every time limit in one table, "Timing at a glance": the 16 limits of rules JML-03 to JML-15, from HR's [[5]] working days' notice of a joiner to the [[1]] working day in which an orphaned account is disabled. Change a time there first, then in the steps here.
Escalation
A step that cannot be done in its time is escalated at once, never left for the reconciliation to find.
Situation | What to do | Who decides |
|---|---|---|
HR records a joiner late | Create the accounts the day the record arrives and enable them on the start date at the earliest. Never enable an account before it is recorded. Report the late notice to the process owner. | Process owner |
A manager asks for an account with no HR or sponsor record | Refuse, and ask the manager to have HR or the sponsor record the person. A senior requester does not change this. | Process owner |
A named administrator does not confirm a removal by the end of the day | Call the administrator, then the system owner. If the account cannot be removed, disable sign-in at the system's network or single sign-on gateway where possible, and record the removal as late. | System owner |
A supplier cannot remove access in time | Record the removal as late with the supplier's reason. Tell the system owner, who raises the supplier's removal time against its contract. | System owner |
A conflict is found when checking resulting access | Do not grant. Tell the line manager and the system owner. Remove one of the two rights; if neither can go, the request goes to the exception process before anything is granted. | System owner |
An urgent leaver is decided out of hours | Call the on-call service desk number. The person is not told until the service desk confirms every account is disabled. | HR |
A reset caller cannot be checked by any of the identity checks | Do not reset. Offer the in-person check, and tell the person through a second channel that a reset was asked for. | Process owner |
A system's extract does not arrive for the reconciliation | Record the system as not reconciled in the report. A missing extract is incomplete coverage, never a month with no findings. | Head of Information Security |
Records and evidence
Each rule leaves a record. Keep each for [[the period your records policy sets, and at least until the next audit]].
Record | Shows |
|---|---|
HR record or sponsor register entry for the event, with its date | JML-01 |
The approved request for non-standard access, with its expiry | JML-04 |
The segregation-of-duties check for each grant, kept as P02 SD-07 sets | JML-06 |
The access provisioning log entry for every grant, change, suspension and removal | JML-14 |
The completed leaver checklist for every leaver, with the time of each removal | JML-09 |
The reset ticket, with the identity check used | JML-13 |
The discovery results and the outcome for each system found | JML-12 |
The monthly reconciliation and report, with the findings raised | JML-15 |
The leaver checklist covers 9 groups of items for every leaver: directory account and single sign-on, local accounts outside single sign-on, remote access, email and files, shared credentials, tokens and devices, physical access, supplier and customer accounts and privileged access.
Worked example: what the September month end found
EXAMPLE, not part of the procedure. The organisation is the one used throughout the pack: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. Replace it with your own.
A mover who kept the old role. M-01 moved from accounts payable clerk (RP-04) to payments officer (RP-05) on 7 Sep 2026, with no handover, and kept supplier invoice entry (SYS-01), supplier master data, including bank details (SYS-01) and accounts payable folder (SYS-05). Beside the new role's payment run approval, the bank details right is SOD-FI-01, rated High. It was held for 17 working days to the month end, found by the reconciliation on 1 Oct 2026, and removed on 2 Oct 2026. The Chief Financial Officer asked the ERP provider for same-day removal; P07's weakness PW-02 (the provider's five-day removal time) is still open. The Financial Controller checked every change to supplier bank details since 7 Sep: none was made by the mover. Mover requests now replace the old profile by default (JML-08), and the conflict check covers the person's resulting access (JML-06).
A leaver whose local account stayed. L-02, a warehouse team leader, left on 11 Sep 2026. The local account on SYS-02 warehouse management system was removed on 17 Sep 2026, four working days late. The warehouse system's log shows no sign-in to the account after the last working day, and the badge was recovered on the day. Recorded against P07 PW-01 (HR Director, due 30 Nov 2026), which stays open. The leaver checklist now sends the warehouse system line to the named administrator.
The position for the leadership team: September 2026: 8 of 9 leavers on time, two orphaned accounts and one mover with residual access, each raised with the access review. (EXAMPLE)
Related documents
Document | Relationship |
|---|---|
Access Control Policy | The rules this procedure runs (JML-01 to JML-16) |
Role-Based Access Profile Matrix | The base and role profiles used in steps 1.2, 2.2 and 3.3 |
Access Request & Approval Form | Non-standard access, renewals and extensions |
Leaver Access Removal Checklist | The line-by-line leaver checklist used in steps 4.2 to 4.7 |
Access Provisioning Log | Where every grant, change, suspension and removal is logged |
Identity Lifecycle Responsibility Matrix | Who is responsible, accountable, consulted and informed for each activity |
Leaver Timeliness & Orphaned Account Report | The monthly reconciliation report and the four measures |
Segregation of Duties Conflict Matrix; SoD Conflict Review & Compensating Control Procedure | The conflicts checked before every grant, and what happens when one cannot be separated (Security Exception, Waiver & Segregation of Duties pack) |
Access Review Campaign Operating Procedure; Access Review Findings & Revocation Tracker | The periodic review this procedure hands findings to (User Access Review pack) |
Privileged Access Request, Elevation & Revocation Procedure | The privileged steps for a leaver or mover, and privileged resets (Privileged Access Management pack) |
Incident Triage & First-Hour Assessment Procedure | Reporting an urgent leaver suspected of misuse, or an account used after its owner left (Security Incident Management pack) |
Adapting this template
Guidance — delete before approval
Small organisation: HR may be the office manager and the service desk your IT provider. Keep the seven events, the conflict check on resulting access, the leaver checklist and the monthly reconciliation; drop the step tables to a one-page checklist per event if that is easier to follow. The reconciliation can be a spreadsheet with the HR list in one column and each system's users in the next.
Regulated entity (NIS2, DORA): for the digital providers its Article 1 names, Implementing Regulation (EU) 2024/2690 expects access modified on termination or change of employment (Annex point 11.2), the full life cycle of identities managed, deactivating those no longer needed without delay (11.5), resets under a controlled process (11.6) and assets returned on leaving (12.5). A DORA financial entity needs a lifecycle process for identities and accounts covering creation, change, temporary deactivation and termination (Delegated Regulation (EU) 2024/1774, Article 20(2)) and removal without undue delay (Article 21(e)). The seven events and their records are that process.
IT run by a service provider: your managed IT provider may run the service desk steps and some suppliers the administrator steps. Put the times in this procedure into their contracts, and have them confirm every removal in the system. The HR record, the approvals and the reconciliation stay with your organisation.
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2) and Implementing Regulation (EU) 2024/2690; Regulation (EU) 2022/2554 (DORA); Delegated Regulation (EU) 2024/1774.
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 5.16 — Identity management | The lifecycle events; the monthly reconciliation |
ISO/IEC 27001:2022 | Annex A 5.18 — Access rights | Joiner, mover and leaver steps; who approves access; the provisioning log |
ISO/IEC 27001:2022 | Annex A 5.15 — Access control | Checking resulting access; building role profiles |
ISO/IEC 27001:2022 | Annex A 5.3 — Segregation of duties | Checking resulting access against the conflict matrix |
ISO/IEC 27001:2022 | Annex A 5.17 — Authentication information | First sign-in for joiners; password and factor resets |
ISO/IEC 27001:2022 | Annex A 6.5 — Responsibilities after termination or change of employment | Mover and leaver steps |
ISO/IEC 27001:2022 | Annex A 5.11 — Return of assets | Equipment, badges and tokens recovered (steps 4.6, 5.4) |
NIST CSF 2.0 | PR.AA-01 — “Identities and credentials for authorized users, services, and hardware are managed by the organization” | The lifecycle events; the monthly reconciliation |
NIST CSF 2.0 | PR.AA-02 — “Identities are proofed and bound to credentials based on the context of interactions” | Joiners' first sign-in; reset identity checks |
NIST CSF 2.0 | PR.AA-05 — “Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties” | Building role profiles; checking resulting access |
NIST CSF 2.0 | ID.AM-02 — “Inventories of software, services, and systems managed by the organization are maintained” | Accounts outside single sign-on: discovery |
NIST CSF 2.0 | GV.RR-04 — “Cybersecurity is included in human resources practices” | HR records every event (steps 1.1, 3.1, 4.1, 7.1) |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(i) — “human resources security, access control policies and asset management” | Whole procedure; regulated-entity tailoring |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 11.2 — access rights are provided, modified, removed and documented under the access control policy: assigned and revoked on need-to-know, least privilege and separation of duties; “modified accordingly upon termination or change of employment”; authorised by the relevant persons; third-party access limited in scope and in duration; a register of access rights granted; logging of the management of access rights; and review at planned intervals | Mover and leaver steps; who approves access |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 11.5 — “manage the full life cycle of identities of network and information systems and their users”: unique identities, each user identity linked to a single person, shared identities only where necessary and explicitly approved and documented, logging of identity management, and regular review, deactivating identities no longer needed “without delay” | The lifecycle events; the monthly reconciliation |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 11.6.2(b) and (c) — the allocation and management of secret authentication information is controlled by a process that ensures its confidentiality, and credentials are changed initially, at predefined intervals and upon suspicion that they were compromised | Password and factor resets |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 12.5 — assets in the custody of personnel are deposited, returned or deleted upon termination of employment, and this is documented; where that is not possible, the assets can no longer access the entity's network and information systems | Equipment recovered from leavers |
DORA — Regulation (EU) 2022/2554 | Article 9(4)(c) — policies that limit access to information and ICT assets to what is required for legitimate and approved functions, with controls that ensure sound administration of access rights | Building role profiles: access limited to what the job needs |
DORA — Delegated Regulation (EU) 2024/1774 | Article 20(2) — a unique identity and user account for each staff member, and for each member of an ICT third-party service provider's staff, with records of identity assignments kept after a reorganisation or the end of the contract; and “a lifecycle management process for identities and accounts managing the creation, change, review and update, temporary deactivation, and termination of all accounts”, automated where feasible and appropriate | The lifecycle events, including suppliers' staff and temporary deactivation |
DORA — Delegated Regulation (EU) 2024/1774 | Article 21(a) — access rights assigned on need-to-know, need-to-use and least privilege principles, including for remote and emergency access | Building role profiles: need to know, need to use, least privilege |
DORA — Delegated Regulation (EU) 2024/1774 | Article 21(b) — an access control policy with segregation of duties that prevents combinations of access rights able to circumvent controls | Checking resulting access against the conflict matrix |
DORA — Delegated Regulation (EU) 2024/1774 | Article 21(e) — account management: roles for granting, reviewing and revoking access; privileged access on a need-to-use basis; removal without undue delay; review at least every six months for systems supporting critical or important functions and at least yearly for others | Removal without undue delay: leaver and urgent leaver steps |
DORA — Delegated Regulation (EU) 2024/1774 | Article 19(b)(iii) — staff return all ICT assets and tangible information assets that belong to the financial entity upon termination of employment | Equipment returned by leavers |
Definitions
Term | Meaning in this procedure |
|---|---|
Base profile | The access everyone gets on day one: an account, single sign-on, a mailbox and the office apps. |
HR record | The HR system's record of each employee: start date, job, department, line manager, absence and leaving date. The only source for an employee's lifecycle events. |
Last working day | The leaver's last day at work, from the HR record. It can be earlier than the contractual end date, for example where holiday or garden leave follows. |
Local account | An account a system holds itself, outside single sign-on. Disabling the directory account does not touch it; it must be removed in the system. |
Long absence | An absence expected to last more than [[30]] days, such as parental leave, long sick leave, a sabbatical or a suspension. |
Move date | The date a mover starts their new job, from the HR record. |
Mover window | The time a mover may keep old access: none after the move date, or up to [[5]] working days where the old line manager records a handover (JML-08). |
Non-employee | Anyone who is given an account but is not on the payroll: a contractor, an agency worker, a consultant or a supplier's staff. |
Non-standard access | Any access right that is not in the person's base or role profile. Needs its own approval and an expiry date. |
Orphaned account | An account that matches no current person in the HR record or the sponsor register, or a shared account with no named owner. P07 calls it an orphan account. |
Reconciliation | The monthly comparison of every in-scope system's accounts with the HR record and the sponsor register, to find orphaned accounts, late leavers and movers with residual access. |
Remove | To disable an account or withdraw an access right so it can no longer be used. A removed account is deleted later, once its data has been dealt with. |
Residual access | Access a mover still holds from their old role after the mover window has closed. |
Resulting access | Everything a person will hold after a change: the base profile, their role profile, any non-standard access and whatever they still hold from an earlier role. |
Role profile | The standard access for one job role, on top of the base profile, approved in advance by the profile owner and the owner of each system in it. Granted without further approval. |
Sponsor register | The record of every non-employee who uses the organisation's systems: who they are, who sponsors them, why, and the end date. Kept by [[HR, or the service desk where HR does not hold non-employees]]. The only source for a non-employee's lifecycle events. |
Suspend | To disable an account so it cannot be used, keeping it and its access rights so they can be restored. |
Urgent leaver | A leaver who leaves at short notice or on bad terms: a dismissal, a resignation with immediate effect, a suspension, or a leaver suspected of misconduct. Also called a hostile leaver. |
Working day | Monday to Friday, excluding [[public holidays where you are]]. |