CSA CCM LLM Requirements: A Baseline for Hosted Model Traffic

An application's CCM obligations become visible in one production inference request. An authenticated person or agent asks the application to perform a task. The application assembles a prompt, chooses a model endpoint, receives a response and may convert that response into a business action. Identity, data, API, supplier, logging and incident controls touch that sequence.

The useful baseline places requirements around the request and assigns everything deeper in the service chain to an explicit owner.

TL;DR

• CCM v4.1 contains 207 controls across 17 domains and applies to hosted LLM use as cloud consumption.
• Application teams need IAM, DSP, AIS, STA, LOG and SEF controls around each production model route.
• Each requirement should produce current, versioned evidence tied to the deployed application and endpoint.
• DeepInspect covers authenticated HTTP traffic deliberately routed between users or agents and LLMs. Layers outside that path need separate controls.

CCM requirements follow the cloud service relationship

The current Cloud Controls Matrix artifact, released January 27, 2026, lists 207 controls across 17 security domains. Its Shared Security Responsibility Model allocates controls among cloud service providers and customers for IaaS, PaaS and SaaS, with shared ownership where both parties act.

A hosted LLM is a cloud service. The application provider consuming its API acts as a cloud service customer for that relationship. If the application then exposes model-backed functions to enterprise customers, it also serves them as a service provider. One company can therefore hold provider and customer duties around the same inference request.

Document those roles for every assessed service. Name the model provider, orchestration services, cloud platform and customer-facing application. Record which party implements each control and which evidence crosses the contract boundary. The CCM controls mapping shows how the matrix lands on the AI request path. The baseline below focuses on the application that consumes hosted models through HTTPS.

IAM requirements keep identity attached to the call

IAM-03 requires an inventory of identities and their access levels. IAM-05 establishes least privilege, IAM-12 makes activity identifiable through uniquely associated IDs, IAM-13 covers strong authentication and IAM-15 requires technical measures that verify authorized access to data and system functions.

Authentication at the user interface supplies the first field. The authorization decision also needs the person or agent represented by the model call, assigned role, requested operation and approved model route. Carry that context through the application and preserve it in the policy record. A provider API key can remain the transport credential. It should never become the only identity in the evidence.

Test one human role and one non-human identity. Confirm that each reaches the intended route and data classes. Change or disable the identity in the authoritative directory, then verify that model access follows. Review privileged identities separately and time-limit privileged rights where IAM-10 applies.

The identity-aware AI gateway architecture describes the request fields behind that control test.

DSP requirements apply to the assembled context window

An inventory of sensitive, regulated and personal data comes from DSP-03. Formal data classification follows under DSP-04 for the same inventory. Data-flow documentation required by DSP-05 identifies what gets processed, stored or transmitted and where. Protected transfer of personal or sensitive data within the permitted scope falls under DSP-10. Retention and deletion sit in DSP-16, while DSP-19 addresses data location.

Inventory every source that can enter a prompt. Record the source classification and the transformation that assembles the context window. Then classify the transmitted payload as a unit. A support request can combine a public product description, an internal runbook, customer account text and an agent instruction. The final payload carries the highest relevant handling rule even when each fragment arrived through an approved connector.

Define allowed data classes by role, use case and destination. Apply the rule before transmission and to the returning response. Decide which prompt or response details belong in evidence, which fields need tokenization and which can use a controlled reference. The prompt-level DLP guide covers that inspection point.

A provider privacy statement supports supplier review. Classification still has to occur where the application assembles the request.

AIS requirements govern the model interface

AIS-02 requires baseline application security requirements. AIS-04 places security into the development lifecycle, AIS-05 covers acceptance testing for new systems and versions, and AIS-08 requires processes and technical measures to secure APIs. Hosted model calls therefore belong inside the application's ordinary security baseline rather than in an experimental exception.

Document approved endpoints, authentication method, request schema, timeouts, retry behavior, content limits and failure handling. Validate input before constructing the model request. Treat model output as untrusted data when it enters rendering, code execution, database queries or downstream tools. Keep system prompts and route configuration under change control.

Acceptance testing should include denied data classes, disallowed destinations, malformed provider responses, timeouts, rate limits and policy-service failure. Test one approved request as well. Record the model route, application revision, policy revision, result and evidence reference for each case.

The baseline should also cover bypass routes explicitly. If application code can call the provider directly around the approved policy point, document that route and close it with network, credential or deployment controls. A gateway only governs traffic deliberately sent through it.

STA requirements expose the service chain

The Shared Security Responsibility Model and its documentation sit under STA-02 through STA-07. An inventory of supply-chain relationships satisfies STA-08. Periodic risk review follows STA-10, while service-agreement provisions for logging, incident communication, audit rights, data privacy and resilience come through STA-11. Risk-based security assessment of the supply chain appears in STA-16.

Build an inventory that names every model provider, orchestration service, vector or retrieval service, API intermediary and cloud dependency used by the application. For each relationship, record service owner, endpoint, regions, data classes, contract, assurance evidence, incident contact, change-notice terms and exit plan.

Then compare that approved list with observed model destinations. Procurement records the organization's approved service intent. Traffic shows where production data actually went. Reconcile both after material releases and on a defined schedule. A model alias or orchestration setting can redirect traffic while the vendor record remains unchanged.

My opinion is direct: a supplier inventory without production destination reconciliation is paperwork about intent. The running route decides where the data went.

The CCM compliance checklist puts that reconciliation beside the wider readiness tasks.

LOG requirements create usable evidence

Documented logging scope comes from LOG-07 and receives review after threat changes or relevant regulatory updates. Records under LOG-09 contain relevant security information. Protection for logs and records comes through LOG-02 and LOG-10. Restricted access and evidence of that access satisfy LOG-04, while reliable time across systems supports LOG-06.

Build each inference record around a correlation ID. Include timestamp, application-supplied identity and role, application and route, model endpoint and version, content classification, policy revision, decision and outcome. Add response classification and handling when the response returns through the controlled path. Record allowed, denied and failed interactions.

An engineer should be able to select one request and follow it across identity, application, policy, provider and incident systems without matching timestamps by eye. At 16:42 during a provider outage, the operations screen may show a route change. The evidence should name the destination actually used, rather than the model alias engineers expected.

Write-path independence materially strengthens the compliance record. Protected centralized storage helps only when the application that made the model call lacks authority to rewrite the compliance event. The CCM audit-evidence guide explains the assessment view of those artifacts.

Change and fallback requirements preserve the baseline

The CCC domain applies to model routes, provider endpoints, orchestration settings, system prompts, retrieval sources, access roles, content policy, retention and fallback behavior. Quality testing and approval sit under CCC-02. Documented configuration baselines come from CCC-06, deviation detection follows CCC-07 and rollback to a known good state satisfies CCC-09.

Treat a model alias change as a production change. Record the request, risk review, approval, deployment, validation and rollback plan. Update data-flow and supplier records when the endpoint, region or processing terms change. Re-run the affected IAM, DSP, AIS and LOG tests.

Choose fallback behavior for each approved use case. During an outage, a drafting assistant may defer the request. Support summarization can move to a reviewed secondary endpoint. Consequential workflows may require human handling before they proceed. The fallback carries its own identity, data, destination and evidence requirements. Confirm that policy evaluates the alternate route before transmission and that the record names the endpoint used.

Silent fallback produces a green availability dashboard while audit evidence describes the wrong service. Make the transition visible to operations and preserve it as a change or resilience event.

SEF requirements prepare the response

An incident response plan under SEF-03 includes communication for internal teams, impacted customers and relevant supply-chain parties. Planned incident exercises at the model route satisfy SEF-04. Event triage sits under SEF-06, while categories and severity levels shape response through SEF-07. Breach notification follows SEF-08, and SEF-09 requires a secure incident repository.

An LLM playbook should cover restricted data sent to a model, unauthorized destinations, prompt injection with impact, cross-tenant response exposure, route compromise and provider incidents affecting the application. Define the entry criteria and owner for each category. Include route denial, role restriction, model rollback, reviewed fallback, customer communication and provider escalation in the response options.

The incident record needs the inference correlation fields plus category, severity, affected assets and data, timeline, containment, recovery, root cause, corrective action and approvals. Exercise one scenario through the real model route. A tabletop confined to slides can miss unavailable records and unclear containment authority.

The official STAR programme uses CAIQ self-assessments based on CCM for Level 1 transparency. A useful answer to an LLM control question should point to policy, configuration, a recent test and retained evidence.

The HTTP boundary covers part of the baseline

Several requirements converge on authenticated HTTP traffic between an application and an LLM endpoint: identity binding, prompt and response classification, destination authorization, policy enforcement, request logging and route containment. A control point on that path can evaluate and record those facts before traffic proceeds.

Other requirements live elsewhere in the service chain. Provider due diligence and contract terms are governance work. Training-data controls and model-weight integrity sit with parties handling those assets. Endpoint security, cloud infrastructure, local execution, STDIO tool traffic, business continuity decisions, human review design and legal interpretation require separate systems and owners. Direct API calls around the configured route also bypass its policy and evidence.

CCM assessments work best with precise responsibility allocation. Put each requirement beside the party and enforcement point that can satisfy it, then retain the handoff evidence. One product entry should never stand in for the complete 207-control matrix.

DeepInspect

DeepInspect sits inline on the authenticated HTTP path between users or agents and LLM APIs. For traffic deliberately routed through it, policy can evaluate application-supplied identity and role, content classification, model destination and route before forwarding. The returning response can be evaluated on the same path.

Each decision produces a signed, tamper-evident record outside the calling application's write path, carrying the policy and model route used at that moment. That supports the IAM, DSP, LOG, destination and incident parts of the baseline. Supplier due diligence, training and model weights, endpoints, local tools, cloud controls, continuity and human governance stay outside the product boundary.

Book a technical deep dive at deepinspect.ai.