The access review nobody dreads

Every few months, managers get a list of who has access to what and are asked to confirm it. Most of them click approve on the whole thing. Send them a short, ranked list with reasons instead, and have the system remove whatever they reject.

Ask a manager to certify four hundred entitlements in a spreadsheet and you'll get four hundred approvals in eleven minutes. A review that approves everything verifies nothing, and a sterner reviewer won't change that. What helps is a smaller queue of riskier items, each one explained.

Auditors have noticed. They now routinely write up near-total approval with decisions made in seconds, since that's evidence the control exists only on paper. A finding like that lands on the CFO's desk and usually means a remediation plan, retesting and a harder audit next year.

The business risk sits underneath the audit one. Access nobody removed is how a person who moved out of accounts payable can still pay a vendor, and how a leaver's account keeps working for months. If you take card payments, PCI DSS v4.0.1 requirement 7.2.4 wants every user account with access to your cardholder data systems reviewed at least once every six months, vendor accounts included. Management has to acknowledge the access is still appropriate, and anything that isn't has to be dealt with. A pile of blanket approvals doesn't meet that for long.

Reviewers approve everything because the campaign gives them no basis to do anything else. A raw entitlementdefinitionOne permission in one system, like being able to post journal entries in the finance app. Someone who's been at a company a few years usually has dozens. name such as SAP_FI_GL_DISP_014 carries no meaning to the manager certifying it, so the rational move is bulk approval. Before any scoring, the campaign has to translate it into business terms, show when it was last used, and flag any collision with something else the person holds. If your identity data can't answer those questions, fix the data first. A certification built on entitlement sprawl and orphaned accounts just launders bad data into signed attestations.

Most access in a healthy organization is boring: birthright entitlements, unchanged since the last campaign, matching the peer group. Certify it by policy and get it out of the human queue. What reaches a reviewer should be the exceptions, ranked. A reviewer facing twelve ranked items with plain-language reasons makes twelve real decisions. A reviewer facing four hundred flat rows makes one decision, four hundred times.

1. Segregation of duties (SoD) conflicts first: the create-vendor-and-pay-vendor combinations that fraud audits exist for.
2. Dormant access nobody has used in 90+ days.
3. Peer-group outliers, people holding entitlements almost nobody in their role holds.
4. Privileged accounts.
5. Access that survived a recent transfer.

The SoD model underneath deserves real engineering, because role-level rules miss most real conflicts. "Accounts payable clerk cannot also be vendor admin" sounds rigorous until you find the conflict living inside one role, granted by two entitlements nobody mapped. Model the rules at entitlement level. Run them at request time so toxic combinations get refused before they exist, and again at certification so the ones that slipped through arrive at the top of the queue with the conflict spelled out.

The same event-driven thinking shrinks the campaigns themselves. When someone transfers between departments, kick off a targeted micro-certificationdefinitionA small review kicked off by an event, usually a transfer. One reviewer checks just the access the person kept, and does it that week instead of at quarter-end. of the access they kept: five items, one reviewer, this week. Waiting for quarter-end is how a finance analyst ends up still holding their old HR entitlements months later.

# q3 certification: scoped by risk, not org chart
campaign: q3-user-access-review
auto_certify: low-risk · unchanged · peer-aligned  // 82% of items
queue[1]: sod_conflict → create_vendor + approve_payment
queue[2]: dormant_90d · peer_outlier · post_transfer
revoke_action: auto-deprovision + closure check
✓ median reviewer time: minutes
✓ evidence: logged with every decision

A revocation decision that ends in a ticket is a wish. Auditors have learned to sample for exactly this gap, tracing certified revocations to target systems where the access is still alive. So the campaign has to drive deprovisioning automatically and then check the access is actually gone, with the confirmation logged next to the decision. People call that closed-loop remediationdefinitionRemoving access automatically, then checking the target system to make sure it's really gone. The check gets logged, so you can show an auditor without digging..

Do it and the evidence auditors want comes for free. You already know who reviewed what on which signals and what was revoked, and you can prove it stayed revoked. In our identity governance engagements the audit conversation shrinks to an export, because the campaign has been emitting its own proof all along. Nobody books a preparation meeting or goes hunting for screenshots. The review nobody dreads is the one that documents itself.

The same phases work for a failed rollout of the new design. If reviewers complain the ranked queue flags the wrong things, pause auto-certification for that app, fix the rule and rerun just that slice. Don't fall back to the full spreadsheet for everyone, because that's the finding you started with.

We design and run these campaigns as part of our identity and access management work. That usually starts with cleaning the identity data and writing the SoD rules at entitlement level, then wiring revocations to automatic removal. If you want to know where your current reviews would fail an audit sample, start with an assessment.