A new section in the audit playbook
SOC 2 auditors did not have an opinion about LLM-backed systems two years ago. They have an opinion now, and it’s getting more specific each quarter. The big four firms have updated their internal audit playbooks. The boutique compliance firms are catching up. Companies renewing SOC 2 Type II this year are getting questions their previous auditor didn’t ask.
The questions cluster around five themes. None of them are exotic. All of them have right answers and wrong answers. The wrong answers cost you a control failure on the report, which costs you customer deals, which costs you actual money. So this is worth getting right ahead of the cycle, not during it.
Below are the five themes, the specific questions auditors are asking, and the answers that hold up.
Theme 1: Data flow into model providers
The question: “Describe the data categories that flow to your model providers, the contractual basis for that flow, and the controls preventing unauthorized categories from being sent.”
What auditors want to see:
- A documented data classification scheme.
- A specific list of which categories are permitted in prompts and responses.
- Technical controls (not just policy) that prevent prohibited categories from leaving your boundary.
- DPAs in place with every model provider, naming sub-processors.
What gets people in trouble: A policy document that says “we don’t send PII to LLMs” without any control that actually enforces it. A common failure: a developer pastes a customer record into a debug prompt during an incident. The policy was violated. The control didn’t exist.
Right answer: Egress filtering at the model client layer. PII detection runs on every outbound prompt. Prohibited categories are either redacted automatically or block the call. The filter is testable and audited periodically.
Theme 2: Vendor management for model providers
The question: “What is your due-diligence process for model providers, and how do you continuously assess them?”
What auditors want to see:
- A vendor register listing every model provider.
- Initial due-diligence artifacts (SOC 2 reports, ISO certifications, security questionnaires).
- A re-review cadence (typically annual).
- Documented sub-processor flow-down: if your provider uses sub-processors, they’re named and contractually bound.
What gets people in trouble: Treating OpenAI/Anthropic as “they’re big, they’re fine.” That’s accurate but not a control. Auditors want to see the artifacts.
Right answer: Treat model providers the same as any sub-processor. Real artifacts in a vendor management system. Annual re-review on the calendar. Documented.
Theme 3: Output controls and review
The question: “What controls exist on model outputs before they reach customers, especially for high-impact actions?”
What auditors want to see:
- A definition of “high-impact” actions in your system.
- A human-in-the-loop control for those actions, or a documented justification for full automation with risk acceptance.
- Logs that show the review actually happened (not just that the control exists).
What gets people in trouble: “The model is reviewed by humans” as a policy claim, with no evidence that any particular output was reviewed. Auditors will sample and ask for the review trail. If it doesn’t exist, the control fails.
Right answer: Reviews are logged at the same level as the actions themselves. Reviewer, timestamp, decision. Sampling auditors find clean evidence.
Theme 4: Incident response for AI-specific failure modes
The question: “Describe your incident response plan for AI-specific incidents, including hallucinated outputs, runaway costs, and autonomous agent overshoot.”
What auditors want to see:
- An incident playbook that names AI-specific failure modes (not just “service outage”).
- Kill switch documentation and testing evidence.
- A post-incident review template that’s been used recently.
What gets people in trouble: A generic incident plan that says “follow ITIL,” without specifics on how to stop an agent that’s behaving badly. Auditors are getting more specific about this every quarter. “Generic” is no longer enough.
Right answer: A specific runbook section per AI system, listing the kill switch, the on-call contact, and the rollback procedure. Tested quarterly. Documented.
Theme 5: Logging and traceability
The question: “For any AI-driven decision affecting a customer, can you reconstruct what happened?”
What auditors want to see:
- Audit logs at the model-call level: who, when, what model, what prompt category (redacted), what tool calls, what output category, what action taken.
- Retention period appropriate to your business.
- Immutability of the log store.
What gets people in trouble: Logs that don’t include the prompt category or the model used. Logs that age out before your retention requirement. Logs stored in a way that’s mutable.
Right answer: Structured logging at the wire boundary, with tenant ID and decision lineage. Immutable store. Retention aligned to your data classification policy. Sampled review periodically.
The audit cycle trap
The most common trap is auditing-to-template. A new auditor or a new partner at an existing firm shows up with a checklist that includes AI questions. The company answers from a template they wrote two years ago. The template is generic enough that it doesn’t fail outright, but the auditor flags several items as “needs evidence” or “needs strengthening.”
The trap is that the company treats those flags as a tactical fix-it list for this cycle. They write more evidence, add more policy language, paper over the gap. Next cycle, the auditor returns with deeper questions. Now the prior fixes don’t hold up. The company is now playing whack-a-mole with audit findings.
The escape from the trap is to do the work once, completely, ahead of the cycle. Get the controls real, not just documented. Three quarters of preparation beats six quarters of remediation.
What to do this quarter
If you have SOC 2 Type II renewal in the next 12 months and you operate AI-backed systems, here is the prep sequence:
- Inventory. List every AI-backed surface in production or pilot. (You should already have this for governance reasons; if you don’t, do it now.)
- Map to the five themes. For each surface, document where you stand on each of the five themes above. Honest assessment.
- Close the easiest gaps first. Output review logging, audit log structure, vendor register — these are usually a week of engineering each.
- Schedule the harder ones. Egress filtering on prompts, automated PII detection, kill-switch testing — these need real engineering investment, but they can be staged across a quarter.
- Run a tabletop with your audit partner. Walk them through your current posture before they begin the formal cycle. Their feedback is much cheaper here than as audit findings.
This sequence costs a quarter of attention and saves a year of remediation work. It also makes the difference between a clean SOC 2 Type II report and one with carve-outs that procurement teams at your prospects will flag.
The broader shift
SOC 2 is the leading edge for this; the same questions show up in ISO 27001, HIPAA, FedRAMP, and the various state and EU regimes coming online. The themes are durable even though the specific compliance frame is shifting. Companies who solve for the five themes are in a strong position regardless of which audit framework gets invoked.
The companies who treat each compliance regime as a separate template exercise are going to spend the next three years doing the same work over and over.
The take
Audit questions about LLM-backed systems are not generic anymore. The five themes above are now standard. The right answers exist, the work to get there is bounded, and doing it ahead of the cycle is meaningfully cheaper than doing it during. Treat the next 12 months as the window. Past that, the audits get more specific and the cost of being unprepared grows.
Audit readiness is one of the deliverables in Fractional CAIO engagements. If you have a SOC 2 cycle coming and want a pre-audit walkthrough, schedule a call.
