Introduction: The CSA AI Controls Matrix (AICM)
The CSA AI Controls Matrix (AICM) is the Cloud Security Alliance's first vendor-agnostic control framework purpose-built for securing and governing artificial intelligence systems, with a particular emphasis on generative AI (GenAI) and large language model (LLM) workloads deployed in and around cloud environments. Released in draft in 2025 and evolving alongside CSA's flagship Cloud Controls Matrix (CCM), the AICM extends CSA's long-standing 'trust but verify' philosophy from conventional cloud services into the emerging domain of AI. It provides organisations building, deploying, operating or consuming AI with a structured, auditable set of control objectives that address the unique risk surface introduced by machine learning models, training data pipelines, model supply chains, prompts, agents and inference endpoints.
For CyberSigma's clients, the AICM matters because it is one of the very few control catalogues that speaks natively to AI security rather than retrofitting generic IT controls. It is designed to be used in tandem with the CSA STAR programme, the Consensus Assessment Initiative Questionnaire (CAIQ) and third-party attestations, meaning that organisations can move from a self-assessment posture towards independent assurance. This guide is written for two audiences at once: the auditor or assessor who must test control effectiveness and gather evidence, and the CISO, AI governance lead or ML platform owner who must design, implement and operate the controls in the first place.
Copyright and licensing note
The CSA AI Controls Matrix, the Cloud Controls Matrix and the CAIQ are copyrighted works of the Cloud Security Alliance (CSA), published under CSA's own licensing terms (typically a Creative Commons attribution-non-commercial-no-derivatives style licence for the spreadsheets). This CyberSigma guide is an original, independent interpretation written to help organisations understand and prepare for the framework. It does NOT reproduce CSA's copyrighted control text, control identifiers verbatim, or the AICM spreadsheet. Always download the authoritative AICM workbook and mapping files directly from cloudsecurityalliance.org and treat those as the single source of truth. Where this guide references domain names or counts, they are paraphrased for educational purposes and may evolve between AICM draft and final releases.
What is the CSA AICM
The AI Controls Matrix is a cybersecurity and governance control framework consisting of a structured set of control objectives, each grouped into thematic domains, and each mapped to the parties in the AI value chain that are responsible for implementing them. Structurally and philosophically it mirrors the Cloud Controls Matrix: a spreadsheet-based catalogue where every control has a unique identifier, a control specification (the objective), a domain, and a set of relationships to external standards. Where the CCM addresses cloud infrastructure and shared-responsibility security, the AICM addresses the AI-specific overlay: model development, data governance for training and fine-tuning, model supply-chain integrity, prompt and output safety, agentic behaviour, and the human oversight and transparency obligations that regulators such as the EU (under the AI Act) increasingly demand.
Three design principles distinguish the AICM:
- AI-native control objectives: Controls address threats such as training-data poisoning, model inversion and membership inference, prompt injection, insecure output handling, model theft and excessive agency, rather than only generic confidentiality-integrity-availability concerns.
- Shared responsibility across the AI value chain: Each control is tagged to the roles that must act on it, typically the AI/model provider (developer), the AI/cloud service provider (deployer or orchestrator), and the AI customer or consumer. This makes the AICM usable for procurement and vendor assurance, not just internal control.
- Interoperability by mapping: The AICM is delivered with cross-mappings to CCM v4, ISO/IEC 42001, ISO/IEC 27001, the NIST AI Risk Management Framework (AI RMF 1.0), the EU AI Act, BSI and other AI-relevant references, so that an organisation already aligned to one standard can reuse evidence.
The AICM is intended to be consumed in several ways: as an internal design checklist for AI programmes; as the basis for a supplier questionnaire (an AI-specific analogue of the CAIQ, sometimes referred to as the AI-CAIQ); as a gap-assessment tool against regulation; and, ultimately, as the control set behind a STAR-style assurance or attestation for AI services.
Who must comply / scope of applicability
The AICM is a voluntary, best-practice framework rather than a statute, so 'must comply' is a function of contractual, regulatory or assurance drivers rather than direct legal mandate. However, because it maps to the EU AI Act, ISO/IEC 42001 and the NIST AI RMF, adopting the AICM is frequently the operational route by which an organisation demonstrates compliance with those regimes. The following table summarises who should apply it and why.
| Actor / role | Why the AICM applies | Typical drivers |
|---|---|---|
| AI model developers (foundation-model and fine-tuning teams) | Own training-data governance, model integrity, evaluation and safety controls at source | EU AI Act GPAI obligations, ISO 42001 certification, customer due diligence |
| AI/cloud service providers (deployers, MLOps, platform teams) | Operate inference, orchestration, guardrails and monitoring; carry most runtime controls | STAR/AI attestation, contractual security schedules, tenant assurance |
| AI customers / consuming enterprises | Must verify supplier controls and implement their own use-side controls (prompt hygiene, DLP, human oversight) | Vendor risk management, regulatory accountability as deployer |
| Regulated enterprises using AI (BFSI, healthcare, public sector) | Sector regulators expect demonstrable AI governance and risk management | RBI/SEBI/IRDAI AI guidance, DPDP Act, HIPAA, DORA where in scope |
| Managed service providers and integrators | Deliver AI capabilities on behalf of clients; inherit shared-responsibility controls | Client audit clauses, empanelment, SOC-style reporting |
| Assessors, auditors and CERT-In empanelled firms | Use the AICM as the criteria set for AI security assessments and attestations | Independent assurance engagements, STAR audits |
- Scope trigger 1 — You build or fine-tune models: full weight on data governance, model lifecycle and supply-chain domains.
- Scope trigger 2 — You deploy or host AI for others: full weight on runtime security, guardrails, monitoring and shared-responsibility documentation.
- Scope trigger 3 — You only consume third-party AI (e.g. an LLM API): weight shifts to vendor assurance, data-handling agreements, output validation and human oversight.
- Scope trigger 4 — You operate under the EU AI Act or a sector AI mandate: the AICM becomes the practical control layer beneath the legal obligation.
Structure of the CSA AICM
The AICM organises its control objectives into a set of thematic security and governance domains. The draft AICM comprises on the order of 240+ control objectives spread across roughly 18 domains. Of these, a subset are entirely new AI-specific domains introduced by the AICM, while the remainder are inherited or adapted from the Cloud Controls Matrix v4 because cloud security is a prerequisite for AI security. The table below paraphrases the domain structure. Treat domain names and counts as indicative; consult the current AICM workbook for exact identifiers such as the two-to-four-letter domain code plus sequential number convention used across CSA matrices.
| Domain (paraphrased) | Focus | AI-specific or inherited from CCM |
|---|---|---|
| Audit & Assurance | Independent assessment, certification and evidence of AI controls | Inherited/adapted |
| Application & Interface Security | Securing AI application layers, APIs and inference interfaces | Adapted |
| Business Continuity & Operational Resilience | Availability and recovery of AI services and pipelines | Inherited |
| Change Control & Configuration Management | Managed change for models, prompts, datasets and configs | Adapted |
| Cryptography, Encryption & Key Management | Protecting model weights, embeddings and data at rest/in transit | Inherited |
| Datacentre & Physical Security | Physical protection of AI compute and storage | Inherited |
| Data Security & Privacy Lifecycle | Governance of training, fine-tuning, RAG and inference data | AI-specific emphasis |
| Governance, Risk & Compliance | AI governance structures, policy, risk and regulatory alignment | Adapted |
| Human Resources | Personnel security, AI ethics awareness and training | Inherited |
| Identity & Access Management | Access to models, datasets, endpoints and agent credentials | Adapted |
| Interoperability & Portability | Model/data portability and lock-in management | Inherited |
| Infrastructure & Virtualisation Security | Securing GPU/accelerator and virtualised AI infrastructure | Adapted |
| Logging & Monitoring | Telemetry for prompts, outputs, drift and abuse detection | AI-specific emphasis |
| Security Incident Management, E-Discovery & Cloud Forensics | AI incident response including model and data incidents | Adapted |
| Supply Chain Management, Transparency & Accountability | Model, dataset and dependency supply-chain integrity and provenance | AI-specific emphasis |
| Threat & Vulnerability Management | Model vulnerabilities, adversarial testing and red-teaming | AI-specific emphasis |
| Universal Endpoint Management | Securing endpoints and clients interacting with AI | Inherited |
| Model Security & AI Lifecycle (new AICM domains) | Model integrity, evaluation, safety, guardrails, agentic controls and explainability | AI-specific (new) |
Each control row in the workbook carries: a unique control ID (domain code plus number), the control title, the control specification (the auditable objective), the responsible party across the AI value chain (provider / deployer / consumer), and mapping columns to external frameworks. This makes each control simultaneously a design requirement, an audit criterion and a procurement question.
Master assessment checklist
This is the operational heart of the guide. For each AICM domain we give the auditor a set of things to verify and the evidence an implementer should have ready. Work through every table; do not skip a domain because it appears inherited from cloud security, because AI amplifies the consequence of each weakness. Where the AICM assigns a control to a specific value-chain role, confirm that the role has actually accepted the obligation in writing.
Audit & Assurance
| What to verify | Typical evidence |
|---|---|
| An AI audit plan exists and covers all in-scope AI systems on a defined cadence | AI audit calendar, scope register, prior audit reports |
| Independent assessment of AI controls is performed (internal audit or external) | Engagement letters, assessor credentials, STAR/AICM assessment output |
| Findings are tracked to closure with owners and dates | Remediation tracker, management responses, retest evidence |
| Assurance results are shared with relevant stakeholders and customers where contracted | Customer-facing attestation summaries, trust portal entries |
Application & Interface Security
| What to verify | Typical evidence |
|---|---|
| Inference APIs and AI application interfaces are authenticated, rate-limited and input-validated | API gateway config, WAF rules, schema validation tests |
| Output handling is validated to prevent insecure output (XSS, code execution, injection downstream) | Output-sanitisation code, security test results |
| Secure SDLC applied to AI application components | SDLC policy, code review records, SAST/DAST reports |
| Prompt/response schemas and content filters are enforced at the interface | Guardrail configuration, filter policy, test transcripts |
Business Continuity & Operational Resilience
| What to verify | Typical evidence |
|---|---|
| AI services have defined RTO/RPO and recovery procedures | BCP/DR plan for AI, RTO/RPO register |
| Model artefacts, datasets and configs are backed up and recoverable | Backup schedules, restore test logs |
| Fallback/degraded-mode behaviour is defined when the model is unavailable | Runbooks, circuit-breaker/fallback design |
| Resilience tested periodically | DR test reports, tabletop exercise notes |
Change Control & Configuration Management
| What to verify | Typical evidence |
|---|---|
| Model, prompt, dataset and hyperparameter changes follow change control | Change tickets, approvals, CAB minutes |
| Model and prompt versions are tracked with provenance | Model registry, prompt version history, lineage records |
| Configuration baselines defined for inference and training environments | Baseline configs, IaC templates, drift reports |
| Rollback capability exists for model and prompt deployments | Deployment pipeline showing rollback, rollback test evidence |
Cryptography, Encryption & Key Management
| What to verify | Typical evidence |
|---|---|
| Model weights, embeddings and training data encrypted at rest and in transit | Encryption config, TLS settings, storage policies |
| Keys managed via KMS/HSM with rotation and separation of duties | KMS policy, rotation logs, access reviews |
| Sensitive prompts/outputs protected where they contain regulated data | DLP/encryption controls on prompt logs |
| Cryptographic standards align to approved algorithms | Crypto standard document, cipher inventory |
Datacentre & Physical Security
| What to verify | Typical evidence |
|---|---|
| GPU/accelerator compute hosted in physically secured facilities | Datacentre certifications (SOC 2, ISO 27001), access logs |
| Physical access to AI infrastructure restricted and logged | Badge logs, CCTV policy, visitor records |
| Secure disposal of media containing model/training data | Media sanitisation records, destruction certificates |
| Environmental controls protect availability of AI compute | Facility SLAs, power/cooling redundancy evidence |
Data Security & Privacy Lifecycle
| What to verify | Typical evidence |
|---|---|
| Training/fine-tuning/RAG data sources are inventoried with lawful basis and consent where personal data is used | Data inventory, DPIA, consent/lawful-basis records |
| Data classification and handling applied across the AI data lifecycle | Classification policy, tagging in data pipeline |
| Data minimisation and de-identification applied before training | Anonymisation/pseudonymisation records, minimisation review |
| Data retention and deletion (including right-to-erasure impact on models) defined | Retention schedule, deletion/unlearning procedure |
| Prompt and output data containing PII is protected and its retention governed | Prompt-log retention policy, PII redaction evidence |
| Cross-border data transfer controls applied to training and inference data | Transfer impact assessments, SCCs/DPAs |
Governance, Risk & Compliance
| What to verify | Typical evidence |
|---|---|
| An AI governance body/committee with defined authority exists | Governance charter, committee minutes, RACI |
| AI policy set covers acceptable use, ethics, risk and compliance | AI policy suite, sign-off records |
| AI risk assessments performed per use case and maintained | AI risk register, risk assessment templates |
| Regulatory obligations (EU AI Act, DPDP, sector rules) mapped to controls | Compliance mapping, legal register |
| Risk acceptance and exception process is documented | Exception log, risk-acceptance sign-offs |
Human Resources
| What to verify | Typical evidence |
|---|---|
| Personnel handling AI systems are screened appropriately | Background-check records (as permitted by law) |
| AI security, ethics and responsible-use training delivered | Training records, completion rates, curriculum |
| Roles and responsibilities for AI defined in job descriptions | JDs, RACI, onboarding checklists |
| Joiner-mover-leaver process revokes AI system access | Access-revocation logs, leaver checklists |
Identity & Access Management
| What to verify | Typical evidence |
|---|---|
| Least-privilege access to models, datasets and inference endpoints | Access matrices, entitlement reviews |
| Strong authentication (MFA) for administrative and pipeline access | MFA policy, IdP configuration |
| Agent and service-account credentials are scoped, rotated and monitored | Secrets inventory, rotation logs, agent scope config |
| Periodic access recertification performed | Recertification campaign records |
Interoperability & Portability
| What to verify | Typical evidence |
|---|---|
| Model and data export/portability options are documented | Export procedures, supported formats |
| Lock-in risks assessed for third-party AI dependencies | Vendor exit strategy, dependency assessment |
| Standard interfaces/formats used where feasible | Architecture docs, format standards |
| Contractual exit and data-return terms in place with AI vendors | Exit clauses in contracts, data-return SLAs |
Infrastructure & Virtualisation Security
| What to verify | Typical evidence |
|---|---|
| GPU/accelerator and virtualised AI infrastructure hardened | Hardening baselines, CIS benchmark results |
| Tenant/workload isolation for multi-tenant AI platforms | Isolation architecture, penetration test results |
| Vulnerability and patch management for AI infrastructure | Patch reports, vulnerability scans |
| Network segmentation isolates training, inference and data zones | Network diagrams, firewall rules |
Logging & Monitoring
| What to verify | Typical evidence |
|---|---|
| Prompts, outputs, and model interactions are logged with appropriate privacy controls | Logging design, sample logs, privacy review |
| Model drift, data drift and performance degradation are monitored | Drift dashboards, alert thresholds |
| Abuse, prompt-injection and anomalous usage are detected and alerted | Detection rules, SIEM/alerts, abuse reports |
| Logs are protected, time-synchronised and retained per policy | Log integrity controls, retention config |
Security Incident Management, E-Discovery & Cloud Forensics
| What to verify | Typical evidence |
|---|---|
| AI-specific incident scenarios (data poisoning, model theft, jailbreak, harmful output) are in the IR plan | IR playbooks covering AI, scenario library |
| Incident detection, triage and escalation defined with timelines | IR procedure, severity matrix, escalation tree |
| Forensic readiness to preserve model, prompt and dataset evidence | Evidence-handling procedure, forensic tooling |
| Post-incident review feeds back into controls and models | Lessons-learned records, corrective actions |
Supply Chain Management, Transparency & Accountability
| What to verify | Typical evidence |
|---|---|
| Foundation models, datasets and ML libraries are inventoried with provenance | AI-BOM/model cards, dataset datasheets, SBOM |
| Third-party model and data suppliers are risk-assessed | Vendor assessments, AI-CAIQ responses |
| Model and dependency integrity is verified (signing, checksums) | Signature verification, hash records |
| Transparency artefacts (model cards, intended use, limitations) are maintained | Model cards, system cards, usage disclosures |
| Contracts assign accountability across the AI value chain | Contractual responsibility matrices, DPAs |
Threat & Vulnerability Management
| What to verify | Typical evidence |
|---|---|
| AI threat modelling performed (covering OWASP LLM Top 10, MITRE ATLAS) | Threat models, ATLAS mapping |
| Adversarial testing and red-teaming of models conducted | Red-team reports, jailbreak/injection test results |
| Vulnerabilities in models, prompts and pipelines tracked and remediated | Vulnerability register, remediation SLAs |
| Guardrails validated against known attack techniques | Guardrail test coverage, bypass test results |
Universal Endpoint Management
| What to verify | Typical evidence |
|---|---|
| Endpoints and clients interacting with AI services are managed and secured | MDM/EDR coverage reports |
| Data leakage from endpoints into AI tools is controlled | DLP policy for AI tools, browser controls |
| Sanctioned vs shadow-AI usage is identified and governed | Shadow-AI discovery reports, allow/deny lists |
| Endpoint configuration baselines enforced | Compliance reports from endpoint management |
Model Security & AI Lifecycle (new AICM domains)
| What to verify | Typical evidence |
|---|---|
| Model integrity protected against poisoning and tampering across the lifecycle | Data validation pipelines, integrity checks, provenance |
| Model evaluation covers accuracy, robustness, bias/fairness and safety before release | Eval reports, benchmark results, bias assessments |
| Guardrails enforce content safety, prompt-injection resistance and output constraints | Guardrail policy and test evidence |
| Agentic AI has bounded permissions, tool allow-lists and human-in-the-loop where warranted | Agent permission config, HITL design, tool restrictions |
| Explainability/interpretability provided appropriate to risk and required disclosures | Explainability documentation, user-facing notices |
| Human oversight and override mechanisms exist for high-risk AI decisions | Oversight procedure, override logs, escalation records |
| Model decommissioning and secure retirement handled | Decommissioning procedure, weight-deletion evidence |
Scoping and materiality / tiering
Not every AICM control applies with equal weight to every organisation or AI system. Scoping is driven by three variables: the organisation's role in the AI value chain, the risk classification of each AI use case, and the sensitivity of the data involved. CyberSigma recommends a use-case-level scoping approach so that controls are proportionate.
| Scoping dimension | How it shapes the control set | Practical guidance |
|---|---|---|
| Value-chain role | Providers own lifecycle/data controls; deployers own runtime; consumers own use-side controls | Filter AICM by the responsible-party column and accept only your controls contractually |
| Use-case risk tier | High-risk use cases (per EU AI Act Annex III style) attract the full control set incl. human oversight and conformity-style evidence | Classify each use case; apply enhanced controls to high-risk |
| Data sensitivity | Personal, sensitive personal, or regulated data raises data-lifecycle and privacy controls | Trigger DPIA and stronger data controls where PII/SPDI present |
| Autonomy/agency | Autonomous agents with tool access raise access, guardrail and oversight controls | Constrain agent scope; require HITL above a materiality threshold |
| Exposure | Internet-facing or customer-facing AI raises app/interface and monitoring controls | Prioritise perimeter, abuse detection and rate limiting |
Materiality thresholds should be pre-agreed: for example, any AI system that can take an irreversible action, that affects a person's legal or financial standing, or that processes sensitive personal data at scale is deemed material and receives the full high-risk control set regardless of other factors.
Implementation approach
CyberSigma recommends a five-phase implementation aligned to how AI systems are actually built and operated. Each phase produces concrete deliverables that later serve as audit evidence.
Phase 1 — Discover and govern
- Activities: inventory all AI systems, models, datasets and third-party AI services (including shadow AI); establish the AI governance committee; define AI policy and acceptable-use; classify use cases by risk tier.
- Deliverables: AI system register/AI-BOM, governance charter, AI policy suite, use-case risk classification.
Phase 2 — Assess and gap-analyse
- Activities: map current controls against the AICM domain by domain; complete an AI-CAIQ-style self-assessment; run threat modelling (OWASP LLM Top 10, MITRE ATLAS); produce a prioritised gap and risk register.
- Deliverables: AICM gap assessment, AI risk register, remediation roadmap with owners and dates.
Phase 3 — Design and build controls
- Activities: implement data-lifecycle governance, model registry and provenance, guardrails, IAM for models and agents, encryption of weights and data, logging/monitoring for prompts and drift.
- Deliverables: control design documents, deployed guardrails, model registry, monitoring dashboards, updated pipelines.
Phase 4 — Validate and red-team
- Activities: pre-release model evaluation (accuracy, robustness, bias, safety); adversarial testing and red-teaming; guardrail bypass testing; DR and incident tabletop exercises.
- Deliverables: evaluation reports, red-team findings and fixes, validated guardrails, tested IR playbooks.
Phase 5 — Operate, monitor and assure
- Activities: continuous monitoring of drift/abuse; periodic access recertification; ongoing supplier assurance; internal audit against the AICM; pursue STAR-style attestation where required.
- Deliverables: monitoring KPIs, audit reports, attestation/trust-portal artefacts, continuous-improvement backlog.
Maturity / capability model
CSA matrices are increasingly paired with a capability maturity view. The AICM can be assessed against a five-level maturity model so that an organisation can express not only whether a control exists but how reliably it is performed. The table below sets out a practical maturity scale CyberSigma applies during assessments.
| Level | Name | Characteristics | Typical evidence maturity |
|---|---|---|---|
| 1 | Initial / ad hoc | AI controls informal, undocumented, person-dependent | Few or no records; verbal assurance only |
| 2 | Repeatable | Basic AI policies and some controls in key areas, inconsistently applied | Some policies and tickets; gaps in coverage |
| 3 | Defined | AICM-aligned controls documented and applied across all in-scope AI systems | Complete policy set, standard procedures, consistent records |
| 4 | Managed / measured | Controls measured with KPIs; drift, abuse and coverage tracked and reviewed | Metrics dashboards, management review records, trend data |
| 5 | Optimising | Controls continuously improved; red-teaming and eval feed back; automated enforcement | Automation evidence, continuous-improvement log, external attestation |
Most organisations beginning their AI governance journey sit between Level 1 and Level 2. A realistic 12-month target for a regulated enterprise is Level 3 (Defined) across all domains, with Level 4 on the highest-risk use cases.
Assessment and audit approach
- Define scope: agree the AI systems, value-chain role and use-case risk tiers to be assessed, and the AICM domains in scope for each.
- Plan and request evidence: issue the evidence request list, schedule interviews with AI, data, security and legal stakeholders.
- Understand the environment: walk through AI architecture, data flows, model lifecycle and third-party dependencies.
- Test control design: assess whether each in-scope AICM control is appropriately designed for the risk.
- Test control operating effectiveness: sample evidence over the review period (changes, evals, incidents, access reviews) to confirm controls operate as intended.
- Perform technical validation: review guardrail tests, red-team results and monitoring efficacy; conduct targeted testing where warranted.
- Rate maturity: assign a maturity level per domain and identify gaps against the target.
- Report and remediate: document findings, risk-rate them, agree remediation owners and dates, and retest closed items.
- Support assurance: package results towards STAR-style attestation or customer trust reporting where required.
Evidence request list
- Governance: AI governance charter, committee minutes, AI policy suite, acceptable-use policy, RACI.
- Inventory and supply chain: AI system register, AI-BOM/SBOM, model cards, dataset datasheets, vendor assessments and AI-CAIQ responses, contracts and DPAs.
- Data lifecycle: data inventories, DPIAs, lawful-basis/consent records, classification policy, retention and deletion procedures, cross-border transfer assessments.
- Model lifecycle: model registry and version history, provenance/lineage records, evaluation and bias reports, decommissioning records.
- Security controls: IAM matrices and access reviews, MFA policy, secrets/agent-credential inventory, encryption and KMS configuration, hardening baselines.
- Runtime and monitoring: guardrail configuration and test evidence, logging design and samples, drift/abuse dashboards, alert rules.
- Testing: threat models, red-team and adversarial-testing reports, guardrail bypass tests, penetration tests.
- Resilience and incident: BCP/DR plans and test results, AI incident playbooks, incident logs, post-incident reviews.
- Assurance: prior audit reports, remediation trackers, attestation artefacts, training records.
Roles and responsibilities
| Role | AICM responsibilities |
|---|---|
| Board / executive sponsor | Approve AI risk appetite, fund the programme, own accountability for AI outcomes |
| AI governance committee | Set policy, classify use cases, approve high-risk deployments, review risk |
| CISO / security team | Own security controls: IAM, crypto, monitoring, incident response, red-teaming |
| AI/ML platform and MLOps team | Implement model registry, pipelines, guardrails, deployment and rollback controls |
| Data governance / DPO | Own data-lifecycle, privacy, DPIAs, lawful basis and cross-border controls |
| Model developers / data scientists | Ensure model integrity, evaluation, bias testing and documentation (model cards) |
| Legal & compliance | Map regulatory obligations, manage contracts and accountability across the value chain |
| Internal audit / assurance | Independently assess AICM controls and report to the board |
| Business/use-case owners | Define intended use, ensure human oversight, accept residual risk for their use case |
KPIs / metrics to track
- Percentage of AI systems inventoried and classified by risk tier
- AICM control coverage: percentage of in-scope controls implemented at Level 3 or above
- Percentage of models with completed evaluation and bias/safety testing before release
- Number and severity of red-team/adversarial findings and their remediation time
- Guardrail effectiveness: prompt-injection/jailbreak block rate in testing
- Mean time to detect and respond to AI-specific incidents
- Model and data drift alerts raised versus resolved within SLA
- Percentage of AI suppliers with completed risk assessments and current AI-CAIQ responses
- Access recertification completion rate for AI systems and agent credentials
- Percentage of high-risk use cases with documented human oversight and override mechanisms
- Shadow-AI discovery and remediation rate
- Training completion rate for AI responsible-use and security awareness
Readiness checklist
- AI governance committee established with a charter and defined authority
- Complete inventory of AI systems, models, datasets and third-party AI services (including shadow AI)
- Every AI use case classified by risk tier with high-risk cases flagged
- AI policy suite (governance, acceptable use, ethics, risk) approved and communicated
- AICM gap assessment completed with a prioritised remediation roadmap
- Data-lifecycle governance in place: inventory, lawful basis, classification, retention, deletion
- Model registry with versioning and provenance operational
- Guardrails deployed and validated against prompt injection and unsafe output
- IAM enforced with least privilege and MFA for models, endpoints and agent credentials
- Weights, embeddings and sensitive data encrypted with managed keys
- Logging and monitoring for prompts, outputs, drift and abuse operational
- Threat modelling and red-teaming performed on high-risk models
- AI-specific incident playbooks written and tested
- Model evaluation (accuracy, robustness, bias, safety) required before release
- Human oversight and override defined for high-risk AI decisions
- Supplier assurance (AI-CAIQ, contracts, model cards) collected and reviewed
- Internal audit against the AICM scheduled and completed at least annually
Common gaps and findings
- No central AI inventory — shadow AI and unsanctioned LLM tools proliferate unmonitored.
- Data provenance for training and fine-tuning is unknown, creating copyright, privacy and poisoning exposure.
- Guardrails deployed but never adversarially tested, giving false confidence against prompt injection.
- Agentic AI granted broad tool and credential access without scope limits or human-in-the-loop.
- Model evaluation focuses only on accuracy, omitting bias, robustness and safety testing.
- Prompt and output logs contain PII with no retention limits or access controls.
- Third-party model suppliers accepted without any AI-specific security assessment or model cards.
- Incident response plans do not contemplate data poisoning, model theft or harmful-output scenarios.
- No documented human oversight for AI that affects individuals' legal or financial standing.
- Responsibilities across the AI value chain are ambiguous, leaving controls unowned between provider, deployer and consumer.
- No maturity measurement — controls exist on paper but operating effectiveness is unproven.
- Right-to-erasure and data-deletion obligations ignore the fact that data is embedded in trained models.
CSA AICM mapped to other frameworks
A principal strength of the AICM is that it ships with cross-mappings, allowing organisations to reuse existing evidence. The table below summarises the key relationships. Always use the authoritative mapping columns in the AICM workbook for precise control-to-control correspondence.
| Framework | Relationship to AICM | How to leverage |
|---|---|---|
| CSA CCM v4 | AICM inherits and adapts many cloud-security domains from the CCM | Reuse existing CCM/CAIQ evidence for inherited domains; add AI-specific controls |
| ISO/IEC 42001 (AI management system) | AICM controls operationalise an AIMS; strong conceptual alignment | Use AICM as the control layer beneath a 42001 certification programme |
| ISO/IEC 27001 / 27002 | Underpins the security controls the AICM builds upon | Map inherited security controls to existing ISMS to avoid duplication |
| NIST AI RMF 1.0 | AICM controls support the Govern-Map-Measure-Manage functions | Cross-reference AICM domains to AI RMF outcomes for US-facing assurance |
| EU AI Act | AICM controls provide practical implementation for high-risk and GPAI obligations | Use AICM to evidence risk management, data governance, transparency and human oversight |
| OWASP Top 10 for LLM Applications | Informs threat-and-vulnerability and model-security domains | Map guardrail and testing controls to specific LLM risks (e.g. prompt injection) |
| MITRE ATLAS | Adversarial technique reference for AI threat modelling | Use ATLAS to drive red-teaming that evidences AICM threat controls |
| NIST SP 800-53 / SP 800-161 | Security and supply-chain control baselines | Map infrastructure and supply-chain controls to federal baselines where relevant |
| India DPDP Act 2023 | Data-lifecycle and privacy controls support DPDP obligations | Use AICM data controls to evidence consent, purpose limitation and erasure handling |
How CyberSigma helps
CyberSigma is a CERT-In empanelled and PCI QSA firm with dedicated AI security and governance practice. We help organisations operationalise the CSA AICM end to end: discovering and classifying your AI estate, running an AICM gap assessment mapped to the EU AI Act, ISO/IEC 42001 and the NIST AI RMF, designing and deploying guardrails, model registries and monitoring, and red-teaming your models against OWASP LLM Top 10 and MITRE ATLAS techniques. We prepare you for STAR-style AI assurance and independent attestation, and provide continuous monitoring so your AI controls stay effective as your models and regulations evolve. Engage CyberSigma to move from ad hoc AI adoption to auditable, defensible AI governance.
Frequently asked questions
How does AICM relate to the CSA CCM?
AICM extends the CSA Cloud Controls Matrix methodology to AI systems, adding AI-specific control objectives while preserving CSA mapping conventions.
Official documents
CyberSigma resources
Need help with CSA AICM?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.