Team Roles & Permissions Matrix (RBAC) Markdown Table Template
A roles and permissions matrix maps every built-in role in a product to the actions it can perform. Three groups depend on it. Customers’ IT admins read it before deciding which role to give a contractor. Security reviewers and auditors use it as evidence for access-control questions in SOC 2 and ISO 27001 assessments. Your own engineers need it as the specification that authorization checks are tested against.
Edit This Template
Edit cells, add rows, or sort — the Markdown updates livePaste cells from Excel or Google Sheets into the first header to replace the table · Tab / Enter / arrows move · Shift+F10 opens row & column actions
When to Use This Table
The design principle behind a good matrix is least privilege: each role gets the smallest set of permissions needed for its job, and dangerous actions — deleting data, managing credentials, moving money, transferring ownership — are concentrated in as few roles as possible. The template’s separate Billing Contact role is a good example. A finance person can manage invoices without being able to read or delete customer data, and an admin can run the workspace without being able to change what the company pays.
What separates a trustworthy matrix from a decorative one is that it matches the code. Every row should correspond to an actual permission check, conditional rights such as “own items only” should be spelled out, and the table should change in the same pull request as the authorization logic. An auditor who finds a role doing something the matrix says it cannot will treat the whole document as unreliable.
What Goes in Each Column
| Column | Alignment | What to put here |
|---|---|---|
| System Permission | left :--- | An action phrased as verb plus object (“Invite & revoke members”), matching a real permission or policy in code. Left-aligned. Group by area — content, members, integrations, billing — and order destructive actions after read-only ones. |
| Owner | center :---: | The single account that holds the workspace and can do everything, including transferring ownership and deleting the workspace. Centered ✓. Keep exactly one Owner per workspace so there is always an unambiguous final authority. |
| Admin | center :---: | Day-to-day administration: members, roles, integrations, security settings. Centered. Note explicitly what Admins cannot do — commonly billing and ownership transfer — since that boundary is exactly what security reviewers look for. |
| Editor | center :---: | Creates and changes content but cannot manage people or credentials. Centered. Conditional rights like Own only belong in the cell, with a footnote defining “own” (created by the user, or assigned to them). |
| Viewer | center :---: | Read-only access. Centered. Check whether viewing includes exporting or downloading; for many compliance purposes export is a separate, more sensitive permission and deserves its own row. |
| Billing Contact | center :---: | A finance-only role with access to plans, payment methods, and invoices, and no access to workspace content. Centered. Its row of — marks is the point: it shows reviewers that financial and data access are separated. |
How to Fill It In
- 1Export the actual permission set from code: the policy file, the
can()checks, or the role-to-scope mapping in your auth service. Every row in the table should map to one of these identifiers. - 2Build the grid with roles as columns, ordered from most to least privileged, then fill each cell from the code rather than from what the role “should” do.
- 3Mark conditional permissions with a short qualifier and a numbered footnote. Avoid task-list syntax such as
[x]; it does not render inside GFM tables (see checkboxes), so use✓and—instead. - 4Review the dangerous rows — delete, credentials, billing, ownership — with a security engineer and confirm each is limited to roles that need it.
- 5Add a test that fails when the matrix and the policy disagree, or at least link the table from the authorization module so reviewers update both together.
Ready-to-Paste Variations
Permission matrix with scopes and footnotes
Adds the code-level permission identifier so engineers and auditors can trace each row to an actual check.
| Permission | Scope | Admin | Editor | Viewer |
| :--- | :--- | :---: | :---: | :---: |
| Read tables | `tables:read` | ✓ | ✓ | ✓ |
| Export to CSV | `tables:export` | ✓ | ✓ | — |
| Delete tables | `tables:delete` | ✓ | Own only¹ | — |
| Rotate API keys | `keys:write` | ✓ | — | — |Role summary for onboarding docs
A role-per-row view for people choosing which role to assign, rather than auditing individual permissions.
| Role | Intended for | Can | Cannot |
| :--- | :--- | :--- | :--- |
| Admin | IT or team leads | Manage members, keys, settings | Change billing, transfer ownership |
| Editor | Day-to-day contributors | Create and edit content | Manage members or credentials |
| Viewer | Stakeholders, auditors | Read content | Edit, export, or delete |
| Billing Contact | Finance | Manage plan and invoices | See workspace content |Common Mistakes
Documenting intended permissions instead of implemented ones.
Generate or verify the matrix against the authorization code. Where they differ, fix the code or the table, and file a bug either way.
Giving Admin every Owner permission “for convenience”.
Keep ownership transfer, workspace deletion, and billing out of the Admin role. A compromised admin account should not be able to take the workspace or change payment details.
Hiding conditional access behind a plain checkmark.
Write the condition in the cell (
Own only,Assigned projects) and define it in a footnote. A bare✓on delete implies the user can delete anyone’s work.Treating export as part of “view”.
Add a separate row for export or download. Bulk export is how data leaves the system, and many customers want viewers who cannot take a copy.
Letting custom roles drift from the documented defaults.
If customers can create custom roles, say so and document only the built-in ones here, with a link to where custom role permissions can be inspected.
Related Markdown Table Templates
Browse all 50 templatesRACI Responsibility & Stakeholder Matrix
RACI governance chart defining who is Responsible, Accountable, Consulted, and Informed across critical project workflows.
Risk Assessment & Mitigation Matrix
Identify potential technical and business risks, calculate probability and impact scores, and document mitigation strategies.
Security Advisory & CVE Vulnerability Matrix
Track security advisories, CVE identifiers, CVSS v3 ratings, affected library versions, patched releases, and remediation guidance.
Team Roles & Permissions Matrix (RBAC): Frequently Asked Questions
What is the principle of least privilege?
Each user or service gets only the permissions needed for its task, and nothing more. In a matrix, it shows up as roles with clearly bounded rows of ✓ marks and sensitive actions limited to one or two roles.
Should Admins be able to manage billing?
Often not. Separating billing into its own role lets finance staff manage invoices without data access, and stops an admin account from changing payment details or plan tier. Owners can still grant both roles to one person if they want.
How is RBAC different from ABAC?
RBAC grants permissions through roles assigned to users. ABAC evaluates attributes of the user, resource, and context, such as department, ownership, or time of day. Conditions like “own items only” are an attribute rule layered on top of a role table.
Do auditors accept a Markdown matrix as evidence?
It helps as documentation of the designed access model, but auditors usually also want evidence that the system enforces it, such as configuration exports, access reviews, or test results. Keep the matrix dated and versioned in Git so its history is reviewable.