Does SOC 2 have a separate AI trust services criterion?

Not currently. The AICPA has published guidance on AI-specific considerations for SOC 2 audits, and the Trust Services Criteria still apply to AI systems within their existing categories. The 2026 audit season is the first where major firms are including AI systems in the standard SOC 2 scope by default.

How do SOC 2 AI controls interact with ISO 42001 controls?

The two frameworks overlap. ISO 42001 has a dedicated AI management system with Annex A controls specific to AI. SOC 2 relies on the existing Trust Services Criteria applied to the AI system. Deployments pursuing both certifications map the same evidence artifacts to both frameworks. The per-decision audit record satisfies ISO 42001 Annex A.6.2.7 and SOC 2 CC7.3 with the same data.

What sample size do SOC 2 auditors use for AI decisions?

Standard SOC 2 sample sizes apply. Auditors typically select 25 to 60 items per control depending on the total population during the audit period. For AI decisions, the population is the count of AI requests during the period. High-volume deployments produce large populations, and the auditor selects a stratified sample by request category, identity, and decision outcome.

How do you evidence CC6.1 logical access controls for the model endpoint itself?

The model endpoint is not reachable directly. The inspection layer is the only ingress. The evidence artifact is the network configuration that shows the model endpoint accepting connections only from the inspection layer's identity, plus the identity binding at the inspection layer that authenticates each caller before the request forwards.

Does a SOC 2 report on the AI controls travel with the customer?

Yes. Customers receive the SOC 2 Type II report and use it as third-party assurance for their own compliance obligations. The AI-specific control coverage in the report becomes evidence the customer can present to their own auditor. The reporting language is standard SOC 2 auditor prose, and the AI-specific controls appear in the CC and PI sections rather than a separate category.

What audit-period frequency do SOC 2 AI controls require?

SOC 2 Type II covers a period of six to twelve months. The AI controls operate continuously during the period, and the auditor reviews the operating effectiveness across the full period. Deployments running their first SOC 2 Type II covering AI controls often start with a three-month observation period to build the evidence base, then extend to twelve months for the annual renewal.

SOC 2 AI Controls Mapping: Which Trust Services Criteria a Policy Gateway Actually Evidences

SOC 2 auditors are asking about AI systems in 2026 engagements. The Trust Services Criteria themselves did not change. The scope of the SOC 2 audit did. Auditors from the big four and the specialist SOC 2 firms are now including AI request handling, model access controls, and AI-produced data flows under the Common Criteria (CC6, CC7) categories and the Processing Integrity (PI) category when the deployment uses AI to produce or process customer data.

The mapping between the Trust Services Criteria and the controls that actually evidence AI system operation is where most SOC 2 engagements for AI-enabled products get stuck. The criteria are written at a level of abstraction above AI. The controls have to be written at the AI request layer.

I want to walk through the CC6, CC7, and PI criteria one by one, the specific control points at the inspection layer that evidence each, and the audit-report language that emerges from the evidence.

CC6 Logical and Physical Access Controls

CC6 covers logical access. CC6.1 through CC6.8 collectively require the entity to implement controls that restrict access to its system resources based on identity, role, and authorization policy. For an AI system, the resources are the model endpoints, the training data, and the derived output.

CC6.1 Logical access security software

CC6.1 requires the entity to implement logical access security software. For an AI deployment, the security software includes the policy engine that gates AI requests. The inspection layer runs the policy engine and evaluates every AI request against the identity and role of the caller. The evidence artifact is the per-decision audit log record that shows the policy state applied at the moment of decision.

CC6.2 Registration and authorization

CC6.2 requires new access to be registered and authorized. For AI systems, the registration covers the mapping of user identities to model access rights, prompt scopes, and tool-call permissions. The inspection layer holds the mapping in policy configuration. The evidence artifact is the policy-configuration change log, which records who added, modified, or revoked which identity's access to which AI capability.

CC6.6 System boundaries

CC6.6 requires the entity to define and enforce boundaries around its system. For an AI deployment, the boundary is the perimeter of the AI enforcement layer. The inspection layer is the boundary point. Every AI request enters and exits through it. The evidence artifact is the network configuration that shows all AI request traffic routed through the inspection layer with no direct-to-model path available.

CC6.7 Data transmission

CC6.7 requires the entity to restrict the transmission, movement, and removal of information. For AI systems, the transmission covers the prompt content sent to the model and the response content returned. The inspection layer enforces data-transmission policy on both sides. The evidence artifact is the per-decision audit record with the data-classification metadata attached.

CC7 System Operations

CC7 covers system operations. CC7.1 through CC7.5 collectively require the entity to detect and respond to security events. For an AI system, the events include prompt-injection attempts, data-exfiltration attempts through prompt content, and unauthorized tool-call attempts by AI agents.

CC7.1 Detection and monitoring

CC7.1 requires the entity to monitor for anomalies and threats. The inspection layer produces a continuous audit stream that feeds the SIEM. The evidence artifact is the SIEM ingestion configuration and the sample records the SOC analyst reviewed during the audit period.

CC7.2 Anomaly monitoring

CC7.2 requires the entity to monitor for anomalies. For AI systems, the anomalies include unusual prompt patterns, unusual tool-call sequences, and unusual response content. The inspection layer produces the request-layer stream that anomaly detection operates on. The evidence artifact is the list of anomaly detections during the audit period, the triage disposition, and the response actions.

CC7.3 Security event evaluation

CC7.3 requires the entity to evaluate security events for potential incidents. The per-decision audit log is the primary evidence for AI-related security events. The evidence artifact is the sample of security events evaluated during the audit period, keyed by record_id to the audit log entries.

CC7.4 Incident response

CC7.4 requires the entity to respond to identified incidents. For an AI incident (prompt injection, data exfiltration, unauthorized tool call), the response includes blocking further requests from the affected identity, rotating any credentials the incident exposed, and producing a post-incident report. The evidence artifact is the incident-response runbook for AI incidents and the sample incident records during the audit period.

CC7.5 Recovery and reconstruction

CC7.5 requires the entity to recover from incidents and restore normal operation. For an AI incident, the recovery includes reconstruction of the affected AI transactions from the audit log. The evidence artifact is the audit log's completeness and integrity, which allow the reconstruction under Article 12 of the EU AI Act as a byproduct.

PI Processing Integrity

PI covers processing integrity. PI1.1 through PI1.5 collectively require the entity to ensure that system processing is complete, accurate, timely, and authorized. For an AI system, the processing integrity extends to the AI decisions themselves.

PI1.1 Data processing objectives

PI1.1 requires the entity to define processing objectives for its systems. For an AI system, the processing objective is the intended use of the model, the categories of prompts the model handles, and the expected quality of the output. The evidence artifact is the AI system's intended-purpose statement, which the EU AI Act Article 4 documentation already requires and SOC 2 auditors accept.

PI1.2 Data processing inputs

PI1.2 requires the entity to control the inputs to the processing. For an AI system, the inputs are the prompts and the input-side classification of the data. The inspection layer runs input-side classification and rejects inputs that violate the processing policy. The evidence artifact is the per-decision audit record with the input classification attached.

PI1.3 Data processing outputs

PI1.3 requires the entity to control the outputs of the processing. For an AI system, the outputs are the model responses and the output-side classification. The inspection layer runs output-side classification and applies redaction or blocking when the response violates policy. The evidence artifact is the per-decision audit record with the response-side classification attached.

Compliance gap

Most SOC 2 engagements for AI-enabled products discover that the AI system falls outside the existing control coverage. The gaps are structural.

The application logs that evidence CC7.1 detection for the non-AI parts of the system do not include the AI request traffic. The SIEM ingests application access logs and infrastructure metrics, but the AI request stream is either missing or attached to the wrong subject.

The access controls that evidence CC6.2 registration and authorization for the non-AI resources do not extend to the AI capabilities. A user granted access to a SaaS application gets the AI features of that application by default, and no separate authorization step gates the AI capabilities.

The processing-integrity controls that evidence PI1.2 and PI1.3 for the non-AI processing do not extend to the AI decisions. The application controls the inputs and outputs of its non-AI logic but the AI decision layer runs inside the model and the application-layer controls are blind to it.

The evidence artifact SOC 2 auditors accept

SOC 2 auditors accept three categories of evidence for AI controls.

Configuration evidence. The policy configuration that governs AI requests, the identity provider integration that authenticates callers, and the audit-log destination that receives per-decision records. The auditor reviews the configuration in effect during the audit period.

Sample evidence. A statistically valid sample of per-decision audit records that show the controls operating during the audit period. The auditor selects the sample, and the evidence artifact is the full record for each sampled decision.

Exception evidence. The list of policy exceptions during the audit period, the approval trail for each, and the evidence that the exception was closed by the end of the period. The auditor reviews the exception log.

The three categories combined produce a SOC 2 report that describes the AI-specific controls in language the auditor's methodology accepts and the customer receiving the report understands.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits inline between your users or agents and the LLM APIs they call. Every AI request is evaluated against the identity and the policy in effect, and every decision produces an audit record.

The audit records are the sample evidence for CC6, CC7, and PI controls. The policy configuration is the configuration evidence. The exception log is the exception evidence. The three categories map to the SOC 2 auditor's expected artifacts on a per-decision basis, and the mapping is stable across audit periods.

Book a demo today.