SOC 2 and AI Systems: What Auditors Actually Ask About Your Models

Your product shipped an LLM feature eighteen months ago. Your SOC 2 Type 2 observation window opens next quarter. The auditor's request list arrives and there is not a single line item with the word "AI" in it.

That absence is the problem. Not because the model is out of scope — it is squarely in scope — but because nothing on the list tells you where. The AI component will be tested under criteria written before it existed, and management, not the auditor, decides in writing which criteria apply and what evidence proves the controls worked.

Here is where the AI component actually lands, what will be asked for, and what breaks when instrumentation starts after the window has opened.

1. There is no AI criterion, and that is the whole difficulty

SOC 2 rests on the AICPA's 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus — 2022). Five categories. Security is always in scope; the other four are elected. There is no sixth category for artificial intelligence, and the AICPA states that the 2022 revisions to the points of focus "do not, in any way, alter the criteria in the 2017 TSC."

What the criteria do have is a definition of the examined object broad enough to swallow your entire stack. Per the TSC glossary, a system is "the infrastructure, software, people, processes, and data that are designed, implemented, and operated to work together to achieve one or more specific business objectives ... in accordance with management-specified requirements."

Read that against your AI feature. A hosted model endpoint is software, or a subservice. Prompt templates are software or data, depending on how you store them. A vector index is data. The engineers who tune them are people. The Friday deploy that pushes a prompt edit is a process. Every part of the feature is already named — what is unusual is that most teams have never written any of it down.

So the auditor will not ask whether the model is good. No criterion asks that. The auditor will ask what you said your system does, and whether you can show controls that make it do that.

2. The system description is where AI actually gets adjudicated

Before any control is tested, management writes a description of the system, and that description is evaluated against the AICPA's 2018 Description Criteria for a Description of a Service Organization's System in a SOC 2® Report (With Revised Implementation Guidance — 2022) — DC section 200, criteria DC1 through DC9. Three of the nine decide almost everything about how an AI component is treated.

DC3 — the components of the system, broken out as infrastructure, software, people, procedures, and data. This is where the phrase "AI-powered insights" fails. That is marketing; DC3 wants components. Name the model and the provider. Name the mechanism that pins the version. Name the prompt store, the retrieval index, the embedding store, and the log that holds prompt text. DC section 200's implementation guidance encourages exactly this specificity, because technical terms "help create a clearer understanding of the service organization's system and system boundaries." A component that never appears in the description has no control tested against it.

DC7 — subservice organizations. If your feature calls a third-party model API, management has to decide whether that provider is a subservice organization and, if so, whether to use the inclusive method — the provider's relevant components treated as part of your system and separately identified — or the carve-out method, which excludes them, with disclosure of the provider's identity when that would be useful to report users. Most teams carve out. That is defensible, and it also means the report is silent on the component customers ask about first — which is why the follow-up is always "can we see their report too."

DC6 — complementary user entity controls. CUECs are, in DC section 200's words, "those controls that service organization management assumed ... would be implemented by user entities and that are necessary, in combination with controls at the service organization," to provide reasonable assurance that commitments are met. If your design quietly assumes customers will not paste regulated records into a free-text prompt box, that assumption is a CUEC and belongs in the description, not in a help-center article.

One more worth knowing before you need it: DC4 requires disclosure of identified system incidents that resulted from controls not suitably designed or operating effectively, or that otherwise caused a significant failure to achieve commitments — nature, timing, extent, and disposition. A model surfacing one tenant's content to another is a system incident under any honest reading.

3. The criteria your model gets tested against

CC8.1 — change management. The criterion reads: "The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives."

Note "data." A prompt edit is a change. A model version bump is a change. A rebuilt retrieval index is a change. A temperature adjustment is a change. Change control that is disciplined for application code often does not reach those four, because they tend to live in a config table, an admin UI, or an environment variable someone edits during an incident. This is the most predictable finding-in-waiting in an AI-feature SOC 2, and it is entirely mechanical to fix: put prompts in version control, route them through the same pull-request approval as code with an approver who is not the author, and pin model versions explicitly instead of pointing at a floating alias.

CC6 — logical access. Two questions. Who can invoke the model, with which credential? And who can read the store holding user prompts and completions? That store is frequently the most sensitive data in the product and the least access-controlled, because it was built for debugging and nobody reclassified it afterward.

CC7.1 — detection and monitoring. It requires procedures that identify "changes to configurations that result in the introduction of new vulnerabilities." If a prompt is configuration — and under CC8.1 it is — undetected prompt drift is undetected configuration drift. A related failure mode is covered in our guide to prompt injection and LLM security.

C1.1 and C1.2 — confidentiality, if elected. C1.1 requires the entity to identify and maintain confidential information; C1.2 requires it to dispose of it. Disposal is where AI features come apart, because the same customer text now exists in the request log, the completion cache, an evaluation fixture someone copied into a test repository, and possibly an embedding. Deleting the row in the primary database does not remove the other four copies, and C1.2 is indifferent to the fact that the copies were made for good engineering reasons.

P4.1 — privacy, if elected. "The entity limits the use of personal information to the purposes identified in the entity's objectives related to privacy." Fine-tuning on customer data is a use. If your privacy notice does not describe it, no engineering control closes that gap.

PI1.1 through PI1.5 — processing integrity, and the trap. Processing integrity is elective, and teams shipping AI features are drawn to it because it sounds like the category that certifies the output is right. It is not. Read PI1.5: the entity stores inputs, items in processing, and outputs "completely, accurately, and timely in accordance with system specifications to meet the entity's objectives." The measuring stick is your own stated specification, not external ground truth — and PI1.2 and PI1.3 treat inputs and processing the same way, against requirements you define.

That cuts both ways, and it is the sharpest trade-off in the whole exercise. Elect processing integrity and write specifications about the pipeline — inputs validated, processing performed as defined, output delivered intact to the intended recipient, records retained — and every one is provable with logs you probably already have. Write a specification asserting that your model produces accurate summaries, and you have handed the auditor a claim you must evidence for every month of the period. Say less, and mean it precisely. If you do want a quality claim, build the measurement first; our guide on how serious teams test AI systems covers what that harness looks like.

4. Evidence you will be asked to produce

The Type 2 distinction is what catches people. A Type 1 addresses whether controls were suitably designed as of a date. A Type 2 addresses design and operating effectiveness over a period. Evidence produced the week before fieldwork does not cover a window that opened nine months earlier. Expect requests for:

• Change records for every prompt and model change inside the period, each showing an approver who was not the author.
• Proof of which model version ran when. Today's configuration is not evidence of March's configuration. Version pinning plus a change log beats a screenshot, every time.
• Access reviews covering model API credentials and the prompt/completion store, performed on whatever cadence you claimed — and dated inside the period.
• Retention and disposal receipts, not the retention policy. What ran, what it deleted, when. A deletion job that emits no output is not evidence that anything was deleted.
• Vendor review evidence under CC9.2, which reads: "The entity assesses and manages risks associated with vendors and business partners." For a model provider that means obtaining and actually reading their report. OpenAI's trust portal states its products are covered by a SOC 2 Type 2 report available to customers with portal accounts; Anthropic lists SOC 2 Type I and Type II along with ISO/IEC 27001:2022 and ISO/IEC 42001:2023 for its commercial products. Getting the file is the easy half; recording who reviewed it, when, and what the complementary user entity controls in their report require of you is the half that produces evidence.
• Evaluation or quality-gate records — but only if you claimed a gate. Do not volunteer an eval program into scope that you cannot evidence every month of the period.

5. What to instrument before the window opens

Ordered by how painful each is to retrofit:

1. Move prompts and model configuration into version control today, behind the same review gate as code. A change history cannot be reconstructed after the fact — you either have the commits or you do not.
2. Pin model versions explicitly and log the resolved version with every request, so "which model answered this" is a query rather than an archaeology project.
3. Separate the store holding prompt and completion text from general application logs, then give it access control, a classification, and a retention period.
4. Make disposal emit a receipt. Scheduled job, logged output, archived where the auditor can see it.
5. Open the vendor file now: the provider's report, the data processing terms, and a written statement of whether your data is used for training.
6. Decide carve-out versus inclusive early and write the description around that decision, rather than patching the description to match a decision made late.

Then start one full observation period ahead of when the report is due. That is the entire trick, and it is the one nobody schedules time for.

6. Where SOC 2 stops

Be direct with customers about what the report will and will not say. A SOC 2 report is an attestation by a CPA firm about controls evaluated against the Trust Services Criteria. It is not a statement that your model is accurate, fair, or well governed, because no criterion asks that.

If those are the questions your buyers are raising, the instruments are different. ISO/IEC 42001:2023, published in December 2023, specifies requirements for an AI management system — risk management, AI system impact assessment, lifecycle management, third-party supplier oversight. The NIST AI Risk Management Framework (NIST AI 100-1, January 2023) organizes the same territory into four functions: Govern, Map, Measure, Manage.

These do not have to sit beside your SOC 2. The AICPA describes a SOC 2 engagement that addresses additional subject matter and additional criteria, in which the service auditor reports on whether that subject matter is presented in accordance with additional suitable criteria — the arrangement practitioners call SOC 2+. That is how AI-governance criteria get carried inside the report rather than requiring a second one, and it is a scoping conversation to have before the engagement letter is signed.

None of this is difficult work. It is early work. The teams that struggle are not the ones with weak controls; they are the ones who decided in month ten that the AI feature needed evidence for months one through nine.

Sources: AICPA — 2017 Trust Services Criteria (With Revised Points of Focus — 2022), from which CC7.1, CC8.1, CC9.2, C1.1, C1.2, P4.1 and PI1.1–PI1.5 are quoted; AICPA — DC section 200, 2018 Description Criteria (With Revised Implementation Guidance — 2022), source of DC3, DC4, DC6 and DC7; AICPA — Addressing additional subject matter and criteria in a SOC 2® engagement; NIST — AI Risk Management Framework (AI 100-1); ISO/IEC 42001:2023 — AI management systems; OpenAI Trust Portal; Anthropic — certifications. Analysis and framing by Precision AI Academy.

Common questions

Is there a SOC 2 criterion for AI? No. SOC 2 is built on the AICPA's 2017 Trust Services Criteria (With Revised Points of Focus — 2022), which has five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. There is no AI category. An AI component is tested under the existing criteria — most often change management, logical access, monitoring, confidentiality, and vendor risk.

Does a prompt change count as a change under CC8.1? CC8.1 states that the entity "authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives." Prompt templates, pinned model versions, retrieval indexes, and inference parameters all fall inside that language, so they need the same authorization and documentation trail as application code.

Is my model API provider a subservice organization? That is a decision management makes and documents. Under DC section 200 criterion DC7, a service organization using a subservice organization elects either the inclusive method, which describes the provider's relevant components as part of the system, or the carve-out method, which excludes them. Either way, vendor risk is still assessed under CC9.2.

Does a SOC 2 report say my AI model is accurate or unbiased? No. A SOC 2 report is an attestation about controls against the Trust Services Criteria, and no criterion addresses model accuracy, bias, or AI governance. Organizations that need to answer those questions typically look to ISO/IEC 42001:2023 or the NIST AI Risk Management Framework, and can ask their auditor about a SOC 2 engagement that addresses additional subject matter and additional criteria.