# HAIAMM v3.0, Executive Summary

**Version:** 3.0 (2026-05-14)
**Status:** Current
**Companion documents:** [`HAIAMM-v3.0-Framing.md`](HAIAMM-v3.0-Framing.md) (canonical model master), [`HAIAMM-Handbook.md`](HAIAMM-Handbook.md) (practitioner handbook), [`practices/`](practices/) (72 one-pagers), [`questionnaires/`](questionnaires/) (assessment instruments)

---

## What HAIAMM is

**HAIAMM v3.0 is an AI assurance maturity model**, the OWASP SAMM / BSIMM analogue for AI/HAI systems. It measures and guides the maturity of an organization's ability to make the AI/HAI systems it builds, consumes, and operates **trustworthy and defensible**.

**The subject of HAIAMM is the AI/HAI itself**, applications, models, agents, data, infrastructure, workflows, endpoints, and vendor tools. The AI is what is being *secured*, not a tool being *used to secure*. Frameworks for AI-augmented security operations (AI-SOC, AI-DLP, AI code-review tools) sit outside HAIAMM's scope.

## Why HAIAMM exists

Organizations now ship AI-enabled products, consume AI-embedded SaaS, embed AI in business workflows, and operate AI infrastructure at a pace that outstrips classic AppSec, TPRM, and IT-Security maturity models. NIST AI RMF tells you *what* to govern; ISO/IEC 42001 tells you *what AIMS structure to have*. **HAIAMM tells you *how mature* your ability to govern, build, verify, and operate AI/HAI actually is**, with practices, levels, and outcome metrics specific enough to assess.

## What HAIAMM v3.0 contains

### Architecture

- **4 Business Functions**, Governance, Building, Verification, Operations (lifecycle shape inherited from SAMM, adapted for AI assurance)
- **12 Practices** grouped under the functions, SM, PC, EG (Governance); TA, SR, SA (Building); DR, IR, ST (Verification); EH, IM, ML (Operations)
- **6 Domains**, Software, Data, Infrastructure, Vendors, Processes, Endpoints
- **3 Maturity Levels** per (domain × practice) cell, L1 Foundational, L2 Comprehensive, L3 Industry-Leading
- **216 cells total** = 6 domains × 12 practices × 3 levels, each authored to a canonical template

### Canonical cell template

Every (domain × practice × level) cell carries the same structure:
- Practice Overview (Objective + Description + Context)
- Per level: Objective → Dependencies → Desired Outcomes → Activities (A/B/C) → Outcome Metrics table → Process Metrics → Effectiveness Metrics → Success Criteria
- Trailer: Key Success Indicators, Common Pitfalls, Practice Maturity Questions (3 yes/no per level)
- Canonical Document Version stamp

### HAI-specific threat categories

| Code | Name | One-line description |
|---|---|---|
| **EA** | Excessive Agency | The AI / agent has more capability than its use case requires. |
| **AGH** | Agent Goal Hijack | The agent's benign goal is redirected via content injected along a trusted-looking path. |
| **TM** | Tool Misuse | Tools available to the AI are invoked for attacker purposes. |
| **RA** | Rogue Agents | Autonomous agents drift from intended behavior across long sessions or multi-agent miscoordination. |

### Priority compliance map

Threaded through every PC cell and referenced by TA / SR / SA / DR / IR / ST / IM / ML:
- EU AI Act (Art. 26 deployer duties, Art. 50 transparency, Annex III high-risk, Art. 9 risk management, Art. 15 accuracy/robustness/cybersecurity, Art. 12 logs, Art. 14 human oversight)
- NIST AI RMF 1.0 + Playbook (GOVERN, MAP, MEASURE, MANAGE)
- GDPR (Art. 28 processor, Art. 22 automated decisioning, Art. 32 security, Art. 33 breach, Arts. 44–49 international transfers, Arts. 5/6/9 lawful basis and special-category data)
- ISO/IEC 42001 AI Management System
- ISO/IEC 27001 (A.5 supplier relationships, A.8 asset management)
- SOC 2 (CC9.2 vendor management)
- Sector-specific: HIPAA, PCI-DSS 12.8, FINRA/SEC model risk, HHS/FDA AI medical devices, NYDFS Part 500, OCC third-party risk, NYC Local Law 144, CO SB-21-169, FCRA, EEOC, FERPA, COPPA

### MITRE ATLAS as canonical adversarial-ML reference

§14.5 of the framing doc elevates MITRE ATLAS from "one of several references" to **the canonical adversarial-ML reference** running through every threat-relevant practice. Where HAIAMM names an attack, threat, or test case, the corresponding ATLAS tactic / technique ID is provided. ATLAS tactics TA0001–TA0014 are walked per archetype in TA practices; AML.M00xx mitigation IDs are referenced in SA; per-cloud threat-model templates (AWS authored, Azure/GCP pending) accompany the canonical TM methodology.

## What's distinctive about HAIAMM v3.0

1. **Six-domain decomposition of AI surface area.** NIST AI RMF and ISO 42001 treat "the AI system" monolithically. HAIAMM splits it into Software / Data / Infrastructure / Vendors / Processes / Endpoints, which makes ownership and assessment tractable. Each domain's practice content names what the org actually builds, consumes, or operates, not abstractions.
2. **Vendors as a first-class domain.** Vendor-provided AI (including AI-embedded SaaS features silently enabled in approved tools) is the fastest-growing shadow AI surface. HAIAMM gives it a full 12-practice, 3-level treatment. Shadow AI reduction is the primary L1 outcome of the Vendors domain.
3. **HAI-specific TTPs (EA / AGH / TM / RA).** Agentic risk deserves its own category, not a footnote. These TTPs are tagged in TA threat libraries, mitigated in SA reference patterns, tested in ST batteries, and detected in ML monitoring.
4. **Outcome metrics by default, no activity without a metric.** Every level prescribes outcome metrics with baseline, target, and source. Activity counts ("reviews completed," "tickets processed") are not metrics; outcomes are. If a practice cannot be measured, HAIAMM does not prescribe it.
5. **Risk-tier-driven calibration.** SM L2 in each domain produces a risk-tier rubric and tier-treatment matrix. Every other L2 cell inherits the rubric, Critical AI artifacts get the full program; Low ones get the fast track. A program that treats all artifacts identically at L2 is not at L2.
6. **Shipped assessment instruments.** Most frameworks stop at principles. HAIAMM ships 72 questionnaires (one per domain × practice pair) with outcome-metrics scoring at v3.0.

## Maturity-level intent

| Level | Intent | Signature output |
|---|---|---|
| **L1 Foundational** | Stand up the minimum viable capability. | Inventories, short published policies, baseline metrics, first detections, first reference patterns, first requirements pack. The program can answer "what AI/HAI do we have, what rules apply, who is accountable" within a week. |
| **L2 Comprehensive** | Calibrate intensity by risk tier; replace point-in-time activities with continuous validation. | Published risk-tier rubric, tier-treatment matrix, per-tier calibrated activities, continuous validation for high tiers, deeper evidence assembly, post-incident learning loops. |
| **L3 Industry-Leading** | Automate the substrate; benchmark externally; contribute back. | Signal-driven inventory and tier updates, telemetry-driven policy refresh, continuous attestation, external benchmarking briefs, contributions to MITRE ATLAS, OWASP LLM/Agentic, NIST AI RMF, AVID, CSA, OpenSSF AI, sector ISACs. |

## How HAIAMM relates to peer frameworks

| Framework | Relationship |
|---|---|
| **OWASP SAMM** | HAIAMM borrows SAMM's lifecycle shape (Governance / Building / Verification / Operations) and extends rather than replaces it. SAMM remains for classic AppSec. |
| **BSIMM** | HAIAMM borrows BSIMM's observational posture for L2/L3 maturity. |
| **NIST AI RMF 1.0 + Playbook** | Complementary. NIST AI RMF is risk-framework shape; HAIAMM is maturity-model shape. See [`NIST-AI-RMF-Playbook-Mapping.md`](NIST-AI-RMF-Playbook-Mapping.md). |
| **ISO/IEC 42001** | HAIAMM supplies the operational practices a 42001 AIMS needs as evidence. |
| **ISO/IEC 27001** | HAIAMM extends with AI-specific practices; classic Annex A controls still apply. |
| **OWASP LLM / Agentic Top 10** | Threat taxonomies consumed by HAIAMM's TA practice. |
| **MITRE ATLAS** | Canonical adversarial-ML reference (per §14.5). |
| **CSA AI Safety Initiative / AI Controls Matrix** | HAIAMM contributes to the controls matrix at L3. |

## v3.0 status

- **216 / 216 cells** structurally canonical per §8.
- **72 / 72 one-pagers** at full conformance (Vendors, Software, Data, Infrastructure, Processes, Endpoints × 12 practices each).
- **1 / 72 questionnaires** at v3.0 (IR, Implementation Review). The remaining 71 carry the v3.0 banner but v2.0 content; Phase 2/3 rewrites pending.
- **AWS** per-cloud threat-model template authored; **Azure / GCP** companions pending (§14.5).
- Framework documents (Handbook, NIST AI RMF Mapping, Unified Metrics, this Executive Summary) reframed to v3.0.

## Where to start

1. **Read the canonical model**, [`HAIAMM-v3.0-Framing.md`](HAIAMM-v3.0-Framing.md) (~700 lines, declarative).
2. **Pick a domain** and work through its 12 practice one-pagers (`practices/{PRACTICE}-{DOMAIN}-OnePager.md`).
3. **Treat Vendors and Software as exemplars**, they were authored first and serve as references for the other four.
4. **Use the questionnaires for formal assessment**; use the one-pagers for practitioner guidance.
5. **Authors and contributors:** read §12 (authoring rules) before writing, especially §12.1 (subject rule), §12.3 (metric rule), and §12.7 (version rule).

## Change log

- **3.0 (2026-05-14)**, Practice one-pager model structurally complete (216 cells, 72 one-pagers, all six domains canonical).
- **3.0.x (2026-04 → 2026-05)**, Incremental domain rewrites; see §15 of the framing doc for per-phase deltas.
- **2.0 (deprecated)**, Earlier subject framing treated AI as a security tool ("AI doing SAST/DLP/SOC/vendor scoring"). Retired; v3.0 inverts to AI as the subject being secured.

---

*HAIAMM v3.0 is open and community-driven. Contributions welcome through the project repository.*