HAIAMM vs Other AI Security Frameworks

A comparative analysis of HAIAMM v3.0 against the Cloud Security Alliance AI security framework family — plus the other major frameworks and maturity models for AI security and governance (NIST AI RMF, ISO/IEC 42001, Google SAIF, OWASP LLM Top 10, MITRE ATLAS, Gartner AI TRiSM, Databricks DASF) — with a practice-to-control alignment map.

Published: 2026-05-28 · Source basis: HAIAMM v3.0 framing doc; CSA AICM v1.0.3 (Oct 2025); CSA AISMM (May 19, 2026).

Orientation

CSA doesn't publish a single AI maturity model. It publishes a three-artifact family:

• AICM (AI Controls Matrix, v1.0.3, July 2025): 243 controls in 18 domains. Flat catalog, no maturity levels.
• AISMM (AI Security Maturity Model, May 19, 2026): 12 categories in 3 domains, 5 CMM-aligned levels (L1-L5). Qualitative self-assessment.
• STAR for AI: external certification/assurance program built on AICM and ISO 42001.

HAIAMM is a single integrated framework: 12 practices × 6 domains × 3 maturity levels = 216 cells, organized into 4 business functions (Governance, Building, Verification, Operations).

Side-by-side

HAIAMM strengths

1. One coherent model. CSA splits "what to control" (AICM), "how mature you are" (AISMM), and "how to assure" (STAR). HAIAMM puts the control, the maturity tier, and the success criteria in the same 216-cell grid.
2. AI-native domain taxonomy. AICM's 18 domains are 17 inherited cloud-security categories (HRS, DCS, etc.) plus one AI-only domain (MDS). HAIAMM's 6 domains were designed for AI lifecycle reality: Software, Data, Infrastructure, Vendors, Processes, Endpoints.
3. Shadow AI as a first-class L1 outcome. Third-party AICM analysis flags shadow AI as absent. HAIAMM makes "shadow AI reduction" the primary L1 outcome of the Vendors domain and threads it through all other domains.
4. GPU / model registry / vector-store / AI CI/CD coverage. Not present in AICM. HAIAMM's Infrastructure domain has dedicated archetypes for each, with SLSA provenance, GPU residual-state clearing, and orchestrator least-privilege as explicit concerns.
5. EU AI Act is structural, not annexed. CSA's EU AI Act work lives in a separate Catastrophic Risk Annex (April 2026, rolling out through Dec 2027). HAIAMM bakes Art. 14 (human oversight), Art. 22 GDPR, Art. 50 transparency, and the Annex III FRIA gate into the Processes domain handbook directly.
6. Endpoint AI is its own domain. Browser-extension AI governance, MDM allowlists for AI assistants, mobile/edge AI integrity, SaaS-AI silent-enablement detection, and Art. 50 disclosure UX have no dedicated home in AICM.
7. Quantitative assessment. AISMM is explicitly qualitative with no numerical score. HAIAMM ships a 108-question per-domain workbook with scoring methodology that produces a concrete number per practice-domain cell.
8. Public, granular content. Every HAIAMM practice, domain, and per-level cell template is public markdown. AISMM's 12 category names are not publicly enumerated.
9. HAI-specific TTP framework (EA / AGH / TM / RA). Threaded through every domain's Threat Assessment practice. CSA's 9 threat categories are framework-level only.
10. Per-cell maturity, not program-level CMM. You can be at L3 in Vendors and L1 in Infrastructure simultaneously. AISMM's CMM is one program-wide rating.

Complementary CSA strengths

A serious comparison names where the other framework is stronger. CSA's family has clear advantages worth borrowing or pairing with HAIAMM:

• Catalog breadth. 243 AICM controls vs. HAIAMM's 216 cells. AICM goes deeper on traditional cloud-security areas (encryption, IAM, data center security).
• External assurance program. STAR for AI is a public certification registry; STAR Level 2 requires ISO 42001 certification plus a "Valid-AI-ted" scored assessment. HAIAMM has no equivalent third-party attestation.
• Release velocity. CSA shipped AICM v1.0 → v1.0.3, plus CBRA, STAR for AI, AISMM, and the Agentic Trust Framework in ~10 months.
• Recognition. AICM won the 2026 CSO Awards. CSA became a CVE Numbering Authority (CNA) in 2026.
• Shared-responsibility tagging. Each AICM control is tagged to one of five provider roles (Model Provider, Orchestrated Service, Application Provider, AI Customer, Cloud Service Provider). HAIAMM's domain split implies but does not formally tag this.
• Standards mapping density. AICM ships with explicit ISO 42001 / ISO 27001 / NIST AI RMF / BSI AI C4 / EU AI Act crosswalks. HAIAMM has NIST AI RMF Playbook mapping; the others are partial.

How HAIAMM compares to other AI security & governance frameworks

CSA is the closest peer (it's the only other group shipping an AI maturity model), so it gets the deep treatment above. But teams rarely choose in a vacuum. Here are the most important comparisons against the other frameworks and maturity models tailored for AI security and governance. The recurring pattern: most are either risk/governance frameworks or flat control catalogs — HAIAMM is the one that fuses concrete controls, AI-native domains, and per-cell maturity tiers with a quantitative score.

vs. NIST AI RMF (+ Generative AI Profile)

• Risk framework, not a maturity model. NIST AI RMF organizes work into four functions (Govern, Map, Measure, Manage) but ships no maturity levels and no score — you cannot say "we're at Level 2." HAIAMM gives you a measurable tier per practice-domain cell.
• Trustworthiness-wide, not security-deep. AI RMF spans the full trustworthiness set (validity, safety, fairness, explainability, privacy, security). Security is one slice. HAIAMM is security-first and goes far deeper on adversarial threat, hardening, and monitoring.
• HAIAMM maps to it. HAIAMM already crosswalks to the NIST AI RMF Playbook, so adopting HAIAMM operationalizes AI RMF rather than competing with it. Pair them: AI RMF for board-level risk language, HAIAMM for the engineering maturity roadmap.

vs. ISO/IEC 42001 (AI Management System)

• Management system, not technical controls. ISO 42001 certifies that you have an AI management system (policies, roles, PDCA improvement loop) — it is governance- and process-oriented and deliberately light on prescriptive technical control text. HAIAMM supplies the concrete, AI-native control depth a 42001 program needs as evidence.
• Certifiable vs. free & public. ISO 42001 is a paid, externally-certifiable standard. HAIAMM is fully public markdown with no license cost and no certification body (CSA's STAR-for-AI is the certification path that pairs with ISO 42001).
• No maturity gradient. 42001 is conformant / non-conformant; it has no L1→L3 progression. HAIAMM's per-cell tiers give you an improvement runway, not a pass/fail gate. Pair them: 42001 for the auditable governance shell, HAIAMM for what actually goes inside each control.

vs. Google SAIF + OWASP LLM Top 10 + MITRE ATLAS

• These are threat/control inputs, not maturity scaffolds. Google SAIF is a set of security-engineering principles/risk map; OWASP LLM Top 10 is a vulnerability list; MITRE ATLAS is an adversary TTP knowledge base. None of the three is a maturity model or gives you a program score.
• HAIAMM consumes them. HAIAMM threads MITRE ATLAS plus its own HAI-specific TTPs (EA / AGH / TM / RA) through every domain's Threat Assessment practice, and the OWASP LLM risks land naturally in the Software and Endpoints domains. They are the "what to test for"; HAIAMM is the "how mature is our program at handling them."
• Coverage breadth. OWASP/ATLAS/SAIF center on the model and application layers. HAIAMM extends the same rigor to Vendors, Infrastructure, Processes, and Endpoints — the parts those lists barely touch.

vs. Gartner AI TRiSM + Databricks DASF

• Analyst category vs. operational framework. Gartner AI TRiSM is a conceptual market category (governance, runtime enforcement, information governance, infosec pillars) behind a paywall — strong for strategy slides, but not a free, hands-on assessable model. HAIAMM is open and directly assessable.
• DASF is a control catalog, not a maturity model. The Databricks AI Security Framework maps ~60 risks to ~50 controls across AI system components — excellent breadth, but flat (no tiers, no score), much like CSA's AICM. HAIAMM adds the maturity gradient and quantitative workbook on top of comparable control coverage.
• Vendor-neutral. DASF is anchored to the Databricks/lakehouse architecture; AI TRiSM tooling is Gartner's vendor lens. HAIAMM is platform-agnostic across clouds, model providers, and deployment patterns.

The one-line summary

Alignment map

HAIAMM practices ↔ AICM control domains

HAIAMM business functions ↔ AISMM domains

Maturity-level alignment

HAIAMM is intentionally three-tiered (L1/L2/L3) and per-cell. AISMM is five-tiered (L1-L5) and program-wide. The closest practical mapping:

Translation rule of thumb: AISMM-L2 ≈ HAIAMM-L1; AISMM-L3 ≈ HAIAMM-L2; AISMM-L4 ≈ HAIAMM-L3.

When to use which

• Pair them. Use HAIAMM as the primary maturity-and-practice scaffold, with the per-cell scoring workbook driving roadmaps. Use AICM as a deeper controls catalog when an HAIAMM practice cell needs more concrete control text (especially in IAM, CEK, DCS). Use STAR for AI when you need an externally-attested public posture.
• Use HAIAMM alone when AI-native domain coverage matters (shadow AI, endpoints, AI infrastructure, vendor AI) or when a quantitative maturity number per practice-domain cell is required.
• Use CSA alone when external certification and broad cloud-security control depth dominate, and when AISMM's program-level CMM rating is acceptable.

One-line positioning

HAIAMM's "domains" are the AI things you defend (Vendors, Endpoints, Infrastructure, ...). CSA's "domains" are the security disciplines you do (IAM, BCR, HRS, ...). That structural divergence drives every other difference.