Ask an AI vendor about security and you will get the same three words back almost every time: "we're SOC 2 compliant." It shows up on the homepage next to a padlock icon, in the sales deck, in the answer to your procurement questionnaire. It is meant to end the conversation.
It shouldn't. SOC 2 is not a certification, a pass/fail test, or a guarantee that the vendor's product is secure. It is an audit report — a specific document, written by a specific accounting firm, describing a specific set of controls over a specific period of time. Some of those reports are strong evidence. Some are three pages of caveats wearing a badge. You cannot tell which one you have until you open it and read it, and almost nobody does.
That gap matters more with AI vendors than it did with your old software suppliers, because AI adds moving parts — model providers, training pipelines, prompt logs, subprocessor chains — that a badge on a website was never built to describe.
What the badge actually promises
- SOC 2 is issued by the AICPA — the American Institute of CPAs — and delivered as an attestation report by a licensed CPA firm, not a government certification body.
- Only one of the five Trust Services Criteria is mandatory: Security. Availability, processing integrity, confidentiality, and privacy are optional add-ons a vendor can choose to include or leave out.
- A Type I report checks control design at one point in time. A Type II report checks whether those controls actually worked, over a period typically running six to twelve months — a materially stronger form of evidence.
- "Unqualified opinion" does not mean zero issues found. A report can carry an unqualified opinion and still list exceptions, if the auditor judged them non-pervasive.
- SOC 2 was not written to govern AI models. It attests general security controls — access, change management, monitoring — not model bias, explainability, or how training data was sourced, unless the vendor specifically scoped that in.
01Type I and Type II are not the same claim
A SOC 2 Type I report answers one question: on a single date, were the vendor's controls designed appropriately? It is a snapshot. It says nothing about whether those controls were actually followed the week before the audit, or the month after.
A SOC 2 Type II report answers a harder question: over an observation window — commonly six to twelve months — did those controls operate effectively, in practice, the whole time? The auditor pulls samples, checks logs, tests exceptions. It is the difference between reading a company's safety policy and watching an inspector follow the policy in use for six months.
A brand-new AI vendor will often lead with a Type I report because it is faster and cheaper to obtain — sometimes available within weeks of starting a compliance program. That is a legitimate first step, and not disqualifying on its own for an early-stage tool. But if a vendor handling anything sensitive has been operating for a year or more and still only produces a Type I, ask why. The honest answer is usually "we haven't finished the Type II cycle yet." Accept that as a timeline, not as equivalence to a Type II.
The one-line question that separates the two
Ask directly: "Is this Type I or Type II, and what is the observation period?" If the answer is Type I, ask when the Type II is expected. If the vendor can't answer either question specifically, that hesitation is itself information.
02The five criteria, and why "Security" alone is the floor, not the ceiling
SOC 2 is organized around five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only one that is required for a report to exist at all. Everything else is scope the vendor chose — or chose not to include.
That matters because "SOC 2 compliant" tells you almost nothing about scope by itself. A vendor whose report covers only Security has not made any formal, audited claim about how it handles availability commitments, data confidentiality beyond baseline access control, or privacy practices specifically. If your use case depends on one of those — you're storing regulated client data, or uptime is contractually critical to you — check the report's cover page for which criteria are actually in scope before assuming they are.
| Criterion | Required? | What it actually addresses |
|---|---|---|
| Security | Always required | Protection against unauthorized access — the baseline every SOC 2 report contains. |
| Availability | Optional | Whether systems are available for operation and use as committed — uptime, disaster recovery, incident response for outages. |
| Processing Integrity | Optional | Whether system processing is complete, valid, accurate, timely and authorized — relevant if the AI's output feeds a transaction or a decision. |
| Confidentiality | Optional | Protection of information designated as confidential, beyond ordinary access control — relevant to prompts, uploaded files, and business data. |
| Privacy | Optional | How personal information is collected, used, retained and disposed of — the criterion most relevant if you send customer PII through the tool. |
Only Security is mandatory for a SOC 2 report to be issued. The other four are scoped in or out at the vendor's discretion, and a report's cover page states which criteria it covers — check it rather than assuming "SOC 2" implies all five.
03What a SOC 2 does not cover, and why that gap is bigger for an AI vendor
SOC 2 was designed for conventional service organizations — payroll processors, hosting providers, SaaS platforms — and it maps cleanly onto their risks: access control, change management, encryption, monitoring, incident response. An AI vendor's SOC 2 will typically cover those same categories as they apply to its infrastructure.
What it was not built to answer is the AI-specific question you actually care about: what happens to the data inside the model, not just the systems around it. A SOC 2 auditor checking access controls on a training data store is testing whether that data store is properly secured — not whether the model trained on it retained anything, whether your prompts get used to improve someone else's model, or whether outputs can leak another customer's information. Those are model governance questions, and the standard built to certify a management system around them — covering model lifecycle, human oversight, and data governance across training and inference — is a separate framework (ISO/IEC 42001), not SOC 2.
In practice this means a vendor can hold a clean SOC 2 report and still have said nothing, formally, about whether your data trains their model. That question belongs in the contract, not the audit report — and a SOC 2 badge is not a substitute for reading that clause.
04Exceptions and qualified opinions: the part everyone skips
Every SOC 2 report ends with an auditor's opinion, and most people read the word "unqualified" as "clean" and stop there. It is not quite that simple. An unqualified opinion means the auditor found the controls, taken as a whole, met the criteria — but the same report can still list individual exceptions the auditor found during testing, as long as those exceptions weren't judged severe or widespread enough to change the overall conclusion.
A qualified opinion is a different and more serious thing: it means the auditor found one or more criteria that were not met, significant enough that a clean opinion couldn't be issued, but not so severe as to warrant an adverse opinion. In plain terms, qualified means the vendor came close and missed.
The section to actually read is usually called "Exceptions Noted" or similar, inside the body of the report — not the opinion letter at the front. This is where you find things like "access reviews were not performed on schedule for two of the twelve months tested" or "one terminated employee's credentials were not disabled within the required window." A report with a handful of narrow, promptly-remediated exceptions and an unqualified opinion is normal and even reassuring — it shows the audit found real things rather than rubber-stamping. A report with recurring exceptions in the same control area, or a qualified opinion, is a real flag worth asking the vendor to explain directly.
05Subservice organizations: the part of the chain that gets carved out
Almost no AI vendor runs its own data centers, and most don't run their own foundation models either. They sit on top of cloud infrastructure, and often on top of a model API from a separate provider. Each of those is a subservice organization, and how the vendor's SOC 2 treats them matters a great deal.
Most reports use what's called the carve-out method: rather than including the subservice organization's controls in the audit, the report simply discloses the type of controls it assumes the subservice organization has in place — called Complementary Subservice Organization Controls, or CSOCs. Critically, CSOCs are a disclosure, not something the auditor actually tested. The vendor is representing that it has a basis to expect those controls exist at its cloud provider or model provider; the auditor did not go verify them.
In practice, this means a vendor's own SOC 2 tells you about the vendor's controls — not necessarily about the security of the infrastructure or model provider underneath it. If the underlying cloud or model provider is well-known and separately audited (most major cloud platforms publish their own SOC 2 reports), that's reasonable comfort. If a vendor cannot or will not name which infrastructure and model providers it carves out, or whether those providers hold their own current SOC 2 reports, that is a real gap worth asking about — particularly relevant if you're also negotiating subprocessor terms in the contract, since subservice organizations in the audit and subprocessors in the contract are often the same list.
There is a second, related concept worth knowing: Complementary User Entity Controls, or CUECs — controls the vendor's report assumes you, the customer, will implement. A common example is that the vendor assumes you manage your own users' access to the tool responsibly. If you skip the CUEC section, you may be silently failing to hold up your half of the control environment the report depends on.
06What to actually ask for, and what to look at
- Ask for the full report, not the summary letter. Vendors often hand out a one-page attestation or a badge; the real report — usually 20 to 80 pages under an NDA — is where the useful information lives.
- Check the report date and the observation window. A Type II report from eighteen months ago tells you nothing about current controls. Ask if a bridge letter or a more recent report is available.
- Confirm which Trust Services Criteria are in scope on the cover page — Security alone, or Security plus Confidentiality and Privacy, matters for what you can rely on.
- Read the "Exceptions Noted" or equivalent section, not just the opinion letter. Ask the vendor directly to explain any exception and what was done about it.
- Find the subservice organization section and identify whether it's a carve-out or an inclusive report. Ask by name which cloud and model providers are carved out, and whether they hold current SOC 2 or equivalent reports of their own.
- Check the system description for AI-specific scope. Does it mention training data stores, prompt logging, or model inference systems at all — or only the surrounding infrastructure?
- Separately ask about model training on your data. SOC 2 does not answer this. Get it in writing in the contract, regardless of what the audit report says.
- Note the CUEC section and confirm your own team is actually doing what the vendor's control environment assumes you're doing.
07The honest summary
"SOC 2 compliant" is a real, useful signal — but it is a badge standing in for a document, and the document is where the actual information lives. Type I versus Type II changes what's actually been tested. The five criteria are mostly optional, so scope varies report to report. Exceptions can sit inside a clean opinion. Subservice organizations are usually disclosed, not audited, by the vendor's own report. And none of it, by default, answers the question you probably care about most with an AI vendor — what happens to your data once it reaches the model.
None of that means distrust every AI vendor with a SOC 2 badge. It means treat the badge as an invitation to ask for the report, not as the end of the conversation the vendor was hoping it would be.
08Common questions
What's the difference between SOC 2 Type I and Type II?
Type I checks whether a vendor's security controls were designed appropriately on one specific date — a snapshot. Type II checks whether those same controls actually operated effectively over an extended period, typically six to twelve months, based on the auditor testing samples and logs across that window. Type II is meaningfully stronger evidence because it demonstrates sustained practice rather than a point-in-time design review. A new vendor may only have a Type I; ask when their Type II is expected.
Does SOC 2 mean the vendor's AI model itself was audited?
Not by default. SOC 2 was built to audit general security controls — access management, change control, monitoring, encryption — and it applies those same categories to whatever infrastructure the vendor runs, AI included. But it was not designed to test model-specific questions like whether your data trains the model, whether outputs can leak another customer's information, or how training data was sourced. Those questions need to be asked separately and ideally answered in the contract, not assumed from the audit badge.
What are the five SOC 2 Trust Services Criteria?
Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only one required for a SOC 2 report to exist at all; the other four are optional and a vendor chooses which to include in scope. This means two vendors can both say "we're SOC 2 compliant" while one report covers only Security and the other covers all five — check the report's cover page to see which criteria actually apply.
Does an unqualified opinion mean the report is clean with zero issues?
Not necessarily. An unqualified opinion means the auditor concluded the controls, overall, met the criteria — but the same report can still list individual exceptions found during testing, as long as the auditor judged them not severe or widespread enough to change that conclusion. Look in the body of the report, usually under a section like "Exceptions Noted," rather than relying on the opinion letter alone. A qualified opinion is the more serious case: it means one or more criteria were not met.
What is a subservice organization carve-out, and why does it matter?
Most AI vendors run on top of cloud infrastructure and sometimes a separate model provider — both are subservice organizations. Under the common "carve-out method," the vendor's SOC 2 report discloses the type of controls it assumes those subservice organizations have in place, called Complementary Subservice Organization Controls, but the auditor does not actually test them. In practice this means the vendor's own SOC 2 speaks to the vendor's controls, not necessarily to the security of the cloud or model provider underneath — ask by name which providers are carved out and whether they hold their own current reports.
Should I trust a vendor that only offers a Type I report?
For an early-stage AI tool, a Type I is a reasonable first step and not automatically disqualifying — it takes time to accumulate the observation period a Type II requires. What matters is whether the vendor has been operating long enough that a Type II should exist, and whether they can give you a specific timeline for it. A vendor handling sensitive data that has been in business for years and still can't produce a Type II, or can't say when one is coming, is a legitimate flag.
What should I actually ask an AI vendor for, beyond the badge?
Ask for the full report under NDA, not the summary attestation. Check the report date, the observation window for a Type II, and which Trust Services Criteria are in scope. Read the exceptions section rather than just the opinion letter. Ask directly which cloud and model providers are carved out as subservice organizations, and whether they hold their own current SOC 2 reports. And separately — because SOC 2 won't answer it — ask in writing whether your data is used to train their model.
Is SOC 2 a government certification?
No. SOC 2 is an attestation framework developed by the AICPA (the American Institute of CPAs), and the report itself is produced by an independent licensed CPA firm, not a government agency. It is not a pass/fail certification like a UL listing; it is an auditor's documented opinion on a specific, scoped set of controls over a specific period, which is exactly why the actual report matters more than the badge summarizing it.
Send us the report before you sign
If an AI vendor has handed you a SOC 2 report, forward it along with what you plan to use the tool for. We'll help you read the parts that actually matter — Type I versus Type II, what's in scope, what the exceptions section says, and which subservice organizations are carved out — before you're relying on a badge instead of the document behind it.
Ask for a report reviewSources, read 18 September 2026: AICPA Trust Services Criteria framework documentation; industry compliance-auditor guidance on SOC 2 Type I versus Type II reporting periods and evidentiary weight; guidance on the five Trust Services Criteria and Security as the sole mandatory category; guidance on qualified versus unqualified SOC 2 opinions and the distinction between an exception and a qualified opinion; guidance on the carve-out method, Complementary Subservice Organization Controls (CSOCs), and Complementary User Entity Controls (CUECs) in SOC reports; and 2025–2026 commentary on SOC 2's scope gap for AI-specific risks (model training data, model governance) relative to frameworks such as ISO/IEC 42001. Not legal advice — a vendor's specific report should be reviewed against your own data-handling requirements. Related: Six Clauses to Check Before You Sign and Who Owns What AI Makes for Your Business.
Hero image from Unsplash, used under the Unsplash License.