SOC 2 for AI start-ups: the same criteria, a different scope.
The Trust Services Criteria do not mention AI. Your system description, your vendor list and your change process will. Here is what an auditor looks at when the product is built on models, and the gaps they usually find.
Last updated Published by TryTrustableNot legal advice
SOC 2 has no AI-specific criteria: an AI start-up is examined against the same AICPA Trust Services Criteria as any SaaS company. What changes is scope. Your model providers become vendors or subservice organisations, prompts and model versions are changes the auditor samples, and customer data sent to a model has to match what your system description and contracts promise. Expect the same timeline: two to four months of readiness, then a Type 1 or a Type 2 window of three to twelve months.
What applies, and when
SOC 2 is a CPA firm's examination under AICPA attestation standards of whether your controls meet the 2017 Trust Services Criteria. No law requires it. It applies when a customer's security review asks for it, which for an AI start-up selling to mid-market and enterprise buyers usually happens at the first serious deal. The basics, including report types and who may sign, are in the SOC 2 guide; this page covers what is different when the product is built on models.
The criteria are outcome statements and do not name AI, models or prompts. The AI-specific work comes from three places: the description criteria, which ask you to describe the components of the system (infrastructure, software, people, procedures and data); the vendor criteria, because most AI start-ups depend on a model provider; and the change criteria, because prompts and model versions change what the product does.
| Area | Criteria (common reading) | What it means for an AI product |
|---|---|---|
| System description | Description criteria | Name the model providers, where inference runs, what customer data reaches a model, and whether any of it is retained or used for training |
| Vendors and subservice organisations | CC9.2 | Model API providers, vector databases and GPU clouds are vendors. Most reports carve the large ones out as subservice organisations and list the complementary controls you rely on them for |
| Change management | CC8.1 | Prompt edits, model version upgrades, retrieval configuration and guardrail rules are changes. They need authorisation, testing and approval like code |
| Logical access | CC6.1 to CC6.3 | API keys for model providers, access to training data, fine-tuned weights and evaluation datasets |
| Risk assessment | CC3.2, CC3.4 | Prompt injection, data leakage through outputs, and a provider changing or retiring a model you depend on |
| Monitoring and incidents | CC7.2 to CC7.5 | Abuse detection, output monitoring, and an incident route for a model producing harmful or leaked content |
| Confidentiality (optional) | C1.1, C1.2 | Customer data in prompts and context windows: identified, protected and disposed of as committed |
Criteria references are the usual mapping; agree yours with your auditor before fieldwork.
What auditors actually look for
For a Type 2 the auditor asks for populations and samples from them. For an AI product, the requests that differ from an ordinary SaaS audit are these:
- Every change in the period, including prompts. If prompts live in a database edited through an admin screen, there is often no population to give. Prompts in the repository, changed through reviewed pull requests with evaluation results attached, give the auditor the same evidence as code
- Vendor reviews that read the vendor's report. For each model provider: its SOC 2 or equivalent, the exceptions in it, its data retention terms, and the complementary user entity controls it expects of you
- Key management. Who holds the model provider API keys, how they are rotated, and whether a leaver's access was removed
- A risk assessment that names AI risks. A generic register with no line for prompt injection or model-provider dependency reads as copied
- Commitments that match practice. If your terms say customer data is not used for training, the auditor may test the control that enforces it, such as the provider setting or the absence of a training pipeline reading production data
Does SOC 2 require MFA, MDM or pen testing? covers the controls every SOC 2 asks about, AI or not.
The gaps we see most often in AI start-ups
- Prompts edited in production with no review or history
- One shared model-provider API key, in several engineers' environment files
- Customer data sent to a model provider that is not on the subprocessor list or in the customer contract
- Evaluation runs done in notebooks, with results nobody kept, so there is no testing evidence for CC8.1
- GPU or notebook environments outside the boundary the system description draws, holding production data
- Staff using AI tools on customer data with no acceptable-use policy
- Processing Integrity added to scope for model outputs that cannot be shown to be accurate
The AI acceptable-use policy template closes the staff-tools gap; the vendor security questionnaire is a starting point for reviewing model providers.
A realistic timeline
| Stage | What happens | Typical length |
|---|---|---|
| Scope | Entity, system boundary, model providers named, categories chosen (Security, often Confidentiality), auditor engaged | Two to four weeks |
| Readiness | Prompts into version control, keys into a secrets manager, vendor reviews, AI risks in the register, policies written | Two to four months from a standing start |
| Type 1 (optional) | Design tested as of one date | A few weeks of fieldwork |
| Type 2 window | Controls operate and evidence accumulates | Three to twelve months |
| Fieldwork and report | Populations, samples, exceptions, management responses | Several weeks after the window |
Common ranges, consistent with the SOC 2 guide, not AICPA requirements. The AICPA sets no minimum Type 2 period.
A start-up whose engineering already runs reviewed pull requests and infrastructure as code is often ready sooner. Whether to take a Type 1 first is covered in SOC 2 Type 1 vs Type 2.
What drives the cost
There is no published price list for SOC 2, and we do not quote figures we cannot source. The fee a CPA firm quotes is driven by the categories in scope, the number of systems and subservice organisations (an AI stack often adds several), the length of the Type 2 window, and how much evidence arrives as system-generated populations rather than screenshots. Ask two or three licensed firms to quote on the same written scope, and check the signing firm on CPAverify.
SOC 2 checklist for an AI start-up
| # | Task | Done when |
|---|---|---|
| 1 | Write down every model provider, where inference runs and what customer data reaches each | A data-flow diagram the system description can use |
| 2 | Decide which providers are carved out as subservice organisations | Each listed with the complementary controls you rely on |
| 3 | Review each model provider's SOC 2 or equivalent and its retention terms | Dated review that notes the exceptions |
| 4 | Move prompts, model versions and guardrail rules into version control | Every change is a reviewed pull request |
| 5 | Attach evaluation results to model and prompt changes | Testing evidence exists for sampled changes |
| 6 | Put model-provider keys in a secrets manager with named owners | No shared keys; rotation recorded |
| 7 | Add AI risks to the risk register | Prompt injection, output leakage and provider dependency have owners |
| 8 | Match contracts and the subprocessor list to what is actually sent to models | No provider missing from either |
| 9 | Adopt an AI acceptable-use policy for staff | Acknowledged by everyone in scope |
| 10 | Choose categories: Security, plus Confidentiality if customer data reaches models | Scope agreed in the engagement letter |
| 11 | Run MFA, access reviews, offboarding and vulnerability management as for any SaaS | Evidence produced by the system, not screenshots |
How TryTrustable helps, and what it does not do
- SOC 2 mapped to shared controls. The compliance programme enables SOC 2 and derives readiness from control results, so nobody can type a number in
- Evidence from code and cloud. The SDK and CI gate run checks in your own pipeline, and the GitHub, AWS and Google Cloud integrations check branch protection, review and configuration. Those are the live integrations today
- For the auditor and the buyer. A scoped auditor portal, sealed reports a reader can verify, and a public trust page whose readiness figures come from control results
- AI alongside. The same inventory carries EU AI Act classification and ISO 42001 mappings, if a buyer asks about AI governance next
The platform does not write your questionnaire answers or issue the report; a licensed CPA firm does. TryTrustable does not hold SOC 2, ISO 27001 or ISO 42001 itself yet: all are in progress, as the security page says. Customer data is hosted in India (Mumbai) today; we are expanding to Singapore, the US and the EU.
Sources
- AICPA: 2017 Trust Services Criteria, revised points of focus (2022)
- AICPA: SOC 2 description criteria
- AICPA: SOC suite of services
- CPAverify: CPA licence lookup
- ISO/IEC 42001:2023
Checked against these sources in October 2026. Laws, standards and dates change: check the source before you rely on a figure. Not legal, audit or certification advice.
Related audience guides: ISO 42001 for AI start-ups · EU AI Act for SaaS · GDPR for SaaS · DPDP for SaaS · SOC 2 from India
The things people ask us
Is there an AI version of SOC 2?
No. The AICPA Trust Services Criteria (2017, points of focus revised 2022) have no AI-specific section. An AI company is examined against the same Security criteria as any service organisation, plus whichever optional categories it chooses. AI governance as such is covered by ISO/IEC 42001, which is a separate certification.
Do we need SOC 2 if we only call a model provider's API?
If your customers ask for it, yes. SOC 2 is a commercial requirement, not a legal one. Calling a third-party model does not reduce your scope much: the provider becomes a vendor you review under CC9.2, or a subservice organisation carved out of your report, and you still own the controls around what you send it.
Are prompt changes in scope for change management?
Usually, yes. If a prompt or a model version changes what the product does for customers, it is a change to the system, and CC8.1 expects changes to be authorised, tested and approved. Keeping prompts in the repository and changing them through reviewed pull requests is the simplest way to evidence that.
Should an AI start-up add Processing Integrity to its SOC 2?
Only if you can define what complete, valid and accurate processing means for the output and test it. Model outputs are probabilistic, so a Processing Integrity commitment you cannot evidence produces exceptions. Most first reports cover Security, often with Confidentiality, which fits customer data sent to models well.
Does SOC 2 answer the question whether we train on customer data?
Not directly. SOC 2 tests the controls you describe against the criteria. If you commit to customers that you do not train on their data, that commitment belongs in your contracts and system description, and the auditor may test the controls that enforce it. Buyers will still ask the question in their questionnaire.
See a prompt change sampled like code.
We connect a repository and a cloud account and show which SOC 2 criteria have evidence behind them, prompt and model changes included. Thirty minutes.