What is Access Review?

Definition

An access review — sometimes called access certification, access recertification, or entitlement review — is a periodic process where business and security stakeholders confirm that the access granted to identities is still appropriate, necessary, and authorized.

For each reviewed entitlement the reviewer typically chooses to:

• Certify — keep the access; it is still needed.
• Revoke — remove the access; no longer needed.
• Modify — keep partial access; some permissions should be removed.
• Reassign — escalate or change the reviewer.

NIST SP 800-53 (AC-2(7), AC-6(7)) and most major frameworks (SOX, HIPAA, PCI DSS, ISO/IEC 27001, SOC 2) require periodic review of accounts and privileges.

---

Why Access Reviews Matter

Even a perfectly provisioned environment drifts over time:

• People change roles and keep old access.
• Projects end but access remains.
• Temporary elevations become permanent.
• Service accounts gain permissions and never lose them.
• OAuth apps installed years ago still have tenant-wide scope.

Without periodic review, the environment quietly accumulates:

• Privilege creep
• Toxic combinations (SoD violations)
• Orphaned accounts
• Excessive service-account permissions
• Forgotten admin assignments

Access reviews give the organization a structured chance to catch and fix this drift.

---

Types of Access Reviews

1. User Access Review

Reviewers confirm that a specific user's entitlements are still appropriate.

Common reviewers: the user's manager.

2. Resource Access Review

Reviewers confirm that the list of who has access to a specific resource (a system, repo, dataset) is still appropriate.

Common reviewers: the resource owner.

3. Role / Group Membership Review

Reviewers confirm the membership of a role or group, especially privileged groups (Domain Admins, Global Administrators, AWS root group equivalents).

Common reviewers: security or platform owner.

4. Privileged Access Review

Focused review of all privileged accounts and elevations — typically more frequent than standard reviews.

5. Service Account / Non-Human Identity Review

Confirms that service accounts, workload identities, OAuth apps, API keys, and AI agents still have an active purpose, owner, and appropriate permissions.

6. Cross-System Reviews

Reviews that look at effective access across systems (AD + Entra ID + AWS + SaaS), not just per-system entitlements.

---

How Often Should Reviews Happen?

Scope	Recommended Frequency
Standard user access	Annually
Sensitive data access	Quarterly
Privileged groups (Domain Admin, Global Admin, root)	Quarterly or monthly
Service accounts	Annually, plus event-driven
OAuth apps and tenant-wide permissions	Quarterly
Cloud admin roles	Quarterly + JIT review
AI agent scopes	Quarterly
After major change (M&A, reorg)	Event-driven

PCI DSS 4.0 explicitly requires reviews at least every six months for system component access.

---

Access Review Process

Step 1: Define Scope

Decide what is being reviewed: which users, which entitlements, which systems, which time window.

Step 2: Identify Reviewers

Pick the right person:

• Manager for user-centric reviews.
• Resource owner for resource-centric reviews.
• Security or platform owner for privileged reviews.

If you ask the wrong reviewer, they'll just rubber-stamp.

Step 3: Provide Context

Reviewers need to understand:

• What does this entitlement actually allow?
• Has it been used recently?
• Does it create risk (sensitive data, admin power, SoD violation)?

Without this, reviewers can't make informed decisions.

Step 4: Run the Review

Use an IGA tool or workflow:

• Send tasks to reviewers.
• Track completion.
• Escalate stale tasks.
• Capture decisions and justifications.

Step 5: Remediate

Approved revocations must actually happen. This is the step most often skipped.

Step 6: Document and Audit

Capture evidence:

• Who reviewed
• When
• What was decided
• What was changed

This is the artifact auditors will ask for.

Step 7: Continuously Improve

Use review outcomes to:

• Tighten roles and groups.
• Improve provisioning rules.
• Reduce future review fatigue.

---

Examples

Example 1: Quarterly Privileged Group Review

The CISO team reviews Domain Admins, Enterprise Admins, Global Administrators, and AWS Organization Admins every quarter:

• Each member must be reconfirmed by name.
• JIT eligibility is preferred over standing membership.
• Inactive admins are removed.

Example 2: Mover Event Review

A developer transfers from one product team to another:

• The IGA tool triggers a focused review of the developer's existing entitlements.
• The new manager certifies what should be kept.
• The old manager confirms what should be removed.

Example 3: SaaS Resource Owner Review

The owner of the customer data warehouse reviews the list of users with read or write access every six months. Inactive accounts and unused service accounts are removed.

Example 4: Service Account Annual Review

Every service account is reviewed annually:

• Owner is confirmed.
• Purpose is reconfirmed.
• Permissions are right-sized to actual usage.
• Stale or unowned accounts are decommissioned.

Example 5: OAuth App Review

The IT team reviews enterprise OAuth applications quarterly:

• Apps no longer in use are removed.
• Apps with tenant-wide permissions are re-evaluated.
• Suspicious or unrecognized apps are revoked.

Example 6: AI Agent Scope Review

The product team reviews each AI agent quarterly:

• Confirm tool/action scopes are still appropriate.
• Validate human-in-the-loop policies.
• Remove unused tools from the agent's allow list.

---

Common Access Review Pitfalls

1. Rubber Stamping

Reviewers approve everything to clear the queue. Common when reviews are frequent, large, and lack context.

2. Wrong Reviewer

Asking a manager about a complex technical entitlement they don't understand → rubber stamping.

3. No Remediation

Decisions are made but never enforced. The review is theater.

4. Reviewing the Wrong Things

Reviewing benign access in detail while ignoring privileged groups and service accounts.

5. No Risk Context

Treating every entitlement as equally important wastes attention.

6. Ignoring Effective Access

Reviewing direct assignments only — missing access granted via nested groups, inheritance, or attack paths.

7. Manual Spreadsheets

Reviews tracked in spreadsheets are error-prone, slow, and hard to audit.

8. No Continuous Layer

Annual reviews catch things 364 days late. Without continuous detection, risk lingers.

---

Best Practices

1. Risk-based scope — focus reviews where risk concentrates (privileged, sensitive data, NHIs).
2. Right reviewer for the right entitlement — manager, resource owner, or platform owner.
3. Provide usage context — when was this last used? What does it grant?
4. Use IGA tooling, not spreadsheets.
5. Auto-remediate revocations whenever possible.
6. Combine periodic + continuous monitoring.
7. Detect SoD violations during reviews.
8. Include non-human identities in every review cycle.
9. Include effective access, not only direct assignments.
10. Measure quality, not only completion (e.g., revocation rate, review duration).
11. Tie reviews to mover and leaver events, not only the calendar.
12. Use attack path analysis to surface high-impact access for priority review.

---

Access Review Checklist

• Are privileged groups reviewed at least quarterly?
• Are sensitive resources reviewed at least quarterly?
• Are service accounts and OAuth apps included?
• Are AI agent scopes reviewed?
• Are the right reviewers assigned per entitlement?
• Do reviewers see usage and risk context?
• Are revocations enforced and verified?
• Are SoD violations flagged in the review?
• Is effective (not only direct) access reviewed?
• Are review results auditable?
• Is review fatigue measured and addressed?

---

How Forestall Helps

Forestall makes access reviews more meaningful by focusing them on real risk:

• Highlights overprivileged identities and stale entitlements.
• Surfaces effective access through nested groups, ownership, and ACL chains.
• Identifies attack paths to Tier 0 assets that should be reviewed first.
• Detects orphaned and dormant identities continuously, not just on review day.
• Reduces noise so reviewers can spend time on decisions that actually matter.

Used alongside an IGA tool, Forestall turns access reviews from a compliance task into a real risk-reduction exercise.

---

Frequently Asked Questions

Is access review the same as access certification?

The terms are usually used interchangeably. Some frameworks distinguish "review" (any check) from "certification" (formal sign-off).

How long should an access review take?

For a single reviewer: minutes per identity if context is provided. For a quarter-wide review: weeks of elapsed time, but only hours per reviewer.

Can access reviews be automated?

Decisions still need human accountability, but the work around them — task routing, evidence collection, remediation — should be automated.

Are access reviews required by law?

Many regulations (SOX, HIPAA, PCI DSS, GDPR-related controls) require periodic review of access. Frameworks like NIST 800-53, ISO 27001, and SOC 2 explicitly require it.

What if reviewers always approve everything?

That signals a process problem. Improve scoping, reviewer choice, and risk context — and measure revocation rate as a quality metric.

---

Conclusion

Access reviews are the safety net that catches what provisioning, mover, and leaver processes miss. Done well, they prevent privilege creep, surface stale access, and demonstrate compliance. Done poorly — as a calendar-driven rubber stamp — they consume time without reducing risk.

The best access review programs are risk-focused, context-rich, continuously informed, and tightly integrated with remediation. They don't just ask "should this person still have access?" — they ask "is this access still safe given everything else they can reach?"