Access Review
アクセス・レビュー
An access review is a recurring check that verifies whether users, service accounts, roles, and privileged permissions still match business need. It turns access control from a one-time approval into an auditable operating loop.
What it means
Access review, also called access certification in some governance programs, is the process of comparing current access assignments with role, job, system, data, and risk requirements. The reviewer confirms, changes, or removes access and records evidence. A good access review does not simply ask managers to click approve. It defines the in-scope systems, privileged roles, dormant accounts, exception owners, review frequency, evidence retention, and escalation rules so unnecessary access is actually removed.
How to calculate it
Access review is not a financial formula, but the operating quality can be measured. Use coverage, exception age, revocation speed, and stale-access rate to judge whether the review changed risk. Review coverage | reviewed access assignments / in-scope access assignments | Shows whether the review reached the intended population Revocation completion | revoked or corrected assignments / assignments marked for removal | Shows whether decisions became system changes Stale-access rate | access with no valid owner, user, or business need / in-scope access | Indicates residual risk after the review
| Lens | Formula / treatment | When to use it |
|---|---|---|
| Review coverage | reviewed access assignments / in-scope access assignments | Shows whether the review reached the intended population |
| Revocation completion | revoked or corrected assignments / assignments marked for removal | Shows whether decisions became system changes |
| Stale-access rate | access with no valid owner, user, or business need / in-scope access | Indicates residual risk after the review |
What counts / what does not
The value of an access review depends on a clear boundary. Without a boundary, reviewers may approve too broadly and miss the highest-risk permissions. Include | Human users, service accounts, admin roles, shared accounts, production access, finance systems, customer data systems | These can create material security or compliance risk Exclude | Access already removed, test-only accounts outside the production boundary, roles covered by a separate review | Avoid double counting while preserving evidence Define explicitly | Emergency access, break-glass accounts, contractor access, dormant users, group inheritance, service principals | These are common places where hidden access survives
| Item | Treatment | Why it matters |
|---|---|---|
| Include | Human users, service accounts, admin roles, shared accounts, production access, finance systems, customer data systems | These can create material security or compliance risk |
| Exclude | Access already removed, test-only accounts outside the production boundary, roles covered by a separate review | Avoid double counting while preserving evidence |
| Define explicitly | Emergency access, break-glass accounts, contractor access, dormant users, group inheritance, service principals | These are common places where hidden access survives |
What moves the number
Access-review workload and risk move when the organization, systems, permissions model, and identity data change. Role quality | Clear roles and least-privilege policies reduce ambiguous reviewer decisions Identity data quality | Accurate manager, department, employment status, and owner fields reduce false approvals Privilege concentration | Admin and production access usually need shorter review cycles and stronger evidence Change volume | Hiring, transfers, contractors, M&A, and system migrations create new access drift
| Driver | Metric impact |
|---|---|
| Role quality | Clear roles and least-privilege policies reduce ambiguous reviewer decisions |
| Identity data quality | Accurate manager, department, employment status, and owner fields reduce false approvals |
| Privilege concentration | Admin and production access usually need shorter review cycles and stronger evidence |
| Change volume | Hiring, transfers, contractors, M&A, and system migrations create new access drift |
How to design it
Design the review as an evidence-producing control, not as a generic checklist. Define the scope by system, role, data sensitivity, and review period. Assign accountable reviewers who understand the business need for the access. Pre-label high-risk access such as administrator, production, financial approval, and customer-data roles. Require a decision outcome: keep, remove, change owner, reduce role, or document exception. Track remediation until the system-of-record and the actual access state agree.
- Define the scope by system, role, data sensitivity, and review period.
- Assign accountable reviewers who understand the business need for the access.
- Pre-label high-risk access such as administrator, production, financial approval, and customer-data roles.
- Require a decision outcome: keep, remove, change owner, reduce role, or document exception.
- Track remediation until the system-of-record and the actual access state agree.
How to run it
Run the cadence according to risk. Privileged and regulated access should be reviewed more often than low-risk read-only access. Quarterly | Privileged access, production systems, finance approval workflows, regulated data Semiannual or annual | Lower-risk business applications when identity data and role design are stable Event-driven | Termination, transfer, incident, system migration, merger, new sensitive data store
- Quarterly | Privileged access, production systems, finance approval workflows, regulated data
- Semiannual or annual | Lower-risk business applications when identity data and role design are stable
- Event-driven | Termination, transfer, incident, system migration, merger, new sensitive data store
When it helps
Reduces identity and access risk by removing permissions that no longer match business need. Creates audit evidence that access was reviewed, exceptions were owned, and removals were completed. Improves role design by showing which permissions are repeatedly over-granted or repeatedly removed.
- Reduces identity and access risk by removing permissions that no longer match business need.
- Creates audit evidence that access was reviewed, exceptions were owned, and removals were completed.
- Improves role design by showing which permissions are repeatedly over-granted or repeatedly removed.
How to use it
- Access review is a control loop: scope, review, decision, remediation, evidence, and follow-up.
- The review is weak if removals are not executed in the actual system.
- Privileged access needs shorter cadence and stronger reviewer evidence than low-risk access.
- Good role and identity data make reviews faster and reduce rubber-stamp approvals.
- Review exceptions need owners, expiration dates, and escalation paths.
Decision cautions
Do not treat access review as proof that access is safe. It is one control that must connect to provisioning, deprovisioning, monitoring, and incident response. A manager approval without context is not strong evidence. Dormant accounts, shared accounts, and service accounts need special handling because normal manager review can miss them. If the source system cannot prove remediation, the review should stay open.
- A manager approval without context is not strong evidence.
- Dormant accounts, shared accounts, and service accounts need special handling because normal manager review can miss them.
- If the source system cannot prove remediation, the review should stay open.
Read with
Read access review with identity, risk, and remediation signals. Provisioning SLA | Time to grant approved access | Shows whether access changes are controlled Deprovisioning SLA | Time to remove terminated or transferred access | Reduces stale-access exposure Privileged access count | Users or accounts with elevated roles | Indicates blast radius Exception age | Days an exception remains open | Shows whether risk acceptance is controlled
| Metric | Role | Why read together |
|---|---|---|
| Provisioning SLA | Time to grant approved access | Shows whether access changes are controlled |
| Deprovisioning SLA | Time to remove terminated or transferred access | Reduces stale-access exposure |
| Privileged access count | Users or accounts with elevated roles | Indicates blast radius |
| Exception age | Days an exception remains open | Shows whether risk acceptance is controlled |
Example
A finance system review includes 480 access assignments. The team finds 38 assignments owned by transferred employees, 12 dormant accounts, and 9 users with approval rights they no longer need. The controller approves 421 assignments, removes 42, downgrades 11, and grants 6 temporary exceptions with expiration dates. The review is not closed until the identity system and the finance application both show the removals and downgrades.
Compare with
Access review | Periodic verification of current access | Best for finding and removing access drift Access request | Approval before access is granted | Best for initial authorization Access monitoring | Continuous observation of access use | Best for detecting suspicious activity Least privilege | Design principle that limits access | Best for setting the target state
| Metric | Difference | Why read together |
|---|---|---|
| Access review | Periodic verification of current access | Best for finding and removing access drift |
| Access request | Approval before access is granted | Best for initial authorization |
| Access monitoring | Continuous observation of access use | Best for detecting suspicious activity |
| Least privilege | Design principle that limits access | Best for setting the target state |
Common mistakes
- Access review is not just a compliance form. It should remove or reduce access when business need is missing.
- Reviewer approval is not enough when the reviewer cannot see role meaning, usage, or risk.
- Annual review alone is usually too slow for privileged access, high-change teams, and sensitive data.
Frequently asked questions
Is access review the same as access approval?
No. Access approval happens before access is granted. Access review checks whether existing access is still justified.
Who should review access?
The reviewer should understand the business need and the risk of the permission. For privileged access, include system owners or security owners, not only people managers.
What is the most common failure?
The most common failure is approving access without enough context or failing to complete the removals that the review identified.