SOC 2 Evidence Collection Best Practices

SOC 2 evidence falls into three categories. Each requires a different collection strategy:

1. Continuous evidence: System-generated, automatic, ongoing. Examples: audit logs, infrastructure-as-code commits, ticketing system records, vulnerability scan reports, deploy approvals.
2. Periodic evidence: Scheduled human-driven activities. Examples: quarterly access reviews, annual policy attestations, monthly vulnerability triage, weekly backup tests.
3. Event-driven evidence: Generated when specific events occur. Examples: incident response tickets, change approvals, exception logs, security alerts.

Map every control to its primary evidence category. Continuous evidence is the easiest to collect (automatic) but requires good logging. Periodic evidence is the most often missed because people forget the scheduled activity. Event-driven evidence requires good ticketing discipline.

Reference the documentation module for evidence templates and audit-ready writeups.

Automation prevents the worst evidence problem: missing evidence because someone forgot to capture it. Prioritize automation in this order:

1. Access provisioning and reviews: Identity provider audit logs, access matrix reports, automated review workflows
2. Change management: Git commit history, PR approvals, deploy logs from CI/CD pipelines
3. Vulnerability management: Scanner outputs, ticketing system tickets, remediation tracking
4. Monitoring and alerting: SIEM logs, alert tickets, on-call rotations
5. Backup and recovery: Backup job logs, restoration test results, RTO/RPO tracking

Automation does not mean you need a GRC platform. It means evidence is captured by the system that performs the activity, not by humans taking screenshots. A monthly access review report generated by your IdP is automated evidence. A spreadsheet someone fills out manually is not.

For controls that genuinely require human judgment (e.g., access review approvals, exception decisions), build ticketing workflows so the human action is captured automatically with timestamps, approvers, and rationale.

Evidence with bad names and bad organization wastes audit time. Auditors should be able to find any control's evidence within 60 seconds of being asked.

Naming convention that scales:

YYYY-MM-DD_ControlID_BriefDescription.pdf
2025-04-30_CC6.1_Q1-Access-Review-Production-Team.pdf

Folder structure that scales:

• By Trust Service Criterion: /Security/CC6/CC6.1/, /Availability/A1.2/, etc.
• By time period within criterion: 2025-Q1/, 2025-Q2/, etc.
• By evidence type: continuous/, periodic/, events/

The ideal: one folder per control, with sub-folders by quarter, with evidence named by the convention above. Auditors love this structure because it matches how they sample. "Show me the Q2 access reviews for CC6.1" navigates to one folder.

Evidence retention rules:

• Audit period plus three years: Standard SOC 2 retention. Auditors may sample beyond the current period for trending.
• Tamper-evident storage: Logs and audit trails should be in storage that prevents modification. Object storage with object lock, or write-once log retention systems.
• Access controls: The evidence repository itself is in scope. It needs the same access controls as production: MFA, RBAC, audit logging.
• Backup and disaster recovery: If your evidence is destroyed, you fail your audit. Back it up.

Many companies underestimate the access control requirement. The evidence repository contains your security controls in detail. Treat it as sensitive infrastructure.

The most common evidence collection failures, and how to prevent each:

• Screenshots without dates: A configuration screenshot is useless without a visible timestamp showing when it was captured. Use system clock visible in screenshot, or capture configuration as code (terraform plan output) instead.
• Evidence in chat threads: Slack messages and Microsoft Teams chats are not durable evidence. They get archived, deleted, or become unsearchable. Move evidence to ticketing systems and document repositories.
• Reactive collection during fieldwork: Trying to find evidence for the past 12 months during fieldwork is the worst-case scenario. Collect continuously.
• Different formats for same control: A monthly vulnerability scan that is a PDF in March, a screenshot in April, and a CSV in May confuses auditors. Standardize the output format.
• No mapping to controls: Evidence that exists but is not tagged to a specific control takes time to interpret. Tag at collection time.

Build the evidence pipeline once and refine it. Each audit cycle should be easier than the last as the pipeline matures.