Should organisations use role modelling or keep access decisions more granular?

Why the answer is usually “both,” not either-or

Role models are useful when access patterns repeat. They give reviewers, auditors, and engineers a stable way to see why someone or something has access, and they reduce the number of one-off grants that must be maintained manually. Granular access still matters where the business need is narrow, temporary, or unusual, but it should be treated as an exception path, not the default operating model.

The practical test is whether the access pattern can be expressed as a reusable entitlement without hiding the real business need. If yes, a role is usually the cleaner governance unit. If no, a fine-grained rule may be justified, but it should remain traceable back to a named use case, owner, and expiry.

When granularity helps, and when it starts to hurt

Granular access is valuable for edge cases such as limited operational tasks, special approvals, and tightly scoped application permissions. It lets teams avoid forcing every case into an overly broad role, which is how permission sets become bloated and hard to reason about. The trade-off is that highly bespoke access is harder to review, harder to recertify, and easier to forget once it has been granted.

That is why organisations should be careful not to let repeated exceptions accumulate into an informal role structure. Once the same exception appears again and again, it is no longer an exception in practice. At that point, the cleaner control is usually to promote it into a managed role or policy pattern instead of leaving it scattered across individual accounts.

For teams building the access model itself, the distinction between role mining and role design matters because the goal is not to create the maximum number of roles, but the smallest set that still reflects how work actually gets done.

How to prevent granular exceptions from becoming shadow roles

The main governance failure is not “too much granularity” in isolation. It is untracked granularity that behaves like a hidden role model. When many accounts receive the same exception, but the access is recorded as individual grants, reviewers lose the ability to see the pattern. That weakens attestation, makes ownership ambiguous, and often leaves no obvious trigger for cleanup.

role modelling and exception handling need a common control surface. One useful approach is to keep a catalogue of approved roles and a separate, time-bounded exception register. If an exception is granted more than once, or if it survives past its intended expiry, it should be reviewed for conversion into a governed entitlement pattern or removed.

For a practical map of how role models sit beside other access structures, IAM and IGA basics is a useful companion because it frames roles, entitlements, provisioning, and access review as parts of one governance system rather than separate controls.

Where organisations need a finer-grained decision model, authorisation models provide the next layer of thinking: roles handle repeatability, while attribute or relationship based controls handle cases where static roles would be too blunt.

Practitioner Guidance

Decision rule: Use roles for access that is stable, reusable, and easy to explain; use granular grants only when the business need is narrow enough that a role would become misleading or overbroad. If the same granular pattern appears repeatedly, treat it as a candidate for role design rather than a permanent exception.

What to verify: Every exception should have an owner, an expiry, and a documented reason that would still make sense to a reviewer months later. If you cannot explain the grant without referencing a ticket history or tribal knowledge, the access is already too opaque.

Common mistake: Teams often preserve “just one more exception” because it seems safer than changing the role model. In practice, that shortcut usually creates hidden privilege patterns that are harder to review than a modestly refined role catalogue.

Practitioner takeaway: The best access model is usually not the most granular one, it is the one that makes repeated access easy to govern and rare access easy to retire.

Related resources from NHI Mgmt Group

• How do organisations keep role models aligned with actual access use?
• What is the difference between role-based access and API key governance for NHI security?
• How can organisations keep automated access decisions current over time?
• How should organisations use device trust in privileged access decisions?