CSA AI Controls Matrix (AICM) Guide: Domains and STAR for AI

Organisations buying or building AI services need a control catalogue that says who must do what across the model provider, the platform and the application, and most AI frameworks stop short of that. The Cloud Security Alliance AI Controls Matrix (AICM) fills the gap: a vendor-neutral set of control objectives for cloud-based AI systems, built on the CSA Cloud Controls Matrix, with ownership assigned across five roles and an assessment questionnaire (AI-CAIQ) that feeds the STAR for AI assurance programme. This guide explains the structure of AICM v1.1, the domains and pillars, how to scope it by role, how to implement and evidence it, and how it maps to ISO/IEC 42001, NIST and the EU AI Act. It is for GRC teams, cloud and AI security architects, and third-party risk teams. It builds on the Cloud Security Alliance CCM and STAR Guide.

Key takeaways

AICM is CCM extended for AI. Version 1.1 has 247 control objectives in 18 domains: the CCM v4.1 domains plus a Model Security (MDS) domain.
Ownership is the main value. Every control is analysed for applicability to Model Providers, Orchestrated Service Providers, Application Providers, AI Customers and Cloud Service Providers.
The AI-CAIQ is how customers will ask. The v1.1 questionnaire has 320 questions and is the basis of a STAR for AI Level 1 self-assessment.
Mappings save work but show gaps. AICM ships mappings to ISO/IEC 42001, NIST AI RMF and AI 600-1, the EU AI Act, BSI AIC4 and, from v1.1, AIUC-1, with gap percentages.
Identity controls carry over directly to agents. The IAM domain applies to model, agent and pipeline identities as much as to people; that is where most AI incidents start.

What it is and who it applies to

CSA released AICM v1 on 9 July 2025 with 243 control objectives in 18 domains, and v1.1 on 22 June 2026 with 247 control objectives synchronised to CCM v4.1. It is free to download as a bundle containing the matrix spreadsheet, implementation and auditing guidelines, role-specific guidance, the AI-CAIQ, introductory guidance and a STAR for AI Level 1 submission guide.

Status: a voluntary industry framework. Nobody is legally required to use it, but enterprise customers increasingly send the AI-CAIQ in procurement, and STAR for AI listings are public.
Who should use it: AI model providers, AI platform and orchestration providers, SaaS vendors embedding AI, and enterprises consuming AI services who need to know which controls remain theirs.
Scope: cloud-based AI systems across the lifecycle, including generative AI. It covers classic cloud controls (identity, logging, encryption, supply chain) as they apply to AI, and AI-specific controls in Model Security and elsewhere.
Relationship to CCM: organisations already using CCM v4.1 can treat AICM as a superset and reuse existing evidence for unchanged controls.

Structure and key requirements

The 18 domains

Code	Domain	AI-specific emphasis
A&A	Audit & Assurance	Audit of AI systems and their controls
AIS	Application & Interface Security	AI application and API security; v1.1 cites prompt injection protection as AIS-15
BCR	Business Continuity Management & Operational Resilience	Continuity of AI services and models
CCC	Change Control & Configuration Management	Change control for models, prompts and configurations
CEK	Cryptography, Encryption & Key Management	Protection of model weights, data and keys
DCS	Datacenter Security	Physical security of AI infrastructure
DSP	Data Security & Privacy Lifecycle Management	Training, fine-tuning and inference data
GRC	Governance, Risk & Compliance	AI governance, risk and regulatory compliance
HRS	Human Resources Security	Staff roles and training for AI
IAM	Identity & Access Management	Access to models, data, pipelines and agent tools
IPY	Interoperability & Portability	Portability of models and data between providers
I&S	Infrastructure Security (formerly Infrastructure & Virtualization Security)	Compute and network for training and inference
LOG	Logging & Monitoring	Logging of AI activity for detection and audit
MDS	Model Security	New domain: 13 AI-specific and AI-related controls for models
SEF	Security Incident Management, E-Discovery & Cloud Forensics	AI incident handling
STA	Supply Chain Management, Transparency & Accountability	Model and data suppliers; v1.1 cites a service bill of materials as STA-09
TVM	Threat & Vulnerability Management	AI threats and vulnerabilities
UEM	Universal Endpoint Management	Endpoints that run or access AI

The domain set is the CCM v4.1 domains plus MDS, with names as CSA publishes them for CCM; the AI emphasis column is a summary, so read the control text in the matrix before relying on any one control.

The five analysis pillars

Control Type: classifies the nature of each control, which helps separate AI-specific controls from cloud controls carried over from CCM.
Control Applicability and Ownership: which of the five roles owns or shares the control.
Architectural Relevance: which layer of the AI stack the control applies to.
LLM Lifecycle Relevance: which phases of the model lifecycle the control applies to, so data and training controls can be separated from deployment and operation controls.
Threat Category: which AI threat category the control addresses, which links AICM to threat models.

Shared responsibility roles

Role	Abbreviation	Typical example	Controls it usually owns
Model Provider	MP	Organisation that trains and supplies a foundation or fine-tuned model	Model Security, training data governance, model supply chain
Orchestrated Service Provider	OSP	Platform that hosts models and orchestrates prompts, retrieval, tools and agents	Platform IAM, logging, isolation, tool integration
Application Provider	AP	SaaS or internal team building an AI application	Application security, prompt injection defences, output handling
AI Customer	AIC	Organisation using the AI service	Acceptable use, data it submits, user access, configuration
Cloud Service Provider	CSP	Underlying infrastructure provider	Datacenter, infrastructure and virtualisation controls

One organisation can hold several roles. A SaaS vendor that fine-tunes an open-weight model and builds an agent on its own platform is MP, OSP and AP at once, and must answer for all three sets of controls.

Identity and NHI requirements

The IAM domain carries over from CCM, but in AI systems most of the identities it governs are non-human: model serving accounts, training pipeline service accounts, vector database credentials, inference API keys and agent tool tokens.

Inventory every AI identity: include API keys issued to customers, keys the application holds for model providers, and credentials agents use for tools. See the Agent Identity and Access Guide.
Least privilege for agents and pipelines: scope agent and pipeline credentials to the data and tools a task needs; an agent with write access to a CRM is a privileged identity.
Short-lived credentials and rotation: prefer workload identity federation and short-lived tokens over static keys; vault anything static. See the Credential Vaulting for AI Agents Guide.
Tenant isolation: per-user or per-tenant authorisation must hold through retrieval and tool calls, not only at the front door.
Logging per identity: link LOG controls to IAM so every model call and tool call can be traced to an identity. The Moltbook database exposure in January 2026 shows the cost of getting this wrong: about 1.5 million agent API tokens were readable because database access policies were never configured.

Implementation steps

Decide your roles: for each AI service, record whether you act as MP, OSP, AP, AIC or CSP. Filter the matrix by those roles using the ownership pillar.
Reuse CCM evidence: if you already maintain CCM v4.1 or a STAR listing, mark unchanged controls as inherited and focus on AI-specific and AI-related controls, especially MDS.
Gap assess with the AI-CAIQ: answer the 320 questions internally before any customer sees them. Record evidence references against each answer.
Prioritise identity, data and model controls: fix IAM, DSP, MDS, AIS and LOG gaps first; these are where AI incidents concentrate.
Agree supplier responsibilities: for controls owned by your model or platform provider, obtain their AI-CAIQ or STAR for AI listing and record reliance in your risk register.
Pilot on one AI service: complete the full cycle (scoping, assessment, remediation, evidence) on one service before scaling.
Choose an assurance level: start with a STAR for AI Level 1 self-assessment, then decide whether Level 2 is worth it for your customers.
Keep versions under control: record which AICM version each assessment used and re-map when CSA releases updates.

Using AICM as a buyer

Third-party risk teams can use the same matrix in reverse. Ask each AI supplier which roles it holds, request its AI-CAIQ or STAR Registry entry, and check that the controls you rely on it for are answered with evidence rather than a bare "yes". Pay most attention to the MDS, DSP, IAM and STA answers: how the supplier protects model weights, whether your prompts and outputs are used for training, how it scopes the credentials its agents use inside your tenant, and which upstream model and data suppliers it depends on. Record the answers against the AICM control IDs so a later incident or contract review can trace what was promised. See the AI Procurement Checklist.

Small and large organisations

Small AI customers: filter to AI Customer controls only, answer them in a short register, and rely on supplier STAR for AI listings for the rest. A full AI-CAIQ is rarely proportionate.
SaaS vendors adding AI features: expect customers to send the AI-CAIQ; a Level 1 self-assessment published once saves answering it repeatedly.
Model and platform providers: own most MDS and I&S controls and should plan for a Level 2 route, since enterprise buyers will want independent assurance.
Large enterprises with many AI services: run AICM inside the existing ISMS or AI management system so control owners, evidence stores and audit cycles are shared rather than duplicated.

Evidence and assessment

STAR for AI assurance levels

Level	What it involves	Independent assurance	Best fit
Level 1 Self-assessment	Submit an AI-CAIQ describing how the service implements AICM controls; listing in the STAR Registry	None	First step; answering customer questionnaires at scale
Level 1 Valid-AI-ted	Automated validation of the submitted AI-CAIQ	Automated check, no auditor	Adds a quality signal to a self-assessment
Level 2 Certification	Third-party certification extending ISO/IEC 27001 or ISO/IEC 42001 (or both) with AICM controls	Accredited auditor	Organisations already certified to ISO standards
Level 2 Attestation	SOC 2 report extended with AICM controls	Independent auditor	US-centric customers who expect SOC 2

CSA's STAR for AI page notes that ISO/IEC 42001 shows a management system exists while AICM adds AI and cloud security controls, which is why the Level 2 routes combine them.

Evidence and metrics

Evidence per control: policies, configuration exports, access reviews for AI identities, model and dataset provenance records, red team reports, and log samples, referenced by AICM control ID.
Coverage: share of in-scope AICM controls (for your roles) implemented and evidenced.
MDS completion: share of the 13 Model Security controls implemented for each model you provide or fine-tune.
Supplier reliance: share of controls you rely on a supplier for that are backed by their AI-CAIQ or STAR for AI listing.
Identity hygiene: share of AI identities with an owner, scope review and rotation date.
Questionnaire turnaround: time to answer a customer AI-CAIQ, which falls once evidence is mapped.

Mapping to other frameworks

Framework	Mapping in the AICM bundle	How to use it
ISO/IEC 42001:2023	Yes	Use 42001 for the management system and AICM for the controls; the basis of the STAR for AI Level 2 42001 route. See the ISO/IEC 42001 Guide.
ISO/IEC 27001	Yes	Extend an existing ISMS; the 27001 route for Level 2.
NIST AI RMF 1.0 and AI 600-1	Yes	For US-aligned governance; AICM supplies concrete controls for AI RMF outcomes. See the NIST AI 600-1 Generative AI Profile Guide.
EU AI Act	Yes	Starting point for provider and deployer obligations; confirm legal coverage separately. See the EU AI Act Compliance Guide.
BSI AIC4	Yes	German cloud AI criteria catalogue, relevant for German public sector and regulated customers.
AIUC-1	Yes, new in v1.1	Agent-level certification; CSA highlights AIS-15 and STA-09 as AICM controls that go beyond AIUC-1. See the AIUC-1 Agent Certification Guide.
OWASP and MITRE ATLAS	Not in the bundle	Use the Threat Category pillar to link controls to OWASP risks and ATLAS techniques. See the AI Security Frameworks Crosswalk Guide.

CSA publishes gap percentages for each mapping, which is a useful reminder that a mapping is not equivalence. Record partial coverage explicitly.

Common pitfalls

Claiming controls you do not own: an application team marks model security controls as implemented when they belong to the model provider; the answer should be "relied on supplier" with evidence.
Treating Level 1 as certification: a self-assessment is a statement, not assurance. Buyers should weigh it accordingly.
Answering the AI-CAIQ without evidence: "yes" answers that cannot be backed up become contractual misstatements.
Ignoring non-human identities in IAM: access reviews cover staff but not agent tokens, pipeline service accounts or inference keys.
Version drift: assessments done on v1 (243 controls) are compared with v1.1 (247) without re-mapping.
Skipping the role analysis: one generic assessment across all services hides that some services make you a Model Provider and others only an AI Customer.

Practitioner checklist

Download AICM v1.1 and record the version used in every assessment.
Record your role (MP, OSP, AP, AIC, CSP) for each AI service and filter controls accordingly.
Reuse CCM v4.1 evidence for inherited controls and focus effort on MDS and AI-specific controls.
Complete the AI-CAIQ internally with evidence references before sharing it.
Bring every AI non-human identity into IAM inventory, review and rotation.
Obtain AI-CAIQ or STAR for AI evidence from model and platform suppliers you rely on.
Decide on STAR for AI Level 1 now and assess the case for a Level 2 route.
Use the AICM mappings to ISO/IEC 42001, NIST and the EU AI Act and record partial coverage.

CSA AI Controls Matrix Guide: AICM Domains, Shared Responsibility, AI-CAIQ and STAR for AI