User Access Review for SMB | Quarterly Checklist

User Access Review for Small Business: Quarterly Checklist

*Tom Reed · Updated 6 October 2026*

A user access review is a scheduled check — usually quarterly for admin and finance systems, at least twice a year for everything else — where IT lists who can get into each important system, the person who owns that system confirms each account is still needed at the right level, and anything stale is removed and recorded. For a 20–100 person company you do not need an identity governance platform to do this well: you need a list of critical systems, an owner per system, an export of users and roles, a short sign-off, and a place to keep the evidence. This checklist shows IT managers how to scope the first review, handle admin rights and shared accounts, get managers to actually reply, and repeat it each quarter — without invented breach statistics.

What is a user access review (and how is it different from onboarding, offboarding, and MFA)?

An access review — also called a user access review, entitlement review, or access recertification — is the periodic sweep that asks: does this person still need this access at this level? IT exports the list. A business system owner certifies keep, change role, or remove. You record the decision and fix anything stale.

That is user access management as a recurring control, not day-one provisioning. The formal name for the sign-off step is access certification: the owner attests the list is correct. Same job, different label on the form.

Neighbour practices stay neighbours — link them, do not merge them:

• Device onboarding and offboarding grants and removes access at join and leave. The review catches what those steps missed: movers who kept old roles, contractors past end date, and accounts nobody recognises.
• MFA rollout makes sign-in harder to abuse. Note MFA status as a column in the export. It does not decide who should have an account.
• Password manager stores and shares credentials safely. It does not certify who may use them.
• Change management approves individual production changes. Removals and downgrades from the review travel that path as standard changes.
• Shadow IT finds unsanctioned apps. This playbook reviews users inside systems you already know about.
• Software licence management tracks seats and cost. When you remove access, reclaim the seat there — do not rewrite that checklist here.

Least privilege is the goal this process enforces: people only keep the access they need. An access review is how you check you are still meeting that goal after joiners, movers, and leavers. Say it once; the rest of this post stays in the review playbook, not an identity-architecture explainer.

What usually goes wrong without a review is ordinary: a contractor left months ago and still opens the CRM; a mover kept export rights; a shared finance login has no named owner. You do not need a made-up breach percentage to clean those rows. A quarterly pass with a named owner and a ticket for every removal is enough for most 20–100 person companies.

Which systems should a small business include in an access review?

Start from what would hurt if the wrong person still had a login. Use your IT asset inventory as the seed list if you have one. If not, build the list below in a single sheet.

Name a system owner who is a business person, not IT, for each row. They confirm who needs access. IT runs the exports, tickets, and evidence folder. Customer-data apps and any tool that can move money sit in the first pass even if the sheet already feels long. Marketing CMS copy and low-risk collaboration tools can wait for v2 if capacity is thin — mark them "not yet in scope", do not pretend they were reviewed.

Guest users, external "anyone with link" shares, and dormant registrar admins sit outside the HR staff list — put them on the collect sheet anyway. If an app is missing from the list, it is out of scope on purpose or it belongs in the shadow IT find step before the next review.

How often should you review access — and who signs off?

A workable SMB baseline: quarterly access review for admin, privileged, finance, and payroll access; every six months for general users. Write that one line into your access control policy so the cadence is not a hallway rumour. Some customer contracts or audits set their own schedule — follow those where they apply. Frameworks such as ISO 27001, SOC 2, and SOX are reasons auditors ask for evidence of periodic reviews; this post is not legal advice and does not tell you which framework you must adopt.

Who signs off:

• System owner — keep / change role / remove per account on their sheet.
• IT lead — runs the mechanics, challenges standing admin, implements removals.
• Business owner for high-impact systems (finance lead, COO/MD for identity admins) — accepts the timing and the residual risk of any exception.

Silence is not approval. Give owners five working days. Escalate once to their manager. If there is still no reply, treat the row as remove-or-downgrade pending a written keep, and say so on the ticket. A user access review template that works at this size is a CSV plus three decision columns — not a vendor portal.

Keep the owner sheet short. One system per sheet. Columns: account name, role, last sign-in if known, MFA yes/no, and the three decisions. Paste a one-line reminder at the top: "Reply keep, change role, or remove — silence will be treated as remove." Managers reply faster when the ask fits one screen. Do not attach a 40-page policy and call it a review.

How do you run your first user access review step by step?

Do the first pass in two to three weeks. After that, run the same loop each quarter for privileged and finance systems, and every six months for the rest. This is your user access review checklist and user access review process in one place.

First user access review checklist (2–3 weeks, then quarterly)

Scope (days 1–3)

1. List critical systems: identity provider / email (Microsoft 365 or Google Workspace), finance and payroll, CRM, file storage, cloud hosting / DNS / domain registrar, password manager admin, endpoint/MDM console, phone system admin, and any customer-data app.
2. Name a system owner (a business person, not IT) for each — they confirm who needs access; IT runs the mechanics.
3. Set tiers: quarterly for admin/privileged and finance/payroll; six-monthly for everyone else. Note it in the access control policy in one line.

Collect (days 4–7)

1. Export users + roles from each system (CSV). Mark: active / disabled, last sign-in if available, role/permission level, MFA on/off.
2. Match against the HR or staff list: flag leavers, movers (changed team), contractors past end date, and unknown names.
3. Separately list admin accounts, shared/generic logins (info@, reception, a shared finance login), and service/integration accounts.

Certify (days 8–12)

1. Send each system owner a short sheet: keep / change role / remove, per account. Deadline 5 working days; escalate silence to their manager once — "no reply" is not "keep".
2. Challenge standing admin: anyone with admin who doesn't do admin work daily gets a normal account plus a separate admin account (or loses admin).
3. Shared accounts: replace with named accounts or shared mailboxes/groups where the tool allows; where they must stay, store in the password manager, name an owner, rotate after any leaver.

Fix and record (days 13–15)

1. Remove or downgrade access through the normal change/helpdesk path (standard change — see change management); note ticket numbers.
2. Save the evidence: export date, reviewer, decisions, changes made, date completed. One folder per quarter.
3. Root-cause anything stale: which offboarding or mover step was missed? Fix the onboarding/offboarding checklist, not just the account.
4. Book the next review in calendars now.

A second person must be able to open last quarter's folder and see what was decided without asking you. A sheet and ticket numbers can do that. Chat cannot.

After the first review, most of the work is incremental: export again, highlight deltas (new accounts, role changes, no sign-in), and only re-challenge the full list for admins and finance. Movers and contractors still get a full row every time. Book the next date before you close the folder so the cadence survives holiday cover.

What do you do about admin rights, shared accounts, and service accounts?

Admin rights and other privileged accounts need their own list every quarter. Anyone who has admin but does not do admin work daily should not keep standing privilege on their everyday login. Prefer a normal account plus a separate admin account, or remove admin. A privileged access review is the same certification loop with a shorter list and a harder challenge. Enterprise privileged-access-management (PAM) tooling sits beyond typical SMB scope until the number of systems or the audit burden makes spreadsheets error-prone — mention it as a later option, not a day-one purchase.

Shared accounts — info@, reception, a shared finance login — hide who did what and survive leavers. Replace with named accounts or shared mailboxes/groups where the product allows. Where a shared login must stay, put it in the password manager, name a living owner, and rotate the secret after every leaver who knew it. Do not leave shared vault membership unreviewed.

Service and integration accounts — API keys, sync users, billing contacts on DNS or hosting — often outlive the person who created them. List them separately. Confirm the owner, the purpose, and whether MFA or IP restriction is possible. Rotate keys on a fixed cadence and when someone who knew them leaves.

A practical access rights review for admin and shared logins takes one sitting per system: open the privileged list, ask "would this person still get this tomorrow if they asked fresh?", and write the answer. Permission audits that try to score every fine-grained ACL on day one stall. Start with who can administer, export, pay, or change routing. Tighten roles later.

Endpoint and MDM console admins belong on the same privileged list; point day-to-day device hardening at endpoint security rather than expanding it here. Production-admin norms sit next to the acceptable use policy.

What evidence should you keep for auditors, insurers, or customers?

You need a short pack that answers: what did you review, who certified it, what changed, and when. One folder per quarter is enough.

Minimum evidence per system:

• Export date and source (which console, which CSV).
• Reviewer (IT) and system owner who signed off.
• Decisions: keep / change role / remove, with names.
• Change or helpdesk ticket numbers for removals and downgrades — the helpdesk queue is useful evidence when it holds those tickets.
• Date completed and next review date booked.

If a customer or insurer asks why you review access, point at the policy line and the folder. If an account is later compromised, the incident response path takes over; the review pack shows whether that account should still have existed.

How this practice sits next to related IT work:

Stay on this side of each line. Link the other playbooks; do not rewrite them. When a removal frees a seat, finish the seat step in licence management. When an unknown app appears, finish the find step in shadow IT, then add the app to next quarter's scope if it stays.

Put the quarterly review on the same calendar as your other IT hygiene passes so it is not dropped when a project overruns. Fifteen systems with clear owners beat fifty with nobody answering.

FAQ

What is a user access review?

A periodic check where system owners confirm each user still needs their access at the current level, and IT removes or reduces anything that isn't needed, keeping a record.

How often should a small business do access reviews?

Quarterly for admin, finance, and payroll access; every six months for general users is a reasonable SMB baseline. Some audits or customer contracts set their own cadence — follow those where they apply.

What is the difference between an access review and access certification?

Mostly naming. "Certification" or "recertification" usually means the formal sign-off step where the owner attests the list is correct.

Do we need identity governance software?

Not to start. CSV exports, a spreadsheet per system, and owner sign-off work at 20–100 people. Consider tooling when the number of systems or the audit burden makes spreadsheets error-prone.

How does this relate to least privilege?

Least privilege is the goal (people only have the access they need); access reviews are how you check you are still meeting it after joiners, movers, and leavers.