SOC 2 Evidence Collection: What Auditors Actually Need

Four Types of Evidence Auditors Use

SSAE 18 — the attestation standard underlying SOC 2 — recognizes four types of evidence-gathering procedures. Inquiry involves the auditor asking questions of your personnel and recording the responses. Observation means the auditor watches a process happen in real time. Inspection means the auditor reviews a document, record, or configuration. Re-performance means the auditor independently executes a procedure and verifies the result matches what you documented.

Inquiry alone is never sufficient for a SOC 2 opinion — it must be corroborated by other evidence types. In practice, this means every control needs at least one document, record, or configuration screenshot to support it. For high-risk controls (like privileged access management or change management approvals), auditors typically use all four evidence types.

The weight auditors give each type varies by risk. For CC8.1 (change management), re-performance is common: the auditor selects a sample of production deployments and independently checks that each went through the defined approval and testing process. For CC1.2 (board oversight), inquiry and inspection of board meeting minutes may be sufficient.

Evidence Required by Control Area

CC6 (Logical Access): user access lists from your identity provider (Okta, Google Workspace) showing all active users and their roles; MFA enrollment reports; records of access provisioning and de-provisioning tied to onboarding/offboarding events; quarterly access review records with approver signatures and timestamps; privileged access management logs showing admin session recordings or approval workflows.

CC8 (Change Management): pull request records with reviewer approvals; CI/CD pipeline logs showing automated tests ran and passed before deployment; deployment logs mapping commit SHAs to production deployments; change request tickets for infrastructure changes with risk assessment and approval; records of any emergency changes and the post-change review.

CC7 (System Operations): vulnerability scan results and remediation tracking; penetration test report and remediation evidence; security monitoring alerts with investigation records; incident log with detection time, response time, and resolution for each incident during the observation period.

CC3 (Risk Assessment): completed risk register with identified risks, likelihood/impact scores, risk owners, and treatment decisions; evidence that the risk assessment was reviewed and updated at least annually; meeting minutes or approval records showing leadership review of the risk register.

CC9 (Vendor Management): vendor inventory listing all critical vendors; completed vendor risk assessments for each vendor (typically reviewing their SOC 2 report or security questionnaire response); records of vendor onboarding security review; vendor contract clauses covering security and data protection.

How to Organize Evidence Before the Audit

The standard approach is to organize evidence by criterion ID. Create a folder structure where each folder is named after a criterion (CC6.1, CC6.2, CC8.1, etc.) and contains all evidence supporting that criterion. Within each folder, use descriptive filenames that include the date and the source system: "2025-10-01_okta-user-access-list.pdf" is far more useful to an auditor than "export (2).csv".

For Type II audits, you need evidence from multiple points in the observation period, not just the most recent date. For an access review criterion, you need records from each quarterly review cycle. A common mistake is providing only the most recent access review and omitting earlier ones — which causes the auditor to ask for them separately, adding days to fieldwork.

Build your evidence index before the audit begins: a spreadsheet mapping each criterion to the evidence files that support it, with file names, dates, and a brief description of what each file shows. This gives the auditor a navigation map and reduces the number of follow-up requests.

Continuous Evidence Collection vs Pre-Audit Scramble

Most companies that run their first SOC 2 manually experience what compliance teams call "the pre-audit scramble" — the two weeks before fieldwork begins where everyone is frantically exporting spreadsheets, taking screenshots, and trying to reconstruct records from memory. This approach produces evidence that is incomplete, poorly organized, and riddled with gaps that trigger extensive auditor follow-up.

The alternative is continuous collection: setting up systems that automatically capture evidence as controls operate throughout the observation period. Every access review is recorded in a structured format with timestamps. Every change approval is logged with the approver's identity. Every vulnerability scan result is archived. When the audit begins, the evidence library is already fully populated.

Continuous collection also protects you against the scenario where a control failed during the observation period and you only discover it when the auditor asks for evidence. Discovering a gap 6 months after it occurred, with the observation period almost closed, leaves you no time to remediate.

Automating Evidence Collection

Modern compliance platforms integrate directly with the systems that generate your evidence. An AWS integration automatically retrieves: CloudTrail logs, IAM user lists, S3 bucket policy configurations, GuardDuty finding reports, and AWS Config compliance snapshots. A GitHub integration retrieves: branch protection settings, pull request approval records, and deployment workflow logs. An Okta integration retrieves: MFA enrollment status for all users, group membership lists, and application access logs.

These integrations run on a schedule — typically daily or weekly — and store evidence in a structured, time-stamped repository. When an auditor requests evidence for a specific criterion and time period, the platform generates a pre-organized evidence package in seconds rather than hours.

The practical impact: companies using compliance automation platforms typically spend 5–15 hours preparing evidence for fieldwork. Companies running manual processes typically spend 40–80 hours on the same task. Multiply by $150/hour of internal time cost and the ROI calculation is straightforward.

Common Evidence Gaps That Cause Exceptions

Missing access reviews: the most common exception. CC6.2 and CC6.3 require periodic review of user access. Many companies implement access reviews but don't document the results — manager approvals happen in Slack or email and are not preserved in a retrievable record. Use a formal access review tool or platform that creates a timestamped audit trail.

Incomplete change management records: CC8.1 requires that all changes to systems in scope go through a defined change management process. Companies often handle emergency changes informally — a direct push to production to fix a critical bug — without creating a ticket or PR. Each undocumented emergency change is a potential exception. Create an emergency change procedure that still produces a record, even if approval is retroactive.

Vendor risk assessment gaps: CC9.2 requires assessing the security of critical vendors. Many companies maintain a vendor list but have never formally assessed the security of vendors with access to customer data. Missing vendor assessments for vendors like your cloud hosting provider, payment processor, or HR system are common audit findings. Your vendors' own SOC 2 reports can serve as the assessment basis — download and archive them annually.