Your auditor asks for evidence that the access review ran in March. You open the compliance dashboard and every tile is green. That is a good answer to a different question. The dashboard describes today. The auditor is asking about a Tuesday five months ago.
Key takeaway: SOC 2 evidence is a dated, attributable record that a control operated on a specific day inside the observation window. Current state is not evidence of past operation.
1. Type 1 and Type 2 Ask Different Questions
| SOC 2 Type 1 | SOC 2 Type 2 | |
|---|---|---|
| Question | Are controls suitably designed? | Were they designed suitably and did they operate? |
| Time covered | A single date | A period, commonly 3 to 12 months |
| Evidence needed | Current config and documentation | Dated records across the whole period |
| What a dashboard proves | A great deal | Almost nothing on its own |
Type 1 is a photograph. Type 2 is a film, and the auditor picks frames at random. Enterprise buyers and most cyber insurers ask for the film.
2. What Makes an Artifact Evidence
Three properties, and missing any one makes it unusable. It is dated, with the timestamp coming from the system rather than your file name. It is attributable, naming who or what performed the control. And it is complete, representing the whole population rather than a filtered view that happened to look clean.
That third one costs teams the most time. Auditors sample, and a sample is only valid if the population behind it is complete, so any export you hand over gets tested before your control does. Show the filter, the date range, the source system, and who ran it. A screenshot cropped to the rows that support your case is worse than nothing, because now there is a reason to widen the sample.
Sample sizes follow control frequency. These are common practitioner conventions, not a rule written into the Trust Services Criteria, but the shape is consistent enough to plan around.
| Control frequency | Population over 12 months | Typical sample |
|---|---|---|
| Daily or more | 250 to 365+ | 25 to 40 |
| Weekly | 52 | 5 to 8 |
| Monthly | 12 | 2 to 5 |
| Quarterly | 4 | 2 |
| Annually | 1 | 1 |
Read that as a build requirement. A daily control needs roughly forty defensible artifacts spread across the year, produced at the time. You cannot generate those in the final month.
3. Why Green Says Nothing About Day 47
A posture dashboard evaluates current state and overwrites the previous answer. That is exactly right operationally and exactly wrong as a record.
A storage container opened for a debugging session on day 47 and closed on day 52 leaves no trace. Day 200 is green, and so was day 46. The misconfigurations that matter most are often the transient ones, and a tool storing only the latest verdict cannot see them, which also means it cannot tell you whether you have something to disclose.
Retention closes the gap: one dated result per scan, kept for the length of the window. This makes scan cadence a compliance decision, not just an operational one. Four quarterly scans cannot support a sample of forty.
4. Gaps, and the One Thing You Cannot Do
A control failure is not automatically a qualified report. Auditors weigh cause, frequency, detection and remediation. One documented miss with a fix is a footnote. Ten are a pattern.
Missing evidence is the worse problem. A control that cannot be tested cannot be concluded on, so absence is treated as a deviation rather than a neutral blank. A control that ran perfectly all year and left no trace is, for reporting purposes, a control that did not run.
To be unambiguous about the tempting shortcut: you cannot back-fill. Recreating a March export in October and presenting it as contemporaneous is a misrepresentation to your auditor, and it ends engagements rather than delaying them. Disclose the gap, document the cause, remediate, and let the auditor evaluate it. A disclosed gap is survivable.
5. Where Automated Posture Data Helps
Continuous assessment earns its place by producing dated results on a schedule, which gives you population density no manual review will match, and by surfacing drift while the window is still open and you can document the fix.
What it cannot do is cover the human criteria. Onboarding and offboarding, vendor reviews, training, privileged account handling decisions, board oversight and incident exercises live in your HR and ticketing systems. Technical criteria automate well, organisational ones do not, and both halves need a dated trail. Any vendor implying otherwise is selling half an answer. Wider context sits in our guide to cloud compliance frameworks and what CSPM actually does.
What to Actually Do
- Decide the window first. Treat its start date as the day evidence capture must already be running, not the day the project starts.
- Give every control a named artifact, with a frequency, a source system and an owner. A control without a named artifact will not produce one.
- Capture to an archive, not a dashboard. You need a dated file in durable storage, not a tile that recalculates.
- Check log retention against window length. Ninety days will not support a twelve month examination, and this is usually discovered in month eleven.
- Sample yourself at the halfway point. Pick four random dates, ask for the evidence, and see what comes back. It is the cheapest audit rehearsal there is.
- Keep the exception log as you go. Auditors respond far better to a maintained log than to a spotless record with unexplained silence in it.
A control that leaves no dated record is indistinguishable from a control that never ran. That is the whole argument.
Frequently Asked Questions
What counts as evidence for a SOC 2 Type 2 audit?
Any artifact showing that a specific control operated on a specific date inside the window, produced at that time and attributable to a person or system. System reports with the query parameters visible, tickets with approvals and timestamps, job and pipeline logs, signed exports and meeting minutes all qualify. Current configuration presented as though it were historic does not.
How long does the SOC 2 observation window need to be?
There is no minimum in the Trust Services Criteria, but practice has settled on 3 to 12 months. First reports often use 3 months to reach buyers quickly, then move to a 12 month annual cadence. If the period ends well before a customer asks, a bridge letter from management can cover the gap, though it is an assertion rather than audited evidence.
Can I use screenshots as SOC 2 evidence?
Yes, and they get rejected constantly for lacking provenance. A usable screenshot shows the system date and time, enough context to identify the source, the filters applied, and the complete result set rather than a crop. Prefer a scheduled export or log record where one exists, since machine-generated artifacts carry their own timestamps.
Does one failed control mean a qualified SOC 2 report?
No. Isolated failures with a documented cause and fix are normally noted rather than fatal. Repeated failures, or ones revealing a design problem instead of an execution slip, are what push toward a qualified opinion. A hole in the evidence is more dangerous than a failure, because an untestable control cannot be concluded on at all.
Is a CSPM or compliance automation tool enough to pass SOC 2?
Not alone, and the limit is scope rather than quality. These tools cover technical configuration well and can supply dated evidence for a meaningful share of the Common Criteria around access, encryption, logging and change. They cannot evidence hiring and termination, vendor risk reviews, training completion, management oversight or incident exercises. Use the tool as the engine for technical evidence, and build a deliberate trail for every control that turns on a human decision.
