Because a correct decision does not guarantee the downstream entitlement changed. If access is inherited through role membership or another upstream rule, the certification record can show revocation while the system still grants access. The control only works when review decisions are reconciled with the source entitlement path.
Why a correct review decision still does not guarantee the access changed
Access reviews fail when the decision is recorded at the certification layer, but the entitlement is enforced somewhere else. If access comes from a role, group, inherited policy, or another upstream relationship, revoking the item on the review form may leave the underlying grant intact. That is why the control has to reconcile the review outcome with the source entitlement path, not just the approval record.
The practical failure is a mismatch between the “what was reviewed” object and the “what actually grants access” object. Reviewers can be accurate about the item in front of them and still miss that the system is deriving access from membership, nested roles, application logic, or a connected identity store.
That is why Access Reviews and Certification Guide emphasises closing the loop on remediation rather than treating certification as a paperwork exercise.
Where the entitlement path usually breaks the control
The most common failure condition is indirect entitlement. A reviewer revokes one line item, but the access survives because the user still belongs to a group, inherits a role, or retains a birthright permission from a source system. In those cases, the review has approved the right decision, but the operational change never lands on the true grant path.
Another common break point is poor entitlement modelling. If roles are too coarse, overlapping, or reused across functions, reviewers may only see a symptom of access rather than the root cause. The record can look clean while the authorization model keeps reasserting the same privilege.
This is also why IAM and IGA Basics matters here, because access reviews only work when reviewers can trace entitlements through roles, inheritance, and upstream provisioning logic.
When the entitlement source is a role model, Role Mining and Role Design Guide is the more relevant lens: the review problem is often a role design problem that certification alone cannot fix.
How to make access reviews actually enforce removal
The control needs three things at once: a clear entitlement source-of-truth, a remediation workflow that updates that source, and verification that the downstream system no longer grants access. If any one of those is missing, the review can still be “correct” while the account remains over-permissioned.
Practitioners should also separate direct grants from inherited grants in the review workflow. If a reviewer revokes direct access, the system should still surface whether a group, role, or policy is going to re-add it on the next sync or evaluation cycle. That is the difference between a record of intent and a durable entitlement change.
For recurring cleanup, Joiner-Mover-Leaver (JML) Guide is useful because stale access often persists when mover and leaver events are not reconciled back to the authoritative source.
Where privilege is involved, the right follow-up is to check whether the entitlement sits inside a broader privileged model that needs a separate control path. Privileged Access Management Guide is relevant when the access review touches accounts that should have been time-bound, vaulted, or removed from standing privilege altogether.
Risk and Threat Considerations
Failed reconciliation creates a quiet control failure: auditors see a revocation, but the system still authorizes the user or workload. That gap can leave excessive access in place for long periods, especially when roles are reused, inheritance is nested, or the entitlement source is not checked after the review closes.
Failure mechanism: The review action updates the certification record, but the actual authorization path is preserved by upstream role membership, inherited policy, or another indirect grant, so access is re-established or never removed.
Impact: Overprivilege persists despite “successful” review outcomes, which increases the likelihood of misuse, lateral movement, audit exceptions, and false confidence in governance reporting.
That risk is especially pronounced when access is broad or shared, because one missed inherited grant can affect many systems at once. The control failure scales with role reuse and weak entitlement decomposition.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Access reviews must tie to account and entitlement lifecycle actions. |
| AC-6 — Least Privilege | The issue is persistent excess access after review closure. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Review outcomes need evidence that the downstream entitlement actually changed. | |
| Recommendation — Verify revocations are executed against the authoritative account source and rechecked after propagation. Reduce inherited and standing access so reviews can remove privileges cleanly. Correlate certification records with entitlement state changes and investigate mismatches. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and entitlement governance is central to preventing revocation gaps. |
| Recommendation — Continuously reconcile approved access decisions with active account and group memberships. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access Control | Access reviews are an access control activity that must reflect real authorization state. |
| Recommendation — Ensure access-review decisions change the underlying authorization source, not just the review record. | ||
Practitioner Guidance
What to verify: Every revocation should be tested against the authoritative entitlement path, not only the certification item. If the source grant is inherited, verify the upstream role, group, or policy change as evidence of completion.
Common mistake: Treating the review tool as the system of record for enforcement. It is only the decision layer; the enforcing system is the identity, access, or application source that actually calculates access.
What good looks like: A closed review case produces a measurable entitlement change, a post-change access check, and an audit trail that shows the privilege is no longer granted anywhere in the path.
Practitioner takeaway: An access review is only effective when the revocation is propagated to the real grant source and then independently verified; otherwise the organisation has recorded a decision, not removed access.