A completed review can still leave exposure because the governance decision and the actual access change are separate events. Revocations may depend on automated deprovisioning, an ITSM ticket, or manual action by an application owner. If any handoff fails, or if closure is accepted without reconciliation, the unnecessary access can remain active.
Why the review is not the control
A completed access review is only evidence that someone decided access should be removed. It is not proof that the access actually disappeared. The exposure remains whenever revocation depends on downstream systems that can fail, such as IAM workflows, ITSM tickets, application-owner action, or delayed synchronization between directories and the target application.
This gap matters because reviewers often validate the decision outcome, while attackers and auditors care about the real state of the entitlement. If closure is accepted without a separate check that the account, role, token, group membership, or application permission was actually removed, the organisation can falsely believe the risk was eliminated. In practice, many teams discover the gap only after an access re-certification is “finished,” not when the account was still live.
How the gap appears in practice
Most review programs separate approval from execution. That is normal, but it creates a control dependency: the review closes only when the revocation is completed and verified. Where that dependency is weak, the review process becomes a paper exercise that records intent rather than state.
Common failure points include:
- an approved revocation creates a ticket but no one completes the change;
- the application does not support automated deprovisioning and relies on manual follow-up;
- directory changes propagate, but the target system retains local access;
- shared accounts, group membership, or nested roles hide the effective privilege;
- the reviewer signs off on the business decision without reconciling the post-change entitlement.
The operational standard should be evidence of removal, not just evidence of approval. That means the control must confirm the access state in the authoritative system, and for sensitive entitlements it should also confirm that no alternate path still grants the same capability. A review that only records a revocation request is incomplete when the entitlement remains active in the application, vault, or privileged access path. This guidance breaks down most often in older applications with manual administration and in environments where identity changes are not reconciled back to the source record.
When revocation still leaves exposure behind
Tighter governance often increases operational overhead, requiring organisations to balance faster review closure against stronger verification. The trade-off is most visible in high-friction environments, such as legacy systems, shared admin tools, and manually managed service access, where revocation can be delayed even after the review is signed off.
There is no universal standard for every environment, but the practical rule is simple: a review is not complete until the revoked access is no longer usable. That matters most when one decision fans out across multiple systems, because a single missed dependency can preserve effective access even after the primary entitlement is removed. This is why reconciliation, exception handling, and closure criteria must be part of the review design, not an afterthought.
For identity-heavy programs, the same problem can appear when humans and non-human identities share the same access paths, because the revocation workflow may remove one record while leaving another standing. NHIMG’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a useful reminder that approval and deactivation are often different operational steps. On the external control side, CIS Controls v8 and NIST SP 800-53 Rev 5 Security and Privacy Controls both support the need for access governance, auditability, and timely revocation, which is exactly where review programs often fail to prove closure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Access reviews must end with verified revocation and entitlement cleanup. |
| 8 — Audit Log Management | Post-review verification depends on logs and evidence that access actually changed. | |
| Recommendation — Reconcile revoked access and validate removal before closing the review. Collect evidence that the entitlement was removed and remained unused. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication and Access Control | The question concerns whether access governance decisions became effective state changes. |
| DE.CM — Continuous Monitoring | Ongoing monitoring helps detect lingering access after a completed review. | |
| Recommendation — Require post-change confirmation that access was removed across all relevant systems. Monitor for orphaned entitlements and unresolved revocation requests. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Review closure depends on trustworthy identity state and lifecycle evidence. |
| AAL — Authentication Assurance Level | Lingering active authentication means the access review did not fully retire access. | |
| Recommendation — Use trusted identity records to confirm the right account was actually deprovisioned. Verify authentication paths are disabled after access revocation. | ||
Practitioner Guidance
What to verify: Treat closure as invalid until the revoked entitlement is confirmed absent in the authoritative system of record and, where relevant, in the target application itself. If the review evidence does not show post-change state, assume the risk is still live.
Decision rule: If a review depends on manual action, ticket handling, or cross-system propagation, require a reconciliation check before closure. If the control cannot produce that check, classify the review as incomplete rather than completed.
What practitioners underestimate: The weakest point is often not the review committee but the handoff after the decision. The control fails when teams confuse agreement with execution, or when exceptions are allowed to linger because no one owns final verification.
Practitioner takeaway: The real control objective is not to decide that access should be removed, it is to prove that the access is no longer usable after the decision is made.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
