SOC 2 Type 2 Compliance: A Practitioner's Guide

SOC 2 scope defines which systems, services, and Trust Service Criteria (TSC) your audit covers. Getting scope wrong is the single most expensive mistake in SOC 2 preparation.

The five Trust Service Criteria are: Security (CC — Common Criteria, required for all SOC 2 reports), Availability (A), Processing Integrity (PI), Confidentiality (C), and Privacy (P). Security is mandatory. The others are optional and should be included only if customers are contractually requiring them or if you process data types that make them directly relevant.

For most SaaS companies completing their first SOC 2: Security only. Adding Availability adds roughly 25% to audit scope and requires demonstrating uptime SLAs, redundancy architecture, and capacity management controls. Adding Privacy requires demonstrating GDPR/CCPA-aligned data handling across your entire data processing pipeline. These additions are appropriate if your customer base specifically requires them — not as a default.

System scope defines which infrastructure components are in scope for the audit. The correct approach: scope the systems that directly deliver the service you are selling, process customer data, and support the security controls you are asserting. Do not scope internal tooling, development laptops, or test environments unless they have direct access to production customer data. A tight scope produces a faster, cheaper audit and a more defensible report.

Document your scope in a System Description — the narrative document that opens every SOC 2 report. Auditors use the System Description to set expectations for what controls they will test. A vague System Description leads to scope creep during fieldwork.

The Common Criteria (CC) contains nine control categories covering organizational governance through logical and physical access. The controls that fail most often in first-time audits fall into four areas.

CC6 — Logical and Physical Access Controls is the category auditors test most rigorously. Required evidence includes: a formal access provisioning and deprovisioning process (with evidence that terminated employees lose access within a defined SLA — typically same business day), MFA enforcement for all production system access, privileged access review documentation (quarterly access reviews with evidence of remediation for any inappropriate access found), and unique account policy enforcement (no shared accounts, no shared credentials).

CC7 — System Operations covers monitoring and anomaly detection. You need a functioning SIEM or log aggregation platform with defined alert logic, evidence of alert review, and documented response to alerts generated during the observation period. 'We have CloudWatch configured' is not sufficient — you need evidence that alerts were reviewed and acted on.

CC8 — Change Management covers your software development and infrastructure change process. Every production change during the observation period should have an associated change record demonstrating: authorization (a second person approved it), testing (it was tested before deployment), and documentation (what changed and why). If your team pushes directly to production without a documented approval process, this control will fail.

CC9 — Risk Mitigation covers vendor management. You need a vendor inventory listing every third party with access to customer data, evidence of security review for each (SOC 2 reports, security questionnaire responses, or equivalent), and a process for monitoring vendor security posture changes.

Type 2 audits cover an observation period — typically 6 to 12 months — during which your controls must operate consistently. The auditor tests whether your controls actually functioned as described throughout the period, not just at a point in time.

Start evidence collection on day one of the observation period, not when audit fieldwork begins. Common evidence failures: access review documentation that begins two months before the audit rather than at the start of the observation period; change management records that are complete for the last quarter but sparse for the first three quarters; security training completion records that show 100% completion in the week before the audit started.

Build evidence collection into operational workflows rather than treating it as a separate compliance activity. Access reviews should generate artifacts automatically (export from your IdP showing users and access levels, signed-off by the reviewer). Change management should generate artifacts automatically (pull request approvals, deployment records from CI/CD). Vulnerability management should generate automated scan reports rather than manual point-in-time exports.

Compliance automation platforms (Vanta, Drata, Secureframe, Tugboat Logic) significantly reduce evidence collection burden by integrating with cloud providers, identity systems, and engineering tools to pull evidence automatically. For a company completing its first SOC 2, the cost of a compliance automation platform ($15,000 to $30,000 annually) is typically less than the engineering time required to manually collect equivalent evidence.

Auditor selection matters. SOC 2 auditors are licensed CPA firms, but experience with technology companies varies enormously. An auditor who primarily audits manufacturing companies will struggle with cloud-native infrastructure. Request references from technology companies of similar size and architecture before engaging.

Conduct a readiness assessment three to four months before the observation period ends. Engage a third party — your auditor cannot perform the readiness assessment for an engagement they will later audit — to walk through your control evidence and identify gaps before fieldwork begins. Readiness assessment findings with three to four months remaining in the observation period give you time to remediate gaps and generate evidence of remediation before the audit.

During fieldwork, respond to auditor information requests within agreed SLAs (typically 48 to 72 hours per request). Delays in evidence production extend fieldwork timelines and increase audit cost. Assign a single point of contact who coordinates all auditor communications — auditors requesting information from multiple stakeholders produce inconsistent responses and scope creep.

For exceptions — instances where a control failed during the observation period — document the exception, the root cause, and the corrective action taken. Auditors expect some exceptions in a Type 2 report. A report with no exceptions for a 12-month period is more suspicious than one with a few well-documented exceptions and demonstrated remediation.

SOC 2 Type 2 is a 12-month operational commitment, not a one-time audit event. The companies that pass cleanly are not the ones with the most sophisticated controls — they are the ones with consistently operated controls, clean evidence trails, and access management processes that work reliably throughout the observation period. Over-engineering controls and under-investing in evidence collection is the failure mode. The inverse — simple, consistently operated controls with automated evidence generation — produces a clean report.