Why access reviews pass the audit and still fail the business

User access reviews are one of the most common controls in any IT control framework, and one of the most commonly hollow. A review can be completed on time, signed by the right manager, and filed with a clean evidence package, while inappropriate access stays exactly where it was. This article looks at why that happens and how to redesign the review so it removes access that should not exist, rather than producing paperwork that says it was checked.

The certification that certifies nothing

Consider an illustrative but familiar scenario. A manager receives a spreadsheet of 400 entitlements for their team. The tool offers an “approve all” button. The manager clicks it in under two minutes, and the review is marked complete.

On paper, the control operated. There is a timestamp, a named reviewer, and a sign-off. In practice, nobody looked at anything.

Rubber-stamping is not usually laziness. It is a design problem. When reviewers get long lists of cryptic entitlement names with no context, approving everything is the rational response. They cannot tell a read-only reporting role from one that can change payment instructions, so they assume someone else already got it right.

An access review is only as good as three things: the list being reviewed, the person reviewing it, and the proof that what they rejected was actually removed. Weakness in any one of them breaks the control.

Start with the population

Before I evaluate how well a review was performed, I ask where the list came from. If the user listing is incomplete or inaccurate, the review is built on sand, no matter how carefully the reviewer worked.

In audit terms, the listing is information produced by the entity, or IPE. Auditors need comfort over its completeness and accuracy before relying on it. That means answering questions like these:

• Was the listing pulled directly from the system of record, or from a spreadsheet someone maintains?
• What query or report generated it, and has that logic been validated?
• Does the record count reconcile to the source system at the time of extraction?
• Were any filters applied, and do they exclude anything that should be in scope?

A common gap is the extract that quietly drops certain account types: disabled accounts that can be re-enabled, accounts in a separate domain, local accounts on a database, or users provisioned directly in a cloud console outside the identity platform. If they are not in the file, nobody reviews them.

The reviewer has to be able to judge

The second failure point is the reviewer. Managers are well placed to say whether a person still works for them. They are often poorly placed to say whether a specific entitlement is appropriate for that person’s job.

Good review design closes that gap. Entitlements should carry plain-language descriptions. High-risk roles should be flagged. Where a manager cannot judge technical access, the application or data owner should review it instead, or as a second step.

It also helps to make the review smaller. Showing only changes since the last cycle, plus high-risk entitlements every time, gives reviewers something they can genuinely evaluate. A list of 40 meaningful items gets more scrutiny than a list of 400 that look identical.

Privileged and service accounts are where the risk lives

Many reviews cover business users well and leave out the accounts that matter most. Administrator accounts, database owners, break-glass accounts, and service accounts used by applications and scripts often sit outside the standard certification.

These accounts can change configurations, bypass application controls, and read or alter data directly. A service account with broad rights and a password that never changes is a far bigger exposure than a business user with one extra report.

Every privileged and non-human account should have a named owner who certifies it, a documented business purpose, and a check that it is still in use. If nobody will put their name to a service account, that is a finding in itself.

In my AWS and Azure control assessments, cloud roles and access keys deserve the same attention. Access granted through cloud identity and role assignments can sit entirely outside the on-premises review if no one connects the two.

Terminations and transfers

Periodic reviews are a detective backstop. The primary control is timely removal when people leave or change roles. Reviews that pass while leavers still have active accounts are a sign that the provisioning process is weak and the review is not catching it.

Transfers are the harder case. A person moves from operations to finance and keeps their old access while gaining new access. Over several moves, they accumulate rights that no single role would justify, and that can create segregation of duties conflicts. Reviews should make that accumulation visible by showing access against role, not just against the person.

Proof that revocation happened

This is where many otherwise good reviews fall apart. The reviewer marks an entitlement for removal. The review is closed. Nobody checks that the access was actually removed.

A reviewer’s rejection is a request, not a result. The control should include evidence that each revocation was completed, ideally a follow-up extract from the system showing the access is gone, within a defined timeframe. A ticket marked “done” by the same team that was asked to do the work is weaker evidence than a system report.

What auditors test, and what that means for design

When I tested access reviews as part of SOX-relevant ITGC work, the questions were consistent. Knowing them helps control owners design reviews that hold up, and, more importantly, that work.

Test area	What the auditor asks	Weak evidence	Strong evidence
Population	Is the listing complete and accurate?	Spreadsheet with no source details	System extract with query, timestamp, and count reconciled to source
Reviewer	Is the reviewer appropriate and independent?	Reviewer certifies their own access	Manager or data owner, with self-review routed elsewhere
Precision	Did the reviewer actually evaluate access?	Bulk approval with no changes, cycle after cycle	Documented decisions, with removals and questions on record
Scope	Are privileged and service accounts included?	Business users only	All account types, each with a named owner
Revocation	Was rejected access removed on time?	Reviewer comments only	Follow-up extract confirming removal within the agreed timeframe
Timeliness	Was the review completed within the defined cycle?	Late completion with no escalation	Completion tracked, with overdue reviews escalated

One signal I pay attention to is a review with zero changes, cycle after cycle, for a large population. Some stable teams genuinely need no changes. But a long run of clean reviews across thousands of entitlements usually says more about the review than about the access.

Redesigning the review

If your access review passes audit but you are not confident it reduces risk, these steps are a practical place to start:

1. Validate the population. Document the source, the extraction logic, and the reconciliation to the system of record. Fix any filters that exclude account types.
2. Bring in every account type. Include privileged, service, shared, break-glass, and cloud accounts, each with a named owner.
3. Translate entitlements. Add plain-language descriptions and risk ratings so reviewers know what they are approving.
4. Route to the right reviewer. Use managers for “should this person still have access” and data or application owners for “is this access appropriate.”
5. Reduce the volume. Focus each cycle on changes and high-risk access, with a full review at a defined interval.
6. Remove the rubber stamp. Disable or restrict bulk approval for high-risk entitlements, and require a decision on each.
7. Close the loop on revocation. Track every removal to completion and confirm it with a follow-up extract.
8. Watch the signals. Report review completion, removal rates, overdue revocations, and repeated zero-change reviews to the control owner.
9. Strengthen the upstream controls. Tie terminations and transfers to HR events so the review is a backstop, not the primary defense.

A review that earns its sign-off

An access review is meant to answer a simple question: does everyone who has access still need it? When the population is complete, the reviewer can judge what they see, and removals are confirmed, the signature on the certification means something. Until then, a clean audit result may simply mean the control was performed as written, not that it worked.

---

This article reflects my professional perspective and is general information, not legal or regulatory advice. Apply it in light of your organization’s obligations and risk appetite.