SOC 2 for AI Deployments: The Trust Service Criteria Reread for the Model Era

Three things happen the week your enterprise prospect asks for a SOC 2 Type 2 report. Procurement adds an AI-vendor questionnaire on top of it. Their security team forwards a list of evidence requests that did not exist in the report template you bought eighteen months ago. And your auditor, who used to read your CloudTrail logs and approve your access-review matrix in two days, sends back a question you have not been asked before: "What is your evaluation evidence for the model in production, and how do you know it has not drifted?"

This is not the AICPA changing the rules. The 2017 Trust Services Criteria, with the 2022 revised points of focus, are still the document your auditor is reading. What has changed is the surface they are being applied to. A SOC 2 report covering a system that ships generative AI to enterprise customers has to produce evidence about model behaviour, eval gates, training-data lineage, and guardrail configuration — none of which the 2017 criteria mention by name, and all of which the criteria already require, once you reread them through the model lens.

This article does that reread. It walks through each of the five Trust Service Criteria — Security, Availability, Processing Integrity, Confidentiality, Privacy — and then adds a practical sixth pillar, model governance, that auditors are now asking about even though it sits outside the formal framework.

The Five Criteria, Plus One

SOC 2 reports are built around the AICPA's Trust Services Criteria. Security is the Common Criteria — every report includes it. The other four — Availability, Processing Integrity, Confidentiality, Privacy — are elective categories that you opt into based on what your customers contract for. Most enterprise-selling organisations end up with Security, Availability, and Confidentiality at minimum, with Processing Integrity and Privacy added as the customer base demands.

The AICPA has not, as of mid-2026, issued an AI-specific TSC module. What it has done is publish revised points of focus, several of which translate directly to AI workloads once you read them carefully. The five criteria categories cover almost everything an auditor needs to evaluate an AI-bearing system. The gap they leave — model governance, lineage, deprecation policy, evaluation evidence as a first-class artefact — is the sixth pillar we treat at the end. Auditors are already asking the questions even though the framework does not name them yet.

The order matters. Each criterion builds evidence the next one depends on. Skip Security and you have no foundation for Confidentiality. Skip Processing Integrity and your Privacy controls collect dust. The reread is sequential, and the architecture that satisfies it is unified.

Security: The Common Criteria, Reread for the Model Surface

Security covers the controls that protect the system against unauthorised access, both physical and logical. For a traditional SaaS the evidence is well-rehearsed: IAM policies, MFA, network segmentation, vulnerability management, change control.

For an AI deployment the surface widens. The model itself becomes an asset. The inference endpoint is a privileged interface that can read from RAG corpora, invoke tools, call out to sub-processors, and emit content that bypasses the access controls the rest of your system was designed around. Auditors are now asking five questions you should have answers to.

First, who can invoke the model, and through what identity. The answer should be AWS IAM Identity Center or your equivalent enterprise IdP — never long-lived API keys passed through a proxy. Principals should be human users or workload identities, never shared service accounts. Every invocation should attribute to a specific principal in CloudTrail data events.

Second, what is the change-control record for the model itself. Auditors who used to ask for the deployment ticket of your last code release now ask for the deployment ticket of your last model swap. That includes minor version bumps within a provider — Claude 4.6 to Claude 4.7 is a change-controlled event with rollback criteria, not a config flip. Your model registry should produce this evidence automatically.

Third, what is the eval-suite version that was active at the time of the change. Eval suites are now Security artefacts as well as Processing Integrity artefacts — they are the test gates that prevent unauthorised behaviour from reaching production. They should be in version control, signed, and referenced by hash in the deployment record.

Fourth, what is the vulnerability response process for the AI surface specifically. Prompt-injection disclosures, jailbreak techniques, sub-processor vulnerabilities in the model provider's stack — these are vulnerabilities in your scope, and an auditor will ask how they enter your triage queue and who owns remediation.

Fifth, what does the model registry contain and how is it protected. The registry is now part of the Security inventory, treated with the same change-control rigour as your container registry.

Availability: Inference Is a Production Workload

The Availability criterion covers system uptime against the commitments you have made. The classical evidence is your SLA, your incident log, your RTO/RPO documentation, your DR test record.

For AI workloads, three patterns get exercised by the auditor.

Inference endpoints fail differently from databases. Provider-side outages, regional capacity exhaustion, and model deprecation announcements are all availability events. The mitigation is multi-region inference with model fallbacks — the deployment can target a primary model and fall back to a comparable model in a different region when the primary is unavailable. The fallback policy is itself a documented control: which model substitutes for which, what the eval delta is, what the customer-facing communication is when fallback is engaged.

Model deprecation is an availability event with a long fuse. Providers announce deprecation months in advance and then enforce it on a date that does not move. If your application is pinned to a specific model version, the deprecation date is your availability cliff. The auditor will expect a documented deprecation-response process that includes detection (you subscribe to provider deprecation notices and ingest them into your ticketing system), evaluation (you re-run your eval suite against the replacement model), and migration (you have a rollback plan and a documented cutover window).

Prompt caches are part of your availability surface. If your application caches inference results for cost or latency reasons, the cache is part of the served system. Backup and restore should cover it, or the policy should explicitly document that the cache is regenerable and tolerates loss. Auditors want one or the other in writing.

Processing Integrity: Where Evaluation Becomes Evidence

Processing Integrity is the criterion that fits AI evaluation most directly. The framework definition is straightforward: system processing is complete, valid, accurate, timely, and authorised. For a deterministic system this is reconciliation and input validation. For a non-deterministic system this is evaluation.

Three artefacts carry the weight here.

The eval suite is the headline artefact. For each capability your model exposes — answering questions over a knowledge base, drafting customer correspondence, classifying support tickets — there should be a versioned eval suite that measures the relevant dimensions: faithfulness to the source, citation accuracy, regression against a frozen test set, hallucination rate against ground truth. The suite is run on every model change, every prompt change, and every retrieval-pipeline change. Results are stored in an eval registry with the same retention as your CloudTrail logs.

Guardrail configuration is the second artefact. The guardrails — denied topics, PII filters, contextual grounding thresholds, output validators — are control artefacts. They must be in version control, change-controlled, and tested. The auditor will ask to see the exact guardrail policy that was active at the time of a sampled inference. Your architecture has to produce that record.

Drift detection is the third. Models drift in two ways: the underlying model changes (when the provider silently updates a tier) and the input distribution changes (when your customer base evolves). Both reduce Processing Integrity. Drift detection is a documented control with thresholds, escalation paths, and a feedback loop into the eval suite.

The fairness and bias dimension fits here too. Auditors increasingly treat fairness as a Processing Integrity concern — output that is systematically wrong for a subset of users is not accurate, complete, or valid in the framework's terms. Pre-deployment bias testing and production fairness monitoring belong in the same eval registry as faithfulness and accuracy.

Confidentiality: Data Classification Through the Model Lens

Confidentiality covers information designated as confidential — your customer's data, your own proprietary data, anything contractually scoped. The traditional evidence is your data classification policy, your encryption posture, and your access controls over confidential stores.

AI deployments add three concerns.

Training-data classification is now in scope. If you fine-tune or do any form of bespoke training, the training corpus is confidential data with its own classification and handling requirements. The auditor will ask how you ensure customer-confidential data does not enter a training set that produces a model serving other customers.

RAG corpus classification is the more common case. Most enterprise AI deployments do not fine-tune; they retrieve. The retrieval corpus is confidential data, indexed and exposed to the model. The classification, access control, and DSPM posture over that corpus is part of your Confidentiality evidence.

Encryption posture is widened. Bedrock or your inference provider should be configured with customer-managed KMS keys for any caching, logging, or storage they perform on your behalf. CMK rotation, key policy access reviews, and CloudTrail data events for key use are all in scope. For the highest-confidentiality workloads, the air-gapped Bedrock pattern — VPC endpoints, no egress to public model endpoints, no training-data sharing with the provider — is the architecture pattern that produces the confidence the auditor needs.

Privacy: PII Filters, Denied Topics, and the Attribution Trail

The Privacy criterion is the only one explicitly tied to PII and the broader category of personal information. Many SOC 2 reports do not include Privacy — Confidentiality covers the bulk of the duty for most B2B SaaS. But if you process personal data and your customers include the public sector, healthcare, or financial services, Privacy is in scope.

For AI workloads, Privacy maps to four concrete controls.

PII filters at the boundary are the first. The model sees a prompt; the prompt may contain personal information that the user did not intend to expose. The filter — Bedrock Guardrails, a sidecar like Presidio, or a custom validator — redacts or refuses on detection. The filter configuration is a controlled artefact with version history and test coverage.

Denied-topic policies are the second. The model must not answer in categories that are out of scope for the application, and some of those categories are regulatory rather than commercial.

The relationship to external law is the third. SOC 2 Privacy criteria do not duplicate GDPR, NDPA, or the EU AI Act, but they do require that you have a documented privacy programme that addresses the laws applicable to you. Article 10 of the EU AI Act, on data governance for high-risk systems, maps cleanly onto the data classification and lineage evidence you have already produced for Confidentiality. NDPA mapping is the equivalent for Nigerian deployments. The work is documenting the crosswalk, not reinventing the controls.

The principal-attribution audit trail is the fourth. For any inference involving personal data, the audit log should answer four questions: which principal invoked the model, which retrieval set was authorised for that principal, which guardrail policy was active, and which model and eval suite were in production at that time. This is the record an auditor samples from, and it is the record a regulator will subpoena if there is an incident.

Model Governance: The Sixth Pillar Auditors Now Ask About

Model governance is not a TSC category. It will eventually become one, or its substance will be folded into Processing Integrity through revised points of focus. In the interim, auditors who specialise in AI-deploying organisations ask about it under the catch-all of "controls relevant to the system." Producing the artefacts ahead of time is faster than negotiating their absence.

Five artefacts compose model governance evidence.

Model cards. For each model deployed, a structured card documenting capabilities, intended use, out-of-scope use, known limitations, and the eval results that justify the deployment decision. The card has a version and an owner and is updated on every change.

Lineage. For each model, the upstream provenance — base model, any fine-tuning data, any prompt-engineering layers — should be traceable. For frontier models invoked through a provider, the lineage is shallow (you do not know how Anthropic trains Claude), and that is acceptable; the lineage record documents what you do know and what you have contracted for in the provider's data-handling commitments.

Eval results, versioned. The output of every eval run, stored in a registry, indexed by model version and prompt version, with cryptographic integrity. This is the artefact that demonstrates Processing Integrity over time.

Deprecation policy. Your own deprecation policy for models you stop supporting, including customer communication, data migration, and the retention rules for inference logs after deprecation.

Training-data provenance. If you train, the chain of custody from data source through licensing through ingestion through training-set composition. If you do not train, the explicit statement that no customer data leaves the inference boundary, evidenced by configuration.

The Evidence Pack: What Lives Where

A SOC 2 audit is an evidence exercise. For each criterion the auditor samples controls and asks for the evidence that the control operated effectively over the audit period. The architecture that satisfies SOC 2 for AI cleanly is the architecture in which each evidence type has a single source of truth that is queryable and time-stamped.

If your architecture matches this shape, the audit is a query exercise. If it does not, the audit is a reconstruction exercise — and reconstruction is where compliance projects exceed their budgets.

The Architecture That Produces the Evidence

The architecture pattern that satisfies all six pillars without a separate compliance workstream has four components.

A model registry. Every model in production is registered with its version, its provider, its deployment date, its eval-suite version, and its current change-control state. This serves Security, Availability, and Model Governance simultaneously.

An eval registry. Every eval run is stored with its inputs, its outputs, its model version, its prompt version, and its pass/fail verdict. This serves Processing Integrity and Model Governance, and feeds the change-control gate that serves Security.

CloudTrail data events on every privileged surface — Bedrock InvokeModel, KMS Decrypt, the retrieval store. This serves Security, Confidentiality, and Privacy. It is the substrate auditors sample from for principal-attribution evidence.

A posture rule engine that continuously evaluates the configured state against documented policy and emits findings. This serves all six pillars by detecting drift between policy and reality without waiting for the next audit window.

We have been building this stack as an open-source project, compliance-automator, specifically because the alternative — assembling the evidence by hand from CloudTrail exports and screenshots three weeks before the audit — does not scale past the first SOC 2 cycle. The architecture and the compliance posture are the same object.

What This Teaches Us About Enterprise Scaling

The shift visible in SOC 2 audits for AI-deploying organisations is the same shift visible in the failures we have written about elsewhere. The failure mode is not the model — it is the day-two operational discipline that production demanded and the pilot had not produced.

SOC 2 is the externalised expression of that discipline. The criteria do not change for AI; they are reread through a surface that demands more evidence than a deterministic system did. Eval suites become Processing Integrity artefacts. Model registries become Security artefacts. Guardrail policies become Privacy artefacts. The reread is not a re-engineering of the framework — it is a re-engineering of where evidence lives in your system.

The organisations that come out of their first AI-scope SOC 2 cycle in good shape are the ones where the evidence is a query, not a screenshot. The ones that do not arrive in time for the audit are the ones where every evidence type was someone's quarterly task. SOC 2 evidence is now an engineering output. The architecture decision precedes the compliance project, not the other way around.

Companion Content

• Compliance Automator: A Case Study — the open-source pattern this article references
• Air-Gapped LLM Deployments on AWS Bedrock — the high-Confidentiality architecture pattern
• Custom Evaluation Frameworks for Enterprise LLMs — the Processing Integrity primitive
• Strict RBAC in Enterprise Knowledge Bases — the Confidentiality and Privacy primitive for RAG
• Mitigating Non-Deterministic AI Failures: Day-Two Operations — the Availability primitive
• Why Enterprise AI Pilots Fail at Deployment — the operational backdrop

How to engage

We help enterprise teams design SOC 2-aligned AI architectures and produce the evidence pack from the architecture itself rather than from a parallel compliance project. The open-source compliance-automator repo holds the model and eval registries, the posture rule engine, and the CloudTrail-driven evidence collectors we use as the starting point for client engagements. Talk to us at creativeminds.dev/contact.