AttestProof
Why access reviews get rubber-stamped, and five fixes
Published 27 Oct 2026
This is the third process guide in our access-review set. The user access review template gives you the spreadsheet and the quarterly access review guide gives you the calendar. This one is about the failure both of them are built to prevent: a review that is finished on time while nobody actually decides anything.
A sysadmin described their own company's review like this: "9,800 rows. 140 managers. Due in 10 days. Completion rate last quarter was 34%… The managers who do complete it approve everything. Every single row" (r/sysadmin). That review produces a signed-off spreadsheet and very little information. It looks exactly like a careful review unless the record shows how each decision was made, and most of the fixes below are about making that visible.
What a rubber-stamped review looks like
You rarely need an audit to spot it. Open last quarter's review and look for these:
- Nothing revoked, again. Every row kept, review after review, on a system where people join, change roles and leave.
- Leavers kept. Accounts of people who have left, approved by the manager they used to report to. Check a few against your HR leavers list.
- Decisions faster than reading. Hundreds of rows answered within a minute or two of each other, often on the due date.
- No questions. Not one comment or "don't know", even on entitlements named like
FIN_GL_RW_03that few reviewers could explain.
One of these on its own can be innocent. A short list reviewed by someone who knows every account can honestly come back as all keeps. Two or three together usually mean the review made approving the easy answer.
Why it happens
Reviewers are rarely lazy. The design of the review gives them the wrong incentives:
- Too many rows for one person. 9,800 rows across 140 managers is 70 each on average, but the split is never even: whoever owns the finance or engineering groups gets hundreds.
- Rows nobody can read. An export carries the system's own names for things. A reviewer who cannot tell what a group grants cannot judge whether someone still needs it.
- Two answers only. With just approve and revoke, revoking is a decision that might break someone's work, and approving feels like no decision at all. Uncertain reviewers pick approve.
- Nothing happens afterwards. When revocations are never carried out, or nobody can tell whether they were, reviewers learn that their answers do not matter.
Five fixes
Each of these works in a spreadsheet. None needs a new tool or a new license.
Split the review by reviewer, and keep each share readable. Every reviewer gets only their own rows, in a separate file or a filtered tab, with the due date at the top. When one person's share runs to hundreds of rows, split it by system or move part of it to the system's owner. Send reminders a week before the due date, two days before and on the day, instead of one email at the start.
Describe every entitlement in plain words. Add a description column: one line on what the access lets someone do ("can post journal entries in the general ledger"), written once by the system owner and reused every quarter. Add each user's last sign-in date too. Microsoft's own access reviews use it as a decision helper: with "No sign-in within 30 days" selected, users who have not signed in during the past 30 days are recommended for denial (Microsoft Learn). A spreadsheet can show the same signal with one extra column.
Make "don't know" a valid answer, and route it. A reviewer who cannot tell what a row grants should say so instead of approving by default. Send every "don't know" to the system owner with a date to answer by. A handful of them is a good sign, because it means people are reading. A cluster on one entitlement means its description needs rewriting.
Make bulk approval cost a sentence. Allow "keep everything" only with a written reason, and record it as one bulk decision instead of hundreds of individual approvals. Microsoft's access reviews offer the same lever: a "Justification required" setting that makes the reviewer "supply a reason for approval or denial" (Microsoft Learn). In a spreadsheet, a reason cell next to the reviewer's sign-off does the job.
Show the exceptions and the follow-through. List every revoke with the date the access was actually removed and who removed it, every "don't know" with how it was settled, and every bulk approval with its reason. Decide in advance what happens to rows nobody answered. Microsoft's access reviews ask the same question when you set one up, with four options: no change, remove access, approve access, or take the recommendations. Whichever you choose, write it down, and never let silence turn into a keep without anyone seeing it.
The last fix is the one an assessor's wording points at. PCI DSS requirement 7.2.4 asks for a review at least once every six months in which "Any inappropriate access is addressed. Management acknowledges that access remains appropriate" (the PCI DSS v4 text, quoted on Microsoft Learn). A rubber stamp produces the acknowledgement without the review behind it.
Numbers that show the review is real
Track four numbers per review and per system, and keep them next to last quarter's:
| Measure | How to count it | What to watch |
|---|---|---|
| Completion | Rows decided ÷ rows sent, per reviewer | Who finishes late or not at all, not only the overall rate |
| Bulk-approval rate | Rows kept through "keep everything" ÷ rows decided | A high rate on a system with known joiners and leavers |
| Revocations | Revoke decisions, and how many were carried out and when | Zero, quarter after quarter, or revokes still open at the next review |
| Don't know | "Don't know" answers ÷ rows decided, and how each was settled | None at all, or the same entitlement every time |
None of these has a correct value. They are there so that a change shows up: a reviewer whose bulk-approval rate drops after the descriptions improve is reading the rows now.
Questions
- Is bulk approval ever fine?
- Yes. A manager with eight direct reports who knows every account can keep all of them in good conscience. The fix is not to ban it, but to make the reviewer say why and to keep that reason in the record.
- Should rows nobody answered be removed automatically?
- It depends on the system. Removing access on silence is strict and can break someone's work; approving on silence hides the problem. Pick one rule per system, write it down before the review starts, and list the unanswered rows as exceptions either way.
- Will these fixes satisfy our auditor?
- That is a judgment for you and your auditor, and we do not give audit advice. What the fixes do is give the auditor something to look at: who reviewed, when, what each decision was and what happened next. Our guide on what auditors ask for in an access review covers that side.
Next step
All five fixes work in a spreadsheet. If you would rather not build the split, the reminders and the exception lists by hand, AttestProof runs the review from a CSV. Each reviewer gets a link to their own rows, with no account, and marks every row Keep, Revoke or Don't know, with an optional comment. "Keep all remaining" requires a typed justification and is recorded as a bulk decision. Reminders go out seven days before the due date, two days before and on the day, then every three days while overdue, up to four times. The dashboard shows completion, decisions by type and every revoke, and the evidence pack lists the exceptions, including Don't know and bulk-approved rows, next to the revocation follow-through.
What it does not do: connect to your identity provider or remove anyone's access. You export the list, someone with admin rights makes each change in the system, and the review records that it was done. It is not a GRC platform, and it does not make you SOC 2 compliant. The free plan covers one system with up to 50 rows per review, with reviewer links you copy yourself; email invites and reminders start on the $29-a-month Starter plan. The help page walks through a first review, and the plans are on the pricing page.