Do identity and access reviews actually work by resource, or by person?

Two things called a review turn out to be the same test. One reviews your own access: who should still have what. The other reviews a product before you buy it, and the second is best conducted by making the candidate produce the lists the first one needs.

A tool that cannot answer those questions will not help you on the day you have to.

So this page is about the access review: how to scope one that finishes, who should sign it, what to do with the accounts nobody claims, and how to use it as the test that decides a purchase.

What to take away

Review by resource, not by person

Person-by-person reviews are how these efforts die. There is no natural stopping point, the person reviewing does not know what half the entries mean, and the exercise takes weeks and produces a signature.

Start from the resource instead. Pick the systems where access actually matters, list who can reach each one, and ask the person responsible for that system to confirm each name. It is finite, it fits in a sitting, and the reviewer knows what the access is for.

Four lists cover most of the risk in a small business:

Half an hour a quarter covers all four for most small organizations. Knowing who holds access, and removing it once it is no longer needed, is one of the small number of actions the United States Cybersecurity and Infrastructure Security Agency puts in Cyber Essentials for organizations with no security team.

Who signs, and what they are signing

The reviewer must be the person who would notice a wrong name. That is the head of the function, not the administrator, because the administrator can tell you the access exists and not whether it should.

Give them three options per entry, not two: keep, remove, or reduce. Reduce is the one that gets used most once people know it is available, and it is where accumulation actually comes off.

Make the default removal rather than retention. An entry nobody confirms is removed, on a stated date, with a way to restore it quickly if the removal was wrong. That inversion is the entire difference between a review that changes something and a review that produces a document. It only works if restoring is genuinely fast, so establish that first.

What to do with the accounts nobody claims

Every review turns up entries that no one recognizes. Deleting immediately is tempting and occasionally breaks something important, because unclaimed frequently means automated rather than abandoned.

Use a staged approach. Disable rather than delete, and record the date.

Wait a defined period that covers a monthly cycle, because a job that runs once a month is the classic case. If nothing breaks and nobody claims it, delete and record that too. If something breaks, you have learned who owns it. Assign the owner properly instead of restoring the mystery.

Write the owner down at that point. Half the value of a review is not the removals, it is converting unowned things into owned things.

Evidence, without turning it into a project

Keep the review light enough that it happens, and complete enough that it means something later.

Record which lists were reviewed, on what date, by whom, what was removed or reduced, and what was disabled pending a claim. One page. If a customer, an insurer or an auditor asks how you manage access, that page is a better answer than a policy, because it shows the thing was done rather than described.

Where a questionnaire asks you to map the work onto a recognized set of controls, the United States National Institute of Standards and Technology's Cybersecurity Framework is a free vocabulary to borrow, and access management sits in its protect function.

Attach the review to your control register so it has an owner and a cadence, in the way described in security foundations controls.

Tie the cadence to events, not only the calendar

Quarterly is a reasonable default and it is not the important part. These events should each trigger a review of the relevant list, whatever the date:

Using the review as the buying test

Now the second meaning. If you are evaluating a tool, do not ask for a demonstration. Ask it to produce the four lists above for your own environment during the trial, and time each one.

Score it on what comes back: does the admin list include people who hold rights through a group or nested group?

Does the customer data list include anyone with export capability, not only named grants? Can it show non-human accounts at all, and can it answer for a date last month, or only today?

Then test the other half: remove a test account and see what actually stops, including a session that was already open. A tool that produces good lists and cannot end access quickly has told you which half of the job it does.

Products that fail these tests are not useless, they are provisioning tools rather than records, and knowing which you are buying is the point. The rest of the requirements, including retention and coverage, are in best identity and access software 2027.

When you have no tool at all

The review still works, and for a small business it may be the only part of formal access management worth doing.

Read the administrator page of each platform you use, in turn, your current staff list beside you. Read the shared vault access list, where applications outside any directory live, as described in identity and access alternatives.

That is a morning, once a quarter, and it finds the account belonging to someone who left, the administrator nobody remembers appointing, and the integration from a project that ended. Those three findings are the substance of most access reviews at any size. The lifecycle they come from is set out in identity and access.

Common questions

How long should a review take?

If it takes more than a morning, the scope is wrong rather than the effort. Narrow the lists until it fits, then widen only if the narrow version stops finding anything.

What if the reviewer approves everything without looking?

Expected, and worth designing against. Small lists help, because a list of two hundred entries guarantees rubber-stamping. So does asking for a reason on anything sensitive that is being kept. And so does the removal default, which makes inattention produce removals rather than retention.

Should we review non-human accounts differently?

Yes. They have no leaving date, no complaints, and often no owner, so the useful question is not who has this but what would break if it stopped. Disable-and-wait is the practical way to find out.

Does a review help if we cannot remove the access anyway?

It helps more, not less. Knowing that four people can reach a system you cannot control access to is exactly the finding that justifies changing the system, adding a compensating check, or moving the data. Recording what you cannot fix is legitimate work, and the operating case for it is in identity and access features.