SOC 2 Compliance Requirements

SOC 2 (System and Organization Controls 2) is a voluntary but commercially significant compliance framework governing how service organizations manage customer data across five Trust Services Criteria. Developed by the American Institute of Certified Public Accountants (AICPA), it functions as the dominant third-party assurance standard in the US technology and cloud services sector. Procurement teams, enterprise clients, and regulators treat SOC 2 reports as primary evidence of operational security controls, making the framework a practical requirement for B2B SaaS providers, data processors, and managed service organizations regardless of its voluntary legal status.


Definition and scope

SOC 2 is defined and administered by the AICPA, which publishes the Trust Services Criteria (TSC) used as the evaluative standard for all SOC 2 engagements. The framework applies to any service organization that stores, processes, or transmits customer data on behalf of another entity — a category that encompasses cloud infrastructure providers, payroll processors, healthcare IT vendors, and financial technology platforms.

The five Trust Services Criteria establish the substantive scope of SOC 2:

  1. Security — Protection of system resources against unauthorized access (the sole mandatory criterion)
  2. Availability — System accessibility for operation and use as committed
  3. Processing Integrity — Complete, valid, accurate, timely, and authorized processing
  4. Confidentiality — Protection of designated confidential information
  5. Privacy — Collection, use, retention, disclosure, and disposal of personal information

Organizations select which criteria apply to their service commitments. A cloud storage provider may include Confidentiality and Availability alongside the mandatory Security criterion. A payment processor may add Processing Integrity. The Privacy criterion maps closely to principles published in the AICPA/CICA Generally Accepted Privacy Principles (GAPP) and aligns with frameworks such as the NIST Privacy Framework.

SOC 2 is distinct from SOC 1, which addresses internal controls over financial reporting under SSAE 18. Understanding the broader landscape of cyber compliance standards clarifies where SOC 2 sits relative to ISO/IEC 27001, FedRAMP, and HIPAA Security Rule requirements.


How it works

A SOC 2 examination is conducted by a licensed CPA firm registered with the AICPA Peer Review Program. The auditor evaluates whether a service organization's controls are suitably designed and, depending on report type, whether they operated effectively over a defined period.

Type I vs. Type II — the primary classification distinction:

Attribute SOC 2 Type I SOC 2 Type II
Point in time vs. period Single point in time Minimum 6-month observation period
Evaluation focus Design suitability only Design suitability + operating effectiveness
Evidence requirement Policy documentation, control design evidence Transaction logs, access records, incident history
Market weight Lower assurance for enterprise buyers Higher assurance; standard enterprise expectation

The examination process follows discrete phases:

  1. Scoping — Define system boundaries, applicable TSC, and observation period dates
  2. Readiness assessment — Internal or consultant-led gap analysis against TSC criteria
  3. Evidence collection — Gather control documentation, system configurations, audit logs, vendor agreements, and personnel records
  4. Auditor fieldwork — CPA firm tests controls through inquiry, observation, inspection, and re-performance
  5. Report issuance — Auditor issues a formal opinion; report includes a description of the system, management's assertion, the auditor's opinion, and detailed control testing results

The AICPA's AT-C Section 205 governs the attestation standards applicable to SOC 2 examinations. Auditors apply the TSC as published in the AICPA's Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (2017, updated 2022).


Common scenarios

SaaS vendor procurement vetting — Enterprise buyers routinely require a SOC 2 Type II report as a condition of vendor approval. A 12-month observation period report covering at least the Security criterion is the baseline expectation in enterprise software procurement.

Healthcare and financial services supply chains — Organizations subject to HIPAA or Gramm-Leach-Bliley Act (GLBA) obligations use SOC 2 reports from their technology vendors as third-party assurance evidence in their own compliance programs. Under 45 CFR §164.308(b), covered entities must obtain satisfactory assurances from business associates — SOC 2 reports frequently satisfy this requirement.

FedRAMP-adjacent environments — Cloud service providers pursuing FedRAMP authorization sometimes obtain a SOC 2 report as an interim assurance artifact or as supplemental evidence, though FedRAMP and SOC 2 are separate frameworks with distinct control sets.

Startup-to-enterprise maturation — Seed-stage companies often achieve a SOC 2 Type I report first, then convert to an annual Type II cycle as they pursue mid-market and enterprise sales. The cyber compliance participation structure for service organizations reflects this staged adoption pattern.


Decision boundaries

SOC 2 is not a regulatory mandate under any federal statute, but its absence can constitute a contractual deficiency or disqualify vendors from enterprise procurement processes. Key boundaries that determine applicability and scope:


📜 1 regulatory citation referenced  ·  🔍 Monitored by ANA Regulatory Watch  ·  View update log