SOC 2 evidence

SOC 2 evidence is anything that shows a control worked: an approval, a review, a ticket, a log, a report. For a Type II report the auditor asks for the complete population of each kind of event in the period, tests a sample, and checks recurring controls every time they fell due. Complete, dated, system-generated evidence passes fastest.

The requirement in plain English

The Trust Services Criteria do not list evidence. They describe outcomes, and the AICPA’s attestation standards require the auditor to gather enough appropriate evidence to support an opinion on them. In practice that means four kinds of test.

Inquiry: asking the person who runs the control. Never enough on its own.
Observation: watching the control happen, such as a new starter’s access being set up.
Inspection: reading the record the control left: a signed-off review, an approved change.
Reperformance: the auditor redoing the control, for example re-running the leavers-against-accounts check behind SOC 2 CC6.2.

Populations come first

For an event-driven control, the auditor first asks for the full list of events in the period: every production change for SOC 2 CC8.1, every incident for SOC 2 CC7.4, every leaver. They then test that the list is complete and accurate, because a sample from an incomplete list proves nothing. Lists your systems produce are information produced by the entity, and the auditor tests how each was generated: the query, the filters, the date range.

Samples grow with frequency

From each population the auditor picks a sample. The sample grows with how often the control runs: one occurrence of an annual control such as the recovery test for SOC 2 A1.3, a few of a quarterly one, and many more of a control that runs every day. Each auditing firm sets its own sample sizes.

Recurring controls must be on time, every time

A quarterly access review for SOC 2 CC6.3 has to exist for every quarter in the period, done when your policy says. A missed or late occurrence is an exception even if the next one is perfect.

This is guidance to help you understand the requirement, not legal advice.

What good looks like

A 25-person software company in Bristol keeps an evidence calendar: every recurring control, its owner, its frequency and its due dates for the coming period. The operations manager spends half an hour each month checking that every item due has a record, and chases what is missing that week, not at audit time.

Each recurring control leaves a record in the same place, made at the time, with the reviewer’s name and the date. Event-driven controls live in the system that runs them (the ticketing tool, the code repository, the identity provider), and the team knows how to export a complete list from each one for any date range. When an export is taken, the file name records the system, the query and the date.

Screenshots are the exception, kept for settings that have no export, and each shows the system name and the date and time. At the start of fieldwork the team hands the auditor a list of populations with their sources, so the first week goes on testing, not on searching.

Evidence an auditor expects

None of this is a document the criteria name; all of it is the usual evidence a SOC 2 auditor samples.

Population lists: complete exports for the period, with how each was generated.
Recurring review records: every occurrence in the period, dated, with who reviewed and what changed.
Change tickets or pull requests: approval by someone other than the author, and test results.
Joiner and leaver tickets: access granted after approval, removed on time.
Incident records: detection, classification, response and closure.
Configuration evidence: exports or dated screenshots of settings such as multi-factor authentication and encryption.
Training completions: everyone in scope, within the time your policy allows.
Supplier assurance: each critical supplier’s report, with your review of it.
Test reports: penetration tests, vulnerability scans and recovery tests, with findings tracked to closure (SOC 2 CC4.1).

Common mistakes

Screenshots without a clock

A screenshot of a setting with no date, time or system name could have been taken any day. Capture the whole window, including the date, or use an export.

The population nobody can reproduce

A list of changes pasted into a spreadsheet, with no record of where it came from, fails the completeness test. Keep the query and run it again in front of the auditor if asked.

Evidence written after the event

Auditors spot backfilled reviews quickly: file dates, ticket histories and edit trails give them away. If a control was missed, say so and record the fix; a missed control is an exception, but a fabricated one undermines the whole report.

One missing quarter

Three quarterly reviews in a four-quarter period is an exception, however good the three are. Put every due date in the calendar on the first day of the period.

Evidence spread across inboxes

When evidence lives in personal email and chat threads, people leave and it leaves with them. Keep it in one place, with an owner.

How Sted helps

Records follow templates with sections and, where useful, structured fields you can report on.
Records are part of the Full Management System plan.
Records take file attachments, scanned for malware before download.
Of the 61 record templates Sted maps to SOC 2, 18 come with a suggested frequency, from monthly to annual, among them the Access Review Record (REC-ARR, twice a year), the Log Review Record (REC-LRR, quarterly) and the BC/DR Test Record (REC-BCDRT, quarterly); nothing is scheduled until you pick a first due date.
Records are part of the Full Management System plan.
Only evidence from the last 12 months counts towards readiness.
Administrators and Policy and Process Owners see a training register of every person’s training across documents, filterable by status and document.
Sted does not connect to your cloud, code or HR systems to collect evidence automatically; you record it.

Sted does not pull evidence from your systems or test it. You record it in Sted; the auditor samples and judges it.

Evidence: what counts as evidence, and what does not.
SOC 2 Type I and Type II reports: why a Type II period needs populations and every recurring occurrence.
Access reviews: the recurring control auditors sample most often.
Backup and restore testing: evidence for the recovery test under A1.3.
Records in Sted: where each piece of evidence is kept.
SOC 2 availability criteria: the capacity reviews, backup jobs and recovery tests that form the A1 populations.
SOC 2 processing integrity criteria: processing runs and exception reports as populations.

Frequently asked questions

Are screenshots acceptable SOC 2 evidence?

Yes, when they show the system, the setting or record, and the date and time on the same screen. Auditors prefer a system export or a report run in front of them for anything that lists many items, because a screenshot cannot prove the list is complete.

Can we create missing evidence after the period ends?

No. Evidence has to come from the time the control ran, and auditors check file dates, ticket histories and audit trails. A review written up afterwards for a quarter where none happened is an exception at best, and at worst a reason to doubt the rest of your evidence.