Organisations should prioritise preventive checks when repeated findings show that review cadence is not reducing exposure. If the same conflicts return every quarter, adding another certification cycle only repeats the same workflow. Preventive controls matter most when access affects sensitive business processes and risky grants can be blocked before they become standing entitlement.
When preventive checks beat another certification cycle
Prioritise preventive access checks when review results keep repeating the same issues, because that tells you the control is detecting exposure too late. The practical test is simple: if a risky grant would be just as visible in the next quarter as it was in the last one, another review cycle adds effort but not materially better control.
Preventive checks are most valuable when the access decision itself can stop risky entitlement before it exists, especially where access reaches sensitive systems or business processes. In those cases, the question is not whether reviewers can spot the problem later, but whether policy, workflow, or approval logic can block it at the point of request.
Where review volume is high, preventive checks also reduce reviewer fatigue. The best performing programmes use review cycles to validate edge cases and exceptions, while using upstream controls to keep the baseline clean enough that recertification is focused on genuine judgement rather than routine cleanup.
What changes when the problem is recurring rather than exceptional
Repeated findings usually mean the organisation has a control design problem, not a cadence problem. If the same entitlements, conflicts, or SoD exceptions keep reappearing, the gap is often in provisioning logic, request routing, approval criteria, or role design. In that situation, review only documents the symptom.
Preventive checks are the better investment when the organisation can define a clear deny condition before access is granted. That may mean blocking certain combinations of access, requiring additional approval for sensitive applications, or using policy checks to stop access that would otherwise become standing entitlement. For access governance maturity, this is the point at which review moves from primary defence to secondary assurance.
Review cycles still have a role when the access pattern is genuinely dynamic, the business context changes often, or the decision depends on human judgement that cannot be fully encoded. But if the decision can be made consistently in advance, a preventive control is usually more reliable than asking a later reviewer to notice the same issue again.
How to decide whether to shift left
The best trigger is evidence that the same exposure survives multiple review cycles, or that reviewers are approving access because they lack enough context to challenge it. At that point, a preventive check should be built around the decision that is failing, not around the review report that records the failure.
That usually means using contextual controls at request time, such as entitlement rules, segmentation, approval thresholds, or risk-based gating for sensitive access paths. It can also mean tightening role definitions so that the access request itself is less likely to produce excessive privilege. NHIMG’s Access Reviews and Certification Guide is useful when you need to separate review work that should remain detective from the upstream checks that should become preventive.
Where the access touches privileged functions, the threshold for prevention should be even lower. Privileged Access Management Guide is the right reference point when standing access, break-glass paths, or admin roles can create immediate blast radius and should be constrained before they are ever granted.
Risk and Threat Considerations
When organisations rely on review cycles alone, risky access can remain usable for an entire period even after the issue is already known. That creates exposure to misuse, accidental overreach, and avoidable standing privilege, especially when access reaches critical business flows or production systems.
Failure mechanism: The control fails when review operates after the grant and no preventive gate exists to stop the same entitlement from being reintroduced, so the organisation keeps catching the same risk instead of removing the cause.
Impact: Repeated cycles consume reviewer time, reduce confidence in certification outcomes, and leave sensitive access in place long enough for misuse, escalation, or process abuse to occur before the next review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix, 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 |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Covers access governance and preventive controls for entitlement decisions. |
| Recommendation — Enforce IAM controls to block risky access before it becomes standing entitlement. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Addresses account and entitlement lifecycle controls that reduce repeated review findings. |
| AC-6 — Least Privilege | Supports limiting access at grant time instead of relying on later recertification. | |
| Recommendation — Automate account controls to prevent recurring excessive access. Apply least privilege to prevent unnecessary access from being granted. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Directly covers controlling access decisions before they create exposure. |
| Recommendation — Tighten access control so risky grants are blocked earlier. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Focuses on managing permissions and reducing recurring access risk. |
| Recommendation — Use access control management to remove repeated entitlement issues. | ||
Practitioner Guidance
What to prioritise: Start with the entitlements that repeatedly show up in certifications, especially those tied to finance, production, admin, or sensitive customer data. Those are the best candidates for request-time blocking because they combine repetition with high consequence.
What to verify: Check whether the review workflow is uncovering the same root cause every cycle, such as role explosion, weak approval logic, or missing separation-of-duties checks. If the root cause is stable, prevention should move ahead of another review pass.
Decision rule: If the control can reliably stop the risky grant before it becomes standing access, implement the preventive check first and keep review for exception handling. If the judgement depends on changing context or managerial knowledge, keep the review cycle as the primary control.
Practitioner takeaway: Use review cycles to confirm control health, but use preventive checks to remove the exposure that keeps coming back. When the same risk survives quarter after quarter, the programme needs a better gate, not a more frequent report.
Related resources from NHI Mgmt Group
- Should organisations prioritise patching exposed SAP kernel defects over routine access review cycles?
- When should organisations prioritise IGA modernization over more review cycles?
- When should organisations prioritise continuous compliance over manual review cycles?
- When should organisations prioritise role-based access control over ad hoc permission checks in Express apps?