The SOC 2 Evidence Collection Playbook

The Evidence Problem

Three weeks into the observation period, Priya got her first evidence request from the audit firm. It was a list of 47 items. Some were simple: "Provide your information security policy." Others were more complex: "Provide evidence of user access reviews conducted during the observation period, including the reviewer name, date, and list of users reviewed for each system."

She spent an entire weekend collecting evidence for that first request. By the third request, she'd cut it to 4 hours. By the sixth, it was 45 minutes. The difference: a system.

The Three Types of Evidence

Before we get into the system, understand what you're collecting.

Type 1: Policy and Procedure Documents

These are your written policies. They're static — you write them once, keep them updated, and provide them when requested.

Examples: Information security policy, access control policy, incident response plan, vulnerability management policy, change management policy, acceptable use policy.

Format requirement: Policies must be dated, have an owner, and be approved. A Google Doc with "last edited by Rishabh" and no approval date doesn't cut it. Auditors want a document with a version number, approval date, and the name of who approved it.

Type 2: Configuration Screenshots

These are point-in-time captures of system settings proving that controls are configured correctly.

Examples: Screenshot of Okta showing MFA enforcement policy, AWS console showing RDS encryption enabled, GitHub showing branch protection rules configured, Kandji showing MDM enrollment.

The key: Screenshots must show the date or be timestamped. Take them as late as possible during the audit period so they're clearly within scope.

Type 3: Operating Evidence

This is the hardest category — proof that a control actually operated during the observation period. Not just that it exists, but that it was used.

Examples: Access review completion report from a specific date, completed offboarding checklists, vulnerability scan reports with dates, incident tickets showing response timeline, change management tickets showing approval workflow.

The key: Every piece of operating evidence needs a clear date and shows a human doing something. "We do quarterly access reviews" is a policy. A signed, dated quarterly access review report showing the reviewer, the date, and the list of users reviewed — that's operating evidence.

The Filing System

Orion used a Google Drive structure that mapped directly to the SOC 2 control framework. Here's the top-level structure:

📁 SOC 2 Evidence (2024-2025)
├── 📁 00 - Policies and Procedures
│   ├── Information Security Policy v2.1.pdf
│   ├── Access Control Policy v1.3.pdf
│   ├── Incident Response Plan v2.0.pdf
│   └── ... (all policies)
│
├── 📁 CC1 - Control Environment
│   ├── Security RACI Matrix.pdf
│   ├── Organizational Chart.pdf
│   └── Board Resolution - Security Governance.pdf
│
├── 📁 CC6 - Logical Access
│   ├── 📁 CC6.1 - Infrastructure Security
│   │   ├── AWS VPC Architecture Diagram.pdf
│   │   ├── RDS Encryption Screenshot 2024-11-01.png
│   │   └── TLS Certificate AWS ACM 2024-11-01.png
│   ├── 📁 CC6.2 - Access Provisioning
│   │   ├── Access Request Template.pdf
│   │   ├── Sample Ticket - John Access Request Oct 2024.png
│   │   └── Sample Ticket - Sarah Access Request Dec 2024.png
│   ├── 📁 CC6.3 - Access Removal
│   │   ├── Offboarding Checklist Template.pdf
│   │   ├── Offboarding - James N - 2024-10-15.pdf
│   │   └── Offboarding - Maria K - 2024-12-02.pdf
│   └── 📁 CC6.7 - Privileged Access
│       ├── Admin Account List 2024-10-01.xlsx
│       ├── Admin Account List 2024-12-15.xlsx
│       └── Privileged Access Review Q4 2024.pdf
│
├── 📁 CC7 - System Operations
│   ├── 📁 CC7.1 - Vulnerability Management
│   │   ├── Vulnerability Scan Report October 2024.pdf
│   │   └── Vulnerability Scan Report December 2024.pdf
│   └── 📁 CC7.3 - Incident Response
│       ├── Incident Response Plan v2.0.pdf
│       └── IR Tabletop Exercise - November 2024.pdf
│
└── [Similar structure for CC8, CC9, A1]

The key principle: Every file name includes a date. "RDS Encryption Screenshot" is useless. "RDS Encryption Screenshot 2024-11-01.png" tells the auditor exactly when it was taken.

The Evidence Request Process

When auditors send evidence requests, they typically use a format like:

"Please provide evidence of the quarterly user access review for the period October 1, 2024 to December 31, 2024, including the name of the reviewer, systems reviewed, date completed, and list of users reviewed."

With Orion's filing system, responding looked like this:

1. Open the CC6 → CC6.7 folder
2. Find the Q4 2024 access review file
3. Upload to the audit portal

5 minutes. Not a weekend.

The 8 Most Commonly Requested Evidence Items

In every SOC 2 audit I've been involved in, these eight items are almost always requested. Have them ready before the auditor asks:

1. All in-scope policies (version-controlled, approved, dated)
2. User access list for all in-scope systems (point-in-time, during observation period)
3. Terminated employee list with offboarding evidence (for employees who left during observation period)
4. Quarterly access reviews (all cycles completed during observation period)
5. Vulnerability scan reports (every scan during the observation period, with remediation tracking)
6. Change management tickets (sample of production changes showing approval workflow)
7. Incident tickets (all security incidents logged during the observation period)
8. Vendor SOC 2 reports for your key subservice organizations (AWS, Okta, etc.)

The Evidence Quality Test

Before submitting any evidence, ask yourself:

• Date: Does this evidence clearly show it was produced during the observation period?
• Actor: Does this evidence show a specific person (not just "the system") performing the control?
• Completeness: Does this evidence show the full picture, not just the start of a process?
• Format: Is it clearly legible and in a format the auditor can review without asking for clarification?

If you answer no to any of these, the auditor will follow up. Every follow-up adds time and creates uncertainty.

What Comes Next

With your evidence system in place, let's address one of the most commonly underestimated parts of SOC 2: vendor risk management. Most companies have dozens of SaaS tools. Which ones matter for your audit? What evidence do you need? We cover it next.