SOC 2 Checklist for Startups: Everything You Need Before Your Audit

What SOC 2 actually requires

SOC 2 is built around five Trust Service Criteria (TSC). Most startups only need to cover Security (CC series) for their first audit. Availability, Confidentiality, Processing Integrity, and Privacy are optional — include them only if your customers require them.

This checklist covers everything you need for a SOC 2 Type II audit. Type I is simpler — it's a point-in-time assessment, not a 6-12 month observation period.

Before you start: what auditors actually look for

Auditors aren't trying to fail you. They're trying to verify that your controls were consistently in place during the observation period. The three things that kill audits:

1. Evidence that exists but isn't organized or timestamped
2. Controls that were implemented but not documented
3. Gaps in the observation period (e.g., evidence from month 1 and month 6, nothing in between)

Continuous, automated evidence collection solves all three.

The SOC 2 checklist

CC1 — Control Environment

• ☐ Organizational structure documented (org chart or RACI)
• ☐ Board/leadership oversight of security program
• ☐ Code of conduct or acceptable use policy signed by all employees
• ☐ Background checks completed for relevant roles
• ☐ Security awareness training completed and tracked
• ☐ Annual management review of security program

CC2 — Communication and Information

• ☐ Security policies published and accessible to employees
• ☐ Incident response policy documented
• ☐ Vendor/third-party security policy documented
• ☐ Customer-facing privacy policy published
• ☐ Internal communication channels for security issues defined

CC3 — Risk Assessment

• ☐ Formal risk assessment completed (at least annually)
• ☐ Risk register maintained with likelihood × impact scoring
• ☐ Risk treatment decisions documented
• ☐ Threat and vulnerability monitoring in place

CC6 — Logical and Physical Access Controls (most evidence-heavy)

• ☐ User access provisioning process documented
• ☐ Access reviews conducted quarterly (with sign-off records)
• ☐ Terminated user offboarding checklist with timestamps
• ☐ MFA enforced on all production systems
• ☐ Privileged access limited and documented
• ☐ SSH keys and API keys inventoried and rotated
• ☐ AWS IAM / Okta / Azure AD user records with MFA status exported regularly
• ☐ Least-privilege principle applied and documented

CC7 — System Operations (monitoring)

• ☐ Infrastructure monitoring configured (CloudWatch, Datadog, etc.)
• ☐ Alert thresholds defined and documented
• ☐ Incident log maintained with timeline, impact, resolution
• ☐ Vulnerability scanning running regularly (Snyk, AWS Inspector, etc.)
• ☐ Vulnerability remediation tracked and documented
• ☐ CloudTrail or equivalent audit logging enabled

CC8 — Change Management

• ☐ Code review process documented and enforced
• ☐ GitHub PRs with approval records available for observation period
• ☐ CI/CD deployment logs exported and timestamped
• ☐ Rollback procedures documented
• ☐ Change advisory process for significant infrastructure changes

CC9 — Risk Mitigation

• ☐ Vendor risk assessment process documented
• ☐ Active vendor list with SOC 2 / ISO 27001 status tracked
• ☐ Annual pen test completed (or scheduled)
• ☐ Pen test report and remediation plan on file
• ☐ Business continuity / disaster recovery plan documented
• ☐ RTO and RPO targets defined and tested

Policies you need to have written

SOC 2 requires documented policies for each area. These need to exist, be signed off by leadership, and be accessible to employees:

• Information Security Policy
• Acceptable Use Policy
• Access Control Policy
• Incident Response Plan
• Change Management Policy
• Vendor Management Policy
• Business Continuity / Disaster Recovery Plan
• Data Classification Policy
• Encryption Policy

Evidence you need to collect during the observation period

For Type II, your auditor will ask for evidence covering the full observation period (typically 6–12 months). The most common gaps:

• Access review records (quarterly, with approver sign-off)
• User provisioning and deprovisioning records with timestamps
• MFA enforcement status across all production systems
• Vulnerability scan results and remediation tickets
• Deployment logs and PR approval records
• Security training completion records
• Incident log (even if empty — "no incidents" still needs to be documented)

The fastest way to check your readiness

Before spending time on any of this manually, run a free compliance readiness check — it takes 60 seconds and tells you which controls are likely already covered by your existing tools, and which ones are genuinely missing.

Or start collecting evidence automatically. TraceLayer connects to your AWS, GitHub, Okta, and Slack and starts mapping evidence to SOC 2 controls immediately — so you arrive at your audit with 6 months of clean, organized records instead of a ZIP file of screenshots.