SOC 2 Evidence Collection Checklist: What Auditors Actually Request

Most first-time SOC 2 audits encounter delays not because controls are missing, but because evidence is disorganized, incomplete, or inconsistent. Auditors don’t expect perfection—they expect proof that your documented controls actually operate as described.

This checklist provides a tactical, week-by-week evidence collection framework for startups preparing for their first SOC 2 Type I audit. It includes specific screenshots to capture, exports to save, naming conventions to follow, and folder structures that substantially reduce auditor clarification requests. For a complete readiness plan, see our SOC 2 Readiness Checklist for Startups (2026) and SOC 2 System Description Guide.

What Auditors Actually Review (Not What You Think)

SOC 2 auditors do not:

• Perform penetration testing on your infrastructure
• Read your source code line-by-line
• Inspect every employee device
• Test every single control exhaustively

SOC 2 auditors do:

• Verify that documented controls exist and are appropriately designed
• Sample 1–3 instances per control to validate operational consistency
• Cross-reference policies against actual system configurations
• Confirm that exceptions are documented with remediation plans
• Validate that third-party vendors maintain appropriate certifications

Bottom line: Your evidence must demonstrate consistent execution, not perfection.

The 10 Most-Requested Evidence Types

Based on common startup SOC 2 audit patterns, these are the evidence artifacts auditors request in nearly every engagement.

1. Access Management & MFA Enforcement

What auditors ask for:

• Screenshot of MFA enforcement settings in identity provider (Okta, Google Workspace, Azure AD)
• User access list export showing active employees and contractors
• Termination/offboarding checklist with access revocation timestamps

How to collect it:

• Okta: Admin Console → Security → Authentication → MFA Policies (screenshot)
• Google Workspace: Admin Console → Security → 2-Step Verification (screenshot)
• Export user list: Okta → Users → Export CSV; Google Workspace → Directory → Users → Download
• Save as: ACE-001_MFA_Settings.pdf, ACE-002_User_Access_List.csv

2. Change Management & Code Review

What auditors ask for:

• GitHub/GitLab branch protection rules screenshot
• Sample of 3–5 pull requests showing peer review approvals
• Deployment pipeline configuration (GitHub Actions, CircleCI, Vercel)

How to collect it:

• GitHub: Settings → Branches → Branch protection rules (screenshot main/master branch)
• Pull requests: Navigate to 3 recent merged PRs, capture approval timestamps and reviewer names
• Save as: CHG-001_Branch_Protection.pdf, CHG-002_PR_Approval_Samples.pdf

3. Encryption & Data Protection

What auditors ask for:

• Database encryption configuration (AWS RDS, Supabase, MongoDB Atlas)
• TLS/SSL certificate configuration for web application
• Object storage encryption settings (S3 bucket policies)

How to collect it:

• AWS RDS: RDS Console → Databases → Configuration tab → Encryption (export config)
• S3: S3 Console → Bucket → Properties → Default encryption (export config)
• Save as: ENC-001_Database_Encryption.pdf

Note: Export configuration details rather than relying solely on screenshots. Auditors accept exported JSON or PDF configs.

4. Backup & Disaster Recovery

What auditors ask for:

• Automated backup configuration
• Backup retention policy documentation
• Most recent backup restoration test evidence

How to collect it:

• AWS RDS: RDS Console → Backups → Automated backups enabled (export config)
• Restoration test: Document date, method, and outcome of last test restore
• Save as: BKP-001_Backup_Configuration.pdf, BKP-002_Restoration_Test_Log.pdf

5. Incident Response

What auditors ask for:

• Incident response policy document
• Incident escalation procedures
• Sample incident log (even if empty, document “no incidents reported”)

How to collect it:

• Incident response policy: Use your documented policy (PDF)
• Create incident log spreadsheet with columns: Date, Severity, Description, Resolution, Owner
• If no incidents: Document “No security incidents reported during period [date range]”
• Save as: INC-001_Incident_Response_Policy.pdf, INC-002_Incident_Log.xlsx

6. Vendor Management & Subprocessors

What auditors ask for:

• Vendor/subprocessor inventory spreadsheet
• SOC 2 reports or security questionnaires from critical vendors (AWS, Stripe, Okta, etc.)
• Data Processing Addendums (DPAs) with vendors handling customer data

How to collect it:

• Create spreadsheet: Vendor Name, Service Provided, Data Access Level, SOC 2 Status, DPA Signed
• Request SOC 2 reports from AWS, Stripe, Okta, etc.
• Save as: VND-001_Vendor_Inventory.xlsx, VND-002_AWS_SOC2_Report.pdf

7. Security Awareness Training

What auditors ask for:

• Security awareness training policy
• Employee training completion records
• New hire onboarding security checklist

How to collect it:

• Training policy: Use your documented policy (PDF)
• Export completion records from training platform (KnowBe4, Hoxhunt, or internal LMS)
• Save as: TRN-001_Training_Policy.pdf, TRN-002_Training_Records.xlsx

8. Physical Security & Device Management

What auditors ask for:

• Device management policy (MDM enrollment, disk encryption, screen locks)
• MDM console screenshot showing enrolled devices
• Disk encryption verification (FileVault/BitLocker status)

How to collect it:

• MDM console (Jamf, Kandji, Intune): Admin console → Devices → Enrollment status
• For remote-first teams: Document “Physical security controls managed via MDM and device encryption policies”
• Save as: DEV-001_MDM_Enrollment.pdf, DEV-002_Disk_Encryption_Policy.pdf

9. Logging & Monitoring

What auditors ask for:

• Cloud audit log configuration (AWS CloudTrail, GCP Audit Logs)
• Alerting rules for security events
• Log retention settings

How to collect it:

• AWS CloudTrail: CloudTrail Console → Trails → Logging status (export config)
• Alerting: Show alert rules for failed logins, privilege escalation, configuration changes
• Save as: LOG-001_CloudTrail_Configuration.pdf, LOG-002_Security_Alerts.pdf

10. HR & Employee Lifecycle

What auditors ask for:

• Employee handbook with security policies
• Signed security acknowledgment forms
• Background check completion records

How to collect it:

• Employee handbook: PDF with security policy section highlighted
• Acknowledgments: Signed forms from all employees (digital signatures acceptable)
• Background checks: Completion confirmation from Checkr, GoodHire, or provider
• Save as: HRM-001_Employee_Handbook.pdf, HRM-002_Security_Acknowledgments.pdf, HRM-003_Background_Check_Records.xlsx

Evidence Naming Convention (Auditor-Preferred)

Use this standardized format to make evidence instantly scannable:

Format: [PREFIX-XXX]_[Description]_[Date/Period].[ext]

Examples:

• ACE-001_MFA_Settings_2026-01.pdf
• CHG-002_PR_Samples_Q1-2026.pdf
• ENC-001_Database_Encryption.pdf
• VND-001_Vendor_Inventory_Q1-2026.xlsx

Recommended Folder Structure

Organize evidence to mirror AICPA Trust Services Criteria with realistic control prefixes:

Evidence Differences: SOC 2 Type I vs Type II

Area	Type I	Type II
Evidence Timing	Point-in-time	Multi-month observation period
Access Reviews	Current snapshot	Quarterly recurring reviews
Monitoring Evidence	Configuration screenshots	Historical logs & alerts
Change Management	Sample pull requests	Repeated operational consistency
Backup Testing	Configuration proof	Ongoing restoration verification

Evidence Collection Timeline (12-Week Prep)

Manual Collection vs. Automation Platforms

Evidence Type	Manual (Templates)	Vanta/Drata/Secureframe
MFA Settings	Screenshot Okta/Google Workspace console	Auto-captured via API
User Access	Export CSV from Okta/Google Workspace	Auto-synced daily
Branch Protection	Screenshot GitHub settings	Auto-validated
Encryption	Export config from AWS/Supabase console	Auto-detected
Backup Config	Export backup settings	Auto-monitored
PR Approvals	Screenshot 3–5 sample PRs	Auto-sampled
Vendor SOC 2 Reports	Manual collection via NDA	Some auto-fetched

Bottom line: Automation platforms reduce evidence collection time by 60–70%, but cost $8k–$20k/year. Manual collection requires 80–150 hours but costs $0 in software. For bootstrapped startups, the template path is viable if you start early and stay organized.

Common Evidence Mistakes & How to Fix Them

• Evidence quality too low: Blurry or cropped screenshots. Fix: Use full-screen captures, ensure text is readable, include URL bar.
• Missing timestamps or dates: Evidence without visible dates. Fix: Include system clock or add date stamp in filename.
• Inconsistent naming: Files named screenshot1.png. Fix: Use standardized naming convention from day one.
• Evidence from wrong environment: Capturing staging instead of production. Fix: Verify URL and environment before capturing.
• No exception documentation: Controls not fully implemented with no explanation. Fix: Create exception log with rationale and remediation timeline.

Evidence Tracker Template

Create a master evidence tracker with these columns to monitor collection progress and auditor status:

Control ID	Control Description	Evidence File Name	Date Collected	Auditor Status	Notes
CC6.1	Logical Access Controls	ACE-001_MFA_Settings.pdf	2026-01-15	Approved	—
CC7.1	System Operations	CHG-002_PR_Samples.pdf	2026-01-18	Pending Review	Need 2 more samples
CC8.1	Change Management	CHG-001_Branch_Protection.pdf	2026-01-20	Approved	—

Platform-Specific Evidence Guides

Deep-dive guides for your specific tech stack:

Frequently Asked Questions