SOC 2 Evidence Collection Checklist
A practical SOC 2 evidence checklist by control area — access, change management, monitoring, vendor risk — with concrete artifact examples auditors accept.
SOC 2 comes down to one thing: evidence that your controls are designed well and operating effectively. The audit goes faster — and cheaper — when that evidence is organized by control area, source-linked, timestamped, and covers the full audit period. Use this checklist to get ahead of the request list.
What evidence does a SOC 2 audit require?
| Control area | Example evidence auditors accept |
|---|---|
| Access control | User access lists, periodic access reviews, MFA configuration, role definitions |
| Change management | Pull-request approvals, CI/CD logs, deployment records |
| Vulnerability management | Scan results, penetration test report, remediation tickets |
| Monitoring | Alerting configuration, on-call/incident records, log retention |
| Vendor risk | Subprocessor list, vendor security reviews, DPAs |
| HR / personnel | Onboarding/offboarding tickets, background checks, security training |
| Policies | Information security, incident response, BCP/DR, acceptable use |
Type I vs Type II evidence
Type I shows controls are designed correctly at a single point in time. Type II shows they operated effectively across a period — typically 3 to 12 months — so you need recurring samples: multiple access reviews, several change approvals, ongoing monitoring evidence spread across the window, not a single snapshot.
How a penetration test fits in
A penetration test is the clearest evidence for the security-testing and vulnerability-management controls. Auditors want a scoped report, validated findings with severities, remediation status, and ideally a retest confirming critical/high issues were fixed. See do you need a pen test for SOC 2?
Make evidence collection repeatable
The teams that breeze through SOC 2 treat evidence as an ongoing operation, not a fire drill — collecting, structuring, and refreshing artifacts continuously. That is exactly what the AssuranceOps evidence operations workflow automates.
Ready to test your own systems? Request a security assessment or explore Security Assurance packages.
Frequently asked questions
- What evidence is needed for a SOC 2 audit?
- SOC 2 evidence spans access control (user lists, access reviews, MFA configs), change management (PR approvals, CI/CD logs), system monitoring and alerting, vulnerability management and penetration test reports, vendor risk reviews, HR onboarding/offboarding, and policies. Each should be source-linked, timestamped, and cover the audit period.
- What is the difference between SOC 2 Type I and Type II evidence?
- Type I evidence shows controls are designed correctly at a point in time. Type II evidence shows controls operated effectively across a period (often 3–12 months), so it requires recurring samples — for example multiple access reviews or change approvals throughout the window.
- How is a penetration test used as SOC 2 evidence?
- A penetration test report demonstrates the vulnerability management and security testing controls. Auditors look for a scoped report, validated findings, remediation status, and ideally a retest confirming critical and high issues were resolved.
Prove your systems are ready.
Human-validated security assurance with an audit-ready evidence pack.
Request an assessmentRelated reading
- Penetration Test vs Vulnerability Scan: What’s the Difference?
Scans are automated and cheap; pen tests are human-validated and prove real risk. When to use each — and what auditors and customers actually expect.
- How Much Does a Penetration Test Cost?
What a pen test actually costs in 2026, the factors that move the price, and how to scope an assessment so you don’t overpay or under-test.
- Securing LLM and RAG Applications
LLM and RAG apps introduce risks traditional pen tests miss. The top AI-specific threats and a concrete checklist to test and mitigate them.