SOC 2 and AI Deployment Controls
Written by Jakub Rusinowski · Last updated 2026-09-13 · Assessment logic is deterministic and runs in your browser
This section is practitioner guidance on deployment and governance mechanics, not legal advice. Regulatory classification turns on facts about intended purpose and real-world use that a questionnaire cannot establish — involve your counsel or DPO for decisions about your specific obligations.
SOC 2 is an attestation engagement, not a certification. An independent CPA firm reports on a service organisation's controls against the AICPA Trust Services Criteria: security as the common criteria, plus optionally availability, processing integrity, confidentiality and privacy. A Type I report addresses design at a point in time; a Type II addresses operating effectiveness over a period. No tool can produce a SOC 2 report, and nobody is "SOC 2 certified".
SOC 2 Attestation — a CPA firm reports on your controls
- Version Trust Services Criteria (2017, as revised)
- Publisher American Institute of Certified Public Accountants (AICPA)
- Last verified 2026-09-13
An attestation engagement in which an independent CPA firm reports on a service organisation's controls against the Trust Services Criteria: security (the common criteria), and optionally availability, processing integrity, confidentiality and privacy. A Type I report addresses design at a point in time; a Type II report addresses operating effectiveness over a period.
What this tool does not do
- SOC 2 is an attestation performed by a licensed CPA firm. There is no "SOC 2 certification", and no tool can produce a SOC 2 report.
- The Trust Services Criteria are AICPA material. We store criterion identifiers and our own descriptions only.
- Our mapping points at the common criteria most often relevant to an AI deployment. Your auditor defines the actual scope, and a control we flag may sit outside it.
The three things buyers get wrong about SOC 2
"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.
Which criteria an AI deployment actually touches
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.
What SOC 2 does not tell you about an AI system
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.
Deployment controls that relate to Trust Services Criteria
Criterion identifiers with our own descriptions — AICPA material is published under its own terms. Your auditor defines the actual scope, and a control flagged here may sit outside it.
Human oversight of AI output CTL-OVERSIGHT-001
A named human role that can understand the system's output and limitations, decide not to use it, and override or reverse it — with the authority and the time to actually do so. Oversight is a staffed procedure, not a checkbox in a UI.
CC5 — Conceptual · low confidence
Control activities, including those performed by people over automated processing
Conceptual. The Trust Services Criteria concern controls over the service commitments an organisation makes, not over harm to third parties. An oversight procedure may be in a SOC 2 scope, but SOC 2 does not require oversight of AI decisions about people.
Last verified 2026-09-13
Personal data handling in the inference path CTL-PRIVACY-001
Establish the lawful basis, the data minimisation position and the retention rule for personal data that enters prompts, retrieval context or logs. Inference logging is the common failure: a system designed not to store personal data often stores it anyway, in the log.
P-series (Privacy criteria) — Strong · medium confidence
Privacy criteria on collection, use, retention and disposal of personal information
The privacy category of the Trust Services Criteria addresses notice, collection, use, retention and disposal. Applies only where the organisation has elected the privacy category into its SOC 2 scope, which many do not.
Last verified 2026-09-13
Inference and audit logging CTL-LOGGING-001
Record what the system was asked, what it answered, which model version answered, who was involved and when — to a retention period you chose deliberately. For high-risk systems the deployer must keep the automatically generated logs.
CC7.2 — Strong · high confidence
Monitoring system components for anomalies indicative of malicious or erroneous behaviour
The common criteria on monitoring depend on logging as their input. Strong rather than direct because CC7.2 is about detection, and this control is about the record itself.
Last verified 2026-09-13
Access control and network isolation for the inference endpoint CTL-SEC-001
Authenticate and authorise every caller of the model endpoint, and place the endpoint where only intended callers can reach it. An internal model server on an open port is a data-exfiltration path with a chat interface.
CC6.1 / CC6.6 — Direct · high confidence
Logical access security, and protection against threats from outside the system boundary
The common criteria on logical and physical access map directly to endpoint authentication and network placement.
Last verified 2026-09-13
AI incident detection and response CTL-INCIDENT-001
A route for someone to report that the system did something wrong, a person who owns the response, and a record of what happened. For high-risk systems, serious incidents carry a reporting duty with a deadline.
CC7.3 / CC7.4 — Strong · high confidence
Evaluating security events and responding to identified incidents
Same shape as the ISO mapping and the same caveat about what counts as an incident.
Last verified 2026-09-13
Named accountability and AI literacy CTL-GOV-001
Someone owns this system by name. The people operating it understand what it can and cannot do. Article 4 of the AI Act makes AI literacy a duty for providers and deployers, and it applied from February 2025 — earlier than most of the rest.
CC1.3 / CC1.4 — Strong · medium confidence
Management establishing structures and reporting lines, and commitment to competence
The control environment criteria address organisational structure and competence, though for the service organisation as a whole rather than for one AI system.
Last verified 2026-09-13
Assess a specific deployment
The generic answer is on this page. The specific one depends on what your system is for, who it affects and what it decides — which is what the assessment asks about.
Automated assessment based on the information you provide. Not legal advice, certification or an audit.