---
title: "AI Controls Matrix: A Practical Guide to AICM and AI-CAIQ"
url: "https://www.arphie.ai/blog/ai-controls-matrix"
collection: blog
lastUpdated: 2026-08-08T17:43:01.552Z
---

# AI Controls Matrix: A Practical Guide to AICM and AI-CAIQ

AI systems cross cloud, model, application, data, and customer boundaries. A policy can assign broad responsibility while leaving the actual control, evidence, and owner unclear. The AI Controls Matrix gives security and governance teams a common structure for closing that gap. The practical challenge is scoping it to your service and turning its requirements into evidence-backed answers that customers and auditors can review.



## What Is the AI Controls Matrix?



An AI controls matrix can mean any working document that connects AI risks to controls, owners, evidence, and tests. The capitalized **AI Controls Matrix (AICM)** is the Cloud Security Alliance's vendor-agnostic security and governance framework for cloud-based AI systems. Its control objectives cover the policies, processes, and technical measures needed to develop, deploy, operate, and consume AI responsibly.



For respondent-side security and governance, risk, and compliance (GRC) teams, one distinction prevents a lot of wasted work: AICM is the control catalog, while the AI Consensus Assessments Initiative Questionnaire (AI-CAIQ) is the response document. We built [Arphie for security questionnaire workflows](https://www.arphie.ai/security-teams). When an AI-CAIQ or a custom AICM-aligned workbook arrives, our AI agents draft from connected policies, control records, and evidence. They show sources and confidence signals, route questions to the right reviewers, and export the approved Excel file in place. This keeps customer due diligence moving while human control owners decide applicability, validate every claim, and provide final sign-off.



The current [AICM v1.1 package](https://cloudsecurityalliance.org/artifacts/ai-controls-matrix-v1-1) contains 247 control objectives across 18 domains. It builds on the Cloud Controls Matrix (CCM) and adds AI-specific coverage for areas such as model security, prompt and output handling, agent boundaries, data provenance, and shared responsibility across the AI supply chain.



A control objective defines the outcome an organization should achieve. It does not decide whether the objective applies to a particular service or prove that a control works. Those decisions require a documented scope, assigned ownership, implementation evidence, and testing.



## How AICM v1.1 Is Structured



The current [machine-readable AICM dataset](https://cloudsecurityalliance.org/artifacts/aicm-machine-readable-bundle-json-yaml-oscal) classifies 200 objectives as cloud and AI related, 32 as AI-specific, and 15 as cloud-specific. That mix reflects AICM's design: existing cloud controls remain relevant, with an added layer for risks introduced or amplified by AI.



| Domain | Controls | Main coverage |
| --- | --- | --- |
| Audit & Assurance | 6 | Independent assessment, audit planning, findings, and remediation. |
| Application & Interface Security | 15 | Secure development, APIs, input and output validation, agent boundaries, and sandboxing. |
| Business Continuity Management and Operational Resilience | 11 | Impact analysis, continuity planning, backup, recovery, and resilience testing. |
| Change Control and Configuration Management | 9 | Controlled changes to systems, configurations, models, prompts, and related assets. |
| Cryptography, Encryption & Key Management | 21 | Encryption, secrets, certificates, keys, and cryptographic lifecycle management. |
| Datacenter Security | 18 | Physical facilities, environmental safeguards, access, and asset protection. |
| Data Security and Privacy Lifecycle Management | 24 | Data inventory, classification, lineage, privacy, retention, transfer, and disposal. |
| Governance, Risk and Compliance | 15 | AI policy, risk management, legal obligations, governance, and oversight. |
| Human Resources | 15 | Screening, training, acceptable use, role changes, and offboarding. |
| Identity & Access Management | 18 | Identity lifecycle, authentication, authorization, least privilege, and privileged access. |
| Interoperability & Portability | 4 | Data and service portability, interfaces, and exit planning. |
| Infrastructure Security | 9 | Infrastructure configuration, network protection, environments, and segmentation. |
| Logging and Monitoring | 16 | Event capture, integrity, alerting, model and service monitoring, and anomaly detection. |
| Model Security | 13 | Model provenance, integrity, access, evaluation, attacks, and secure model handling. |
| Security Incident Management, E-Discovery, & Cloud Forensics | 10 | AI-aware incident preparation, response, evidence preservation, and lessons learned. |
| Supply Chain Management, Transparency, and Accountability | 16 | Supplier risk, model and component provenance, transparency, and shared responsibility. |
| Threat & Vulnerability Management | 13 | Threat modeling, vulnerability handling, security testing, and remediation. |
| Universal Endpoint Management | 14 | Managed endpoints, device posture, software controls, and data leakage prevention. |



Each objective also has metadata that helps you decide where it belongs:



- **Control Type.** Separates AI-specific, cloud-specific, and combined controls.



- **Control Ownership.** Identifies typical responsibility across providers and customers.



- **Architectural Relevance.** Maps objectives to components of the generative AI stack.



- **Lifecycle Relevance.** Connects controls to preparation, development, evaluation and validation, deployment, delivery, and service retirement.



- **Threat Category.** Links controls to risk areas such as model manipulation, data compromise, and service abuse.



AICM also includes crosswalks to ISO/IEC 42001, the NIST AI Risk Management Framework and Generative AI Profile, the EU AI Act, BSI AIC4, and AIUC-1. These mappings support evidence reuse. They do not make the requirements interchangeable.



## AICM, AI-CAIQ, and STAR for AI Serve Different Jobs



The AICM package includes several connected artifacts. Treating them as separate work products makes implementation easier to manage.



| Artifact | Job | Working output |
| --- | --- | --- |
| AICM control catalog | Defines the security and governance outcomes to address. | Scoped control set. |
| Implementation and auditing guidelines | Explains how each actor can implement a control and how an assessor can test it. | Control design, procedures, and test plan. |
| AI-CAIQ | Converts AICM objectives into 320 self-assessment and third-party assessment questions. | Yes, No, or Not Applicable answers with ownership and evidence. |
| STAR for AI | Provides CSA's assurance path based on AI-CAIQ disclosure and further validation. | Registry self-assessment or higher assurance designation. |



AI-CAIQ is separate from the conventional cloud-focused assessment covered in our [CAIQ v4.1 questionnaire guide](https://www.arphie.ai/blog/caiq-questionnaire). That questionnaire maps to CCM v4.1 rather than AICM and uses a different workbook.



AICM itself is a voluntary framework. It is not a law, certification, or one-time checklist. A contract, customer requirement, internal policy, or applicable regulation can still make a particular control operationally mandatory.



## How to Apply the AI Controls Matrix



### 1. Define the System Boundary



Scope one AI service or use case at a time. A company-wide answer often hides material differences between an internal copilot, a customer-facing application, and an autonomous agent with production access.



Record the context that changes control applicability:



- **Purpose and Users.** State what the system does, who uses it, and which decisions or actions it influences.



- **Architecture.** Identify the application, orchestration layer, models, retrieval components, plugins, infrastructure, and endpoints.



- **Data Flows.** Record inputs, outputs, training or fine-tuning data, retrieved knowledge, logs, retention, and transfers.



- **Authority.** Document what the system can read, generate, recommend, change, or execute.



- **Risk Context.** Include data sensitivity, jurisdictions, regulatory classification, customer commitments, and potential harm.



- **Dependencies.** List upstream providers, subprocessors, open-source components, and customer-managed controls.



This service profile becomes the rationale for every control you select or exclude.



### 2. Assign Your Role in the AI Supply Chain



AICM uses a shared security responsibility model. One organization can occupy more than one role, and its role can change between products.



| Role | AICM abbreviation | Responsibility boundary |
| --- | --- | --- |
| Model Provider | MP | Develops, trains, fine-tunes, or distributes the model. |
| Orchestrated Service Provider | OSP | Combines models, data, tools, and guardrails into an AI service layer. |
| Application Provider | AP | Delivers the end-user application and controls its application behavior. |
| AI Customer | AIC | Selects, configures, administers, and uses an AI service in its environment. |
| Cloud Service Provider | CSP | Supplies the underlying compute, storage, networking, and cloud platform. |



Assign each applicable objective as provider-owned, customer-owned, or shared. For shared controls, describe the handoff. A statement such as “the model provider handles security” is incomplete if the application provider still owns input validation, tenant permissions, output handling, and customer-facing disclosures.



### 3. Select Controls Using Applicability and Risk



Start with role, architecture, lifecycle, and threat metadata. Then apply the service's risk profile. High-impact uses, sensitive data, external actions, and broad tool permissions require a deeper control set and stronger evidence.



Document the reason for every exclusion. “Not applicable” should mean that the control falls outside the defined service boundary, not that implementation is difficult or evidence is missing. A control owned upstream can remain relevant because your organization may need supplier assurance, a contractual commitment, or monitoring of that dependency.



### 4. Map Current Controls to Evidence



AICM is a superset of CCM v4.1, so organizations with mature cloud controls can reuse much of their existing program rather than create parallel policies. The [v1.1 release guidance](https://cloudsecurityalliance.org/blog/2026/07/14/ai-controls-matrix-v1-1-strengthening-the-foundation-for-trustworthy-ai) explains that Model Security is the new AI-focused domain and that the Infrastructure Security domain carries forward the CCM scope under a new name.



Map each applicable objective to evidence that shows both design and operation:



| Evidence layer | Examples |
| --- | --- |
| Governance | Approved policy, risk appetite, role charter, control standard, or responsibility matrix. |
| Procedure | Runbook, secure development procedure, evaluation protocol, incident playbook, or supplier review process. |
| Configuration | Access policy, guardrail settings, model registry entry, retention configuration, or deployment rule. |
| Operating record | Approval, change ticket, access review, evaluation result, alert, incident record, or training completion. |
| Independent assurance | Audit result, penetration test, red-team report, certification, or remediation retest. |



A policy can show that a control was designed. Dated records, configurations, and test results show whether it operated.



### 5. Build a Working Implementation Matrix



Keep the official AICM workbook unchanged. Add an internal working layer that connects each selected objective to your system, evidence, test, and response. A practical record contains these fields:



| Field group | What to record |
| --- | --- |
| Scope | Service, use case, AICM domain and control ID, applicability decision, and rationale. |
| Accountability | Implementer, accountable owner, reviewer, upstream dependency, and customer responsibility. |
| Implementation | Control activity, system or process, frequency, and trigger. |
| Evidence | Artifact name, source link, owner, version or date, and sharing classification. |
| Testing | Design test, operating-effectiveness test, sample, last result, and next test date. |
| Status | Implemented, partial, not implemented, or not applicable, plus gap and remediation target. |
| Response | Related AI-CAIQ question, draft disclosure, approved wording, and sign-off record. |



This layer separates internal evidence from customer-safe disclosure. It also prevents one stale answer from becoming the default across services with different architectures.



![Workflow from a scoped AICM control through ownership, operating evidence, AI-CAIQ response, and human approval](https://cdn.prod.website-files.com/672fc2345132970736914b73/6a7662d9fe257d35d656aef7_0372be23-2fa3-40d0-9fc7-e457f2d91b8d.png)



### 6. Test and Maintain the Control Set



Test control design first: does the activity address the objective, assign authority, and specify evidence? Then test operating effectiveness using a representative sample or technical result. Record gaps with an owner, risk, milestone, due date, and retest requirement.



Review the scoped matrix on a defined cadence and when any of these events occur:



- **Architecture Changes.** A new model, retrieval source, plugin, agent tool, or hosting pattern changes the boundary.



- **Material Releases.** Model, prompt, guardrail, or workflow updates change behavior or risk.



- **Provider Changes.** A supplier changes terms, data use, hosting, subprocessors, or control coverage.



- **Incidents and Failed Tests.** An event exposes a missing or ineffective control.



- **Requirement Changes.** A law, standard, contract, or customer commitment changes the expected outcome.



## How to Complete AI-CAIQ Without Overclaiming



The [AI-CAIQ v1.1 workbook](https://cloudsecurityalliance.org/artifacts/ai-consensus-assessments-initiative-questionnaire-ai-caiq-v1-1) maps 320 questions to the 247 AICM objectives. Several objectives produce more than one question, so a single control can require separate answers about implementation and review frequency.



CSA's [AI-CAIQ completion guidance](https://cloudsecurityalliance.org/artifacts/filling-in-the-ai-caiq) defines four respondent fields:



| Workbook field | What a defensible response contains |
| --- | --- |
| Service Provider AI-CAIQ Answer | Exactly one status: Yes, No, or NA (Not Applicable). Treat Yes as an evidence-backed claim and explain every NA answer. |
| SSRM Control Ownership | The responsible actor or shared ownership combination from AICM's shared security responsibility model. A No answer still needs a remediation owner. |
| Service Provider Implementation Description | A concise description of how the control works for this service, with specific policies, configurations, records, versions, and evidence links. |
| Service Customer Responsibilities | The policies, settings, access decisions, monitoring, or processes the customer must operate. |



For a partial implementation, the answer should reflect effectiveness. A minor gap can sit behind a Yes when the limitation and dated remediation are disclosed. A gap that materially reduces effectiveness belongs under No with a corrective-action plan. Not Applicable should never stand in for “not yet implemented.”



A useful answer is specific enough for a customer to understand the boundary and for an auditor to follow the evidence path. An AICM-aligned change-control response for an application provider could look like this:



| Response field | Example |
| --- | --- |
| Answer | Yes. |
| Ownership | Owned by AP. |
| Implementation description | Production prompts, retrieval settings, and application configurations are version-controlled. Changes require peer review, pre-deployment testing, approval, and a deployment record. Evidence includes the AI change standard, repository approval logs, and release tickets. |
| Customer responsibilities | Customers control tenant administrators and periodically review permissions for their connected knowledge sources. |
| Internal approval | Engineering validates the implementation and Security approves the disclosure and evidence scope. |



This is where response automation should reduce retrieval and coordination work without making the control judgment. Our AI agents can find the current policy, control record, and prior approved language; create a source-backed first draft; and route low-confidence or sensitive items to the responsible reviewer. The control owner still confirms the Yes, No, or Not Applicable status, the shared-responsibility boundary, and which evidence is safe to disclose.



## How AICM Fits with Other AI Frameworks



AICM turns broad governance outcomes into a detailed, auditable control set. Its mappings help you reuse work across frameworks, while each source keeps its own purpose and authority.



| Framework or requirement | Relationship to AICM | Important limit |
| --- | --- | --- |
| CSA CCM v4.1 | AICM carries forward the cloud control foundation and adds AI-specific coverage. | A cloud control may need new AI-specific implementation and evidence. |
| ISO/IEC 42001 | The ISO standard defines an AI management system; AICM maps detailed security and governance objectives to it. | An AICM assessment does not grant ISO certification. |
| NIST AI RMF and AI 600-1 | NIST organizes AI risk work around Govern, Map, Measure, and Manage; AICM supplies granular controls and assessment questions. | A crosswalk does not establish that every NIST outcome is satisfied. |
| EU AI Act | AICM maps operational controls to relevant legal obligations and risk areas. | Applicability and compliance depend on the organization's legal role, system classification, and facts. |
| BSI AIC4 and AIUC-1 | The package includes mappings that support gap analysis and evidence reuse. | Mapping strength varies by requirement, so partial and full gaps still need treatment. |



Use a crosswalk to locate reusable controls and evidence. Keep a separate obligation record for legal interpretation, certification scope, contractual commitments, and gaps that the mapping does not cover.



## Common AICM Mistakes



- **Applying all 247 controls to every system.** Scope by service, role, architecture, lifecycle, and risk so owners can focus on relevant work.



- **Assigning one role to the whole company.** Record the role your organization plays for each service and component.



- **Treating policy as operating evidence.** Pair written requirements with configurations, logs, approvals, test results, and dated records.



- **Copying one response across deployment models.** A hosted application, private deployment, and customer-managed model can have different owners and evidence.



- **Using Not Applicable to hide a gap.** Use No for a relevant control that is absent or materially ineffective, then name remediation.



- **Treating a framework mapping as a compliance result.** Review the target requirement, scope, and mapping gap before reusing the evidence.



- **Leaving evidence disconnected from the answer.** Record the source, version, owner, approval, and sharing level behind every material claim.



## Turn AICM Evidence into Approved Answers



An AICM program works when implementation, evidence, and external claims stay connected. Our platform gives security and GRC teams a controlled response workflow for that last mile, from an incoming AI-CAIQ to a source-backed first draft and accountable sign-off. [Book an Arphie demo](https://www.arphie.ai/contact) to see how it fits your security questionnaire process.