User access reviews: how to run one that isn't rubber stamped

Access reviews are one of the most tested controls in any security audit and one of the most frequently faked, usually by people with forty other things to do and a spreadsheet that looks fine.

An access review that never removes anyone proves that nobody looked. The fix is in how the review is set up, and asking people to try harder won't change it.

I've run access reviews inside fintech companies and prepared them for audit, and I've seen the same three failures in almost every first attempt.

What auditors test

ISO 27001 Annex A controls 5.15 on access control, 5.18 on access rights and 8.2 on privileged access rights expect access to be granted, reviewed and removed according to policy. SOC 2 criteria CC6.2 and CC6.3 expect access to be authorised, modified and removed in a timely way, and periodically reviewed.

Auditors usually check three things: that the list reviewed was complete, that the reviewer was appropriate, and that decisions were acted on. They'll also compare your leaver list with access logs to see how quickly accounts were removed.

The three common failures

An incomplete list. Someone exported users from the identity provider and missed the SaaS tools outside single sign on, the database accounts, the cloud console users created directly. The review covered the systems that were easy, not the ones that matter.

The wrong reviewer. IT reviews the list because IT owns the systems. IT doesn't know whether the marketing intern still needs access to the customer database. The person who knows is the intern's manager.

No action. Decisions are recorded but nothing changes. A "remove" with no ticket and no date is a wish.

Most managers have approved 140 rows in four minutes while half listening to a call. That one sitting contains all three failures.

When every one of 140 rows comes back "keep", what you've done is take a headcount.

A review that holds up

Scope it to systems with customer or sensitive data, plus admin access everywhere. List those systems and update the list when you add tools.

Pull user lists directly from each system, with the date and the parameters used, so completeness can be shown.

Send each person's access to their manager, and privileged access to the system owner as well.

Make every "remove" a ticket with a completion date, and keep the before and after.

Fix the leaver process separately. Access removal on the last working day, triggered by HR, is the control that stops most of the problems an access review would find.

Repeat quarterly for sensitive systems and admin access, and at least twice a year elsewhere.

Treat each review as a dated set of decisions with owners and follow up tickets, which is roughly what an auditor reconstructs anyway. Whatever you use, the evidence should show who decided what, and what changed because of it.

An access review that never removes anyone is the most reassuring lie in your evidence folder.