Should organisations prioritise access reviews or role design first in IGA?

Should access reviews or role design come first?

When role structure is weak, role design should come first because access reviews mostly validate what already exists. If the role model is broadly sound and the main problem is entitlement drift, reviews can take priority sooner. The sequence should follow the dominant failure mode: architecture first when access is messy, enforcement first when access is mostly well-shaped but stale.

How to decide which problem is actually larger

The practical question is whether your organisation has a role architecture problem, an entitlement hygiene problem, or both. If users sit in oversized, overlapping, or poorly named roles, reviews will keep confirming bad structure. If roles are sensible but provisioning, movers, exceptions, or inherited access are creating drift, reviews become the faster control to restore confidence.

Role design is the right first move when teams cannot explain why a role exists, when one role serves too many job functions, or when business ownership is unclear. In that state, access reviews become noisy, repetitive, and easy to rubber-stamp because reviewers are judging exceptions against a confused baseline. A cleaner role model improves request approval, recertification, and least-privilege enforcement at the same time.

What each control is good at

Role design is a structural control. It reduces role explosion, makes access assignments more predictable, and gives reviewers a stable reference point for what a person or system should have. Good role design also makes downstream controls more efficient, because entitlement reviews can focus on true deviations instead of sorting out foundational ambiguity.

Access reviews are a detection and attestation control. They help find privilege creep, dormant access, excessive inheritance, and access that no longer matches business need. They are especially useful when the role catalogue is mostly fit for purpose but the environment has accumulated exceptions, mergers, manual grants, or lifecycle gaps that are no longer visible in day-to-day operations.

That is why the two controls are complementary rather than interchangeable. Role design defines the target state; reviews confirm whether live access still matches that target state. If the target state is wrong, review effort is mostly diagnostic noise. If the target state is right, review effort becomes a meaningful enforcement mechanism.

Good role design is also easier to sustain when paired with a disciplined Role Mining and Role Design Guide, because role governance needs a repeatable way to create, refine, and retire roles. In parallel, strong review programmes depend on Access Reviews and Certification Guide to keep attestations tied to meaningful access decisions rather than checkbox recertification.

How to sequence the work in practice

If the current state is undefined, start with role rationalisation: identify high-volume entitlements, merge duplicated roles, remove obsolete ones, and clarify role ownership. Once the structure is coherent enough to trust, reviews can then be used to confirm that access is staying within those boundaries. If the structure already exists, start with review hygiene and close the obvious drift before investing heavily in role redesign.

In many organisations, the best sequence is iterative rather than strictly linear. You do a first role pass to establish the core model, then run reviews to reveal where the model still fails in the real environment, then refine the roles again. That loop is often more effective than trying to perfect either control in isolation.

For broader IGA operating models, the relevant distinction is whether you are stabilising the entitlement model or governing it. IAM and IGA Basics is a useful anchor for that separation, because it makes clear why provisioning, roles, and reviews solve different parts of the same governance problem. If the issue is lifecycle-driven drift, Joiner-Mover-Leaver (JML) Guide shows why access drift often starts before the review cycle ever sees it.

Risk and Threat Considerations

Poor sequencing creates a false sense of control. If organisations rely on reviews before fixing a broken role model, reviewers often approve bad access because they have no trustworthy baseline to compare against. That leaves excessive privilege, inherited access, and orphaned entitlements in place while the control appears to be working.

Failure mechanism: A weak role model turns access reviews into confirmation of existing errors, while a weak review process allows entitlement drift to accumulate even when roles are well designed.

Impact: The organisation can end up with persistent overprivilege, higher audit friction, slower remediation, and a larger blast radius when an account or role is misused.

Practitioner Guidance

What to prioritise: Prioritise role design first when reviewers cannot tell whether access is structurally correct. Prioritise access reviews first when the role catalogue is serviceable and the immediate issue is proving whether live access still matches need.

What to verify: Before trusting either control, check whether roles have clear ownership, stable business meaning, and a manageable number of exceptions. If reviewers cannot explain what “good” looks like, the review cycle is probably doing cleanup that should have been done in design.

Practitioner takeaway: The right order is determined by the weakest layer, not by control fashion, so fix the architecture before you ask reviewers to certify it.

Related resources from NHI Mgmt Group

• Should organisations prioritise external exposure or internal credential governance first?
• What should organisations prioritise first: access reviews or privilege reduction?
• How do organisations decide whether to prioritise access reviews, lifecycle automation, or shadow IT detection first?
• Should organisations prioritise edge-device monitoring or third-party access reviews first?