Access Review & Recertification
Periodically review who has access to what, confirm it's still needed, and revoke what isn't. Kills the slow-drip accumulation of stale permissions that turn into audit findings.
On this page
Visual Flow
Rendering diagram…
When to Use This Pattern
Use access review whenever access matters and people change roles or leave:
- Production system access (databases, admin consoles, deploy keys)
- Financial systems with transaction-level permissions
- Customer data in support, sales, or CRM tools
- Any resource flagged by SOX, SOC 2, ISO 27001, or similar
- Anywhere "why does that person still have X?" is asked more than once a year
If access never changes and no one ever leaves your company, you're lucky and you don't need this pattern.
How It Works
On a cadence (monthly for critical systems, quarterly for most, annually for long-tail), a process enumerates every access grant and routes it to a reviewer — typically the grantee's manager, the system owner, or a data steward. The reviewer confirms the grant is still needed or revokes it.
Grants not confirmed by the deadline are auto-revoked. "No response" must not mean "keep" — that's how stale access accumulates.
Celebrate revocations. A review that revokes nothing is a review the reviewers didn't do. Report on "access removed this quarter" as a security metric.
Implementation Guide
Step 1: Build the access inventory first
You can't review what you can't see. Ingest grants from every system (IAM, databases, SaaS tools, file shares) into a single table. This alone often reveals surprises.
Step 2: Define the reviewer for each grant type
System owner, grantee's manager, data steward, or a mix. Encode the rule per system. When an edge case surfaces ("this group has no owner"), fix it in the inventory, not per-review.
Step 3: Generate per-reviewer review packets
Each reviewer should see only their scope, with enough context to decide: user, resource, what it grants, when last used, who originally approved. "Last-used" is the single most useful signal.
Step 4: Enforce deadlines with auto-revoke
Non-response is revocation. Communicate this explicitly at every reminder. The first time you auto-revoke someone important, expect noise; stand firm, re-grant if appropriate, and the culture shifts.
Step 5: Close the loop with revocation execution
Confirmed revocations must actually remove access. Integrate with your IAM, HR, and tool APIs so a "revoke" click propagates everywhere within minutes. Manual tickets to remove access is how revocations get forgotten.
Tips & Best Practices
- Review grants, not groups. If a user is in a group that grants 40 permissions, review what they effectively have, not the group abstraction.
- Separate "still needed" from "still correct". A grant can be needed but should be a lower privilege. Offer "revoke" and "reduce" options.
- Use last-used data to pre-flag. Access not used in 90 days is almost always revocable. Highlight these for reviewers.
- Don't email spreadsheets. Build a proper review UI. Spreadsheet reviews are missed, lost, or faked.
- Keep a complete history. Every review cycle's decisions, for every grant. Auditors will ask and you'll need a good answer.
Related patterns
Immutable Audit Trail
Record every significant action to an append-only log that can be inspected but not altered. Essential for compliance, incident response, and answering 'who changed this and when?'
Decision Table
Externalize complex branching logic — pricing tiers, eligibility rules, routing decisions — into a readable table that business users can maintain without a developer in the loop.
Regulatory Data Request Handler
Process CCPA, GDPR, and other data subject access requests (DSARs) within legally mandated timeframes. Manage intake, identity verification, data collection, review, and response.