SOC 2 Compliance Checklist

Scope drives everything in SOC 2. The system description in your report defines what was audited. Get this right and the rest of the project flows. Get it wrong and you either waste audit fees on out-of-scope systems or end up with findings on systems you forgot to harden.

Scoping decisions to make before you start:

• Service description: What product or service is being audited? Be specific.
• System boundary: Which infrastructure, applications, networks, and personnel are in scope?
• Trust Service Criteria: Security is mandatory. Pick from Availability, Confidentiality, Processing Integrity, and Privacy based on customer requirements.
• Subservice organizations: Cloud providers, payment processors, and other vendors that support your service.

Document the scope in a system description draft early. Your auditor will refine it during fieldwork, but starting from a thoughtful draft beats reverse-engineering one. Cross-reference the SOC 2 framework reference for criteria details.

SOC 2 does not give you a control list. The Trust Services Criteria define what controls need to address (e.g., "the entity restricts logical access") but you choose the implementation. This flexibility is a strength once you know what you are doing and a trap if you do not.

Common control mapping that holds up in audits:

• CC6.1 (Logical access): Identity provider with MFA, RBAC, periodic access reviews
• CC6.6 (Logical access for external): VPN with MFA, customer-side authentication controls
• CC7.1 (Detection of vulnerabilities): Vulnerability scanning, dependency monitoring, pen testing
• CC7.2 (System monitoring): SIEM, alerting, on-call rotation
• CC8.1 (Change management): Code review, automated testing, deploy approvals

Map every Trust Services Criterion to at least one control. Map every control to a system that operates it. The auditor walks this map looking for gaps.

SOC 2 Type II audits are evidence-heavy. The auditor samples evidence across the audit period (3-12 months) for every control. If your evidence is scattered across tools, screenshots in Slack, and people's heads, you will spend the audit firefighting.

Evidence patterns that work:

• Continuous evidence: System-generated logs, automated reports, infrastructure-as-code commits, ticketing system records
• Periodic evidence: Quarterly access reviews, annual policy attestations, monthly vulnerability scans, weekly backup tests
• Event-driven evidence: Incident tickets, change approvals, exception logs

Build a single evidence repository with folders mapped to controls. Cloud storage (Drive, Box) works for small organizations. Larger orgs need GRC tooling that ingests evidence automatically. Either way, the goal is one location, indexed by control, with timestamps preserved.

Start collecting evidence at least three months before the audit period begins, not on day one of the audit window.

A pre-audit readiness assessment is optional but strongly recommended for first-time SOC 2 audits. The readiness reviewer simulates auditor activities, identifies gaps, and gives you 60-90 days to remediate before the formal audit starts.

The actual audit has two phases:

1. Type I or interim review (Type II): Auditor reviews design effectiveness. Are the controls designed properly? Walk-throughs and document review.
2. Type II operating effectiveness: Auditor tests whether controls operated effectively across the audit period. Sample-based testing.

During fieldwork, expect requests for samples covering the entire audit period. "Show me the access review for Q2" or "Pull the change tickets for these 25 deployments." If your evidence is dated, organized, and complete, fieldwork moves fast. If not, you spend the audit reconstructing history.

If the auditor identifies a deviation (control did not operate as expected during a sampled instance), you have a finding. Findings come in three flavors:

• Exception with mitigating control: Issue noted but compensating controls limit the impact
• Modified opinion (qualified): Significant control failure that did not undermine the system as a whole
• Adverse opinion: Material control failures that undermine the audit conclusion

Most companies aim for an unmodified (clean) opinion. To get there, fix any control gaps during the audit period rather than waiting. Auditors will accept remediation evidence if the fix is in place and operating before fieldwork concludes.

Report issuance typically takes 4-8 weeks after fieldwork. Distribute the report under NDA to customers and prospects. The report has a 12-month freshness window, after which you need a new one. Plan the next audit cycle to avoid coverage gaps. See the SOC 2 framework guide for detailed criteria mapping.