CSA CCM AI Controls Mapping: 17 Cloud Domains Against One Outbound Model Call

Every mapping in this piece resolves to the same moment: an HTTPS POST carrying a context window to a model endpoint, somewhere outside your network boundary. That single request is where identity is known, where classification is still evaluable, where the destination gets selected, and where a decision record is either written or lost forever. The Cloud Controls Matrix governs exactly that shape of transaction across its 197 control objectives and 17 domains.

Mapping exercises usually run the other direction. Someone takes the CCM domain list, walks down it, and writes a sentence per row describing a control that exists somewhere in the environment. The row passes. What the row does not say is whether the control reaches the AI request path, and that is the question a walkthrough surfaces. I want to set out, domain by domain, which control an enterprise consuming hosted models has to run in that path, and where it fires.

Identity and Access Management

The IAM domain asks whether access to resources is granted to authenticated principals under least privilege, and whether that access is reviewed. For AI traffic the resource is a model endpoint and the principal is frequently a service account holding one key. The control is identity binding at the boundary, carrying the end user or agent identity into the policy decision rather than collapsing every caller into a single credential. The evidence is an identity-bound per-request record, and the architecture is described in identity-aware AI gateway architecture.

Data Security and Privacy Lifecycle Management

The DSP domain governs classification, handling, retention, and transfer of regulated data. AI creates a data object with a lifespan of one API call, assembled from several stores into a context window nobody classified as a unit. The control is prompt-level classification evaluated before transmission and tied to per-role policy, so a caller whose role carries no basis for health data gets blocked at the boundary. The evidence is a per-request classification decision with the policy outcome recorded against it.

Logging and Monitoring

The LOG domain asks whether security-relevant events are recorded, protected from tampering, retained, and reviewed. For AI decisions the demanding property is custody rather than volume. The control is write-path independence, meaning the record is produced by a system the application making the model call has no ability to modify. The evidence is an externally written, signed log, and the reasoning sits in AI audit log immutability and in You Own the AI Liability, Not the Vendor.

Supply Chain Management, Transparency and Accountability

The STA domain asks who is in the chain and what each party is accountable for. AI supply chains run deeper than procurement records reflect, because an orchestration layer, a vector store, and two model providers can hide behind one registered vendor. The control is destination-aware routing against an allowlist, so a request either reaches an approved endpoint or fails closed. The evidence is a destination log naming every endpoint actually called during the period, which reconciles the vendor inventory against production traffic.

Cryptography, Encryption and Key Management

The CEK domain covers encryption in transit and at rest plus key lifecycle. AI traffic is TLS-encrypted throughout, which reads as a clean answer and creates a second-order problem: network-layer inspection runs underneath that encryption and stays blind to prompt content. The control is session termination at the application boundary, where the payload is readable and a classification decision is possible. The evidence is an inspected request record produced by a component that legitimately holds the session.

Governance, Risk and Compliance

The GRC domain covers policy, risk treatment, and external obligation tracking. For AI the control is a policy decision point that renders written policy executable in the request path, with the policy revision stamped onto each decision. The evidence is a per-request policy decision record, which converts an approved AI usage policy from a document an assessor reads into a control an assessor tests. AI policy versioning covers how the revision travels with the record.

Change Control and Configuration Management

The CCC domain assumes production changes are reviewed, approved, and recorded. Repointing a route from one model version to another changes production behaviour and often lands in a config file with no ticket behind it. The control is treating model and route selection as a configuration item under change control. The evidence is a change record joined to the decision records that ran under each configuration.

Interoperability and Portability

The IPY domain asks whether data and workloads can move to another provider. For AI this reaches past the workload and into the evidence, since decision records that only exist inside one vendor's console leave with that vendor at contract end. The control is producing records in an exportable schema. The evidence is an on-demand export, which is also what makes the same records answer several frameworks instead of one.

Security Incident Management, E-Discovery and Cloud Forensics

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. The control is the same independent request log every row above produces, retained across the investigation period. The evidence is a reconstructable timeline, which is the thing an AI incident response playbook assumes already exists.

The mapping at a glance

The four domains whose answers quietly go stale

IAM, DSP, LOG, and CEK are the rows where an existing CAIQ answer stays literally accurate and stops being responsive. "SSO with per-user entitlements" describes the application login and says nothing about the shared key on the outbound call. "Data classified in the catalogue" describes stores and says nothing about the context window. "All events forwarded to the SIEM" describes a pipe and says nothing about who controls the write. "All traffic encrypted in transit" describes TLS and quietly removes network DLP from the control chain.

My frank opinion: the CCM covers AI traffic better than most security teams expect and worse than their filled-in questionnaire suggests, and the difference is not a framework problem. The questionnaire asks whether a control exists. The walkthrough asks whether it reached the request that left at 14:02 on a Tuesday in March. Those four rows pass the first question and fail the second.

Lifecycle scope, not new controls

Assessors scope engagements by service, by data type, and by incident history, which means the same nine controls above get examined repeatedly under different headings. Building them once at the request boundary and presenting them against several scopes is the pattern that survives repeat assessment without duplicating engineering work. The CCM audit-evidence view covers what each artifact looks like under questioning, and the CCM compliance checklist covers the order to build them in.

DeepInspect

Each row above resolves to an enforcement point, and DeepInspect is that point. It sits inline between your users or agents and the LLM APIs they call, evaluates identity, classification, and destination on every request, enforces per-role and per-route policy with a fail-closed default, and writes a signed record of the decision before the response returns.

For an organization already assessed against the CCM, that turns the IAM, DSP, STA, and LOG rows from descriptions into queries. When an assessor asks which principal sent regulated content to which endpoint on a given date, the answer comes from records the application never had custody over. Book a technical deep dive at deepinspect.ai.