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

Most organisations need both: roles for repeatable access patterns and granular exceptions for edge cases. The key is to keep exceptions visible and temporary, otherwise granular workarounds become shadow roles that weaken governance and make reviews less reliable.

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.

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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Role modelling and exceptions are directly about limiting access to what is needed.
	AC-2 — Account Management	Role assignment, exception tracking, and cleanup depend on account lifecycle governance.
	AC-3 — Access Enforcement	The question is about how access decisions are enforced through roles or granular policies.
Recommendation — Apply AC-6 to minimise standing access and keep exceptions narrowly scoped. Use AC-2 to govern role assignment, exception expiry, and account review. Use AC-3 to enforce access consistently through roles or explicit policy rules.
ISO/IEC 27001:2022	A.5.15 — Access control	Role-based and granular access models are both access-control design choices.
	A.5.18 — Access rights	Temporary exceptions and recurring access patterns both affect access-right management.
Recommendation — Define access control rules so roles and exceptions remain governed and reviewable. Review access rights regularly and remove exceptions that no longer have a clear need.

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.