From Sidhant Tamrkar | Product & Market Analysis
SOC 2 Trust Services Criteria for AI: What Applies and What Falls Outside
On this page
A SOC 2 report tests a system against up to 61 trust services criteria, and not one of them was written with a model in mind. We mapped 12 common AI risks to the AICPA criterion text. Only 3 land in Security, the one category every SOC 2 report covers. Six live in the optional categories, and 3 fall outside every criterion that exists today.
Key takeaways
- Only 3 of 12 AI risks are tested in every SOC 2 report. Prompt injection, credential theft and unannounced model changes map to the Security common criteria, which every report includes, while the other 9 depend on scope choices or sit outside the framework entirely.
- Processing integrity is the category written closest to AI output risk. Its criterion PI1.4 asks that output be delivered completely, accurately and on time in accordance with specifications, which is the plainest available text for a hallucination control.
- Training on customer data is a confidentiality and privacy question, not a security one. C1.1 and the privacy use limitation criterion carry it, so a Security-only report can be clean while saying nothing about it.
- Bias, explainability and output ownership fall outside all 61 criteria. The AICPA's October 2026 exposure draft proposes AI points of focus, but they could not apply before engagements beginning on or after 31 December 2027.
The short answer. All 5 trust services criteria categories can apply to an AI system, but only Security applies by default. Processing integrity covers output accuracy, Confidentiality and Privacy cover training data use, and Availability covers inference capacity. Bias, explainability and output ownership fall outside every criterion. Choose your categories from the AI risks your customers actually ask about.
The 5 trust services criteria categories, read for AI
The AICPA trust services criteria are the control objectives a SOC 2 auditor tests against. They sit in TSP section 100, issued in 2017, with points of focus revised in 2022. Points of focus are illustrations of how a criterion might be met. They are not requirements, and an auditor can apply a criterion to technology no point of focus mentions.
The criteria fall into 5 categories. Security holds the 33 common criteria, numbered CC1 to CC9, and is present in every SOC 2 report. Availability adds 3 criteria, Confidentiality adds 2, Processing Integrity adds 5 and Privacy adds 18. You choose the optional categories with your auditor, usually based on what your customers ask for.
That choice is where most of the AI coverage gets decided. A previous post here covered the evidence pack auditors now sample under the Security common criteria. This post goes the other way. It starts from the AI risks, finds the criterion that fits each one, and counts how many land in categories your report may not include.
For a conventional SaaS product, Security does most of the work. Bugs in business logic are real, but they rarely become the headline risk a buyer asks about. With a model in the product, the headline risks are different in kind. Buyers ask whether outputs are accurate, whether their data trains someone else's model, and whether the service survives a provider outage.
None of those 3 questions is primarily a security question. Each has a natural home in an optional category. My view is that most AI vendors scope their reports as if they were still selling conventional software, and their buyers have not yet noticed the gap.
The AI risk to trust services criteria mapping table
This is the core of the post. Each row names an AI risk, the criterion whose text fits it best, and the category that criterion belongs to. Where a second criterion helps, it is listed. The mapping is my reading of the criterion text, not an AICPA position, and the limitations section below says where it is most contestable.
| AI risk | Best-fit criterion | Category | Tested by default? |
|---|---|---|---|
| Prompt injection, direct or through retrieved content | CC7.2 anomaly monitoring; PI1.2 input controls as a second fit | Security | Yes |
| Theft of API keys, model weights or admin access | CC6 logical access series | Security | Yes |
| Provider swaps or updates the model without notice | CC8.1 change management; CC9 vendor risk | Security | Yes |
| Customer data used to train or fine-tune a model | C1.1 identify and maintain confidential information; privacy use limitation | Confidentiality, Privacy | No |
| Prompts and outputs retained past the agreed period | C1.2 disposal of confidential information | Confidentiality | No |
| Hallucinated or inaccurate output reaching a customer | PI1.4 output controls | Processing integrity | No |
| Model drift degrading quality over time | PI1.3 processing controls | Processing integrity | No |
| Poisoned retrieval corpus or fine-tuning data | PI1.2 input controls; CC8.1 covers changes to data | Processing integrity | No |
| Inference capacity limits and provider outages | A1.1 capacity; A1.2 recovery infrastructure | Availability | No |
| Biased outcomes in automated decisions | No criterion fits | None | No |
| Explainability of an individual output | No criterion fits | None | No |
| Ownership and infringement risk in generated output | No criterion fits | None | No |
Criterion references are to the AICPA 2017 trust services criteria with 2022 points of focus. Risk names follow the OWASP Top 10 for LLM Applications where one exists. An auditor may reasonably map a row to a neighbouring criterion. The count that matters is the category column.
Group the category column and the result is 3, 6 and 3. Three risks sit in Security and are tested in every report. Six sit in the 4 optional categories and are tested only if you scoped them in. Three sit nowhere. That is the working behind the claim in the opening paragraph, and you can recount it from the table.
Put differently, a clean Security-only SOC 2 report from an AI vendor speaks to a quarter of this list. I would not read such a report as evidence about output accuracy or training data use. It was never designed to carry that weight.
What the Security common criteria always cover for AI
Security is the only category you cannot drop. Its 33 criteria are technology neutral, which cuts both ways. They reach a model endpoint without amendment, but they say nothing specific about how a model fails.
Prompt injection is an anomaly monitoring problem first
OWASP ranks prompt injection first in its Top 10 for LLM Applications, describing crafted inputs that steer a trusted model, either directly or through content the model later reads. The closest Security text is CC7.2. It asks the entity to monitor "for anomalies that are indicative of malicious acts, natural disasters, and errors".
That wording fits a detection control, such as logging prompts and flagging suspicious tool calls. It fits prevention less well. The design work of separating untrusted content from instructions is covered in the breakdown of prompt injection defences for agents, and an auditor will test only whatever control you describe.
Model change control lives in CC8.1
CC8.1 requires that the entity "authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures". Note the word data. A new fine-tuning set or a refreshed retrieval index is a change to data, and the criterion already reaches it.
The harder case is the change you did not make. A provider can update the model behind an alias without any ticket in your system. I would treat a pinned model version as the control and the provider's deprecation notices as the change trigger. Without a pin, there is no change record for an auditor to sample.
Processing integrity is where AI output accuracy belongs
Processing integrity is the category written closest to the risks buyers worry about most. The AICPA frames it around whether system processing is complete, valid, accurate, timely and authorised. Its 5 criteria run from inputs through processing to output and storage, which maps neatly onto a model pipeline.
My position is blunt. If your product's value is a model's output, processing integrity belongs in your report. Leaving it out tells an informed reader you would rather not be tested on the thing you sell.
PI1.1 forces you to write down what correct means
PI1.1 asks the entity to obtain and communicate quality information about processing objectives, "including definitions of data processed and product and service specifications". For a deterministic system, a specification is straightforward. For a model, it is the hard part.
A usable specification names the task, the acceptable error rate and how it is measured. That is an evaluation suite in all but name. The method for building one is laid out in the guide to building an LLM evaluation suite, and the suite's results become your PI1.1 evidence.
PI1.4 is the closest thing to a hallucination criterion
PI1.4 asks for procedures to deliver output "completely, accurately, and timely in accordance with specifications". Pair it with a PI1.1 specification and you have a testable control. Output is checked against an evaluation threshold, and failures are blocked, flagged or routed to a person.
An auditor cannot test whether a model is accurate in general. They can test whether your control ran, whether thresholds were met, and what happened when they were not. That is a narrower claim than buyers assume, and it is the honest one.
PI1.2 covers controls over system inputs, including completeness and accuracy. A retrieval corpus is an input, so source allow lists and ingestion checks fit here. PI1.3 covers processing itself, which is where drift monitoring belongs. The operational side of drift is covered in the analysis of agent drift in production.
Confidentiality, privacy and availability carry the data and uptime questions
The question buyers ask first about any AI vendor is whether their data trains a model. Under the trust services criteria, that is not a Security question. It sits with Confidentiality and Privacy, and the CBIZ sample suggests Confidentiality is now common but far from universal.
C1.1 and C1.2 cover use and disposal
C1.1 requires that the entity "identifies and maintains confidential information to meet the entity's objectives related to confidentiality". If your commitment says customer data is never used for training, that commitment becomes the objective, and the control is whatever stops training from happening.
C1.2 covers disposal of confidential information. For an AI system that means prompt logs, output caches, vector embeddings and anything sent to a provider with its own retention period. Embeddings are the item most teams forget, because they do not look like the source document. Provider retention terms are compared in the ranking of AI vendor data retention periods.
Privacy applies only when personal information is involved
The privacy criteria apply only to personal information, while confidentiality can apply to any sensitive information. The privacy series includes a use limitation criterion, P4.1, which restricts use of personal information to the purposes in your privacy objectives. Training on personal data without a stated purpose is the obvious failure.
Privacy is also the category most vendors avoid, because its 18 criteria are a heavy lift. I think that is usually the right call for a B2B AI vendor. Confidentiality with a precise training commitment answers the buyer's question with far less scope.
Availability and the inference dependency
Availability has only 3 criteria, and it is the optional category most often included, at 75.3% of the CBIZ sample. A1.1 covers capacity: the entity "maintains, monitors, and evaluates current processing capacity" to manage demand. A1.2 covers recovery infrastructure.
For an AI product, capacity is partly rented. Rate limits and provider outages are capacity events you do not control. A credible A1 control monitors provider rate limit headroom and names a fallback model or a degraded mode. Many vendors claim availability while depending on a single provider with no fallback, which is a statement an auditor will test.
| If your product | Add this category | Because the buyer's risk is |
|---|---|---|
| Produces outputs customers act on, such as extraction, classification or drafted decisions | Processing integrity | Wrong output, which PI1.4 tests against your own specification |
| Sends customer documents or prompts to a model provider | Confidentiality | Training use and retention, which C1.1 and C1.2 carry |
| Processes personal data about individuals at scale | Privacy | Use beyond stated purpose, covered by the use limitation criterion |
| Sits in a customer's critical workflow | Availability | Provider outage and capacity limits under A1.1 and A1.2 |
| Where Security alone is the right answer | None | An internal tool with no customer-facing output and no customer data sent out |
What falls outside every trust services criterion
Three risks in the table have no home, and stretching a criterion to cover them would mislead a reader. The trust services criteria test whether controls meet your own stated objectives. They do not test whether those objectives are fair, explainable or lawful.
Bias and fairness have no criterion
Nothing in the 61 criteria asks whether automated decisions treat groups of people equitably. A processing integrity objective could include a fairness metric, and then PI1.4 would test it. But the framework does not require one, and most reports will not contain it. For hiring and lending use cases, that gap is where regulation is filling in instead.
Explainability and output ownership have none either
No criterion requires that an individual output be explainable to the person it affects. None addresses whether generated output infringes someone else's rights. These are legal and governance questions. For them, frameworks such as ISO/IEC 42001 are the better fit, and the gap between the two is covered in the piece on ISO 42001 certification readiness.
My recommendation is to say so in your system description. A sentence stating that the report does not address model fairness or output ownership is more credible than silence, and it stops a procurement reviewer assuming coverage that does not exist.
What the 2027 exposure draft changes, and when
On 26 October 2026, the AICPA Assurance Services Executive Committee released exposure drafts of proposed 2027 trust services criteria and description criteria. The Journal of Accountancy reported that new points of focus address AI governance, model monitoring, prompt manipulation, data poisoning, transparency of AI-generated outputs, training data management and automated decision-making risks.
The AICPA's release sets comments due by 15 January 2027. If approved, the criteria would apply to engagements beginning on or after 31 December 2027, with early adoption permitted. Amy Pawlicki, the AICPA's vice president of assurance and advisory innovation, said the revisions are "intended to improve the usability of SOC 2 reports and refine criteria so they can adapt to rapidly evolving technologies".
Separately, on 11 September 2026 the AICPA published TQA section 9561, technical questions and answers on how a service organisation's use of AI affects SOC 1 and SOC 2 examinations. I could not read its full text, which sits behind an AICPA account, so I have not characterised its contents here.
Points of focus are illustrative even once final, so the draft changes what auditors look for rather than what is mandatory. I would not wait for it. Every AI topic on its list already maps to an existing criterion in the table above, so the controls you build now will carry over.
Where this mapping is weakest
The mapping table is my reading of criterion text, not an authoritative interpretation. Auditors exercise judgement, and two competent firms could place prompt injection under CC6 rather than CC7, or put drift monitoring under CC4 rather than PI1.3. The category column is sturdier than the criterion column.
The risk list is also a choice. A different list of 12 would produce a different split, and a list weighted towards infrastructure risks would push more rows into Security. I chose risks that buyers raise in AI vendor reviews, which tilts towards output and data use.
The prevalence data is thin. The CBIZ figures come from 73 reports reviewed by one firm, and the public summary does not give processing integrity or privacy shares. I could not find a primary source for either, so I have not printed one. Treat the claim that processing integrity is rarely included as unverified.
Finally, I could not read the exposure draft or TQA 9561 directly. Both sit behind an AICPA account. The AI topics listed here come from the AICPA's own release and the Journal of Accountancy. The draft may attach those points of focus to criteria differently from my table, and the final version may differ again.
Frequently asked questions
Which SOC 2 trust services criteria apply to AI?
All 5 categories can apply, but only Security is included in every report. Prompt injection, key theft and model change control fall under the Security common criteria. Output accuracy and drift fall under Processing Integrity, training data use under Confidentiality and Privacy, and inference capacity under Availability. Bias, explainability and output ownership fall outside every current criterion.
Does SOC 2 processing integrity cover AI hallucinations?
Indirectly. PI1.4 requires output to be delivered completely, accurately and on time in accordance with specifications, and PI1.1 requires those specifications to be defined. If you define an accuracy threshold and a control that checks output against it, an auditor can test that control. Without a written specification, there is nothing for the criterion to test against.
Is there an AICPA SOC 2 for AI?
No separate AI report exists. The AICPA released an exposure draft of proposed 2027 trust services criteria on 26 October 2026 that adds AI points of focus, with comments due 15 January 2027. If approved, it would apply to engagements beginning on or after 31 December 2027. Until then, reports use the 2017 criteria with 2022 points of focus.
Does a SOC 2 report show whether a vendor trains on my data?
Only if the vendor included Confidentiality or Privacy and made a training commitment that the auditor tested. A Security-only report can be clean while saying nothing about training use. Check which categories are in scope, then search the system description for the vendor's commitments on training and retention before you rely on it.
How many trust services criteria are there?
The 2017 trust services criteria contain 61 criteria. Security holds 33 common criteria numbered CC1 to CC9. Availability has 3, Confidentiality has 2, Processing Integrity has 5 and Privacy has 18. Points of focus sit under each criterion as illustrations and are not requirements. The proposed 2027 revision would consolidate and restructure some criteria.
What AI risks does SOC 2 not cover?
Three common AI risks fit no current criterion: bias in automated decisions, explainability of individual outputs, and ownership or infringement risk in generated content. The criteria test whether controls meet your stated objectives, not whether those objectives are fair or lawful. ISO/IEC 42001 and sector regulation address these areas more directly than SOC 2 does.
How to scope your next report this week
Take the 12-row table and mark each risk your customers have raised in a security questionnaire over the last 2 quarters. Any marked row whose category is not in your current report is a gap a buyer has already noticed. That list, not a framework, should decide whether you add Processing Integrity or Confidentiality.
Then write one sentence for your system description naming what the report does not cover. If you buy AI software instead of selling it, ask each vendor for their scoped categories before you read anything else in the report.
References
- AICPA, 2017 Trust Services Criteria with Revised Points of Focus (2022), TSP section 100. Used for category structure, criterion counts and criterion wording.
- AICPA, AICPA proposes update of SOC 2 trust services criteria, 28 October 2026. Used for comment deadline, proposed effective date and the Pawlicki quote.
- AICPA, Exposure Drafts: Proposed 2027 SOC 2 Trust Services Criteria and Description Criteria, 26 October 2026. Used for release date and issuing committee.
- Journal of Accountancy, Bryan Strickland, AICPA proposes improvements to SOC 2 trust services criteria, 28 October 2026. Used for the list of AI points of focus.
- AICPA, TQA Section 9561, Effect of the Service Organization's Use of AI on SOC 1 and SOC 2 Examinations, 11 September 2026. Used for title and date only.
- CBIZ, The Evolution of SOC Reporting: Key Findings from the 2024 SOC Benchmark Study, Part Two, 12 March 2025. Used for category inclusion rates across 73 SOC 2 reports.
- OWASP GenAI Security Project, Top 10 for LLM Applications 2025. Used for risk names and the prompt injection description.
Weakest point in the source base: the official criteria PDF, the exposure draft and TQA 9561 all require an AICPA account, so criterion wording was checked against independent reproductions rather than the PDF itself. Figures retrieved 30 October 2026; re-verify after the comment period closes on 15 January 2027.
Related reading