SOC 2 for AI Startups: Controls for LLM & Model Risk
No separate "SOC 2 for AI" — it attests against the AICPA Trust Services Criteria like any SaaS. But an LLM product stresses specific criteria: confidentiality (customer data in prompts), vendor risk (your model provider is a subservice org — get their SOC 2 and check the DPA for training terms), availability (you inherit provider uptime), change management (model/prompt changes alter behavior). SOC 2 says nothing about bias, accuracy, or hallucinations — that's NIST AI RMF and ISO/IEC 42001, which buyers now ask about alongside SOC 2.
Key Concept: How LLM and model risk map to a SOC 2® examination — and where SOC 2 stops and AI governance begins
Reading Time: 9 minutes
Difficulty: Intermediate
Relevant for: Founders and engineers at AI/LLM startups pursuing SOC 2®
You're building on top of an LLM, an enterprise prospect likes the product, and then the security questionnaire lands: "Please share your SOC 2 report." Now you're wondering what SOC 2 even means when your core feature is a model you didn't train, running on an API you don't control, processing customer data you'd rather not store.
Here's the reassuring part and the catch, up front. There is no special "SOC 2 for AI." The framework is the same one every SaaS company goes through. But an AI product leans on specific parts of it much harder than a CRUD app does — and increasingly, buyers want more than SOC 2 alone. This guide maps LLM and model risk onto the actual SOC 2 criteria, then shows where SOC 2 stops and AI governance has to take over.
First: there's no "AI certification" hiding inside SOC 2
SOC 2® is an independent attestation performed by a CPA firm against the AICPA's Trust Services Criteria (TSC) — five categories: Security (the "common criteria," always required), Availability, Processing Integrity, Confidentiality, and Privacy. There is no AI-specific category, no "model card" requirement, no clause about hallucinations. Being an AI startup doesn't change the framework at all.
What it changes is which risks are material. Your model provider, your data flows, and your rate of change all shift the weight of the audit. So the useful question isn't "how do we get an AI SOC 2?" — it's "where does our AI stack put pressure on the criteria we're already committing to?" (New to the basics? Start with our complete SOC 2 guide for founders.)
Where an LLM product stresses the Trust Services Criteria
Confidentiality & Privacy — your prompts are a data pipe
Every prompt and completion is a place customer data can flow. If users paste contracts, source code, or personal data into your product, that content leaves your boundary and hits a model API. Auditors will want to know: what data reaches the model, is it minimized, how long is it retained, and — if it's personal data — how Privacy commitments are met. This is usually the biggest AI-specific lift, and it's a documentation problem more than a technical one.
Vendor / subprocessor risk — your model provider is in scope
Your model provider (OpenAI, Anthropic, AWS Bedrock, Azure OpenAI) is a subservice organization in SOC 2 terms, and vendor risk management is an explicit control area. Two things auditors expect you to have done:
- Collect their SOC 2 report. The major API providers maintain their own SOC 2 Type II attestations (OpenAI and Anthropic both do) — request and review them as part of due diligence.
- Check the data-processing agreement separately. A vendor's SOC 2 report tells you their controls operate; it does not tell you whether they train on your data. That lives in the DPA and product tier. On API and enterprise tiers, the major providers contractually don't train on your inputs by default — but you must verify it per provider and write it down, not assume it.
Availability — you inherit your provider's uptime
If your product is a wrapper around one model API and that API has an outage, so do you. If you commit to Availability in your SOC 2 scope, you'll need to show you've thought about degradation and failover — retries, timeouts, a fallback model or graceful "try again later," and monitoring of the dependency.
Change management — models and prompts change behavior
Swapping a model version or editing a system prompt can change your product's behavior as much as a code deploy. That puts model and prompt changes squarely inside change-management controls (CC8): version them, test them, and record who approved the change. "We quietly upgraded to a new model in production" is exactly the kind of uncontrolled change SOC 2 is designed to catch.
Access & monitoring — API keys are privileged credentials
Your model-provider API keys are production secrets: scope them, rotate them, and keep them out of client-side code and repos (CC6). And log your AI interactions for security monitoring (CC7) — while being careful not to over-retain sensitive prompts in your logs, which would reintroduce the confidentiality problem you just solved.
What SOC 2 does not cover for AI (and what buyers now ask for)
This is the part most SOC 2 content skips. SOC 2 attests to the security and operating effectiveness of your controls. It says nothing about whether your model is accurate, fair, unbiased, or safe. Hallucination rate, training-data provenance, model bias, and responsible-AI governance are all outside its scope.
That gap is now being filled by dedicated AI frameworks, and sophisticated buyers are starting to ask about them alongside SOC 2:
- NIST AI Risk Management Framework (AI RMF 1.0, 2023) — a voluntary framework organized around four functions: Govern, Map, Measure, Manage. It's the common reference point for demonstrating you manage AI risk deliberately.
- ISO/IEC 42001:2023 — the first certifiable AI management system standard, covering AI impact assessments, lifecycle management, and third-party oversight. Think of it as "ISO 27001 for AI."
You don't need either on day one. But if you sell into regulated or enterprise buyers, expect "how do you govern your AI?" to become a standard questionnaire line — and plan to answer it with more than your SOC 2 report.
Ready to Streamline Your Compliance?
Discover how AuditBadger can simplify your compliance management process.
Scoping SOC 2 as an AI startup: a practical path
- Choose your criteria deliberately. Security is mandatory. Most AI startups add Confidentiality (customer data in prompts) and, if they process personal data, Privacy. Add Availability only if you're making uptime commitments. Be cautious with Processing Integrity — it's easy to over-promise with non-deterministic model output, so scope it on purpose, not by accident.
- Map your data flows, model included. Draw where customer data goes: your app, your database, and out to the model API and back. That diagram is the backbone of your confidentiality and privacy story.
- Document model providers as subservice organizations. Record each provider, its SOC 2 status, and its data/training terms from the DPA. Most AI startups use the "carve-out" method for these vendors.
- Write an AI data-handling policy. Cover what data may be sent to models, retention, and human-review rules — an extension of your internal policies, not a separate binder.
- Bring models under change management. Version and approve model and prompt changes like code.
- Run a risk assessment that names AI risks. Add model-vendor dependency, data leakage via prompts, and prompt injection to your risk assessment — don't leave them implicit.
Do those, and an LLM product moves through a SOC 2 examination like any other SaaS. The extra work is mostly documentation and vendor diligence, not rebuilding your stack — the same lean approach we describe in getting SOC 2 without a security team.
One trap worth calling out
Don't confuse "we use AI" with "our AI runs our compliance." Piping your control environment through a general-purpose chatbot is its own mistake — we cover why in why general-purpose AI won't survive your SOC 2 audit. Being an AI company that gets audited and using AI to pass an audit are two different problems; this guide is about the first.
How AuditBadger helps
AuditBadger is built for exactly this kind of small, fast team: it keeps your policies, vendor records, risk register, and evidence in one place, and walks you through SOC 2® step by step — including the AI-specific pieces like model-vendor tracking and data-handling policies. If you're an AI startup facing your first security questionnaire, see AuditBadger for AI startups. Onboarding is run by our founding team, so you're not decoding the Trust Services Criteria alone.
SOC 2 won't vouch for your model — but it will prove you run the company around it responsibly, and for most enterprise buyers, that's the door you need open.
Related reading
Frequently asked questions
Is there a special SOC 2 for AI companies? +
No. SOC 2® is an attestation against the AICPA's Trust Services Criteria, and there is no AI-specific version or "AI certification." Being an AI startup doesn't change the framework — it changes which criteria and risks are material, such as data confidentiality in prompts, model-vendor risk, and change management for model updates. For AI-specific governance, buyers increasingly look to the NIST AI Risk Management Framework or ISO/IEC 42001 alongside SOC 2.
Do we need our LLM provider (OpenAI, Anthropic) to be SOC 2 compliant? +
Effectively yes — treat your model provider as a subservice organization and do vendor due diligence. The major API providers (OpenAI's API platform, Anthropic) hold SOC 2 Type II attestations you can request. But note the limit: a provider's SOC 2 report shows their controls operate — it does not tell you whether they train on your data. That's governed by the data-processing agreement and product tier, so verify the training terms there separately and document them.
Does SOC 2 cover AI bias, hallucinations, or model accuracy? +
No. SOC 2 attests to the security and operating effectiveness of your controls — not the quality, fairness, or accuracy of your model's output. Hallucination rate, bias, and training-data provenance are outside its scope. Those concerns are addressed by dedicated AI frameworks like the NIST AI Risk Management Framework and ISO/IEC 42001. If your buyers care about responsible AI, plan to demonstrate it separately from your SOC 2 report.
Which Trust Services Criteria should an AI startup include? +
Security (the common criteria) is mandatory for every SOC 2. Most AI startups add Confidentiality, because customer data flows through prompts and completions, and Privacy if they process personal data. Add Availability only if you make uptime commitments — remember you inherit your model provider's uptime. Be deliberate with Processing Integrity: it's easy to over-promise with non-deterministic model output, so include it on purpose rather than by default.
Will using AI models make our SOC 2 harder? +
Not harder, but different. Your model provider becomes a key vendor to assess, your data flows are more complex to document, and model and prompt changes need to run through change management. Handle those and an LLM product moves through a SOC 2 examination like any other SaaS. The bigger lift is usually documenting data handling and vendor risk, not the AI technology itself.
