A user access review is a scheduled check in which someone who knows the work confirms, in writing, that each person’s access to each system is still correct. To run one, build a list of who has access to what, send each system’s list to the person best placed to judge it, record their decision on every line, action the removals, and keep the signed result. For most small businesses the whole exercise takes a few hours a quarter once the list exists.
This article is general information about security administration and recordkeeping. It is not legal, compliance or security advice. Which frameworks and obligations apply to an organization varies by industry, size and jurisdiction, and those questions belong with a qualified professional who knows your situation.
Build the list of who has access to what
The list is the whole job. Everything after it is routine.
Work system by system rather than person by person, because that is how the data comes out of each tool and because it lets you hand one clean sheet to one reviewer. For each system, export the user list and record four things per line: the account name, the real person behind it, the permission level, and the date access was granted if the system tells you.
Then add the lines no export will give you. Shared accounts that several people use. Service accounts that software uses rather than people. Accounts belonging to contractors, bookkeepers, agencies or anyone outside payroll. Administrative access granted for one project and never withdrawn. These are the lines that make a review worth running.
Compare the combined list against your staff roster. Three categories fall out immediately: people on the roster with no account in a system they should have, accounts with no matching person on the roster, and accounts whose permission level nobody can explain. Mark all three for follow-up before the review proper begins.
If you already keep an asset and account inventory, your access list should read straight out of it. If the two disagree, the disagreement is itself a finding worth writing down.
Group access by what it lets someone do
Permission names differ in every tool, so translate them into plain language before a reviewer sees them. “Can see customer records”, “can change billing”, “can add and remove users”, “can export everything” are categories a manager can judge. Raw role names like contributor, editor or power user are not.
Write the translation down once in a short key and reuse it. The key makes next quarter’s review faster and makes the record readable to someone who was not there.
Choose who reviews and what they decide
The reviewer should be the person who knows whether the work requires the access, not the person who administers the system. In a small business that is usually a department lead, an office manager or the owner. Whoever administers access should prepare the sheet and action the outcome, but should not also be the one approving it, since that collapses the review into a self-check.
Give the reviewer exactly four options per line, and make them pick one:
- Keep as is. The access matches the job.
- Reduce. The person needs the system but at a lower level.
- Remove. The access is no longer needed.
- Query. The reviewer cannot tell, and someone must find out before the review closes.
The query option matters more than it looks. Without it, reviewers tick “keep” on anything they do not understand, and the review produces a clean sheet that confirms nothing. Expect queries on service accounts and on anything inherited from a predecessor.
Set a deadline for the sheet to come back and name a single person who chases it.
Set a user access review cadence and hold it
A fixed schedule is the difference between a review and a one-off cleanup. Pick a cadence by what the access can reach rather than by convenience.
| What the access covers | Suggested cadence | Reviewer |
|---|---|---|
| Administrative access to any system | Monthly | Owner or senior lead |
| Financial, payroll or banking systems | Monthly | Finance lead |
| Customer records and customer data stores | Quarterly | Department lead |
| General business applications | Quarterly | Department lead |
| Contractor and third-party accounts | Quarterly, plus at contract change | Whoever owns the relationship |
| Shared and service accounts | Twice a year, plus on owner change | Named account owner |
Hold the cadence even in the quarters where nothing has changed. A dated review recording no changes is still a record of a review, and a gap in the sequence is what a careful reader notices first.
Alongside the scheduled reviews, run an event-driven check whenever someone joins, changes role or leaves. Role changes are the ones that quietly accumulate access, because the new permissions get added and the old ones rarely get taken away. A leaver check should walk every system on the list by name and record the date each account was disabled.
Document the approvals so the user access review stands up later
A review nobody can produce afterwards is indistinguishable from a review nobody ran. Keep the record deliberately plain.
For each review cycle, save one file containing the system name, the review period, the date the sheet went out, the date it came back, the reviewer’s name, the full line-by-line list with the decision against each line, and a short note on anything queried and how it resolved. Save the reviewer’s actual reply alongside it rather than retyping their answers, since the reply in their own words is the stronger record.
Then record what happened to the removals. A decision to remove access is not a completed removal, and the gap between the two is where most reviews lose their value. Add two columns: date actioned and who actioned it. Close the cycle only when every “remove” and “reduce” line has both filled in.
Where a reviewer decides to keep access that looks unusual, ask for one line of reasoning and write it down. “Keeps export rights because she produces the monthly board pack” is a complete answer and saves you relitigating the same line every quarter.
Exceptions and shared accounts
Some access will not fit the rules you have written, and pretending otherwise just pushes the problem out of sight. Keep a short exceptions list: what the exception is, who approved it, why, and when it will be looked at again. An exception with a review date is a managed decision; an exception nobody wrote down is a gap.
Shared accounts need their own treatment because no individual appears against them. For each one, record the named owner, the list of people who currently use it, what it is for, and whether it could be replaced with individual accounts. Reviewing the user list on a shared account is the only way that line stays honest.
Common problems and how to handle them
Nobody knows what an account is for. Do not quietly leave it in place and do not act on a guess. Record it as a query, give it an owner to investigate, and set a date. If the investigation finds nothing, the decision to disable it is the owner’s to make and should be written down as such.
The reviewer approves everything in two minutes. Usually a sign the sheet was unreadable. Translate permissions into plain language, cut the line count by splitting systems, and ask for a reason on any line granting administrative or export rights.
The list does not match the inventory. Treat the mismatch as the output of the review rather than an obstacle to it. Fix both records and note the date.
The removals never happen. Give the actioning step its own owner and its own deadline, separate from the review itself, and do not close the cycle until the columns are filled.
Keep each cycle’s file rather than overwriting the last one. A year of dated reviews, each showing who decided what and when it was carried out, is the clearest evidence that access is administered rather than assumed.
To see how your access records compare with the rest of your security administration before you set a cadence, work through the Free Cyber Security Scorecard page on this site and start with whichever area it shows as thinnest.