Does SOC 2 Cover AI? What Auditors Now Test

Not specifically. As of August 2026 the AICPA has published no AI-specific Trust Services Criteria, so an AI company's SOC 2 report is issued against the same Trust Services Criteria as any other SaaS vendor. Be precise about what that set is, because it is not five categories in every report: Security is mandatory and appears in all of them, while Availability, Processing Integrity, Confidentiality and Privacy are optional and appear only where management selects them, usually because a customer contract names one. What has changed is interpretation, not the criteria: auditors increasingly request AI-shaped evidence under the existing Security and Confidentiality criteria, including training-data controls, prompt and inference logging, model change management, and vendor risk assessments for third-party model providers. If a buyer wants attested AI governance specifically, that is ISO/IEC 42001 territory, because SOC 2 produces an auditor's opinion on your controls rather than a statement about how you govern AI.

This article covers where AI evidence actually lands inside the existing criteria, what auditors are asking for in practice, what SOC 2 structurally cannot tell a buyer about AI, and how to decide whether you need a second report.

Key takeaways

• There are no AI-specific Trust Services Criteria as of August 2026. The existing criteria carry the whole load: mandatory Security, plus any of the four optional categories you scoped in.
• AI evidence lands mostly under Security (CC6, CC7, CC8) and Confidentiality, not under a new section.
• Auditors now commonly ask for model inventory and lineage, prompt and inference logging, and third-party model provider risk assessments.
• SOC 2 says nothing about model fairness, explainability or societal impact, and a buyer asking about those needs a different artifact.
• The common pairing for AI companies selling to enterprises is a SOC 2 report plus an ISO 42001 certificate, and they answer different questions.

What the Trust Services Criteria actually say about AI

Nothing, by name. The Trust Services Criteria are outcome-based: they describe what a control environment must achieve rather than which technologies it must achieve it for. That design is why the criteria have absorbed cloud, containers, infrastructure as code and now machine learning without amendment, and it is also why "does SOC 2 cover AI" has no clean yes-or-no answer.

The practical consequence is that AI systems are in scope to exactly the extent that they sit inside your system boundary and support the service commitments in your description. If your product's core feature calls a model, that model and the pipeline around it are part of the system being reported on, whether or not the word "AI" appears anywhere in the criteria.

Where this trips companies up is scoping. We see AI features excluded from the system description because they were treated as experimental, then included in the sales narrative to the same customers who received the report. That gap is visible to any reviewer who reads both documents, and it is the kind of thing that turns a routine security review into a long one. If the feature is in the product, put it in the description.

Where AI evidence lands inside the existing criteria

Auditors are not inventing a new section; they are asking harder questions inside the sections that already exist.

Logical access (CC6)

Who can reach training data, model artifacts, and the credentials for third-party model APIs? Model API keys are production credentials and are frequently managed worse than database credentials, which is a finding waiting to happen.

System operations and monitoring (CC7)

What do you log at inference time, and how do you detect abnormal behavior in a system whose normal behavior is probabilistic? This is where prompt and output logging comes up, along with the privacy problem it creates: logs that capture prompts capture whatever customers put in them.

Change management (CC8)

A model version change is a production change. Auditors increasingly ask to see model changes moving through the same approval, testing and rollback path as code changes, and "we updated the model" as an untracked event is the answer that generates a follow-up.

Vendor management (CC9)

Third-party model providers are sub-service organizations or vendors depending on how you have carved the system, and either way you owe a risk assessment. We cover what to ask them in AI Vendor Risk Assessment: The Questions That Matter.

Confidentiality

If customer data reaches a model, the confidentiality commitments in your description have to be true about that path too, including retention at the provider.

Processing Integrity, if you selected it

This is the criterion buyers most often assume covers model accuracy. It does not, and the distinction is covered below.

What auditors are asking for in practice

Three requests come up repeatedly in AI-heavy engagements, and none of them are new controls so much as new evidence for old ones.

A model inventory with lineage: which models are in production, which version, trained or fine-tuned on what data, approved by whom. This is the same artifact an AI governance program needs, which is a good argument for building it once.

Logging that covers the inference path, with a documented position on what is captured, how long it is kept, and how customer content in prompts is protected. The tension between "log enough to monitor" and "do not retain customer content" is real, and auditors want to see that you resolved it deliberately rather than by default.

Risk assessments for third-party model providers, current rather than filed at onboarding two years ago, because the terms and default retention settings of those providers move.

Audit firms have been publishing on this. Baker Tilly has written about evolving SOC 2 reports for AI controls, and the practitioner consensus in that material is consistent: the criteria have not changed, the evidence expectations have.

What SOC 2 structurally cannot tell a buyer

This is the section worth sending to whoever is arguing that your report should be enough.

A SOC 2 report is an opinion on whether controls relevant to the selected criteria were suitably designed and, for a Type II, operated effectively over a period. It says nothing about whether your model is accurate, whether its outputs are fair across groups, whether the training data was lawfully obtained, whether the system is explainable, or whether anyone assessed its impact on the people it makes decisions about.

Processing Integrity is the criterion that sounds like it should cover accuracy, and it does not. It addresses whether processing is complete, valid, accurate, timely and authorized with respect to your own defined objectives. If your objective is "return a model response," a wrong answer is not a Processing Integrity exception. That is a genuine limitation rather than a loophole, and buyers reading the report as an accuracy assurance are misreading it.

Those questions are what an AI management system standard is for. If a buyer is asking them, adding criteria to a SOC 2 report will not get you there. This is also the cleanest way to explain the difference internally: SOC 2 yields an opinion on control operation, while ISO 42001 yields a certificate confirming a management system meets a published standard.

When you need ISO 42001 as well

The pairing is common and the division of labor is clean. SOC 2 answers "are this company's security controls working," which is the question the security team asks. ISO 42001 answers "does this company govern its AI systematically," which is the question the AI risk or procurement team now asks alongside it.

You need the second one when a customer, regulator or partner names it, when you sell into segments with AI-specific procurement requirements, or when the questions coming back from reviews are consistently about governance rather than security. You do not need it because AI is in your product. Plenty of AI companies sell perfectly well on a SOC 2 report plus documented NIST AI RMF alignment, which costs nothing to adopt.

We work through that choice, including what to send a reviewer who has not named a standard, in NIST AI RMF vs ISO 42001: Which Do You Need?.

When we would tell you not to add anything

If your only AI is a third-party feature nobody has asked about, do not expand your SOC 2 scope to cover it preemptively. Scope costs money every year, forever, and an expanded description is harder to shrink than to grow.

If you are pre-report and choosing between starting SOC 2 and starting ISO 42001, and your buyers are security teams rather than AI procurement functions, start with SOC 2. It is the artifact more of your customers already know how to read, and an unfamiliar certificate does less work in a review than a familiar report.

And if an auditor tells you they will issue an AI-specific opinion under the Trust Services Criteria, ask which criteria. As of August 2026 there are none, and a firm implying otherwise is describing its own methodology as though it were a standard.

Where Top Floor fits

Our SOC 2 work scopes AI features into the system description honestly, which mostly means deciding early whether a feature is in the product or in the lab, and building the model inventory and change-management evidence before the auditor asks rather than during fieldwork. Where the buyer questions are actually governance questions, our ISO 42001 practice runs the management system alongside, sharing the evidence that both need.

We will also tell you when documented NIST AI RMF alignment is enough and a second audit is not, which is the recommendation more often than the reverse.

How to decide this week

• Read your own system description and check whether every shipped AI feature is inside it. Fix the gap in the direction of honesty.
• Build the model inventory with lineage, because SOC 2 evidence and AI governance both need it and neither will accept a spreadsheet nobody updates.
• Write down your position on prompt and inference logging: what is captured, how long it is kept, how customer content is protected.
• Refresh the risk assessment for every third-party model provider, and check the current default retention setting rather than the one you documented at onboarding.
• Ask your last three enterprise buyers whether they wanted security assurance or AI governance assurance. The answer tells you whether a second artifact is worth buying.

Frequently asked questions

Does SOC 2 have AI-specific criteria?

No. As of August 2026 the AICPA has published no AI-specific Trust Services Criteria, so an AI company reports against the same criteria set as any other service organization: Security, which every SOC 2 includes, plus whichever of Availability, Processing Integrity, Confidentiality and Privacy it selects. The criteria are outcome-based rather than technology-specific, which is why they have absorbed cloud, containers and now machine learning without amendment. What has changed is the evidence auditors request under the existing criteria, not the criteria themselves.

What AI evidence do SOC 2 auditors ask for?

Three requests recur: a model inventory with lineage showing which models are in production, on which version, trained or fine-tuned on what data and approved by whom; a documented position on inference-path logging covering what is captured, how long it is retained and how customer content inside prompts is protected; and current risk assessments for third-party model providers rather than ones filed at onboarding. Model API keys are also production credentials and get logical-access scrutiny accordingly, and a model version change is treated as a production change under change management.

Does a SOC 2 report prove my AI model is accurate or fair?

No, and Processing Integrity is the criterion most often misread on this point. It addresses whether processing is complete, valid, accurate, timely and authorized against your own defined processing objectives, not whether a model's outputs are correct or fair across groups. A SOC 2 report also says nothing about explainability, the lawfulness of training data, or the assessed impact of the system on the people it affects. Those questions belong to an AI management system standard such as ISO/IEC 42001, and adding criteria to a SOC 2 report will not answer them.

Do AI companies need both SOC 2 and ISO 42001?

Many enterprise sellers end up with both, because they answer different questions: SOC 2 gives an auditor's opinion on whether security controls were suitably designed and operating, while ISO/IEC 42001 gives a certificate that an AI management system meets a published international standard. Buy the second one when a customer, regulator or partner names it, or when review questions are consistently about governance rather than security. Plenty of AI companies sell successfully on a SOC 2 report plus documented NIST AI RMF alignment, which is free to adopt and is worth trying before paying for a second audit cycle.