SOC 2 for AI Startups: What Auditors Ask About Models

SOC 2 has no AI criteria. The AICPA’s Trust Services Criteria — the 2017 set with points of focus revised in 2022 — contain no control mentioning models, prompts, embeddings, or training data, and shipping an AI product doesn’t change the framework you’re audited against. What changes is scope and evidence: your model providers become vendors receiving customer data, prompts and completions become a data flow crossing a trust boundary you don’t own, and vector stores, GPU nodes, and eval pipelines become systems in scope. Everything below is an existing criterion pointed at a new data path — plus a separate set of questions enterprise buyers now ask that are not SOC 2 requirements at all.

What is actually required versus what buyers just ask?

Keep two lists, because conflating them is how AI startups over-scope a first audit. Required is the existing criteria applied to AI systems: vendor management (CC9) over model providers, logical access (CC6) over vector stores and GPU infrastructure, change management (CC8) over model and prompt changes, monitoring (CC7), and — if you scope it — Confidentiality (C1) over prompt and log data. Not required, but increasingly asked are model cards, red-team results, bias testing, eval coverage, and zero-data-retention attestations. Those come from security questionnaires, not the criteria.

The trap sits between the lists. Your auditor tests your control language, not a fixed checklist — so the moment you write “we evaluate model outputs for accuracy before release” into your control set to satisfy a buyer, it becomes testable, and a missing quarter of eval runs becomes an exception. Answer questionnaires generously; write control language conservatively.

What belongs in an AI model and vendor inventory?

Your asset inventory already lists databases and SaaS vendors; AI adds a row type. Auditors want a complete population before they sample, so an incomplete inventory is the fastest route to a finding. For each model your product calls, record provider, model and version, how it’s reached, which data classes go into the prompt, and the contractual data terms.

The “how it’s reached” column matters more than teams expect, because it changes who the vendor is. Calling api.openai.com directly makes OpenAI your subprocessor. Reaching the same class of model through Amazon Bedrock, Google Vertex AI, or Microsoft Foundry keeps the data inside your existing cloud relationship — AWS documents that Bedrock deep-copies provider models into service-operated accounts and that model providers have no access to Bedrock logs or customer prompts and completions. Same model, different vendor review.

Where does customer data go when you call a model API?

Trace it end to end and write it down, because “we send prompts to OpenAI” is not a data flow. Auditors and buyers land on the same questions: is the prompt retained, for how long, by whom, and is it used for training?

• Training. OpenAI states that API data is not used to train or improve OpenAI models unless you explicitly opt in. Anthropic states it will not use commercial inputs or outputs to train its models by default. Microsoft states prompts and completions for models sold by Azure are not available to the model provider and not used to train foundation models.
• Retention. Here is the nuance. OpenAI retains abuse-monitoring logs up to 30 days by default; zero data retention requires prior approval, and per the same docs stateful features — assistants, conversations, vector stores — hold application state until deleted and aren’t covered. Azure’s equivalent is modified abuse monitoring, verifiable via a ContentLogging value of false. Azure’s Global and DataZone deployment types also change where inference runs, which matters if you’ve told an EU buyer otherwise.

ZDR is the strongest answer, but not a SOC 2 requirement. SOC 2 wants evidence you made a decision, documented the terms, and can produce the vendor review record. Subprocessor disclosure is the same shape: publishing a subprocessor page listing OpenAI or Anthropic flows from your customer DPAs and privacy law, not from a Trust Services Criterion — though if your contracts promise notice before adding subprocessors, an auditor will test that commitment.

Which AI concerns map to which controls?

AI-specific concern	Criterion it lands under	Evidence that satisfies it
Third-party model providers	CC9 vendor management	Vendor review record, provider SOC 2 report, DPA, no-training terms
Prompts retained upstream	CC9 · C1	ZDR or modified-abuse-monitoring approval, config proving it’s on
PII reaching a model API	C1 · Privacy	Data classification, redaction or tokenization at the app tier
Vector database contents	CC6 · C1	Per-tenant namespace isolation, IAM policy, encryption with managed keys
GPU / fine-tuning infrastructure	CC6 · CC7	Network isolation, IAM roles, node logging, dataset access reviews
Model and prompt changes	CC8 change management	Versioned prompts in Git, reviewed PRs, deploys tagged with model version
Model artifact integrity	CC6 · CC8	Registry with immutable versions, checksums, provenance to the training run
Output quality and drift	CC7 (only if you claim it)	Scheduled eval runs, thresholds, alerting, tickets when they trip

Are vector databases and GPU infrastructure in scope?

If they hold or process customer data, yes — and both get missed in first scoping conversations. A vector store holds embedded chunks of customer documents, so it is a customer-data store carrying the same CC6 obligations as your primary database: authenticated access, least privilege, encryption at rest, per-tenant isolation. Shared-index designs where tenant separation rests on a metadata filter are the failure mode; auditors ask what stops a filter bug from leaking across tenants.

GPU and training infrastructure comes into scope when you fine-tune or train on customer data — the training cluster, the dataset bucket, and the notebook environments engineers reach them from, on AWS, GCP, or Azure alike. Logs are the other half: traces capturing full prompts and completions are a copy of your most sensitive customer data sitting in an observability tool with looser access controls than your database. Redact at the emit point, scope who can read traces, set a documented retention period. The same discipline applies to AI in your own toolchain — see keeping secrets out of AI coding tools.

What evidence covers model integrity and evaluation?

Model artifact provenance is CC8 wearing different clothes. If a model weight file can reach production without a reviewed, logged path, your change-management narrative is inaccurate — so pin model versions explicitly instead of floating on a provider alias, store artifacts in a registry with immutable versions and checksums, and tag deployments with the model version so a log line answers “what was serving on March 12?”

Evaluation evidence is the genuinely emerging area. No criterion requires you to run evals. But buyers ask, and if you scope Processing Integrity — which some AI companies now do for exactly this reason — you are asserting the system processes data completely and accurately, and eval results become that assertion’s evidence. For most seed and Series A companies, Security plus Availability is the right first report, with evals run as engineering practice rather than an audited control. Sequence the rest with our SOC 2 infrastructure checklist and the criterion-by-criterion mapping.

Does SOC 2 or ISO 42001 come first?

SOC 2 first, in almost every case. SOC 2 remains the default US enterprise ask and covers the operational foundation; ISO 42001 certifies an AI management system — impact assessments, lifecycle documentation, human oversight — that assumes that foundation already exists. They are complementary rather than competing, and the AI governance questions your buyers ask are mostly ISO 42001 questions arriving early. If a specific deal demands AI governance now, ask your auditor about adding subject matter to a SOC 2 examination rather than running two programs.

The bottom line

The AI-specific work in a SOC 2 audit is about a week of inventory and vendor review, plus real engineering on tenant isolation and log redaction. The framework isn’t the hard part — telling requirements apart from procurement pressure is. Our SOC 2 infrastructure package builds the cloud controls auditors actually test on AWS, GCP, or Azure, a free infrastructure health check finds the gaps before an auditor does, and pricing shows how audit-prep is scoped.

This is engineering guidance based on public provider documentation and the SOC 2 Trust Services Criteria — not legal or audit advice. Confirm scoping and contractual specifics with your auditor and counsel.