Two Frameworks in Your Hands: SANS or CSA AI Security Maturity Model

Both published in 2026. Both named "AISMM." Both want to help you secure AI. They're solving different problems, and picking the wrong one will cost you.

Someone on the board read a Bloomberg article about AI data breaches and now wants to know, where the company stands on AI security. Marketing shipped Copilot to 800 employees last quarter. Engineering is building an LLM-powered feature that touches customer data. And somewhere in IT, someone approved an "AI agent" that has access to the Salesforce instance, you found out when it started emailing customers. You have two weeks to come back with an answer. This is the moment both frameworks were designed for.

What Even Is a Maturity Model? Before we compare them, let's be honest about what a maturity model actually does, because a lot of people misuse them. A maturity model doesn't tell you every control you need. It tells you where you are, where you realistically need to be, and critically in what order to get there. The order matters more than most teams realize. Skipping steps doesn't make you faster; it means you're building defenses on top of an incomplete foundation. "Improve our AI security" is a direction. "We're at Stage 2 in Governance, Stage 1 in testing, and here's a 90-day plan to reach Stage 3 in both" is a program. Both SANS and CSA give you that structure. What they disagree on is what belongs inside it.

Meet the Two Frameworks The SANS AI Security Maturity Model comes from Chris Cochran, Field CISO at SANS Institute, and co-author of the EU AI Act's harmonized cybersecurity standard (prEN 18282). That last credential matters when you get to the regulatory alignment section. SANS published a complete, self-contained ebook. It includes the framework, a 15-question scored self-assessment, industry-specific weighting profiles, and stage-by-stage action plans. You can run a meaningful assessment with a small team in half a day. Think of it as a practitioner's field guide , built for people who need to act, not just plan. The CSA AI Security Maturity Model comes from the Cloud Security Alliance, the same organization that built the Cloud Security Maturity Model (CSMM) that many enterprise security teams already live inside. The CSA AISMM follows the same structural logic. 12 categories across 3 domains, 5 maturity levels, control objectives as measurable KPIs. It's designed to work as a layer on top of your existing program, alongside the CSA AI Controls Matrix (AICM) and the AI CAIQ vendor questionnaire. Think of it as an architecture blueprint, built for organizations doing this properly, with a GRC team and time to go deep.

The Difference Nobody Talks About Here's the thing most framework comparisons miss:

SANS and CSA are not measuring the same thing.

SANS has three pillars:

• Protect AI: defending your AI systems from attackers
• Utilize AI: how your security team uses AI to do its job better
• Govern AI: policies, risk, accountability

CSA explicitly, excludes the middle one. The document says it plainly: "It is deliberately not a measurement of how the security team itself uses AI internally". CSA is only measuring the security program that protects the business's AI usage. Whether your SOC has mature AI-powered detection, whether your. red team uses AI tools, whether your threat hunters are leveling up with generative AI, none of that is in scope for CSA.

Why does this matter to you? If you're a security engineer asking "how do we use AI to get better at defending ourselves?", SANS covers it. CSA does not. If you're a GRC analyst asking "how do we build and audit the program that governs all the AI the business is deploying?" , both frameworks apply, but CSA gives you more structural depth. If you need a clean, auditable boundary between "protecting the company's AI" and "the security team's internal AI use", CSA's explicit scope is exactly what you want. Neither choice is wrong. But picking without knowing this will leave you confused about what your assessment is actually measuring.

Inside SANS: Five Stages You Can't Skip

SANS describes a five-stage journey, and each stage has hard prerequisites. You can't claim Stage 3 if Stage 2's foundations aren't real.

Stage 1 — Unaware/Ad Hoc This is where most organizations actually are, even if they think they've moved past it. Employees freely use AI with customer data. Developers pull AI models from Hugging Face without checking their integrity. AI agents are being granted access to production systems because someone found a cool tool. The security team doesn't know what's in the environment. SANS introduces a distinction here that's more useful than it sounds:

BYOAI (Bring Your Own AI) versus Shadow AI.

BYOAI is neutral, it means employees using unapproved AI tools before any policy exists. Shadow AI means doing it in violation of an existing policy.

At Stage 1, there's no policy to violate yet. Everything is BYOAI. The reason this matters: your first instinct might be to write a policy that bans everything. SANS has a name for that instinct, the "Framework of No" and documents it as a well-worn failure mode. Block-everything policies don't stop AI use. They push it underground and make it invisible. The goal of Stage 2 is not restriction. It's visibility.

Stage 2 — Reactive/Policy-Emerging A policy exists now. It's usually blunt, "don't use AI with sensitive data" or "use with caution" but it exists. Some tools are blocked. Some are allowed without oversight. Leadership knows AI is a risk area but hasn't invested strategically. Before you can move to Stage 2, SANS has a hard prerequisite: Data classification must be in place. You cannot write a meaningful AI policy if you don't know where your sensitive data lives. If your data classification is nonexistent or incomplete, fix that first.

Stage 3 — Defined/Risk-Informed This is where intentional security starts. A formal AI Governance Council exists, with cross-functional membership and actual decision authority. Enterprise-approved AI tools replace the outright bans. AI systems appear in your asset inventory with documented owners and data classifications. Here's one of the most important Stage 3 requirements: AI agents get Non-Human Identities (NHIs). Instead of borrowing a human user's credentials (which is a disaster waiting to happen), every AI agent gets its own distinct, scoped credential with a documented human owner responsible for it. This is the AI equivalent of service accounts, except most teams aren't doing it yet. Adversarial testing begins. Prompt injection defenses go in. AI systems appear in penetration testing scope, with findings mapped to MITRE ATLAS, the AI-specific attack framework that does for AI threats what MITRE ATT&CK does for traditional ones. SANS is explicit that Stage 3 is a defensible target for most organizations. If your AI footprint is limited and you're not running critical AI systems, Stage 3 is not a compromise , it's the right goal.

Stage 4 — Managed/Integrated Stage 4 is where AI security starts requiring dedicated resources and new skills. You have a dedicated AI red team program, and SANS is careful to note that AI red teaming is not traditional pentesting. It focuses on adversarial inputs, prompt injection chains, model extraction, and behavior manipulation. Different skill set. Different tooling.

During the stages 3 and 4, you developed 4 major capability in your organization:

• Advanced AI threat hunting capability
• AI red team capability
• AI threat simulation capability
• Continuous monitoring and validated response capability

Also 2 solid services has been deployed which I believe deserve to attention:

• MLSecOps : security baked into the model training pipeline, not added after deployment. Secure training pipelines, model versioning, training data validation, runtime guardrails. If your AI systems are built by your own teams, this is the difference between security as an afterthought and security as infrastructure.
• Confused Deputy Defense : this one takes a sentence to explain. When an AI agent processes a document or external content, an attacker can embed malicious instructions in that content. The agent reads them, treats them as legitimate instructions, and uses its own real tools to act on them, against you, using its own credentials. The Confused Deputy defense isolates untrusted input from the agent's execution context so this can't happen. Stage 4 requires it.

Stage 5 — Optimizing/Adaptive Stage 5 is the frontier. Self-improving defenses. AI agents authorized for autonomous Level 1 incident remediation. Chaos engineering running continuously to test AI system resilience. The security team includes AI researchers. The organization publishes work and shapes industry standards. SANS is direct about who this is for: large technology companies, defense contractors, and AI-native firms. "For most organizations, Stage 5 is a multi-year trajectory, not a near-term target." Don't let anyone pressure you into claiming Stage 5 readiness that isn't real.

The Scoring System That Prevents Lying to Yourself (and maybe others) Every question in SANS's 15-question self-assessment scores 0 to 5. The levels are:

0. No evidence this exists

1. Someone does it sometimes, undocumented
2. Written plan or draft; partially implemented
3. Approved, documented, consistently executed
4. Metrics tracked; data drives decisions
5. Continuously improving; proactive adaptation

Here's the rule that makes this system honest: self-reported capabilities without documentary evidence cap at 2. If you say "yes, we do that" but can't show a policy document, audit log, configuration screenshot, or test result, your score is 2, not higher. This one rule eliminates most of the governance theater that plagues maturity model assessments. The final score is weighted by industry (Financial Services puts 40% weight on Protect; Healthcare puts 40% on Govern; Education puts 45% on Govern) and it should be noted that Protect and Govern are weighted higher than Utilize in the default profile because foundational failures in either Protect or Govern create cascading risk that advanced Utilize capabilities cannot offset, and then passed through two anti-gaming rules:

Governance Floor Rule: Your overall stage cannot be more than one stage above your Govern pillar. Because without governance, your technical controls are unowned, untested, and unaccountable. Minimum Pillar Rule: Your overall stage cannot be more than one stage above your weakest pillar. A critical gap in one dimension cannot be hidden by excellence in another.

These two rules are what make the SANS score mean something.

A score that can be gamed doesn't protect you , it just makes you feel better.

Inside CSA: Three Domains, Twelve Categories, and a comprehensive set of Control Objectives

CSA doesn't give you a number. It gives you something more precise: a full set of control objectives with stable IDs, assessed at the category level, with a clear 85% threshold rule. To claim a maturity level in a category, you must meet all control objectives for that level across at least 85% of your deployments. That 15% window is intentional. It gives you room for dev environments and edge cases without letting you pretend you're mature when you aren't. Control objective IDs look like IAM-04.2 or GOV-03.1, category prefix, maturity level, sequence number. These IDs are stable references you can use in audit reports, risk registers, and remediation tickets. That precision is something SANS's narrative format simply can't match. Each objective also carries deployment type (All / Self-hosted / PaaS / API/SaaS), manual vs. automated flag, AICM control mappings, and external references down to specific OWASP LLM item numbers, NIST AI RMF subcategories, and ISO/IEC 42001 clauses.

The Three Domains

The Foundational Domain is where most programs need to start, and I think where most will struggle.

• Governance (GOV) covers the AI Council, policies, decision rights, approval processes, and ethics review for high-risk use cases. It is more operational than most people expect.
• Organization Management (ORG) is where governance gets enforced technically, cloud-provider restrictions on AI services, AI-SPM (AI Security Posture Management, which automates AI asset discovery across your environment), AI-BOM (AI Bill of Materials), and blast-radius isolation so one compromised AI deployment can't take down everything.
• IAM covers human and non-human identity into AI services, MCP tool access control, and agent delegation chains. By using RFC 8693, an agent's delegated scope must remain a strict subset of the user's permissions.
• Security Monitoring (MON) covers prompt and response capture, guardrail-violation logging, agent action logs, and the SOC workflows that consume them.

The Structural Domain is where security looks most familiar, but where the underlying technology behaves differently enough that your existing playbooks don't fully transfer.

• Infrastructure Security (INF) covers compute and network for AI workloads.
• Model Security (MOD) governs the model itself , the approval registry, version pinning, integrity verification, and provenance tracking. Model registry is foundational; other categories reference it. For example it is going to mandate that floating version aliases like "latest" are prohibited in production.
• Application Security (APP) covers system prompt hardening, here you implement safeguards customized to your application requirements and responsible AI policies, input/output validation, MCP tool restrictions, and human-in-the-loop enforcement. AI Red teamers are perfoming in this domain.
• Data Security (DAT) arguably where most organizations are weakest, covers RAG and vector store access control, permission-aware retrieval (so the AI only retrieves the data that it's user is authorized to see), inference output sanitization (a critical security layer that inspects and cleans AI-generated responses in real-time before they reach the user or backend systems), and data poisoning detection.

The Procedural Domain covers the operational processes that keep AI security sustainable over time.

• Risk & Provider Assessment (RSK) handles AI provider selection, approved provider registries, and ongoing reassessment as providers change their capabilities and terms (new model, ToS shift, security incident, deprecation, ownership change).
• AI-Supported Development and Supply Chain Security (DEV) addresses AI coding assistants, the AI components in your software supply chain, and CI/CD integration. Enterprise coding assistants have training and retention opt-out enabled, content exclusions covering secret-bearing paths, and consumer-tier AI chat tools are blocked on developer endpoints that handle production code.
• Privacy, Compliance & Audit (CMP) covers regulatory compliance evidence, AI CAIQ completion, AI specific privacy impact assessments, bias and fairness audits run for high-risk AI use case, and IP/licensing tracking.
• Incident Response (IR) covers the playbooks you need for the AI-specific scenarios like model abuse, and data exfiltration through AI-generated outputs, agent compromise.

The Feature Most People Miss — The deployment types Every CSA control objective (or you can call them also KPI) is tagged with the deployment pattern it applies to:

• Self-hosted: you run the model on your own infrastructure.
• PaaS: you consume managed services.
• API/SaaS: you call APIs directly or use AI embedded in SaaS.

An organization that only uses PaaS or SaaS deployment method, enterprise has almost nothing in common, security-wise, with an organization running its own fine-tuned model on a GPU cluster. CSA lets you filter the entire framework to only the controls relevant to your deployment pattern or If you're purely API/SaaS, you skip the self-hosted infrastructure and model security controls that simply don't apply to you.

SANS treats all deployment patterns the same. That's fine when you're building a foundational program, but it creates noise for cloud-first organizations doing a detailed assessment.

Where They Diverge and Where It Matters

On scoring: SANS gives you a number with defensible anti-gaming rules. CSA gives you per-category pass/fail with an 85% deployment threshold. They serve different purposes. The CISO who needs to say "we are at Stage 3" in a board meeting picks up SANS. The security architect who needs to audit IAM-04.2 conformance across 12 production agent deployments picks up CSA.

On agentic AI: I'll be direct. After reading the full workbook, both frameworks cover agentic AI in serious depth. The difference is architectural. SANS covers it as a coherent narrative arc: Principle of Least Agency to NHI management to Confused Deputy defense to cascading failure controls to JIT authorization.

It reads as a progression. It's faster to internalize and easier to explain to a team that's new to agentic concepts.

CSA covers it with more engineering specificity, distributed across categories. IAM-03.3 specifies OAuth 2.1 with named scopes for MCP authorization. IAM-04.1 requires per-agent NHI with SPIFFE/SPIRE (CNCF-graduated projects designed to securely authenticate software systems or workloads in dynamic, modern, and heterogeneous environments) or equivalent attestation. IAM-04.2 specifies RFC 8693 token exchange for on-behalf-of flows with dual-identity delegation. IAM-05.2 validates delegation chains across multi-agent hops with scope-expansion denial. APP-04.2 requires deterministic execution boundaries enforced by OPA or Cedar policy-as-code that the agent cannot override. IR-05.1 requires automated containment for agent hijacking with an 80% true-positive rate threshold. That level of specificity is harder to synthesize on a first read, but it's what you actually need when implementing.

SANS tells you what to build. CSA tells you exactly how to build it.

On regulatory alignment: SANS maps each stage to NIST AI RMF, EU AI Act, and ISO 42001 readiness in a single table. The EU AI Act mapping carries weight because the SANS author co-wrote the harmonized standard (prEN 18282).

CSA cross-references NIST, ISO, EU AI Act, and state-level regulations (Colorado AI Act, NYC Local Law 144) at the individual control level as external references.

Both cover it; SANS makes it scannable, CSA makes it precise.

On data security depth: CSA has a significant advantage here. The cross-context denial testing for vector stores, permission-aware retrieval with ACL enforcement at the vector layer, and poisoning detection with embedding-space analysis are controls that simply don't exist at this level of specificity in SANS's Protect pillar. For organizations running production RAG systems or fine-tuning models, CSA's DAT category is essential reading.

What Neither Framework Solves

Both reference MITRE ATLAS and OWASP attack patterns, but neither walks you through threat modeling your specific AI deployment. That's work you do separately, informed by these frameworks, not replaced by them. Neither fixes organizational dysfunction. The hardest part of going from Stage 1 to Stage 3 is not technical. It's getting Legal, Engineering, Product, HR, and Security into a room with a shared mandate. A framework gives you the vocabulary for that conversation. It doesn't have the conversation for you. Neither addresses AI safety and reliability in depth, harmful bias, hallucinations, legal liability from AI decisions. SANS explicitly hands these to Legal/Risk. CSA has compliance and ethics review categories that touch the edges. But responsible AI governance is a different problem for a different framework.

The Bottom Line

Start with SANS if you're building a program from scratch, need to move fast, or need a defensible score for the board. It's complete, opinionated, and tells you exactly what to do next at every stage. The Utilize pillar, how your security team uses AI for defense, is unique to SANS. No other framework covers it. The cap rules ensure you can't paper over a real weakness with a number. Build toward CSA when implementation depth matters. The control objectives with stable IDs, SPIFFE/SPIRE for agent workload identity, RFC 8693 delegation chains, permission-aware retrieval at the vector layer, adversarial-pattern scanning in RAG content, AI-BOM per release, these are the specifications your engineers actually implement, not just the goals your governance team tracks. The 85% threshold rule makes it auditable. The deployment-type tagging makes it precise. Use both if you can. SANS gives you the scored roadmap and the practitioner playbook. CSA gives you the implementation spec and the audit instrument. They might be designed to coexist, SANS cites CSA AICM as a source, and CSA was built to sit on top of existing security frameworks, not replace them. One last thing worth saying plainly: a real Stage 2 beats a claimed Stage 4 every time. The SANS framework has a quote I'd put on the wall of any security program office:

"A 30-person company at a genuine, evidence-based Stage 2 is in a stronger security posture than an enterprise claiming Stage 3 without documentation to prove it."

I believe, that's the point of using a framework at all, specially security frameworks.