What counts as evidence
Evidence is anything that independently demonstrates a control operated. System-generated exports, tickets, signed reviews, configuration captures with visible timestamps, training completion reports, dated meeting records.
What does not count: an assertion that something happened, or a document describing what should happen. A policy proves a policy exists. It does not prove anyone followed it.
The strongest evidence has three properties — it is dated, it is system-generated rather than authored by the person being tested, and it covers the period rather than the moment.
What proves what
| Control | Evidence that works | Evidence that gets rejected |
|---|---|---|
| MFA on production | IdP configuration export plus an enrollment report showing all users | A screenshot of your own login prompt |
| Quarterly access review | Signed review export per system, per quarter, dated | One review covering all four quarters, done last week |
| Offboarding revocation | Tickets showing revocation within SLA, sampled across the window | A policy stating the SLA |
| Change approval | Pull request history showing review before merge | A description of your branching strategy |
| Vulnerability scanning | Scan reports across the window plus remediation tickets | The current dashboard |
| Incident response test | Tabletop record with date, participants and findings | The incident response plan itself |
| Security training | Completion report with dates per employee | The training deck |
| Risk assessment | Risk register with ratings, owners and review date | A risk methodology document |
| Backup restore | Restore test record with date and outcome | Backup job success logs |
| Vendor security terms | Executed agreements with the relevant clauses | A vendor list |
The pattern down the right-hand column: describing the control rather than demonstrating it. It is the most common reason a first evidence submission comes back with requests.
How much you need
Enough for the auditor to sample across the observation window. That is a coverage requirement, not a volume one.
A quarterly control over a twelve-month window needs four instances, each dated and complete. A daily or continuous control will be sampled — the auditor picks a subset of dates and asks for those. You do not need to hand over everything; you need to be able to produce any of it.
The consequence people miss: a quarterly control gives you four chances to fail and a daily control gives you hundreds. Frequent controls are more forgiving of a single miss and less forgiving of a systemic one.
Why auditors reject evidence
It is undated. Screenshots without a visible timestamp are the single most commonly rejected artifact. If the image does not show when it was taken, it proves nothing about a period.
It shows now, not then. A current configuration export says the control is in place today. For a Type 2 the question is whether it was in place in month two.
It is self-generated. A spreadsheet you maintained describing access reviews is weaker than an export from the system that granted the access.
It covers part of the window. Three quarters of evidence for a four-quarter control is an exception, not a near miss.
It does not match the control description. If your control says reviews happen quarterly and evidence shows them happening twice a year, the finding is against your own stated control.
What automation cannot evidence for you
Compliance platforms collect technical evidence continuously and that is real value — it is the tedious part, and doing it by hand is genuinely worse.
What they do not cover are the controls that happen outside connected systems:
Tabletop exercises. Somebody has to run one and write down who attended and what was found.
Vendor agreement review. Reading contracts for security clauses is not an API call.
Management review and board oversight. CC1 wants evidence that someone senior is accountable. That is a meeting record.
Anything before the tool was connected. Automation cannot retroactively produce evidence for a period it was not observing — which is why connecting a platform is a reason to start the window, not a substitute for having started it. See passing SOC 2 when you already run a platform.
The evidence plan
Settle this before the window opens, not during it. For every control in scope, three columns:
Which artifact proves it. Named specifically — "IdP enrollment export", not "access evidence".
Who produces it. A person, not a team. Unowned evidence is uncollected evidence.
On what cadence. With the dates in someone's calendar, because a quarterly control that depends on remembering is a quarterly control that will be missed once.
A readiness assessment produces this plan as a deliverable, which is most of why it exists.
FAQs
What counts as evidence in a SOC 2 audit?
Anything that independently demonstrates a control operated: system-generated exports, tickets, signed reviews, configuration screenshots with visible timestamps, training completion reports, meeting records. What does not count is an assertion that something happened, or a document describing what should happen rather than what did.
How much SOC 2 evidence do I need?
Enough for the auditor to sample across the observation window. For a control that runs quarterly over a twelve-month window, that means four instances, each dated and complete. For a daily or continuous control they will sample a subset. The requirement is coverage across the period, not volume.
Why do auditors reject SOC 2 evidence?
Most often because it is undated, because it shows current state rather than what happened during the period, because it was generated by the person being tested rather than by a system, or because it covers only part of the window. Screenshots without visible timestamps are the single most commonly rejected artifact.
Can compliance automation collect all my SOC 2 evidence?
It collects a lot of the technical evidence continuously, which is genuinely useful. It does not produce evidence for controls that happen outside connected systems — tabletop exercises, vendor agreement reviews, management reviews, board oversight — and it cannot retroactively create evidence for a period before it was connected.
When should I start collecting SOC 2 evidence?
Before the observation window opens, not during it. Evidence has to cover the whole period, so anything you set up in month two leaves month one uncovered. Deciding which artifact proves which control, and who produces it, is the last thing to settle before starting the clock.
Where to go next
Work the control list in the SOC 2 compliance checklist, understand what each criterion asks in CC1 through CC9, get the evidence plan built in a readiness assessment, or see how sampling works in the audit.