Most security leaders are now in the same position. The board wants to know what the security program is doing about AI. The business has already shipped Copilot to every employee, signed an enterprise ChatGPT contract, and approved several agent pilots — sometimes before security saw the procurement request. Application teams are wiring LLMs into customer-facing products, and someone in marketing just stood up an AI agent platform over the weekend. The question security leaders are asking isn’t should we worry about AI — it’s what do we need to change in our security program to safely adopt and secure AI across the enterprise?

That’s the question the AI Security Maturity Model (AISMM) was built to answer.

The AISMM describes the maturity journey for an enterprise security program adapting to protect AI usage. It is not a checklist of AI controls. It is not a measurement of how mature any single AI project is. And it is deliberately not a measurement of how the security team itself uses AI internally (a different and worthwhile topic, but not this one). It is a structural map for the security program — what capabilities are needed, what they look like at each level of maturity, and how to make conscious decisions about where to invest.

For those familiar with the Cloud Security Maturity Model (CSMM), the structure of the AISMM will look familiar by design. The CSMM has been in active use for years across hundreds of organizations — first as a maturity model, and increasingly as a high-level framework for organizing cloud security programs. The AISMM applies those lessons to AI security. The components that worked in the CSMM are kept (twelve categories across three domains, five CMM-aligned maturity levels, control objectives as KPIs), and the components AI security specifically needs are added (a deployment-type field for the three AI deployment patterns, direct alignment with the CSA AI Controls Matrix (AICM), and an expanded companion document for the depth a spreadsheet can’t hold).

What the AISMM Answers — and What it Doesn’t

The single most important thing to understand about this model: the AISMM is about the security program, not individual AI projects.

It answers: what does a security program need to look like to safely adopt and secure AI in the enterprise?
It does not answer: is this particular AI project secure? That’s a project-level assessment question, and the CSA has separate work for it — the AI Controls Matrix and the AI Consensus Assessment Initiative Questionnaire (AI CAIQ) — that lives in the same family as the AISMM but operates at a different layer. AISMM control objectives can be used to assess a specific deployment, and many of them will be useful that way, but that is not the design center. The design center is the program.

A few scope boundaries worth being explicit about:

The AISMM is about adapting the security program to protect enterprise AI usage. It includes some recommendations on adopting AI within the security program — because some maturity capabilities legitimately involve AI tooling (AI-SPM for asset discovery, for example) — but it is not a maturity model for how a security team itself uses or advances AI. Measuring how mature a SOC is at applying AI to detection engineering is a different model for a different day.

The AISMM covers AI security activities specifically. It is not a comprehensive enterprise security framework. The assumption is that an organization already has a security program based on something like the NIST Cybersecurity Framework, ISO/IEC 27001, or equivalent, with established capabilities in HR security, endpoint management, identity, and the rest of the standard portfolio. The AISMM is the AI lens applied on top — what changes, what gets added, and what gets retired.

The AISMM is opinionated about what is representative of each maturity level, not exhaustive about every possible control. The control objectives are KPIs chosen because they discriminate one level from another. They are not the full list of every control an organization should have. For comprehensive control coverage at the project and provider level, use the AICM.

How the AISMM Is Structured

The AISMM has the same backbone as the CSMM, with the modifications AI security needs.
Twelve categories across three domains. These cover the major areas of AI security activity an enterprise program needs to address. The category structure deliberately mirrors the CSMM where the concepts map, and differs where AI security genuinely requires its own categories (for example, Model Security has no direct CSMM counterpart).

Five maturity levels, based directly on the standard Capability Maturity Model (CMM) levels — Initial (L1), Repeatable (L2), Defined (L3), Capable (L4), and Efficient (L5). There are no Level 1 control objectives in the AISMM by design: Level 1 is the starting state where no AI-specific capabilities exist, so there is nothing to measure.

Three deployment types. This is new compared to the CSMM. AI deployments cluster into three meaningfully different patterns — Self-hosted (running the model on owned infrastructure), PaaS (consuming model APIs through cloud-provider managed services like Bedrock or Azure OpenAI), and API/SaaS (consuming model APIs directly from a provider, or an embedded AI feature in a SaaS product). Many control objectives apply across all three, but enough of them differ that the deployment type matters for assessment. Each control objective in the model is tagged with the deployment types it applies to.

AI security control objectives for each category and maturity level. These function as KPIs that indicate maturity. They are aligned with the AICM where the concepts overlap, and deliberately deviate where the model needs to (more on this in the AICM section below).

An expanded companion document — the AISMM Control Objectives Details document — that provides depth the spreadsheet can’t hold. This includes the rationale for each KPI, scoring guidance, evidence an assessor looks at, and clarifying scope notes. The spreadsheet is the working tool. The companion document is the explanation of what every cell means and why.

The Domains

Like the CSMM, the AISMM organizes its twelve categories into three domains that describe the role each category plays.

The Foundational Domain contains the core capabilities that span everything else: governance, organization management, IAM, and security monitoring. These are where most programs need to start. If governance and identity aren’t working, the rest of the model is mostly aspirational.

The Structural Domain covers the per-deployment security of AI infrastructure, models, applications, and the data flowing through them. This is where security looks most familiar to teams with traditional application and data security backgrounds, but where the underlying technology behaves differently enough that existing playbooks don’t fully translate.

The Procedural Domain covers the processes needed to sustain AI security over time: risk and provider assessment, AI-supported development and supply chain, compliance and audit, and incident response. These are the long-term-sustainability capabilities. Programs usually develop these in parallel with the foundational and structural categories, but they tend to mature later.

The Twelve Categories

The categories below are summarized; full descriptions live in the model itself and in the companion details document.

Foundational Domain

• Governance (GOV): Enterprise governance of AI — policies, decision rights, approval authorities, the AI Council or equivalent body, the authoritative registries of approved use cases and deployments, AI acceptable use, role-based training, and the ethics/safety review process for high-risk AI use cases.

• Organization Management (ORG): Technical enforcement of governance decisions across the enterprise — cloud-provider organization policies restricting AI services, AI-SPM and AI-BOM discovery, blast-radius isolation, and shared security services that AI deployments consume.

• IAM: Identity for AI — human identity into AI services, non-human identity (NHI) patterns for agents and MCP tools, authorization scopes, delegation chains, and credential lifecycle. AI strains existing IAM models in ways that matter.

• Security Monitoring (MON): Telemetry collection, SIEM integration, and detection coverage for AI-specific activity — prompt and response capture, guardrail-violation logging, agent action logs, model behavior monitoring, and the SOC workflows that consume them.

Structural Domain

• Infrastructure Security and Resilience (INF): The compute, network, and cloud or datacenter environment where AI workloads run. Training clusters, inference servers, network isolation, host vulnerability management, and resilience requirements specific to AI workload patterns.

• Model Security (MOD): The model itself — selection, approval, version pinning, integrity, provenance, parameter bounds, and model-layer behavioral monitoring. Includes the approved-model registry that downstream categories anchor to.

• Application Security (APP): AI-powered application security — system prompt structure and hardening, guardrails (Bedrock Guardrails, Azure AI Content Safety, OpenAI moderation, or equivalent), input/output validation, tool and MCP restrictions, runtime I/O monitoring, and human-in-the-loop enforcement.

• Data Security (DAT): Training data governance, RAG and vector store access control, permission-aware retrieval, inference output sanitization, and data poisoning detection. The data side of AI is where most organizations are weakest.

Procedural Domain

• Risk & Provider Assessment and Management (RSK): Risk assessment of AI providers, models, and projects — provider selection, ongoing reassessment, the approved AI provider registry, and the risk-assessment processes for specific AI deployments.

• AI-Supported Development and Supply Chain Security (DEV): Securing the use of AI in development (coding assistants like Copilot, Cursor, and similar) and the AI components in the software supply chain — AI-BOM, library scanning, CI/CD integration, and AI-specific supply-chain considerations.

• Privacy, Compliance and Audit (CMP): Regulatory compliance for AI — audit evidence collection, AI CAIQ completion, privacy impact assessments, IP and licensing tracking, and the audit-side of safety and ethics policy verification.

• Incident Response (IR): AI-specific incident response — playbooks for prompt injection, agent compromise, model abuse, data exfiltration via AI flows, and the threat intelligence integration that informs them.

The Control Objectives — What Each Column Means

Each category has its own tab in the AISMM workbook. Each tab contains between one and three representative control objectives per maturity level, starting at Level 2. These are KPIs — meeting one indicates an organization is likely at or near that maturity level, not definitively there. They are representative, not exhaustive. They were chosen because they discriminate one level from another, and they were drafted, reviewed, and revised by working subject matter experts.

Every control objective row in the workbook has the following columns:

• Control ID — a stable identifier in the form {PREFIX}-{LEVEL}.{NUMBER} (for example, MOD-03.1 is the first control objective at Level 3 in Model Security). The prefix maps to the category. This is the reference point for assessments, cross-mappings, and citations from other frameworks.

• Maturity Level — which level the control objective indicates (L2 through L5).

• Control Objective Name — a short descriptive title.

• Control Objective — a one-to-three-sentence statement of the outcome or state when the control objective is implemented. This is what an organization measures against. It is written to be SMART: specific, measurable, achievable, realistic, and (where the timing matters) time-bound.

• Deployment Types — which of the three AI deployment patterns this objective applies to: All, Self-hosted, PaaS, API/SaaS, or a combination. Organizations consuming only API/SaaS AI can filter the model to the objectives that apply to them.

• Manual / Automated — the realistic assessment mode. Automated means the objective can and should be auto-assessed via tooling like AI-SPM, CSPM, SIEM, or equivalent. Manual means it requires human review (most governance and process objectives sit here). Either means both modes are reasonable, depending on implementation.

• AICM Mapping — cross-reference to the relevant control(s) in the CSA AI Controls Matrix. Where the AISMM control objective relates to AICM controls, the IDs are listed here. Some objectives map to multiple AICM controls; some have no direct AICM counterpart by design (see the AICM section below).

• External References — cross-references to other frameworks where applicable, including the NIST AI Risk Management Framework, ISO/IEC 42001, OWASP LLM and AI security work, and others. These are not exhaustive — they are called out where they directly inform the rationale or evidence for the KPI.

The companion details document — AISMM_Control_Objectives_Details.md — adds three more elements that don’t fit cleanly in a spreadsheet cell:

• Key Indicator Rationale — one sentence explaining why an organization that meets this KPI likely has the broader maturity of that level. This is the load-bearing logic of the model. Understanding the rationale is what makes it possible to judge whether a substitute KPI an organization might prefer holds up.

• Description — deeper context, examples of what an organization actually does, the rationale for specific thresholds, and clarifying scope notes. This is where the model breathes.

• Evidence — what an assessor actually looks at to verify the KPI. Logs, configurations, registry entries, dashboards, training records, decision documents.

Use the spreadsheet to find a KPI; use the companion document to understand why it’s there and how to assess against it. The two are designed to be used together.

Relationship to the AICM and AI CAIQ

The AISMM and the AICM (with its AI CAIQ companion questionnaire) are designed to work together. They cover different questions.

The AICM is the comprehensive AI controls catalog. It is the answer to “what controls should be in place to secure an AI deployment?” — and the AI CAIQ is the standardized way an AI provider or AI-deploying organization attests to which of those controls they have implemented. Both operate at the control level. Both are comprehensive by design.

The AISMM is the maturity lens on top. It is the answer to “what does the security program managing all of this look like at each stage of maturity?” — and its control objectives are representative indicators, not a full control catalog. They are chosen specifically because they discriminate one maturity level from another.

This is why the AISMM control objectives are aligned with the AICM but may deviate from it in two specific ways.

First, some AISMM objectives describe states that are below the desired final posture but help discriminate maturity levels. An L2 KPI like “manual reconciliation across three sources” is a useful indicator that an organization is repeatable but not yet defined — but it is deliberately not a state that belongs in a comprehensive control catalog, and so it does not belong in the AICM. The AISMM uses these lower-maturity indicators on purpose. The AICM should not.

Second, some AISMM objectives describe higher-than-average maturity states — capabilities that are appropriate at Level 4 or Level 5 but that not every organization needs to achieve. A small organization with low-risk AI usage may consciously target Level 3 across most of the model. That is a reasonable program decision. The AICM is the comprehensive set of controls a fully mature program would consider; the AISMM helps an organization decide which subset of that is right for them.
Where the concepts overlap directly, the AISMM cites the AICM controls by ID in the AICM Mapping column. This makes the AISMM useful as a roadmap into the AICM: if an organization is targeting Level 4 in Model Security, the AICM mappings show which AICM controls should be in place to get there. The two work as a layered pair — the AISMM tells the program-level story of where an organization is and where it is going; the AICM (and the AI CAIQ) gives the detailed control catalog and assessment instrument to support specific deployments.

Relationship to Other AI Security and Maturity Models

The AISMM lives in a growing ecosystem of AI security frameworks, and it is worth being clear about what fits where. There is real value in each of these works, and they have different focuses by design.

The NIST AI Risk Management Framework (AI RMF) is the U.S. government’s risk management framework for AI. Its scope is broader than security alone — it covers responsible AI development, deployment, and use, organized around the Govern, Map, Measure, and Manage functions. The AISMM cross-references NIST AI RMF subcategories where they directly inform a control objective, and the two are complementary: the NIST AI RMF describes what risks to manage and how to organize the risk management function; the AISMM describes what a security program executing against those risks looks like at each stage of maturity.

ISO/IEC 42001 is the international standard for AI management systems. Like the NIST AI RMF, its scope is broader than security and includes the full AI management system. Organizations pursuing ISO/IEC 42001 certification will find that the AISMM’s governance and procedural categories overlap meaningfully with the standard’s clauses, and relevant clauses (Clause 5 leadership, Clause 7.2 competence, Annex A.6 AI system life cycle, and others) are cited in the model where they directly inform a control objective.

OWASP’s AI maturity work — including the OWASP AI Maturity Assessment and the related top-10 lists for LLM applications and agentic systems — focuses primarily on the application-security and threat-landscape view of AI. OWASP’s lens is the developer’s and application security engineer’s; the AISMM’s lens is the enterprise security program leader’s. The two are complementary. Organizations using OWASP’s work to assess and harden specific AI applications will find that the AISMM gives them the program-level structure to organize that activity at scale.

Other AI maturity models are emerging in the industry as well, mostly focused on AI capability maturity (how good is the organization at building AI, generally) or on responsible-AI maturity (how mature is the organization’s ethics and governance posture for AI development). These are valuable in their own right and address different questions. The AISMM is specifically the security program maturity model for enterprise AI usage.

Using the Model

The AISMM is meant to be used the same way the CSMM is — as a structural framework for designing, building, and maintaining the AI security side of a program, and as a maturity model for making conscious decisions about where to invest.

As a structural framework. The twelve categories give a way to organize AI security activities, identify gaps, and structure ownership across security functions. Many organizations find the model useful as a high-level framework even before they engage with the maturity-level dimension — it gives the AI Council, the security architecture team, and the business stakeholders a shared vocabulary for talking about what the program covers.

As a maturity model. The five levels describe the journey from no coordinated AI security (Level 1) to a fully automated and self-improving program (Level 5). The levels are qualitative, not quantitative — they describe what is commonly seen in practice, not a precise score. Different parts of a program will sit at different levels, and that is expected. A born-in-the-cloud product team running AI agents in production will probably be ahead of a legacy business unit just turning on Copilot. Both can be at appropriate levels for their context.

Organizations should not target Level 5 across the board. Most should not even target Level 5 in most categories. The cost and complexity of Level 5 is substantial, the gap from Level 4 to Level 5 is often steep, and for many use cases the marginal risk reduction does not justify it. A reasonable program target for many enterprises is Level 3 to Level 4 across the foundational and structural categories, with selected Level 4 to Level 5 capabilities in the categories that matter most for that organization’s specific AI usage. Smaller organizations or organizations early in their AI adoption may rightly target Level 2 to Level 3 as a starting point.

For KPI-based assessment. The control objectives function as KPIs to measure a program against. KPIs can and should be modified to fit how a given organization works, as long as the substitute is genuinely representative of the same maturity level. The deployment-type field lets assessment be scoped to the AI patterns the organization actually uses.

Recommended Process

1. Review the AISMM and the companion details document. Get a feel for the categories and what they cover.
2. Run a quick self-assessment across the twelve categories. Where does the program sit today, qualitatively, against the level descriptors on the main grid? This is a 30-minute exercise, not a six-week project.
3. Set targets. For each category, decide what level to aim for and by when. Use S.M.A.R.T. goals — Specific, Measurable, Achievable, Realistic, Time-bound. “Reach Level 4 in Security Monitoring within 12 months” is a goal; “improve AI monitoring” is not.
4. Assess against the control objectives. For each category where the program is working toward a target, use the per-category KPIs to identify what is in place, what is partially in place, and what is missing.
5. Build the roadmap. Prioritize gaps by risk and by dependencies (some categories’ Level 4 capabilities assume other categories are at Level 3 first — these dependencies are noted in the companion document as guidance, not strict gates). Sequence the work and assign owners.
6. Reassess on a meaningful cadence. AI adoption is moving fast enough that an annual reassessment is reasonable; quarterly check-ins on the highest-priority gaps are reasonable for larger or higher-risk programs.

A key point: the model is a set of guidelines, not a mandate. Not every recommendation will fit every organization. The right answer for a 200-person SaaS company with two AI integrations is going to look different from the right answer for a global financial services firm running a dozen agent platforms in production. The model provides the structure to make those decisions deliberately — it does not make them for the organization.

A Final Note

There is no correct level of AI security maturity. Over time, organizations should improve their AI security posture as their AI usage grows and the threat landscape evolves. But not every organization needs to be Level 5 across the board, and very few should try. The model serves its purpose when security leadership uses it to make informed, deliberate decisions about how mature each part of the program should be — and then can defend those decisions to the board, to auditors, and to itself.

The AISMM is a living document. As AI usage patterns evolve, as providers add and change capabilities, and as the AICM and the broader AI security ecosystem mature, the model will be revised. Contributions from practitioners are encouraged through the Cloud Security Alliance.