How access reviews become audit findings

Access reviews are among the most common sources of audit findings. Not because teams ignore access entirely, but because "we review access" is a claim, and an auditor wants evidence. The gap between doing a review and being able to prove a decision is where the nonconformity lives.

Why "we review access" fails

When an auditor asks about access reviews, a confident verbal answer is not enough. The usual failure is that the review happened informally - someone glanced at a user list, nodded, and moved on - with nothing recorded. There is no artefact showing who reviewed what, what they decided, or what changed as a result.

Common weak spots:

• A list was exported but no one documented a decision against each entry.
• Access that should have been removed was flagged but never actually revoked.
• Privileged and service accounts were left out of scope.
• The review covered the application but missed the database, the cloud console or the code repository.

The review may have genuinely happened. Without evidence, it did not happen as far as the audit is concerned.

What strong evidence looks like

Good access-review evidence answers four questions for every account in scope:

• Who performed the review, and when.
• What was reviewed - the specific systems, users and privilege levels.
• The decision for each account: retain, reduce or revoke, with a reason where access looked unusual.
• The removal record - proof that revocations were actioned, with a date, not just recommended.

That last element is the one teams miss most. A review that identifies excess access but cannot show it was removed is arguably worse than no review, because it documents a known gap you failed to close.

Cadence and scope

A defensible review has a stated cadence and sticks to it. Quarterly is common for privileged access; less critical systems may run half-yearly. What matters is that the interval is written down, justified and followed, with each cycle dated.

Scope needs the same discipline. Decide explicitly which systems are in scope and confirm the list is complete:

• Production systems and the data stores behind them.
• Cloud consoles and infrastructure accounts.
• Source code repositories and CI/CD pipelines.
• Third-party tools holding customer or company data.
• Privileged, shared and service accounts, named individually.

A review that quietly excludes the highest-risk accounts is the one an auditor will find first.

Joiners, movers and leavers

Periodic reviews catch drift, but they are a backstop. The stronger control is handling access changes as they happen.

• Joiners get access based on role, provisioned and recorded at onboarding.
• Movers have old access removed when they change teams, not just new access added. Accumulated permissions from role changes are a frequent finding.
• Leavers lose access promptly, ideally same-day, with a record of when it was revoked.

When joiner, mover and leaver handling is tight, periodic reviews get shorter and cleaner because there is less to correct. When it is weak, every review turns into cleanup.

Bottom line

Access reviews fail audits when they produce claims instead of records. Strong evidence names the reviewer, the scope, the decision and the removal, on a stated cadence, backed by disciplined joiner-mover-leaver handling. If you are not confident your last access review would stand up to an auditor asking "show me", a readiness review can test it against real evidence before the audit does.