Common signs include frequent approvals of familiar roles, repeated exceptions that are never reduced, and review results that cannot explain why an identity has end-to-end control. If the evidence only proves a campaign happened, but not what capability was assessed, the programme is measuring activity rather than assurance.
What an access review programme should be proving
An access review programme is meant to prove that the right identities retain the right access for the right reasons. When it is certifying the wrong thing, the process still looks complete on paper, but it stops answering the real assurance question. That usually means the review is centred on ownership, role labels, or campaign completion instead of effective access and actual capability.
The most common failure mode is that the programme certifies an artefact, not a decision. If reviewers only confirm that a campaign ran, or that a familiar role name looked acceptable, the result tells you very little about whether the identity can still reach sensitive systems, combine privileges across applications, or act outside the intended control boundary. A useful review has to test the access outcome, not just the administrative wrapper.
That distinction matters because access reviews sit inside broader identity governance, not outside it. A review that cannot explain why an identity has end-to-end control is missing the connection between entitlements, role design, privileged paths, and lifecycle events such as movers, leavers, exceptions, and temporary elevation. In practice, IAM and IGA basics are the right reference point when you need to separate real access assurance from a cosmetic certification exercise.
How to tell the review is measuring activity instead of assurance
The clearest sign is repetitive approval behaviour. If reviewers keep approving the same familiar roles, the programme is probably optimised for speed and recognisability rather than scrutiny. Another warning sign is when exceptions never shrink. A healthy review cycle should reduce unexplained access over time, not preserve it through habit.
Look closely at whether reviewers can answer a concrete question: what can this identity actually do, across which systems, and with what privilege boundary? If the review output cannot explain that, it is usually certifying a label, a cost centre, or a reporting queue, not the access itself. That is especially visible when broad roles conceal excessive entitlements or when a single approval masks several downstream permissions.
This is where role and entitlement structure become material. A role model that is too coarse makes every review look benign, while a poor entitlement catalogue turns certification into guesswork. If the programme depends on role names being “known good” instead of validating the permissions underneath, it will miss privilege creep and overbroad access. Role Mining and Role Design Guide is relevant when the issue is whether the access structure itself is misleading the reviewers.
Which review results point to the wrong certification target
Three patterns usually show up together. First, the campaign produces a high pass rate with little explanation, which suggests rubber stamping. Second, exceptions are accepted repeatedly without a clear expiry or remediation owner, which means the review is normalising risk. Third, the evidence does not connect the identity to end-to-end capability, so the reviewer cannot tell whether the person or machine can actually perform the sensitive action being attested.
If those patterns appear, the programme may be certifying proximity to access rather than operational authority. That is a serious distinction in environments with privileged roles, service accounts, shared accounts, or combined approvals across multiple systems. In those cases, the right question is not whether the person was on the list, but whether the access path still creates the intended level of control, segregation, and accountability.
The same problem often appears when certification campaigns are disconnected from privileged access governance. Reviews that ignore high-impact accounts, standing privilege, or emergency access paths can look disciplined while leaving the most dangerous access untouched. Privileged Access Management Guide is the better companion when access review findings need to be translated into actual privilege reduction.
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 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Access reviews must produce usable evidence, not just completion records. |
| AC-2 — Account Management | The question is about whether accounts and entitlements are being reviewed meaningfully. | |
| AC-6 — Least Privilege | Wrong certification often preserves excessive access instead of reducing it. | |
| Recommendation — Use AU-6 to validate that review evidence explains real access decisions and exceptions. Use AC-2 to tie certification to account status, ownership, and removal of stale access. Use AC-6 to drive review outcomes toward least privilege and removal of unnecessary rights. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access reviews are an access control assurance activity under Annex A. |
| A.5.18 — Access rights | The issue is whether access rights are being confirmed, justified, and withdrawn correctly. | |
| A.8.2 — Privileged access rights | Mis-certification is especially dangerous when privileged access is involved. | |
| Recommendation — Use A.5.15 to keep certification focused on approved access and periodic reassessment. Use A.5.18 to review and revoke access rights that are no longer justified. Use A.8.2 to scrutinise privileged entitlements separately from ordinary access. | ||
| SOC 2 (AICPA) | CC6.2 — Restricts Logical Access | Access review programmes are meant to confirm that logical access remains appropriately restricted. |
| CC6.3 — Authenticates Users and Devices | A review that ignores who can actually act through an account fails to validate access assurance. | |
| CC6.6 — Monitors Logical Access | Review campaigns are part of ongoing monitoring of logical access. | |
| Recommendation — Use CC6.2 to ensure reviews support restricted access and removal of unnecessary permissions. Use CC6.3 to verify that access approvals align with authenticated identities and device trust. Use CC6.6 to evidence that review results are monitored and exceptions are remediated. | ||
| CIS Controls v8 | CIS-5 — Account Management | The programme is fundamentally about whether accounts and access remain appropriate. |
| Recommendation — Use CIS-5 to inventory, review, and remove accounts or rights that no longer need access. | ||
Practitioner Guidance
What to verify: Each reviewed item should map to a specific capability, not just a role name or campaign row. Require evidence that shows the effective permission set, the resource boundary, and any inherited or cross-system access that makes the entitlement materially risky.
Common mistake: Teams often treat approval rate as the success metric. That rewards reviewer throughput, not assurance quality. A review with fewer approvals but clearer explanations, fewer standing exceptions, and more removals is usually the healthier programme.
What practitioners underestimate: The hardest part is not getting reviewers to click approve or revoke, but forcing the programme to explain why the access exists at all. If the review cannot justify end-to-end control in plain terms, it is not certifying the right thing.
Practitioner takeaway: A good access review programme reduces uncertainty about actual capability; if it only proves that a campaign ran and a role looked familiar, it is producing process evidence, not access assurance.