SOC 2 for AI companies: what actually changes
The Trust Services Criteria have no AI section. What moves is which existing criteria bite, and what evidence satisfies them once customer data leaves for a model provider.
SOC 2 for AI companies is the same examination every other software company sits for. The Trust Services Criteria have no AI category.1 What changes is which existing criteria bite, and what an auditor will accept as evidence for them.
Sending customer data to a model provider makes that provider a subservice organization, moves your vendor file to the middle of the engagement, and puts your data processing agreement in front of a buyer who reads it. Security is the scope. ISO 42001 is a different engagement.
Search this and you get a page explaining that SOC 2 is a security framework, then a paragraph about how AI raises the stakes, then a demo button. Nothing in it names a control that changed. Two things below do. The first is a criteria map: where a model provider actually lands in the common criteria, and the artifact that closes each one. The second is the question list a security reviewer sends, decoded into the document that answers it.
What does not change
Start here. It removes most of the anxiety. A SOC 2 examination tests the controls in your description against the criteria in your scope,2 and those criteria are published by the AICPA as one document for every kind of company. There is no additional criterion for models.
So nobody is coming to test your model. An auditor does not evaluate output quality, bias, hallucination rate or eval coverage, because none of those are security criteria. That work is real. It belongs to a different standard, and that standard is at the bottom of this page.
Where a model provider lands in the criteria
The moment a request carrying customer data leaves your infrastructure for somebody else’s inference endpoint, criteria that were quiet on your last review get loud. Six of them, with the fact pattern that triggers each and the artifact that satisfies it.1
| Criterion | What the model provider changes | What satisfies it |
|---|---|---|
| CC3.2, risk identification | The provider is a new path for customer data to leave your boundary. It belongs on the risk register with a named owner, not in an architecture diagram | Your risk assessment, dated inside the period, naming the provider and the class of data it receives |
| CC6.1, logical access | Your API key to the provider is a production credential. Same scoping, same rotation schedule, same storage as every other one | The secrets manager record plus rotation evidence, tested the way any production key is tested |
| CC6.7, restricted transmission | The criterion this whole question sits under. Customer data moves outside your system boundary on every inference call | The data flow in your system description, the encryption in transit setting, and the rule that decides what is allowed into a prompt |
| CC7.1 and CC7.2, monitoring | Prompt and response traffic is a log source. Log the prompts and you have created a second store of customer data with its own retention question | The retention setting on prompt logs, plus a query returning a real record from the oldest date you claim to hold |
| CC8.1, change management | The provider ships a new model version underneath you. That is a change to your production system that your own change process never saw | Version pinning in configuration, plus the ticket and the approval for each deliberate version move |
| CC9.2, vendor risk | The provider is a subservice organization. Carving it out is ordinary. Carving it out silently is the finding | The vendor assessment, the executed agreement, and the provider’s own report with a dated note recording who read it |
Read the middle column down. Not one of those is an AI control. Each is an ordinary control with a new object inside it, and the auditor tests it the way they always did: population, sample, date, artifact. If you want the criteria themselves rather than this mapping, the Trust Services Criteria guide covers the five categories and what each one commits you to.
The model provider is a subservice organization
This one fact decides how the rest of your report reads. A subservice organization is a vendor whose controls your own service commitments depend on.3 If your product cannot do what you promised when that provider is down, or if a mishandled prompt at the provider would breach what you told a customer, the provider is one.
You then pick a method, and there are two. The inclusive method pulls the provider into your examination with its own management assertion and its own testing. The carve out method names the provider, leaves its controls out of your description, and states the controls you assume it operates. No ten person company is negotiating the first one with a frontier lab. Carve out.
The carve out has a price, and the price is a written assumption. Every control you rely on the provider to run becomes a complementary subservice organization control in your system description, worded well enough that a reader can tell what you are and are not claiming. How to word CUECs and CSOCs covers the difference between a sentence that transfers something and one that reads as decoration.
What your agreement with the provider has to answer
A vendor assessment for a model provider turns on three lines, and none of them are about security architecture. They are about what happens to the text you send.
- Training on your inputs
- Find the clause. Not the marketing page, not a blog post, not a support answer: the executed agreement or the data processing addendum it references. Copy the section number into your vendor file. If your product carries customer data into a prompt and the agreement is silent on training, that silence is the finding.
- Retention at the provider
- How long the provider holds a prompt, where it holds it, and who there can read it inside that window. A retention period you cannot state is one you cannot disclose to your own customer, and it is the third line on the questionnaire below.
- Subprocessors underneath the provider
- Your provider has vendors too, and the one that matters most is where inference physically runs. Region matters if you told a customer their data stays somewhere. Get the list, and get the notice terms for changes to it.
Put the answers in the vendor file rather than in somebody’s memory. What an auditor tests is the record: a dated assessment, the executed agreement, the provider’s own report, and a review note naming who read it and what they concluded. A link to a trust page is none of those. That request already sits on the evidence request list, worded almost exactly that way, and it is the same request whether the vendor runs models or runs payroll.
Change management when the model moves underneath you
This is the one genuinely new operational problem on the list, and it is not an AI problem. Your provider deprecates a version. Your provider ships a point release. Output shifts, prompts drift, and nothing crossed your own change process on the way in.
The fix is boring. Pin the version in configuration. Treat a version move as a change: ticket, review, approval before it reaches production, the same path a schema migration takes. Then the change population you hand over at fieldwork actually contains the changes that happened, which is the entire test.
Skip it and the failure lands somewhere ordinary. The auditor pulls your change population, finds behavior in production that no approved change explains, and asks. Your policy set has to say this out loud too, because a change management policy that describes only your own deploys does not describe your system. The policy list shows which document that language belongs in.
What the security questionnaire is asking
The AI questions on a security review are not about your code. They are about a vendor you do not control, which is why your report answers some of them and cannot answer the rest. Six questions, what each is checking, and the document that closes it.
| The question | What it is checking | What closes it |
|---|---|---|
| Do you use third party language models, and which ones? | Whether there is a data path you have not disclosed | Your vendor register, and the system description that names the provider once it is carved out |
| Is customer data used to train models, yours or theirs? | The training clause, in both directions | The section number in the executed agreement, plus your own written position if you fine tune on customer data |
| How long are prompts and outputs retained? | Whether your retention commitment survives at the provider | The provider’s stated retention period from the agreement, and the retention setting on your own prompt logs |
| Can a customer turn the AI features off? | Whether the data path is a product choice or unavoidable | The product configuration, plus a CUEC if switching it off is something the customer has to do |
| What stops sensitive fields from reaching a prompt? | A control rather than an intention | The redaction or field allow list in code, and a test showing it fires, in the change population like anything else |
| Does your SOC 2 cover the AI features? | Scope, which is the one that catches people | Your system description and the period the report covers, read together rather than separately |
A SOC 2 covers the system described, for the period examined. Ship an AI feature the week after your period closes and the report does not describe it, however good the feature is. Say so on the form. An overstatement there is the rare kind a reviewer can check against the report itself, in about a minute, using the section you sent them.
Scope, and what SOC 2 will not do for you
Polara G.R.C. scopes Security only. That is fixed. It is not a customer setting, and Security is the category a buyer means when they ask whether you have a SOC 2. For the reasoning behind leaving the other four categories out of a first report, the scoping tool walks the decision through.
Security does not reach model behavior. It covers who can reach the data, what happens when the data moves, how a change gets approved, and whether anyone noticed. Accuracy, bias and model lifecycle governance sit outside it. That is not a hole in your report. It is a different subject with its own standard.
ISO/IEC 42001 is that standard. It was published in December 2023, it covers a management system for artificial intelligence, and an accredited certification body issues the certificate. A SOC 2 will not produce one, and that certificate will not produce a SOC 2. Two engagements, two timetables. Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.
Type 1 is $4,000 one time, and the engagement fee for the independent partner auditor is inside that number rather than on a second invoice. Type 2 is $600 per month on a 12-month term, and each examination is $5,000 once the 3-month observation window completes and the subscription is active. Calling a model provider does not move any of those. It moves your vendor file.
Questions
Is there a special SOC 2 for AI companies?
Is a model provider a subservice organization in a SOC 2?
Does a SOC 2 report say whether a model provider trains on your data?
Does a new model version count as a change under SOC 2?
Do you need ISO 42001 as well as a SOC 2?
Sources
Get audit-ready without a compliance team.
$4,000 one time for SOC 2 Type 1, with the first examination and the auditor engagement fee included. audit-ready starting at about a week.
Get startedPolara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.