SOC 2 and AI Deployment Controls

"SOC 2 certified" is not a thing. SOC 2 is an attestation: a CPA firm expresses an opinion on management's description of a system and the suitability of the design — and for Type II, the operating effectiveness — of the controls. There is no certificate and no certifying body. A vendor claiming certification is either being loose with language or has not read their own report. The scope is chosen by the organisation being audited. A SOC 2 report covers a defined system, over a defined period, against the criteria the organisation elected. Security (the common criteria) is always included; availability, processing integrity, confidentiality and privacy are optional. So "we have a SOC 2" answers almost nothing on its own. The questions that matter are: which system, over what period, which criteria, and what exceptions did the auditor note. That last one is where the useful information is, and it is why you read the report rather than the badge. A Type II says nothing about your AI deployment unless it was in scope. If the report covers a SaaS platform and you are asking about the LLM assistant someone added last quarter, the answer is almost certainly that it was not in the period, in the description, or in the system boundary.

Most of what an AI deployment needs from a SOC 2 perspective is in the common criteria and is not AI-specific:

• CC6 — logical and physical access. The inference endpoint authenticates callers; the retrieval corpus enforces the same access boundaries as the documents in it; the GPU host is not reachable from places it should not be.
• CC7 — system operations. Monitoring, detection, and incident response. The AI-specific widening applies here: your incident definition needs to include a system that worked as designed and produced a harmful output.
• CC5 — control activities, which is where a human oversight procedure sits if you have one.
• CC1 — control environment, which covers organisational structure and competence. The closest SOC 2 gets to the AI-literacy question.

If your organisation elected the confidentiality or privacy categories, those bring the more interesting AI questions: what personal data enters prompts and logs, what the retention rule is, and whether the disposal actually happens. Most organisations have not elected privacy, which is worth knowing before you rely on a report to answer a personal-data question.

This is the section to read if you are evaluating a vendor rather than preparing your own report.

A clean SOC 2 Type II report tells you that an auditor tested a set of controls over a period and found them operating. It does not tell you:

• whether the AI system is correctly classified under the EU AI Act,
• whether the model's outputs are accurate, fair, or monitored for drift,
• whether anyone can override a decision the system makes about a person,
• what data the model was trained on, or what the vendor's rights in it are,
• whether the model version changes under you and whether you are told.

None of those are SOC 2 failures — they are simply outside what the Trust Services Criteria address. The vendor evaluation checklist covers the questions that fill the gap, and the honest framing for procurement is: a SOC 2 report is table stakes for the security conversation and irrelevant to the AI governance conversation.