SOC 2 for an AI Vendor: Which Trust Service Criteria Apply

SOC 2 is an attestation engagement performed by a licensed CPA firm against the AICPA’s trust services criteria. It has no AI-specific criteria and is not going to get any soon, which means every AI-related control an auditor tests has been mapped onto criteria written for service organisations generally. Knowing which criteria your controls land under is most of the work.

What a SOC 2 report is, precisely

Three things about the instrument change how you should read it. First, the scope is defined by the service organisation itself, in the system description, and the auditor gives an opinion on whether that description is fairly presented and whether the controls in it were suitably designed — and, in a Type 2, whether they operated effectively over a stated period. A Type 1 is a point in time; a Type 2 covers a window, typically six or twelve months, and only a Type 2 tells you anything about whether controls actually ran.

Second, the criteria come from the AICPA’s trust services criteria (TSP section 100), in five categories: security, availability, processing integrity, confidentiality and privacy. Only security is mandatory. Its criteria are the common criteria, numbered CC1 through CC9, and CC1 to CC5 are structured around the seventeen COSO internal control principles. Everything else is opt-in by the service organisation.

Third, a SOC 2 report is not a certificate and there is no accreditation register behind it. It is an opinion letter with evidence attached. That is a genuine difference from an accredited ISO certificate — see what accredited certification adds over a self-assessment — and neither instrument substitutes for the other.

Security: the only mandatory category

Every SOC 2 includes security, and for an AI vendor the common criteria land in some specific places.

• CC6, logical and physical access. Who can call the model endpoints, how API keys are issued, rotated and revoked, whether keys are scoped per tenant, and how the inference environment is segregated between customers. If you fine-tune on customer data, the question underneath is whether the resulting weights are a tenant-scoped asset with the same access controls as the data that produced them — auditors increasingly ask this and it is a control most young vendors have not written down.
• CC7, system operations. Monitoring, anomaly detection, and incident management. For an AI vendor this has to cover AI-specific incidents — a prompt injection that caused data to be returned to the wrong party is an incident under CC7 and often gets classified as a product bug instead.
• CC8, change management. The one that catches people. Swapping the underlying model, changing a system prompt, or altering a retrieval index changes system behaviour, and if your change management process only covers code deployments then a material behavioural change is happening outside the control.
• CC9, risk mitigation, including vendor management.Your model providers are subservice organisations or vendors, and this is where their assessment, their contracts and their monitoring get evidenced.

Confidentiality and the prompt-retention question

Confidentiality has a small set of criteria — identifying and maintaining confidential information, and disposing of it — and for an AI vendor almost all the substance is in one question: what happens to prompts and completions.

To evidence it, you need a written retention position, a technical mechanism that implements it, and a record that the mechanism ran. Concretely: how long request and response bodies are stored, whether they are stored at all in logs and traces, whether they are used for training or evaluation, whether that is a customer-configurable setting, and what the deletion path is including backups. The failure mode is almost always the same — a clean statement in the contract, a clean setting in the product, and prompt bodies sitting in an observability tool for ninety days because that pipeline was never in scope of the retention decision.

The subprocessor dimension belongs here too. If you forward customer text to a third-party model provider, that provider’s own retention policy is part of your confidentiality story, and it changes when they change it. See what subprocessor disclosure requires for the data-protection side of the same fact.

Processing integrity, where AI vendors overclaim

Processing integrity is the category AI vendors most often add and most often misunderstand. Its criteria concern whether system processing is complete, valid, accurate, timely and authorised — against the entity’s own defined processing objectives.

That last clause is the whole thing. Including processing integrity does not mean an auditor has tested whether your model gives correct answers. It means you defined what correct processing is for your system and the auditor tested controls over that definition. If your objective is “every submitted request is processed exactly once and the response returned to the requesting tenant is the response generated for that request”, that is testable and worth attesting. If a salesperson translates the same badge into “our outputs are audited for accuracy”, that is a misstatement of what the report says, and it is the kind of misstatement that has drawn regulatory attention to AI marketing claims generally — see how AI accuracy claims are treated as advertising claims.

Where processing integrity genuinely earns its place for an AI vendor is around pipeline completeness: documents ingested equals documents indexed, retrieval returning only records the requester is entitled to, batch jobs whose partial failures are detected rather than silently truncating a corpus.

Privacy and availability

The privacy category is derived from generally accepted privacy principles and covers notice and choice, collection, use and retention, access, disclosure to third parties, quality, and monitoring and enforcement — but only in relation to personal information. It is the least commonly included category, partly because most B2B AI vendors are processors rather than controllers of the personal data flowing through them, and the privacy criteria are written from a controller-shaped perspective. Including it when your customers are the ones making the notice and choice decisions produces a report full of criteria answered by pointing at somebody else.

Availability is narrower and easier: performance monitoring, capacity management, environmental protections, and backup and recovery. For an AI vendor the interesting content is dependency availability. Your service level is bounded by your model provider’s, and if you have no failover the honest availability control is a monitoring and communication control rather than a recovery one. If you do have failover, the control needs evidence that it has been exercised, not only that it is configured.

Reading somebody else’s report

When a report arrives from a vendor, four things decide whether it tells you anything.

1. The opinion. Is it unqualified? A qualified opinion is not a disaster but it names something specific, and that something is usually the most informative sentence in the document.
2. The period and the categories. A Type 2 covering twelve months and a Type 1 issued last week are different assurances. Check which categories beyond security are in scope, because a “SOC 2 Type 2” with security only says nothing about confidentiality.
3. The system description. Confirm the product you are buying is the system described. A report scoped to a platform that does not include the new AI feature is common and easy to miss.
4. Subservice organisations and complementary controls.Find whether model providers are carved out or included, and read the complementary user entity controls — that list is the vendor telling you, in writing, which controls are your job. It is routinely skipped and it routinely contains the obligation you assumed they had.

Finally, read the exceptions in the testing tables rather than only the opinion. A Type 2 that discloses two exceptions with remediation described is usually a better-run organisation than one with a spotless table and a scope narrow enough to guarantee it.