Should IAM teams focus on access review or access optimisation?

They need both, but the order matters. Review verifies whether access was ever acceptable, while optimisation continuously reduces access that no longer fits the role or task. In mature programmes, review becomes a targeted response to outlier access rather than the primary governance mechanism.

Why access review and access optimisation are different controls

access review is a point-in-time control: it asks whether a user, service, or role still has access that can be justified. Access optimisation is the continuous design and cleanup layer: it removes excess entitlements, narrows role scope, and reduces the amount of access that later has to be reviewed. If you collapse them into one activity, review turns into a backlog exercise instead of a governance check.

That distinction matters because access review is strongest when it validates exceptions, high-risk access, and role design assumptions, while optimisation is strongest when it prevents entitlement drift in the first place. In practice, review tells you what is still defensible; optimisation changes the default so fewer permissions become defensible by accident. For teams managing IAM and IGA basics, the two controls sit at different points in the lifecycle.

For organisations trying to reduce governance noise, that separation is often the difference between a review programme that is merely compliant and one that is operationally useful. A broad review cycle can confirm the current state, but it rarely fixes the underlying role model, entitlement sprawl, or stale access patterns that created the review burden.

How mature programmes sequence review and optimisation

Mature IAM teams usually use review as a corrective signal, then use optimisation to fix the pattern that review exposed. When a recurring access issue appears, such as inherited privileges, dormant accounts, or overbroad roles, the long-term answer is usually role refinement, joiner-mover-leaver cleanup, or policy tuning rather than another larger review campaign. The strongest programmes treat review findings as input to design change.

That approach is consistent with Access Reviews and Certification Guide, which focuses reviews on removing access and closing the loop, and with Role Mining and Role Design Guide, which frames role cleanup as the way to prevent role explosion and reduce future exceptions. In other words, review is the detection and decision layer, while optimisation is the structural remediation layer.

The practical sequencing is simple: start with review where you need assurance, then use optimisation where the same pattern keeps reappearing. If a team keeps certifying away the same excess access every quarter, the programme is telling you that the access model, not the reviewers, is the problem.

What should IAM teams actually prioritise?

IAM teams should prioritise optimisation for steady-state access and reserve review for outliers, exceptions, and higher-risk entitlements. That usually means tightening birthright access, shrinking role sets, removing unused entitlements, and aligning access to job function or task scope first. Review then becomes a targeted control for access that is unusually broad, sensitive, temporary, or hard to model cleanly.

Good optimisation work often depends on better lifecycle discipline. A team that improves joiner-mover-leaver hygiene, cleans up dormant access, and reduces shared or inherited entitlements will usually see review volume fall naturally. Resources such as Joiner-Mover-Leaver (JML) Guide and NHI Lifecycle Management Guide reinforce the same operating principle: remove access when the relationship that justified it has ended or changed, then review what remains because it is genuinely difficult to eliminate.

For teams operating cloud or machine access at scale, optimisation also matters because static access tends to accumulate faster than review can safely absorb. That is why workload and service access programmes often favour tighter defaults, shorter-lived access, and narrower scopes before they rely on periodic certification.

Risk and Threat Considerations

When review is treated as the main governance mechanism, excess access can persist long enough to become exploitable. The failure mode is not just bad paperwork, it is permission drift, stale access, and overbroad roles that expand the blast radius of a compromise. Attackers benefit when access is left to survive until the next certification cycle.

Failure mechanism: Broad entitlements and weak lifecycle cleanup let low-value access accumulate, then a review programme validates what should have been removed earlier instead of shrinking the exposed surface.

Impact: The organisation keeps more active privilege than it needs, which increases lateral movement potential, makes insider misuse easier, and turns every downstream compromise into a larger incident.

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 governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Access optimisation is fundamentally about reducing unnecessary privilege.
	AC-2 — Account Management	Review and cleanup both depend on governing account creation, change, and removal.
	AC-3 — Access Enforcement	The topic centers on enforcing who should retain access after review or optimisation decisions.
Recommendation — Enforce least privilege and remove standing excess access wherever possible. Continuously review and adjust account entitlements across the lifecycle. Apply access enforcement rules that reflect the current role and task need.
CIS Controls v8	CIS-5 — Account Management	CIS account management directly supports review, recertification, and entitlement cleanup.
Recommendation — Inventory accounts and remove access that no longer matches business need.

Practitioner Guidance

What to prioritise: Use optimisation to reduce the number of items that require human judgement, then use review to focus attention on the access that is truly ambiguous, high-risk, or exceptional. If the same entitlement keeps reappearing in review, treat that as a role or lifecycle design defect, not a reviewer failure.

What to verify: Check whether your review population still contains obviously removable access, such as dormant accounts, duplicated roles, and recurring exceptions. If most findings are predictable cleanup items, the programme is overusing review where optimisation should have done the work earlier.

Practitioner takeaway: A strong IAM programme does not choose review or optimisation, it uses optimisation to make review smaller, sharper, and more defensible.