A user access review is a periodic check, by someone who knows the job, that each person with access to a system still needs that access. To run one, pull a complete user list, send it to the right reviewers, make them decide on every line, remove what is not needed, and keep proof of each step. An auditor will test the list, the reviewer and the follow-up, not just the sign-off.
Last reviewed: 17 October 2026. Facts checked. We searched for how access reviews are run and evidenced and found consistent practitioner guidance (checklists and vendor guides) on population completeness, reviewer choice, line-by-line decisions, revocation proof and retention. It was mostly vendor material, so there is no single authoritative standard behind the steps. We did not open any regulator or standard-setter text. Frequency and sign-off roles below are examples to match to your own control wording.
Why the review matters
Access builds up. People change roles, projects end, staff leave, and rights stay. Over time one person can hold a set of rights that no one approved together. That creates a segregation of duties problem and a fraud opening. The review is the control that catches this drift.
It is also one of the first things an IT or financial auditor asks for, because it is simple to test and easy to fail.
Step 1: Fix the scope
List the systems in scope. Start with those that touch the financial statements, such as ERP, banking portals, payroll and the accounting package. Add systems that hold personal data or can change other systems, such as the database and the cloud console.
For each system, record the owner, the review frequency and the reviewer. Quarterly is a common choice, but the frequency should follow your documented control and risk assessment. Higher-risk systems and privileged accounts may deserve more frequent review.
Step 2: Build a complete and accurate list
This is where most reviews fail. If the list is incomplete, the review proves nothing.
- Export users directly from the system, with the date and time of export.
- Include user ID, name, status, roles or permissions, last login and account type (employee, contractor, service account).
- Compare the list to the HR roster to spot accounts for people who no longer work there, and accounts with no HR record at all.
- Keep the raw export unchanged, so an auditor can see it was not edited before review.
Step 3: Choose the right reviewers
Reviewers must know what each role should be able to do. The direct manager is usually best for user-level access. The application owner is best for the list of roles and for privileged accounts. The IT team that administers the system should not be the only reviewer of its own access.
Give reviewers a short guide: what to approve, what to challenge, and by when.
Step 4: Decide on every line
Each user gets one of three decisions: keep, change or remove. A reviewer who is not able to explain why someone has a role should not approve it. Do not accept "approve all" as an answer without a record that each line was considered.
Pay special attention to:
- Leavers. Anyone who left, and still has an active account.
- Movers. People who changed department and kept old rights.
- Privileged accounts. Admins, super-users and database access.
- Conflicts. Users who hold two roles that your conflict matrix says should not go together.
- Dormant accounts. No login for a long period, with a limit you define.
- Shared and generic accounts. Each should have a named owner or be removed.
Step 5: Act on the exceptions
Every "remove" or "change" decision must be carried out by IT, and the result must be checked. Set a deadline. Then pull a fresh user list and confirm that the account is gone or the role changed. A review that records decisions but does not prove they were executed leaves the finding open.
Where a conflict is accepted, record who accepted it, why and what compensating control applies.
Step 6: Sign off and keep the evidence
| Evidence | Why it is kept |
|---|---|
| Original user export with date and source | Proves the list was complete and unaltered |
| HR roster used for comparison | Shows leavers were checked |
| Reviewer assignment and who they are | Shows an appropriate person reviewed |
| Reviewer decisions per line, with date | Shows each line was considered |
| Change requests or tickets raised | Links decisions to action |
| Proof of removal, such as a second export | Shows decisions were executed |
| Exceptions accepted, with approver and reason | Shows deliberate risk acceptance |
| Final sign-off by control owner | Shows the review was completed |
Keep evidence for as long as your audit and legal retention rules require. We have not stated a specific period because it depends on your policies and law applicable to your business.
What an auditor tests
An auditor typically asks whether the review happened at the stated frequency, whether the user list was complete and accurate, whether the reviewer was suitable, whether exceptions were followed up, and whether the evidence supports all of this. Common failures are an incomplete list, a reviewer who approves everything without checking, leavers left active, and decisions never executed.
A neat way to prepare is to pick five users at random from the export and trace each from the list to the decision to the outcome.
A practical calendar
- Week 1: export lists and compare with HR.
- Week 2: reviewers decide.
- Week 3: IT executes changes.
- Week 4: re-export, verify, sign off, file evidence.
Adjust to your size, but fix dates in advance so the review does not slide.
Where it fits
Access review is one control inside IT general controls. See our ITGC guide and the article on SOX IT general controls testing. For a working file to track testing, use the ITGC audit workbook.
Frequently Asked Questions
How often should a user access review be done?
It depends on the system's risk and your documented control. Quarterly is common for key financial systems, with more frequent checks for privileged access. Pick a frequency you can sustain and follow it.
Who should perform the review?
The manager or application owner who understands what each person needs. IT can supply the list and make changes, but should not be the only reviewer of its own access.
What evidence do auditors want to see?
The original user list, who reviewed it, the decision on each user, proof that removals happened and the final sign-off. Keep these together for each cycle.
What is a leaver, mover, joiner check?
It tests that access ends when someone leaves, is changed when someone moves roles, and is approved when someone joins. A review mainly catches leavers and movers who kept old rights.
Can the review be automated?
Tools can pull lists and route requests. Decisions such as approving privileged access or accepting a conflict still need a person. Automating the approval itself defeats the purpose.
Related Articles
Statutory facts on this page are checked against their sources, and the page says where it relied on secondary reporting. How we verify · Report an error