Does the Cloud Controls Matrix cover AI, or do we need the AI Controls Matrix?

The CCM covers AI traffic as outbound cloud consumption, so the identity, data, logging, supply chain, cryptography, and incident domains apply without amendment. CSA released the AI Controls Matrix on 10 July 2025 to add what the CCM lacks, principally Model Security and the four-party ownership split across cloud, model, orchestration, and application providers. Organizations already assessed against the CCM inherit most of the structure.

How many controls are in CCM v4?

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

Do we have to redo the whole CAIQ for AI usage?

The existing answers remain accurate for the services they described. The practical step is to re-walk IAM, DSP, LOG, STA, CEK, and SEF with model endpoints specifically in scope, and to note which answers rest on controls that stop at the application boundary. Item 1 above defines that scope from production traffic rather than from the last architecture review.

Which item should we do first if we only have a week?

Item 1, then item 2. The destination list tells you what is actually in scope, and identity binding is the control every downstream domain depends on, because a record that cannot name the caller answers no question an assessor asks. The rest of the list is tractable once those two exist.

How does this map to SOC 2 and ISO 42001?

The CCM maps to SOC 2 among its aligned standards, so the artifacts overlap heavily. An identity-bound, classified, independently written per-request record answers CCM domains, the SOC 2 common criteria for AI, and ISO 42001 audit evidence expectations from a single store. Building the record once and mapping it several ways is the pattern that survives repeated assessment.

CSA CCM AI Compliance Checklist: Ten Items Before Your CAIQ Covers AI Traffic

The Cloud Controls Matrix carries 197 control objectives across 17 domains, and the Cloud Security Alliance maps them to roughly 40 standards and regulations. The Consensus Assessments Initiative Questionnaire converts those objectives into more than 250 yes-or-no questions, and the completed answers sit in the CSA STAR registry where customers and assessors read them.

The failure mode I keep running into has nothing to do with a gap in the framework. A CAIQ filled in during 2023 describes controls that were true for the SaaS applications and infrastructure in scope at the time, and every one of those answers is still sitting in the registry, unchanged, now being read as though it covers the model endpoints your engineers wired up last quarter. This checklist walks the ten actions that make those answers true again. Each one pairs the work with the artifact it produces, because the questionnaire asks what is in place rather than what is planned.

1. Re-scope the CAIQ against a destination list, not a memory

Pull the list of model endpoints production traffic actually reached in the last 30 days and compare it against the services your CAIQ describes. Evidence is a scoping delta naming every endpoint in production and absent from the questionnaire. Running this first stops the other nine items from being scoped against a system diagram that no longer matches the network.

2. Bind a named principal to every inference call (IAM)

The Identity and Access Management domain asks whether access is granted to authenticated principals under least privilege. A shared API key grants permanent full access to every capability the endpoint offers, which inverts the control at the moment it matters. Evidence is a per-request record binding a named user or agent to a specific inference call, and the pattern is set out in identity-aware AI gateway architecture.

3. Classify the context window before it leaves (DSP)

The Data Security and Privacy Lifecycle Management domain governs classification, handling, retention, and transfer. A prompt assembles fragments from several stores into a payload no catalogue ever labelled as a unit, so a document-level classification scheme reports clean while regulated content leaves in the body of an HTTPS POST. Evidence is a classification decision applied to prompt content at transmission, which prompt-level DLP produces.

4. Move the compliance record off the application (LOG)

The Logging and Monitoring domain asks whether security-relevant events are recorded, protected from tampering, retained, and reviewed. An application that makes the model call and also writes the record is attesting to itself, and that record fails in three specific ways: selective logging of edge cases, later modification by the system that failed, and loss between the model response and the log commit. Evidence is an externally written, signed decision record, and the property is described in AI audit log immutability.

5. Reconcile the destination log against the vendor inventory (STA)

The Supply Chain Management, Transparency and Accountability domain asks for an inventory of providers with evidence that each is governed. An orchestration layer, a vector store, and two model providers can sit behind what procurement recorded as a single vendor. Evidence is a destination log naming every model endpoint called during the period, reconciled against the registered vendor list. That reconciliation is the fastest gap-finder on this list and it almost always finds something, which is also what shadow AI discovery turns up under a different heading.

6. Terminate the session where inspection is possible (CEK)

The Cryptography, Encryption and Key Management domain covers encryption in transit and at rest. AI traffic is TLS-encrypted throughout, which reads as a clean CAIQ answer and quietly removes network-layer DLP from the control chain, because that inspection runs underneath the encryption. Evidence is a control that terminates the session at the application boundary and records what it saw, since any answer resting on network inspection of prompt content is claiming something the encryption prevents.

7. Version the policy and stamp it onto each decision (GRC)

The Governance, Risk and Compliance domain covers policy, risk treatment, and external obligation tracking. AI obligations arrive faster than an annual policy review cycle absorbs them. Evidence is a per-request record naming which revision of the AI usage policy was in force when the request ran, which is what AI policy versioning exists to produce.

8. Route model changes through change control (CCC)

The Change Control and Configuration Management domain assumes changes to production services are reviewed, approved, and recorded. Repointing a route from one model version to another changes the behaviour of a production system and frequently happens in a config file with no ticket attached. Evidence is a change record for model and route changes, joined to the decision records that ran under each configuration.

9. Prove the exit path before you need it (IPY)

The Interoperability and Portability domain asks whether data and workloads can move to another provider. For AI traffic this reaches past the application and into the evidence itself, since a compliance record that only exists inside a single vendor's console leaves with that vendor. Evidence is an export of decision records in a portable format, produced on demand rather than promised in a contract clause.

10. Rehearse the reconstruction query (SEF)

The Security Incident Management, E-Discovery and Cloud Forensics domain assumes forensic reconstruction is possible. Confirm you can answer which prompts carrying which classifications reached which endpoints during an arbitrary past window. My candid view: this is the item teams defer because it feels like preparation for an event that may never happen, and it is the one that decides whether an AI incident response playbook has anything to run against. Evidence is a reconstructable timeline query with a retention period behind it, covered in AI audit log retention requirements.

Where the ten items land

Nine of the ten rows resolve to artifacts produced at one place. The CCM audit-evidence view covers what each artifact looks like when a STAR assessor asks to see it, and the CCM controls mapping covers where in the request path each control fires.

DeepInspect

Items 2 through 9 produce their evidence at the boundary between your users or agents and the LLM APIs they call. DeepInspect sits inline at that boundary. It binds identity to each request, classifies the prompt before transmission, enforces per-role and per-route policy with a fail-closed default, allowlists and records destinations, and writes a signed per-decision record before the response returns to the caller.

For a team refreshing a CAIQ that predates its first model endpoint, items 2 and 4 decide how every other answer reads. Identity binding makes the records meaningful, and write-path independence makes them evidence rather than assertion. Book a technical deep dive at deepinspect.ai.