Checklist

Quarterly access-review checklist

A user access review only counts as evidence if it's real access, a real decision, and a real revocation. Work through this before you close the campaign.

Before you launch a campaign

Decide the scope — which systems, teams, or sensitivity tiers this campaign covers.
Confirm each in-scope system's access list is current, not a stale export from last quarter.
Identify the right reviewer for each scope — usually a manager or system owner, not a single central admin.

Give reviewers real access, not a guess

Pull together who can actually reach what, aggregated from your connected systems.
Scope each reviewer to only the access that's theirs to judge.
Surface context that helps a decision: role, last login, why the access was granted.

Run the review

Give reviewers a clear approve-or-revoke action per user, not an open-ended spreadsheet.
Send reminders on a cadence so campaigns don't stall halfway through.
Track completion status so you can see who's done and who still needs a nudge.

Follow revocations through to done

A 'revoke' decision isn't evidence until the access is actually removed.
Track each revoke decision to completion, not just to the click that recorded the decision.
Re-check that revoked access doesn't quietly come back (e.g. via a group membership) before closing the campaign.

Capture the evidence

Record every decision with the reviewer, a timestamp, and any notes.
Export the full campaign — decisions, completion status, and revocation follow-through — mapped to the access-control requirement it satisfies.
Keep the signed history; most frameworks want to see access reviews over time, not just the most recent one.

This is the workflow our access-reviews product runs on: scheduled campaigns, real access, and revocations tracked to completion.

See access reviews Back to resources

Capture the evidence

Record every decision with the reviewer, a timestamp, and any notes.

Export the full campaign — decisions, completion status, and revocation follow-through — mapped to the access-control requirement it satisfies.

Keep the signed history; most frameworks want to see access reviews over time, not just the most recent one.