SOC 2 evidence is what turns strong security into a passing audit. Strong security alone does not pass; provable security does. This is how to collect the evidence that proves it.
TL;DR
Evidence is the proof that each of your controls actually operated. Auditors do not take your word for it. They sample dated artifacts, access reviews, change tickets, logs, and verify the control ran.
The teams that pass cleanly are the ones whose evidence is collected continuously, indexed by Trust Services Criteria, and retrievable in minutes, not reconstructed the week before fieldwork.
On this page
What counts as SOC 2 evidence
SOC 2 evidence is any objective artifact that shows a control exists and operated as described. Policies say what you intend to do; evidence proves you did it.
The details matter to an auditor. Logs should carry timestamps and user identifiers. Tickets should show approvals, dates, and outcomes. Attestations must be signed and dated.
Type I vs Type II: two different evidence jobs
How much evidence you need, and of what kind, depends entirely on which report you are pursuing.
How auditors sample evidence
Auditors do not inspect every event. For a Type II they use population sampling: they ask for the full population of something, then test a representative sample from it.
What auditors want, by control area
Auditors organise their SOC 2 evidence requests around the Common Criteria. Indexing your evidence the same way, by criterion, makes fieldwork dramatically faster.
Access (CC6)
- Access reviews with sign-offs
- MFA configuration proof
- Deprovisioning records for leavers
Operations (CC7)
- Monitoring and alert logs
- Vulnerability scan results
- Incident records, including tests
Change (CC8)
- Change tickets with approvals
- Dates and outcomes recorded
Governance & vendors
- Risk assessment, signed
- Vendor assessment files
- Training completion logs
How to collect evidence well
The goal is SOC 2 evidence that is continuous, complete, and instantly retrievable. A repeatable approach:
Map each control to a source
- Decide exactly what artifact proves it
- No evidence source means a gap to fix now
Index by criterion
- Organise the way auditors request it
- Retrievable in minutes beats a stronger control you cannot locate
Automate collection
- Pull logs, configs, access events via APIs
- Manual collection is slow and misses days
Start on day one
- Begin when the observation window opens
- What you miss in month two cannot be recreated in month six
Run periodic internal checks too, so a missed access review or lapsed scan surfaces while you can still fix it, not during fieldwork.
The mistake that sinks audits
If there is one SOC 2 evidence failure mode to burn into memory, it is treating evidence collection as a one-time push at the end of the window. Type II is about continuous operation, and evidence you did not capture as you went cannot be reconstructed later.
Evidence that collects itself
Step back and the core problem is obvious. Evidence collection is painful because the controls live in one set of tools, and the evidence they produce lands in another, so someone has to bridge the two by hand, for months.
Walk into fieldwork with the receipts already in hand.
Osto is a one-stop cybersecurity and compliance platform for growing companies. Controls and their evidence in one place, captured continuously and mapped to the criteria, so you can get SOC 2 ready in about 115 days. No security team required.
Frequently asked questions
What counts as SOC 2 evidence?
Any objective artifact that proves a control exists and operated as described: policies, procedures, access logs, change tickets, access reviews with sign-offs, monitoring and alert logs, vulnerability scans, and signed attestations, all dated and retrievable.
How does evidence differ between Type I and Type II?
A Type I report evaluates control design at a single point in time, so evidence is collected once and is mainly policies, procedures, and limited samples. A Type II proves controls operated across the whole observation window, so evidence must be collected continuously.
How do auditors sample evidence?
For a Type II, auditors use population sampling. They request the full population of an item, such as every change ticket or every user granted access during the window, then test a representative sample from it.
Can strong security still fail a SOC 2 audit?
Yes, because SOC 2 tests provability, not just security. A control can be working perfectly, but if it left no retrievable, dated evidence trail, the auditor cannot verify it, and that becomes an exception.
Do I need to automate evidence collection?
For a Type II it is effectively non-optional at any real team size. Automated tools pull audit logs, configuration snapshots, and access events via APIs, so evidence accumulates continuously instead of being gathered by hand.