Vaikora › Blog › Frameworks & Standards

CSA AI Controls Matrix: Vendor Assessment Framework

Frameworks & Standards · June 30, 2026 · 14 min read

The Cloud Security Alliance AI Controls Matrix (AICM) is a framework for evaluating AI security across governance, data protection, model safety, and monitoring. It standardizes vendor assessment questions so organizations can compare AI offerings against a common baseline.

What is the CSA AI Controls Matrix?

The CSA AI Controls Matrix is the Cloud Security Alliance's answer to a market problem: every vendor has a different security questionnaire, every buyer asks the same questions in ten different ways, and no one agrees on how to measure AI safety. The AICM standardizes this conversation.

The framework organizes AI security into control domains, each containing related control objectives. These domains span governance and risk management (defining who decides what the AI can do), data security (protecting training and inference data), model security (safeguarding the model itself), and operational transparency (recording what happened and why). Each control objective includes implementation guidance and vendor-assessment criteria so you know what to look for when evaluating a tool or platform.

The AICM is not a compliance checklist or a pass-fail score. It is a conversation starter. It lets you ask vendors what they do in each domain, compare their answers side by side, and understand where your risk appetite matches their capabilities. It also serves as a reference for building your own internal AI security policy.

Why Vendor Assessment Matters in AI Security

AI vendors span a huge range of maturity and risk profile. A small startup offering a fine-tuning API has a different surface area than a large platform providing managed agents, RAG pipelines, and model routing. A vendor storing your proprietary data for training has different obligations than one using only ephemeral inference containers.

Vendor assessment lets you decide what trade-offs you can live with. Can you accept a vendor that logs all prompts to their servers, or does your data governance require inference to stay on-premises? Does the vendor use the model for training data, or can you negotiate a data-processing agreement that excludes your workloads? Can they sign an attestation that their model was red-teamed, or do you need a full security audit? These are risk decisions, not yes-or-no questions, and the AICM gives you the vocabulary to make them clearly.

AICM Control Domains and What They Address

The CSA organizes AI security into several control domains, each with concrete objectives. While the exact taxonomy evolves, the core domains typically include:

Governance and Risk Management

This domain covers who is accountable for AI decisions, how risk is measured, and what policies govern system behavior. Control objectives address model governance (approving which models are deployed and why), risk assessment (identifying where AI introduces novel risks), and incident response (what to do when an AI system behaves unexpectedly).

When evaluating vendors, ask about their governance model. Do they provide audit trails of who deployed what model and when? Can you define policies for what the model is allowed to do, and do they enforce those policies at runtime? Do they have a process for validating that a model meets your risk tolerance before it goes live?

Data Security and Privacy

This domain focuses on protecting data used to train, fine-tune, and operate AI models. Control objectives cover data classification (knowing what data is sensitive), access controls (limiting who can view or extract data), and data retention (deleting training data after a set period).

Key vendor questions: Where does training data live? Can they certify that your data is not used to train their model or other customers' models? Do they encrypt data in transit and at rest? Can you request deletion of your data, and do they have a process to verify it is actually gone? Can they sign a data-processing agreement compliant with GDPR or your region's privacy law?

Model and Algorithm Security

This domain protects the model itself from poisoning (injecting malicious training data), extraction (stealing the model weights), and adversarial inputs (crafted prompts designed to break the model's guardrails). Control objectives include model provenance (documenting where the model came from), red-teaming (testing it for vulnerabilities), and prompt injection detection (filtering inputs for jailbreak attempts).

Ask vendors: Can they provide a model card documenting training data, fine-tuning steps, and known limitations? Have they performed adversarial testing? Do they monitor for or block prompt injection attacks? If they host multiple models, do they isolate inference workloads so one customer's malicious prompt does not affect another's? Can they revert to a previous model version if a security issue is discovered?

Operational Resilience and Monitoring

This domain ensures AI systems keep working when things go wrong and that you can see what is happening. Control objectives cover logging (recording every decision and why), monitoring (detecting anomalies in real time), and disaster recovery (restoring service after an outage).

Vendor questions: What is logged and for how long? Can you export logs in a standard format, or are you locked into their dashboard? Do they alert you when error rates spike or usage patterns change? How quickly can they restore service after an outage? Do they have a published SLA, and what is the penalty if they miss it? Can you query logs to understand why a specific decision was made?

Audit, Compliance, and Transparency

This domain creates accountability through independent verification and disclosure. Control objectives include audit readiness (preparing for external audits), vulnerability disclosure (reporting security issues you find), and transparency (publishing security practices and certifications).

Ask vendors: Can they provide a security audit report or SOC 2 attestation? Do they participate in responsible-disclosure programs? Do they publish a security policy and incident-response timeline? If a vulnerability is discovered, how do they notify customers and provide a fix? Can they participate in your internal audit or compliance review?

How to Use AICM for Vendor Assessment

Building a vendor questionnaire using the AICM is a four-step process: map your risk priorities to control domains, translate control objectives into questions, compare vendor responses, and make a risk decision.

Step 1: Define Your Risk Profile

Start by identifying which control domains matter most to your organization. A fintech firm handling payment data cares deeply about data security and compliance, so they weight those domains heavily. A research lab fine-tuning models for internal use cares less about data exfiltration (since the data is not proprietary) but more about model provenance and operational monitoring.

Write down your priorities. Example: "We need strong governance (high priority), encryption at rest (high priority), model audit trails (medium priority), and 99.9% uptime (medium priority)." This becomes your assessment rubric.

Step 2: Create Control-Driven Questions

For each high-priority domain, write specific questions grounded in control objectives. Do not ask "Is your platform secure?" instead, ask "Describe your logging and retention policy for inference queries, and can you filter logs by user, model, or date range?"

The AICM gives you sample control objectives to start from. Example from governance: "The organization has defined and documented acceptable uses for deployed AI models." Your question: "Show us your model governance documentation. How do you define acceptable use for each deployed model, and how is that policy enforced?"

Keep questions open-ended so vendors describe their approach in detail, then you assess whether it meets your requirements.

Step 3: Collect and Normalize Responses

Distribute your questionnaire to vendors. Expect varying levels of detail. A mature vendor will give you a precise, documented answer. A startup might say "We are building that feature" or "We use vendor X, who handles it." Both are useful signals.

Create a comparison table. Example:

This table makes trade-offs visible so decision-makers can choose, not just IT compliance teams.

Step 4: Assess Risk and Negotiate

For each gap, decide whether it is a blocker or a negotiable risk. If Vendor B does not offer 30-day data retention, can they sign a data-processing agreement promising deletion on request? If Vendor C does not have a published model card yet, can they commit to providing one by a certain date, or is that a deal-breaker?

Document your decision. Example: "We chose Vendor A because they offer automated data deletion and full audit logging. We accepted a 6-month log retention limit as a trade-off for their lower cost, and we added quarterly audit reviews to our contract to monitor compliance."

Aligning AICM with Other Frameworks

The CSA AI Controls Matrix is one of several AI security frameworks in wide use. Understanding how AICM relates to others helps you harmonize assessments across multiple vendors or internal policies.

AICM and NIST AI RMF

The NIST AI Risk Management Framework (AI RMF) provides a structured process for building organizational AI risk practices around four core functions: Govern, Map, Measure, and Manage. NIST focuses on your internal practices, while AICM focuses on vendor capabilities. Both are complementary. You use NIST AI RMF to build your internal AI governance process, then use AICM to evaluate vendors who help you execute that process.

Example: NIST AI RMF tells you to "map AI systems to organizational risk levels." AICM tells you to ask vendors "Can you isolate customer workloads, and do you enforce role-based access controls?" Both address the same risk but at different levels.

AICM and OWASP LLM Top 10

OWASP's LLM Top 10 is a prioritized list of the ten most critical security risks in large language model applications (prompt injection, data leakage, insecure output handling, etc.). It is a threat model, not a control framework. AICM incorporates LLM Top 10 risks into the model and algorithm security domain. When you create a question around "prompt injection detection," you are operationalizing OWASP guidance through AICM structure.

AICM and ISO 42001

ISO 42001 is an international standard for AI management systems, published in December 2023, covering design, deployment, monitoring, and incident management. It is broader than AICM and includes internal organizational practices, not just vendor evaluation. If you are pursuing ISO 42001 certification, use AICM to assess vendors you depend on, then use ISO 42001 to audit your own processes.

Common Assessment Challenges and How to Handle Them

Vendors Cannot or Will Not Answer Certain Questions

Some vendors, especially startups, have not built certain capabilities yet. They might say "We are in beta and only log errors, not full inference traces." This is useful information. Decide if you can work with a vendor that is still building, or if you need mature features now.

For sensitive questions around data handling or security audits, some vendors claim confidentiality. Negotiate. Offer to sign an NDA so they can share details with your security team but not your purchasing team.

Your Questions Are Too Specific for the Vendor's Product

A vendor offering a managed fine-tuning API might not have a multi-tenant isolation story because they do not run inference workloads. Adjust your questions to their use case. Instead of "How do you isolate customer inference?", ask "Can we run inference on our own infrastructure using our fine-tuned model?" Different question, same risk decision.

Vendors Claim Compliance with a Standard but Cannot Prove It

If a vendor says "We are SOC 2 compliant" but can not produce a SOC 2 Type II report, that is a red flag. Ask for evidence. Get a copy of their audit report, or at least their audit scope and the auditor's name. Verify with the auditor's firm if necessary. A vendor that will not prove compliance claims is hiding something.

Building Your Internal AI Security Policy with AICM

Beyond vendor assessment, use AICM to build your internal AI security policy. If you are deploying AI models internally or running a platform for your data scientists, AICM gives you a checklist of control domains to implement.

Example internal policy structure:

• Governance: Designate an AI Risk Owner. Require approval for every model deployment. Document acceptable uses. Test models against acceptance criteria before production.
• Data Security: Classify data as public, internal, or confidential. Encrypt inference data in transit and at rest. Delete training data after model retirement.
• Model Security: Document model provenance. Red-team models before deployment. Monitor for prompt injection and adversarial inputs.
• Monitoring: Log all inference requests. Alert on error-rate spikes. Review logs quarterly.
• Audit: Perform internal audits annually. Make logs available for external audits. Respond to security issues within 30 days.

The AICM control objectives give you the specificity to turn policy into practice.

Runtime Policy Enforcement and Audit

One challenge AICM frameworks address is the gap between policy on paper and policy in action. A vendor might promise "role-based access controls," but does that actually prevent an unauthorized user from accessing the model in production?

This is where runtime enforcement comes in. Systems that intercept every AI action, evaluate it against a policy, and block or allow it in real time provide the audit trail that AICM control objectives require. Runtime guards can sit between applications and language models, evaluating every proposed action against customer policies before execution, logging the decision to an audit chain, and alerting on policy violations. This closes the gap between "we have a governance policy" and "every single action is logged and verified."

Frequently asked questions

What is the CSA AI Controls Matrix?

The CSA AI Controls Matrix is a structured framework by the Cloud Security Alliance for evaluating AI security across governance, data protection, model safety, operational resilience, and audit domains. It provides control objectives and assessment guidance so organizations can standardize how they evaluate AI vendors and build internal AI security policies. It is vendor-agnostic and freely available.

How do you use AICM for vendor assessment?

Create a vendor questionnaire mapping control objectives to specific questions. Distribute it to vendors, normalize their responses in a comparison table, and assess trade-offs. For each gap or weak answer, decide if it is a blocker or a negotiable risk. Document your decision and add terms to your contract to address remaining risks.

What does the CSA AI security framework cover?

The CSA's AI security work spans governance (defining who can deploy what AI and why), data security (protecting training and inference data), model security (safeguarding the model from poisoning, extraction, and adversarial inputs), operational resilience and monitoring (logging and alerting on anomalies), and audit and compliance (preparing for external verification and transparency). The AICM organizes these into structured control domains.

How does CSA AICM compare to NIST AI RMF?

NIST AI RMF is a process framework for building your organization's internal AI risk practices around four core functions: Govern, Map, Measure, and Manage. AICM is a control framework for evaluating vendors. Both are complementary. Use NIST to design your internal practices, then use AICM to assess vendors who help you execute those practices. Both address similar risks but at different levels of abstraction.

Should we assess all control domains or focus on high-priority ones?

Focus first on the domains your organization cares about most. A healthcare firm handling patient data prioritizes data security and compliance. A research lab fine-tuning internal models prioritizes model provenance and operational monitoring. Define your risk profile, weight the domains accordingly, and build your questionnaire around high-priority areas. You can assess lower-priority domains in a second phase or negotiation round.

Can vendors refuse to answer AICM questions?

Vendors can decline, but that is useful information. If a vendor will not discuss data handling or security practices, that is a risk signal. For sensitive topics, offer to sign an NDA. For capabilities they have not built yet, decide if you can work with a vendor that is still maturing. Document your decision so stakeholders understand the trade-offs.

How do we know if a vendor's AICM answers are truthful?

Ask for evidence: audit reports, security attestations, model cards, code samples, or references from other customers. For critical claims (e.g., "We encrypt data at rest"), require third-party verification such as a SOC 2 audit. For ongoing verification, add audit clauses to your contract and perform annual reviews.

Is AICM only for large enterprises?

No. AICM scales from startups assessing a single AI vendor to enterprises evaluating dozens. A small team can focus on the 3 to 5 control domains that matter most and ask 20 to 30 key questions. A large enterprise might assess 15 to 20 objectives across multiple vendors. The framework adapts to your context.

How does AICM relate to AI safety standards like ISO 42001?

ISO 42001 is an international standard for AI management systems, published in December 2023, covering governance, design, deployment, and monitoring across your entire organization. AICM is a vendor-assessment framework. If pursuing ISO 42001 certification, use AICM to audit vendors you depend on, then use ISO 42001 to audit your own internal processes.

Can AICM help with regulatory compliance like GDPR or the EU AI Act?

Yes. AICM control domains around data security and audit trails support GDPR compliance (e.g., data classification, deletion rights, audit logs). The EU AI Act establishes obligations for high-risk AI systems around governance, data quality, and documentation, which align with AICM's governance, data security, and monitoring domains. Map relevant regulatory requirements to control objectives, then assess vendors against those objectives.

How often should we re-assess vendors using AICM?

Reassess annually or when a vendor makes significant changes to their platform or security practices. If a vendor experiences a security incident or misses contractual commitments, trigger an emergency reassessment. For ongoing monitoring, add audit clauses to contracts requiring quarterly or annual security reviews.

More from the Vaikora blog