CSA CCM AI Risk Assessment: Put Every Model Route Under an Owner

An AI risk assessment becomes operational when it names a deployed function, a data flow, a model route and the person accepting the remaining exposure. "An LLM may disclose sensitive data" belongs in a workshop. "The support summarizer can send restricted account notes to endpoint X under a shared credential" belongs in a risk register because engineering can test it and an owner can fund the treatment.

The January 2026 Cloud Controls Matrix release supplies the management structure for that work.

TL;DR

• CCM GRC-02 requires a documented, leadership-sponsored program for identification, evaluation, ownership, treatment and acceptance.
• Scope the deployed use case, then map identities, data, routes, providers, outputs and business actions.
• Test concrete scenarios and preserve the result, evidence, treatment, due date and residual-risk decision.
• DeepInspect covers authenticated HTTP traffic deliberately routed between users or agents and LLMs. Risks outside that path need separate controls.

GRC-02 defines the risk lifecycle

The current Cloud Controls Matrix artifact, released January 27, 2026, contains 207 controls across 17 domains. GRC-02 requires a formal, documented and leadership-sponsored Enterprise Risk Management program. Its required lifecycle covers risk identification, evaluation, ownership, treatment and acceptance.

Every lifecycle stage creates a reviewable artifact. Identification produces a scenario tied to a real asset or process. Evaluation records likelihood, impact and the evidence behind both judgments. Ownership names someone with authority over the service and budget. Treatment points to an engineering or governance change with a due date. Acceptance records the remaining exposure and approval.

GRC-06 then requires documented roles for planning, operation, assessment and improvement. GRC-07 maps applicable standards, contracts and statutory duties. A&A-03 puts independent assurance work on a risk-based plan and adds reassessment after significant changes or emerging risks.

This differs from the CCM compliance checklist, which asks if a control activity exists. The risk assessment explains which scenario drove it, how well it performed and who owns what remains.

Scope starts with one deployed use case

Write the use case in operational terms. Name its business purpose, users, application owner, model and endpoint, orchestration component, connected data sources, tools, output consumers and actions. Record the production regions and customer groups. Add current model, route and policy revisions.

Then draw the request path on one page. Begin with the authenticated person or agent. Follow the application, any policy decision point, retrieval or orchestration layer, model endpoint and returning response. Mark each trust boundary and evidence source. Add direct provider routes, fallback paths and background jobs that can call the model.

That page should show the cloud roles involved. A SaaS application can act as the cloud service customer for its model provider while serving its own customers as a provider. The CCM Shared Security Responsibility Model assigns controls to the parties that operate each layer. Contracts document the handoff, while the architecture shows where responsibility actually sits.

A spreadsheet containing 60 generic AI risks creates activity. One diagram with four real routes creates decisions. I would take the diagram every time.

Scenarios need an observable cause and consequence

Write each scenario as a chain that engineering can reproduce. Name the initiating condition, path through the system, affected asset or person, control expectation and business consequence. Link the scenario to CCM domains after the mechanism is clear.

For authenticated HTTP traffic to an LLM, useful scenarios include:

• A user with valid application access sends restricted customer data to an approved model for an unapproved purpose.
• An agent under a broad service identity reaches a model route outside its assigned task.
• Retrieved text carries prompt injection that changes the request and exposes protected output.
• A newly configured endpoint receives production traffic before inventory, contract and logging reviews finish.
• Sensitive content returns to the caller because policy covered the prompt while response inspection remained absent.

Map these scenarios to IAM authorization, DSP classification and transfer, STA supplier controls, LOG evidence and SEF response. Add AIS-08 when API security matters. Change controls enter when a model alias, route or system prompt altered the exposure.

Other risks sit outside this path. Training-data poisoning, model-weight tampering, compromised developer laptops, cloud control-plane failure and local tool execution need controls and owners at those layers. Keep them in the broader assessment without assigning them to an HTTP control point.

Evaluation should preserve its assumptions

A heat-map cell compresses several judgments. Keep the supporting facts underneath the final score. Record the population exposed, data sensitivity, route reachability, action authority, detectability, recovery path and business impact. Cite the source and date for each assumption.

The CCM v4.1 implementation guidelines stress that implementation depends on architecture, technology, risk, regulation and policy. That matters for AI because one control label can describe very different systems. A drafting assistant that returns text has a different consequence profile than an agent that can approve a refund or modify a customer record.

For a disclosure scenario, test the live path with a controlled payload. Use an account with a known role. Include content carrying the classification that should trigger the rule. Record the endpoint selected, policy revision, decision, response handling and generated evidence. Repeat with an allowed request so the team sees both sides of the rule.

The useful detail on a review call is the red test payload denied at 14:06 under policy revision 37. "DLP implemented" says almost nothing about effectiveness.

Inherent exposure and control effectiveness belong together

Inherent risk describes the scenario before assessed controls. Control effectiveness records how the deployed mechanisms performed. Residual risk reflects exposure after those controls and any known gaps. Keep all three in one record so an approver can see the reasoning.

Begin control testing with identity binding. IAM-12 requires uniquely associated IDs that make activities identifiable. IAM-15 requires technical measures that verify access to data and system functions is authorized. A provider API key identifies the calling application. The policy decision may need the human or agent represented by that call. Verify that the application supplies authenticated identity and role context and that the evidence retains both.

Next, test classification on the assembled prompt. DSP-04 covers data classification, while DSP-10 addresses protected transfer of personal or sensitive data within permitted scope. A context window can combine fragments that create a higher handling requirement than any individual source. The prompt-level DLP guide describes that inspection point.

Then test destination authorization, response handling, failure behavior and evidence protection. Ambiguous policy or an unavailable control should follow the approved failure rule. Decision records should reach protected storage with correlation fields before an incident requires them.

Treatment plans need engineering verbs

"Improve AI governance" cannot close a risk. A treatment should say which team changes which mechanism by which date, then name the retest that proves completion.

Useful request-boundary treatments include supplying user or agent context on each model call, limiting roles to approved route sets, adding prompt and response classification, blocking direct provider paths, versioning policy and protecting decision records outside the calling application's write path. Supplier treatments can add contract clauses, assurance evidence, destination reconciliation or an approved replacement provider. Business treatments may narrow the use case or require human approval before an action.

Link each treatment to the CCM control it changes. Preserve the ticket, approval, deployment record, test case and result. A treatment marked complete without a retest only proves that work moved through a workflow.

The CCM audit-evidence guide covers how an assessor reads those artifacts. The risk owner needs one additional item: the updated residual-risk rationale after the test.

Residual risk needs a real owner

GRC-02 includes ownership and acceptance because some exposure remains after treatment. Name the individual who can fund another control, alter the service, restrict the population or stop the use case. A committee can review the decision, but a generic group name leaves accountability diffused.

Record the residual scenario, current score, tested control state, accepted gaps, monitoring indicators, review date and conditions that reopen the decision. Approval should reference the exact model route and application revision in scope. A new provider or broader action authority can invalidate the acceptance even when the use-case label stays the same.

My opinion is simple: a residual-risk acceptance signed by someone without budget or operational authority is administrative theatre. The signature belongs with the person who can change the exposure.

Policy exceptions need the same operating discipline. GRC-04 requires an approved process for policy deviations. Give each exception an owner, narrow scope, expiry date and compensating control. Recheck it before renewal rather than rolling it forward through calendar reminders.

Change triggers keep the assessment current

Annual review provides a baseline cadence. A&A-03 also calls for assessment after significant changes or emerging risks. Build those event triggers into the risk record.

Run a scoped reassessment when the model or provider changes, retrieval gains a new data source, an agent receives another tool, a role acquires broader access or traffic enters another region. Trigger one when prompt retention changes, a fallback route enters production, an incident exposes a failed assumption or a provider's assurance status changes.

The change record should identify which scenarios and controls were reconsidered. A model-version update may affect output handling and monitoring while leaving identity policy unchanged. A new provider can change destination, contract, region, retention and incident evidence at once. Scope the review to the actual change and document why unaffected areas stayed stable.

The official STAR programme publishes self-assessments based on the CAIQ and CCM. A maintained risk register makes those answers defensible because the control description points to a current scenario, tested mechanism, owner and accepted residual exposure.

Shared responsibility sets the assessment boundary

CCM v4.1 labels control ownership as provider-owned, customer-owned or shared across cloud service models, then tells users to revise the allocation for their actual contract and architecture. For an LLM use case, application teams own their code and user flows. Model and orchestration providers own the parts they operate. Cloud providers control the relevant underlying services. The enterprise owns the business decision and use of the resulting output.

For DeepInspect, the assessable boundary is authenticated HTTP traffic that users or agents deliberately route through the proxy to LLM endpoints. Tests on that path can cover application-supplied identity and role, prompt and response classification, destination authorization, policy decision and independent evidence.

Direct calls around the route, stolen credentials, compromised endpoints, local execution, STDIO traffic, provider training pipelines, model weights and physical infrastructure sit outside that boundary. A complete risk program still assesses them under their proper owners. Precise scope gives the risk committee a truthful control map.

The CCM controls mapping helps place those treatments across the matrix without expanding any product claim beyond its mechanism.

DeepInspect

DeepInspect provides a policy decision point 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 creates a signed, tamper-evident record outside the calling application's write path. That gives a CCM risk assessment a repeatable control test and evidence for request-boundary scenarios. Model training, endpoint security, cloud infrastructure, local execution, business impact analysis and residual-risk approval stay with the systems and people that own them.

Book a technical deep dive at deepinspect.ai.