Access Control Policy
States the access principles, approval requirements and review obligations for every system; the identity domain's single policy.
Available soon
- Format
- Word
- Size
- 71 KB
- Length
- 23 pages
- Version
- 2.0
- Updated
What's inside
What changed
- 2.0
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.
- 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 policy sets how [[Organisation Name]] gives people access to its systems, changes that access when their job changes, and takes it away when they leave. Every account belongs to one person known to HR or to a sponsor. Every right a person holds is either part of the standard profile for their job, or approved for them for a limited time. Every change is made from a record, logged, and checked each month against the people who should hold access.
Access that nobody removes is the commonest weakness an access review finds: leavers whose accounts still work, movers who keep their old role, and accounts that belong to nobody. Each one is a way in for an attacker or a former member of staff. The rules below close that way in when it opens, at joining, moving and leaving, instead of months later at a review.
The Joiner-Mover-Leaver Operating Procedure says who does each step and by when. The Role-Based Access Profile Matrix holds the role profiles, the Access Request & Approval Form records approvals for access outside them, the Leaver Access Removal Checklist lists what is removed when someone leaves, and the Leaver Timeliness & Orphaned Account Report reports how well the process works. Privileged access follows the Privileged Access Standard of the Privileged Access Management pack.
Guidance — delete before approval
This is the policy for topic PT-03, access control and identity, in the Security Policy Management pack's list of policy topics. It is a Policy-tier document: approved by executive management and reviewed at least every 12 months.
If you already have an access control policy, compare it statement by statement with this one. Most existing policies say who approves access; few say what ends it. Keep your own wording where it is clearer, and keep the rule IDs, because every document in the pack cites them.
Scope
This policy applies to:
- People: every employee, and every non-employee given an account: contractors, agency workers, consultants and suppliers' staff.
- Systems: every system that holds accounts for [[Organisation Name]], on premises or in the cloud, including software bought with a company card or signed up to with a work email address, and supplier portals staff use on the organisation's behalf (JML-12).
- Access: accounts, the access rights they hold, the sign-in factors that protect them, and the equipment, badges and tokens that give access.
- Events: joining, moving, leaving, a long absence, and the end of a non-employee's engagement.
Excluded: 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. Customers' own accounts on customer-facing services are out of scope unless they carry administrative rights. The periodic review of access follows the Access Review Methodology of the User Access Review pack; this policy prevents what that review would otherwise find. [[Anything else deliberately left out, and where it is covered; or "None"]].
Guidance — delete before approval
Name the systems in scope in the Role-Based Access Profile Matrix, starting with the ones that hold money, personal data or customer orders. A system nobody listed is the one whose accounts outlive the people who used them.
A supplier that runs a system for you makes the changes in it, but the rules still apply: the HR record starts the change, and the change is confirmed in the system before it is recorded as done. Put the supplier's removal time into the contract.
Access principles
The rules put seven principles into practice. Where a case is not covered by a statement, decide it by the principle.
Principle | Carried by |
|---|---|
Access follows the job. People get the access their current job needs, and no more: need to know, need to use and least privilege. | JML-03, JML-04 |
One person, one identity. Every account belongs to one named person, so every action can be traced to someone. | JML-02 |
The HR record and the sponsor register start every change. A manager's email is not a trigger. | JML-01 |
Standard access is approved once, in a role profile. Anything else is approved each time, and expires. | JML-03, JML-04 |
Nobody controls their own access, and duties that conflict are kept apart. | JML-05, JML-06 |
Access ends when the need ends: at a move, at leaving, at a non-employee's end date, and during a long absence. | JML-08, JML-09, JML-10, JML-11 |
Every change is recorded, and each month the records are checked against the people who should hold access. | JML-14, JML-15 |
Need to know and need to use. A person holds a right because their current job cannot be done without it, at that level, now. A right is not needed because the person used to need it, because a colleague has it, or because removing it might cause a support call.
Least privilege. Least privilege applies to the level of a right as well as to the system. A clerk who enters invoices needs the invoice entry role, not a supervisor role that also approves them.
Accountability. Every action in a system must be traceable to one person. That is why shared accounts are the exception (JML-02), why every change is logged with who made it (JML-14), and why the person who makes a change never approves it (JML-05).
The identity lifecycle
Every change to access starts from one of seven events, recorded in the HR record or the sponsor register (JML-01). The Joiner-Mover-Leaver Operating Procedure sets the steps for each.
Event | Source and trigger | Target | Rules |
|---|---|---|---|
Joiner (employee) | HR record: HR records the start date, job, department and line manager. | 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 |
Joiner (non-employee) | Sponsor register: the sponsor records the person, the reason and the end date. | As an employee joiner; the account expires automatically at the end date, no more than [[12]] months ahead. | JML-01, JML-07, JML-10 |
Mover | HR record: HR records a new job, department or line manager, with the move date. | 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 |
Leaver | HR record or sponsor register: HR records the last working day, or the sponsor ends the engagement. | All access removed by the end of the last working day; equipment and tokens recovered the same day. | JML-09 |
Urgent or hostile leaver | HR record: HR or the line manager decides the person leaves now, or is suspended. | All access removed within [[60]] minutes of the decision, and before the person is told. | JML-09 |
Non-employee end date | Sponsor register: the recorded end date arrives, or the sponsor ends the engagement early. | The account expires automatically at the end of the end date; an early end is a leaver the same day. | JML-10 |
Long absence | HR record: HR records an absence expected to last more than [[30]] days. | Accounts suspended from the first day of the absence; restored on the day of return, once the line manager confirms it. | JML-11 |
The HR record is 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. The sponsor register is 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.
A record that is late or wrong is corrected at its source. The service desk does not create, change or remove an account from a manager's email, a chat message or a phone call, however senior the person asking. It asks HR or the sponsor to record the event, and acts on the record.
Guidance — delete before approval
If HR and IT use different systems, agree how an event reaches the service desk: an automatic feed is best, a daily report is acceptable, and an email from HR is the minimum. Whatever the route, the service desk acts on what HR recorded, with its date.
Agency workers and contractors are the people most often missing from HR. The sponsor register exists for them. It can be a list kept by the service desk, as long as every entry has a sponsor and an end date before an account is created.
Who approves access
Approval depends on whether the access is part of a profile, and on who could gain from it.
Request | Who approves | Rule |
|---|---|---|
Base and role profile, for a joiner or a mover | None beyond the HR record: the profile is approved in advance by its owner and the owner of each system in it. The line manager confirms which profile applies. | JML-03 |
Non-standard access | The line manager (or the sponsor), and the owner of the system or data. With an expiry no more than [[6]] months ahead. | JML-04 |
Renewal of non-standard access, or extension of a non-employee's end date | The same approvers as the original request, before the expiry or end date. | JML-04 |
Access that would create a segregation-of-duties conflict | Not granted unless accepted as an exception under P02 SD-04, approved at the level P02 sets for the exception's band. At Critical that is the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management. | JML-06 |
An exception to the Access Control Policy | Through the P02 exception process, approved at the level P02 sets for the band. At Critical, the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management. | P02 EX-05 |
Privileged, emergency or service account access | As the Privileged Access Standard sets. | JML-16 |
The person who makes a change in a system never approves it, and nobody approves their own access or that of anyone who approves theirs (JML-05). This applies the conflict P02 calls SOD-IT-01 in its Segregation of Duties Conflict Matrix: "create or change user accounts and permissions" and "approve access requests" are kept apart. The service desk and administrators make changes; line managers, sponsors and system owners approve them.
Guidance — delete before approval
A role profile is approved once, by its owner and by the owner of every system in it. That approval covers every joiner and mover given the profile, which is why a profile must never contain a conflict or privileged access (JML-03). The Role-Based Access Profile Matrix records each approval.
Policy statements
The statements keep the rule IDs JML-01 to JML-16 that every document in the Joiner-Mover-Leaver & Access Provisioning pack cites. Values in [[brackets]] are the pack's defaults; set your own before approval. Each statement names the evidence an auditor looks at.
Identity and where every change starts
Most access that should not exist was created on an email from a manager and never tied to a record that ends. Tying every account to one record that has an end is what lets the organisation find it again.
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.
Evidence: HR record or sponsor register entry for the event, with its date. No account in the monthly reconciliation without a matching record.
JML-02 Every person has one identity, and every account is linked to exactly one identity. A shared account is allowed only where a system cannot work without one, with a named owner and the system owner's approval, and is handled as P07 AR-06 sets.
Evidence: For each shared account, its named owner and the system owner's approval.
Standard access, other access and who approves it
Role profiles make the common case fast and safe: approved once, granted many times. Everything outside a profile costs an approval and carries an end date, so it cannot quietly become permanent.
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.
Evidence: For each role profile, its owner, each system owner's approval and the date of its last review.
JML-04 Access outside the person's profiles is non-standard. It needs a business reason, approval by the line manager (or the sponsor) and by the owner of the system or data, and an expiry date no more than [[6]] months ahead, or the non-employee's end date if that is sooner. At expiry it is removed unless the same approvers renewed it beforehand, with a new expiry date.
Evidence: The approved request for non-standard access, with its expiry.
JML-05 Nobody approves their own access, or the access of anyone who approves theirs. The person who makes the change in a system does not approve it (P02 SOD-IT-01).
Evidence: On each request, approvers who are neither the person receiving the access nor the person who made the change.
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.
Evidence: The segregation-of-duties check for each grant, kept as P02 SD-07 sets.
Joiners, movers, leavers and long absences
Movers are where access builds up: new access is asked for at once, old access is rarely given back. The mover rule therefore removes the old role by default, and anything still needed is asked for again.
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.
Evidence: For each joiner, the date HR recorded them, the date the accounts were created and the date they were enabled.
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).
Evidence: For each mover, the move date, any handover the old line manager recorded, and the date the old role's access was removed.
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.
Evidence: The completed leaver checklist for every leaver, with the time of each removal.
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.
Evidence: For each non-employee, the sponsor and end date in the sponsor register before the account was created, and the account's expiry date set to match.
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.
Evidence: For each long absence, the date the accounts were suspended and restored, and any access kept with its reason.
Systems outside single sign-on
Disabling the directory account ends access to everything connected to single sign-on and nothing else. Every system with its own accounts needs a named line on the leaver checklist, or it will be missed.
JML-12 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.
Evidence: The discovery results and the outcome for each system found.
Password and sign-in resets
A caller who can persuade the service desk to reset a password or a second factor has taken over the account. The check happens before the reset, every time.
JML-13 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 the Joiner-Mover-Leaver Operating Procedure sets. 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.
Evidence: The reset ticket, with the identity check used.
Records and the monthly check
The monthly reconciliation is the control that catches what the process missed. A finding means the check worked; nobody is blamed for finding one.
JML-14 Every grant, change, suspension and removal is recorded in the access provisioning log with its request reference, the approvers, who made the change and when it was completed. A removal is recorded as complete only when it is confirmed in the system.
Evidence: The access provisioning log entry for every grant, change, suspension and removal.
JML-15 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).
Evidence: The monthly reconciliation and report, with the findings raised.
Privileged access
Administrator, emergency and service accounts need stricter rules than this policy sets. They have their own standard, and this policy defers to it.
JML-16 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.
Evidence: As the Privileged Access Standard sets.
Timing at a glance
Every time limit the statements set, in one place. Change a value here, and in the procedure, the form and the workbooks, together.
What | When | Rule |
|---|---|---|
HR records a joiner | At least [[5]] working days before the start date | JML-07 |
Joiner's accounts created, disabled | No earlier than [[5]] working days before the start date | JML-07 |
Joiner's accounts enabled | On the start date, never before | JML-07 |
Mover's old access removed | On the move date; with a recorded handover, within [[5]] working days of it | JML-08 |
Leaver's access removed | By the end of the last working day, local accounts included | JML-09 |
Urgent leaver's access removed | Within [[60]] minutes of the decision, and before the person is told | JML-09 |
Equipment, badges and tokens recovered, shared credentials changed | The same day as the access is removed | JML-09 |
Removed account deleted | After [[90]] days, once its data has been dealt with | JML-09 |
Non-employee's end date | No more than [[12]] months after the start | JML-10 |
Reminder before an end date or an expiry | [[10]] working days before | JML-04, JML-10 |
Non-standard access expiry | No more than [[6]] months ahead, and never after a non-employee's end date | JML-04 |
Long absence | More than [[30]] days: suspended from the first day, restored on return | JML-11 |
Discovery of systems outside single sign-on | Every [[3]] months | JML-12 |
Monthly reconciliation | Within [[3]] working days of each month end | JML-15 |
Orphaned account disabled | Within [[1]] working day of being found | JML-15 |
Role profile reviewed | Every [[12]] months, and after a reorganisation or a new core system | JML-03 |
What this policy rules out
Shortcuts that look harmless and are the usual cause of access that should not exist.
Not allowed | Rule |
|---|---|
Creating an account because a manager emailed the service desk | JML-01 |
Copying a colleague's access to a joiner or mover ("same as Sam") | JML-03, JML-04 |
Granting access outside a profile with no end date | JML-04 |
Approving your own access, or the request of someone who approves yours | JML-05 |
Checking only the new access against the conflict matrix, and not what the person still holds | JML-06 |
Enabling a joiner's account before the start date "to save time on day one" | JML-07 |
Leaving a mover's old access in place "until they have settled in", beyond the handover window | JML-08 |
Disabling the directory account and treating the leaver as done when local accounts remain | JML-09, JML-12 |
Telling an urgent leaver before their access has gone | JML-09 |
Resetting a password because the caller knew the staff number and date of birth | JML-13 |
Recording a removal as complete because the ticket was closed | JML-14 |
Skipping the reconciliation of a system because its extract did not arrive | JML-15 |
Guidance — delete before approval
JML-01 to JML-16 are the rules published at version 1.0, with their IDs and meaning kept. Do not renumber them. If you remove one, keep its number and mark it "Withdrawn in version x.y", so records that cite it still point to the right text.
The timings are drafting defaults, chosen to be achievable with a service desk and single sign-on. Shorten them where your systems allow. Lengthening the leaver or urgent leaver time weakens the policy more than any other change.
Roles and responsibilities
Each role below answers for (A) or does (R) the activities of the Identity Lifecycle Responsibility Matrix. Executive management approves this policy.
Role | Responsibilities under this policy |
|---|---|
Executive management [[e.g. Executive Committee, or the management body]] | Approves this policy and any change to it. Receives a headline measure that stays outside tolerance, with its plan. |
HR [[for joiner, mover and leaver data]] | Keeps the HR record, the only source of an employee's lifecycle events. Answers for: record a joiner, mover, leaver or long absence in the HR record, with its date (JML-01); decide an urgent leaver and tell the service desk before the person is told (JML-09). |
Line manager [[each person's manager]] | Decides what their people need for the job, and tells HR at once of any change. Answers for: confirm which role profile a joiner or mover needs (JML-03); request non-standard access for an employee, with the reason and expiry (JML-04); recover equipment, badges and tokens, and change shared credentials (JML-09). Does: approve non-standard access to a system: the line manager for an employee or the sponsor for a non-employee, with the system owner (JML-04); decide an urgent leaver and tell the service desk before the person is told (JML-09). |
IT service desk [[internal service desk, or the managed IT provider's]] | Makes the changes the records call for, and never approves them. Does: check resulting access against the conflict matrix before a grant (JML-06); create, change, suspend and remove accounts in single sign-on and connected systems (JML-14); recover equipment, badges and tokens, and change shared credentials (JML-09); check a caller's identity before a password or factor reset (JML-13); run the monthly reconciliation and report (JML-15). |
System owner [[the manager accountable for the system]] | Answers for who holds access to their system and what it lets them do. Answers for: approve non-standard access to a system: the line manager for an employee or the sponsor for a non-employee, with the system owner (JML-04); remove local accounts and access rights the service desk cannot reach (JML-09). Does: build and keep each role profile (JML-03). |
System administrator [[IT operations, or the supplier's support team]] | Makes changes in systems the service desk cannot reach. Does: remove local accounts and access rights the service desk cannot reach (JML-09). |
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. Answers for: record a non-employee in the sponsor register, with the reason and end date (JML-10); request non-standard access for a non-employee, with the reason and an expiry no later than their end date (JML-04). Does: approve non-standard access to a system: the line manager for an employee or the sponsor for a non-employee, with the system owner (JML-04). |
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. Answers for: build and keep each role profile (JML-03); check resulting access against the conflict matrix before a grant (JML-06); create, change, suspend and remove accounts in single sign-on and connected systems (JML-14); check a caller's identity before a password or factor reset (JML-13); discover systems outside single sign-on and decide each outcome (JML-12). |
Head of Information Security [[e.g. Head of Information Security]] | Checks that the process works, and reports where it does not. Answers for: run the monthly reconciliation and report (JML-15); raise late leavers, residual access and orphaned accounts as access review findings (JML-15). Does: discover systems outside single sign-on and decide each outcome (JML-12). |
Campaign coordinator [[e.g. Information Security Manager]] | Runs the access review, and receives what the monthly check finds. Does: raise late leavers, residual access and orphaned accounts as access review findings (JML-15). |
The Identity Lifecycle Responsibility Matrix sets who is responsible, accountable, consulted and informed for each of the 16 activities, RA-01 to RA-16. Exactly one role answers for each.
Guidance — delete before approval
In a small organisation one person may hold several of these roles. Two must stay apart: whoever makes changes in a system (the IT service desk or an administrator) never approves them. Where that is impossible, record it as an exception and have someone else check every change each month.
Name the process owner by role. In most organisations it is the head of IT, who answers for the process working; HR answers for the record that starts it.
Compliance and consequences
How compliance is checked. Within [[3]] working days of each month end, every in-scope system's accounts are reconciled with the HR record and the sponsor register. The reconciliation is the main check on this policy: it finds every leaver whose access survived, every mover who kept old access and every account that belongs to nobody. The access review campaign of the User Access Review pack checks the same access independently, and [[internal audit]] tests the policy [[every year]], tracing a sample of joiners, movers and leavers from the HR record to the provisioning log and the systems.
Measures. The Leaver Timeliness & Orphaned Account Report reports four measures. They are this pack's own: no other pack defines them.
Measure | What it counts | Target |
|---|---|---|
JMM-01 Leavers removed on time | Leavers whose last working day fell in the period and whose access was removed from every system, local accounts included, within JML-09's time, out of all such leavers. | All |
JMM-02 Orphaned accounts found | Accounts found at the month-end reconciliation that match no current person in the HR record or the sponsor register, or shared accounts with no named owner. | Zero |
JMM-03 Movers with residual access | Movers whose mover window closed in the period and who still held access from their old role when it closed. | Zero |
JMM-04 Non-standard access past expiry | Non-standard access rights past their expiry date at the period end, neither removed nor renewed. | Zero |
Reporting. Monthly, within [[3]] working days of month end, to the security and IT leadership team with the other operational metrics, and to the access review coordinator.
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.
The metrics programme. The catalogue of the Cybersecurity Metrics & Reporting Programme pack imports ARM-03 as MC-23. It holds no leaver, orphaned-account or mover measure. An organisation that reports these four through its metrics programme adds them as catalogue rows under P11 MR-04, with P13's definitions and targets unchanged.
Consequences of not complying. A mistake reported at once is corrected and recorded, and nobody is disciplined for it. Creating or keeping access outside these rules on purpose, approving your own access, sharing a password, or using a former colleague's account may lead to action under the [[disciplinary procedure]]. For a supplier, a breach of these rules by its staff is a breach of the security terms of its contract, handled under them.
Guidance — delete before approval
EXAMPLE, September 2026, with the tolerances the security and IT leadership team set:
JMM-01 Leavers removed on time: 8 of 9, below target, within tolerance (target all; tolerance [[85%]]). L-02: the warehouse system account was removed four working days late.
JMM-02 Orphaned accounts found: 2, below target, within tolerance (target zero; tolerance [[2]]). Both on the pallet network portal, found on its first full user list, and disabled the day they were found.
JMM-03 Movers with residual access: 1, outside tolerance (target zero; tolerance Same as the target). M-01 kept the supplier bank details role, a High conflict with payment approval (P02 SOD-FI-01).
JMM-04 Non-standard access past expiry: 0 of 17 live, on target (target zero; tolerance Same as the target). Every non-standard right given an expiry at adoption has now been removed or renewed.
Exceptions
Any departure from these rules is requested, scored and approved under the Security Exception & Waiver Standard [[document ID]] (Security Exception, Waiver & Segregation of Duties pack), using the Security Exception Request & Approval Form, before the departure begins. An exception names the rule, the person or system, the reason, the compensating measures and an expiry date, and is recorded in the Security Exception Register. Agreement by email, in a meeting or by a manager is not an exception.
The exception's band, from its score, sets who approves it and how long it may last:
Band | Who approves | Longest exception |
|---|---|---|
Low | Control owner | 365 days |
Medium | Head of Information Security | 180 days |
High | Head of Information Security and the accountable executive (risk owner) | 90 days |
Critical | The board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management | 30 days |
Conflicts of duties
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. The Segregation of Duties Conflict Matrix is P02's: this pack applies it and adds no conflict of its own. Two of its conflicts matter most here:
Conflict | The two duties | Rating | How this policy applies it |
|---|---|---|---|
SOD-FI-01 | Create or change suppliers and their bank details in the finance system; and approve payments | High | Never in one role profile (JML-03). Checked against everything a mover still holds before the new profile is granted (JML-06). |
SOD-IT-01 | Create or change user accounts and permissions; and approve access requests | High | The person who makes a change never approves it (JML-05). |
A conflict that can be separated is separated: one of the two rights is removed. Only a conflict that cannot be separated, usually because a team is too small, goes to P02 SD-04 as an exception, with a compensating control carried out by someone without the conflict. At Critical, that exception is approved by the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management.
Guidance — delete before approval
EXAMPLE: M-01 moved from accounts payable clerk to payments officer and kept the old role's access: 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 approval, the supplier bank details right is a High conflict (SOD-FI-01). Separated: the old role's access removed. No P02 exception. The Financial Controller checked every change to supplier bank details since 7 Sep: none was made by the mover.
Related documents
Document | Relationship |
|---|---|
Joiner-Mover-Leaver Operating Procedure | The steps, owners and times for every lifecycle event, reset and reconciliation (JML-01 to JML-15) |
Role-Based Access Profile Matrix | The base and role profiles, their owners and approvals (JML-03) |
Access Request & Approval Form | The request and approval of non-standard access, renewals and extensions (JML-04 to JML-06) |
Leaver Access Removal Checklist | What is removed and recovered for every leaver, line by line (JML-09, JML-12) |
Access Provisioning Log | The record of every grant, change, suspension and removal (JML-14) |
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 (JML-15) |
Segregation of Duties Conflict Matrix; Security Exception & Waiver Standard | The conflicts checked before every grant, and the exception route (Security Exception, Waiver & Segregation of Duties pack) |
Access Review Methodology; Access Review Findings & Revocation Tracker | The periodic review of access, and where findings go (User Access Review pack) |
Privileged Access Standard | Privileged, emergency and service accounts (JML-16; Privileged Access Management pack) |
Security Incident Management Policy | An urgent leaver suspected of misuse, or an account used after its owner left, is reported as an incident (Security Incident Management pack) |
Information Classification & Handling Policy | Access to Confidential information follows the role profiles and non-standard approvals of this policy (Information Classification & Handling pack) |
[[Information Security Policy]] | [[Parent policy]] |
[[HR policies for starters, leavers and absence]] | [[Where the HR record's events and dates are set]] |
Definitions
Term | Meaning in this policy |
|---|---|
Identity | One person, known to the organisation through the HR record or the sponsor register, to whom every account they use is linked. |
Account | A user name in one system. A person may have several; each is linked to exactly one identity. |
Access right | What an account may do in a system: a role, group or permission, in the system's own words. |
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. |
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. |
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. |
Sponsor | The employee accountable for a non-employee's access: normally the line manager of the team they work for. Confirms the end date, and ends or extends the access. |
Base profile | The access everyone gets on day one: an account, single sign-on, a mailbox and the office apps. |
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. |
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. |
Joiner | A new employee or non-employee who needs access from a start date. |
Mover | A person whose job, department or line manager changes. Their new role's access is added and their old role's access is removed. |
Move date | The date a mover starts their new job, from the HR record. |
Leaver | A person whose employment or engagement ends. All their access is removed, and everything they hold is recovered. |
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. |
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. |
Long absence | An absence expected to last more than [[30]] days, such as parental leave, long sick leave, a sabbatical or a suspension. |
Suspend | To disable an account so it cannot be used, keeping it and its access rights so they can be restored. |
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. |
Single sign-on | Signing in to many systems with one directory account. Disabling that account stops access to every system connected to it. |
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. |
Residual access | Access a mover still holds from their old role after the mover window has closed. |
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. |
Dormant account | An account with no sign-in for [[90]] days (P07). |
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. |
Segregation-of-duties conflict | Two duties that would let one person make and hide an unauthorised change, payment or access grant, as listed in the Segregation of Duties Conflict Matrix. |
Working day | Monday to Friday, excluding [[public holidays where you are]]. |
Document control
Approval record
Version | Approved by | Date | Evidence of approval | Next review by |
|---|---|---|---|---|
[[1.0]] | [[Executive management]] | [[YYYY-MM-DD]] | [[e.g. minutes of meeting, reference and item]] | [[YYYY-MM-DD]] |
Review. This policy is reviewed at least every 12 months, and sooner after: a major incident, or an incident the document should have prevented; a material change to the organisation's activities, systems or suppliers; a change in law, regulation or a contract the document supports; an audit or assessment finding against the document; a significant change in the threats the document addresses. A leaver whose access was used after they left always triggers a review.
Publication and acknowledgement. The current approved version is published at [[location everyone in scope can reach]]. Line managers, sponsors, system owners, HR and the service desk acknowledge it when they take on the role and after every material change.
Guidance — delete before approval
This is a Policy-tier document: approved by executive management. Nobody approves a document they own or wrote: if the owner sits on the approving body, the rest of it approves.
Worked example: the first quarter
EXAMPLE, not part of the policy. 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. It adopted this policy on 1 Jul 2026. The head of IT owns the process and the Head of Information Security owns the report. Replace it with your own, or delete this section before approval.
Date | What happened | Rule |
|---|---|---|
1 Jul 2026 | Policy adopted. 7 role profiles cover 701 of about 900 staff (78%); staff in smaller roles hold the base profile and any non-standard access approved for them. | JML-03 |
31 Jul 2026 | First month-end report: 10 of 12 leavers removed on time, 6 orphaned accounts, 2 movers with residual access. | JML-15 |
31 Aug 2026 | Second report: 11 of 12 leavers on time, 3 orphaned accounts, 1 mover with residual access. | JML-15 |
7 Sep 2026 | M-01 moves from accounts payable clerk to payments officer with no handover, so the mover window closes the same day. The new profile is granted; the old one stays. | JML-06, JML-08 |
11 Sep 2026 | L-02, a warehouse team leader, leaves. The directory account goes on time; the local warehouse system account stays. | JML-09 |
15 Sep 2026 | Quarterly discovery finds four systems outside the inventory: two connected to single sign-on, one kept with local accounts, one closed. | JML-12 |
17 Sep 2026 | L-02's warehouse system account removed, four working days late. | JML-09 |
23 Sep 2026 | An urgent leaver (L-05): every account removed 35 minutes after the decision and 25 minutes before the person was told. | JML-09 |
1 Oct 2026 | Month-end reconciliation, as at 30 Sep 2026: it finds M-01's residual access, L-02's late removal and two orphaned accounts on the pallet network portal, disabled the same day. Each goes to the access review. | JML-15 |
Sep 2026 in numbers
Event | How many | Against the policy |
|---|---|---|
Joiners | 9 (7 employees, 2 non-employees) | 8 recorded and enabled on time. J-06: HR recorded the joiner two working days before the start date; the handheld account was ready on the second day. |
Movers | 5 | 4 had their old access removed within the window. M-01 held the old role for 17 working days to the month end. |
Leavers | 9, of whom two reached a recorded end date and one was urgent | 8 removed on time from every system. The non-employees' accounts expired automatically at their end dates. |
Long absence | 1 | Parental leave: accounts suspended on the first day, 14 Sep 2026. |
Non-standard access granted | 2 | Each with both approvals and an expiry (NS-2026-031 to 12 Mar 2027; NS-2026-033 to 29 Jan 2027). |
Password and factor resets | 46 | Identity checked before every reset: 31 by VM-01, 9 by VM-02, 6 by VM-03. 14 were second-factor resets; none was refused. |
Orphaned accounts | 2 | Both on the pallet network portal, found on its first full user list, disabled the day they were found. |
The measures
Measure | Jul 2026 | Aug 2026 | Sep 2026 | Status |
|---|---|---|---|---|
JMM-01 Leavers removed on time | 10 of 12 | 11 of 12 | 8 of 9 | Below target, within tolerance |
JMM-02 Orphaned accounts found | 6 | 3 | 2 | Below target, within tolerance |
JMM-03 Movers with residual access | 2 | 1 | 1 | Outside tolerance |
JMM-04 Non-standard access past expiry | 3 | 1 | 0 | On target |
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 position for the leadership team: In September 8 of 9 leavers lost all access on time, two orphaned accounts were found and disabled, and one mover kept access from their old role long enough to hold both sides of a High payment conflict. Each went to the access review as a finding.
Guidance — delete before approval
What the quarter taught: the mover case came from a request that added access and removed none, and a conflict check that looked only at the new profile. Mover requests now replace the old profile by default (JML-08), and the conflict check covers the person's resulting access (JML-06).
The late leaver came from a removal task sent to a shared mailbox. 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 orphaned accounts were found only because a supplier portal's user list was asked for. A system nobody reconciles is a system nobody checks.
Adapting this template
Small organisation
Guidance — delete before approval
Keep all 16 statements; they cost little when there are few people. HR may be one person and the service desk your IT provider. Start the role profiles with the [[three]] largest roles, and treat everything else as non-standard with an expiry. The monthly reconciliation can be a spreadsheet: the HR list beside each system's user list.
Where one person both approves and makes changes, have the managing director or another director check the provisioning log each month and sign it.
Regulated entity (NIS2, DORA)
Guidance — delete before approval
NIS2 Article 21(2)(i) asks for human resources security, access control policies and asset management. For the digital providers its Article 1 names, Implementing Regulation (EU) 2024/2690 sets the detail in its Annex: an access control policy (point 11.1), access rights provided, modified and removed on termination or change of employment (11.2), the full life cycle of identities, each linked to one person (11.5), control of passwords and other secret authentication information (11.6) and return of assets on leaving (12.5). For other entities it shows what a regulator expects.
A DORA financial entity limits access to what legitimate, approved functions need (Article 9(4)(c)). Delegated Regulation (EU) 2024/1774 asks for a unique identity for each member of staff and of an ICT provider's staff, and a lifecycle process for accounts (Article 20), access on need-to-know, need-to-use and least privilege (21(a)), segregation of duties (21(b)), limited shared accounts (21(c)), removal without undue delay (21(e)) and return of assets on leaving (19(b)(iii)). Name this policy as the access control policy those articles require.
IT and services run by suppliers
Guidance — delete before approval
Your managed IT provider may run the service desk, and your software suppliers may make changes inside their systems. The rules do not move with the work: the HR record still starts every change, the approvals stay with your managers and system owners, and the change is confirmed in the system before it is logged. Put the removal times into each contract.
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.15 — Access control | Whole policy; access principles; who approves access |
ISO/IEC 27001:2022 | Annex A 5.16 — Identity management | The identity lifecycle; one person, one identity (JML-01, JML-02) |
ISO/IEC 27001:2022 | Annex A 5.18 — Access rights | Standard and non-standard access, joiners, movers and leavers (JML-03 to JML-11, JML-14) |
ISO/IEC 27001:2022 | Annex A 5.3 — Segregation of duties | Conflicts of duties; nobody approves their own access (JML-05, JML-06) |
ISO/IEC 27001:2022 | Annex A 5.17 — Authentication information | First sign-in given only to the joiner; resets after an identity check (JML-07, JML-13) |
ISO/IEC 27001:2022 | Annex A 6.5 — Responsibilities after termination or change of employment | Movers and leavers: access removed when the job changes or ends (JML-08, JML-09) |
ISO/IEC 27001:2022 | Annex A 5.11 — Return of assets | Equipment, badges and tokens recovered from leavers (JML-09) |
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” | Whole policy: permissions defined, managed and reviewed with least privilege and separation of duties |
NIST CSF 2.0 | PR.AA-01 — “Identities and credentials for authorized users, services, and hardware are managed by the organization” | The identity lifecycle; the monthly reconciliation (JML-01, JML-02, JML-15) |
NIST CSF 2.0 | PR.AA-02 — “Identities are proofed and bound to credentials based on the context of interactions” | Joiners' first sign-in and resets bound to a checked identity (JML-07, JML-13) |
NIST CSF 2.0 | GV.RR-04 — “Cybersecurity is included in human resources practices” | The HR record starts every change (JML-01) |
NIST CSF 2.0 | GV.PO-01 — “Policy for managing cybersecurity risks is established based on organizational context, cybersecurity strategy, and priorities and is communicated and enforced” | The policy itself, approved and communicated |
NIST CSF 2.0 | GV.RR-02 — “Roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced” | Roles and responsibilities |
NIST CSF 2.0 | ID.AM-02 — “Inventories of software, services, and systems managed by the organization are maintained” | Systems outside single sign-on found and listed (JML-12) |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(i) — “human resources security, access control policies and asset management” | Whole policy; regulated-entity tailoring |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 11.1 — logical and physical access control policies, based on business and security requirements, that address access by persons, including staff, visitors, suppliers and service providers, and by network and information systems, and “ensure that access is only granted to users that have been adequately authenticated”; reviewed at planned intervals and after significant incidents or significant changes | Whole policy: an access control policy covering staff, suppliers and systems |
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 | Who approves access; non-standard access with an expiry; movers and leavers |
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 identity lifecycle; one identity per person; 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 sign-in resets (JML-13) |
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 and tokens recovered from leavers (JML-09) |
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 | Access principles: access limited to what the job needs |
DORA — Delegated Regulation (EU) 2024/1774 | Article 20(1) — identity management policies and procedures that ensure the unique identification and authentication of natural persons and systems, to enable access rights to be assigned in accordance with Article 21 | The identity lifecycle: each person uniquely identified |
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 | Joiners, movers, leavers and long absences, including suppliers' staff |
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 | Access principles: need to know, need to use and 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 | Conflicts of duties (JML-06) |
DORA — Delegated Regulation (EU) 2024/1774 | Article 21(c) — user accountability: generic and shared accounts limited, and users identifiable for their actions | Shared accounts only with a named owner (JML-02) |
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 | Who approves access; removal on leaving (JML-04, JML-09) |
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 (JML-09) |