Start with current duties, approval boundaries, and separation-of-duty requirements, then map permissions to those realities rather than to org charts. A role should represent a repeatable business function with a clear access boundary. If the role cannot be explained in operational terms, it is probably too broad or too stale to govern effectively.
How to design RBAC roles around business functions, not org charts
RBAC stays useful when each role reflects a repeatable business function with a narrow, explainable access boundary. The practical test is whether the role describes what someone does, which systems that work legitimately touches, and what separation is required. That approach keeps roles stable even when reporting lines, teams, or temporary assignments change.
Role design should start from actual duties, approval boundaries, and separation-of-duty constraints, because those are the things that determine whether access is justified. Role Mining and Role Design Guide is useful here because it frames role engineering as a business-meaningful model rather than a mirror of the org chart.
A role that cannot be described operationally is usually a warning sign. If the explanation depends on a team name, a temporary project, or a single person’s habits, the role is probably mixing responsibilities that should be split, or granting access that has outlived the process it was meant to support. In practice, that leads to role creep, unclear approvals, and permissions that are difficult to review.
What makes an RBAC role durable instead of stale
Durable roles are built around stable business activities, such as approving invoices, closing incidents, reconciling accounts, or maintaining a specific application service. They should have clear entry and exit conditions, with access that can be recertified without debating every entitlement from scratch. That makes the role easier to govern and easier to revoke when the function changes.
Good role design also separates business meaning from technical packaging. The business function defines why the role exists, while the permission set defines how that function is enabled in systems. The role should not be so broad that it becomes a catch-all entitlement bundle, and it should not be so granular that administrators need to assemble dozens of micro-roles for one common job.
IAM and IGA Basics is a strong companion resource for the governance side of that decision, especially where role definitions need to support access review, entitlement management, and separation of duties without creating a maintenance burden.
How to keep roles aligned as the business changes
RBAC drifts when teams rename jobs faster than they update access policy. To prevent that, review roles against current workflows, not inherited title hierarchies, and retire roles that no longer match a repeatable process. If the same access pattern appears in multiple departments, consider whether it is truly one business function or several similar functions that deserve different approval paths.
The maintenance question is not only whether a role is technically correct, but whether it still matches who can approve the work, who can perform it, and who must not perform both sides of the same control. When those boundaries change, the role must change with them, or the organisation ends up with access that is formally approved but practically outdated.
Authorisation Models Guide helps teams decide when RBAC is enough and when a more context-sensitive model is needed, especially if the access decision depends on attributes, relationships, or runtime conditions rather than a fixed job pattern.
Risk and Threat Considerations
Weak RBAC design creates two common failure modes: overbroad access that expands blast radius, and stale access that survives after the business need has changed. Both make recertification harder, increase the chance of SoD violations, and give attackers or insiders more opportunities to reuse legitimate access in ways the business did not intend.
Failure mechanism: Roles drift away from operational reality, so permissions accumulate around titles, exceptions, and convenience rather than governed business functions. That weakens approval quality and makes excessive access harder to spot.
Impact: Reviewers start rubber-stamping roles they do not understand, access becomes harder to explain during audits, and a compromise or misuse can reach more systems than the current business function should allow.
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 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 | RBAC roles must stay narrowly scoped to business need. |
| AC-5 — Separation of Duties | Role design must preserve approval boundaries and conflicting duties. | |
| IA-5 — Authenticator Management | Role governance depends on controlling the credentials used to exercise assigned access. | |
| Recommendation — Limit each role to the minimum permissions needed for the business function. Split conflicting permissions so one role cannot complete both sides of a sensitive process. Tie access review and revocation to the lifecycle of credentials that activate the role. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | RBAC is an access control model that needs clear business justification and review. |
| A.5.18 — Access rights | Roles require periodic review and removal when business need changes. | |
| Recommendation — Define and review role access based on business need and authorised use. Recertify and revoke role-based rights when duties or approvals change. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Role engineering is a core access management activity. |
| Recommendation — Maintain role assignments and permissions as a governed access-control process. | ||
Practitioner Guidance
What to verify: Check whether each role can be tied to one repeatable business function, one approval path, and one clear review owner. If a role needs multiple managers to justify it, that role is probably trying to cover too many duties.
Common mistake: Using org charts as the source of truth. Titles change, temporary assignments come and go, and reporting lines do not reliably express who should hold which permissions.
What good looks like: A reviewer can explain the role in one sentence, understand why the access exists, and identify the control that should remove it when the business need ends.
Practitioner takeaway: Design RBAC so the role survives organisational change, not so it preserves it. The best roles are anchored in stable work, narrow authority, and reviewable business justification.
Related resources from NHI Mgmt Group
- How should security teams make NHI best practices usable across the business?
- How should security teams assess whether an identity platform configuration is still aligned to business and compliance needs?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities at scale?