CSA AICM AI Compliance Checklist: Ten Items Before a STAR for AI Self-Assessment

The AI Controls Matrix carries 243 control objectives across 18 security domains, and the Cloud Security Alliance tagged each one with an owner drawn from four parties: the cloud provider, the model provider, the orchestrated service provider, and the application provider. Working out which of those you are is the first task, because it removes roughly half the matrix from your scope and makes the remaining half non-negotiable.

This checklist assumes the application provider role, which is where most enterprises consuming hosted models sit. It follows the order a STAR for AI self-assessment tends to move: identity and classification first, then policy execution, then supply chain and destination, then evidence independence and retirement. Each item pairs the action with the artifact it produces, because the CAIQ for AI questionnaire asks what is in place rather than what is planned.

1. Establish which AICM role you occupy

Decide whether you are the application provider, the orchestrated service provider, or something else in the chain, and record the reasoning. Evidence is a scoping statement naming which of the 18 domains you own, which is the document an assessor reads before anything else and the one that prevents a Model Security row being answered with a model provider's attestation.

2. Bind a named identity to every inference request

Route AI traffic so a named user or agent, rather than a shared service key, is attached to each prompt. Evidence is a per-request record showing which principal sent which prompt to which model, which is the Identity and Access Management artifact every downstream domain depends on.

3. Classify the context window before it leaves

Evaluate the classification of prompt content at the boundary, since a prompt assembles fragments from several stores into a payload no catalogue classified as a unit. Evidence is a per-request classification decision, the Data Security and Privacy Lifecycle Management artifact that prompt-level DLP produces at transmission rather than at rest.

4. Render written policy executable at the request boundary

Convert the AI usage policy into per-role and per-route rules evaluated in the request path, failing closed on ambiguity. Evidence is a per-request policy decision record, which is what moves a Governance Risk and Compliance answer from a document reference to a testable control.

5. Allowlist model destinations and log every endpoint called

Route requests only to approved endpoints and record the destination and region for each one. Evidence is a destination log that reconciles the vendor inventory against production traffic, satisfying the Supply Chain Management, Transparency and Accountability domain and regularly surfacing endpoints nobody registered.

6. Stamp the model and policy version onto every decision

Record which model, which version, and which policy revision handled each request. Evidence is a version-stamped decision record, which the Model Security domain needs to answer what reached the model and what came back on a given date rather than under today's configuration.

7. Inspect the response path, not only the request

Apply classification and policy to model output before it returns to the caller, because the AICM threat categories cover manipulation and poisoning that surface in what comes back. Evidence is a response-side classification and policy record joined to the request that produced it.

8. Keep the evidence write path outside the application

Ensure the compliance record is produced by a system the application making the AI call has no custody over, so it survives selective logging, later modification, and crash-loss between the model response and the log commit. This is the Logging and Monitoring requirement, and the argument sits in You Own the AI Liability, Not the Vendor.

9. Pre-build the incident reconstruction path

Confirm you can answer which prompts carrying which classifications reached which endpoints during an arbitrary past window, before you need to. Evidence is a reconstructable timeline query, which the Security Incident Management domain assumes exists and which an AI incident response playbook cannot substitute for.

10. Instrument service retirement

Set retention so records covering a decommissioned model version stay retrievable and keep naming that version after the route is repointed. My honest take: retirement is the AICM lifecycle stage every team skips, and it is the one that turns a clean assessment into a finding, because an assessor asking about last quarter gets an answer describing this quarter's configuration. AI audit log retention requirements covers the periods the various regimes expect.

How the checklist maps to the domains

Items 1 through 10 resolve to a handful of enforcement points at the request boundary, laid out in the AICM controls mapping. The audit-evidence view covers what each artifact looks like when a STAR for AI assessor asks. Together they turn this list into a running system with evidence attached.

DeepInspect

Nine of these ten items produce evidence at one place: 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, enforces per-role and per-route policy, allowlists and records destinations, inspects the response, and writes a signed per-decision record before the response returns. The CAIQ for AI becomes a query rather than a drafting exercise.

For an application provider preparing a Level 1 self-assessment, items 2 and 8 are the two that decide how every other answer reads, because identity binding makes records meaningful and write-path independence makes them evidence. Book a technical deep dive at deepinspect.ai.