The user access review is the most widely performed IT control in the world and one of the least effective. Every quarter, thousands of managers receive a spreadsheet or a certification task listing the people who report to them and the systems they can reach, and most of them click approve on every line in under five minutes. The population was extracted by someone who could not say whether it was complete. The entitlements were described in codes the reviewer could not read. The revocations the reviewer did request were sent to a help desk and, in a third of cases, never executed. The control’s evidence is a signed list, and the signed list proves that a list was signed. When the audit later finds terminated employees with live accounts, the review that was supposed to catch them has been operating, on paper, for years.
This guide was rewritten in September 2026 and expanded from the original August 2026 version to add the scoping tiers, the population completeness method in full, the decision-quality data pack that turns reviewers from signers into reviewers, the revocation follow-through loop with its evidence, a template pack containing the reviewer instruction memo and the completeness record, a ten-test program for auditing someone else’s review, and a worked example at MidState Beverage, where a quarterly review of 412 ERP users was rebuilt inside an FY27 access engagement after the previous quarter’s review had approved nine terminated employees. It is written for two readers: the person designing or running a review, and the auditor testing one. The companion guides are the identity and access management audit, which covers the lifecycle controls the review compensates for, and the ERP segregation of duties analysis, whose results the review should surface.
In this guide
- What a user access review is for, and why most of them are theater
- Scoping: tiers, frequency, reviewers and what gets reviewed
- Population completeness: the test the review usually fails before it starts
- Decision quality: the data pack that makes a reviewer able to review
- Revocation follow-through: where the control actually operates
- Automation: what a certification tool changes, and what it does not
- Evidence: what a complete review package contains
- The template pack: reviewer instruction memo and completeness record
- Auditing a user access review: the ten-test program
- Worked example: MidState Beverage rebuilds its ERP review
- Common mistakes
What a user access review is for, and why most of them are theater
A user access review is a detective control. Its job is to catch what the preventive controls of the identity lifecycle missed: the account that should have been removed when the employee left, the role that should have been changed when the employee moved, the entitlement that was granted for a project and never withdrawn, the contractor whose engagement ended, the conflict that was created when two clean roles were combined. It answers three questions for every line: should this identity exist, should it have this access, and does the access create a conflict. Those three questions define the evidence a reviewer needs, and most reviews provide none of it, which is the mechanical reason they fail. A manager shown a user identifier and a role code called ZFI_AP_02 cannot answer any of the three; the only decision available is approve, and approve is what happens.
The review is also the control that compensates for the weakness of every other access control. Where the joiner-mover-leaver process is manual and the termination feed from HR is unreliable, which describes most mid-sized organizations, the review is the only control that will eventually remove a departed employee’s access. That makes its effectiveness disproportionately important and its typical condition disproportionately dangerous: an organization with weak provisioning and a theatrical review has no working control over who can reach its systems, however many signatures it holds. The preventive and detective controls guide explains why a detective control must be designed to detect; this guide applies that to the one control everyone already has.
Scoping: tiers, frequency, reviewers and what gets reviewed
Reviewing everything quarterly guarantees that nothing is reviewed well. Scope follows risk: the systems that carry financial transactions, sensitive data and administrative power are reviewed most often and most deeply, and the rest are reviewed on a cycle that the organization can actually sustain. The table gives a workable tiering. Two categories are reviewed on their own schedule regardless of the system’s tier: privileged and administrative access, which is reviewed by the security function and not by line managers, and service, generic and shared accounts, which are reviewed by their named owner against the purpose for which each exists. The scope decision is documented once, in the access review policy, with the system inventory that the IT audit plan is built on, so that the systems out of scope are out of scope by decision rather than by omission.
| Tier | Systems | Frequency | Reviewer | What is reviewed |
|---|---|---|---|---|
| 1 | ERP and financial systems, identity directory, banking and treasury platforms, payroll and HR, systems in SOX scope, systems holding regulated data | Quarterly | Line manager for existence and reasonableness; application owner for entitlements; both decisions recorded | Every user, every role or entitlement in business language, SoD conflicts, last logon, changes since last review |
| 2 | Operational systems with financial or customer data, warehouse, fleet, CRM, procurement tools | Semi-annually | Application owner with line manager confirmation for movers and leavers | Users and high-risk entitlements; full entitlement review annually |
| 3 | Collaboration and productivity tools, low-risk SaaS | Annually, or by automated reconciliation to HR | System owner | Existence against HR; external accounts |
| Privileged | Administrative accounts on every tier-1 and tier-2 system, directory and cloud administration, database administration, backup administration | Quarterly, monthly where the population changes often | Security function with the platform owner | Every privileged account, its owner, justification, last use, vault enrollment; see the privileged access guide |
| Non-human | Service, interface, generic and shared accounts | Annually, and at every owner change | Named account owner | Purpose, interactive logon capability, credential management, continued need |
Three scoping decisions are commonly wrong. Reviewing users but not entitlements: a review that confirms a person should have access to the ERP without confirming which roles they hold cannot detect a mover who kept the old job’s roles. Assigning the wrong reviewer: a line manager can say whether a person still works for them and roughly what they do; only the application owner can say whether a role is appropriate for that job, and privileged access is nobody’s line-management responsibility. And ignoring external identities: contractors, vendor support accounts and partner logins usually have no manager in the organization and therefore no reviewer unless one is assigned.
Population completeness: the test the review usually fails before it starts
A review can only remove access that appears on the list, and the list is wrong more often than anyone assumes. The extract was taken from a reporting copy rather than the system; it excluded locked accounts that could be unlocked; it excluded accounts created after the extract date; it listed one identifier per person when some people have three; it omitted the generic account the whole depot uses. Completeness is established in two directions before any reviewer sees a line. The system side: the user list is extracted from the system itself by an administrator with the review coordinator observing, the query and its parameters are recorded, the count is reconciled to the system’s own user count, and the extract is treated as information produced by the entity under the IPE method. The organization side: the list is reconciled to the HR active employee list and the contractor register through an identity map that links each system identifier to a person, and every difference is classified and resolved before the review is issued.
| Reconciliation result | What it means | Action before the review is issued |
|---|---|---|
| System account with no match in HR or the contractor register (orphan) | A generic, service or test account, an unrecorded contractor, or a person who left before HR records began | Attribute to an owner or disable; orphans are never sent to a line manager who cannot recognize them |
| System account matched to a person HR shows as terminated | The leaver process failed; the account should already be gone | Disable immediately; record as a lifecycle control failure, not a review finding; count reported to the security function |
| Person active in HR with no account | Normal for staff who do not use the system | None; noted as expected |
| Person with more than one account | Multiple identifiers, test accounts, or a second account created to work around a lockout | Consolidate or justify; all accounts assigned to the same reviewer so the person’s total access is visible |
| Account locked or expired but not deleted | Dormant access that can be reactivated | Include with a dormant flag; the reviewer decides removal |
| Account created after the extract date | Timing | Included in the next cycle; noted so that the review period is unambiguous |
Entitlement completeness is the second half. Every role or entitlement on the list needs a description in business language, an owner, and its segregation of duties classification, held in a role catalog that is itself reconciled to the system’s role inventory before each cycle. A reviewer shown “ZFI_AP_02” will approve it; a reviewer shown “Accounts payable: enter and approve supplier invoices (SoD-sensitive: conflicts with vendor master maintenance)” has been given something to decide. Building the catalog is a one-time investment that pays back in every subsequent cycle, and its absence is the single most common design finding when an auditor tests a review.
Decision quality: the data pack that makes a reviewer able to review
Reviewers approve everything because approving everything is the only decision the review has equipped them to make. The remedy is a data pack per line that answers the three questions in advance. Should this identity exist: the person’s name, job title and department from HR, their manager, their status, and the date of any recent move. Should it have this access: each entitlement in business language, when it was granted and by whom, the last date it was used, whether peers in the same job hold it, and whether it was added since the last review. Does it create a conflict: the segregation of duties conflicts the person’s combined access creates, flagged from the latest SoD analysis, with the pair and the rating. A reviewer with that pack can see the accounts payable clerk who still holds the treasury role from a secondment, the salesperson who has not logged in for six months, and the depot manager whose access lets them enter and approve overrides; a reviewer without it sees a list of names.
Decision quality is then measured, not assumed. The review coordinator, or the auditor testing the review, computes for each reviewer the number of lines, the elapsed time from opening to submission, the proportion approved, the proportion of dormant accounts approved, and the proportion of flagged SoD conflicts approved without comment. A reviewer who approved 140 lines in three minutes including eleven dormant accounts and four high-rated conflicts has not reviewed anything, and the review is re-issued to them with the coordinator present. Certification tools, whether the identity directory’s own access review feature, an identity governance platform or a spreadsheet with a submission log, record enough to compute these measures; the practice is to publish them, because reviewers who know the measures are read behave differently. The table gives the pack and the measures.
| Question | Data provided per line | Decision-quality measure | Threshold that triggers re-review |
|---|---|---|---|
| Should this identity exist? | Name, job title, department, manager, HR status, move or leave date, account status, last logon | Dormant accounts (no logon in 90 days) approved without comment | Any dormant account approved without a reason |
| Should it have this access? | Entitlement in business language; grant date and grantor; last use; peer comparison; added since last review | Time per line; proportion approved; entitlements unused for 180 days approved | Under 10 seconds per line, or 100 percent approval on more than 30 lines |
| Does it create a conflict? | SoD conflicts from the latest analysis with pair and rating; mitigating control if any | High-rated conflicts approved without a mitigation or acceptance reference | Any high-rated conflict approved without reference |
Revocation follow-through: where the control actually operates
A review that identifies access to remove and does not remove it has operated as a survey. The control operates at the moment the entitlement is gone from the system, and everything between the reviewer’s decision and that moment is where reviews fail quietly. The follow-through loop has five parts: every revocation decision generates a ticket or a task automatically, with the system, the identity and the entitlement; the ticket has a service level, typically five business days for standard access and one for privileged or terminated-user access; execution is evidenced by the system’s own change record, not by the ticket being closed; a completion check compares the revocation list to a fresh extract of the system after the service level has elapsed; and the results, including revocations still open, are reported to the reviewers and to the security function. The completion check is the step most organizations omit, and it is the one that finds the revocations closed by the help desk without being done.
Two design points matter. Revocations of the highest-risk category, terminated users and privileged access, should not wait for the review cycle at all; the review is a backstop for a leaver process that should have acted on the day, and any terminated user found by a review is a lifecycle finding to be reported as such. And where a reviewer requests a change rather than a removal, a role to be reduced rather than deleted, the request is tracked to completion in the same loop, because partial revocations are the ones that get lost. The issue log template works well as the tracker for the open items across cycles.
Automation: what a certification tool changes, and what it does not
Identity governance platforms and the access review features built into cloud directories automate the mechanics that make manual reviews fail: they pull the population from connected systems on a schedule, join it to the HR feed, present entitlements with descriptions from a catalog, route lines to the right reviewer by rule, record every decision with a timestamp, generate the revocation automatically and, on connected systems, execute it and confirm it. Where such a tool is properly connected, the completeness record becomes a configuration to test rather than a document to complete, and the revocation loop closes by itself. The auditor’s tests move accordingly: is every tier-1 system connected or covered by a manual process; is the HR feed the authoritative source and is it current; is the catalog maintained; are the routing rules right, especially for privileged, external and non-human accounts; are decisions and revocations actually recorded and executed as the tool claims, which is verified against the target system exactly as for a manual review.
What the tool does not change is the decision. A reviewer presented with a well-described line in a certification portal can still approve it in two seconds, and the approve-all pattern is, if anything, faster in a tool than in a spreadsheet. The decision-quality measures, the thresholds and the re-review remain the control over the reviewer, and the better tools compute the measures for you. Nor does the tool remove the need for the periodic review where automation of the lifecycle is genuine: if leavers are disabled on the day by the HR feed and movers’ access is adjusted by role at transfer, the review’s population of real findings shrinks and its frequency can fall for lower tiers, but the tier-1 review continues as the evidence that the automation is working. The organization that has automated provisioning and stopped reviewing has a preventive control with no detective check on it, which the IAM audit guide treats as a design gap in its own right.
Evidence: what a complete review package contains
The package for each cycle and system is what an auditor, an external auditor or a regulator will ask for, and it is what makes the review defensible. It contains the extract with its query, parameters, date and reconciliation to the system count; the HR and contractor reconciliation with each difference resolved; the role catalog version used; the review assignments and the data pack issued; each reviewer’s decisions with timestamps and comments; the decision-quality measures and any re-reviews; the revocation list with tickets, service levels and system change evidence; the completion check against the fresh extract; and the summary reported to management. A package missing the reconciliation or the completion check is missing the two elements that distinguish a review from a signature. The workpaper example shows the layout conventions, and the audit evidence guide the general standard.
The template pack: reviewer instruction memo and completeness record
Two documents carry most of the design. The reviewer instruction memo is issued with every cycle and states what the reviewer is deciding, how, by when, and what happens to their decisions; it is short because reviewers do not read long memos, and it is specific because vague instructions produce approve-all. The completeness record is completed by the coordinator before the review is issued and filed in the package; it is the evidence that the population was established. Both are written to be copied as they stand, with the bracketed guidance removed. The templates directory lists the companion documents, including the issue log used as the revocation tracker.
Reviewer instruction memo. Review cycle: ________ System: ________ Issued to: ________ Issued by: ________ Date issued: ________ Decisions due: ________
1. What you are deciding. For each person and each entitlement listed, you are confirming three things: that the person should have an account on this system; that each entitlement is needed for the job they do today; and that where a segregation of duties conflict is flagged, either the access is reduced or a mitigating control or approved acceptance is referenced. [State the period the review covers and the extract date.]
2. What you have been given. Each line shows the person’s HR details and status, each entitlement in plain language with the date granted and last used, whether peers in the same role hold it, whether it was added since the last review, and any conflict it creates. [Name the role catalog version.]
3. The decisions available. Retain; remove; reduce (state the entitlement to remove); transfer (the person no longer reports to you: name the correct reviewer). Every dormant account and every flagged conflict requires a comment whatever the decision.
4. What happens next. Removals and reductions generate tickets automatically with a service level of ________ business days; you will receive confirmation from the system record when each is complete, and a list of any still open after the service level.
5. Quality. Reviews are measured on time per line, approval rate, and dormant accounts and conflicts approved without comment; reviews outside the thresholds are re-issued with the coordinator present. [State the thresholds.]
6. Help. [Coordinator contact; where to see the role catalog; how to query an entitlement you do not recognize.]
Population completeness record. Review cycle: ________ System: ________ Prepared by: ________ Observed by: ________ Date: ________
1. System extract. Source table or report: ________. Query and parameters: ________. Extract date and time: ________. Row count: ________. System’s own user count at extract time: ________. Difference and explanation: ________. Locked or expired accounts included with flag: ________.
2. HR and contractor reconciliation. HR active headcount at extract date: ________. Contractor register count: ________. Identity map version: ________. Orphan accounts: ________ (disposition of each). Accounts of terminated persons: ________ (disabled on ________; reported to security). Persons with multiple accounts: ________ (consolidated to one reviewer).
3. Entitlement completeness. Role catalog version: ________. Roles in system not in catalog: ________ (described and owned before issue). Roles in catalog not in system: ________ (removed from catalog).
4. Conflict flags. SoD analysis run date: ________. Users with flagged conflicts: ________. Mitigations and acceptances referenced: ________.
5. Reviewer assignment. Lines assigned: ________. Lines with no identifiable reviewer: ________ (assigned to ________). Review issued on: ________.
Auditing a user access review: the ten-test program
When the review is management’s control and internal audit is testing it, the program below covers the design and the operation for a period. Its logic is the logic of this guide: completeness first, then decision quality, then revocation, because a review that fails completeness cannot be effective whatever its reviewers did. Sample sizes follow the usual conventions for the populations involved, and the sampling rationale belongs in a sampling memo. The tests double as the design checklist for a function building its own review.
| # | Test | Population and sample | Evidence | What a failure looks like |
|---|---|---|---|---|
| 1 | Evaluate the scope: systems, tiers, frequencies, reviewer roles, privileged and non-human accounts | Policy and system inventory | Access review policy; inventory with tier and review status | Tier-1 systems missing; privileged access reviewed by line managers; contractors with no reviewer |
| 2 | Re-perform the population completeness for one cycle of each tier-1 system | All tier-1 systems in the period, one cycle each | Auditor’s own extract compared with the review population; HR reconciliation | Users in the system not in the review; terminated users in the population; generic accounts absent |
| 3 | Test the identity map and orphan handling | All orphans in the cycle | Disposition of each orphan | Orphans approved by a manager who could not know them; orphans carried cycle to cycle |
| 4 | Test entitlement descriptions and the role catalog | All roles in tier-1 systems | Catalog with business descriptions and owners; reconciliation to system roles | Codes shown to reviewers; roles without descriptions |
| 5 | Test the data pack: last logon, grant dates, peer comparison, SoD flags | Sample of 25 lines | The review file as issued | No usage data; SoD conflicts not flagged |
| 6 | Compute decision-quality measures per reviewer | All reviewers in the cycle | Submission timestamps, approval rates, dormant and conflict approvals | Approve-all patterns; dormant accounts and conflicts approved without comment; no re-reviews |
| 7 | Test revocation execution | All revocations in the cycle, or 40 if more | Ticket, service level, system change record | Tickets closed without system evidence; service levels exceeded; partial reductions lost |
| 8 | Re-perform the completion check | All revocations | Fresh extract after the service level compared with the revocation list | Revoked access still active |
| 9 | Test the treatment of terminated users found by the review | All such cases | Disable evidence; report to the security function; lifecycle root cause | Terminated users handled as ordinary revocations; no lifecycle finding raised |
| 10 | Test reporting and follow-up | Reports for the period | Summary to management; open items across cycles; trend of findings | No reporting; the same open items every quarter |
Worked example: MidState Beverage rebuilds its ERP review
MidState Beverage, the three-state drinks distributor with twelve depots that appears throughout this site’s examples, had run a quarterly access review of its ERP since 2022. The FY27 ERP user access engagement, 550 hours plus 140 co-sourced, tested the review as one of its three workstreams, alongside the segregation of duties analysis and privileged access. The previous quarter’s review package consisted of a spreadsheet of 398 users and role codes, emailed to eighteen reviewers, twelve of them depot managers, with a request to “confirm access is appropriate,” and eighteen replies.
The auditor’s completeness re-performance extracted 412 active users from the ERP against the 398 reviewed: nine accounts created after the extract, and five generic depot accounts the reviewer had excluded as “not people.” The HR reconciliation, using an identity map the engagement had to build because none existed, found nine accounts belonging to employees terminated between four and eleven months earlier, all approved by their former managers, and fourteen orphans, mostly former contractors of the acquisition integration project. The decision-quality analysis of the email replies found that seven of the eighteen reviewers had replied within four minutes of receipt approving every line, that no reviewer had commented on any of the 61 accounts with no logon in the quarter, and that none of the eleven depot managers who held both the enter and approve override roles had been shown that they did. The revocation test found 31 removals requested across the previous four quarters, 19 executed, and 12 open for more than sixty days, including two of the terminated employees, whose managers had in fact asked for removal a year earlier.
| Element | Previous review (as found) | Rebuilt review (first cycle) |
|---|---|---|
| Population | 398 users from an unreconciled spreadsheet; generic accounts excluded | 412 users from an observed system extract, reconciled to HR and the contractor register; 5 generic accounts attributed to depot owners |
| Terminated users in population | 9, all approved | 0 (disabled before issue); lifecycle finding raised on the missing HR termination feed |
| Orphans | 14, approved or ignored | 14 dispositioned: 11 disabled, 3 attributed |
| Entitlement description | Role codes | Role catalog of 74 roles in business language with SoD classification |
| Data pack | None | Last logon, grant date, peer comparison, 214 SoD flags from the analysis |
| Decision quality | 7 of 18 reviewers approve-all in under four minutes; no comments on 61 dormant accounts | Measures published; 3 reviewers re-reviewed with the coordinator; 48 dormant accounts removed; 2 conflicts accepted with COO signature, 9 reduced |
| Revocations | 31 requested over four quarters, 19 executed, 12 open over sixty days | 67 requested, 67 executed within five business days, completion check against a fresh extract clean |
| Evidence | Eighteen emails | Complete package: extract and query, reconciliations, catalog version, decisions with timestamps, measures, tickets, change records, completion check |
The report carried the review’s failure as a single Medium finding with the design gaps listed, and the nine terminated users as a separate High finding against the leaver process, because the review had failed but the process it was backstopping had failed first; the root cause recorded for both was the absence of a termination feed from HR to system owners, which was the same cause the payroll portal review and the SOC 1 review had found, and the enterprise recommendation was written once. The rebuilt review ran its first cycle inside the engagement with the analytics and IT auditor as coordinator, then transferred to the controller’s team with the templates above. The CAE’s audit committee note recorded the before-and-after table and one sentence: the review had produced eighteen signatures a quarter for three years and had never removed a terminated employee.
Common mistakes
- Issuing an unreconciled population. Extract from the system with the query recorded, reconcile to HR and contractors, and disposition every difference before a reviewer sees a line.
- Excluding generic, service and locked accounts. They are the accounts most likely to carry the access nobody owns.
- Showing role codes. Build the catalog; a reviewer cannot decide on a code.
- Sending everything to line managers. Entitlement appropriateness belongs to application owners; privileged access to the security function; external accounts to an assigned owner.
- Providing no usage or conflict data. Last logon, grant dates and SoD flags are what turn signing into reviewing.
- Not measuring decision quality. Compute time per line and approval patterns, publish them, and re-issue reviews that fail the thresholds.
- Closing revocations on the ticket. The control operates when the system record shows the access gone; check a fresh extract after the service level.
- Treating terminated users as revocations. They are lifecycle failures; disable immediately and raise the finding against the leaver process.
- Keeping eighteen emails as evidence. The package is the extract, reconciliations, catalog, decisions, measures, tickets, change records and completion check.
- Reviewing quarterly what should be automatic. Where an HR feed can disable leavers on the day, build it; the review is the backstop, not the control.
Related guides
- How to audit identity and access management
- How to run an ERP segregation of duties analysis
- How to audit privileged access
- Segregation of duties beyond the ERP
- IPE: testing information produced by the entity
- Preventive, detective and corrective controls
- The audit issue log template
- Root cause analysis for audit findings
- How to review a SOC 1 report
- Building the IT audit plan
- IT general controls: the complete primer
- Audit sample sizes: 25, 40, 60
- Templates and downloads
Leave a Reply