SOC 2

SOC 2 Evidence for AI Features: What Auditors Actually Ask

LowerPlane Team••9 min read

TL;DR

  • • Auditors care about three things when your product uses AI: where the data flows, how you control prompt injection, and how you log model outputs
  • • Most existing Trust Services Criteria (CC6, CC7, CC8) already cover these — you just need to describe your AI stack in the auditor's language
  • • A specific evidence pack — model provider agreements, prompt/response logs, vector store access reviews, output filter configurations — satisfies 90% of AI-related asks
  • • Two red flags trip almost every AI startup on their first Type 2: no logging of prompts sent to third-party LLMs, and no documented review of the training data used by fine-tuned models
  • • You do not need a separate framework (yet) to pass SOC 2 with an AI product — you need clear artifacts that show your existing controls apply to AI infrastructure

Your product uses an LLM. Maybe you call OpenAI or Anthropic from your backend, maybe you self-host, maybe you built a RAG pipeline over a vector store. Now an enterprise buyer wants your SOC 2 Type 2 report and their security team is asking pointed questions about your AI stack. Meanwhile your auditor has never audited a company that uses vector embeddings and keeps asking for "the AI system inventory." This is the guide we wish we'd had.

The Three Questions Every Auditor Now Asks

SOC 2 auditors have had two years to catch up with AI-native products. The good news: they've converged on a small set of questions. The bad news: they expect specific answers, not slide decks. If you can answer these three, you're past the awkward first meeting.

1. Where does customer data go?

Show the data flow: user prompt → your backend → third-party LLM (which one, in what region, under what contract) → response → back to user. Any customer data that leaves your VPC needs a documented purpose, a signed DPA, and — if you're on the enterprise plan of the model provider — a zero-retention clause or equivalent.

2. What stops a user from making the model do something bad?

This is the prompt-injection question rephrased. Auditors expect input validation, an allow-list of tool calls if you have an agent, output filtering (for PII, credentials, or off-topic responses), and rate limiting per user or per tenant. The bar isn't "prompt-injection-proof" — it's "documented controls with evidence they run."

3. If something goes wrong, can you tell what happened?

Prompt and response logging, retention policy, access review on the log store, and — increasingly — a documented human-in-the-loop for high-risk automated decisions. If the model can take an action a customer would care about, an auditor wants to see the decision trail.

Mapping AI Infra to Existing CC Controls

You don't need new controls. You need to describe the AI parts of your stack in the language of the Trust Services Criteria you already have. Here's the mapping most SOC 2 auditors have converged on:

CC ControlAI Infra InterpretationEvidence
CC6.1Access to vector stores, model API keys, prompt/response logs is restricted by role.IAM policy or Okta group listing for vector store, quarterly access review, API-key rotation records.
CC6.6Data sent to third-party LLM providers is protected in transit and covered by contract.Model provider DPA, zero-retention addendum, TLS enforcement config.
CC7.1Prompt and response payloads are logged for security-relevant events.Sample log entries, retention policy, log store access review.
CC7.2Anomalous model behavior (e.g., sudden token spike, jailbreak patterns) triggers an alert.Alert rule definitions, sample alerts, on-call runbook.
CC8.1Changes to prompts, model versions, and tool allow-lists follow the change-management process.Prompt-file PRs, approver evidence, model version bump tickets.
CC9.2Model providers are treated as sub-processors and reviewed on the same cadence as other critical vendors.Vendor risk assessment, sub-processor list, SOC 2 reports from providers on file.

The Evidence Pack That Satisfies 90% of AI Asks

When your auditor sends the "walk me through your AI stack" email, this is what to send back. If you have these six artifacts in one folder, you've pre-empted most of the follow-up.

1
AI system inventory
One row per model or vector store — provider, region, purpose, data class, owner, and the contract on file. Two pages max.
2
Model provider agreements
The DPA + any zero-retention or business-tier addendum for each provider. Auditors want the signed PDF, not a link.
3
Prompt/response logging spec
What you log, what you redact, where it goes, and how long it stays. Include a sample log entry.
4
Output filter configuration
The regex, classifier, or moderation-API rules that scrub PII/secrets from model output. A screenshot of the config plus a test-case list.
5
Vector store access review
Quarterly review showing who has read/write access to your embedding store — same shape as any other database access review.
6
Model change log
Every time you bumped a model version, changed a system prompt, or added a tool. A CSV or a query result from your version-control system is fine.

Two Red Flags That Trip Almost Every AI Startup

After watching dozens of AI startups go through their first Type 2, the same two gaps show up in nearly every management letter.

Red flag #1: no logging of prompts sent to third-party LLMs

Startups often log requests at their API layer but stop there. When the auditor asks "show me the payload you sent to OpenAI when this incident happened," there's nothing to show. Fix: log the fully-rendered prompt (after templating, before send) in a separate access-controlled store with a documented retention window.

Red flag #2: no documented review of fine-tuning data

If you fine-tune, the training data becomes part of your product. Auditors want a documented review — who approved the dataset, what PII scrubbing was applied, where it's stored, and who can access it. "We used the customer support tickets" is not an answer that lands.

Do You Need a Separate AI Framework?

Not for SOC 2. Auditors accept mapped-and-described AI evidence against existing CC controls today. The reason to consider ISO 42001 or the NIST AI RMF is when your buyers start asking for it in RFPs — which is happening more each quarter, especially in regulated industries and public sector.

If your enterprise buyer is asking, run SOC 2 and ISO 42001 in parallel. There's substantial overlap; you can share evidence between them if your compliance platform supports it.

How LowerPlane Helps AI Startups Pass SOC 2

  • →Pre-built AI system inventory template and model-provider register
  • →Evidence collection from OpenAI, Anthropic, Google Vertex AI, and self-hosted model endpoints
  • →Vector store access reviews (Pinecone, Weaviate, Qdrant) on the same cadence as your database reviews
  • →Prompt/response log connectors that satisfy CC7.1 without building custom pipelines
  • →Shared controls with ISO 42001 and NIST AI RMF — implement once, satisfy three frameworks
See How LowerPlane Handles AI Evidence

SOC 2 Ready for Your AI Product

LowerPlane handles the AI-specific evidence auditors ask for — model inventories, prompt logging, vector store reviews — without building a compliance team.

Book a Demo