How many controls are in the Cloud Controls Matrix?

CCM v4 contains 197 control objectives structured across 17 domains covering cloud technology, and it aligns with roughly 40 standards and regulations. The Consensus Assessments Initiative Questionnaire derives more than 250 questions from those objectives for use in self-assessment and third-party evaluation through the CSA STAR registry.

Does the CCM cover AI, or do we need the AICM?

The CCM covers AI traffic as outbound cloud consumption, so the identity, data, logging, supply chain, and incident domains all apply without amendment. CSA released the AI Controls Matrix on 10 July 2025 to add what the CCM lacks, principally Model Security and the AI supply chain ownership split across cloud, model, orchestration, and application providers.

Which CCM domains break first when AI arrives?

Identity and Access Management and Logging and Monitoring. Shared API keys collapse per-user entitlement at the point of the outbound call, and application-written logs fail the independence property that makes a record evidence. Data Security and Privacy Lifecycle Management follows closely, because prompt content is classified nowhere.

Do we need to redo our CAIQ for AI usage?

The existing answers stay accurate for the services they described and become misleading when read as covering model endpoints. The practical step is to re-walk IAM, DSP, LOG, STA, and SEF with AI traffic specifically in mind and note which answers rest on controls that stop at the application boundary.

How does this relate to SOC 2?

The CCM maps to SOC 2 among its roughly 40 aligned standards, so the artifacts overlap. An identity-bound, classified, independently written per-request record answers CCM domains and the SOC 2 common criteria for AI from the same store, which is the case for building the record once and mapping it many ways.

CSA CCM AI Audit Evidence: Running 197 Cloud Controls Against AI Traffic

The Cloud Controls Matrix contains 197 control objectives across 17 domains and maps to roughly 40 standards and regulations, which is why a large share of enterprise cloud assurance already runs through it. The Consensus Assessments Initiative Questionnaire turns those objectives into more than 250 yes-or-no questions, and the answers sit in the CSA STAR registry.

AI traffic falls inside that existing scope without anyone adding a control. A prompt is an outbound API call carrying regulated data to a third-party endpoint, which is the exact shape the CCM was built to govern. The problem is subtler than a gap in the framework: answers written for ordinary cloud services stop being true when the service is a model endpoint, and the questionnaire does not flag which ones. I want to walk the domains where that happens and name the evidence an assessor asks for once they notice.

Identity and Access Management (IAM)

The IAM domain asks whether access is granted to authenticated principals under least privilege, and whether that access is reviewed. A cloud service reached through SSO with per-user entitlements answers this cleanly.

A model endpoint reached through a shared API key does not. The application authenticates the user, then makes the outbound call with one credential granting permanent full access to every capability the endpoint offers, which is the opposite of least privilege at the point that matters. The artifact an assessor asks for is a per-request record binding a named principal to a specific inference call, and closing the gap is what identity-aware AI gateway architecture describes.

Data Security and Privacy Lifecycle Management (DSP)

The DSP domain governs classification, handling, retention, and transfer of regulated data. Existing answers usually describe data at rest in known stores with catalogue labels attached.

AI creates a data object with a lifespan of one API call: the context window, assembled from several sources into a payload no catalogue ever classified. The evidence is a classification decision applied to prompt content before transmission, which prompt-level DLP produces and a document-level label cannot.

Logging and Monitoring (LOG)

The LOG domain asks whether security-relevant events are recorded, protected from tampering, retained, and reviewed. Most CCM answers point at a SIEM fed by infrastructure and application logs.

For AI decisions, the demanding property is custody. An application that makes the model call and also writes the compliance record is attesting to itself. That record breaks in three ways: the application logs its successes and misses its edge-case failures, the log can be modified by the same system that failed, and a crash between the model response and the log commit leaves the action taken with the evidence gone. I set this out in You Own the AI Liability, Not the Vendor, and the property an assessor is testing is described in AI audit log immutability.

Supply Chain Management, Transparency and Accountability (STA)

The STA domain asks for an inventory of providers and evidence that each is governed. AI supply chains run deeper than the inventory usually reflects, because an orchestration layer, a vector store, and two model providers can sit behind what procurement recorded as one vendor.

The artifact that closes this is a destination log naming every model endpoint actually called during the period. Reconciling that against the registered vendor list is the single fastest way to find the gap, and it typically finds one. The same reconciliation appears under a different heading in shadow AI discovery.

Cryptography, Encryption and Key Management (CEK)

The CEK domain covers encryption in transit and at rest plus key lifecycle. AI traffic is TLS-encrypted end to end, which reads as a clean answer and creates a second-order problem: network-layer inspection runs underneath that encryption and cannot see prompt content. Any control depending on network DLP to catch regulated data leaving through an AI channel is asserting something the encryption prevents. The evidence has to come from a component terminating the session at the application boundary.

Audit and Assurance (A&A) and Governance, Risk and Compliance (GRC)

The A&A and GRC domains ask about audit planning, independence, policy, and external obligation tracking. AI adds obligations at a pace that outruns annual policy review cycles, and the evidence an assessor wants is a policy decision record showing which version of the AI usage policy was in force when a given request ran.

Security Incident Management, E-Discovery and Cloud Forensics (SEF)

The SEF domain assumes forensic reconstruction is possible. For an AI-channel exposure, reconstruction means answering which prompts carrying which classifications reached which endpoints during a window, months after the fact. Without an independent request log retained across that window, the honest answer is a description of the architecture rather than a timeline.

Where the CCM answers quietly go stale

My candid view: the CCM covers AI traffic better than most teams expect and worse than their filled-in CAIQ suggests, because the questionnaire asks whether a control exists rather than whether it reaches the AI request path. The rows above pass a self-assessment and fail a walkthrough, and the difference surfaces the moment an assessor asks to see one specific prompt from March.

DeepInspect

This is the evidence layer that makes CCM answers true for AI traffic. DeepInspect sits inline between your users or agents and the LLM APIs they call. For every request it evaluates identity, data classification, and destination, enforces per-role and per-route policy, then writes a signed, tamper-evident record before the response returns. The record holds the caller, the classification in the prompt, the model endpoint and region, the policy decision, and the response.

When a STAR assessor asks which principal sent regulated data to which endpoint on a given date, the answer is a query against records the application never controlled. The CSA AICM audit evidence view covers the AI-specific matrix CSA layered on top of the CCM. Book a technical deep dive at deepinspect.ai.