How to Gather Evidence for SOC 2 Type 2: A Practitioner's Guide

The most expensive misconception in SOC 2 compliance is that evidence collection is something you do in the weeks before the auditor arrives. It is not. SOC 2 Type 2 requires evidence that your controls operated across a defined period, typically six to twelve months. Evidence of what happened in month eleven does not prove what happened in months one through ten.

This is the operational reality that separates companies that pass SOC 2 Type 2 cleanly from those that end up with qualified opinions and management letter comments: the former treat evidence collection as a continuous practice, and the latter treat it as a sprint before the audit deadline.

This guide covers what evidence you need for SOC 2 Type 2, how to collect it, how to organize it, and how to verify it before the auditor sees it.

What SOC 2 Type 2 Evidence Must Prove

Under AT-C 205 and the Trust Services Criteria, your evidence must establish two things for each control: first, that the control is suitably designed to address the criteria it maps to; and second, that the control operated effectively throughout the audit period.

Design effectiveness is relatively easy to demonstrate. A policy document, a configuration screenshot, or an architecture diagram can establish that a control exists and is configured as intended. Operating effectiveness is what trips companies up. It requires evidence that the control actually operated on each occasion it was supposed to operate, across the full audit window, not just at the beginning or end of it.

For a control that operates continuously, like automated log monitoring, operating effectiveness evidence looks like log records that span the full audit period, with sampling from the beginning, middle, and end. For a control that operates periodically, like quarterly access reviews, operating effectiveness evidence looks like records from every review cycle within the audit period, with specific dates, reviewers, and dispositions documented for each.

The Four Categories of Evidence

1. Policy and Procedure Documentation

Policies establish what your controls are designed to do. They are necessary but insufficient on their own. An auditor who sees a well-written access control policy will then ask for evidence that the policy was followed. Policy documentation typically includes information security policies, change management procedures, incident response plans, business continuity plans, vendor management policies, and acceptable use policies. These should be version-controlled, with approval dates and designated owners.

2. Configuration Evidence

Configuration evidence establishes how your technical controls are set up. For access controls, this means identity provider configuration exports showing MFA requirements, password policies, and session timeout settings. For network security, this means firewall rule exports, security group configurations, and network segmentation documentation. For endpoint security, this means MDM policy exports and agent deployment records. Configuration evidence should be collected at the start of the audit window and refreshed whenever changes occur. A configuration that was correct at day one may have drifted by month six.

3. Operational Records

Operational records are the primary source of operating effectiveness evidence. They include access review records, change management tickets and approval logs, incident records, vulnerability scan reports, penetration test reports, background check documentation for new hires, security training completion records, and vendor review records. The defining characteristic of a good operational record is that it was created as the control operated, not reconstructed afterward. A retrospective access review created to fill an audit gap is not operational evidence. It is a correction, and auditors can usually tell the difference.

4. Monitoring and Exception Records

Monitoring records demonstrate that your organization actively oversees its controls and responds to exceptions. These include SIEM alerts and resolutions, vulnerability management remediation records showing tickets opened and closed against discovered vulnerabilities, access anomaly investigations, and management reporting on the state of security controls. This category of evidence is the one most commonly absent from companies that have not built a continuous monitoring practice. If your controls operate but nobody reviews the output, you have a CC4 gap regardless of how strong the controls themselves are.

Evidence Requirements by Control Area

Control Area	Typical Evidence	Frequency
Logical access	User access review records, provisioning and deprovisioning tickets, MFA enrollment export	Quarterly reviews; provisioning/deprovisioning on each event
Change management	Change request tickets with approvals, code review records, deployment logs	Per change event
Vulnerability management	Scan reports, remediation tickets, age-of-vulnerability tracking	Monthly scans minimum; quarterly reporting
Incident management	Incident tickets, root cause analyses, customer notification records where applicable	Per incident; quarterly review of incident register
Monitoring and logging	SIEM alert logs, monitoring configuration exports, alert review records	Continuous; monthly or quarterly review evidence
Vendor management	Vendor risk assessments, subservice organization SOC 2 report reviews, contract records	Annual review minimum; on-boarding assessment for new vendors
Human resources security	Background check records, training completion logs, onboarding/offboarding checklists	Per hire/departure; annual training records
Business continuity	BCP/DR plan, test records with outcomes, management approval of plan	Annual test minimum
Physical security	Data center SOC 2 or equivalent, office access logs if applicable, visitor records	Annual vendor report review; ongoing for internal facilities
Risk management	Risk register, risk assessment documentation, treatment plan records	Annual review; continuous updates for material changes

Evidence Repository Design

Where you store evidence matters almost as much as whether you have it. An auditor working through a prepared-by-client (PBC) list should be able to locate any artifact within minutes. A sprawling Google Drive with inconsistently named folders and undated files creates friction that translates into additional requests and extended fieldwork.

A well-designed evidence repository has a consistent folder taxonomy, a naming convention that encodes the control, the period, and the version, and a single authoritative location for each artifact type. Here is an example structure:

The Evidence Index is a spreadsheet that lists every artifact in the repository, maps it to the control and criterion it evidences, and records the collection date and the person who collected it. When the auditor submits a PBC request, the person managing the audit can pull from the index rather than searching through folders. The index itself becomes a piece of evidence that demonstrates the rigor of your evidence management program.

Platform Exports vs. Source Evidence

GRC platform exports have an important role in an evidence program. They provide a consolidated view of control status and make it easy to track what has been collected and what is missing. They should not, however, be the primary or only form of evidence for any control.

A platform that reports access reviews as complete needs to be supplemented by the actual review records: who reviewed what, what they found, and what actions were taken. A platform that reports MFA as enabled needs to be supplemented by a configuration export from your identity provider showing the specific policy settings. A platform that shows vulnerability scans as passing needs to be supplemented by the actual scan reports, including the findings and the remediation records.

The test for any evidence artifact is whether an independent person, with no prior knowledge of your environment, could examine it and determine what control operated, when it operated, who was responsible, and what the outcome was. If any of those elements are missing or unclear, the artifact is incomplete as evidence.

Building a Collection Calendar

The simplest way to ensure evidence is collected continuously across the full audit window is to build a collection calendar before the window opens. Map each control to its frequency, identify the collection date for each evidence artifact, assign an owner, and set reminders. For monthly controls, that is twelve collection events per year. For quarterly controls, it is four. For annual controls, it is one, with a specific due date.

Review the calendar monthly as part of your security operations cadence. Any control where evidence has not been collected on schedule should be escalated immediately. A one-month gap is manageable. A three-month gap starts to look like a pattern. A six-month gap in a twelve-month audit window is an operating effectiveness finding.

SOC 2 Type 2 is not hard because the requirements are complicated. It is hard because it requires twelve months of consistent operational discipline, not four weeks of audit preparation. The companies that treat it as the former consistently produce clean reports. The companies that treat it as the latter consistently wonder why their reports have findings.