SOC 2
SOC 2 is an attestation report on a service organization's controls against the AICPA Trust Services Criteria. Learn how SOC 2 works, Type I vs Type II, and its AI relevance.
What SOC 2 actually is
SOC 2 is not a certification and not a pass/fail badge. It is an attestation engagement performed under the American Institute of Certified Public Accountants (AICPA) attestation standards. A licensed CPA firm — the only party permitted to issue a SOC 2 report — examines a service organization's controls and issues an independent opinion on whether those controls meet the applicable Trust Services Criteria.
The output is a report, not a logo. A SOC 2 report contains the auditor's opinion, management's assertion, a description of the system under examination, and — for one report type — the detailed tests the auditor performed and their results. Because it is an attestation, the value lies in the auditor's evidence-based opinion, not in a marketing claim.
SOC 2 reports are typically issued under a restricted-use designation, meaning they are shared with customers, prospects, and their auditors under NDA rather than published openly. This distinguishes SOC 2 from SOC 3, a general-use summary report covering the same examination that an organization may distribute publicly.
The Trust Services Criteria
SOC 2 is built on five Trust Services Criteria (TSC). Security — referred to as the Common Criteria — is always required; the remaining four are included only if relevant to the services the organization provides and the commitments it makes to customers. A vendor scopes its report to the criteria that match its obligations.
| Trust Services Criterion | Required? | What it evaluates |
|---|---|---|
| Security (Common Criteria) | Always | Protection of systems and data against unauthorized access, disclosure, and damage — access control, change management, risk assessment, monitoring |
| Availability | Optional | Whether systems are available for operation and use as committed, including resilience, recovery, and capacity |
| Processing Integrity | Optional | Whether system processing is complete, valid, accurate, timely, and authorized |
| Confidentiality | Optional | Protection of information designated as confidential throughout its lifecycle, including handling and disposal |
| Privacy | Optional | Collection, use, retention, disclosure, and disposal of personal information in line with the organization's privacy notice |
Because the criteria are referred to by name rather than fixed control numbers, two organizations can hold SOC 2 reports of very different depth. A report covering only Security is meaningfully narrower than one covering Security, Confidentiality, and Privacy. Reading which criteria are in scope is the first step in evaluating any SOC 2 report.
Type I versus Type II
SOC 2 reports come in two types, and the distinction is central to how much assurance a report provides. A Type I report describes a service organization's controls and assesses whether they are suitably designed at a single point in time. A Type II report goes further: it tests whether those controls operated effectively over a defined review period, typically three to twelve months.
| SOC 2 Type I | SOC 2 Type II | |
|---|---|---|
| What is assessed | Design of controls | Design and operating effectiveness |
| Time frame | A single point in time | A period (commonly 3–12 months) |
| Evidence | Controls exist and are designed well | Controls were tested and worked throughout the period |
| Assurance level | Lower — a snapshot | Higher — demonstrated performance over time |
| Typical use | First report; new control programs | Ongoing assurance; what most buyers require |
In practice, enterprise buyers strongly prefer Type II, because a point-in-time design opinion says nothing about whether controls were actually followed day to day. Many organizations issue a Type I as an initial milestone, then move to an annual Type II cycle. A SOC 2 report also carries an "as of" or coverage date; a report whose period ended long ago provides weaker current assurance, which is why buyers ask for recent reports and, between cycles, a bridge letter from the vendor.
How SOC 2 is used in vendor due diligence
For most B2B software buyers, SOC 2 is the entry ticket to a security review. When an organization evaluates a vendor that will process its data, the security or procurement team requests the vendor's SOC 2 report and reads it rather than trusting a claim of "SOC 2 compliant."
A thorough review looks at several things: which Trust Services Criteria are in scope, whether the report is Type I or Type II, the length and recency of the review period, the auditor's opinion (an unqualified opinion is clean; a qualified opinion flags exceptions), any noted exceptions and management's response, and the complementary user-entity controls the report assumes the customer will operate. Subservice organizations — the vendor's own critical providers — are also disclosed, so a buyer can see what is carved out of scope.
SOC 2 does not replace a buyer's own diligence, but it consolidates a large amount of independent evidence into one document, which is why it has become a near-universal request in enterprise procurement.
Why SOC 2 matters for AI
As organizations adopt AI tools and AI-powered vendors, SOC 2 has become a focal point for AI risk in two directions.
First, AI vendors are themselves service organizations. A company offering an AI assistant, model API, or agentic product processes customer data, and buyers increasingly demand a SOC 2 report before approving it — exactly as they would for any SaaS vendor. AI features embedded in existing products fall within the scope of that product's SOC 2 examination, meaning the controls around model access, data handling, and logging are now part of what auditors and customers scrutinize.
Second, an organization's own adoption of AI creates new control objectives that map onto the Trust Services Criteria. Sensitive data flowing into prompts and tool calls bears on Confidentiality and Privacy. Access to AI models and agents bears on Security. The ability to demonstrate who used which AI tool, what data was submitted, and what autonomous agents did bears on the monitoring and logging expectations within the Common Criteria. Auditors and customers now ask how AI usage is governed, not just whether the rest of the environment is.
The practical consequence is that AI governance is becoming part of SOC 2 readiness. Organizations that cannot show control over AI access, data exposure through prompts, and agent actions face questions in their own audits and in the diligence their customers run on them.
