The access review nobody reads

Somewhere in your organisation, a manager received a spreadsheet last quarter. It listed the ninety or so people who report to them, each with a column of system names, and it asked them to confirm that all of this was still appropriate.

They approved it. Of course they did. It arrived on a Thursday, it was the fourth thing competing for that hour, and there was no realistic way to evaluate ninety rows of entitlements they had never seen described before.

That control is now recorded as performed. It will appear in your evidence pack. And it caught nothing, because it was never capable of catching anything.

This is not a people problem. Nobody in that story behaved unreasonably. It is a design problem, and it is fixable.

Why the spreadsheet fails

Three things go wrong at once.

The reviewer does not recognise what they are looking at. Entitlement names are written by the systems that own them. FIN_GL_POST_APPROVER is perfectly clear to the finance platform team and completely opaque to the line manager being asked to judge it. You cannot approve what you cannot read.

Everything is presented as equally important. Read access to a shared calendar sits in the same list, formatted identically, as the ability to move money. Given ninety rows and forty minutes, attention gets spread evenly across items that deserve nothing like equal attention.

Approving is easy and questioning is expensive. Ticking the box takes a second. Querying one line means an email, a wait, a follow up, and possibly a difficult conversation with a colleague. The process quietly rewards the outcome it was designed to prevent.

A control that makes the wrong answer cheaper than the right one will get the wrong answer, consistently, from good people.

What changes the outcome

We have watched this work when three things change, and none of them require new software.

Review by exception, not by inventory. Do not ask somebody to confirm ninety things are fine. Ask them to look at the nine that changed since last time, or the nine that look unusual against their peers. A short list gets read. A long list gets approved.

Translate the entitlement. Next to FIN_GL_POST_APPROVER, write what it lets somebody do in a sentence a manager would use. This is unglamorous work and it is the single highest return change available in most programmes.

Separate the dangerous from the ordinary. Anything that grants administrative control, touches money, or reaches personal data goes in its own review with its own cadence and a named approver who understands it. Everything else can be lighter. Treating them the same is what makes the whole exercise feel like paperwork.

The accounts nobody is reviewing at all

While we are here, there is a category that usually escapes the process entirely.

Service accounts, integration credentials, API keys and the various non human identities that hold your systems together are rarely in anybody's review list. They have no line manager. They frequently hold more privilege than any person in the organisation. Their credentials often have not changed since the integration was built, by somebody who has since left.

Make a list of them. For each one, find a human owner and a rotation date. Anything without an owner should be a candidate for removal rather than a permanent exception, because an account nobody claims is an account nobody is watching.

The CIS Controls treat account and access management as foundational for exactly this reason, and the NIST Cybersecurity Framework puts identity management at the front of the Protect function. Both are worth reading if you need to make the case internally that this deserves real time rather than a quarterly ritual.

Making the evidence worth something

There is a compliance angle too, and it is the one that tends to unlock the budget.

An access review produces evidence. If that evidence is a signed spreadsheet with ninety approved rows, it proves that a process ran. It does not prove that anything was examined. An auditor who is paying attention will notice the difference, usually by asking the reviewer a question about one specific row.

Evidence worth having records what was actually looked at, what was questioned, and what changed as a result. A review where nothing was ever removed is not a clean bill of health. Over enough cycles it is a sign that nobody is really looking.

This is the thread that runs into CyberNexus, where a control closes against the evidence a reviewer accepted rather than against the fact that a task was completed. It is also why ControlGraph holds who owns a control alongside the control itself. Ownership that only exists in a spreadsheet stops existing the moment that person changes role.

The test worth running this week

Pick one access review that was approved last quarter. Take three rows from it at random and ask the person who approved them what those entitlements allow.

If they can tell you, your process is working and you should leave it alone. If they cannot, you have not found a careless manager. You have found a control that was asking a question nobody could answer, and that is a much easier thing to fix.

Common questions

Why do access reviews get rubber stamped

Because approving is cheap and questioning is expensive. Ticking the box takes a second, while querying one line means an email, a wait and possibly an awkward conversation. A process that makes the wrong answer cheaper will get the wrong answer from good people.

How often should access reviews be done

Frequency matters less than design. A quarterly review of nine changed entitlements catches more than a monthly review of ninety unchanged ones. Review by exception rather than by inventory, and give the dangerous entitlements their own cadence.

What should be included in an access review

What changed since last time, anything unusual against peers, and anything that grants administrative control, touches money or reaches personal data. Presenting everything with equal weight is what causes attention to be spread evenly across items that do not deserve it.

Should service accounts be included in access reviews

Yes, and they usually are not. They have no line manager, they rarely rotate and they frequently hold more privilege than any person in the organisation. Anything without a human owner should be a candidate for removal rather than a permanent exception.