SOC 2 Type II Compliance Guide 2026

SOC 2 has become the de facto compliance credential for technology service organizations operating in the United States. Enterprise procurement teams, security-conscious buyers, and institutional investors now treat a SOC 2 Type II report as a baseline prerequisite for vendor engagement — not a differentiator, but a minimum. Organizations that cannot produce a current SOC 2 report increasingly find themselves eliminated early in vendor evaluation processes, regardless of their actual security posture. This guide explains exactly what SOC 2 requires, how the audit process works, where organizations consistently fall short, and how to assess your compliance readiness before engaging a CPA firm.

1. What SOC 2 Type II Is — and Who Needs It

SOC 2 is a framework developed by the American Institute of Certified Public Accountants (AICPA). It defines the security, availability, confidentiality, processing integrity, and privacy criteria that service organizations must demonstrate to their customers. Unlike many compliance frameworks, SOC 2 is not a government regulation — it is a voluntary attestation standard. Its power comes entirely from market demand: customers require it, so organizations pursue it.

The distinction between Type I and Type II is fundamental. A SOC 2 Type I report evaluates whether your controls are suitably designed to meet the applicable Trust Services Criteria as of a single point in time. A SOC 2 Type II report goes substantially further: an independent CPA firm assesses whether those controls operated effectively throughout an observation period, typically six to twelve months. Type II is what enterprise procurement teams actually require, because Type I only proves the controls existed on one day, not that they function consistently in practice.

Organizations in scope for SOC 2 include any entity that stores, processes, or transmits customer data on behalf of its users. This encompasses SaaS companies, cloud infrastructure providers, data centers, managed service providers (MSPs), managed security service providers (MSSPs), payment processors, healthcare technology vendors, and a broad range of B2B software companies. If your organization has access to customer data or systems, and your customers are enterprises or regulated entities, SOC 2 Type II is almost certainly expected.

SOC 2 and ISO 27001 address overlapping but distinct needs. ISO 27001 is an international standard resulting in certification from an accredited body; SOC 2 is an AICPA attestation resulting in a report from a licensed CPA firm. Approximately 60% of controls overlap, but the audiences differ: US enterprise customers typically request SOC 2, while European customers and multinationals often require ISO 27001. Organizations serving both markets frequently pursue both. SOC 2 reports are also often shared under NDA, while ISO 27001 certificates are typically public.

Why has SOC 2 become effectively mandatory? The answer is third-party risk management. Enterprise organizations and regulated entities face growing pressure from their own regulators, customers, and insurers to demonstrate that their vendors meet security standards. A SOC 2 Type II report shifts that burden of proof to the vendor and provides an independent, structured evidence package that satisfies procurement and legal review cycles efficiently.

2. The Five Trust Services Criteria Explained

SOC 2 is built around five Trust Services Criteria (TSC), each covering a distinct dimension of security and operational integrity. Only the Security criteria is mandatory; the remaining four are selected based on what commitments your organization makes to customers in its system description and service agreements.

Security (CC6–CC9) — Mandatory

Security is the foundation of every SOC 2 engagement. It covers logical and physical access controls (CC6), system operations and monitoring (CC7), change management (CC8), and risk mitigation including incident response (CC9). Every SOC 2 report covers Security; there is no SOC 2 without it. The Security criteria maps closely to the CIS Controls and NIST Cybersecurity Framework, making it a useful anchor point for organizations with existing frameworks in place.

Availability (A1)

Availability covers uptime commitments, redundancy, disaster recovery, and capacity planning. If your organization makes SLA commitments to customers about system availability — particularly if downtime causes material harm — Availability should be in scope. Auditors will look for documented RTO (Recovery Time Objective) and RPO (Recovery Point Objective) targets, evidence that DR plans have been tested, and monitoring systems that detect and alert on availability degradation before customers are impacted.

Confidentiality (C1)

Confidentiality addresses how information designated as confidential is collected, retained, used, and disposed of. This includes data classification policies, encryption at rest and in transit, NDA enforcement with staff and vendors, and data disposal procedures. Organizations handling customer business data, intellectual property, or legally privileged information typically include Confidentiality in their SOC 2 scope.

Processing Integrity (PI1)

Processing Integrity covers whether system processing is complete, valid, accurate, timely, and authorized. This criteria is most relevant to financial processing systems, payroll platforms, data transformation services, and organizations where processing errors create direct financial or operational consequences. It requires monitoring of processing completeness, error handling procedures, and validation of outputs.

Privacy (P1–P8)

The Privacy criteria aligns with the AICPA Generally Accepted Privacy Principles (GAPP) and covers personal information collection, use, retention, disclosure, and disposal. It maps substantially to GDPR and CCPA requirements, making it a useful dual-purpose criteria for organizations managing personal data across jurisdictions. Most organizations beginning their SOC 2 journey start with Security and Availability, then layer in additional criteria as customer requirements and market positioning evolve.

3. The SOC 2 Audit Process: What to Expect

The SOC 2 audit process has several distinct phases, and understanding the full timeline before you begin is essential to setting realistic expectations with leadership and customers who are waiting on your report.

Selecting a CPA Firm

SOC 2 audits must be performed by a licensed CPA firm with demonstrated competence in Trust Services Criteria attestations. Not all auditors are equal — experience with your industry, familiarity with your technology stack, and the quality of their evidence review process vary significantly. Request sample reports, ask about their experience with cloud-native environments, and verify that they have staff dedicated to SOC 2 rather than treating it as a side practice. Auditor quality directly affects the credibility of your report with sophisticated enterprise buyers.

Readiness Assessment Phase

Before the observation period begins, most organizations conduct a readiness assessment to identify gaps between their current controls and the applicable Trust Services Criteria. This phase involves mapping existing policies and controls to specific criteria, identifying missing or inadequate controls, and building a remediation plan. The readiness assessment can be performed internally, by an external consultant, or by the auditing firm itself (though auditor-performed readiness assessments raise independence questions that some CPA firms decline for that reason).

Observation Period

The observation period is the window during which the auditor assesses whether controls operated effectively. For Type II, a minimum of six months is required; twelve months is typical for mature reports. During this period, your controls must actually function as documented. Access reviews must happen on schedule. Patch management must meet your stated timelines. Incident response procedures must be followed when events occur. Evidence of control operation is generated during the observation period and collected for auditor review.

Evidence Collection and Report Delivery

At the end of the observation period, the CPA firm collects and reviews evidence: policies and procedures, system configuration screenshots, access review logs, penetration test reports, security training completion records, vendor risk assessments, and change management logs. The auditor issues a report that includes a description of your system, management’s assertion about controls, and the auditor’s opinion. An unqualified opinion means controls operated effectively; a qualified opinion indicates exceptions were found; an adverse opinion means controls were insufficient. From initial decision to first clean report, plan for nine to eighteen months.

4. The 10 Most Common SOC 2 Compliance Gaps

Readiness assessments consistently surface the same control gaps across organizations of all sizes. Addressing these before your observation period begins significantly reduces the risk of exceptions in your final report.

• No formal access review process. SOC 2 CC6.2 requires periodic reviews of user access rights. Quarterly access reviews with documented evidence of completion are the standard expectation. Organizations frequently conduct informal reviews but lack the documentation trail auditors require.
• MFA not enforced across all privileged and remote access. Multi-factor authentication is required for administrative accounts, remote access, and privileged system access. Many organizations have MFA available but not uniformly enforced — exceptions for specific users or legacy systems are audit findings.
• No documented change management process. CC8 requires that changes to infrastructure and applications follow a documented approval and testing process. Undocumented deployments, even small ones, are exceptions under SOC 2.
• Vendor and third-party risk management absent. CC9.2 requires that organizations assess vendor risk and monitor third-party exposure. A spreadsheet of vendors without documented assessments, contractual security requirements, or ongoing monitoring does not satisfy this criterion.
• Backup procedures not tested against RTO/RPO targets. Availability criteria require documented RTO and RPO targets and evidence that backups are periodically restored and tested against those targets. Documented targets without test evidence are exceptions.
• Vulnerability management without SLA-tracked remediation. A vulnerability scanning program without documented remediation timelines tied to severity (e.g., critical vulnerabilities patched within 30 days) and evidence of adherence is inadequate under CC7.1.
• No security awareness training records. CC2.2 requires security awareness training for all personnel. Completion records, training content documentation, and evidence of topic updates are all required. Annual training without completion tracking is insufficient.
• Encryption not applied at rest for all customer data stores. Confidentiality and Security criteria both require encryption at rest for customer data. Partial encryption — some databases encrypted, others not — generates findings.
• Incident response plan exists on paper only, never tested. CC9.1 requires that incident response procedures exist and are tested. An untested IR plan is consistently flagged. Tabletop exercises with documented outcomes satisfy this requirement and generate direct audit evidence.
• Privacy notice does not match actual data practices. If your Privacy criteria is in scope, auditors will compare your stated data practices in your privacy notice against actual system behavior. Discrepancies between stated and actual data retention, sharing, or processing practices are material exceptions.

5. How to Prepare for a SOC 2 Audit in 90 Days

Ninety days is not enough time to complete a SOC 2 Type II audit — the observation period alone requires six months minimum. But ninety days is a realistic window to complete readiness activities and enter the observation period with controls in good shape. Here is how to structure that sprint.

1. Weeks 1–2: Define scope. Determine which systems, services, and data flows are in scope. Define which Trust Services Criteria apply based on customer commitments. A narrower initial scope reduces audit cost and complexity — many organizations begin with Security only and expand in subsequent years.
2. Weeks 3–4: Gap assessment. Map your current controls against each applicable Trust Services Criteria. Document your current state honestly: fully implemented, partially implemented, or absent. Use the ten common gaps above as a starting checklist, but also work through the full criteria point by point. Partial implementation is still a gap.
3. Month 2: Policy documentation sprint. SOC 2 auditors will request your information security policy, access control policy, change management policy, incident response plan, business continuity plan, and vendor management policy at minimum. These must be approved, version-controlled documents — not drafts. Month 2 is when missing policies get written and existing policies get reviewed for accuracy against current practice.
4. Month 3: Control implementation and evidence gathering. Implement missing controls and begin generating evidence. Set up your access review calendar. Configure vulnerability scanning. Enroll remaining users in MFA. Run your first tabletop exercise to generate incident response test evidence. Confirm backup restoration tests are scheduled. At month three’s end, begin the observation period.
5. Pre-audit readiness check. Before the observation period closes, conduct a pre-audit readiness assessment — either internally or with an external assessor. Identify any evidence gaps or control failures that occurred during the observation period and assess whether they rise to the level of exceptions. Surprises at the final audit are expensive and avoidable.

The two most common preparation mistakes are underestimating the volume of evidence required and starting too late. Auditors request hundreds of evidence items: access review logs for each review cycle, change tickets for each deployment, training completion records for every employee, and vulnerability scan reports for every assessment period. Building evidence collection habits from day one of the observation period is far easier than reconstructing evidence retroactively.

6. SOC 2 and Other Frameworks: How They Overlap

Organizations operating across multiple regulatory environments rarely pursue SOC 2 in isolation. Understanding how SOC 2 overlaps with other frameworks allows you to build a unified control environment that satisfies multiple requirements simultaneously, reducing audit fatigue and evidence duplication.

SOC 2 and ISO 27001

ISO 27001 and SOC 2 share approximately 60% control overlap. Both frameworks require risk assessment, access control, incident management, asset management, and supplier security. Organizations that have achieved ISO 27001 certification have a substantial head start on SOC 2, and vice versa. Dual certification is increasingly common among mid-market SaaS companies serving global enterprise customers. Many auditing firms now offer combined ISO 27001 and SOC 2 engagements that reduce duplication in evidence collection and interviews.

SOC 2 and HIPAA

Healthcare technology vendors frequently find that SOC 2 with the Privacy criteria and HIPAA Security Rule requirements map closely. SOC 2 Privacy criteria addresses notice, choice, collection, use, access, disclosure, and disposal of personal information — themes that run throughout HIPAA’s Privacy and Security Rules. A SOC 2 report covering Privacy criteria is not a substitute for a HIPAA compliance program, but it provides an independent validation of security controls that satisfies many healthcare customers’ vendor due diligence requirements alongside a Business Associate Agreement.

SOC 2 and PCI DSS

SOC 2 and PCI DSS serve different purposes and require separate compliance programs. PCI DSS is a contractual requirement from card brands for organizations that store, process, or transmit cardholder data; SOC 2 is a market-driven attestation covering the broader service organization. Some control infrastructure can be shared — access management, vulnerability scanning, encryption policies — but the reporting requirements are distinct and both audits must be completed independently.

SOC 2 and GDPR

SOC 2 Privacy criteria aligns meaningfully with GDPR Article 25 (privacy by design and by default) and Article 5 (data minimization, purpose limitation, storage limitation). For organizations processing EU residents’ personal data, a SOC 2 report covering Privacy criteria does not constitute GDPR compliance, but it provides substantial evidence of technical and organizational measures that satisfies GDPR’s accountability principle (Article 5(2)). Organizations should treat SOC 2 Privacy and GDPR as complementary programs, not alternatives.

Using Tabletop Exercises Across Frameworks

Tabletop exercises generate evidence that satisfies multiple frameworks simultaneously. A documented cybersecurity incident tabletop exercise serves as evidence for SOC 2 CC9.1 (incident response testing), ISO 27001 Annex A.5.26 (response to information security incidents), HIPAA §164.308(a)(6) (response and reporting), and GDPR Article 32 (appropriate technical and organisational measures). Running one high-quality exercise per quarter builds a robust evidence library that reduces friction across all concurrent audit programs.

7. Assessing Your SOC 2 Readiness Right Now

Before engaging a CPA firm and committing to an observation period, a structured self-assessment gives you an honest picture of where you stand. The cost of discovering major gaps during a live audit observation — in terms of delayed report delivery, remediation costs, and potential exceptions — is substantially higher than the cost of a pre-engagement readiness review.

A readiness score translates directly to your likely audit timeline. Organizations scoring above 80% across all applicable criteria typically enter observation periods immediately and complete their first clean Type II report within nine to twelve months. Organizations scoring below 60% should plan a three-to-six-month remediation sprint before beginning the observation period, or risk exceptions that require a qualified opinion or an extended observation window to clear.

The cost of a qualified opinion goes beyond auditor fees. Enterprise customers receiving your report with exceptions will follow up with questions, may require a remediation plan and bridge letter, or may pause vendor approval until a clean report is available. The reputational and commercial cost of a qualified SOC 2 opinion in a competitive sales environment almost always exceeds the cost of delaying the observation period to address gaps properly.

CyberICS Solutions’ free SOC 2 Readiness Assessment covers all five Trust Services Criteria across 25 structured questions. You receive an instant readiness score, domain-level gap analysis identifying your highest-priority control weaknesses, and specific remediation recommendations — all in under ten minutes, with no login required. Use the results to brief leadership, scope your CPA firm engagement, and structure your 90-day readiness sprint.

Frequently Asked Questions

Next Steps & Related Resources

Once you have your SOC 2 readiness baseline, the most effective next step is stress-testing your incident response and change management procedures through structured tabletop exercises. Exercises generate the tested-IR-plan evidence that SOC 2 CC9.1 requires, and the CyberICS Solutions platform includes scenarios mapped directly to Trust Services Criteria control themes. A single well-documented exercise per quarter builds the evidence library your auditor will want to see across the full observation period.