Does adding AI to an existing SOC 2 report require re-audit of the previous period?

No. The AI-related controls apply to the current audit period. The previous period's report stands. The current report includes the AI-related test results alongside the existing controls.

Can we exclude AI from the SOC 2 scope?

Scope exclusions are possible when the AI system is not part of the service the customer receives. Internal-only AI use (an internal copilot with no customer-facing exposure) can be scoped out with a documented boundary. Customer-facing AI (a chatbot the customer uses, an AI feature embedded in the product) cannot be scoped out without materially reducing the report's usefulness to service organization customers.

How does the auditor test the AI classifier's accuracy?

The auditor tests the control's design, not the classifier's accuracy in absolute terms. The audit accepts the classifier as a control activity if the organization has a testing and tuning process that produces evidence of expected behavior. The organization's own internal testing (a periodic evaluation of the classifier against a labeled test set) provides the accuracy evidence.

What happens if the AI provider (OpenAI, Anthropic) is not SOC 2 compliant?

Most tier-1 AI providers hold SOC 2 Type II reports. The service organization typically includes the provider's report as a subservice organization report and describes the complementary user entity controls. The service organization's own controls apply to the AI request path within the organization's environment.

How do we handle the case where the AI provider updates its model mid-audit period?

The audit report describes the operating environment during the period. Model version changes get documented in the change management records. The auditor traces the change through the change management process and verifies the audit log recorded the new version starting at the switchover time. The change does not typically require a report modification unless the change materially affected control effectiveness.

SOC 2 Common Criteria for AI: Mapping CC5, CC6, CC7, and CC8 to LLM Deployment Controls

SOC 2 reports use the AICPA Trust Services Criteria. The 2017 Common Criteria (CC1 through CC9) apply to every service organization's security engagement, regardless of whether the organization opts into the availability, confidentiality, processing integrity, or privacy categories. When the service organization deploys an LLM as part of the service, the auditor tests the AI-related controls against the existing criteria. CC5 (control activities), CC6 (logical access controls), CC7 (system operations), and CC8 (change management) carry the most weight because the AI request path introduces new control gaps in each area.

I want to walk through the CC5, CC6, CC7, and CC8 tests as they apply to an LLM deployment, the control activities that auditors have accepted as evidence in 2025 and 2026 engagements, and the inspection-layer records the service organization produces to carry the evidence in a single audit pass.

CC5: Control Activities

CC5 requires the service organization to select and develop control activities that contribute to the mitigation of risks to the achievement of objectives. For an LLM deployment, the auditor tests whether the organization has identified the AI-specific risks and has selected control activities that address them.

The auditor's test procedures typically ask for:

The AI risk register that names the AI-specific risks the organization has identified. Common entries include: unauthorized disclosure of customer data through the AI prompt, unauthorized decisions made by the AI system, non-deterministic AI output that affects service delivery, and unauthorized access to the AI infrastructure by internal actors.

The mapping of each risk to a specific control activity. The mapping has to name the control, the responsible role, and the evidence the control produces.

The evidence samples showing the controls operated during the audit period. The auditor samples 25 to 40 events from the AI request log and traces the control operation to each.

The control activities that address AI risks include: the AI Usage Policy (see the policy template article), the AI request classifier that flags prohibited data classes at request time, the AI gateway that enforces the identity-based access rules on each request, the AI audit log that records each decision, and the AI incident response runbook.

CC6: Logical and Physical Access Controls

CC6 requires the service organization to implement logical and physical access controls. CC6.1 covers the access control policy. CC6.2 covers the identification and authentication of users. CC6.6 covers the transmission of data over public networks.

For an LLM deployment, CC6.1 tests whether the access to AI systems is governed by an access control policy. The policy has to name the AI systems in scope, the roles that can access each system, and the approval process for access changes.

CC6.2 tests whether users are identified and authenticated before accessing the AI system. The service organization typically federates the AI access to the identity provider (Okta, Entra ID, Google Workspace). The auditor tests the identity federation, the multi-factor authentication enforcement, and the deprovisioning process when users leave the organization.

CC6.6 tests the transmission of data over public networks. AI requests to OpenAI, Anthropic, or Google typically traverse the public internet. The auditor tests the TLS configuration, the certificate management, and the transmission integrity.

The auditor accepts the AI gateway as the enforcement point for CC6. The gateway resolves the identity federation on each request, enforces the access control policy at the gateway, and records the enforcement decision in the audit log. A single gateway satisfies CC6.1, CC6.2, and CC6.6 for the AI traffic.

Access reviews under CC6.3 apply to AI access separately from the general system access. The AI access review covers the users and service accounts authorized to make AI requests, the roles assigned, and the policy exceptions granted. The review runs quarterly for most engagements.

CC7: System Operations

CC7 covers system operations including the detection and monitoring of anomalies (CC7.2), incident response (CC7.4), and change management coordination (CC7.5).

CC7.2 tests whether the organization detects anomalies in AI system operation. The AI gateway's classifier verdicts and policy events serve as the anomaly detection sources. The SIEM ingests the events and runs the detection rules. The auditor tests whether the detection is operational and whether the SOC receives alerts on anomalies.

CC7.4 tests the incident response process. The AI incident response runbook (see the runbook article) provides the process artifact the auditor reviews. The auditor samples incidents from the period and traces the response through the runbook phases.

CC7.5 tests the coordination of changes to systems with monitoring. When the AI gateway policy changes, the SIEM detection rules that depend on the policy have to update. The auditor tests whether the change coordination is documented and operational.

For AI system operations, the CC7 evidence set includes: the SIEM detection rules that reference the AI gateway signals, the incidents opened in the period, the incident response records with phase timestamps, and the change coordination records for AI-related policy changes.

CC8: Change Management

CC8 covers change management. The service organization has to authorize, design, develop, configure, document, test, approve, and implement changes to infrastructure, data, software, and procedures.

For an LLM deployment, CC8 has three categories of change the auditor examines.

Model provider changes. When OpenAI updates GPT-5 or Anthropic releases a new Claude version, the change affects the AI system's behavior. The service organization typically has no advance notice of the model provider's change. The change management process has to account for provider-initiated changes: monitoring the provider's release notes, testing the new model version against the organization's regression suite, and updating the audit log's model version field on switchover.

Policy changes. Changes to the AI gateway policy affect the decisions the gateway makes on live traffic. Policy changes have to run through the standard change management process: change request, testing, approval, implementation, verification. The auditor samples policy change records and traces the approval and verification.

Infrastructure changes. Changes to the AI gateway itself, the storage layer that holds the audit records, and the classifier configuration all follow the standard change management process.

The CC8 evidence set for AI includes: the change request records for AI-related changes, the approval records from the change advisory board, the test results for provider updates, and the verification records showing the change operated as intended after implementation.

The evidence artifacts the auditor accepts

Across CC5, CC6, CC7, and CC8, the auditor accepts a small set of artifacts as evidence for most controls.

The AI Usage Policy artifact (the document plus the policy events showing the enforcement).

The AI risk register (the document plus the tie-outs to control activities).

The AI gateway audit log (the record series showing the decisions the gateway made during the audit period).

The identity provider integration records (the federation configuration plus the access review records).

The SIEM detection rules and the alert records (the rule definitions plus the alerts fired in the period).

The incident response records (the incidents plus the runbook execution records).

The change management records (the change requests, approvals, and verification records).

The auditor's sampling typically pulls 25 to 40 events from the audit log across the audit period. The events have to trace through to the control activities the sample tests. Broken traces (an event that cannot be resolved to a control) become exceptions the auditor documents in the report.

The Type II report considerations

A SOC 2 Type II report covers the operating effectiveness of controls over a period, typically six or twelve months. For an LLM deployment new to the organization, the initial Type II period requires operating evidence across the full period. Deployments that go live mid-period cannot support a Type II report until the following period.

The auditor may accept a Type I report on the AI controls (a point-in-time report on the design of the controls) as a bridge report while the organization builds the operating evidence for the Type II period.

The auditor's fees for the AI-related work vary with the depth of the deployment. Adding AI to an existing SOC 2 report typically adds 30 to 60 hours of audit work.

The interaction with ISO 42001 and NIST AI RMF

Service organizations that also pursue ISO 42001 certification or align to NIST AI RMF can reuse the SOC 2 evidence set. ISO 42001 Annex A.8.4 (responsible use logging) overlaps with SOC 2 CC7.2. NIST AI RMF MEASURE and MANAGE functions overlap with SOC 2 CC5 and CC7.

The overlap does not eliminate the need for framework-specific evidence, but reduces the incremental effort. The service organization's control framework maps the same underlying evidence to the applicable criteria across the frameworks.

DeepInspect

The DeepInspect gateway produces the audit log the SOC 2 auditor samples for CC5, CC6, CC7, and CC8 evidence. The gateway's identity binding satisfies CC6.1 and CC6.2. The gateway's policy engine satisfies CC5's control activity requirement. The gateway's audit log satisfies CC7.2's anomaly detection source and CC8's change verification.

The gateway integrates with the identity provider (Okta, Entra ID, Google Workspace) and the SIEM (Splunk, Datadog, Chronicle, Sentinel) the SOC 2 report references. The integration lets the auditor trace the AI request from the identity federation through the policy enforcement to the audit record in a single evidence chain.

If your team is preparing a SOC 2 report that includes an LLM deployment or wants to align the AI evidence pack to the Common Criteria, let's talk today.