SOC 2 Compliance Checklist: From Zero to Audit-Ready
A practical SOC 2 readiness checklist covering all five Trust Service Criteria. Learn what controls to implement, how to gather evidence, and how to prepare for a Type 1 or Type 2 audit.
SOC 2 (System and Organization Controls 2) is the most common security certification required by US enterprise customers. If you're selling B2B SaaS, you'll eventually be asked: "Do you have a SOC 2 report?"
Getting there requires implementing specific controls and demonstrating they work over time. This checklist walks through what you need for each Trust Service Criterion.
Understanding SOC 2 Structure
A SOC 2 audit evaluates your controls against the Trust Service Criteria (TSC) defined by the AICPA:
- Security (CC) — Required for all SOC 2 reports
- Availability (A) — Optional; system uptime and performance
- Processing Integrity (PI) — Optional; processing is complete and accurate
- Confidentiality (C) — Optional; protection of confidential information
- Privacy (P) — Optional; collection and use of personal information
Most companies pursue Security + Availability. Security alone is the minimum.
Security Criterion (CC) — Required
The Security criterion has the most controls. They're organized into 9 categories:
CC1: Control Environment (Governance)
□ Information security policy written, approved by leadership, and reviewed annually
□ Organizational chart defines security responsibilities
□ Code of conduct / acceptable use policy
□ Background checks for employees with access to sensitive systems
□ Security awareness training completed by all employees (annual)
□ Risk assessment process documented and performed annually
□ Internal communication of security responsibilities (onboarding includes security training)
CC2: Communication and Information
□ Security policies communicated to all personnel
□ Relevant external information (threat intelligence, vendor alerts) reviewed
□ Data classification policy: defines public, internal, confidential, restricted
□ Asset inventory maintained (systems, software, data)
□ Vendor/third-party management program
CC3: Risk Assessment
□ Annual risk assessment covering all system components
□ Risk register documenting identified risks, likelihood, impact, treatment
□ Risks reviewed and updated when significant changes occur
□ Business continuity risk considered
□ Third-party risks assessed
CC4: Monitoring Activities
□ Security monitoring tools deployed (SIEM, IDS/IPS)
□ Continuous monitoring of systems (uptime, errors, security events)
□ Log review process documented and performed
□ Anomaly alerts configured with response procedures
□ Vulnerability scanning (internal and external) performed regularly
□ Penetration testing conducted annually
□ Security incidents tracked and reviewed
□ Internal audit or review of control effectiveness
CC5: Control Activities (Policies and Procedures)
□ Policies and procedures written for each control area
□ Change management process: all changes tested and approved before production
□ Software development lifecycle (SDLC) with security review stage
□ Incident response plan documented and tested
□ Business continuity plan and disaster recovery plan documented
CC6: Logical and Physical Access
□ User access requires approval (documented request and approval process)
□ Unique user IDs — no shared accounts
□ MFA enforced for all users accessing production systems
□ Principle of least privilege — users have only the access they need
□ Access reviews: quarterly for privileged accounts, annually for all
□ Access revoked within 24 hours of termination
□ Remote access secured (VPN/ZTNA with MFA)
□ Passwords: minimum length 12 chars, complexity, not reused
□ Physical access to data centers controlled (badge access, visitor logs)
□ Encryption at rest for sensitive data
□ Encryption in transit (TLS 1.2+) for all sensitive data
□ Cryptographic key management process
CC7: System Operations
□ Vulnerability management: critical patches applied within 30 days
□ Anti-malware on endpoints
□ Incident detection: IDS/SIEM configured and monitored
□ Security incidents documented, classified, and responded to
□ Problem management: recurring issues tracked to root cause
□ Capacity planning: monitor resource utilization
□ Backup and recovery tested (restore tested at least annually)
CC8: Change Management
□ Formal change management process
□ Changes tested in non-production before production
□ Changes peer-reviewed (code review)
□ Emergency change process documented
□ Rollback procedure for failed changes
□ Patch management policy
□ Dependency updates tracked and applied
CC9: Risk Mitigation
□ Risk treatment plan for identified risks
□ Insurance (cyber liability) in place
□ Vendor risk management: security reviews of key vendors
□ Business continuity: critical functions can continue during disruption
□ Data backup: RPO and RTO defined and tested
Availability Criterion (A) — Optional
□ Uptime commitment defined (e.g., 99.9% SLA)
□ System availability monitored and measured
□ Status page for users (status.yourdomain.com)
□ Incident communication process during outages
□ Redundancy for critical components (multi-AZ, load balancing)
□ Auto-scaling for unexpected traffic
□ DDoS protection in place
□ Database failover tested
□ Backup tested for successful restore within RTO
□ Disaster recovery plan tested annually
Confidentiality Criterion (C) — Optional
□ Confidential data identified and classified
□ Access to confidential data restricted to authorized personnel
□ Confidential data encrypted at rest
□ Confidential data not logged unnecessarily
□ NDAs in place with employees and contractors
□ Data destruction procedure when no longer needed
□ Confidential data transmission only over secure channels
Evidence Collection: What Auditors Will Ask For
For each control, auditors require evidence that the control exists and works. Start collecting evidence from day 1:
| Control | Evidence Examples |
|---|---|
| Security training | Training completion records, dates, employee list |
| Access reviews | Quarterly spreadsheet review with approvals, exported from IdP |
| Vulnerability scans | Scan reports from ShipSafer, Qualys, Tenable with dates |
| Patch management | Ticket history showing patches applied with timestamps |
| Incident response | Incident tickets with timestamps, resolution notes |
| Change management | Pull requests with reviewer approvals, deployment logs |
| Backup testing | Screenshot of successful restore test with date |
| Penetration test | Pentest report from the audit period |
| Background checks | HR confirmation (not the actual results — auditors don't need to see these) |
Type 1 vs Type 2: Which to Start With
SOC 2 Type 1 — Point-in-time: "Your controls are suitably designed" as of the audit date. Faster (6–12 weeks) but less valuable to buyers.
SOC 2 Type 2 — Period-of-time: "Your controls operated effectively for X months." 6–12 month observation period required. This is what most enterprise buyers want.
Recommendation: Go straight to Type 2. Type 1 is not universally accepted and you'll need Type 2 within 1–2 years anyway. The extra time to get Type 2 is worth it.
Timeline to SOC 2 Type 2
Month 1–2: Gap assessment — identify missing controls
Month 3–4: Implement controls and document policies
Month 5: Readiness assessment (internal or with auditor)
Month 6–11: Observation period — controls in operation
Month 12: Audit fieldwork (auditor reviews evidence)
Month 13: Receive and review draft report
Month 14: Receive final SOC 2 Type 2 report
Using a Compliance Platform
Tools like Vanta, Drata, Secureframe, and Tugboat Logic:
- Connect to your systems via APIs (AWS, GitHub, Okta, etc.)
- Automatically collect evidence (IAM reviews, vulnerability scans, training records)
- Map your controls to TSC requirements
- Generate pre-built policy templates
- Coordinate with auditors
They significantly reduce the manual work of evidence collection. For a company pursuing SOC 2 for the first time, a compliance platform typically saves 200–400 hours of engineering and operations time.