Pull the list of everyone who can reach your most sensitive system. Now ask when anyone last confirmed each of those people still needs to be on it. The honest answer is often that nobody has asked since the day the list was built.
That list is longer than you think, and the extra names are not random. A contractor whose project ended two years ago. Somebody who changed teams and kept both sets of access. An account opened for a migration that finished last spring. A dormant account draws no attention, which is why it stays on the list.
A user access review is what finds them. Not because anyone was careless. Somebody granted every entry for a reason that was good on the day, and nothing ever asks whether the reason still holds.
What is a user access review?
A scheduled check of who can reach what, done deliberately rather than after an incident. Somebody who did not grant the access reads the list, confirms each person still needs what they have, and removes what no longer fits.
It is rarely urgent, which is precisely why it slips. Nothing about an over-permissioned account announces itself. The work continues, the reports run, and the gap often surfaces when an outside party asks rather than when your own team spots it.
How does access drift in the first place?
Through reasonable decisions, one at a time. Somebody covers a colleague's leave and needs their view. A month-end close runs late, so a controller takes temporary access to speed it up. A contractor joins for a project that then extends twice.
Each grant made sense. What is missing is the other half of the transaction, the moment somebody decides the reason has ended. That half rarely has a process attached, because removing access creates no visible benefit and interrupts nobody.
So the list grows in one direction only. Some sectors have had this written down longer than others. The access and authentication guidance for financial institutions has expected periodic verification for years.
What does a user access review actually involve?
Less than people expect, provided you keep it narrow. Pull the list by group rather than by person, then ask three questions of each.
- Is everyone in this group still doing the job the group was built for? A no here usually means somebody changed roles and kept both sets of access.
- Does the group still need everything it can reach? Scope widens when one person asks for something and the answer lands on the whole group rather than on them.
- Is anyone here on a temporary arrangement? Cover, secondments and contractor extensions all tend to carry an end date somebody assumed rather than wrote down.
Reviewing by group keeps this short. Forty people across six groups is six conversations, not forty. If access sits on individuals instead, the review gets genuinely hard, and that difficulty is itself a finding.
How often should you run a user access review?
As often as your obligations require, and the obligation is usually where the answer lives. Some frameworks name a review period. Others require you to define one and document the reasoning. Where nothing names a frequency, change makes a better trigger than the calendar.
A reorganisation is the clearest example, since it moves many people at once and the access that fitted beforehand rarely fits after. More useful than the frequency, though, is who does the review. A granter is well placed to defend each individual decision and poorly placed to see what the list adds up to. Somebody else asking why tends to find things.
What to do with what you find
Remove what has expired, and write down why you kept the rest. People skip that second half, and it is the one a reviewer asks about.
A note saying somebody examined eleven accounts and reduced three shows a process doing real work. One saying only that everything was fine shows very little. Recording what you decided, and when, is what turns a user access review into something you can show. Our guide to creating data access logs for auditing covers the record side of that.
Record what you found even when that is nothing. A review that changes nothing still shows somebody looked, provided the note says what they checked and against what.
The review is cheaper than the discovery
A scheduled user access review is a small cost you choose. Learning the same thing during an audit costs more, and by then you control neither the timing nor the room.
A review also tells you what a permission list cannot: whether your access model still matches how the business works. In a growing organization the two drift apart quietly, for good reasons, all year.
Our guide to user permissions sets out the six decisions that shape what you are reviewing. For help designing a review that fits your own obligations, talk to an expert.
