What SOC 2 access review evidence looks like
An access review is not a meeting or an intention. It is a dated record, per system, showing who held access, who looked at it, and what changed as a result.
Access review evidence is a per-system record carrying six things: the system reviewed, the complete list of accounts in that system on a stated date, the role or entitlement each account held, a decision of keep or remove against every line, the name of the person who made those decisions, and proof that the removals actually happened. Anything missing one of those six is the thing auditors bounce most often in a first Type 2.
6 fields Minimum an access review record carries
Per system Not one combined review of everything
What does an access review record have to contain?
The record has to show the control running, not describe it. The table below is the shape that gets accepted without a follow-up question. Build it as one row per account, one file per system, one file per review.
| Field | Why the auditor wants it | Where it comes from |
|---|---|---|
| System name and environment | Ties the review to a control and to a scope boundary | You, from the system inventory |
| Extract date | Fixes the population to a point inside the observation window | The export header or the file timestamp |
| Account identifier | Lets the auditor trace a name back to a person or a service | Identity provider or the application user list |
| Role, group or entitlement | Tests least privilege, not just whether an account exists | The same export |
| Employment status | Surfaces leavers and contractors still holding access | The HR system, joined on email |
| Decision, keep or remove | Shows judgement was applied line by line | The reviewer |
| Reviewer name and date | Identifies who is accountable for the decision | The reviewer, in the file |
| Removal confirmation | Proves the review changed something, not just observed it | Ticket, log entry or a follow-up export |
How do you build the population list?
The population is every account that exists in the system on the review date, including the ones you would rather not think about. Build it from a query, not from memory, and run the same query every quarter so the lists are comparable.
- Export the full user list from the system itself, not from your onboarding spreadsheet. The spreadsheet is what you intended; the export is what is true.
- Include service accounts, API tokens and integration users. These are accounts with access and they are the ones nobody owns.
- Include contractors, agency staff and anyone on a personal email address who was given a seat during a busy month.
- Include accounts in a disabled or suspended state, and mark them as such. Omitting them looks like concealment when the auditor pulls their own export.
- Join the list against your HR roster so every account resolves to a current person, a current contractor, or a documented service.
- Keep the raw export next to the reviewed version. The auditor may want to see that nothing was deleted between the two.
Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.
How much of the review will the auditor actually test?
For a Type 2 the auditor samples. They select from your population of reviews across the window, or your population of accounts within one review. Each firm sets its own sizes, but the shape is consistent: the sample grows with the population and then flattens.
| Population | Items selected | What this means for you |
|---|---|---|
| Up to 25 | 3 | Every selected item has to be perfect |
| 26 to 50 | 5 | One weak record is a fifth of the sample |
| 51 to 100 | 10 | Consistency starts to matter more than care |
| 101 to 250 | 15 | Manual collection begins to hurt |
| 251 to 500 | 25 | Exports have to be scripted |
| Over 500 | 40 | Automation is cheaper than the labour |
A small population is not an easy audit
Teams assume a short list means a light test. The opposite is true. With a sample of three, a single record missing a reviewer name is a 33 percent failure rate on that control, and the auditor has no room to treat it as an isolated slip.
Why does an access review get sent back?
Five reasons account for almost all of it, and four of them are about the record rather than the review.
- No reviewer name
- A spreadsheet of accounts with a tick column and no signature does not show who exercised judgement. Put a name and a date in the file, not only in the email that carried it.
- No evidence of removal
- Six accounts marked remove, and nothing showing they were removed. The auditor needs a ticket, a log line, or a later export where those accounts are gone.
- A screenshot with no date in frame
- A cropped user list proves nothing about when it was true. Capture the full window including the system clock, or better, export to CSV where the system stamps the date itself.
- The population excludes contractors
- The most common finding of the five. Contractors are provisioned quickly, sit outside the HR system, and are missing from the list the reviewer worked from. When the auditor finds one through a separate export, every population you provided is now in question.
- The review happened outside your stated cadence
- A policy promising quarterly reviews and a window containing two of them is an exception you wrote yourself. Fix the policy before the window opens rather than the record afterwards.
Running one this week
0 of 7 done ·
The wider rules about what auditors accept sit on the evidence collection page, and the evidence tracker will generate the access review rows for your criteria with an owner and a cadence attached. If your access reviews are failing because provisioning itself is loose, the joiner and leaver evidence page is the upstream fix, and the checklist puts both in sequence.
Get access reviews done before the window opens
Access reviews are the control most often failed on a first Type II, because the evidence has to exist for the whole period. Tell us your scope and compare firms that run them.
Get matchedCommon questions
How often do we have to do access reviews for SOC 2?
As often as your policy says, and no less. SOC 2 does not set a frequency, you do, and the auditor tests you against your own commitment. Quarterly is common and defensible for production systems; annual is acceptable for low-risk internal tools if your policy separates them that way.
Can one review cover all our systems at once?
You can run them on the same day, but keep one record per system. A single merged sheet makes it impossible for the auditor to test the cloud console control separately from the code repository control, and they will ask you to split it anyway.
Do service accounts and API keys need reviewing?
Yes, and they are usually the weakest part of the record. Every service account needs a named human owner, a stated purpose, and a keep or remove decision like any other line. Orphaned integration credentials from a tool you stopped using two years ago are a finding waiting to be written.
Who should sign the access review?
The person who can judge whether the access is appropriate, which is normally the system owner rather than the compliance lead. A review signed by someone who does not know what the roles mean is a rubber stamp, and auditors ask follow-up questions that expose it.
We missed a quarterly review. What now?
Record the miss, do the review late, and write down why it happened and what changed. A documented exception with a root cause is treated far better than a backdated record. Backdating turns a control exception into a question about your integrity.