How to run a quarterly access review, step by step

Why the cadence matters as much as the review

A practitioner answering a r/soc2 question about Type II evidence summed up the ask: "the auditor wants to see who reviewed, when, what the outcome was, and that it happens on a defined cadence" (r/soc2). The last part is the one a single good review cannot prove. SOC 2 and ISO 27001 generally leave the interval to you, and the auditor then tests whether you kept the interval your own policy states. Quarterly is the common choice: frequent enough to catch leavers and role changes before they pile up, rare enough that reviewers still read what they approve.

So the goal is not one perfect review. It is the same review, on the same systems, closed on time four quarters in a row.

Step 1: Pick the systems by risk

Two weeks before the review opens, choose what is in it. Do not start with every system you own. Start with the ones an auditor or an attacker would start with:

• Systems in audit scope. Whatever your SOC 2 or ISO scope names, plus anything that holds customer data.
• Money and identity. Accounting, payroll, banking portals, the identity provider itself, and the admin consoles for email and cloud.
• Privileged roles anywhere. Admin, owner and billing roles, even in small tools. Three owners on a ten-person app deserve a reviewer's attention more than a read-only wiki does.

Three to five systems is a reasonable first quarter. For each one, write one plain sentence per entitlement that says what it lets someone do. A reviewer who cannot tell what "Contributor" means will approve it; the description is what turns a click into a decision.

Step 2: Export the access list on day 0

Pull users, entitlements and last-login dates from each system on the day the review opens, and note how and when you pulled them: the admin page or report name, and the time. That export is the population an auditor samples from, so it should come from the system, not from memory or from last quarter's sheet.

Do not clean the list first. Deleting an account you already know is stale feels tidy, but it erases the evidence that the review caught it. Leave it in, let the reviewer mark it, and record the removal at close-out.

Step 3: Split the list by reviewer

Every row gets exactly one accountable reviewer: usually the user's manager for business apps, and the system owner for infrastructure and admin roles. Two rules prevent most problems later:

• Nobody reviews their own access. A manager's own rows go to their manager or to the system owner.
• Rows without an obvious reviewer go to the review owner, not to a shared mailbox, so one person is accountable for them.

Short lists get read. A sysadmin describing their own company's review put the alternative in numbers: "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). Per-reviewer lists that show only that person's rows, with a description beside every entitlement, are the cheapest fix for both numbers. Give every row three possible answers: keep, revoke, or don't know. A "don't know" is useful, because it shows where the descriptions or the ownership need work.

Step 4: Chase on a fixed schedule

Set the due date ten working days out and publish the reminder schedule with the invitation, so nobody is surprised by it:

• Day 0. Invitations go out with the due date, what each answer leads to, and who to ask about an entitlement the reviewer does not recognize.
• Seven days before the due date. A reminder to everyone who has not submitted.
• Two days before. A second, shorter reminder.
• On the due date. A final reminder.
• Overdue. A reminder every few days, and after the second one, a note to the reviewer's own manager.

Check completion every day while the review is open. If a reviewer is on leave, reassign their rows and write down who took them over and why. A delegation recorded at the time is evidence; one reconstructed for the auditor months later is a question you will have to answer.

Step 5: Close out and compare with last quarter

A review is not finished when the last reviewer submits. It is finished when the decisions have been carried out and written down:

• Act on every revoke. The system owner removes the access and records the date and who did it. A revoke decision with no follow-through is worse than no decision, because the record shows you knew.
• Resolve every "don't know". Ask the system owner, decide, and record who decided. Anything still open becomes an exception with an owner and a target date.
• Look at bulk approvals. If a reviewer approved hundreds of rows within a minute, ask for a written justification now rather than when the auditor asks.
• Lock the record and file it where an auditor can find it in a minute: one folder per quarter, named the same way every time.

Then compare with the previous quarter for the same system. Three lists answer most follow-up questions: users added since last time, users who disappeared, and entitlements that changed. Check that last quarter's revocations are still revoked. A leaver who appears in two reviews in a row points to the offboarding process rather than the reviewer, and that is worth fixing before the next quarter opens.

The quarter on one page

Counting working days from the day the review opens:

• Two weeks before. Confirm the systems, the reviewers and the entitlement descriptions.
• Day 0. Export, split by reviewer, send invitations.
• Days 1 to 10. Reminders on schedule, a daily completion check, reassignments for leave. Day 10 is the due date.
• Days 11 to 15. Chase overdue reviewers, act on revocations, resolve "don't know" rows.
• Day 15. Close, compare with last quarter, file the record, and note what to change next time.

Put the next quarter's start date in the calendar on the day you close this one. Cadence is the first thing to slip, and the one thing that cannot be repaired afterwards.

Questions

Do we have to review every system every quarter?

Not necessarily. Many teams review privileged access and in-scope systems quarterly and lower-risk tools less often. Whatever you choose, write it into your access-control policy and keep to it, because the auditor tests you against what the policy says.

How long should a review stay open?

Long enough for a reviewer back from a week of leave to finish, and short enough that it does not drift into the next quarter. Ten working days to the due date, plus a week for overdue reviewers and close-out, is a reasonable default.

What if a manager never responds?

Escalate to their manager with the date and the rows still open, and record the escalation. A documented non-response followed by a decision from someone accountable still closes the review. A review that quietly expires does not.

Next step

Everything above works with a spreadsheet and a calendar. If you would rather not run the chasing by hand, AttestProof follows this schedule from a CSV. Each reviewer gets a link, with no account, and marks every row Keep, Revoke or Don't know. Non-submitters get a reminder seven days before the due date, two days before, on the day, then every three days overdue, up to four times. Closing the review produces the evidence pack.

What it does not do: connect to your identity provider, or remove anyone's access. You export the list, the system owner makes each change, and you mark it actioned in the review. Email reminders and the comparison with the previous review start on the Starter plan; on Free you copy the reviewer links yourself. The help page walks through a first review, and the plans are on the pricing page.