Key points
- Scope the review by application, group and directory role. Start with admin roles and the apps that hold sensitive data.
- Put the last sign-in and usage beside each decision. A reviewer with no evidence approves everything.
- Decide what happens to unanswered rows before launch. No change, remove access and accept access each leave a different record.
- A denial is a decision, and the auditor wants the removal. Check it account by account.
- The evidence is one export: each decision, who made it, when, and whether the removal worked.
What is a user access review?
A user access review is a scheduled check of who holds access to your systems. The people who know each system decide whether that access should stay. A manager or an application owner approves or denies each right. Denied access then comes off, and the decisions become your audit evidence.
Frameworks ask for it in their own words. NIST SP 800-53 Rev. 5 control AC-2 (Account Management) says to "review accounts for compliance with account management requirements" at a frequency the organization defines. AC-6(7) (Review of User Privileges) adds a periodic review of privileges, with privileges reassigned or removed where needed.
Starting a review is easy. Finishing one is hard. A review stalls when reviewers cannot judge the rows in front of them. It fails the audit when nobody can show that denied access came off. This checklist is built around those two failures.
The 12-step user access review checklist
Before the review starts
- Write down the control. Note which control the review satisfies, how often it runs, and what the auditor will ask to see.
- Set the scope. Pick the applications, groups and directory roles in the campaign. Start with admin roles and the apps that hold customer or financial data.
- Clean the source data. Find accounts that match no person. An orphaned account has nobody to review it, and it will sit in the queue unanswered.
- Name the reviewers. Give each row to someone who knows the access: the app owner for app roles, the line manager for everything else. Name a fallback reviewer for rows with neither. Nobody approves their own access.
- Decide the no-response rule. Choose what happens to rows nobody answers before you launch. The options and their trade-offs are below.
While the review runs
- Put evidence on each row. Show the last sign-in and how often the access gets used. Flag anything unused for 90 days.
- Set the deadline and the reminders. Remind reviewers with open rows at fixed points, such as halfway and near the end.
- Reassign what a reviewer cannot judge. A manager may not know what a GitHub admin role allows. Move that row to the app owner and keep a record of the move.
- Decide each row. Approve or deny. Approve the obvious rows in bulk, and spend your time on admin roles and unused access.
After the review closes
- Remove denied access, then check it. Confirm each removal account by account. A failed removal stays open until someone fixes it.
- Export the evidence. Keep each decision, the reviewer, the time and the result of each removal. Record who signed off the campaign, and when.
- Follow up. Fix the failed removals, find out why rows went unanswered, and schedule the next cycle.
What should a reviewer see on each row?
A reviewer needs enough on the row to decide without leaving the queue. Ask a manager "should Riley keep this?" with nothing else on screen, and they will approve. That is how a review turns into a rubber stamp.
Put these facts beside the decision:
- Last sign-in. To the application itself, not only to the directory.
- Usage. How often the person used the access during the period.
- What the access allows. An admin role in GitHub carries more weight than a member seat.
Unused access is where the evidence pays off. Sonrai's Cloud Access Risk Report found that "on average, 92% of all identities with access to sensitive permissions did not use them over 90 days." That study covered cloud estates. Your own review data will show how much of your SaaS access goes unused.
Take Riley Adeyemi, a contractor on the platform team who still holds an admin role in GitHub. The row shows a last sign-in 97 days ago and no use in the period. Amara Osei, the app owner, denies it in seconds. Without those two facts, she would have to ask around or approve.
What should happen when a reviewer never answers?
Some rows will go unanswered. Decide what happens to them before launch. You have three options, and each leaves a different record.
| Option | What happens to the access | What the auditor sees |
|---|---|---|
| No change | It stays as it was | A row with no decision |
| Remove access | It comes off | A removal with no reviewer behind it |
| Accept access | It stays, recorded as accepted | An approval nobody gave |
Remove access is the safest option for admin roles. It is also the riskiest for a team's main application. Microsoft's Entra ID documentation warns about this option. When unanswered rows come off automatically, "all access to this resource could potentially be revoked if the reviewers fail to respond."
A workable split is remove access on admin roles and no change on broad business apps. Send the open rows to the fallback reviewer before the deadline. Accept access is the weakest choice, because it turns silence into approval.
Why does removal decide whether the review counts?
A denial records a decision. The auditor wants to see the access gone. Many reviews break here. The spreadsheet says "remove", and the ticket sits in someone's queue for a month.
After the campaign closes, check three things:
- Each denied right came off the account that held it.
- Each failed removal is listed by account, with the reason.
- The next review does not find the same access back.
If removal is manual, give each ticket an owner and a date, and link the tickets to the campaign. Leavers should not wait for a review at all. They belong in your leaver process, on their last day.
What evidence will the auditor ask for?
The auditor wants proof that the review ran as designed and that its decisions took effect. Keep these in one export per campaign.
| Evidence | What it proves |
|---|---|
| The scope and the access at the start | What the review covered |
| Each decision, with reviewer and time | Who decided, and when |
| Reassignments | Rows reached someone who could judge them |
| The no-response setting and the rows it decided | Silence was handled as planned |
| Removal results per account | Denials took effect |
| The sign-off | A named person owns the result |
For the SOC 2 side of this, read SOC 2 user access reviews. For the full audit story, see how Govern prepares you for an audit.
How EnscureX runs a user access review
In Govern, a campaign covers tags, groups, applications or directory roles. Reviewers work in ordered stages, with a fallback reviewer on each. Each row shows the last sign-in and usage, and flags anything unused for ninety days.
Reviewers approve or deny, reassign rows they cannot judge, and approve the obvious rows in bulk. Reminders go out at set percentages of the time to the deadline. You choose the no-response action when you configure the campaign: no change, remove access or accept access.
When the campaign completes, denied application access, group membership and directory roles come off per account. Removals run through the connection's write-back tasks. Those ship switched off, and you turn them on per connection. A failed removal is reported per account. Sign-off is recorded against a named person, and the evidence exports as a CSV of each decision. Access reviews has the detail.
Frequently asked questions
What is the difference between a user access review and access recertification?
They describe the same job. Recertification, or certification, is the older governance term for a reviewer confirming that a person still needs their access.
How often should you run a user access review?
NIST SP 800-53 leaves the frequency to the organization. A sensible default is quarterly for admin roles and systems in audit scope, and once or twice a year for broad business access.
Should service accounts and app registrations be in the review?
Yes. Give each one a human owner who reviews it. A non-human identity with no owner can go unreviewed for years.
Can you run a user access review in a spreadsheet?
You can, for a small scope. The weak points are a snapshot that goes stale, decisions with no timestamp, and removals tracked somewhere else. Auditors ask about all three.