User access review: certifying that people still need what they have

A user access review is a periodic exercise in which the people who own a system or a dataset confirm, name by name, that everyone with access to it still needs that access. It exists because permissions are granted continuously and revoked almost never: people change teams, projects end, contractors finish, and the rights stay.

The review is not an IT task, even though IT runs the report. Only the owner of the system knows whether a particular person still needs to approve payments or read the customer database. IT can tell you who has access; it cannot tell you who should.

What a user access review has to produce

• A complete list of accounts with access to the system in scope, including service accounts and administrators.
• The owner’s decision on each: keep, reduce, or remove — one per line, no bulk approvals.
• Evidence of the decision: who reviewed, when, and what they were shown.
• Confirmation that removals were actually executed, with the date.
• A record of exceptions and why they were accepted.

The fourth item is where most reviews fail. A review that produced a list of removals nobody carried out is worse than no review: it creates a document asserting that access was corrected when it was not, and that document is the one an auditor or an investigator will read.

Running one that is not theatre

1. Scope by risk: systems holding money, personal data or production access first, everything else annually.
2. Pull the access list from the system itself, not from a spreadsheet someone maintains.
3. Include leavers explicitly — a review that only looks at current employees misses the accounts that matter most.
4. Give each owner their own list, with roles translated into what the role can actually do.
5. Require a decision per line, and treat an unanswered review as an escalation rather than an approval.
6. Verify removals afterwards by re-running the report, and keep both versions.

Reviewing role names rather than capabilities produces confident wrong answers. An owner asked whether Jane should have "Finance Contributor" will say yes; the same owner asked whether Jane should be able to change bank details on suppliers may say no. Translate before you ask.

Reviewing rights presupposes somebody granted them deliberately. How to set up roles and permissions for a small team covers the handful of roles a small organisation actually needs and which of them may invite others.

Why it keeps coming back

Access reviews appear in almost every control framework and security questionnaire, and they are also the control most often performed once and abandoned. The reason is that the first review is a clean-up — large, slow and full of surprises — while later ones are short if joiners, movers and leavers are handled properly in between.

If your reviews are still painful after the second cycle, the problem is upstream: access is being granted without an owner, or leavers are not triggering removal. Fixing that makes the review a confirmation rather than an excavation.

Ettex is not an identity governance platform, and this is where the honest boundary sits: the entitlements live in each system that grants them. What Ettex Records holds is the review itself — the list that was circulated, the decision against each line, the evidence of removal and the sign-off — so the control produces a durable record instead of an email thread. That record is what an auditor asks for, and what your own internal controls testing samples.