SOC 2 access review planner
Access reviews fail for the same three reasons every time: the population was not complete, the reviewer was the wrong person, and nothing recorded what was removed. This designs one that does not.
A user access review is the most commonly tested control in a first SOC 2 and the one most likely to produce an exception. Not because teams skip it, but because the version they run is a screenshot of a user list with a note saying it was checked. That is not what gets tested. What gets tested is whether the population was complete, whether the person reviewing it could tell correct access from incorrect access, whether a decision was recorded per account, and whether the accounts marked for removal were actually removed and when.
Pick the systems you run and answer four questions about how access works today. This returns a review schedule with a cadence per system, the right reviewer for each, the number of review events that have to fall inside your observation window, and an evidence checklist you can hand to whoever runs it.
The schedule appears on this page. Nothing is emailed anywhere unless you ask for it at the end.
On its way
Allow one working day. If you would rather talk it through, book a time.
The population is tested before the decisions are
Before an auditor looks at whether you made the right call on an account, they check that the list you reviewed was the complete list. That means the export has to come from the system rather than from a spreadsheet someone maintains, it has to be dated, and it has to include disabled and service accounts rather than only the ones a filter showed. If the auditor finds an account another way and it is not on your list, the finding stops being about that account and becomes a question about whether any of your populations can be relied on.
Build every export from a saved query or a documented export path, and use the same one each cycle so the counts reconcile between quarters. A jump from forty-one accounts to fifty-eight with no hiring in between is a question you want to be able to answer.
What a review that passes actually contains
Five things. A dated export from the system. A named reviewer with the standing to judge the access. A recorded decision against every single account rather than a note that says the list was reviewed. A ticket or a log entry for each removal, with the timestamp. And evidence the removals actually happened, which is usually the next cycle's export showing those accounts gone. The fifth is the one teams skip, and it is the one that turns a review from a document into a control.
The access review evidence page covers what auditors accept and reject in detail, and CC6 access controls sets out where this sits in the criteria.
Common questions
How often does an access review have to happen?
The criteria do not name a frequency. Your own policy does, and the auditor tests you against what you wrote. Quarterly for anything holding production or customer data is the common position and the one most customers expect to see. Annually for low-risk systems is defensible if the policy says so. What is not defensible is a policy saying quarterly and three reviews in a twelve month window.
Can one person review everything?
At twenty people, usually yes, and it is the practical answer. The weakness is that a central reviewer often cannot tell whether a particular engineer should still have access to a particular repository, so the review becomes a check that the person still works there. That catches departures and misses accumulated access, which is the thing reviews exist to catch. Splitting the technical systems out to the people who understand them fixes most of it.
Do service accounts and API keys count?
Yes, and they are the most commonly omitted part of the population. Every non-human credential needs an owner, a purpose and a review of whether it is still needed. They also tend to hold more access than any person does, which is exactly why an auditor asks.
What if the review finds someone who left months ago?
Record it, remove the access, note the date, and keep the record. A review that finds something is evidence the control works. What you should also do is treat it as an offboarding failure and look at whether it was one account or a pattern, because the same auditor will sample your termination population separately and find the same person.
Want someone to run the first cycle with you
The first review is the one that sets the format for every one after it. Canadian firms that do readiness work will run it alongside you.
Get matched