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.
Full template with worked example: Role-Permission Matrix Template — HIVE80lab Ops Notes. The quarterly walk-through that keeps it honest is the free User Access Review Checklist.
1. The matrix, one page
Six columns. A row per role, not per person:
| Column | What goes in it | Why it exists |
|---|---|---|
| Role | A job shape, not a person: Owner/Admin, Finance, Ops/IT, Staff, Contractor, Service account | You grant once per role; when someone changes jobs you change their role, not twelve systems |
| Systems in scope | Every system the role touches | The blank rows are the finding — undefined access is how drift starts |
| Permissions that matter | The handful that carry risk: pay, delete, read-private, publish | Four verbs cover what actually hurts; enumerating every toggle is enterprise theater |
| Admin rights | Explicit yes/no per system, plus the names who hold them right now | "Some people have admin" is not an auditable state. Names are. |
| Who approves changes | One named approver per role, never the person asking | Self-approval is how the matrix erodes |
| Last reviewed + evidence | Date + link to the exported member list or ticket | An undated matrix is a wish; evidence is what an auditor can believe |
2. The five roles most small teams actually need
Teams of 5–50 run fine on five roles. Anything more granular is enterprise dress-up; anything fewer means someone holds admin they shouldn't:
- Owner/Admin (1–2 named people): admin everywhere plus the break-glass account — but browses daily as Staff.
- Finance: billing consoles yes, production no.
- Ops/IT: production yes, billing read-only — and never approves their own access.
- Staff: no admin, does their job in their tools.
- Contractor: one project's workspace, time-boxed, everything they touch has a named internal owner.
Plus the 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, and its scope is the smallest that works. Ownerless admin service accounts are how a departed vendor keeps access for two years.
3. One rule, written down
No more than three named admin accounts per system, plus one break-glass account whose password lives in the password manager's emergency share. Using break-glass is an incident in miniature: logged, time-boxed, reported. This is not a security nicety — it is the difference between an incident affecting one account and one affecting a customer list.
4. The grant loop: ninety seconds
The matrix only holds if granting has a path shorter than the favor:
- Request — one message where history survives: who, which role row, which system, why, until when.
- Check the row — the approver opens the matrix, not the admin console. Either the permission is in the role (grant, done), or it isn't — then the honest question is whether the matrix is wrong (fix it, everyone benefits) or the request is scope creep (refuse it, with the reason written down).
- Grant + log — one line in the change log: who, what, until when. Time-boxing makes contractors safe: the end date is the default, the extension is the exception.
"Can you just make me admin, production is down" is the emergency case: grant under emergency rules, write the retroactive justification the same day. The loop bends during incidents; it never disappears.
5. The quarterly thirty minutes
Four times a year, one owner opens the matrix and the real member/admin list side by side. Every discrepancy is either a fix (revoke) or a matrix update (the role was wrong). Twenty minutes per quarter keeps admin creep at zero and produces the dated evidence that turns the next security questionnaire from a week of archaeology into an attachment.
Worked example: 31 admins to 3
A fifteen-person e-commerce company ran their first matrix after a customer sent a security questionnaire. Findings from the first pass: 31 admin accounts across six systems for a 15-person company — nine belonging to people who had left; an 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); a finance contractor whose billing admin was supposed to expire in January. Sixty days later: three named admins per system plus break-glass, service accounts scoped down with owners assigned and secrets rotated, and the customer's questionnaire answered in one page. Nothing about their work got slower — access just stopped coming from a memory of who was around when it was granted.
Four metrics to keep it true: admins per system (≤3 named + break-glass), role coverage (every person maps to exactly one row), review freshness (every row reviewed within 92 days), and offboarding completeness (a revocation that missed a system means the matrix was stale).
The full one-page template lives at HIVE80lab Ops Notes — free, no signup, printable. Related notes: Employee Onboarding Checklist, Employee Offboarding Checklist, Key Inventory Register.
Top comments (0)