Role-Permission Matrix Template for Small Teams
One page. Every role, every system, the permissions each role actually needs — so access gets granted from a table instead of a favor, and "who has admin?" has an answer you can point at.
Admin creep is the quietest way a small team accumulates risk. Nobody decides to give everyone admin — it happens one urgent afternoon at a time: the accountant needs to fix a payment, the intern needs to see a dashboard, the founder's cousin is "just helping with the website." Each grant is reasonable. The sum is that in an incident you cannot tell which of thirty-one admin accounts matters, your access review has nothing to compare against, and offboarding is a guessing game. The fix is not a policy lecture — it is one table that says, per role and per system, what a person can do, who approves changes to that, and when it was last checked. This template is that page. The quarterly walk-through that uses it is the user access review checklist; the grants that happen on day one come from the employee onboarding checklist.
The matrix, one page
| Column | What goes in it | Why it exists |
|---|---|---|
| Role | A job shape, not a person: Owner/Admin, Finance, Ops/IT, Staff, Contractor, Service account. People hold roles; roles hold permissions. | You grant once per role. When someone changes jobs, you change their role — you don't re-litigate twelve systems. |
| Systems in scope | Every system the role touches: email, files, billing, production, analytics, the password manager. | The blank rows are the finding. A role with no systems listed is a person with undefined access — that is how drift starts. |
| Permissions that matter | Not every toggle — the handful that carry risk: who can pay, who can delete, who can read customer data, who can change what customers see. | Small teams drown trying to enumerate permissions. Four verbs — pay, delete, read-private, publish — cover what actually hurts. |
| Admin rights | Explicitly yes or no per system, plus who holds them right now (names, not headcount). | "Some people have admin" is not a state you can audit. Names are. If the list is longer than three per system, that is your finding. |
| Who approves changes | One named approver per role, and it must not be the person asking. | Self-approval is how the matrix erodes. The approver is the person who says "no, you don't need that" — the most valuable sentence in the table. |
| Last reviewed + evidence | Date of the last quarterly check and a link to the evidence (exported member list, ticket, screenshot of the settings page). | An undated matrix is a wish. The evidence column is what turns "we reviewed access" into something an auditor, an insurer, or an enterprise customer can believe. |
The five roles most small teams actually need
Most teams of 5–50 people run fine on five roles. Anything more granular is enterprise dress-up; anything fewer means someone is holding admin they shouldn't.
| Role | Admin rights | Can | Never |
|---|---|---|---|
| Owner/Admin (1–2 named people) | Yes, everywhere — plus the break-glass account | Everything; approves role changes | Use admin for daily work (owner browses as Staff) |
| Finance | Billing consoles yes; production no | Pay, refund, read financial data | Touch production, deploy code, delete records |
| Ops/IT | Production yes; billing read-only | Deploy, rotate, configure, restore | Approve their own access changes |
| Staff | No | Do their job in their tools | Install anything on the domain, see others' data |
| Contractor | No; time-boxed | The one project's workspace, with an end date written in the matrix | Own anything. Everything they touch has a named internal owner. |
Plus one row most matrices forget: the service account (CI, integrations, the backup job). It gets a named human owner, its secret lives in the key inventory register, and its scope is the smallest that works. Service accounts with admin rights and no owner are how a departed vendor keeps access for two years.
The admin problem, stated as a rule
Write one sentence into the policy and enforce it at review time: no more than three named admin accounts per system, plus one break-glass account whose password lives in the password manager's emergency share. The break-glass account is the answer to "what if both admins are on a plane?" — and its use is an incident in miniature: logged, time-boxed, and reported. Admin count above three is not a security nicety; it is the difference between an incident affecting one account and an incident affecting a customer list. The rotation and custody rules for the credentials behind these accounts live in the secrets rotation schedule.
The grant loop: ninety seconds per request
The matrix only holds if granting has a path shorter than the favor. Make it a three-step loop:
1. Request — one message, in a channel that keeps history: who, which role row, which system, why. "Finance needs billing admin for the quarterly rebate process, ending March 31."
2. Check the row — the approver opens the matrix, not the admin console. Two outcomes: the permission is already in the role (grant, done), or it is not (then the honest question is whether the matrix is wrong — fix the matrix, which benefits everyone — or the request is scope creep, which gets refused with a reason that is written down).
3. Grant + log — the grant gets one line in the change log (who, what, until when), and if it was time-boxed, an expiry reminder exists before the person asks. Time-boxing is what makes contractors and projects safe: the end date is the default, the extension is the exception.
Requests that arrive outside the loop ("can you just make me admin real quick, production is down") are the first-30-minutes case: grant under emergency rules, then write the retroactive justification into the log the same day. The loop bends during incidents; it never disappears.
The quarterly thirty-minute review
Four times a year, one owner opens the matrix and, for each system, the real member/admin list side by side. Every discrepancy is either a fix (revoke) or a matrix update (the role was wrong). The user access review checklist provides the walk-through order; the matrix provides the "supposed to" column that makes the comparison possible at all. Twenty minutes of this per quarter keeps admin creep at zero, and it produces the dated evidence that turns the next security questionnaire from a week of archaeology into an attachment.
Four metrics
- Admins per system — target ≤3 named accounts plus break-glass; rising means the grant loop is being bypassed.
- Role coverage — every person on payroll maps to exactly one matrix row; unmapped people are findings, not exceptions.
- Review freshness — every system row shows a review within the last 92 days; older rows are treated as unreviewed, i.e., untrusted.
- Offboarding completeness — when someone leaves, the matrix row is what gets revoked, in one pass, with the offboarding checklist; a revocation that missed a system means the matrix was out of date.
Worked example: thirty-one admins to three
A fifteen-person e-commerce company ran their first matrix as a one-afternoon project after a customer asked for a security questionnaire. The real member lists took forty minutes to export. Findings from the first pass: 31 admin accounts across six systems for a 15-person company (nine of them belonging to people who had left), the intern still holding production deploy rights from a website migration five months earlier, two service accounts with admin and no named owner (one was the backup job — nobody could say what else it could touch), and a finance contractor with billing admin that was supposed to expire in January. Sixty days later: three named admins per system plus break-glass, the intern's rights moved to the Staff row, both service accounts scoped down with owners assigned and secrets rotated, and the matrix itself lives next to the access-review evidence in the same folder. The customer's questionnaire became a one-page answer. Nothing about their work got slower — the only thing that changed was that access now comes from a table instead of a memory of who was around when it was granted.
Where this fits
The quarterly walk-through that keeps this matrix honest is the user access review checklist; the day-one grants it defines come from the employee onboarding checklist, and the revocation pass when someone leaves is the employee offboarding checklist. The RACI matrix template handles the other half of the same question — not what a role may touch, but who decides, one name per letter. The credentials behind the admin rows live in the key inventory register and rotate on the secrets rotation schedule; the security side of letting a vendor's people near your systems is the vendor security review. If you would rather have the whole loop — the audit that finds the access gaps, the plan that closes them — run by an outside pair, that is the Small-Team Ops Audit ($149, five-day turnaround), and the access review is one of its standard modules; when the scenario that worries you most is "someone gets in and we can't tell what they touched," the Custom Incident Runbook ($249, delivered in 48h) turns it into a procedure. The Ops Starter Kit ($14) covers the incident half; Vol. 2 ($27) covers the on-call rotation; and the free First 30 Minutes quick-start covers the first half-hour after any access incident.