Most user access reviews produce a signed spreadsheet and very little removed access, and when an auditor tests them they fail on the basics: an incomplete user listing, a reviewer who certified their own access, or revocations that were approved but never carried out. This access review checklist, usable as a user access review checklist or UAR checklist, turns the user access review (UAR), also called an access certification, into a repeatable procedure with checkable actions for each stage: scoping the population, assigning reviewers, preparing complete and accurate data, running the review, covering privileged and non-human accounts, revoking and verifying, and capturing evidence that will survive a SOX IT general controls test. It is written for identity and IAM teams who run access certification campaigns, application owners who review, and the control owners and internal auditors who rely on the result. For why reviews fail and how to design them, read the Access Reviews Guide; this page is the working template.
How to use this template
- Replace text in square brackets, such as [Organisation], [IAM team], [10 working days] and [Quarterly], with your own teams and values. Bracketed numbers are suggestions, not standards, unless a source is named.
- "Must" is mandatory; "should" is recommended, with deviations recorded as exceptions under section 10.
- Each check has an ID (for example SC-1). Copy the checks into your tracker or governance tool and add three columns: Done (Yes, No, N/A), Evidence reference, and Checked by.
- Run one copy per campaign. It works as a user access review template for one SOX application or as an access certification checklist for an enterprise campaign.
- A check is complete only when its evidence is filed. "Reviewer confirmed verbally" is not evidence: PCAOB AS 2201 states that "Inquiry alone does not provide sufficient evidence to support a conclusion about the effectiveness of a control."
1. Purpose
This procedure ensures that every account with access to [Organisation]'s in-scope systems is still authorised, holds only the access its role needs, and is removed promptly when it is not. It implements NIST SP 800-53 Rev. 5 AC-2 item j, "Review accounts for compliance with account management requirements [Assignment: organization-defined frequency]", supports AC-6(7) Review of User Privileges and ISO/IEC 27001:2022 Annex A control 5.18 Access rights, and provides the operating evidence for the periodic access review control in [Organisation]'s SOX ITGC framework.
2. Scope and population
| ID | Check | Evidence |
|---|---|---|
| SC-1 | List every system in scope for this campaign: SOX-relevant applications, their databases and operating systems, the identity provider, cloud platforms and [other regulated systems]. Record why each is in scope. | Scope register entry with control ID |
| SC-2 | For each system, define the access to be certified: accounts, roles, groups, entitlements and application-level permissions, not only membership of a directory group. | Entitlement catalogue extract |
| SC-3 | Include every account type: employees, contractors, guests and partner accounts, local application accounts that bypass single sign-on, shared and generic accounts, service accounts, API keys and integration users. | Population summary by account type |
| SC-4 | Exclude birthright access only where the role definition itself is reviewed separately by its role owner, and record that review. | Role content review sign-off |
| SC-5 | Identify high-risk access for the shorter cadence in section 4: administrator roles, access that can change financial data, production write access, and entitlements in a segregation of duties conflict. See the Segregation of Duties Guide. | Risk-tagged entitlement list |
3. Roles and reviewer assignment
| ID | Check | Evidence |
|---|---|---|
| RA-1 | Name a campaign owner in [IAM team] who prepares data, chases reviewers and closes the campaign. | Campaign record |
| RA-2 | Assign each item to a reviewer who can judge it: line managers for whether a person still needs a job function, application or entitlement owners for what an entitlement allows, and system owners for privileged roles. Use a second stage where neither alone has the full picture. | Reviewer mapping table |
| RA-3 | Prevent self-review: no reviewer certifies their own access or access they administer for themselves. Route those items to the reviewer's manager or the control owner. | Configuration screenshot or rule; exception report showing zero self-certifications |
| RA-4 | Set a fallback reviewer for every item whose primary reviewer has left, is on leave or is unknown, so items do not silently time out. | Fallback reviewer list |
| RA-5 | Brief reviewers before launch: what entitlements mean, what "approve" commits them to, the deadline and escalation path. | Briefing note or reviewer email text with date sent |
| RA-6 | Confirm independence for the sign-off: [Internal audit or second line] samples completed reviews and is not a reviewer in the same campaign. | Sample test record |
In Microsoft Entra ID Governance these map to the reviewer options "Group owner(s)", "Managers of users", "Selected user(s) or groups(s)" and "Users review their own access", plus "Select fallback reviewers" and a "Multi-stage review" of up to three stages. Keep self-review for low-risk attestations, never privileged or SOX access.
4. Access review frequency and triggers
Set access review frequency by risk, not by habit. Two published minimums anchor the table: CIS Controls Safeguard 5.1 asks organisations to "Validate that all active accounts are authorized, on a recurring schedule at a minimum quarterly, or more frequently", and Safeguard 6.8 asks for access control reviews "on a recurring schedule at a minimum annually". Your auditors and regulators may set their own expectation; confirm it before fixing the schedule.
| Review type | Suggested frequency | Reviewer |
|---|---|---|
| Privileged and administrator access on in-scope systems | [Quarterly] | System owner, with control owner sign-off |
| Quarterly access review of SOX application users | [Quarterly] | Application or business owner |
| Service accounts, API keys and integration users | [Quarterly] (CIS Safeguard 5.5 states quarterly at a minimum) | Named NHI owner |
| All other workforce application access | [Every 6 months] or [Annually] | Line manager, then application owner for exceptions |
| Guest and partner accounts | [Quarterly] and at contract end | Sponsor |
| Event-driven review | Within [10 working days] of a mover, long-term leave, contract extension, dormancy or a security incident | New manager or owner |
- F-1: Publish the year's calendar with each campaign's start, review window ([14 days]) and close date.
- F-2: Align SOX campaigns with the audit period. PCAOB AS 2201 notes that "testing performed closer to the date of management's assessment provides more evidence", and auditors who test earlier in the year will ask what happened in the remaining period (paragraphs .55 and .56 on roll-forward). A quarterly cadence keeps the gap short.
- F-3: Dormant accounts should not wait for the next campaign: CIS Safeguard 5.3 says to disable dormant accounts "after a period of 45 days of inactivity, where supported".
5. Access review procedure: preparing complete and accurate data
The user listing is the weakest point in most SOX access reviews. Under PCAOB AS 1105 paragraph .10, when information produced by the company is used as audit evidence the auditor must "Test the accuracy and completeness of the information, or test the controls over the accuracy and completeness". A review of an incomplete list is not a review.
| ID | Check | Evidence |
|---|---|---|
| PR-1 | Extract the access listing directly from the target system (application user table, database roles, identity provider, cloud platform), not from a provisioning tool's view of what should exist. | Raw extract file |
| PR-2 | Record how the listing was produced: system, report or query name, parameters, who ran it and the system timestamp. Keep the query text. | Extraction log with screenshot of parameters and run time |
| PR-3 | Prove completeness: reconcile the record count to the system's own total, or to a second independent source, and explain differences. | Reconciliation worksheet |
| PR-4 | Protect integrity: hash or lock the extract, and make sure reviewers cannot edit the population, only record decisions against it. | File hash or tool configuration |
| PR-5 | Enrich each line with context: entitlement description, how access was granted (role, request, exception), last sign-in or last used date, HR status and manager, and any open SoD conflict. | Review package sample |
| PR-6 | Flag accounts that match no current HR record (orphaned), leavers with active access, and access unused for [90 days] before the review opens, and remove clear cases through the normal leaver process instead of asking a reviewer. | Pre-review exception report and removal tickets |
6. Running the review: reviewer decisions
| ID | Check | Evidence |
|---|---|---|
| RV-1 | Every item receives an explicit decision: approve, remove or modify. "Not reviewed" is a failure, not a default approval. | Decision report |
| RV-2 | Require a written justification for approving high-risk access and for any approval that contradicts a recommendation (for example, approving an account with no sign-in in the review window). | Justification field populated |
| RV-3 | Send reminders and escalate overdue reviewers to their manager at [day 7] and to the control owner at [day 12]. | Reminder and escalation log |
| RV-4 | Detect rubber-stamping: flag reviewers who approve every item, or approve large volumes within seconds, and have the control owner re-perform a sample of their decisions. | Reviewer statistics and re-performance note |
| RV-5 | Decide in advance what happens to unreviewed items at the deadline, and do not let them default to "approve" for privileged or SOX access. | Campaign configuration |
In Entra access reviews, "If reviewers don't respond" offers "No change", "Remove access", "Approve access" or "Take recommendations"; for privileged and SOX scope choose "Remove access" or "No change" with manual follow-up, never "Approve access". "Justification required" forces a reason, and the "No sign-in within 30 days" decision helper recommends denial for inactive users. Access reviews need Microsoft Entra ID Governance or Microsoft Entra Suite licences.
7. Privileged accounts
| ID | Check | Evidence |
|---|---|---|
| PA-1 | Review privileged access separately and more often than standard access (section 4), with the system owner, not a line manager, as reviewer. | Separate campaign record |
| PA-2 | Include every route to privilege: directory admin roles, application superuser and configuration roles, database administrator roles, operating system administrators, cloud administrator roles, and the groups that grant them. | Privileged population by route |
| PA-3 | Review eligible as well as active assignments where just-in-time access is used. In Entra PIM reviews, choose "all active and eligible assignments" so standing and eligible holders are both certified. See the Privileged Identity Management (PIM) Guide. | Review scope setting |
| PA-4 | Confirm each administrator uses a dedicated administrator account (CIS Safeguard 5.4) and that MFA is enforced on it (Safeguard 6.5). | Account list with MFA status |
| PA-5 | Review emergency access accounts: confirm they exist, are controlled, alert on use, and that every use since the last review is explained. See the Break-Glass Account Guide. | Use log and explanation |
| PA-6 | For SOX systems, confirm that administrators who can change the application or its data are not also business users who post transactions, or that a mitigating control (activity log review) is in place. | SoD analysis or mitigating control evidence |
8. Non-human identities
Service accounts, integration users, API keys and bots often hold write access to financial data and have no manager. CIS Safeguard 5.5 requires an inventory of service accounts that contains "the department owner, review date, and purpose", with reviews "on a recurring schedule at a minimum quarterly". See the Service Account Security Guide.
| ID | Check | Evidence |
|---|---|---|
| NH-1 | Every non-human account in scope has a named owning team and an individual accountable owner; accounts with no owner are escalated, not approved. See the NHI Ownership Guide. | Inventory extract with owner fields |
| NH-2 | The owner confirms purpose, the systems it connects, and that its permissions match what it actually does (granted versus used). | Owner attestation per account |
| NH-3 | Credential checks: age of passwords, keys, secrets and certificates; where they are stored; and whether rotation depends on a person who has left. | Credential age report |
| NH-4 | Interactive sign-in is blocked for service accounts, or each interactive use is explained. | Sign-in log extract |
| NH-5 | Include OAuth applications and integrations with their granted scopes. See the SaaS and OAuth App Governance Guide. | App and consent list |
| NH-6 | For Azure and Entra roles, select "Service Principals" in PIM role reviews to cover "machine accounts with direct access" (needs Workload ID Premium plus Entra ID P2 or ID Governance). Where a tool cannot review an NHI type, use the NH-2 attestation. | Review scope or attestation record |
9. Revocation and closure
| ID | Check | Evidence |
|---|---|---|
| RC-1 | Every remove or modify decision creates a ticket or automated change with an owner and a due date: [5 working days], privileged [2 working days]. | Ticket list linked to decisions |
| RC-2 | Where the tool can apply results automatically (for example Entra "Auto apply results to resource"), enable it for directory-managed access and record the applied date. | Applied-by and applied-date fields |
| RC-3 | Verify removal in the target system, not the ticket queue: re-extract the access listing after the due date and confirm every removed item is gone. | Post-removal extract and comparison |
| RC-4 | Check for use between the decision and the removal; activity by a revoked account after its decision date is an incident to investigate. | Sign-in or activity log review |
| RC-5 | For non-human accounts, disable first, monitor for failures for [14 days], then delete; CIS Safeguard 6.2 notes accounts may be disabled rather than deleted to preserve audit trails. Rollback is re-enabling. | Change record with disable and delete dates |
| RC-6 | Close the campaign only when RC-3 shows zero outstanding removals or each remaining item has an approved exception. | Closure memo |
Unremoved access is how dormant accounts become breaches: the Colonial Pipeline attack began with a VPN account that was no longer in use, and the Internet Archive breach showed what unrotated tokens and keys can do after a first compromise. See the Joiner-Mover-Leaver Guide.
10. Access review evidence and SOX ITGC considerations
For a SOX access review the control is tested on design (would this review catch inappropriate access?) and operating effectiveness (did it, every time, in the period?). PCAOB AS 2201 explains that automated controls are generally lower risk only "if relevant information technology general controls are effective", so a failed access review can widen the auditor's work well beyond the one application. The access review audit evidence pack should hold:
| Evidence item | What the auditor checks |
|---|---|
| Population extract and extraction log (PR-1 to PR-4) | Completeness and accuracy of the information produced by the entity; extract date against the review date |
| Reviewer mapping and self-review exclusion (RA-2, RA-3) | Reviewers are appropriate and independent of the access they review |
| Review package as shown to reviewers (PR-5) | Precision: reviewers had enough information to make a real decision |
| Decision report with reviewer, date and justification | Every item decided within the window; approvals of high-risk access justified |
| Revocation tickets and post-removal extract (RC-1 to RC-3) | Timely, complete follow-through on removals |
| Campaign sign-off by the control owner (section 11) | Management review and accountability |
| Exceptions register entries | Approved, time-limited, with compensating controls |
- EV-1: Export the decision history at campaign close and store it in [evidence repository] for [7 years] or your retention period. Do not rely on the tool's own copy: Entra review history reports, for example, "are available for download for 30 days in CSV format". They include ReviewerUPN, ReviewResult, Justification, AppliedByName and AppliedDate fields, which map directly to the table above.
- EV-2: Keep evidence in its original form (system exports, not retyped spreadsheets); AS 1105 notes that original documents are more reliable than copies.
- EV-3: A review that removes nothing for several cycles is a design question to answer before the auditor asks it.
See the SOX IT General Controls (ITGC) Guide for scoping and deficiency evaluation, and the Audit Evidence and Continuous Controls Monitoring Guide for evidence lineage and sampling.
11. Exceptions and sign-off
- Any access approved against policy (an SoD conflict, a shared account, an unowned NHI) needs an exception naming the risk owner, the compensating control and an expiry of no more than [12 months], recorded in [risk register].
- Reviewers who do not complete on time are reported to [governance forum]; repeated non-completion is a control deficiency to log, not a reminder to resend.
- The control owner signs off only after RC-6.
| Item | Entry |
|---|---|
| Campaign name, control ID and systems | [UAR-2026-Q4-ERP] / [ITGC-AC-04] / [List] |
| Population extract date and completeness check | [Date] / [Reconciled: Yes] |
| Items reviewed by account type | Human [n]; privileged [n]; non-human [n]; guest [n] |
| Decisions | Approved [n]; removed [n]; modified [n]; not reviewed [n] |
| Removals verified in target system | [n] of [n], verified on [date] |
| Exceptions raised | [n], references [list] |
| Signed off by | [Name, role, date] |
| Next campaign due | [Date] |
12. Framework mapping
| Checklist area | NIST SP 800-53 Rev. 5 | CIS Controls v8.1 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Scope, frequency and review (sections 2, 4, 6) | AC-2 j; AC-6(7) Review of User Privileges | 5.1 inventory of accounts; 6.8 role-based access control | 5.18 Access rights |
| Dormant and leaver access (PR-6, F-3) | AC-2 h; AC-2(3) Disable Accounts | 5.3 disable dormant accounts | 5.18 Access rights |
| Privileged accounts (section 7) | AC-6(5) Privileged Accounts | 5.4 dedicated administrator accounts; 6.5 MFA for administrative access | 8.2 Privileged access rights |
| Non-human identities (section 8) | AC-2 j; IA-5 Authenticator Management | 5.5 inventory of service accounts | 5.17 Authentication information |
| Revocation (section 9) | AC-2 h | 6.2 access revoking process | 5.18 Access rights |
In NIST CSF 2.0 the review sits under PR.AA-05 (access permissions managed and reviewed with least privilege).
Implementation guidance
- Start with one SOX application and its privileged users: run sections 2 to 11 end to end on a small population, including the post-removal re-extract. It proves the evidence chain before you scale.
- Fix the data before the campaign: reconcile accounts to HR, remove leavers and dormant accounts, and fill entitlement descriptions.
- Pilot the reviewer experience: give [three] reviewers the package a week early and rewrite entitlement descriptions they could not understand.
- Turn on automatic removal in stages: run the first cycle with manual application of results, compare what automatic removal would have done, then enable it for directory groups. Keep manual removal with verification for application-local accounts. Rollback is re-granting from the decision record within [1 working day].
- Add non-human identities once owners exist: run the ownership drive first, then the NH checks.
Small organisations can run this checklist from a spreadsheet and system exports, provided PR-2, PR-3 and RC-3 are done properly. Large organisations need an identity governance tool with connectors, and event-driven reviews for movers and dormancy to cut the periodic load, but must still prove completeness for systems the tool does not connect to. Common failure patterns: reviewing a provisioning tool's records instead of the target system; managers certifying technical entitlements they cannot read; "approve" as the default for non-responses; removals approved but never verified; service accounts excluded because they have no manager; and evidence kept only inside the tool until it expires. Track these measures each cycle, and see the Identity Security Metrics Guide:
- Revocation rate: percentage of items removed or modified, overall and for privileged access.
- Time to verified removal: days from decision to confirmation in the target system.
- Completion on time: items decided within the window, by reviewer.
- Rubber-stamp indicator: reviewers approving 100 percent of items or averaging under [5 seconds] per decision.
- Coverage: in-scope systems, privileged accounts and non-human identities included in a review in the last [quarter].
Standards and references
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (AC-2)
- PCAOB: AS 2201, An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements
- PCAOB: AS 1105, Audit Evidence
- CIS: Controls Assessment Specification, Control 5 Account Management
- CIS: Controls Assessment Specification, Control 6 Access Control Management
- Microsoft Learn: What are access reviews?
- Microsoft Learn: Create an access review of groups and applications in Microsoft Entra ID
- Microsoft Learn: Create an access review of Azure resource and Microsoft Entra roles in PIM
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Access Reviews Guide · SOX IT General Controls (ITGC) Guide · Audit Evidence and Continuous Controls Monitoring Guide · IGA Buyer's Guide · Service Account Security Guide · Cloud IAM Review Checklist