Access Review Methodology
Defines review scope, frequency, reviewer selection and decision criteria so campaigns are consistent and evidence holds up.
Available soon
- Format
- Word
- Size
- 69 KB
- Length
- 23 pages
- Version
- 1.0
- Updated
What's inside
- Purpose
- The rules
- Principles
- Scope
- Inputs
- Scales and criteria
- Decision logic
- Removal windows and confirmation
- Findings and process weaknesses
- Detecting a rubber-stamp review
- Evidence
- Measures
- Worked examples
- How to defend the method to an auditor
- Limitations
- Calibration and review
- Related documents
- Adapting this template
- Framework references
- Definitions
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 methodology is how [[Organisation Name]] reviews who has access to its systems so that the review produces decisions, not signatures. Every campaign covers the same kinds of account, runs at the frequency the access requires, puts each entry before someone who knows whether it is needed, allows only four answers, and turns every "no" into a confirmed change within a set number of working days.
It sets the rules AR-01 to AR-12 below, the review frequencies, who reviews what, the four decisions and the criteria behind them, the removal windows, the checks for a rubber-stamp review, the evidence each campaign keeps and the four measures it reports. Every other document in the User Access Review pack applies these rules and cites them by number; the Access Review Campaign Operating Procedure runs them as a campaign.
A review succeeds when it removes access that should not exist and finds the processes that let it build up. A campaign where every entry is kept on time has not shown that access is right; it may only show that nobody looked.
Guidance — delete before approval
Replace every value in [[double brackets]] before approval. The frequencies, removal windows and quality thresholds are template defaults; change them here first, then in the other P07 documents, so that the pack keeps one set of numbers.
If you already run access reviews, keep your tool and your campaign calendar. Adopt the rules, the four decisions and the quality check; they are what makes a review hold up to an auditor.
The rules
These twelve rules are the method. The sections that follow explain each one; the rest of the pack quotes them by number.
AR-01 Every in-scope system must have a named system owner and a documented way to extract who has access.
AR-02 Access must be reviewed at least as often as its scope requires (see Frequency).
AR-03 The extract must be complete and taken on a stated date; the reviewer must see names, roles, permissions and last sign-in.
AR-04 Nobody may review their own access or the access of anyone who reviews theirs.
AR-05 Every entry must get one of the four decisions; nothing is kept by default when a reviewer does not answer.
AR-06 Privileged, generic and service accounts must each have a named owner and must be reviewed by the system owner and information security.
AR-07 Every Revoke or Modify must be carried out within its removal window and confirmed against a fresh extract.
AR-08 Leavers, dormant accounts and segregation-of-duties conflicts found in review must be raised as findings, not just removed.
AR-09 Campaign quality must be checked for rubber-stamping (see Detecting a rubber-stamp review) before the campaign is closed.
AR-10 Each campaign must keep an evidence file: scope, extracts, decisions, changes, confirmation and sign-off.
AR-11 Findings that show a process weakness (for example, leavers not removed) must go to the owner of that process with a fix and a date.
AR-12 Campaign results must be reported as risk removed and weaknesses found, not only as percentage completed.
Guidance — delete before approval
AR-02 refers to the frequency table in "Frequency"; AR-09 refers to the signals in "Detecting a rubber-stamp review". The thresholds in those tables, and the [[2]] working days for a Cannot decide entry, are template defaults you may change.
Principles
Most disagreements about a review decision are settled by one of these.
- Access is kept because it is needed, not because nobody objected. Silence is not a decision: an entry without an answer is escalated, never kept by default (AR-05).
- The person who knows the job decides the need; the person who knows the system decides the permissions. A line manager can say whether someone still needs the ERP; only the system owner can say whether "AP Supervisor" is the right role for that (REVIEWERS).
- Least privilege, not least trouble. Access is kept at the level the current job needs. "They might need it one day" is a reason to request it again that day, not to keep it now.
- No one marks their own homework. Nobody reviews their own access, or the access of someone who reviews theirs (AR-04).
- A decision is not done until the system shows it. A Revoke counts only when a fresh extract shows the access has gone (AR-07).
- Every leaver found is a symptom. Access that should have been removed at the time is a finding about the joiner, mover and leaver process, not only an entry to delete (AR-08, AR-11).
Scope
Systems
Every in-scope system must have a named system owner and a documented way to extract who has access. Systems are listed in the Access Review Scope & System Inventory with their owner, their scope (which sets the frequency) and how the extract is taken. A system without an owner, or without a way to extract who has access, cannot be reviewed, and that gap is itself a finding.
A system is in scope if any of these is true:
- it supports a critical service, or a critical or important function (DORA), or stores, processes or transmits cardholder data (PCI DSS);
- it holds personal, financial or commercially sensitive data;
- it grants privileged or administrator access to anything else in scope: directories, cloud consoles, firewalls, databases, backup systems;
- it moves money, changes supplier or customer records, or approves transactions;
- [[any other system your organisation adds]].
Accounts
Every account on an in-scope system is reviewed, not only the accounts of employees. Five kinds need different handling:
Kind of account | What it is | Who must own it |
|---|---|---|
Personal (standard) account | Belongs to one named employee or contractor for their own work. | The person; their line manager answers for the need |
Privileged or administrator account | Can change the system, its settings, its users or its security: administrator groups, super-user roles, database owners. | A named person, even where the account is separate from their personal account (AR-06) |
Generic or shared account | Used by more than one person, or by a role rather than a person: a warehouse terminal login, a shared mailbox with sign-in, a training account. | A named manager who answers for every use of it (AR-06) |
Service or system account | Used by software, not a person: an interface between two systems, a scheduled job, a backup agent. | A named technical owner who knows what uses it (AR-06) |
Third-party account | Held by someone outside the organisation: a supplier's support staff, a contractor, an auditor, a customer on an admin console. | The manager who manages that supplier or contract |
- Privileged, generic and service accounts must each have a named owner and must be reviewed by the system owner and information security.
- Generic and shared accounts are kept to a minimum: each one must be justified by the system owner, and a person's actions must be traceable to them some other way (for example, a sign-in log at the terminal).
- Third-party accounts include a supplier's support staff. In the EXAMPLE, the ERP provider (SUP-004 in the Third-Party Security Risk Management pack) reaches the ERP through remote support; those accounts are reviewed with SYS-01 like any other.
- Service accounts are reviewed with the system they run on. Where they cannot sign in interactively, the review confirms the owner, the purpose and that the permissions are no wider than the software needs.
Not in scope
- Physical access to buildings and rooms (a separate review, with the same decisions if you choose).
- Customers' own accounts on a customer-facing service, unless they carry administrative rights.
- The approval of new access requests. This methodology reviews access that already exists; granting is covered by [[your access control procedure]].
Inputs
The extract must be complete and taken on a stated date; the reviewer must see names, roles, permissions and last sign-in. The Access Review Campaign Operating Procedure says when each input is taken and who supplies it.
Input | What it must contain | Where it comes from | If it is missing |
|---|---|---|---|
Access extract | Every account on the system: name or account ID, account type, role or group, permissions, last sign-in, the date the extract was taken | System administrator; for a hosted system, the supplier (SYS-01: by ticket) | The system is not reviewed this campaign; raised as a finding against AR-01 and AR-03 |
People list | Current employees and contractors with job title, manager and department; leavers and movers since the last campaign | HR [[for joiner, mover and leaver data]] | Reviewers cannot spot leavers and movers; do not launch until it arrives |
Role definitions | What each role or group in the system allows, in plain words | System owner | The system owner reviews the permissions of every entry, not only the privileged ones |
Conflict matrix | The combinations of duties that must not sit with one person | Segregation of Duties Conflict Matrix (Security Exception, Waiver & Segregation of Duties pack) | Segregation of duties is not checked; state that in the campaign report |
Previous campaign | Last decisions, open findings and process weaknesses | Access Review Findings & Revocation Tracker | First campaign: nothing to compare |
Guidance — delete before approval
An extract without a last sign-in date is the most common reason a review cannot find dormant accounts. If a system cannot give one, record that in the inventory and ask the system owner to name every account that has not been used, from their own knowledge.
Scales and criteria
Frequency
Access must be reviewed at least as often as its scope requires (see Frequency). Frequency is set by what the access can do, not by how convenient the system is to review. Where a system falls in two scopes, the shorter frequency applies to the access it describes: an ERP reviewed every 6 months still has its administrator accounts reviewed every 3.
Scope | Review at least | Why | Regulated minimum it meets |
|---|---|---|---|
Privileged and administrator access, all systems | Every 3 months | The access that can do most harm, and changes most often. | Shorter than any regulated minimum below |
Systems supporting a critical service (or a critical or important function, DORA; or cardholder data, PCI DSS) | Every 6 months | Regulated minimum for these systems. | DORA: Delegated Regulation (EU) 2024/1774 Article 21(e)(iv), at least every six months for systems supporting critical or important functions. PCI DSS 7.2.4: user accounts, including third-party accounts, at least every six months |
All other in-scope systems | Every 12 months | Regulated minimum for all other systems. | Delegated Regulation (EU) 2024/1774 Article 21(e)(iv): at least yearly for other systems |
- Service and system accounts in a PCI DSS environment are reviewed at the frequency your targeted risk analysis sets (PCI DSS 7.2.5.1); this template's default is the frequency of the system they run on.
- A review also runs out of cycle after [[a restructure, a merger, a security incident involving misuse of access, or a change of system owner]].
- Frequencies are in calendar months from the extract date of the last campaign for that system. ARM-01 (Reviews on time) counts systems reviewed within them.
Who reviews
Each entry goes to the reviewer who can answer its question. Nobody may review their own access or the access of anyone who reviews theirs.
Reviewer | Decides | Reviews |
|---|---|---|
Line manager | Does this person still need access to this system for their current job? | Every personal account of the people they manage |
System owner | Are these the right permissions for that job, and is each privileged or generic account justified? | The permissions behind each role; every privileged, generic, service and third-party account; every Cannot decide and unanswered entry |
Information security | Samples decisions for quality, and reviews every privileged account a second time. | A sample of every reviewer's decisions (AR-09); every privileged account, a second time (AR-06) |
Independence (AR-04) in practice:
- A line manager's own access is reviewed by their own manager, never by themselves.
- An administrator does not review the administrator group they belong to. The system owner reviews it with information security; where the system owner is also in the group, their own membership goes to [[a named executive outside the group]].
- The Head of Information Security's own access is reviewed by [[another executive, e.g. the Chief Financial Officer]], not by the security team.
- In a small team where independence is impossible, record the conflict and have [[an external reviewer or internal audit]] check those entries. An unavoidable conflict is handled like a segregation-of-duties conflict: recorded, with a compensating check.
The four decisions
Every entry must get one of the four decisions; nothing is kept by default when a reviewer does not answer.
Decision | Meaning | What follows |
|---|---|---|
Keep | Access is needed and the permissions are right. | Nothing changes. The reviewer's name and date are recorded. |
Modify | Access is needed but some permissions are not: remove the excess. | The excess permission is removed within its window (1 working day privileged, 5 working days standard) and confirmed (AR-07). The reviewer records which permission and why. |
Revoke | Access is not needed: remove it. | The account or the access is removed within its window and confirmed (AR-07). Leavers, dormant and orphan accounts are also raised as findings (AR-08). |
Cannot decide | The reviewer does not know the person or the permission: it goes to the system owner within [[2]] working days, never to Keep by default. | Goes to the system owner, who decides it. It is never counted as Keep, and it never waits for the next campaign. |
A reviewer who does not answer by the deadline has not decided. Their entries go to the system owner, then to the Head of Information Security (the escalation in the Access Review Campaign Operating Procedure). The campaign report names reviewers who did not answer.
Decision logic
What "needed for the job" means
Access is needed when the person's current job cannot be done without it, at the level of permission they hold, now or within the next [[review period]]. It is not needed because the person used to need it, because a colleague has it, because it was part of a standard bundle when they joined, or because removing it might cause a support call.
Least privilege applies to the permission as well as to the system. A person who needs to enter invoices needs the invoice-entry role, not the finance supervisor role that also approves them. That is a Modify, not a Keep.
The questions, in order
A reviewer asks these for each entry and stops at the first that decides it. The same questions in the same order are what make two reviewers reach the same answer.
# | Question | If the answer is no | If yes |
|---|---|---|---|
1 | Is the holder a current employee, contractor or supplier, or does the account have a named owner? | Revoke. A leaver or an orphan account: also a finding (AR-08) | Next question |
2 | Has the account signed in within [[90]] days? | Revoke, unless the system owner records why an unused account must stay (for example, a break-glass account): a dormant account is also a finding (AR-08) | Next question |
3 | Do I know this person and what their current job needs? | Cannot decide. To the system owner | Next question |
4 | Does their current job need this system? | Revoke | Next question |
5 | Does their job need every permission they hold here? | Modify: remove the permissions it does not need | Next question |
6 | Does the combination of duties appear in the Segregation of Duties Conflict Matrix? | Next question | A finding (AR-08). Modify to separate the duties; where they cannot be separated, the conflict goes to the exception process instead |
7 | Privileged, generic, service or third-party: does it have a named owner who answers for it? | Cannot decide until the system owner names one; never Keep (AR-06) | Keep |
Question 5 is the one reviewers skip. In the EXAMPLE campaign, 22 of the 69 changes were Modify decisions: access that was needed, at too high a level (EXAMPLE).
Segregation-of-duties conflicts
A conflict is a combination of duties that would let one person make and hide an unauthorised change, payment or access grant. This pack does not define conflicts; it uses the Segregation of Duties Conflict Matrix from the Security Exception, Waiver & Segregation of Duties pack, which lists them for each system and rates each High, Medium or Low. For each system covered by the matrix, the system owner checks the extract against it, or the tool does.
- Raise it as a finding (AR-08), with the person, the two duties, the matrix row and its rating. Do not simply remove one of the two roles and move on: the finding shows how the combination was granted.
- Separate it if the duties can be separated. The decision is Modify: one of the two permissions is removed within its window.
- If it cannot be separated (usually because the team is too small), it becomes an exception under the Security Exception & Waiver Standard (SD-04): recorded in the Security Exception Register, approved, and protected by a compensating control carried out by someone without the conflict, as the SoD Conflict Review & Compensating Control Procedure sets out.
- At the next campaign, check that the separation held, or that the exception is still approved and its compensating control was performed.
Removal windows and confirmation
Every Revoke or Modify must be carried out within its removal window and confirmed against a fresh extract. Windows are in working days (Monday to Friday, excluding [[public holidays]]) from the campaign's decision date.
Access | Removed within | Confirmed by |
|---|---|---|
Privileged and administrator access | 1 working day | A fresh extract of the system, taken after the last window ends |
All other access | 5 working days | The same fresh extract |
- Confirmation is against a fresh extract, not a closed ticket. A ticket shows someone was asked; the extract shows the access has gone.
- A removal is late when the access is removed after its window, which counts from the decision deadline (or from the quality check, for a decision the quality check changed); every removal is then confirmed against a fresh extract. ARM-02 (Removals confirmed on time) counts removals made within their window and confirmed, out of all Revoke and Modify decisions; its target is ≥ [[95%]].
- Where a supplier removes access (a hosted system), its removal time must fit inside the window. If it does not, the contract or the window must change; the gap is a process weakness (AR-11). In the EXAMPLE, that is PW-02.
- A leaver's access is removed by the leaver process on their last day, not by the review. A leaver found in a review means that process failed.
Findings and process weaknesses
Leavers, dormant accounts and segregation-of-duties conflicts found in review must be raised as findings, not just removed. Findings that show a process weakness (for example, leavers not removed) must go to the owner of that process with a fix and a date.
Found in review | Raised as | Goes to |
|---|---|---|
A leaver with access | Finding: which system, since when, why it was missed | HR and the system owner; several on one system → a process weakness |
A dormant account (no sign-in for [[90]] days) | Finding | System owner; a pattern → a process weakness |
An orphan account (no owner can be found) | Finding | System owner and information security |
A segregation-of-duties conflict | Finding, with the matrix row | System owner; if it cannot be separated, the exception process (Security Exception, Waiver & Segregation of Duties pack) |
The same cause behind several findings | Process weakness (PW-nn), with an owner, a fix and a date | The owner of that process, not the reviewer |
Findings and weaknesses are tracked in the Access Review Findings & Revocation Tracker until closed. ARM-04 (Process weaknesses open) counts weaknesses not yet fixed; the target is zero past their date.
Detecting a rubber-stamp review
Campaign quality must be checked for rubber-stamping (see Detecting a rubber-stamp review) before the campaign is closed. A rubber-stamp review is one where the reviewer confirmed the list without looking. These signals are checked by information security on every campaign, before it is closed:
Signal | Why it matters | What happens |
|---|---|---|
A reviewer keeps 100% of a large list (more than [[25]] entries) in one sitting | Nobody's team is so stable that every one of a long list of entries is still exactly right. | The list is sent back, or re-reviewed by the system owner; a sample of [[10]] entries is checked by information security |
Decisions made faster than [[5]] seconds each on average | At under [[5]] seconds an entry, the reviewer cannot have read the permissions. | Information security checks a sample of [[10]] entries; if any is wrong, the whole list is re-reviewed |
Leavers or dormant accounts (no sign-in for [[90]] days) marked Keep | The data showed the answer and the reviewer ignored it. This is the strongest signal. | The entry is changed to Revoke by the system owner, and the reviewer's other decisions are sampled |
Privileged or generic accounts marked Keep without a named owner | AR-06 requires an owner; a Keep without one is not a decision. | Changed to Cannot decide until the system owner names an owner |
- The campaign is not closed until every signal found has been dealt with. The campaign report states how many signals were found and what was done.
- A reviewer whose lists show a signal in two campaigns running is reported to their own manager, and gets [[a short briefing from information security]] before the next.
Guidance — delete before approval
The thresholds ([[25]] entries, [[5]] seconds, [[90]] days) are template defaults. Where your review tool records decision times, use them; where reviews are on a spreadsheet, the first and third signals can still be checked from the returned file.
Evidence
Each campaign must keep an evidence file: scope, extracts, decisions, changes, confirmation and sign-off. The Access Review Evidence & Audit File Checklist lists each item and where it is kept.
Evidence | Shows |
|---|---|
Scope: the systems in the campaign, their owners and frequencies, and the date of the last review of each | AR-01, AR-02 |
The extracts as taken, dated, with how completeness was checked | AR-03 |
Reviewer assignments, and how conflicts of independence were handled | AR-04 |
Every decision, with the reviewer's name, the date and a reason for Modify and Revoke | AR-05, AR-06 |
Change tickets for every Modify and Revoke, and the fresh extract that confirms them | AR-07 |
Findings and process weaknesses, with owners and dates | AR-08, AR-11 |
The quality check and what was done about each signal | AR-09 |
Sign-off by the campaign coordinator and the system owners; the campaign report | AR-10, AR-12 |
Evidence is kept for [[3 years, or longer where a regulator or contract requires]]. It is the organisation's own record, held in [[your evidence location]].
Measures
Campaign results must be reported as risk removed and weaknesses found, not only as percentage completed. Every campaign reports the four headline measures, in the Access Review Outcome Report Template:
Measure | Definition | Target |
|---|---|---|
ARM-01 Reviews on time | In-scope systems reviewed within their frequency, out of all in-scope systems. | All |
ARM-02 Removals confirmed on time | Revoke and Modify decisions confirmed removed within their window, out of all such decisions. | ≥ [[95%]] |
ARM-03 Access that should not have existed | Leaver, dormant and orphan accounts found in the campaign. | Falling campaign on campaign |
ARM-04 Process weaknesses open | Findings sent to a process owner (AR-11) not yet fixed. | Zero past their date |
Completion is reported too, but never alone. "100% reviewed" says the lists came back; ARM-03 says what they found.
Worked examples
The examples come from the one EXAMPLE organisation used throughout the pack: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. Its campaign UAR-2026-Q3 took extracts on 1 September 2026, had decisions due on 15 September 2026 and closed on 29 September 2026. Figures are as at 30 September 2026 (EXAMPLE); replace them with your own.
The campaign, by system:
System | Review every | Entries | Keep | Modify | Revoke | Cannot decide | Leaver / dormant / orphan | Conflicts |
|---|---|---|---|---|---|---|---|---|
SYS-01 ERP (hosted; P06 SUP-004) | 6 months | 164 | 139 | 11 | 12 | 2 | 3 / 6 / 1 | 1 |
SYS-02 Warehouse management system | 6 months | 212 | 188 | 6 | 18 | 0 | 7 / 9 / 0 | 0 |
SYS-03 Directory administrator groups | 3 months | 14 | 10 | 1 | 3 | 0 | 1 / 0 / 1 | 0 |
SYS-04 Online ordering admin console | 3 months | 9 | 7 | 0 | 2 | 0 | 0 / 1 / 1 | 0 |
SYS-05 Shared finance drive | 12 months | 96 | 80 | 4 | 12 | 0 | 2 / 4 / 0 | 0 |
Total | 495 | 424 | 22 | 47 | 2 | 13 / 20 / 3 | 1 |
Leaver, dormant and orphan accounts are counted within Revoke. Together they are the 36 accounts that should not have existed (ARM-03) (EXAMPLE).
Example 1 — SYS-01, the ERP: a critical system run by a supplier
Step | SYS-01 ERP (hosted; P06 SUP-004) |
|---|---|
Scope and frequency (AR-01, AR-02) | Owner: Chief Financial Officer. The ERP supports finance and payroll and warehouse dispatch, both critical services, so it is reviewed every 6 months; its administrator accounts every 3 months. (EXAMPLE) |
Extract (AR-03) | Supplier-run user report, requested by ticket, taken on 1 September 2026. It includes the provider's own support accounts (SUP-004), which are third-party accounts. (EXAMPLE) |
Reviewers (AR-04, AR-06) | Line managers for their staff's accounts. The Chief Financial Officer as system owner for the permissions behind each role and for every privileged, generic, service and third-party account; information security a second time for the privileged accounts. (EXAMPLE) |
Decisions (AR-05) | 164 entries: 139 Keep, 11 Modify, 12 Revoke, 2 Cannot decide. The 2 Cannot decide entries went to the Chief Financial Officer within [[2]] working days; the table counts the line manager's answer, and the owner's decision is recorded against the same entries. (EXAMPLE) |
What the Revokes were (AR-08) | 3 leavers, 6 dormant accounts (no sign-in for [[90]] days) and 1 orphan account, each raised as a finding; 2 accounts no longer needed for the holder's job. (EXAMPLE) |
Segregation of duties | 1 conflict: one user could create or change suppliers and their bank details and approve payments, a combination the Segregation of Duties Conflict Matrix rates High (row SOD-FI-01 in the template matrix). Raised as a finding (AR-08). Separated by a Modify; no exception: the Chief Financial Officer separated the duties with a Modify, requested on 15 September 2026, removed by the provider on 22 September 2026 within the standard window and confirmed on the fresh extract of 23 September 2026. Had the team been too small to separate them, the conflict would have gone to the exception process under the Security Exception & Waiver Standard (SD-04), with a compensating control. (EXAMPLE) |
Removal (AR-07) | 23 changes, requested from the provider by ticket. Windows: privileged by 16 September 2026, standard by 22 September 2026. 3 late: finance administrator role removed from 3 accounts (2 Modify, 1 Revoke), removed on 22 September 2026 against a privileged window that ended 16 September 2026. The ERP provider (P06 SUP-004) acts on a removal ticket in 5 working days; privileged access must go in 1 (PW-02). All confirmed on the fresh extract of 23 September 2026. (EXAMPLE) |
Process weakness (AR-11) | PW-02: The ERP provider takes 5 working days to remove users; our window is 5 for standard access and 1 for privileged. Owner Chief Financial Officer; due 15 December 2026. The fix is in the contract with the provider (the Third-Party Security Risk Management pack), not in the review. (EXAMPLE) |
What it shows | A hosted system is reviewed like any other, including the supplier's own accounts. The supplier's removal time is part of your window, and when it does not fit, that is a weakness to fix, not a reason to widen the window quietly. |
Example 2 — SYS-03, the directory administrator groups: privileged access
Step | SYS-03 Directory administrator groups |
|---|---|
Scope and frequency | Owner: Head of IT. Administrator access to the directory reaches every other system, so it is reviewed every 3 months (privileged and administrator access, all systems). (EXAMPLE) |
Extract | Group membership export, taken on 1 September 2026, with last sign-in for each account. (EXAMPLE) |
Reviewers (AR-04, AR-06) | The Head of IT and information security review every membership. The Head of IT's own membership is reviewed by the Head of Information Security, because nobody reviews their own access (AR-04); the Head of Information Security also gives every membership its second review (AR-06). (EXAMPLE) |
Decisions | 14 entries: 10 Keep, 1 Modify, 3 Revoke, 0 Cannot decide. The Revokes were 1 leaver, 1 orphan account and 1 membership no longer needed; the Modify (workbook entry S03-05) removed account-creation rights from the Service Desk Lead's helpdesk administrator role: resets and unlocks stay, creating accounts belongs to the joiner process. (EXAMPLE) |
Removal (AR-07) | Privileged window: 1 working day, so by 16 September 2026. All 4 confirmed on time against the fresh extract. (EXAMPLE) |
Findings (AR-08) | The leaver and the orphan administrator account are findings: an administrator account nobody owns is exactly what an attacker looks for. (EXAMPLE) |
Link to the risk register | This review is one of the controls counted in the residual rating of R-07 "Administrator misuses privileged access" (owner Head of IT) in the Information Security Risk Management pack. If privileged reviews stopped, or kept finding orphan accounts, that rating would need reassessing. (EXAMPLE) |
What it shows | A small list is not a small risk. Fourteen entries reviewed properly every quarter protect more than a hundred reviewed carelessly once a year. |
The campaign's measures
Measure | EXAMPLE result, UAR-2026-Q3 | How it is worked out |
|---|---|---|
ARM-01 Reviews on time | 5 of 5 | Every system in scope was reviewed in this campaign; the shortest frequency is 3 months (EXAMPLE) |
ARM-02 Removals confirmed on time | 65 of 69 = 94.2%: below the ≥ [[95%]] target | 47 Revoke + 22 Modify = 69 removals; 4 late (3 on SYS-01, 1 on SYS-05) (EXAMPLE) |
ARM-03 Access that should not have existed | 36 | 13 leavers + 20 dormant + 3 orphan (EXAMPLE) |
ARM-04 Process weaknesses open | 2 open, none past its date | PW-01 due 30 November 2026; PW-02 due 15 December 2026; as at 30 September 2026 (EXAMPLE) |
Reported as AR-12 requires: the campaign removed 69 pieces of access that were wrong, including 36 accounts that should not have existed and 1 segregation-of-duties conflict, and found 2 process weaknesses. PW-01 (warehouse leavers are not removed from the warehouse system: HR's leaver notice does not reach its owner) explains why the warehouse management system had the most leavers (EXAMPLE).
How to defend the method to an auditor
An auditor will usually test that access rights are reviewed at a defined interval by people who can judge them; that privileged access gets closer attention; that decisions are acted on; and that the review is evidenced (ISO/IEC 27001 Annex A 5.18 and 8.2). Regulated entities will also be asked for the review frequencies against Delegated Regulation (EU) 2024/1774 Article 21(e), and PCI DSS entities for the six-monthly review of user accounts (7.2.4) and the removal of inactive accounts within 90 days (8.2.6).
Evidence to have ready
- This methodology, approved, and the inventory of in-scope systems with owners and frequencies.
- For the last [[two]] campaigns: the evidence file for each system (see Evidence).
- The quality check for each campaign, with what was done about each signal.
- The findings and process weaknesses, with their owners, dates and status, from the Access Review Findings & Revocation Tracker.
- The campaign reports with ARM-01, ARM-02, ARM-03, ARM-04.
The re-performance test
Invite the auditor to pick [[5]] Revoke or Modify decisions from a closed campaign. For each, follow the decision to the change ticket and to the fresh extract that shows the access gone, and check the date against the removal window. Then pick [[5]] Keep decisions on privileged accounts and ask the named owner why each is needed. Run this test yourself after each campaign.
Questions auditors commonly ask
Question | Answer the method gives |
|---|---|
How do you know the extract was complete? | It is taken on a stated date with names, roles, permissions and last sign-in (AR-03), and its completeness is checked against the system before the lists go out. |
What happens when a reviewer does not respond? | Nothing is kept by default (AR-05). Unanswered entries go to the system owner, then to the Head of Information Security; the report names the reviewer. |
How do you stop managers approving everything? | Four signals are checked before each campaign closes (AR-09); a list that shows one is re-reviewed. |
Who reviews the administrators? | The system owner and information security, every quarter; nobody reviews their own access (AR-04, AR-06). |
How do you know removals happened? | A fresh extract after the removal windows, not the ticket (AR-07). A removal is late when the access is removed after its window, which counts from the decision deadline (or from the quality check, for a decision the quality check changed); every removal is then confirmed against a fresh extract. Late removals are counted in ARM-02. |
What did the review actually find? | ARM-03 counts access that should not have existed; ARM-04 the process weaknesses behind it (AR-12). |
Limitations
A periodic review is a detective control, and it has known weaknesses.
Limitation | Effect | How it is managed |
|---|---|---|
It is periodic. | Access granted in error can exist for up to 12 months on a lower-scope system before a review sees it. | The joiner, mover and leaver process is the preventive control; the review measures it (AR-08, AR-11). Privileged access is reviewed every quarter. |
It depends on the extract. | Access the extract does not show — a local account, an API key, a permission granted outside the role model — is never reviewed. | Completeness is checked (AR-03); the system owner confirms every route in; gaps are findings against AR-01. |
Reviewers judge from names and role labels. | A role called "Standard user" can carry powerful permissions. | Role definitions in plain words are an input; the system owner, not the line manager, decides permissions. |
Quality signals catch obvious rubber-stamping only. | A reviewer who varies their answers without thinking passes the checks. | Sampling by information security; the re-performance test; calibration. |
Segregation of duties is only as good as the matrix. | A conflict not in the matrix is not found. | The Segregation of Duties Conflict Matrix is reviewed annually and after any restructure or new core system (Security Exception, Waiver & Segregation of Duties pack). |
Suppliers remove access on their own timescale. | A window can be missed for reasons the organisation does not control. | The removal time is written into the contract; a gap is a process weakness (PW-02 in the EXAMPLE). |
Calibration and review
Calibration between reviewers
- Before the first campaign, and every year after, give two reviewers the same [[10]] entries, including the cases below, and ask each for a decision with a reason.
- Compare. Where they differ, find which question in "The questions, in order" they answered differently, and whether the wording or the inputs caused it.
- Change the wording or the reviewer instructions, not the reviewers' memories, and record the change below.
Calibration cases
Each case has one right answer under this method. Use them in reviewer briefings and in the calibration exercise.
# | Entry | Decision | Why |
|---|---|---|---|
1 | An accounts payable clerk with the invoice-entry role, signed in yesterday, same job as last review | Keep | The ordinary case: needed, and the permissions fit the job |
2 | A warehouse picker who left in August; account still enabled | Revoke | A leaver: removed and raised as a finding (AR-08); several on one system point to a process weakness (AR-11) |
3 | A buyer who moved to sales four months ago and still holds purchase-order approval in the ERP | Modify | A mover: keeps the sales role, loses the approval (least privilege) |
4 | A current employee whose account has not signed in for more than [[90]] days | Revoke | Dormant: re-requested if needed again; raised as a finding (AR-08) |
5 | A shared warehouse terminal login with no named owner | Cannot decide | A generic account may be kept only with a named owner (AR-06); the system owner names one or revokes it |
6 | A contractor the line manager does not recognise | Cannot decide | Goes to the system owner within [[2]] working days; never to Keep by default |
7 | One user can create or change suppliers and their bank details and approve payments | Modify | A High conflict in the Segregation of Duties Conflict Matrix: raised as a finding and separated by removing one of the two duties. Only a conflict that cannot be separated goes to the exception process (Security Exception, Waiver & Segregation of Duties pack) |
8 | An IT engineer in the domain administrator group whose job needs administration of the helpdesk tool only | Modify | Privileged access narrowed to what the job needs; reviewed by the system owner and information security (AR-06) |
9 | The ERP provider's support account, used last month, under a current contract | Keep | A third-party account kept on the evidence of a current contract and recent use, with a named owner for us |
10 | An account whose holder the reviewer cannot identify from the extract, with no owner in HR or the directory | Revoke | An orphan account: removed and raised as a finding (AR-08) |
Every campaign
After each campaign, the Head of Information Security checks these and records the result:
Check | Signal that the method needs attention |
|---|---|
Quality signals | More than [[1 in 10]] reviewers show a signal, or the same reviewer twice. |
Cannot decide | More than [[5%]] of entries Cannot decide: the extract or the people list is not giving reviewers what they need. |
Late removals | ARM-02 below target for two campaigns running. |
Findings | ARM-03 not falling campaign on campaign: the joiner, mover and leaver process is not improving. |
Review
This methodology is reviewed at least every 12 months, and also after a restructure, a new core system, an incident involving misuse of access, or a change in a regulator's expectations. Changes to frequencies or removal windows are approved by [[executive management]].
Calibration record
Date | Reviewers | Entries | Differences | Change made | Approved by |
|---|---|---|---|---|---|
[[YYYY-MM-DD]] | [[Names]] | [[n]] | [[n]] | [[None / description]] | [[Name]] |
Related documents
Document | Relationship |
|---|---|
Access Review Campaign Operating Procedure | Runs a campaign under these rules, step by step, with the timetable |
Access Review Scope & System Inventory | The in-scope systems, owners, scopes and extract methods (AR-01, AR-02) |
Reviewer Instruction Pack & Campaign Communications | What reviewers are told, and the campaign messages |
Access Review Campaign Workbook | Holds the extracts and every decision (AR-03, AR-05) |
Access Review Findings & Revocation Tracker | Tracks every removal, finding and process weakness to closure (AR-07, AR-08, AR-11) |
Access Review Evidence & Audit File Checklist | The evidence file for each campaign (AR-10) |
Access Review Outcome Report Template | Reports the four measures (AR-12) |
Segregation of Duties Conflict Matrix; Security Exception & Waiver Standard | The conflicts checked in review, and the exception route when they cannot be separated (Security Exception, Waiver & Segregation of Duties pack) |
Information Security Risk Management pack | Risk R-07, privileged misuse, which the privileged review helps control |
Third-Party Security Risk Management pack | SUP-004, the ERP provider, whose removal times the contract must fit |
Adapting this template
Guidance — delete before approval
Small organisation: keep the four decisions, the frequencies for privileged and critical access, the fresh-extract confirmation and the quality check; they are what an auditor tests. A spreadsheet per system is enough. Where the IT manager is both administrator and system owner, have [[an executive or an external adviser]] review the administrator accounts with them, so that AR-04 still holds. Start with the [[5]] systems that matter most.
Regulated entity (NIS2, DORA, PCI DSS): NIS2 Article 21(2)(i) expects access control policies; this methodology is the review part of them. A DORA financial entity limits access to what legitimate, approved functions need (Article 9(4)(c)) and, under Delegated Regulation (EU) 2024/1774, limits generic and shared accounts and keeps users identifiable (Article 21(c)) and reviews access at least every six months for systems supporting critical or important functions and at least yearly for the rest (Article 21(e)): the frequency table meets both. A PCI DSS entity reviews user accounts, including third-party accounts, at least every six months (7.2.4), reviews application and system accounts at the frequency its targeted risk analysis sets (7.2.5.1), and removes or disables inactive accounts within 90 days (8.2.6): keep the dormant threshold at or below 90 days.
IT run by a service provider: the provider takes the extracts and makes the changes, but the system owners, the reviewers and the decisions stay in your organisation. Put the extract format, the removal times (1 working day privileged, 5 standard) and the provider's own accounts into the contract. The provider's staff accounts on your systems are third-party accounts and are reviewed like any other.
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); Regulation (EU) 2022/2554 (DORA); Delegated Regulation (EU) 2024/1774; PCI DSS v4.0.1.
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 5.15 — Access control | Whole methodology: the review part of the access control rules |
ISO/IEC 27001:2022 | Annex A 5.18 — Access rights | Frequency; reviewers; decisions; removal and confirmation (AR-02 to AR-07) |
ISO/IEC 27001:2022 | Annex A 8.2 — Privileged access rights | Privileged accounts reviewed quarterly by the system owner and information security (AR-06) |
ISO/IEC 27001:2022 | Annex A 5.3 — Segregation of duties | Segregation-of-duties conflicts found in review (AR-08) |
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 methodology: permissions 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” | Scope: every account, including generic, service and third-party accounts, has an owner (AR-06) |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(i) — “human resources security, access control policies and asset management” | Whole methodology, as part of the access control policies |
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 | Decision criteria: access limited to what the job needs |
DORA — Delegated Regulation (EU) 2024/1774 | Article 21(c) — user accountability: generic and shared accounts limited, and users identifiable for their actions | Generic and shared accounts limited and owned (AR-06) |
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 | Frequency table; reviewers; removal windows |
PCI DSS v4.0.1 | Requirement 7.2.4 — user accounts and their access privileges, including third-party accounts, reviewed at least every six months | Frequency: six-monthly review, including third-party accounts |
PCI DSS v4.0.1 | Requirement 7.2.5.1 — access for application and system accounts reviewed periodically, at a frequency set by a targeted risk analysis | Service and system accounts reviewed at a risk-based frequency |
PCI DSS v4.0.1 | Requirement 8.2.6 — inactive user accounts removed or disabled within 90 days | Dormant accounts: no sign-in for [[90]] days leads to Revoke |
Definitions
Term | Meaning in this methodology |
|---|---|
Campaign | One round of review across the systems due, with one extract date, one decision date and one close date. |
Dormant account | An account with no sign-in for [[90]] days or more. |
Extract | The list of every account on a system, with names, roles, permissions and last sign-in, taken on a stated date (AR-03). |
Fresh extract | A new extract taken after the removal windows, used to confirm that removals happened (AR-07). |
Generic account | An account used by more than one person, or by a role rather than a person. |
Leaver | Someone who has left the organisation or ended their contract. |
Least privilege | Giving each person only the access and permissions their current job needs. |
Mover | Someone who has changed job inside the organisation. |
Orphan account | An account with no current holder or owner who can be identified. |
Privileged account | An account that can change a system, its settings, its users or its security. |
Process weakness | A cause behind several findings, sent to the owner of that process with a fix and a date (AR-11). |
Removal window | The working days from the decision date by which a Revoke or Modify must be done: 1 for privileged, 5 for other access. |
Rubber-stamp review | A review where the reviewer confirmed entries without judging them (AR-09). |
Segregation-of-duties conflict | A combination of 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. |
Service account | An account used by software rather than a person. |
System owner | The manager accountable for a system, who decides what its roles allow and owns its privileged and generic accounts. |
Working day | Monday to Friday, excluding [[public holidays where you are]]. |