User Access Reviews That Aren't Rubber Stamps

A user access review (also called an access certification) is a periodic check where a manager or application owner confirms that each person’s access is still appropriate, and revokes what isn’t. It becomes a rubber stamp when reviewers get too much to judge, too little context to judge it, and no evidence that their decisions change anything. Fix those three things and the review starts doing its job.

I’ve watched a lot of access review campaigns. The ones that fail don’t fail because of the tool. They fail because the process quietly teaches reviewers that clicking “approve all” is the sensible thing to do.

What is a user access review?

A review campaign takes a slice of access (an application, a set of entitlements, everyone reporting to a manager) and asks a named reviewer to make a decision on each line: keep it or remove it. The decisions get recorded, revoked access gets removed, and the whole thing becomes evidence for the next audit.

There are a few common shapes:

• Manager reviews. Each manager certifies everything their direct reports can reach. Good for catching access that no longer fits someone’s job, bad when the manager has no idea what half of it means.
• Application owner reviews. The owner of a system certifies everyone who can use it. Better context about the entitlements, less context about the people.
• Entitlement or role reviews. Someone confirms that a role still contains the right permissions, separate from who holds it.
• Privileged access reviews. A tighter, more frequent pass over admin rights, service accounts and membership in your PAM policies.

Access reviews are one part of a wider identity governance and administration program. They’re the part auditors ask for by name, which is exactly why they’re so easy to turn into paperwork.

Why auditors require access reviews

Almost every control framework expects you to show that access is periodically re-validated, not just granted correctly once.

• SOX. Access to financially significant systems is a core IT general control. External auditors will test that reviews happened, that the right people did them, and that revoked access was actually removed.
• HIPAA. The Security Rule expects covered entities to authorize access appropriately and to review it, so that only the workforce members who need patient data can reach it.
• PCI DSS. Version 4.0 calls for user accounts and their privileges to be reviewed at least once every six months, with management acknowledging that the access is still appropriate.

None of these frameworks says “make managers click through 3,000 rows in December.” That part is self-inflicted. The intent behind every one of them is the same: least privilege, verified by someone who would know.

Why access reviews become rubber stamps

When approval rates sit at 98 or 99 percent quarter after quarter, nobody is reviewing anything. The environment isn’t that clean. Here is what usually causes it.

Volume. A manager with 12 reports, each holding a couple of hundred entitlements, gets thousands of decisions dropped on them with a two-week deadline. The rational response is to approve everything and get back to work.

No context. The reviewer sees a list of names and entitlements and nothing else. No indication of when the access was granted, why, by whom, or whether it’s ever been used.

Entitlements nobody can read. “SAP_FI_GL_POST_X02” or “grp-app-fin-rw-legacy” means nothing to a sales director. People don’t revoke what they don’t understand, because the risk of breaking something feels bigger than the risk of leaving it.

No consequence. If a reviewer approves everything and nothing happens, while a reviewer who revokes access gets angry calls from their team, the incentives point one way.

Revocations that never happen. This is the one that does the most damage. A reviewer marks access for removal, it becomes a ticket, the ticket sits in a queue, and three months later the access is still there for the next campaign. Reviewers notice. Once they believe their decisions don’t matter, they stop making them.

What this usually looks like: Say a quarterly campaign closes with a 99.6% approval rate and a median decision time of a few seconds per line. On paper, that’s a clean environment. Then someone pulls usage data and finds that a large share of the approved entitlements haven’t been touched in a year, including access held by people who changed departments. Every box was checked, and nothing was reviewed.

How to fix your access review process

None of this needs a new platform on day one. It needs the review designed for the person doing it.

Scope reviews by risk

Not all access deserves the same scrutiny. Review high-risk systems (financial applications, systems with regulated data, anything with admin rights) quarterly or more often. Review low-risk SaaS annually, or exclude birthright access entirely if it’s provisioned automatically from HR and removed the same way. Fewer, sharper decisions get better answers than a giant campaign covering everything.

Describe entitlements in plain language

Every entitlement in scope should have a short, human description and a risk rating. “Can post journal entries to the general ledger, high risk” is a decision a manager can make. Getting application owners to write these descriptions is tedious, and it’s the single highest-value cleanup I know of for review quality. Start with the entitlements that show up most in reviews.

Show usage data

If you can tell the reviewer “last used 14 months ago” or “never used,” the decision makes itself. Last-login and last-activity data from the application, the directory or your access management layer turns a guess into a judgment. Unused access is the easiest revocation to justify and the safest to make.

Add event-driven micro-certifications

The calendar-based campaign is a blunt instrument. Better to trigger small, targeted reviews when something changes: a person moves departments, a contractor’s end date approaches, someone is granted a high-risk entitlement outside their role, or an account goes dormant. A manager reviewing five entitlements the week after a transfer will make better decisions than one reviewing 500 at year end. Movers are where access piles up, so this is where event-driven reviews pay off fastest.

Close the loop on revocation

A revoke decision should remove access automatically where the system is connected, and generate a tracked task with a deadline where it isn’t. Then verify it: the next aggregation should confirm the access is actually gone. Report on revocations that are still open past their due date. Auditors increasingly test this, and they’re right to.

Measure the right things

Completion rate tells you the campaign finished. It doesn’t tell you it worked. Track these instead:

Metric	What it tells you
Revocation rate per campaign	Whether reviewers are making decisions at all
Revocation rate per reviewer	Who is rubber-stamping (near 0%) and who is actually reading
Median time per decision	Seconds per line usually means bulk approval
Revocations completed on time	Whether the loop is actually closed
Repeat findings	Access revoked last cycle that came back
Unused access approved	Reviewers ignoring the usage data you gave them

A low revocation rate isn’t automatically bad, especially once a program matures. A low rate combined with fast decisions and a lot of unused access is the signature of a rubber stamp.

What I’d look for: If I could make only one change, it would be closing the loop on revocations. Context and smaller campaigns help reviewers make better decisions, but until reviewers see their revocations actually happen, they have no reason to make them. Watch revocations completed on time first. When that number climbs, revocation rates per reviewer usually follow.

What to look for in user access review software

You can run reviews in spreadsheets. Plenty of organizations still do, and the evidence is about as convincing as you’d expect. User access review software, usually part of an IGA platform, earns its keep in a few specific ways:

• Automated data collection. Pulling access directly from connected applications instead of exported spreadsheets, so reviewers see what’s actually there.
• Context in the review screen. Entitlement descriptions, risk ratings, usage data, peer comparisons (“nobody else on this team has this”), and the original request and approval.
• Flexible campaign types. Manager, owner, role and event-triggered reviews, with delegation and escalation when a reviewer doesn’t respond.
• Closed-loop remediation. Revocations pushed straight to connected systems, or tracked as tasks, then verified on the next data pull.
• Audit-ready evidence. Who reviewed what, when, what they decided, and proof that removals happened.
• Privileged access in scope. Membership in PAM safes and policies should show up in reviews like any other entitlement.

That last point is the one I push hardest. I’ve wired SailPoint back into PAM so that a manager reviewing an engineer sees “can check out domain admin credentials” in the same screen as their SaaS apps. If your privileged access lives in a separate system that nobody certifies, your most dangerous entitlements are the ones getting the least review. Pairing reviews with just-in-time access helps too, since there’s less standing privilege left to certify.

A common version of this: The first campaign that includes privileged entitlements tends to surface the same things: people who still hold PAM safe or policy membership from a project that ended, privileged access granted directly instead of through a request, and vaulted accounts whose owner has left. None of it is exotic. It simply never appeared in a review before, because it lived in a system nobody certified.

When you evaluate tools, run a pilot with your messiest application and your busiest manager. A demo with tidy entitlement names tells you nothing about how the product handles yours.

Where to start

If your access reviews are rubber stamps today, don’t redesign everything at once. Pick your highest-risk application, write plain-language descriptions for its entitlements, add last-used data, and make sure every revocation from the next campaign is actually removed and verified. Then show reviewers the results. Once people see their decisions take effect, they start making real ones.

For more on the governance side, see the IGA topic hub, and for the audit and compliance angle, the GRC hub.