SOC 2 for AI Workflows: What an Auditor Actually Checks

SOC 2 predates the current wave of AI, and its Trust Services Criteria don't mention large language models. But auditors are pragmatic: when your product runs AI workflows in production, they apply the existing criteria to those workflows the same way they apply them to any other system component. The questions just land in unfamiliar places.

If you're heading into a SOC 2 audit with AI features in scope, here's how the criteria actually map to an LLM workflow, and where the gaps most commonly are.

The Framing Auditors Use

SOC 2 is organized around five Trust Services Criteria: Security (always in scope), Availability, Processing Integrity, Confidentiality, and Privacy. An auditor doesn't have an "AI checklist" — they ask how your existing controls extend to cover the AI parts of your system.

The trap teams fall into: they have strong controls for their traditional infrastructure and assume those controls automatically cover the AI workflows. They usually don't. An LLM call to a third-party provider is a new data flow, a new dependency, and a new failure mode that your existing controls may not touch.

Security: The AI-Specific Attack Surface

The Security criterion asks whether the system is protected against unauthorized access. For AI workflows, this extends to a class of risks that traditional security controls don't address:

Prompt injection. If a workflow processes user-provided text, an attacker can craft input that overrides the system instructions. An auditor increasingly asks what mitigations you have. "None" is a finding.
Insecure output handling. If model output flows into a downstream system — a database query, a shell command, a rendered web page — unvalidated output is an injection vector. This maps directly to the OWASP LLM Top 10.
Secrets management. AI API keys are credentials. If they live in environment variable files or config, with no rotation and no audit log, that's the same finding you'd get for any hardcoded credential — auditors just now know to look in the AI code.
Access to the workflow. Who can trigger the AI feature, who can change the prompts, and is that access logged.

Confidentiality and Privacy: Where the Data Goes

This is where AI workflows most often create new obligations. The Confidentiality and Privacy criteria ask how you protect sensitive data.

The moment a workflow sends data to a third-party model, an auditor wants to know:

What data is in the payload? Does it include customer data, PII, or confidential information? Is any of it sent that doesn't need to be?
What is the provider's data policy? Is the data used for training? What's the retention period? Do you have a data processing agreement with the provider?
Is there a record? Can you produce, for a given time period, what categories of data were sent to which providers?

The common gap: teams know their primary database is encrypted and access-controlled, but haven't accounted for the copies of data that leave the perimeter every time an LLM is called.

Processing Integrity: Is the Output Correct and Complete?

Processing Integrity asks whether system processing is complete, valid, accurate, and authorized. For deterministic software this is straightforward. For a probabilistic model, it's subtle — and auditors are still calibrating how hard to push.

What they reasonably expect to see:

Evaluation. Some defined way of measuring whether the AI produces correct outputs, run before changes ship. An eval dataset satisfies this; "we test it manually sometimes" does not.
Output validation. Checks on the model's output before it's used or shown — format validation, range checks, or a confidence gate.
Change control. Prompt and model changes go through review, not straight to production. A prompt is application logic; changing it without review is a change-control gap.

Availability: What Happens When the Provider Is Down

The Availability criterion asks whether the system is available for operation as committed. AI workflows add a dependency you don't control: the model provider.

Auditors ask what happens when the provider returns a 429, a 503, or times out. If the answer is "the feature breaks," that's an availability gap. Expected controls: retry logic with backoff, a circuit breaker, and a defined fallback path — plus monitoring that tells you when the dependency is degraded.

The Control Gaps That Surface Most Often

Across AI workflows heading into SOC 2, the same handful of gaps appear:

1. No complete inventory of AI workflows. You can't scope an audit around systems you haven't enumerated. This is gap zero — everything else depends on it.

2. Undocumented data flows to third-party models. The data leaves, but there's no record of what, where, or under what agreement.

3. No prompt injection or output handling controls on workflows that process untrusted input.

4. Prompts changed without change control. Treated as config, not as code that affects processing integrity.

5. Monitoring that covers infrastructure but not AI behavior — the service is "up" while producing wrong or harmful outputs.

How to Prepare

The efficient path into a SOC 2 audit with AI in scope:

Enumerate every AI workflow first. Scan the codebase and build the complete inventory. This scopes the audit and surfaces the workflows you'd otherwise forget.
Assess each against the relevant criteria. Map every workflow to the Security, Confidentiality, Processing Integrity, and Availability controls that apply. You want a control-level view, not a general assurance.
Document the data flows. For each workflow, record what data goes to which provider and under what agreement.
Close the injection and change-control gaps before the audit window opens — these are the ones auditors reliably find.

Walking in with a current inventory, a control-level assessment, and documented data flows turns a stressful audit into a review of work you've already done.

Scan your AI workflows to build the inventory and get a control-level readiness assessment mapped to the dimensions SOC 2 auditors care about. Or learn more about compliance readiness.