How much evidence does a SOC 2 audit need?
- Mapping our whole control library back to where evidence comes from lands on 22 sources. Not 22 files, 22 systems and document sets.
- One export usually answers several criteria at once, so collection is not proportional to your control count.
- The reliability ranking is simple: the system's own record, then a screenshot of current state, then documents you wrote, then somebody telling the auditor.
- For a Type II, a screenshot of today says very little about last March. That difference catches people out.
Most of a SOC 2 comes from about twenty places
People picture a SOC 2 as an enormous document request. Hundreds of files, months of collecting.
The real shape is narrower. When I map our whole control library back to where the evidence actually comes from, it lands on 22 sources. Not 22 files. 22 systems and document sets.
Your identity provider. Your cloud accounts. Your code repository and its pull request history. Your ticketing system. Your HR records. Your endpoint management. Your vulnerability scanning. Your logging and alerting. Your backup configuration. Your vendor list and the reports those vendors publish. Your policy set. Your risk assessment. A handful more.
If you run a small company, several of those are the same tool.
One export answers several criteria
This is the part nobody tells you, and it is the reason the work is smaller than it looks.
A single export from your identity provider speaks to access provisioning, access removal, multi factor authentication, privileged accounts, and your quarterly access review. That is one file doing the work of five separate requests.
Your code repository is the same story. The pull request history is your change management evidence, your approval evidence, and a good part of your segregation of duties story, in one place.
Collection is not proportional to the number of controls, because coverage overlaps. An auditor who asks you for a separate artifact per control has not mapped their own evidence, and is asking you to do that mapping for them.
The system's own record beats a description of it
Auditors talk about the reliability of evidence. The ranking is not complicated.
Best is the system's own record, pulled straight from the system. An export, an API response, a log. It says what happened whether or not anyone wanted it to.
Next is a screenshot of current state. Useful, with a shelf life. A screenshot proves a setting was on the day it was taken. It says nothing about the eleven months before.
Then documents you wrote: policies, procedures, registers. These establish intent. They are necessary, and they are not proof that anything happened.
Last is inquiry, which means somebody told the auditor. On its own that is not evidence of anything.
Type II moves the bar, and people miss it
A Type I describes your controls at a point in time. A Type II reports on whether they operated across a period.
That changes what evidence means. For a Type I, current state is largely the question, so a screenshot carries real weight. For a Type II covering the last twelve months, a screenshot of today is close to useless for proving what was true last March. You need the record that was kept while the period was running, which is why starting collection at the end of a period goes badly.
The practical consequence: turn on log retention and keep your tickets before the period starts, not when the auditor asks.
Volume is the wrong thing to worry about
The number worth asking about is not how many files you sent. It is what fraction of the conclusions rest on something a system produced by itself.
A tidy audit with forty artifacts, all of them system records, is worth more than one with four hundred where most are documents somebody typed. Ask your auditor which of your controls will be tested against a live system export and which against a document you wrote. The answer tells you what kind of report you are buying.
Frequently asked questions
How much evidence does a SOC 2 audit require?
What evidence do I need for a SOC 2 Type II?
Are screenshots acceptable evidence for SOC 2?
How many documents does a SOC 2 audit need?
Is inquiry enough evidence for a SOC 2 control?
Keep reading
Do you need an evidence collection tool?
Nothing in the standards requires one. Evidence is records your systems already produce, and the auditor should be the one collecting them.
How many controls does SOC 2 require?
None, as a number. The rulebook holds 61 criteria and no control list at all. What actually decides how many you end up writing.
How many samples does an auditor actually test?
No standard sets a number. How often the control runs does. The table firms work from, and why which items get picked matters more.
How long does a SOC 2 audit take?
Three clocks run and only one is your auditor's. Where the time actually goes, and the part nothing can speed up.
Sources
- AT-C section 205 sets the performance and reporting requirements for examination engagements such as SOC 2; it does not prescribe a required number of controls, a required volume of evidence, or a required sample size.
- Audit evidence obtained directly by the auditor is more reliable than evidence obtained indirectly, establishing the evidence-reliability hierarchy.
- AICPA SOC for Service Organizations: a Type II report covers a period of time, while a Type I describes controls at a point in time.
- Trust Services Criteria are evaluated at the criterion level; points of focus are illustrative, not requirements (2017 TSC with revised points of focus, 2022).
- The Chiaro control library, the criteria it maps to, and every test step are published in full.