SOC 2 Compliance Checklist (2026)

What is SOC 2 and who needs it?

SOC 2 (System and Organization Controls 2) is an auditing framework developed by the American Institute of Certified Public Accountants (AICPA). Unlike regulations such as GDPR or HIPAA, SOC 2 is not a legal requirement — it is a voluntary standard. However, it has become the de facto security credential expected by enterprise customers before purchasing B2B software. SaaS companies, cloud infrastructure providers, data processors, and managed service providers are most frequently asked to demonstrate SOC 2 compliance.

SOC 2 is structured around Trust Services Criteria (TSC): Security (CC criteria, mandatory for all reports), Availability (A1), Processing Integrity (PI1), Confidentiality (C1), and Privacy (P1–P8). Most companies start with Security only. Adding Availability is common for uptime-sensitive infrastructure services. Including all five criteria significantly increases audit scope and cost.

SOC 2 Type 1 vs Type 2 — which do you need?

A SOC 2 Type 1 report assesses whether your controls are suitably designed at a single point in time. It is faster to obtain (typically 2 to 4 months) and less expensive. A SOC 2 Type 2 report assesses whether your controls operated effectively over a period of time — typically 6 or 12 months. Enterprise customers and regulated industries almost always require Type 2. The typical path is: implement controls, get a Type 1 report, operate for 6 to 12 months, then get a Type 2 report.

SOC 2 audits must be conducted by a licensed CPA firm. Costs typically range from $20,000 to $80,000 and above depending on scope and auditor. Readiness assessments ($5,000 to $15,000) are strongly recommended before the formal audit to identify gaps. Unlike PCI DSS, SOC 2 does not prescribe specific controls — it defines objectives, and you choose how to meet them. Thorough documentation and evidence collection is critical.

How to use this SOC 2 readiness checklist

Start with the Security (CC) criteria — they are mandatory for every SOC 2 report. The most common gaps found in readiness assessments are: lack of formal quarterly access reviews (CC6.2), missing MFA enforcement (CC6.1), undocumented change management procedures (CC8.1), and absent vendor risk management (CC9.2). Address these first.

Document all evidence as you go — policies should be written and version-controlled, and operational controls should produce logs or records that can be provided to auditors. If you also handle EU data, review our GDPR checklist; if you process payments, see the PCI DSS checklist.

What this checklist is for, and what it is not

This checklist is for SaaS companies, cloud infrastructure providers, and technology service providers preparing for a first SOC 2 engagement or conducting a readiness assessment before engaging a CPA firm. It covers all five AICPA Trust Services Criteria categories, with emphasis on the Security (CC) criteria required for every SOC 2 report. It addresses what an organisation's security or engineering team can self-assess to identify gaps before the formal audit window.

What it does not cover: the specific evidence formats an individual audit firm will require (these vary by firm and scope); the controls that apply to your specific cloud infrastructure (AWS, Azure, and GCP have different implementation details); the formal SOC 2 Type 1 or Type 2 audit itself, which must be conducted by a licensed CPA firm; or specific contractual terms customers may require in your SOC 2 scope. Completing this checklist identifies gaps; it does not produce a SOC 2 report. Last verified May 2026 against the AICPA Trust Services Criteria at aicpa-cima.com.

Real-world failures and the SOC 2 controls that would have prevented them

Since SOC 2 is not regulator-enforced, this section maps significant security incidents to the Trust Services Criteria they illustrate.

In December 2020, attackers injected malicious code into SolarWinds' Orion software build process, distributing the Sunburst backdoor to approximately 18,000 customers including multiple US federal agencies. The attack exploited gaps in change management, code integrity verification, and vendor access controls. The directly relevant TSC are CC6.8 (controls over transmission and disclosure), CC8.1 (change management), and CC9.2 (monitoring of vendor risk). SolarWinds agreed to pay $26 million to settle SEC charges in 2024.

In July 2019, a misconfigured AWS Web Application Firewall allowed an attacker to access Capital One's AWS environment, exposing the personal data of approximately 106 million customers. Capital One was fined $80 million by the OCC. The relevant TSC are CC6.1 (logical access controls) and A1.2 (environmental protections). The attacker used a Server-Side Request Forgery (SSRF) attack to query the AWS instance metadata service — a known vulnerability with a well-documented mitigation. The case demonstrates that cloud misconfiguration is a TSC gap, not just an infrastructure issue.

In September 2017, Equifax's failure to patch a known Apache Struts vulnerability (CVE-2017-5638) for over two months allowed attackers to access the personal and financial data of 147 million US consumers. Equifax ultimately paid a $575 million FTC settlement. The failure maps directly to CC7.1 (monitoring for security events) and CC6.8 (logical access controls over vendor-supplied software). Vulnerability patching without a verified, tracked process is a SOC 2 gap, not just a security best practice.

Common SOC 2 mistakes

Treating Type 1 as a final destination. Enterprise customers require Type 2 reports that demonstrate controls operated effectively over time. Type 1 satisfies some procurement requirements for early-stage companies, but many enterprise buyers will not accept it as a substitute. The common error is to complete a Type 1 and delay beginning the 6 to 12-month Type 2 observation period, creating a significant lag before a Type 2 report is available.

Collecting evidence only during the audit window. SOC 2 auditors assess controls over the entire observation period. Common controls that must produce continuous evidence include: quarterly access reviews (CC6.2), change management approvals (CC8.1), incident response documentation (CC7.3), and employee security training completion records. Many companies begin collecting this evidence only when the auditor asks for it, and retrospective evidence gaps are a common cause of qualified opinions.

Weak vendor risk management. SOC 2 Criterion CC9.2 requires assessing and monitoring third-party service providers that could affect your service commitments. Many companies have extensive third-party software lists but no documented vendor risk assessment process, no criteria for escalation to senior review, and no tracking of vendors' own SOC 2 reports. This is consistently identified as a gap in readiness assessments.

What changed in SOC 2: 2024 to 2026

The AICPA's 2022 revision to the Trust Services Criteria took effect for SOC 2 audits from December 2022 onward. The changes included revisions to the description criteria, updates to the COSO 2013 framework references, and modifications to criteria addressing risk assessment and vendor management. Auditors engaging after December 2022 assess against the updated criteria. If your last readiness assessment was conducted against the 2017 TSC, a gap analysis against the current criteria is needed.

In 2024 and 2025, auditor expectations converged around CC6.1 and CC6.3 requiring multi-factor authentication not only for external-facing systems but also for internal admin access, production environment access, and privileged account management. Many companies that passed SOC 2 audits in 2021 to 2022 with weaker MFA controls are finding those same controls now draw audit findings.

As more SaaS products incorporate AI and machine learning, auditors are increasingly examining CC6.6 (logical access restrictions for system components), CC7.2 (evaluation of anomalous events), and Processing Integrity criteria for AI-driven outputs. The AICPA has issued emerging practice points on AI and SOC 2; whether AI components are in scope depends on whether they affect the entity's service commitments. Last reviewed May 2026 by the Zeta Solutions editorial team.