User access review for small teams: the quarterly pass that proves nobody kept a key

Every audit conversation about access eventually lands on the same question, and it is not a technical one: who still has access to what, and how do you know? The joiner part of access is usually handled — there is a ticket, an onboarding list, an onboarding checklist. The leaver part has its own page (access request & offboarding). What rots in the middle is the staying: the support contractor moved to another client but kept the admin seat, the manager's old backup login survived the promotion, the shared drive permission granted "just for the audit" in March is still wide open in September. A quarterly user access review is the pass that finds the rot — and it is the single cheapest piece of evidence SOC 2, ISO 27001, and every customer security questionnaire will ask you for. This page is the walk.

1. Why the review exists before how to run it

• An access review is not a security project — it is a habit with a signature. The whole deliverable is a dated record that says: on this date, this person walked every person against every system, decided keep or revoke, and signed it. Auditors do not ask whether your access was perfect on the day of the audit. They ask whether you looked, on a schedule, and what you did about what you found. "We reviewed access on 12 Sep and revoked 4 accounts" is evidence. "We're pretty careful about that" is not.
• The review is where movers get caught, not just leavers. People changing roles is the quiet one: the engineer who became a manager and kept production access, the ops person who moved to sales and still receives the finance reports. Offboarding handles the departure; only a periodic review catches the drift while the person is still employed.
• Small teams do this faster than big ones. Twenty people and fifteen systems is a two-hour quarterly pass. The enterprise-grade framing ("recertification campaigns", "RBAC matrices") is borrowed costume — what the auditor wants, and what actually reduces risk, is the walk this page describes, done honestly, four times a year.

2. Build the people list before the systems list

• The people list is whoever is paid or contracted today. Employees, contractors, and the bookkeeper who logs in from her own practice — everyone with credentials, in one column. The source of truth is whoever pays them, not the SSO admin panel: the SSO shows you who can log in; the payroll list tells you who should. Every name in the SSO that is not on the people list is already a finding before the walk starts.
• Mark every line with the one detail that matters: end date or "ongoing". Contractors and temp staff get a date — the date their access should already have died. A person on the list whose end date passed two months ago and who still appears in the SSO is the highest-value finding this whole exercise produces, and it costs one line item to surface.
• Keep the list to one screen. A spreadsheet with name, role, type (employee/contractor), end date, and reviewer initials. If it grows past one screen, you have outgrown the spreadsheet — but most small teams have not, and pretending otherwise just postpones the first review until after the first incident.

3. Inventory the systems list — include the ones without a dashboard

• Start with the SSO tenant and walk outward. The Google Workspace or Microsoft 365 admin panel lists the first dozen apps by itself. Then the stragglers: cloud consoles (AWS, Vercel, Cloudflare), the code host (GitHub), the password vault, the VPN, the finance tool, the shared drives, the project tracker, the status page. The shadow IT audit is what fills in the tools people adopted without telling you — the review assumes that list is roughly current.
• Add the systems that do not have an "Admin → Users" screen. The NAS, the router, the monitoring server, the WordPress admin, the database itself. These are the accounts nobody revokes because there is no offboarding button — exactly why they need a human walking a list every quarter.
• Count shared logins as systems, not as people. The admin login to the billing portal that "the three of us share" gets its own row. Reviews that skip shared accounts skip the accounts most likely to outlive every person who knows the password. (The fix direction is named accounts for humans — the password manager rollout is what makes that affordable.)

4. The walk: every person against every system they touch

• Go system by system, not person by person. Open the admin panel for one system, list its users, and check each name against the people list: does this person still work here, in this role? Keep / downgrade / revoke, one word per name, written down. System-first is faster, catches orphan accounts automatically, and produces the exact export auditors want.
• Apply the role test, not just the employment test. "Still works here" is the easy half. The harder half: does a person in this role need this access? The salesperson with production deploy rights is still employed — and still wrong. Least privilege is the standard the review enforces; the downgrade is usually a two-minute admin-panel change.
• Treat admin, break-glass, and service accounts as their own pass. Admin seats, the break-glass super-admin from the Workspace checklist, CI tokens, API keys tied to a person — these get named individuals and a review every quarter even when nothing else changes. Service accounts should map to a system, not a person; any credential that maps to an ex-employee gets rotated the same afternoon (secrets rotation has the pass).
• Look for the deltas the SSO can show you. Last-login columns and admin-audit logs turn the walk from a guess into a scan: an account with no login in 90 days is a revoke candidate by default; an account logging in at 3am from the finance tool it has no role touching is a conversation. You are not investigating — you are letting the data point at the lines that deserve the two-minute look.

5. The five findings you will find on the first pass

• Orphan accounts. People on the systems list who are not on the people list — ex-employees, ended contractors, "test" accounts someone never deleted. Expect a handful the first quarter. Revoke the same day; note the reason each one survived (usually: no offboarding checklist existed for that system, which is a process fix, not a blame).
• Role creep. Access granted for a one-off project that became permanent. The backup admin from the server migration, the read access granted "while Priya was on leave" in February. Downgrade to what the role needs today; the project archive can live in the vault if it is ever needed again.
• Shared logins with no owner. The billing portal password in a group chat. The fix is naming an owner and moving the credential into the vault as a shared item with a named list — shared access is fine, anonymous shared access is the finding.
• Stale contractor access. The engagement ended, the date passed, the seat is still active. This is the finding most likely to embarrass you in front of a customer — an ex-contractor is one password reuse away from being an outsider with a live account. Revoke, and add the end date check to the next contractor onboarding (contractor checklist already carries the expiry-stamp rule).
• The unreviewed break-glass. The super-admin or root credential that "nobody uses" — which usually means nobody has checked whether its last use was staff, a leaver, or an attacker. Verify its password was rotated after the last time anyone left who knew it, confirm the second factor still points at a current person, and log the verification.

6. Fix same-day, log the decision, skip the re-education

• Revoke and downgrade during the walk, not "next week". The review's value collapses if findings queue up in a doc. The admin panel is open; the decision is written; the button is right there. Every fix takes less time than the meeting to schedule the fix.
• Log every keep with a reason when it is surprising. "Keep — bookkeeper needs billing export until year-end (review again Jan)" is a decision. A bare "keep" next to an odd permission is a loophole wearing a checkbox. The log is also what turns next quarter's review from an investigation into a diff.
• Tell people what changed, once, kindly. A two-line note: quarterly access review ran, here's what changed for you, here's why. Not a lecture — a notification. Reviews that turn into blame theater get quietly skipped next quarter, and a skipped review is worse than a shallow one because it produces false evidence.

7. File the evidence the auditor (or the customer) will ask for

• The artifact is: date, reviewer, scope, decisions, signature. Export the user list from each system before the changes, save it with the decisions marked, and add reviewer name + date at the top. A folder per quarter, one PDF or spreadsheet per system. Ten minutes of filing converts the whole pass into the artifact that answers the access-review question on every security questionnaire for the next ninety days.
• Keep the "all clear" quarters too. A review that found nothing is still evidence — arguably the best kind. The folder should show four dated reviews a year, including the boring ones. Auditors read continuity as control; a gap where a quarter should be reads as "they review when they remember".
• Tie the review into the audit calendar you already run. The access review slots next to the annual security review (which lifts results from it), the quarterly rotation pass, and the tabletop exercise — one compliance afternoon a quarter, four artifacts, and every framework question about access control has a file behind it.

8. The quarterly rhythm, and the part to automate

• Same week every quarter, two hours, calendar-locked. Pick the week after quarter close when the payroll list is fresh. Two hours for a twenty-person, fifteen-system shop is generous; if it runs long, the systems list is the thing to trim first — merge the four cloud consoles into one line item with sub-bullets, not four investigations.
• Automate the boring half: the report, not the decision. A scheduled script that pulls the user list from the SSO and the cloud consoles into one sheet, diffs it against last quarter's, and flags zero-login accounts does 80% of the reading so the human does 100% of the deciding. The decision stays manual on purpose — that judgment call is what the evidence exists to prove. The Automation Starter Pack below schedules exactly this kind of pull-and-diff, and the quarterly nudge that makes the review happen without anyone remembering.
• When headcount doubles, upgrade the ritual, not the frequency. The quarterly human walk scales to roughly fifty people; past that, move to per-system owners reviewing their own roster with you spot-checking — the artifact format stays identical. What never changes: quarterly, dated, decided, signed.

A user access review is one list of people, one list of systems, and a walk that leaves a dated decision on every intersection: revoke the orphans, downgrade the role creep, name the shared logins, kill the stale contractor seats, and verify the break-glass nobody uses. Fix same-day, file the export with a signature, and repeat in the same week every quarter. The Ops Starter Kit ($14) puts the review sheet and the evidence folder structure on fill-in-the-blank templates, and the Automation Starter Pack ($19) schedules the quarterly review nudge and the user-list pulls so the walk starts from data instead of memory.