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

SOC 2 is an examination against the AICPA Trust Services Criteria. An LLM feature does not create a separate SOC 2 framework. It creates a new request path inside the existing system description, and that path needs the same proof of risk assessment, access control, monitoring, and change governance as every other production component.

The useful question is concrete: when an auditor selects one AI event, can the service organization trace it through the policy, identity, operational record, and relevant change history? A screenshot of a model console is rarely enough. The evidence needs a route back to the control that was designed and operated.

I find the evidence chain more valuable than an enormous control spreadsheet. A thin chain exposes a real gap; a thick spreadsheet can hide it for months.

CC5: control activities linked to AI risk

CC5 concerns the selection and development of control activities that mitigate risk. For an LLM deployment, begin with a risk register entry that names the application, purpose, data classes, failure mode, accountable owner, and selected control.

The control description should identify the event it governs. “AI access is restricted” leaves an auditor guessing. “The application sends authenticated LLM requests through an approved route; policy blocks unapproved data classes and records the decision” provides a population, a test method, and an evidence source.

Keep a mapping between each material risk and its control activity. Examples include approval for a model route, identity-aware authorization, prompt-data policy, output review requirements, incident escalation, and release approval. The selected controls depend on the service’s system description and commitments; an LLM vendor’s product page cannot supply that decision for the service organization.

For implementation guidance on connecting those risk decisions to an AI program, use the NIST AI RMF. Its GOVERN, MAP, MEASURE, and MANAGE functions give the control owner a practical structure for the underlying records.

CC6: identity, authorization, and transmission

CC6 covers logical and physical access controls. An AI request adds identities that teams often omit from the access review: service accounts, workload identities, delegated agents, and model-provider credentials. Each one needs a defined owner, permission scope, lifecycle process, and evidence source.

For a request to an LLM, preserve the authenticated principal or originating agent context, the application identity, requested model route, and authorization decision. An identity provider establishes authentication. The application and gateway enforce their configured authorization rules. Model-provider credentials and secrets-management controls remain separate evidence objects.

CC6.6 addresses data transmitted over public networks. TLS configuration and certificate management support that criterion. A gateway record can show that an approved HTTP request was handled, but it does not replace transport configuration evidence, key-management records, or the provider’s own security documentation.

This is where architecture diagrams become useful. Put the identity provider on the left, the application and request gateway in the middle, and the LLM endpoint on the right. Mark the control owner and retained evidence at each hop. Auditors can test that diagram. Marketing diagrams usually cannot.

CC7: operations, detection, and incident response

CC7 addresses system operations, including detection of anomalies, evaluation of security events, incident response, and recovery. AI-specific operations evidence should show the organization has defined which signals matter and who responds when they occur.

Useful signals can include policy blocks, unusual model routes, rejected identity context, rate anomalies, and provider errors. Send the relevant events to the organization’s monitoring process with an owner, severity rule, escalation path, and retention period. A classifier verdict by itself is only a signal. It becomes control evidence when the team can show how the signal was evaluated and handled.

An incident record should connect the event to the affected application, applicable policy, investigation actions, containment decision, and closure review. The incident may involve several systems. DeepInspect’s boundary is limited to HTTP AI traffic it receives between authenticated users or agents and LLMs; endpoint forensics, credential response, and downstream business actions need their own systems and records.

For broader operating evidence, see the AI governance and risk management guide. It separates framework-level accountability from the runtime signals that support it.

CC8: controlled changes to models, routes, and policy

CC8 requires controlled changes to infrastructure, data, software, and procedures. LLM deployments add several change types: model-version selection, provider routing, prompt or retrieval changes, policy configuration, classifier tuning, and gateway releases.

Treat each production policy update as a change with a requester, reviewer, test result, approval, effective time, rollback plan, and post-change verification. When a model provider changes a hosted model, record the provider notice, the organization’s evaluation, the affected routes, and the decision to continue, pin, or change the route.

The operational detail is often a timestamp. A policy version that took effect at 14:07 UTC should line up with the request records that began receiving that version. That link lets an auditor test operation before and after a change without inferring timing from a ticket title.

Building an AI evidence package

An audit-ready package for the request path usually contains these connected artifacts:

• The AI risk register and control mapping for CC5.
• Identity, authorization, and route-approval records for CC6.
• Monitoring rules, event samples, investigation records, and incident evidence for CC7.
• Change requests, approvals, test results, deployment records, and verification for CC8.
• A request-level sample that connects the applicable identity, route, policy version, decision, timestamp, and retention reference.

The AICPA criteria determine the examination. The NIST Generative AI Profile can help an organization identify generative-AI risks that its controls need to address. Keep that distinction clear during scoping: risk guidance informs the control design; the SOC 2 examination tests the stated system and controls.

DeepInspect

DeepInspect is a stateless policy gateway for HTTP AI traffic between authenticated users or agents and LLMs. For requests that cross that boundary, it can evaluate identity-aware policy and retain a per-decision audit record.

Those records can support an AI request sample for CC5 through CC8. They do not independently satisfy the Trust Services Criteria. The service organization still owns risk assessment, identity administration, monitoring, incident response, change management, and evidence retention across the full system.

Let's talk today.