If you're a 2026 AI startup selling to enterprise buyers — Fortune 500 security teams, regulated industries, government — SOC 2 is table stakes. But SOC 2 for an AI product is different from SOC 2 for a classic SaaS. This guide covers what to scope, what auditors are actually asking, and what to skip.
What Enterprise Buyers Are Actually Asking in 2026
Security questionnaires for AI vendors have changed in the last 18 months. Buyers now ask:
- Where does prompt and completion data go? On-disk retention, cross-region replication, who-can-read ACLs.
- Who are your model vendors and sub-processors? OpenAI, Anthropic, Google, Mistral, Cohere, Together, Replicate, Modal, and the stack beneath them.
- How is customer data used for training? Explicit opt-out, retention windows, DPAs with model vendors.
- Who approves model changes? Change management for model switches is net-new — most SaaS teams don't have it.
- How is model output monitored? Hallucination rate, PII exposure in outputs, abuse detection.
- What happens on a model provider outage? Business continuity when your core function depends on OpenAI's uptime.
A plain SOC 2 Type II doesn't answer most of these — but if you scope the audit intelligently, it can.
How to Scope SOC 2 for an AI Product
Trust Services Criteria to include.
- Common Criteria (CC1–CC9) — mandatory.
- Confidentiality — mandatory for any AI product handling customer data.
- Privacy — add if you process personal data at scale (most AI products do; GDPR / CCPA aside, this is where buyers care).
- Availability — add if you have SLAs. Skip if you're pre-GA.
- Processing Integrity — relevant for AI only if you're doing inference-as-a-service with explicit output guarantees. Rare.
Default scope for a 2026 AI startup: Common Criteria + Confidentiality + Privacy.
System boundary. The audit boundary should include:
- Your application plane.
- Your inference infrastructure (whether self-hosted or routed through model APIs).
- The prompt log store, the output log store, and the training data store (if separate).
- CI/CD pipelines that touch model weights, prompts, or evaluation harnesses.
Sub-processors. List every model provider as a sub-processor and treat them as third-party vendors in the vendor-management control. OpenAI, Anthropic, and Google have SOC 2 reports — pull them, document them.
AI-Specific Controls to Add
The SOC 2 control set wasn't written for AI, but it's flexible. These controls, mapped to CC categories, cover what buyers actually care about:
| What buyers ask | Control category | What to document |
|---|---|---|
| Prompt / completion data isolation | CC6.1 (logical access) | Row-level or tenant-level isolation in the log store; access reviews |
| Model vendor sub-processors | CC9.2 (vendor management) | Risk assessment for each model vendor; DPA on file; opt-out confirmation |
| No training on customer data | CC3.4 (risk assessment) + Privacy | Written policy; vendor contract term; monitoring |
| Prompt / output logging retention | CC6.7 (data retention) | Retention policy; deletion verification |
| Model change control | CC8.1 (change management) | Model version registry; approval workflow for model swaps |
| PII in model outputs | Privacy + CC7.1 (monitoring) | PII scanning in outputs; redaction; incident response |
| Model vendor outage BCP | CC7.3 (business continuity) | Fallback provider; graceful degradation plan |
Your auditor doesn't need you to invent new TSCs — they need you to map these to existing ones and provide evidence.
What Doesn't Change
- Access reviews, MFA, logging, encryption-at-rest and in-transit — all the usual.
- Incident response plan, tested annually.
- Information security policy approved by board / senior management.
- Risk register maintained quarterly.
- Vendor management for non-AI vendors (AWS, Datadog, etc.) — same as always.
Picking an Auditor Who Can Audit AI
Not every SOC 2 auditor is comfortable with AI products. When you're shortlisting:
- Ask for recent engagements with AI-native products. If they can name three, good.
- Ask how they treat model vendors as sub-processors. The answer should be structured — not improvised at audit time.
- Ask whether they're comfortable including the inference layer in the system boundary. If they want to carve it out, that's a red flag — you're paying for an audit that doesn't cover the thing your buyers care about.
- Ask about evidence formats for model change management. If they haven't seen it before, they'll want to invent one — budget time for that conversation at kickoff.
Boutique SOC 2 specialists (Insight Assurance, Prescient, Johanson, A-LIGN's AI practice) have moved fastest on AI-specific audit experience. Big-four engagements can be slower to adapt because the methodology is standardised globally.
Browse the SOC 2 auditor directory and shortlist 3.
Timeline
- Weeks 1–3: Scope (TSCs, system boundary, sub-processor list). Pick an automation platform. Draft the AI-specific policies: prompt data handling, model vendor management, model change control, output monitoring.
- Weeks 4–12: Implement AI-specific controls. For most teams this is 3–5 engineer-weeks of work.
- Month 3: Begin Type II observation.
- Month 9: Field work.
- Month 10: Report issued.
What to Add Beyond SOC 2
SOC 2 alone doesn't satisfy every AI-vendor security questionnaire. For AI-specific buyer requirements, consider pairing SOC 2 with:
- ISO 42001 — the first dedicated AI management system standard. Covers governance of AI development.
- NIST AI RMF — a voluntary framework; useful for US federal-adjacent buyers.
- ISO 27001 — if you also sell to EMEA/APAC enterprise buyers.
See ISO 42001 for AI Startups for the ISO 42001 side.
Cost
Expect $30K–$70K year 1 for an AI startup Type II (Series A size, single product scope). The AI-specific controls add 10–20% to a classic SaaS SOC 2 price — mostly in extra policy drafting and auditor hours spent on sub-processor mapping. See SOC 2 cost for US startups for the full breakdown.