A SOC 2 report is only as strong as the evidence behind it. An auditor doesn’t take a company’s word that access reviews happen quarterly, that terminated employees lose access promptly, or that vulnerabilities get patched on schedule — they want proof, and proof that holds up across an entire observation period, not a folder of screenshots assembled the week before fieldwork begins. What counts as evidence, when to collect it, and how to organize it is the difference between an audit that closes smoothly and one that surfaces exception after exception.
What Counts as Evidence
Evidence is anything that lets an auditor independently verify a control existed and operated the way it was described — proof it happened, not a policy saying it should. SOC 2 evidence falls into two broad categories, and the difference matters more than most teams realize going into their first audit.
System-generated evidence
System-generated evidence comes directly out of a tool: audit logs, configuration exports, ticket records, access lists from an identity provider, vulnerability scan reports, CI/CD deployment logs. It’s timestamped automatically, hard to alter after the fact, and reflects what actually happened rather than what someone remembers. Auditors trust it more — a log entry showing an access request was approved and provisioned at a specific time is a different order of proof than someone recalling that “we usually handle it that way.”
Manual and attestation evidence
Manual evidence includes meeting notes, sign-offs, completed checklists, and screenshots. It still has a place — a quarterly access review may genuinely only ever produce minutes and an approval — but it’s weaker. It depends on a person documenting it consistently across the whole period. Screenshots are the clearest trap: one screenshot proves a setting was on the day someone checked it. It says nothing about the other months of a twelve-month period.
- System-generated: access logs, identity provider exports, ticketing system records, vulnerability scan results, CI/CD deployment logs, configuration snapshots
- Manual/attestation: signed policies, meeting minutes, completed review checklists, training records, vendor questionnaires
A screenshot can be staged for the day it’s taken. A log entry, by contrast, is generated by the system itself at the moment the event happened, independent of anyone trying to look compliant. That’s not a reason to abandon manual evidence — some controls only ever produce it — but wherever a system can generate the proof automatically, that’s the evidence an auditor trusts first.
Type I vs Type II Evidence
The kind of evidence an auditor asks for depends on which report is being pursued, and conflating the two is a common planning mistake.
Type I: a single point in time
A Type I report tests whether controls are suitably designed as of one specific date. The evidence supporting it is, by definition, a snapshot: the current MFA configuration, today’s access list, the policy version in effect right now. It only has to be true on that one day.
Type II: sampling from the population
A Type II report tests whether those same controls operated effectively across an observation period, typically three to twelve months. This is where teams most often misjudge what’s being asked: the auditor doesn’t want one example of the control working. They sample from the population of everything that happened during the period and expect evidence for whichever items land in the sample. If the control governs access provisioning, the population is every access change made during the period; if it governs deployments, the population is every deploy in the window.
The practical consequence is retention. A single screenshot from month one proves nothing about month seven. Evidence has to exist for the entire period, organized so that whichever slice the auditor samples, the proof is already there.
Population Completeness
Before an auditor selects a sample, they check something more basic: is the population itself complete? Sampling only means something if it’s drawn from every event that should be in scope. If “all terminations this period” is missing three departures handled informally outside the ticketing system, any sample from that incomplete list is unreliable — no matter how clean the evidence looks for what did make it in.
This is why auditors often ask for a system’s full export rather than a pre-filtered list. They want the population itself — the raw count of terminations, access changes, or deployments — reconciled against an independent source, such as HR records, before trusting that a sample drawn from it means anything.
What breaks population completeness
- Events handled outside the system of record — an access change made directly by an admin rather than through the approval workflow
- Manual processes that don’t consistently generate a record
- Multiple systems tracking the same population differently, with no reconciliation between them
- Historical data that wasn’t retained long enough to cover the full observation period
If three access changes never made it into the ticketing system the auditor samples from, the audit can look clean and still be wrong — those three were never eligible to be selected. An incomplete population isn’t a minor technicality; it’s the kind of gap that becomes a documented exception even when every piece of evidence the auditor did see was in order.
Continuous Capture vs the Pre-Audit Scramble
Two very different collection strategies produce two very different audits, and the difference is visible from the first evidence request.
The pre-audit scramble
The scramble looks like this: a few weeks before fieldwork, someone assembles a spreadsheet, chases down screenshots, and reconstructs after the fact what should have been captured as it happened. Reconstructed evidence is weaker on its face — it’s produced to satisfy the audit rather than generated as a byproduct of the work — and it’s far more likely to have gaps a population-completeness check will expose.
Continuous capture
The alternative treats evidence collection as a background process running all year: logging tools that export access changes automatically, ticketing systems that timestamp every change request, scan results landing in a central repository on a schedule, evidence tagged to the control it supports as it’s produced. By the time the observation period closes, the evidence already exists, ready to be sampled from — nobody has to remember anything.
The SolarWinds compromise, disclosed in late 2020, is a reminder of what evidence is meant to prove. Malicious code was inserted into a routine software update and distributed to thousands of customers, and the intrusion went undetected for months. A one-time check of the build process on almost any single day might have looked fine; the failure was that a control needing to operate correctly every day, continuously, didn’t. That’s the exact gap a Type II observation period — and evidence collected continuously across it — is built to catch, and a pre-audit scramble never could.
The Four Auditor Procedures
Auditors don’t just read the evidence handed to them — they test it using a defined set of procedures, and knowing which one applies to a control clarifies exactly what needs to be ready.
Inquiry
Asking someone how a control works. It’s the weakest procedure alone, since it relies entirely on what a person says, but it’s often the starting point — confirming the described process before checking whether it’s actually true.
Observation
Watching a control happen in real time — sitting in on an access review, or watching an engineer walk through a deployment approval. It confirms the process happens as described, but only for the instance observed.
Inspection
Examining documents or system records after the fact — the access list, the signed policy, the ticket history. This is where most system-generated and manual evidence gets used, and it’s tied most closely to population sampling: the auditor inspects the records for each item selected from the sample.
Re-performance
Independently redoing the control to confirm it produces the expected result — re-running a reconciliation, or attempting to access a system with revoked credentials to confirm access was actually removed. It’s the most rigorous procedure, because it doesn’t rely on any existing record; the auditor generates their own proof.
Common Evidence Gaps and Organizing by Control
Most exceptions in a SOC 2 report trace back to a small, repeatable set of gaps, avoidable with better organization rather than more effort.
Where gaps usually appear
- A ticket exists but is missing the approval step the control actually requires
- Evidence covers most of the period but has an unexplained gap of a few weeks
- The same control is documented differently by different teams, with no single source of truth
- Evidence was rotated out of a log retention window before the observation period closed
- A control changed partway through the period — a new tool, a new approver — and the evidence wasn’t updated to reflect it
Any one of these becomes a documented exception in the final report — not necessarily fatal, but exactly the kind of finding a well-organized evidence program is built to avoid.
Organizing evidence by control
The fix is structural: map every control to the specific evidence that supports it before the observation period starts, assign an owner, and set a retention window covering the full audit period plus a margin. A control mapped this way makes the audit close mechanical — evidence already sits where the control says it should, tagged and dated, rather than being hunted down once the request list arrives.
| Control Area | Example Evidence | How to Capture It |
|---|---|---|
| Access control | Access lists, provisioning/deprovisioning tickets, MFA configuration exports | Scheduled automated exports from the identity provider |
| Change management | Deployment logs, pull request approvals, change tickets | CI/CD pipeline logs plus ticketing system exports |
| Vulnerability management | Scan reports, remediation tickets, patch logs | Scheduled scanner exports tied to ticket closure |
| Incident response | Incident tickets, post-incident review notes, timelines | Ticketing system export plus signed review notes |
| Backup and recovery | Backup job logs, restore test records | Automated job logs plus periodic manual restore sign-off |
| Vendor management | Vendor risk assessments, signed questionnaires | Central vendor register updated at onboarding and renewal |
Final Thought
A SOC 2 report rarely fails because a control was badly designed. It fails far more often because the evidence behind it was thin, inconsistent, or assembled after the fact. Auditors aren’t asking a company to prove it’s perfect — they want proof that a defined population of events, across a real period, holds up under sampling. That’s a different exercise than producing a folder of screenshots the week before fieldwork begins.
The test: pick any control in scope and ask whether the evidence for it already exists, organized and dated, for the full period — or whether producing it would mean reconstructing it from memory. If it’s the latter, that’s the gap to close before the observation period starts, not during audit week.
Frequently Asked Questions
A Type I only requires evidence of controls as they exist on a single date, like a current configuration or a current access list. A Type II requires evidence across the entire observation period, typically three to twelve months, because the auditor samples from the full population of events during that window rather than checking a single moment.
Sampling from a population is how the auditor confirms a control operated consistently rather than just once. If the control governs access changes, the population is every access change during the period; the auditor selects a sample from that full list and expects evidence for each item selected — which only works if the population itself is complete.
A gap — missing approvals, an unexplained stretch with no records — typically becomes a documented exception in the final report. It doesn’t necessarily fail the audit, but it is exactly the kind of finding that continuous, organized evidence collection is meant to prevent.
System-generated evidence — logs, ticket exports, configuration snapshots, scan results — is produced automatically by a tool, timestamped, and difficult to alter after the fact. Manual or attestation evidence, like meeting notes or sign-offs, depends on a person documenting it consistently and is inherently weaker, though some controls only ever produce this type.
Inquiry (asking how a control works), observation (watching it happen in real time), inspection (examining records after the fact), and re-performance (independently redoing the control to confirm the result). Inspection is where most collected evidence gets used, and it’s the procedure most tied to sampling from a population.