A role-based access control (RBAC) model only works if someone can open a single document and see which roles exist, what each one grants, who owns it and when it was last checked, and most organisations do not have that document. This template gives you that artefact: a role catalogue, a role to entitlement matrix, a user to role assignment view and the naming, ownership, separation of duties and review fields that stop the model sliding into role explosion. It is written for identity governance (IGA) teams, application owners and auditors who are building or cleaning up a role model in a spreadsheet or an IGA tool. How to discover and design the roles in the first place, including role mining, is covered in the Role Mining and Role Design Guide; this page is the matrix you record the result in.
How to use this template
- Replace text in square brackets, such as [Organisation], [IGA team] and [Application], with your own values. Fields marked Required are the minimum for a working, auditable model; Recommended fields make maintenance easier.
- Build it as three linked tables: the role catalogue (Section 5), the role to entitlement matrix (Section 6) and the user to role assignments (Section 7). In a spreadsheet use one tab each, joined by Role ID; in an IGA tool, map each field to a role attribute.
- Record entitlements exactly as the target system names them (group, permission set, application role), so the matrix can be checked against the system automatically.
- Start with one application or business unit, prove the model with its owners, then extend. A complete matrix for one area is worth more than a rough matrix for everything.
- Pair the matrix with the Segregation of Duties Matrix Template for conflict rules and the Access Control Policy Template for the policy that makes role-based assignment mandatory.
1. Purpose
1.1 This matrix defines the roles [Organisation] uses to grant access, the entitlements each role contains, who owns each role and who holds it, so that access is granted consistently, on the principle of least privilege, and can be reviewed.
1.2 It is the reference used for provisioning through [IGA tool], for joiner, mover and leaver changes, for access reviews and for audit evidence against CIS Controls v8.1 Safeguard 6.8 (Define and Maintain Role-Based Access Control), NIST SP 800-53 Rev. 5 AC-2 Account Management, AC-5 Separation of Duties and AC-6 Least Privilege, and ISO/IEC 27001:2022 Annex A 5.15 Access control and 5.18 Access rights.
2. Scope and role layers
2.1 The matrix covers roles for [systems and business units in scope]. It uses a layered model so that business roles are built from reusable technical roles rather than from raw permissions.
| Layer | What it represents | Example | Assigned how |
|---|---|---|---|
| Birthright role | Access everyone in a population gets on day one | All-staff: email, intranet, HR self-service | Automatically from HR attributes |
| Business role | A job function, built from technical roles | Accounts Payable Clerk | Automatically from job code or by request with manager approval |
| Technical (application) role | A coherent set of entitlements in one system | ERP AP Invoice Entry | Only as part of a business role, or by request |
| Privileged role | Administrative or high-risk access | ERP System Administrator | By request, time-bound, recorded in the Privileged Account Inventory Template |
2.2 Out of scope: roles for service accounts, workload identities and AI agents. These are defined per workload and environment and must not reuse human business roles; see the Service Account Inventory Template.
2.3 The model follows the RBAC reference model standardised in ANSI/INCITS 359 (first adopted in 2004, revised in 2012): users are assigned to roles, roles are assigned permissions, roles may inherit from other roles, and separation of duty constraints restrict which roles can be combined.
3. Roles and responsibilities
| Role | Responsibility |
|---|---|
| [IGA team] | Owns the template, naming standard and tooling; maintains the matrix; runs role analytics and reports metrics |
| Role owner | Named business manager accountable for a business role's contents, membership rules and review; one owner per role, never a team |
| Application owner | Defines technical roles for their system, explains each entitlement in business language and approves changes |
| Line manager | Requests and confirms role assignments for their staff; attests during user access reviews |
| Risk or compliance | Owns separation of duties rules and approves exceptions |
| Internal audit | Tests that assignments match the matrix and that reviews happen |
4. Naming standard
4.1 Every role name follows the pattern [Layer]-[Domain or system]-[Function]-[Qualifier], using only letters, numbers and hyphens.
| Element | Allowed values | Example |
|---|---|---|
| Layer | BR (birthright), BUS (business), APP (technical), PRV (privileged) | BUS |
| Domain or system | Business area or application short code from the [application register] | FIN, ERP, CRM |
| Function | Plain description of the job or task | APClerk, InvoiceEntry |
| Qualifier | Only where the role genuinely differs: environment (PRD, TST), read-only (RO) | PRD, RO |
4.2 Examples: BUS-FIN-APClerk, APP-ERP-InvoiceEntry-PRD, PRV-ERP-SysAdmin-PRD. Do not put a location, cost centre or person's name in a role name: use attributes or parameters instead (Section 9).
5. Role catalogue fields
| Field | Status | Format or allowed values | Why it matters |
|---|---|---|---|
| Role ID | Required | Unique, never reused, for example [ORG]-R-0042 | Joins the catalogue, matrix and assignments |
| Role name | Required | Per Section 4 | Recognisable and sortable |
| Layer | Required | Birthright, business, technical, privileged | Controls how it may be assigned |
| Business description | Required | One or two sentences a manager can understand: what the holder can do | Reviewers cannot attest to what they cannot read |
| Role owner | Required | Named person from the identity provider | Accountability |
| Deputy owner | Recommended | Named person | Continuity when the owner leaves |
| Systems covered | Required | List of applications | Shows reach and blast radius |
| Risk rating | Required | Low, medium, high, privileged | Drives approval and review frequency |
| Assignment rule | Required | Automatic (attribute rule, for example job code = [X]), request with approval, or both | Makes membership predictable |
| Approval path | Required for requestable roles | Manager, role owner, application owner | Who must approve a request |
| Time limit | Required for privileged roles | Maximum duration, for example [8 hours] or [30 days] | Prevents standing privilege |
| Parent or child roles | Recommended | Role IDs inherited or contained | Records the hierarchy |
| SoD conflicts | Required | Role IDs it must not be combined with, with rule reference | Enforced at request and in review |
| Status | Required | Draft, active, deprecated, retired | Stops new assignments to old roles |
| Version and change reference | Required | Version number, change ticket | Audit trail for content changes |
| Last definition review | Required | Date, reviewer, outcome | Evidence the contents are still right |
| Member count | Recommended | Number, refreshed from the IGA tool | Finds empty or one-person roles |
6. Role to entitlement matrix
6.1 Roles form the rows and entitlements the columns, grouped by system. Mark each cell with the access the role grants, using a fixed legend so the matrix can be compared with the system.
| Role | ERP: AP-Invoice-Create | ERP: AP-Invoice-Approve | ERP: Vendor-Master-Edit | ERP: Payment-Run | CRM: Account-Read | File share: Finance-RW |
|---|---|---|---|---|---|---|
| BUS-FIN-APClerk | G | G | G | |||
| BUS-FIN-APSupervisor | G | G | G | |||
| BUS-FIN-VendorAdmin | G | G | ||||
| BUS-FIN-Treasury | G | R | ||||
| PRV-ERP-SysAdmin-PRD | T (time-bound, via [PAM tool], all ERP configuration) | |||||
6.2 Legend: G = granted; R = read-only; T = granted only through time-bound activation; blank = not granted. Every entitlement column also records, in a header row or linked sheet: the system's exact entitlement name, a business description, the application owner and whether it is sensitive. The Entitlement Catalogue and Application Onboarding Guide explains how to build that entitlement catalogue.
6.3 The example shows a deliberate design: creating invoices, approving them, editing vendor bank details and releasing payments sit in four different roles, so no single role can complete a fraudulent payment end to end.
7. User to role assignments
| Field | Status | Format or allowed values |
|---|---|---|
| User ID | Required | Identity provider identifier, linked to HR record |
| Role ID | Required | From Section 5 |
| Assignment source | Required | Automatic rule, approved request, migration, exception |
| Approved by and date | Required for requested roles | Name, date, ticket |
| End date | Required for privileged and temporary roles | Date |
| Last attested | Required | Date and reviewer from the last user access review |
| Direct entitlements outside roles | Recommended | Count, with justification for each |
7.1 Access granted directly, outside any role, is recorded as an exception with an owner and expiry. A rising count of direct grants is the first sign that the role model no longer fits the work.
8. Separation of duties constraints
8.1 Static constraints: pairs of roles that must never be held by the same person, such as BUS-FIN-VendorAdmin with BUS-FIN-Treasury. These are checked at request time and in every access review.
8.2 Dynamic constraints: roles a person may hold but must not use in the same transaction or session, for example raising and approving the same purchase order. These are enforced in the application.
8.3 Any exception is approved by [Risk or compliance], recorded with a compensating control (for example a monthly report of the person's transactions) and given an expiry date. Rule design is covered in the Segregation of Duties Guide.
9. Rules that prevent role explosion
9.1 A new role is created only when at least [five] people need the same set of entitlements for the same job function. Smaller or one-off needs are met by request-based technical roles with approval and expiry.
9.2 Roles are not duplicated for location, department or cost centre when the entitlements are the same. Use one role with an attribute rule or a parameter, for example one BUS-FIN-APClerk role scoped by a region attribute rather than one role per country.
9.3 A business role should contain technical roles, not individual entitlements, wherever possible. A business role with more than [25] direct entitlements is reviewed for splitting into technical roles.
9.4 Roles with no members for [90 days], or whose contents match another role, are deprecated and then retired.
9.5 Where access depends on context such as data classification, time or device, consider attribute-based rules alongside roles rather than encoding every combination as a role. See the Authorisation Models Guide.
10. Review and change control
| Review | Who | What is checked | Frequency |
|---|---|---|---|
| Role definition review | Role owner with application owners | Entitlements still needed, description accurate, SoD conflicts current | [Annually; six-monthly for high-risk and privileged roles] |
| User access review | Line managers | Each person still needs each role they hold | [Six-monthly; quarterly for privileged roles] |
| Usage review | [IGA team] | Entitlements in roles that no member has used in [90 days] | [Quarterly] |
| Model health | [IGA team] | Role count, empty roles, direct grants, exceptions | [Quarterly] |
10.1 Changes to a role's contents follow change control: request, application owner and role owner approval, SoD test, version increase and notification of affected managers. Role definition reviews are kept separate from user access reviews so that each question is asked once. See the Access Reviews Guide.
Implementation guidance
- Start where the data is clean: pick one well-understood application and its user population, clean up leavers and duplicate accounts first, then build the matrix. Mining dirty data reproduces over-privilege as roles.
- Aim for coverage, not perfection: it is normal for roles to cover the common core of each job and for a minority of access to stay request-based. Trying to cover every combination is the main cause of role explosion.
- Write descriptions in business language: "Can approve supplier invoices up to [limit]" is reviewable; "ZFI_AP_APPR_01" is not.
- Connect to joiner, mover and leaver: automatic assignment rules from HR attributes are where RBAC pays back, especially for movers, who otherwise accumulate access. See the Joiner-Mover-Leaver Guide.
- Metrics to report: number of roles against number of users; percentage of access granted through roles versus direct grants; roles without an owner; empty roles; SoD conflicts and open exceptions; role definition reviews completed on time.
- Common mistakes: one role per person; roles named after people or teams that later change; owners who are IT administrators rather than business managers; human business roles reused for service accounts; and privileged access hidden inside broad business roles.
- Framework alignment: CIS Controls v8.1 Safeguard 6.8; NIST SP 800-53 Rev. 5 AC-2, AC-5, AC-6 and AC-6(7) Review of User Privileges; ISO/IEC 27001:2022 Annex A 5.3 Segregation of duties, 5.15 and 5.18.
- Key sources: NIST CSRC: Role Based Access Control project; NIST SP 800-53 Rev. 5; CIS Controls: Access Control Management.
Related NHI Mgmt Group resources: Role Mining and Role Design Guide · Segregation of Duties Matrix Template · Identity Governance Maturity Model · Least Privilege Techniques Guide