Role-Based Access Matrix: How to Build One That Holds Up

A role-based access matrix is a table that maps job roles to the permissions each role holds on each system, so access follows the job and not the person. Roles run down the side, resources or actions run across the top, and every cell says what that role may do. Build it once, review it on a schedule, and you can answer "who can change this?" in seconds.

This guide covers how to build the matrix, a worked example for network operations, the mistakes that make matrices useless, and how to keep one accurate when you run many sites or many client tenants.

TL;DR

A role-based access matrix maps roles to permissions. Users get roles, never individual permissions.
Start from job functions, list resources and actions, then fill each cell with the least access the role needs.
Add separation of duties and role hierarchies early. They are cheaper to design in than to retrofit.
Review the matrix on a fixed schedule and after every org change. A stale matrix is worse than none.
For MSPs and multi-site teams, the matrix has to work per client and per site, not just per tool.

What a role-based access matrix actually shows
Build the matrix in six steps
Separation of duties belongs in the matrix
A sample matrix for network operations
Common mistakes that break the matrix
Where RBAC stops and context begins
Our perspective: the matrix has to follow the client, not the tool
Keeping the matrix current
Put the matrix to work in Netverge
FAQ
Sources

What a role-based access matrix actually shows

The classic access control matrix lists subjects (users) against objects (files, systems, devices) and records the rights at each intersection. A role-based version swaps the subject axis for roles. Instead of 300 users by 80 systems, you have perhaps 12 roles by 80 systems, and each user is attached to one or more roles.

The underlying model is well documented. NIST describes a general-purpose RBAC model proposed in 1992 by Ferraiolo and Kuhn, later standardized as INCITS 359-2004. Its three core rules are:

Role assignment: a subject can only execute a transaction through a role it has been assigned.
Role authorization: the subject's active role must be authorized for that subject.
Transaction authorization: a transaction is allowed only if the subject's role memberships authorize it.

In practice the matrix is the document that makes those rules visible. It is also the artifact an auditor, a customer security questionnaire or a new engineer asks for first.

Roles versus groups

Teams often confuse the two. A group is a collection of people for administrative convenience, such as "All Employees" or "Helpdesk team". A role is a collection of permissions tied to a job function, such as "Network Engineer". People can share a group and still need different access. If your matrix has columns named after departments or distribution lists, you probably built a group matrix. Rebuild it around what people do.

RBAC, ABAC and PBAC

You will see three acronyms next to each other. According to NIST SP 800-162, RBAC relies on predefined roles as the main attribute for access. ABAC evaluates rules against attributes of the user, the object, the operation and the environment. PBAC enforces access through policies that define which subjects reach which objects under which conditions.

Comparison of RBAC, ABAC, and PBAC decision bases

For most IT and network teams, RBAC is the right starting layer because it is easy to explain and easy to audit. Attribute and context rules come later, as refinements on top of it.

Build the matrix in six steps

Step 1: Inventory resources and actions

List every system the matrix covers. For a network team that usually means monitoring dashboards, device configuration, ticketing, documentation, credential storage, reporting, billing and user administration. Then decide on a short, consistent action vocabulary. Four to six actions is enough for most systems:

View: read data and dashboards
Create/Edit: change records or settings
Execute: run an action, such as a remediation or a reboot
Approve: authorize a change another role requested
Delete/Export: remove data or take it out of the system
Administer: manage users, roles and integrations

Keep the vocabulary identical across systems. If one tool says "write" and another says "modify", translate them in the matrix so a reader never has to guess.

Step 2: Define roles from job functions

Interview team leads and look at what people actually do in a normal week. Name roles after functions, not people or seniority: Service Desk Analyst, Network Engineer, NOC Lead, Security Auditor, Client Read-Only, Billing Admin. A useful early target is a small set of roles. If you reach 40 roles for a 30-person team, you are encoding individuals again.

Step 3: Fill each cell with the least access needed

For every role and resource, ask what the role needs to do its job, and grant only that. Leave blank cells blank. The research here is consistent: a true access matrix is sparse, and the role layer is what keeps it that way. When individual permissions are assigned directly to users, permission bloat follows and audits become close to impossible.

Step 4: Add role hierarchies

NIST notes that role hierarchies reduce management overhead: a senior role inherits the permissions of a junior one. A NOC Lead can inherit everything a Service Desk Analyst has and add approvals. You maintain the base permissions once and describe only the differences above them.

NOC lead inherits analyst permissions and adds approvals

Step 5: Apply separation of duties

Some tasks should never sit with one person. Requesting and approving a firewall change is the standard example. See the next section for how to encode this.

Step 6: Assign users, document, and set a review date

Map each user to roles, record who approved it and when, and put the next review on the calendar before you close the document. Treat the matrix as a controlled document with an owner and a version number.

Separation of duties belongs in the matrix

NIST describes separation of duty as a way to require two or more distinct roles for a sensitive task, so no single user holds enough power to bypass a control. It comes in two forms. Static separation of duty is set when roles are assigned to users: one person cannot hold both roles. Dynamic separation of duty restricts which roles a user can activate in the same session. Both are covered in the NIST RBAC FAQ.

Put this in the matrix as a conflicts column or a second small table listing role pairs that must never be combined. Typical conflicts in network operations:

Role A	Role B	Why they conflict
Change Requester	Change Approver	One person could approve their own change
Network Engineer	Security Auditor	The auditor must be independent of what they review
Billing Admin	User Administrator	Billing changes and access changes should not share one owner

If you run a shared platform for several customers, the same thinking applies across tenants: a role in one tenant must not leak into another. Work on multi-tenant isolation controls shows how policy decision and enforcement points can be used to prove that boundary, and it is a useful frame for deciding which role combinations you forbid.

A sample matrix for network operations

This is a starting template, not a standard. Adjust the roles and columns to your environment. Legend: V = view, E = create/edit, X = execute actions, A = approve, D = delete/export, M = manage users and settings. A dash means no access.

Role	Monitoring dashboards	Device config	Ticketing	Documentation	Credential vault	Reporting	User admin
Service Desk Analyst	V	–	V, E	V	–	V	–
Network Engineer	V, E	V, E, X	V, E	V, E	V (scoped)	V	–
NOC Lead	V, E	V, A	V, E, A	V, E	–	V, D	–
Security Auditor	V	V	V	V	–	V, D	–
Client Read-Only	V (own sites)	–	V (own tickets)	V (own)	–	V (own)	–
Platform Admin	V, M	–	V, M	V, M	M	V, M	V, E, M

Three design choices in this table are worth copying:

Platform Admin cannot change device configuration. Administering users and changing devices are separate duties.
Credential access is scoped. Engineers see only the vault entries for the sites and clients they serve.
Client Read-Only is bound to its own sites. The scope is part of the role definition, not an afterthought.

Copy the table into a spreadsheet, add one row per role and one column per system you actually run, and you have a working RBAC matrix template. Add a second tab for the conflict pairs and a third for user-to-role assignments with approver and date.

Common mistakes that break the matrix

Roles built around people. "Dave's access" is not a role. When Dave leaves, the role is orphaned.
Admin by default. If most of the team needs admin to do their job, the roles are too coarse or the tool's permissions are. Split the role or request finer permissions from the vendor.
No distinction between assigned and active roles. In high-security settings, holding a role is not the same as using it. Activating a privileged role only for the session that needs it is a core least-privilege practice, as the NIST RBAC FAQ explains.
One-time creation. People change jobs, systems get added and integrations create service accounts. Without a review cycle the matrix drifts from reality in months.
Ignoring non-human identities. API keys, automation accounts and AI agents act in your systems. Give each its own role with its own row, owner and limits.
Matrix and reality disagree. The document says Engineers cannot export data, but the tool allows it. Test the matrix against the live configuration, not against the document.

Where RBAC stops and context begins

A role is necessary but not always sufficient. NIST SP 800-207 describes zero trust as assuming no implicit trust and requiring per-session, least-privilege authorization, with RBAC and ABAC among the mechanisms that can enforce it. CISA's hybrid identity guidance discusses context-based access control, which combines roles with device signals and environmental attributes when making access decisions.

In practice, keep the matrix as the baseline and add conditions where risk is highest: require a managed device and MFA for the credential vault, restrict configuration changes to business hours unless an incident is open, and require an approval for production changes. Each condition is a note attached to a cell, so the matrix stays readable.

Our perspective: the matrix has to follow the client, not the tool

Most RBAC advice assumes one organization with one directory. Our customers are MSPs and multi-site enterprises, and the problem looks different. One engineer may need full access to 15 client networks, read-only on five more, and nothing on the rest. A flat role list cannot express that, so teams end up with dozens of near-duplicate groups.

We think the answer is to separate two questions. First: what can this role do? Second: where does it apply? The role is defined once. The scope, which clients and which sites, is assigned on top. That keeps the matrix small and the audit trail clear, and it is why we built multi-tenant management and role-based access into Netverge from the start. If you manage Microsoft partner permissions as well, our write-up on RBAC for MSPs that scales past GDAP's group limit goes deeper on that specific constraint.

The second thing we have learned is that automation needs the same discipline as people. Autonomous agents that diagnose and fix issues should have defined roles, limited scope and a record of what they did. We describe that approach in making autonomous IT agents safe with context and governance. If an agent can restart a service, the matrix should say so, say where, and say who approved it.

Third, a matrix is only as good as the data around it. Access decisions depend on knowing what devices exist and who owns them. That is one reason we argue for a single point of truth across IT tools: when inventory, tickets and documentation live in separate tools, the matrix covers only the part of the estate you can see.

— Jim

Keeping the matrix current

A matrix is a living control. A workable cadence:

Quarterly access review. Each role owner confirms that every person in the role still needs it. Remove anyone who does not.
Event-driven updates. Hires, transfers, departures, new clients, new sites and new integrations each trigger a matrix check.
Privileged role review monthly. Admin and approver roles are small groups and the cost of a mistake is high.
Version history. Record what changed, who approved it and why. Auditors ask for exactly this.
Live comparison. Export actual permissions from each tool and compare them with the matrix. Differences are findings.

If you federate sign-in through an identity provider, map identity provider groups to matrix roles and keep that mapping in the document. Our guide to configuring and testing Okta SSO shows how to test both sides of the connection, which applies equally to role mappings. Identity-level controls also connect to physical and network enforcement; see our enterprise guide to network access control devices for how those layers fit together.

For how we handle platform security itself, see our Security and Trust page.

Put the matrix to work in Netverge

A spreadsheet documents access. A platform can enforce it. Netverge combines monitoring, ticketing, documentation and AI-driven automation with multi-tenant management and role-based access, so the roles in your matrix map to what people can see and do per client and per site.

The Starter Package is $299 per month. Hardware Vergepoints are $49 per month per device and Software Vergepoints are $29 per month per Vergepoint; additional sensors, clients, sites, AI agents and storage are listed on the pricing guide. You can size your own setup with the pricing calculator, or start your free trial and test your role design on real sites. Prefer a walkthrough? Request a demo and we will map your matrix to the platform with you.

FAQ

What is a roles and permissions matrix?

It is a table with roles on one axis and systems, resources or actions on the other. Each cell states what that role may do, such as view, edit, execute or approve. It lets you see and review access for a whole team at a glance, and it gives auditors a single reference.

What are the three primary rules of RBAC?

Per the NIST RBAC FAQ, they are role assignment, role authorization and transaction authorization. Together they mean a user can act only through a role assigned to them, that role must be authorized for them, and the action must be permitted for that role.

Is RBAC still used?

Yes. It remains a widely used baseline, including in zero trust designs, where NIST SP 800-207 treats it as one way to enforce least-privilege decisions. Most organizations now add attribute or context conditions on top of roles for sensitive resources.

How many roles should a matrix have?

There is no fixed number, but fewer is better. If roles start to multiply, check whether you are encoding individuals or mixing scope into the role. Define a role once and assign scope, such as client or site, separately. Review roles with only one or two members to see if they can merge.