A user access review is one of the few controls that almost every framework asks for and almost every team gets partial credit on. The work is usually done. The record of it usually is not.
What an auditor is actually testing
They are not testing whether your access is correct. They are testing whether you have a repeatable process that would have caught it if it were not.
That distinction determines what counts as evidence. A clean access list proves nothing on its own, it is equally consistent with a rigorous quarterly review and with nobody having changed anything in a year.
The four artifacts
A review that survives sampling produces all four of these, dated:
The population. The complete list of accounts in scope at the time of the review, exported from the source system rather than assembled by hand.
The reviewer's decision. Who reviewed it, what they concluded per account or per group, and when.
The remediation. Tickets for every revocation or change, and their resolution.
The closure. Confirmation the changes were actually made, from the system rather than from the ticket.
Three of the four are commonly missing. The population export is the one people skip, because at the time it feels redundant, you can always pull it again. You cannot: pulling it in October tells you nothing about who had access in June.
Every artifact above is a statement about a moment. Recreating it later is not possible, and an auditor will treat a reconstructed population as unreliable, correctly, because it is. ::
Scoping: which systems
Scope is where reviews become unmanageable. The instinct is to review everything, which produces a quarterly exercise nobody completes.
A workable rule: include a system if compromise of an account in it would directly expose customer data, production infrastructure, or the ability to change either. That usually resolves to a much shorter list than the instinct suggests:
Identity provider (the source of truth for most other access)
Cloud provider consoles and production infrastructure
Production databases and data warehouses
Source control, and anything with deploy rights
Customer support tooling that can read customer data
Everything else is reviewed on a slower cycle or covered by the identity provider.
Frequency
Quarterly is the common answer and is usually right, but the honest version is that frequency should follow risk and rate of change. A ten-person team with three systems and a strong joiner-mover-leaver process genuinely does not need the same cadence as a two-hundred-person company with a dozen.
What matters far more than the interval is that the interval is stated and met. A policy saying quarterly with three reviews in a twelve-month window is a finding. A policy saying twice-yearly with two reviews is not.
The joiner-mover-leaver connection
Access reviews are a detective control. They find what your preventive controls missed.
If a review consistently finds nothing, that is a good sign about joiner-mover-leaver and a bad sign about the review, it is worth checking that the population is complete rather than concluding you are finished. If a review consistently finds a lot, the review is working and the underlying process is not, and the fix belongs upstream.
Making it cheaper
The expensive part is assembling the population and chasing reviewers. Both are mechanical. Anything that pulls the population automatically on a schedule, and records decisions where they are made rather than in a spreadsheet someone emails around, converts a two-week exercise into an afternoon, and produces better evidence as a side effect, because the artifacts are captured at the time rather than reconstructed.