SOC 2 + AI Workloads: How the Trust Services Criteria Actually Map to LLM Systems

SOC 2 is the de facto enterprise procurement gate, and the AICPA Trust Services Criteria (TSC) apply to AI workloads even though the criteria predate generative AI by a decade. The AICPA Trust Services Criteria (TSP Section 100, 2017 with revisions effective 2022), the 2024 AICPA SOC 2 + Type 2 + AI Considerations white paper, and NIST AI 600-1 (Generative AI Profile, July 2024) together provide enough material for auditors to evaluate AI workloads under the existing TSC framework. This article is the criterion-by-criterion mapping Areebi's compliance team has shipped to regulated customers preparing for SOC 2 Type 2 examinations that include AI scope. Updated 2026-05-20.

The AICPA Trust Services Criteria have five categories: Security (Common Criteria), Availability, Confidentiality, Processing Integrity, and Privacy. Security is mandatory for any SOC 2 examination; the other four are optional and chosen by the service organisation based on commitments to user entities. The Common Criteria (CC1-CC9) underpin all of them and are where most AI-specific control questions land.

The structural change in 2024-2026 is not in the criteria themselves but in how auditors apply them. The AICPA SOC 2 + AI Considerations white paper (2024) walks through the AI-specific control objectives that auditors are expected to evaluate. Areebi's compliance team designs this control set so each of the AICPA AI considerations maps to an Areebi platform feature with an auditable evidence trail.

If your organisation has not yet decided whether to add AI scope to its SOC 2 examination, the practical default in 2026 is: include it. Procurers are starting to ask whether the SOC 2 report covers AI systems, and a "no" answer increasingly translates into a procurement blocker. Our build vs buy guide covers the procurement context.

CC6 is the criterion most procurement teams ask about first when AI scope enters a SOC 2 report. The criteria require the service organisation to implement controls over logical and physical access. For LLM systems, the controls extend beyond the application layer to the model and the prompt/completion data.

• CC6.1 (Implements logical access security software, infrastructure, and architectures). For LLM endpoints, this requires: authenticated access to inference APIs, rate limits per principal, network segmentation between inference and training environments, and mTLS or equivalent for east-west traffic. Areebi customers wire the policy engine into the inference path so every request carries an authenticated principal and an authorisation decision.
• CC6.2 (Prior to issuing system credentials). User provisioning and de-provisioning for AI tools must follow the same identity lifecycle as other production systems. Shadow AI is the failure mode (see our shadow AI explainer).
• CC6.3 (Authorises, modifies, or removes access). Role-based access to models, fine-tuned variants, and embedding stores. The Areebi platform supports per-model, per-collection, per-prompt-class access control.
• CC6.6 (Implements logical access security measures to protect against threats from sources outside its system boundaries). For LLM, this includes prompt-injection defence (see our prompt injection deep dive), JWT signature verification, and output filtering.
• CC6.7 (Restricts the transmission, movement, and removal of information). DLP-style controls on prompts and completions; redaction of personal data and trade secrets before they leave the controlled boundary.
• CC6.8 (Implements controls to prevent or detect and act upon the introduction of unauthorised or malicious software). For AI, the equivalent is malicious model artefacts (model backdoors, data-poisoned datasets). The data poisoning defence guide walks through the pattern.

The trap to avoid: treating LLM access control as the same problem as REST API access control. The difference is that LLMs are non-deterministic and prompt-injectable, so the access control must extend to the prompt and the completion, not just the request envelope.

CC7 covers detection, response, and recovery from system anomalies and incidents. The AI-specific incident classes that auditors will evaluate against CC7:

• Prompt injection. Detection (input filtering, anomaly scoring), response (blocking, escalation), and recovery (incident review).
• Model drift. Drift in input distribution, output distribution, or performance. Detection via continuous evaluation, response via retraining or rollback, recovery via documented model lifecycle.
• Hallucination incidents. When an AI output causes harm via fabrication, the incident response process must be capable of attributing the output to a specific model version and prompt context.
• Data exfiltration via AI. When sensitive data leaks via a prompt or completion, the incident response must include the AI as a vector.
• Vendor model change. When an upstream vendor updates the model under a service organisation, the change-management process must include validation that the new model meets the service organisation's commitments.

The control evidence auditors expect for CC7: a written incident management policy that includes AI-specific incidents, an incident log that captures AI incidents with the model version, prompt context, and user impact, and a tabletop or live-fire exercise within the audit period that demonstrates the incident response works for an AI scenario. Areebi's audit log captures each of these by default; the AI agent monitoring and observability guide walks through the detection patterns.

The Availability criteria require the service organisation to meet its availability commitments and deliver capacity that meets demand. For LLM inference, the availability questions auditors ask:

• What is the published inference SLA? Most enterprise AI vendors do not publish hard SLAs on inference latency or availability. The service organisation must either set its own internal SLA against the vendor's best-effort or operate with a fallback model.
• What is the failover pattern? The Areebi platform supports multi-vendor inference with automatic failover; if one model provider is unavailable, requests route to a configured backup. The audit log records the failover events.
• What is the capacity plan? Token consumption forecasting, rate-limit headroom against vendor quotas, and concurrent-request capacity. Areebi customers run synthetic load tests against vendor APIs to identify the actual concurrency ceiling.
• What is the disaster recovery pattern for model artefacts and fine-tunes? Fine-tuned model checkpoints, embedding stores, and evaluation suites must be backed up with a tested restore procedure.

The control evidence auditors expect: a documented inference SLA, evidence of failover testing, capacity planning records, and recovery test results within the audit period.

Processing Integrity asks whether system processing is complete, valid, accurate, timely, and authorised. The AI-specific reading:

• Completeness. Did the inference complete successfully? Truncated outputs, timeouts, and partial completions must be detected and handled.
• Validity. Does the output conform to the expected schema or content policy? Structured output validation (JSON schema, regex), guardrail checks, and human-in-the-loop where required.
• Accuracy. Has the model been evaluated on representative test sets? What is the accuracy floor? Hallucination rate? Citation accuracy? The control evidence here is a documented evaluation suite that runs on a defined cadence (Areebi customers typically run it nightly).
• Timeliness. P50/P95/P99 latency against the SLA.
• Authorisation. Each inference request must be authorised by the policy engine, and the authorisation decision recorded in the audit log.

The trap to avoid: treating AI output validation as the application team's problem. PI1 puts it inside the SOC 2 scope, and auditors will ask for evidence that the validation runs and that failures are detected, escalated, and resolved.

The Privacy category has eight criteria covering the GAPP principles - notice, choice and consent, collection, use, retention and disposal, access, disclosure to third parties, quality, monitoring and enforcement. For AI workloads, the criteria apply to (a) personal data in training data, (b) personal data in prompts, (c) personal data in completions, and (d) personal data in embeddings or fine-tunes.

Areebi customers in healthcare and financial services typically include the Privacy category in their SOC 2 because procurement requires it. The Areebi GDPR compliance hub walks through the privacy controls in detail.

NIST AI 600-1 (Generative AI Profile, July 2024) is the operational companion to AI RMF 1.0 for generative AI. Because most SOC 2 auditors are not AI specialists, the practical evidence pattern is to map every TSC control to a NIST AI 600-1 action, then evidence the action with the Areebi audit log. The crosswalk:

• CC6 logical access maps to NIST AI 600-1 MS-2.6 (information integrity), MS-2.7 (security risk), GV-1.6 (accountability).
• CC7 incident management maps to MG-4.3 (incident response), MS-2.8 (evaluation of incidents).
• A1 availability maps to MS-2.5 (system stability), MG-3.1 (vendor risk).
• PI1 processing integrity maps to MS-2.1 (output validation), MS-2.2 (test set evaluation).
• P1-P8 privacy maps to MS-2.3 (data privacy), MS-2.4 (training data integrity), GV-1.7 (data subject rights).

The Areebi platform supports each of these as a first-class control with evidence stored in the audit log. The Areebi NIST AI RMF deep dives (Govern, Map, Manage) walk through the underlying RMF mappings.

ISO/IEC 42001:2023 (AI Management System) is the international management system standard for AI. For service organisations that hold both ISO/IEC 42001 certification and a SOC 2 report, the crosswalk lets a single control set satisfy both. The high-level map:

• ISO/IEC 42001 Clause 5 (Leadership) maps to SOC 2 CC1 (Control Environment).
• ISO/IEC 42001 Clause 6 (Planning) and Annex A.6 (Supplier Relationships) maps to CC3 (Risk Assessment) and CC9 (Risk Mitigation).
• ISO/IEC 42001 Clause 8 (Operation) and Annex A.7 (Data for AI Systems) maps to CC6, CC7, PI1.
• ISO/IEC 42001 Clause 9 (Performance Evaluation) and Annex A.9 (Monitoring) maps to CC4 (Monitoring of Controls).
• ISO/IEC 42001 Annex A.5 (Policies for AI) maps to CC2 (Communication and Information).

The Areebi ISO 42001 hub and the 12-month roadmap walk through the certification path that aligns with SOC 2 evidence.

Areebi publishes its own SOC 2 readiness publicly. The SOC 2 readiness tracker shows the current state of Areebi's controls, the audit period, and the open evidence items. We publish it for two reasons: first, because procurement teams ask for it and we believe transparency reduces friction; second, because it is the example pattern we recommend to regulated customers - publish your own readiness, do not hide behind "we are SOC 2-ready" claims.

The tracker shows the control set in scope (CC1-CC9, A1, C1, PI1, P1-P8 to varying depths), the audit cycle, and the named accountable executive. The Areebi compliance team designs this control so the same evidence supports the SOC 2 report, the ISO/IEC 42001 audit, and the customer security questionnaire.

SOC 2 is the procurement gate that decides whether your AI vendor list opens or closes. Areebi treats the TSC mapping as a first-class control set, with each criterion enforced by the policy engine and evidenced in the audit log. The shortcut most teams take - "we will figure out SOC 2 once we have a customer who asks" - is the wrong order of operations in 2026. Procurement is asking. Build the TSC mapping before you need it; it is the same work whether the auditor or the procurer is the first to read it.