How to run an access review an auditor will accept

If I could only look at one control on day one of an engagement, it would be the access review. Not because it’s the most important control — because it’s the one that tells me how the company really operates. A company that reviews access on a calendar, with a named approver, and keeps the evidence, usually does everything else properly too.

Why reviews fail the test

Most companies do review access. The exception comes from one of four things:

1. No named approver. “The team looked at it” isn’t testable. One person signs.
2. No evidence. The review happened in a meeting; nothing was retained.
3. No action trail. Accounts were flagged for removal; nobody can show they were removed.
4. Wrong population. The review covered the application but not the database, the cloud console, or the deploy pipeline.

The minimum that passes

• Quarterly, on a calendar, for production systems that touch customer data.
• A system-generated export of users and permissions — not a hand-typed list.
• One named reviewer per system who understands what the permissions mean.
• A ticket that records the review, the decisions, and the removals, with a completion date.
• Follow-through within a defined window — five business days is typical.

Evidence an auditor will ask for

Request	What satisfies it
Population of systems in scope	A list, with an owner for each
Proof the review occurred	The export, the ticket, the sign-off, dated
Proof of action	Tickets or logs showing removals
Consistency	The same thing, every quarter, across the observation window

Three quarters of this, done the same way, is a clean control. One quarter done well and two done in a spreadsheet is an exception.