How to Run a Quarterly Access Review for a Small Team

The inventory is the whole game. If the list is incomplete, every later step is theater. Work outward from the identity provider, because it is the easiest source to export and usually covers the most accounts.

Source one: the SSO provider. Export the full user list with status, last login, assigned applications, and role. This is the bulk of your human accounts. Keep suspended users in a separate tab, because suspended accounts are the ones that get reactivated by mistake.

Source two: cloud consoles. Any team running production workloads should have audit logging on from the start; the same startup security discussion puts it bluntly, noting that if you are hosting in AWS you basically have to turn CloudTrail on and collect the data Hacker News discussion. For the review you need the IAM user and role list plus console access history. Service accounts and machine roles belong here even though no human logs into them.

Source three: databases and internal tools. Local database users, admin consoles, internal dashboards. These usually sit outside SSO and are the highest-risk, least-reviewed accounts.

Source four: third-party tools added by hand. Marketing platforms, analytics, support desks, design tools, and anything a department head bought on a credit card. Walk the finance system's vendor list, because it catches tools nobody thought to mention.

CISA's guidance for small business leaders makes inventory a leader action, not just an IT chore: learn what is on your network and maintain inventories of hardware and software assets so you know what is in play and at risk from attack CISA Cyber Essentials. The same logic applies to accounts, since an account you do not know exists cannot be reviewed or revoked.

A practical shortcut for manual sources: ask each department head for the last twelve months of tool invoices, then reconcile that list against SSO application assignments. Every vendor on the invoice that does not appear behind SSO is a manual row.

One spreadsheet, one row per account per system. A person with accounts in five systems gets five rows, because the keep, modify or revoke decision differs per system. These columns are the minimum that makes the sheet usable as both a working document and evidence.

Two design rules keep the sheet usable. First, the owner column must name a person, never a team name, because "Data Team" will not answer an email. Second, do not include passwords, tokens, or copies of personal data; store a reference to where evidence lives instead, a principle a public offboarding template states explicitly when it asks teams to keep evidence references rather than credentials or copied personal data Elba offboarding checklist.

Access review templates from compliance vendors converge on a similar field set: user identification, application inventory, access level, access start date, and a decision with a named approver SecureNDS access review template. An hour spent reading a few is worth it, because those fields have been shaped by audit findings you have not had yet.

The core question per account is not "does this look fine" but "who says so, and on what date." A free template frames it as three questions per account: should this person still have access at all, is the level of access still right, and who approves it with a name and a date SecureSlate access review template. Small teams skip the third question, and it is the one that turns a spreadsheet into evidence.

Owner assignment follows one rule: the owner is the person who would notice if the access were misused. For production databases, that is the engineering lead. For the CRM, the head of sales. For the finance system, whoever owns the books. For service accounts, the engineer who wrote the job that uses them.

Send each owner a filtered view containing only their rows, with three permitted answers:

• Keep: the account is needed, the permission level is correct, and the owner's name goes in the approver column with the review date.
• Modify: the account is needed but over-privileged. The owner must specify the target permission, not just say "reduce," because vague instructions produce vague tickets.
• Revoke: the account is not needed. The owner states why, in one line.

The decision rule that saves the most argument: if an owner does not respond by the deadline, the default is revoke for accounts with no activity in the review period and keep for accounts with recent activity. Announce this default at the start of the window. It converts a polite request into a deadline with consequences, and silence never leaves a dormant account alive.

Two categories deserve a second look whatever the owner says: any account with administrative or root privileges, and any account belonging to someone who has left, changed team, or finished a project. Admin granted for a one-off migration that ended months ago is the classic finding SecureSlate access review template. Ask the owner directly whether that migration still runs.

A repeatable process has dates that do not move. Put the cycle on a calendar and let the calendar drive the work. This table is one quarter; repeat it with shifted dates.

Two things make this schedule work in a company of five to fifty people. The IT lead's total effort is roughly four half-days, small enough to defend against competing priorities. Owners spend minutes, not hours, because they receive only their rows and a three-option answer key.

If the review keeps surfacing departed employees with live accounts, resist moving to monthly reviews. The review is detective, not preventive, and it is doing its job by catching what offboarding missed. Fix the offboarding instead, starting with a confirmed departure date, a full inventory beyond the identity provider, and verification that sessions and tokens have stopped working rather than only that new sign-ins are blocked Elba offboarding checklist.

A review that ends with a spreadsheet edit ends with nothing. Every modify and revoke needs a ticket in the system your team already watches, plus a recorded close date after someone verifies the change in the source system.

The ticket carries four things: account identifier, system, target state (the exact new permission or full removal), and who requested it. When it closes, someone signs in to the source system, confirms the change took effect, and writes the date back into the sheet. Verification by inspection matters because a revocation request is not a revocation. Blocking a sign-in does not stop a session or token from working, as offboarding guidance notes explicitly Elba offboarding checklist.

Then record two metrics per quarter in the sheet header so they are visible next cycle:

1. Orphaned accounts: rows whose owner has left the company, or whose account shows no activity across two consecutive reviews and was not revoked. Count them and list them by name in an appendix.
2. Time to revoke: the median days from decision to verified closure for revoke decisions. Track the maximum too, because one account that took six weeks tells you more than a good median.

A third metric is optional once you have history: the percentage of rows where the owner changed the decision from the previous cycle. Rising churn suggests roles shift faster than provisioning follows. A flat zero across several cycles suggests owners are rubber-stamping, which is its own warning sign.

Small businesses are not a low-risk category. Huntress cites the Verizon Data Breach Investigations Report finding that small businesses under 1,000 employees suffered 2,842 confirmed data breaches compared with 751 at large enterprises Huntress small business checklist. Misused credentials remain a persistent entry path, and the review is one of the few controls that actively retires them.

Print this. It is short enough to finish in the two-week window and specific enough that someone who has never run a review can follow it.

Expect the first cycle's inventory to overrun the schedule, because you will discover accounts nobody knew about. That is the point. A first review that finds dozens of orphans is a successful review, and the second should find far fewer. Most frameworks encourage exactly this incremental pacing rather than a single big-bang cleanup; NIST's Secure Software Development Framework is built as a set of practices to integrate into existing work, adaptable to an organization's existing methodology and risk profile NIST SSDF.

One structural decision remains: who runs the review, and who checks the runner. In a small team the person running the review usually holds admin access to everything being reviewed, which is the situation the review exists to catch. Add one line: a second person, typically the operations lead, reviews the reviewer's own rows and signs the archive. That single step closes the most embarrassing gap in a small team's access review.