SOC 2 for AI companies
Nothing in the Trust Services Criteria mentions a model. What changes is the shape of your system, and four specific things buyers now ask about that a standard SOC 2 scope will miss unless you put them in.
There is no AI-specific SOC 2 and no AI Trust Services category. You buy the same examination every other SaaS company buys, against the same criteria. What changes is the system you are describing, and four things in it that a generic scope will leave out: your model providers as subservice organisations, what you committed about training on customer data, how long prompts and outputs are retained, and whether the model output is a computation your buyer relies on.
Get those four right and a SOC 2 answers most of what an enterprise AI vendor review asks. Leave them out and you will hold a clean report that does not address a single question on the questionnaire, which is the common outcome right now.
Your model provider is a subservice organisation
If customer data leaves your environment for an API run by someone else, that provider is a subservice organisation, and your report has to say so. Most AI companies use the carve-out method, which means naming the provider, describing what it does, and stating the complementary controls you rely on it for. Your reviewer will then read the provider's own report.
The practical difficulty is that model providers change fast, and a report naming a provider you stopped using six months ago is worse than one that describes the class of dependency accurately. Describe the current state, keep the list current between reports, and use a bridge letter to disclose a change of provider between report periods.
| Architecture | Subservice organisation? | What the report must say |
|---|---|---|
| Third party model API, customer data in prompts | Yes | Name the provider, the data sent, the retention terms you contracted for, and the complementary controls you rely on |
| Third party model API, no customer data in prompts | Usually not | Describe it as a vendor rather than a subservice organisation, and be able to show the data never leaves |
| Self-hosted open weights model in your own cloud | No | It is part of your system. Model weights become a change-managed asset like any other deployed artefact |
| Fine-tuned model held by a provider | Yes, and this is the hard one | The training data, who could access the tuned weights, and what happens to them on termination |
| Vector database as a managed service | Yes if it holds customer content | Embeddings derived from customer data are customer data. Reviewers now ask this specifically |
The training data commitment
The most common question in an AI vendor review is whether customer data is used to train models, and the second is how the buyer would know. A SOC 2 can answer both, but only if the commitment is written into your system description rather than left on a marketing page.
Once it is in the description, the auditor tests whether the controls supporting it operated. That is stronger than a contractual promise alone, because somebody independent looked at the mechanism. The control usually looks like a contractual term with the provider, a configuration flag set to disable training, and evidence that the flag is monitored rather than set once and forgotten.
Do not commit to more than you can evidence
A commitment that customer data is never used for training is testable if you can show the provider contract, the configuration, and a periodic check. A commitment that customer data never leaves Canada, or is never seen by a human, is much harder, and an auditor who cannot get evidence for a stated commitment will raise it. Write the commitments you can prove and say nothing about the rest. What an exception looks like in a report is worth reading before you draft them.
Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.
Prompt and output retention
Prompts contain whatever your users paste, and what users paste is consistently more sensitive than the product was designed for. Support transcripts, patient details, source code and payment information all turn up in prompt logs at companies that never intended to store any of it.
Treat prompt and output logs as customer data with a retention period, not as application logs. Set the period, enforce it, and be able to show it was enforced. This is where Canadian privacy law arrives: PIPEDA's limiting principles and Quebec's Law 25 retention duty apply to that store regardless of what your SOC 2 covers, and a Quebec buyer will ask for the retention schedule by name.
Do we need the Processing Integrity criteria?
Usually not, and this is where AI companies are being talked into scope they do not need. Processing Integrity tests whether processing is complete, valid, accurate, timely and authorised. Applied to a model, that reads as a promise about output quality, and no criterion in the framework asks an auditor to assess whether a model is right.
Include it when your product computes something the customer acts on without checking, and where being wrong has a consequence they would attribute to you: a claims decision, a pricing output, an extraction feeding a financial record. Do not include it because the product contains a model. If a buyer names it in writing, ask them what they expect it to tell them, because the answer is often something Processing Integrity does not cover.
What about ISO 42001?
ISO 42001 is a management system standard for artificial intelligence, and it is the thing buyers will increasingly ask for alongside a SOC 2 rather than instead of one. It addresses AI governance directly: impact assessment, intended use, human oversight, and the lifecycle of a model. SOC 2 addresses none of that, and no amount of scoping will make it.
For now, most Canadian AI companies selling into the US should get a SOC 2 first, because that is what procurement asks for, and treat ISO 42001 as a twelve to eighteen month follow-on if the buyers in their segment start naming it. The SOC 2 and ISO 27001 decision runs on the same logic and is the more common fork today.
Before you scope the audit
0 of 0 done ·
Get quotes from firms that have audited AI products
The scoping conversation is different, and a firm that has not had it before will scope you as a generic SaaS company.
Get matchedIs there a SOC 2 for AI companies?
No. There is one SOC 2, examined against the same Trust Services Criteria. What differs for an AI product is the system you describe: model providers as subservice organisations, training data commitments, prompt and output retention, and whether model output is a computation your buyer relies on.
Does a SOC 2 report say whether you train on customer data?
Only if you put the commitment in your system description. Once it is there, the auditor tests the controls supporting it, which makes it a much stronger answer than a marketing claim. Commit only to what you can evidence with a contract term, a configuration and a periodic check.
Is OpenAI or Anthropic a subservice organisation in our SOC 2?
If customer data goes to their API, yes, and the report should name the provider, the data sent, the retention terms you contracted for, and the complementary controls you depend on. Most AI companies use the carve-out method, which means the reviewer reads the provider's own report alongside yours.
Do AI companies need the Processing Integrity criteria?
Usually not. It tests whether processing is complete, valid, accurate, timely and authorised, and it is not a judgement on whether a model is right. Include it when your product computes something a customer acts on without checking and where being wrong has a consequence they would attribute to you. Otherwise it adds roughly a quarter to the fee for nothing.
Should we get ISO 42001 instead of SOC 2?
Not yet, for most Canadian companies selling into the United States. US procurement asks for a SOC 2 report by name. ISO 42001 covers AI governance that SOC 2 does not touch and is best treated as a follow-on once buyers in your segment start naming it in contracts.