# HAIAMM v3.0, Model Master Document **Version:** 3.0 (2026-04-23) **Status:** Canonical. This is the single source of truth for the HAIAMM v3.0 subject, structure, and authoring rules. Every (domain × practice × level) cell in the model must conform to what is declared here. All other documents, handbook, questionnaires, website, executive summary, are derived artifacts. --- ## Table of contents 1. [Mission and subject](#1-mission-and-subject) 2. [Scope, in and out](#2-scope--in-and-out) 3. [Architecture at a glance](#3-architecture-at-a-glance) 4. [The four Business Functions](#4-the-four-business-functions) 5. [The six Domains](#5-the-six-domains) 6. [The twelve Practices](#6-the-twelve-practices) 7. [The three Maturity Levels](#7-the-three-maturity-levels) 8. [Canonical cell template](#8-canonical-cell-template) 9. [Dependency graph](#9-dependency-graph) 10. [Through-lines](#10-through-lines) 11. [Reference-framework mapping](#11-reference-framework-mapping) 12. [Authoring rules](#12-authoring-rules) 13. [Rewrite status](#13-rewrite-status) 14. [How to use this document](#14-how-to-use-this-document) 15. [Change log](#15-change-log) --- ## 1. Mission and subject **Mission.** HAIAMM measures and guides the maturity of an organization's ability to make its AI/HAI systems *trustworthy and defensible*. It is an **AI assurance** maturity model, structured after OWASP SAMM and BSIMM in shape, scoped to AI/HAI in content. **Subject.** The subject of every (domain × practice × level) cell in HAIAMM is the **AI/HAI systems, data, infrastructure, workflows, endpoints, and vendor-provided AI tools the organization builds, consumes, or operates.** The AI is what is being *secured*, not a tool being *used to secure*. **v2.0 subject (deprecated).** Earlier versions of HAIAMM treated AI as a security tool, "AI doing SAST," "AI doing DLP," "AI doing SOC," "AI doing vendor risk scoring." This framing is retired. Frameworks for AI-augmented security operations sit outside HAIAMM's scope. **Why this subject.** Organizations now ship AI-enabled products, adopt AI-enabled tools, embed AI in business workflows, and consume AI features from vendors, at a pace that outstrips classic AppSec, TPRM, and IT-Security maturity models. HAIAMM provides the maturity scaffolding specific to AI/HAI risk. ### 1.1 Guiding principles (non-negotiable) Every practice, every activity, every metric, and every document in HAIAMM exists to serve three principles. If a proposed change violates any of the three, the change is out of scope for v3.0. 1. **Fundamentals first, practices that are essential to mastering the security of AI systems.** HAIAMM teaches the load-bearing practices an organization must have to claim mastery of AI security, not an exhaustive catalog of everything one *could* do. L1 is the floor; L2 is the calibrated norm; L3 is industry-leading. Sophistication that is not foundational is not in HAIAMM's core. 2. **Measurable by default, no activity without a metric.** Every activity prescribed by HAIAMM carries at least one outcome metric with a baseline, a target, and a source. Activity counts are not metrics; outcomes are. If a practice cannot be measured, it cannot be assessed, and HAIAMM will not prescribe it. 3. **Coverage across the six domains that make up the AI surface area.** HAIAMM covers **Data · Software · Endpoints · Infrastructure · Vendors · Processes**, the six places AI/HAI lives and creates risk. A program that secures some domains while ignoring others is not mature. A framework that covers only some of the domains is not complete. All twelve practices apply, at all three maturity levels, in all six domains, 216 cells. These principles are enforced by §8 (every level block requires Outcome Metrics with Baseline / Target / Source), by §9 (the dependency graph ensures L1 fundamentals are built before L2 sophistication), by §12 (the authoring rules), and by the domain taxonomy in §5. --- ## 2. Scope, in and out ### In scope - Security, privacy, governance, and compliance posture of AI/HAI systems the organization **builds** (software domain), **consumes** (vendors / endpoints domains), or **operates** (infrastructure / data / processes domains). - HAI-specific failure modes (prompt injection, training-data leakage, tool misuse, excessive agency, agent goal hijack, rogue agents, output-integrity regression, model-family-swap compatibility, shadow AI). - Deployer duties and processor obligations under regulations that explicitly address AI (EU AI Act, GDPR Art. 22/28, ISO/IEC 42001, sector-specific AI rules). - Integration of AI-specific controls into classic practices (secure coding, code review, testing, hardening, incident response, monitoring) without replacing them. ### Out of scope - **AI as a security tool**, AI-SOC, AI-DLP, AI code-review tools, AI vendor-risk scoring platforms. These are products, not practices. Their procurement and consumption *are* in scope, but they enter HAIAMM through the Vendors domain as tools the org consumes, not through any other practice as "AI doing security." - **General cybersecurity maturity**, OWASP SAMM and BSIMM cover classic AppSec maturity. HAIAMM extends, not replaces. - **ML fairness, bias, and societal AI risk in isolation**, HAIAMM addresses these only where they intersect with security obligations (e.g., Art. 22 automated decisioning safeguards, EU AI Act FRIA triggers). Dedicated AI ethics and fairness frameworks belong alongside HAIAMM, not inside it. - **Physical security of AI infrastructure**, data-center, hardware, supply-chain integrity of silicon. Relevant but covered by ISO 27001 and sector norms; HAIAMM does not duplicate. --- ## 3. Architecture at a glance ``` HAIAMM v3.0 ┌────────────────────────────────────────────────────────────────────────┐ │ 4 BUSINESS FUNCTIONS │ │ │ │ Governance Building Verification Operations │ │ (SM, PC, EG) (TA, SR, SA) (DR, IR, ST) (EH, IM, ML) │ └────────────────────────────────────────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────────────────────┐ │ 12 PRACTICES × 6 DOMAINS │ │ │ │ Software Data Infrastructure Vendors Processes End. │ │ SM · · · ✅ · · │ │ PC · · · ✅ · · │ │ EG · · · ✅ · · │ │ TA · · · ✅ · · │ │ SR · · · ✅ · · │ │ SA · · · ✅ · · │ │ DR · · · ✅ · · │ │ IR · · · ✅ · · │ │ ST · · · ✅ · · │ │ EH · · · ✅ · · │ │ IM · · · ✅ · · │ │ ML · · · ✅ · · │ │ │ │ Each cell = one one-pager, three maturity levels, canonical template │ │ ✅ = Vendors domain is fully v3.0 at L1/L2/L3 │ │ · = v2.0 content pending v3.0 reframe │ └────────────────────────────────────────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────────────────────┐ │ 3 MATURITY LEVELS PER CELL │ │ │ │ L1 Foundational → L2 Comprehensive → L3 Industry-Leading │ │ (establish) (calibrate & scale) (automate & contribute) │ └────────────────────────────────────────────────────────────────────────┘ ``` **Total cells:** 6 domains × 12 practices × 3 levels = **216 (domain × practice × level) cells**. Each cell has a canonical section template (see §8). --- ## 4. The four Business Functions The 12 practices group into four Business Functions, mirroring OWASP SAMM's lifecycle orientation and adapted for AI-assurance work. Business Functions are an *organizing* construct, they are how leaders think about where investment goes. Every practice belongs to exactly one Business Function. ### 4.1 Governance (SM · PC · EG) **Intent:** Establish why, what, who, and how, the program's strategic frame, enforceable rules, and the people-capability that makes everything downstream possible. - **Without Governance:** Building, Verification, and Operations work has no sponsor, no policy backing, and no trained population to run it. The program becomes a series of heroic efforts. - **Signals of Governance maturity:** the program has a named executive sponsor, a published policy stack, and a workforce with the literacy to operate inside that policy. ### 4.2 Building (TA · SR · SA) **Intent:** Decide what could go wrong, what the system must do about it, and how the system is shaped to do it, before code is written or tools are configured. - **Without Building:** Verification tests the wrong things and Operations fights fires that should never have started. Threats are discovered at incident time; requirements are invented per review; architecture is reinvented per integration. - **Signals of Building maturity:** threat libraries are reused, requirements packs are versioned, reference architectures are the default path. ### 4.3 Verification (DR · IR · ST) **Intent:** Prove that the designed system, the implemented system, and the running system actually meet the Building-function outputs. Catch the gaps before adversaries do. - **Without Verification:** the program designs well but ships whatever the team happens to build. Design drifts from implementation; implementation drifts from production; production drifts from what anyone thought was deployed. - **Signals of Verification maturity:** design reviews are routine and cheap, implementation reviews catch drift automatically, security tests run in CI and in scheduled red-team cycles. ### 4.4 Operations (EH · IM · ML) **Intent:** Run the system safely in production, harden the environment, manage the issues, and watch what's actually happening. - **Without Operations:** the program ships secure systems that decay. New AI features quietly ship inside approved SaaS, configurations drift, incidents go unnoticed, evidence for regulators doesn't exist. - **Signals of Operations maturity:** the perimeter distinguishes sanctioned from unsanctioned AI use, one backlog handles all AI issues with tier-aware SLAs, detections and logs produce deployer-duty evidence on demand. **Cross-function rule:** progress in one function without the others is unstable. A mature Verification function on top of weak Governance yields reviews nobody honors. A mature Operations function on top of weak Building chases effects without causes. HAIAMM is balanced across the four by design. --- ## 5. The six Domains The six Domains answer *where the AI/HAI lives*. Every practice applies in every domain, but what that practice *means* is specific to the domain's subject. The domains below are declared in **v3.0 subject** terms. | Code | Domain | v3.0 subject | |---|---|---| | SW | **Software** | The AI/HAI software the organization **builds**, applications, models, agents, retrieval pipelines, fine-tuning and training infrastructure, evaluation harnesses, deployment services. What our developers ship. | | DT | **Data** | The data flowing **into and out of** AI systems, training corpora, inference inputs, retrieval stores, prompt/completion logs, embeddings, fine-tuning datasets, evaluation/test sets. Data is HAI's fuel and exhaust. | | IN | **Infrastructure** | The infrastructure that **hosts and serves** AI systems, inference endpoints, model registries, GPU / accelerator fleets, orchestrator control planes, vector-store infrastructure, AI-specific CI/CD. | | VN | **Vendors** ✅ | The AI/HAI tools and services the organization **consumes from third parties**, consumer GenAI, AI-embedded SaaS, AI coding assistants, AI APIs / foundation-model vendors, AI agent platforms. **Shadow AI prevention is the primary L1 outcome.** | | PR | **Processes** | The business workflows that **embed** AI/HAI, decision pipelines, customer-facing flows using AI output, human-AI collaboration chains, AI-augmented back-office processes. | | EP | **Endpoints** | AI/HAI-enabled endpoints and user-facing AI interfaces, AI assistants and copilots on managed endpoints, browser-based AI tooling, chatbots and conversational UIs, multi-modal AI interfaces. | ### Domain boundary rules - **An artifact belongs to exactly one primary domain.** An AI coding assistant deployed on engineer endpoints is a *Vendors* artifact (the org consumes it from a third party). An internal LLM-powered build-failure analyzer is a *Software* artifact (the org built it). A shared vector store that serves multiple apps is an *Infrastructure* artifact. - **When in doubt, ask: "who is responsible for the security of the *inside* of this thing?"**, the vendor, or the org? Vendor → Vendors or Endpoints. Org → Software, Data, Infrastructure, Processes, Endpoints (in that order of likelihood). - **Data is special**, data flowing *through* an org-built AI service is a Software concern at the service level *and* a Data concern at the corpus / log / embedding level. The two are expected to cross-reference. --- ## 6. The twelve Practices Each practice is described below in its **canonical v3.0 terms**, independent of domain. Reading a practice's one-paragraph definition tells you what to expect in any (practice × domain) cell. The practice code is the two-letter ID. Codes do not change across versions. ### Governance function #### SM, Strategy & Metrics Establishes the strategic **charter** for the domain's AI-assurance program: named executive sponsor, scope, decision rights, working group, and an inventory of the AI/HAI assets in scope. Defines and operates the **metric set** that proves the program is working, primarily outcome-focused, with process and effectiveness metrics supporting. At L3, SM automates inventory and tier maintenance from live signals and benchmarks the program against external peers. #### PC, Policy & Compliance Publishes the **priority policies** that make the program enforceable, typically a small number of short, AI-specific policies (e.g., AI Acceptable Use, Procurement / Intake, Data-Sharing) rather than a comprehensive policy library. Maintains the **priority compliance map** tying each relevant regulation and standard (EU AI Act Art. 26/50, NIST AI RMF GOVERN, GDPR Art. 28/22/44–49, SOC 2 CC9.2, ISO/IEC 42001, ISO/IEC 27001 A.5.19–A.5.23, sector-specific) to the single policy that carries it. Operates the **gate** through which AI/HAI artifacts enter the environment. #### EG, Education & Guidance Builds **AI-assurance literacy** across the workforce who touch AI systems and **practitioner skills** for the smaller population that performs threat modeling, secure coding, code review, security testing, red-teaming, and architecture review. The operational vehicle is the **HAIAMM AI Assurance Education Program** (docs/education/). At L3, EG publishes the curriculum and reviewer rubrics externally and contributes to emerging AI-assurance certification pathways. ### Building function #### TA, Threat Assessment Maintains the **threat library** for the domain's AI/HAI artifacts. At L1 this is archetype-level (one threat model per asset archetype) mapped to **HAIAMM's HAI TTPs (EA/AGH/TM/RA)** and to external taxonomies (MITRE ATLAS, OWASP LLM/Agentic Top 10). Each intake produces a **threat snapshot** in minutes by adapting the relevant archetype. At L2, TA adds per-vendor / per-artifact deep models for high-tier cases and red-teams the library quarterly. At L3, TA contributes discovered TTPs back to industry. #### SR, Security Requirements Translates threats (from TA) and compliance (from PC) into a **reusable requirements pack**: a base set plus per-archetype / per-subject deltas. Each pack requirement is **testable**, either a measurable SLA or a binary evidence condition. Every AI/HAI artifact reaching intake carries a **Requirements-Evidence Map (REM)** linking pack requirements to current evidence, accepted gaps (with owner and expiry), and compensating controls. #### SA, Secure Architecture Publishes the **reference architectures** for safely building / consuming / operating the domain's AI/HAI artifacts, along with an **anti-pattern catalog** derived from real incidents. Each reference pattern covers: scope, data boundary, identity and auth, traffic path, logging, controls mapped to SR requirements, and threats mitigated. At L2, patterns cover multi-region / multi-tenant / agent-platform complexity and are encoded as IaC. At L3, patterns are open artifacts adopted by the industry. ### Verification function #### DR, Design Review Operates the **design checkpoint** between intake approval and build-out for non-trivial AI/HAI integrations. Reviews the proposed design against the applicable SA reference pattern, the TA threat snapshot, and the SR requirements pack. Produces a **written decision** (approve / approve-with-conditions / send-back). Uses a **two-lane model**, fast-lane checklist review for low/medium-risk, full-lane architect review for high/critical or deviation cases. #### IR, Implementation Review Verifies the **actual configuration and code** match the design approved at DR, at go-live, at least annually, and on vendor material change. At L2, IR consumes vendor admin APIs to detect **configuration drift** continuously for high-tier artifacts. Findings are severity-tagged and SLA-bound; they feed IM. No-train and retention settings are probed recurrently, not trusted from DPA text alone. #### ST, Security Testing Exercises AI/HAI artifacts with a **foundational test battery per archetype** (data-egress canaries, no-train verification, prompt-injection probes, tool-scope boundary tests, logging-completeness tests, kill-switch tests, toggle-drift tests). Maintains **regression corpora** for jailbreaks and prompt injections that run in CI. At L2, ST runs scheduled red-team exercises per tier. At L3, ST operates continuous automated adversarial testing and contributes findings to MITRE ATLAS and the AI Vulnerability Database. ### Operations function #### EH, Environment Hardening Tunes the **perimeter and identity controls** so that sanctioned AI/HAI use is frictionless and unsanctioned use is observable or prevented. Covers SSO / IdP policy, DLP tuned for AI-specific patterns, browser policy, endpoint inventory, SaaS admin governance for AI-embedded features, CASB / SSPM AI-tuning, SASE egress granularity, per-tenant isolation, zero-trust AI access. At L3, controls are expressed as IaC with adaptive tightening driven by ML signals and IM incidents. #### IM, Issue Management Runs the **single unified backlog** for AI/HAI issues across the domain, findings from TA snapshots, SR gaps, DR conditions, IR drifts, ST failures, ML detections, external advisories. Operates a **tier-calibrated incident playbook** with pre-established vendor-coordination channels for Critical tier. Tracks **vendor-breach-notification SLAs** and **regulatory SLAs** (GDPR Art. 33, HIPAA breach notification, sector-specific). Every Critical / blocker incident receives a post-incident review that feeds updates back to SA, SR, EG, ML. #### ML, Monitoring & Logging Establishes the **logging baseline** per AI/HAI artifact archetype (prompt/completion events, tool-call events, admin-audit events, identity events) with retention and exportability that meets the longest applicable regulation. Operates a **small high-signal detection set** targeted at the top threats from TA. Produces the **evidence trail** that proves EU AI Act deployer duties, GDPR processor obligations, ISO/IEC 42001 AIMS requirements, on demand, inside a published SLA. --- ## 7. The three Maturity Levels Every (domain × practice) cell carries three maturity levels. The levels are **cumulative**, L2 assumes L1 is in place, L3 assumes L2 is in place. ### L1, Foundational **Intent:** Stand up the minimum viable capability. Discover what exists, publish the core policies, run the first version of the controls, baseline the metrics. **Typical outputs.** Inventories, short published policies, checklists, baseline metrics, first detections, first reference patterns, first requirements pack, first tests, first reviews. **Reality check for L1.** If the program cannot answer "what AI/HAI do we have?", "what rules apply to it?", and "who is accountable?" within a week, the program is not at L1. ### L2, Comprehensive **Intent:** Calibrate the program's intensity by **risk tier**. Move from one-size-fits-all to differentiated depth. Replace point-in-time activities with **continuous** validation. **Typical outputs.** A published risk-tier rubric, a tier-treatment matrix (what each tier receives from each practice), per-tier calibrated activities, continuous validation for high tiers, deeper evidence assembly, post-incident learning loops. **Reality check for L2.** If the same amount of review effort goes to a consumer GenAI used by two employees and to a Critical-tier agent platform acting on customer systems, the program is not at L2. ### L3, Industry-Leading **Intent:** **Automate** the substrate. **Benchmark** externally against peers. **Contribute** back to the AI-assurance ecosystem. **Typical outputs.** Signal-driven inventory and tier updates, telemetry-driven policy refresh, continuous attestation, external benchmarking briefs, contributions to MITRE ATLAS / OWASP LLM / NIST AI RMF Playbook / AI Vulnerability Database / CSA AI Safety Initiative / OpenSSF AI / sector ISACs. **Reality check for L3.** If all activity is still internally generated, no external contributions, no benchmarking deltas, no automation replacing routine ticket work, the program is mature for its own purposes but is not industry-leading. --- ## 8. Canonical cell template Every one-pager in HAIAMM v3.0 covers one (domain × practice) pair and contains three maturity-level blocks plus trailer sections. Authors of new content must conform. Reviewers of existing content must flag deviations. ### 8.1 One-pager skeleton ``` # {Practice Name} ({CODE}) ## {Domain} Domain - HAIAMM v3.0 ### Practice Overview Objective (one sentence, what this practice-in-this-domain achieves) Description (one paragraph, what the practice actually does) Context (one paragraph, why this framing matters, what it replaces) ## Maturity Level 1 [level block, see 8.2] ## Maturity Level 2 [level block, see 8.2] ## Maturity Level 3 [level block, see 8.2] ## Key Success Indicators **Level 1:** 3–6 bullets **Level 2:** 3–6 bullets **Level 3:** 3–6 bullets ## Common Pitfalls **Level 1:** 4–7 ❌ bullets **Level 2:** 4–7 ❌ bullets **Level 3:** 4–7 ❌ bullets ## Practice Maturity Questions **Level 1:** 3 yes/no questions with evidence criteria **Level 2:** 3 yes/no questions with evidence criteria **Level 3:** 3 yes/no questions with evidence criteria **Document Version:** HAIAMM v3.0 **Practice:** {Practice Name} ({CODE}) **Domain:** {Domain} **Last Updated:** {ISO date} ``` ### 8.2 Level block schema Every L1, L2, and L3 block inside a one-pager contains these sections, **in this order**: ``` ## Maturity Level {N} ### Objective: {one-sentence level objective in v3.0 terms} {one-paragraph "at-this-level" summary} #### Dependencies - Bullets naming the (other-practice × same-or-lower-level) cells that must be in place. Use "Required" / "Alignment (not a hard dependency)" / "Supports". #### Desired Outcomes - 4–6 outcome bullets describing the business-or-security state the level delivers. Each bullet is stated as a state, not an activity. #### Activities **A) {Activity name}** {paragraph(s) describing the activity, prescriptive} **B) {Activity name}** {paragraph(s)} **C) {Activity name}** {paragraph(s)} #### Outcome Metrics (L{N}) | Metric | Baseline | L{N} Target | Source | |---|---|---|---| | ... | measure | {target} | {where to read it} | #### Process Metrics (leading) - 2–4 leading-indicator bullets #### Effectiveness Metrics (business value) - 2–4 business-value bullets #### Success Criteria - 4–6 criteria that constitute "this level is achieved." ``` ### 8.3 Section definitions - **Objective**, the single sentence that answers "what does this level of this practice in this domain accomplish?" in v3.0 subject terms. - **Dependencies**, explicit list of other (practice × level) cells that must be in place. Three categories: **Required** (hard dependency), **Alignment** (reference only, not blocking), **Supports / unblocks** (what this cell enables downstream). - **Desired Outcomes**, state descriptions. "Shadow AI footprint is visible and trending down" is an outcome. "Run discovery sweeps monthly" is not. - **Activities**, three prescriptive activities (A, B, C). Each activity is a thing a real team executes. Sub-bullets may enumerate artifacts, acceptance criteria, or concrete examples. - **Outcome Metrics**, table form. Each row has a metric name, a baseline requirement ("measure" is acceptable at L1), an L{N} target (concrete threshold or trend), and a source (where the number is read from). - **Process Metrics**, leading indicators. These predict outcome-metric performance. Examples: cadence adherence, queue aging, review SLA. - **Effectiveness Metrics**, business value. Examples: cycle-time reductions, avoided-incident stories, external recognition, ROI. - **Success Criteria**, the checklist that answers "has this level been achieved?" Must be evidence-backed. ### 8.4 One-pager structural rules - **Practice Overview** is domain-specific (not a copy of §6's practice definition). - **Level numbering** uses `## Maturity Level 1/2/3`, not `## Level N:` or `### Level N:`. Legacy variants exist in 60 files and are scheduled for correction. - **Every level block must contain every section from §8.2**, Dependencies, Desired Outcomes, Activities, Outcome Metrics, Process Metrics, Effectiveness Metrics, Success Criteria. No exceptions. - **Metrics tables use exactly four columns**, Metric · Baseline · Target · Source. - **Activities are A / B / C**, three per level. If a level genuinely needs more, split into sub-activities under the three. - **Trailer sections (KSI / Pitfalls / Maturity Questions) are required**, they are how an assessor consumes the one-pager quickly. - **Document version stamp is required** and matches this model's major version. --- ## 9. Dependency graph HAIAMM practices form a directed graph. Each arrow reads *"B depends on A being at least L1."* The graph applies across all domains, though some cross-domain dependencies are domain-specific (noted below). ### 9.1 L1 build order (within any domain) ``` ┌───────── GOVERNANCE ─────────┐ │ │ │ SM ─► PC ─► EG │ │ │ │ └────┼─────────────────────────┘ │ ▼ ┌─── BUILDING ─────────────────┐ │ │ │ TA ─► SR ─► SA │ │ │ └────┬─────────────────────────┘ │ ▼ ┌─── VERIFICATION ─────────────┐ │ │ │ DR ─► IR │ │ ▲ │ │ └── ST (parallel to DR) │ │ │ └────┬─────────────────────────┘ │ ▼ ┌─── OPERATIONS ───────────────┐ │ │ │ EH ──┐ │ │ ML ──┼─► IM │ │ │ │ └────────┴─────────────────────┘ Governance and Building can overlap in scheduling but SM must ship first. Verification cannot begin before SA L1 exists. Operations depends on SM inventory, SA patterns, and PC policies all in place. ``` ### 9.2 Explicit L1 dependency list | Practice | Requires (L1) | Supports / unblocks | |---|---|---| | SM |, (entry point) | all other practices | | PC | SM | EG, SR, IM | | EG | SM, PC | all reviewer-heavy practices (DR, IR, ST) | | TA | SM, PC, EG | SR, SA, ST, ML, IM | | SR | TA, PC, SM | SA, DR, IR, ST | | SA | SR, TA, PC | DR, IR, ST, EH | | DR | SA, SR, TA, EG | IR, ST | | IR | DR, SR, SA, EG | ST, EH, IM, ML | | ST | TA, SR, SA, IR | IM, ML | | EH | SM, PC, SA | ML, IM | | IM | SM, PC, TA, ML | feeds back to TA, SR, SA, EG | | ML | SM, SA, EH, TA | IM, PC (evidence) | ### 9.3 L2 and L3 dependency rules - **Every L2 cell depends on its own L1 being in place.** SR-Software L2 requires SR-Software L1. - **L2 cells frequently depend on SM L2 for the tier rubric.** TA L2's per-tier deep modeling needs SM L2's risk-tier assignment to exist. - **Every L3 cell depends on its own L2 being in place**, plus the automation substrate typically provided by SM L3 (signal-driven inventory) and ML L2+ (telemetry). - **Cross-domain dependencies:** Vendors SM L1 is effectively a prerequisite for every other domain's practices that touch vendor tools (AI-coding-assistants-on-endpoints, AI-APIs-in-software, etc.). --- ## 10. Through-lines The following concepts appear across all (domain × practice × level) cells. Any v3.0 document that does not reflect them is flagged. ### 10.1 HAI-specific TTPs HAIAMM carries four AI-specific threat-tactic categories. TA, SR, SA, ST, ML documents explicitly tag relevant items to these TTPs. | Code | Name | One-line description | |---|---|---| | **EA** | Excessive Agency | The AI / agent has more capability than its use case requires, tool scopes too broad, permission model wider than any individual human's, effects reaching systems not in scope. | | **AGH** | Agent Goal Hijack | The agent's benign goal is redirected into an attacker's goal via content injected along a trusted-looking path (retrieved document, tool response, multi-turn history). | | **TM** | Tool Misuse | Tools available to the AI / agent are invoked for attacker purposes, argument smuggling, unexpected combinations, crafted parameters, recursive invocation. | | **RA** | Rogue Agents | Autonomous agents drift from intended behavior across long sessions, reflective loops, or multi-agent miscoordination, producing harmful effects nobody explicitly instructed. | ### 10.2 Priority compliance map Every PC cell at L1 publishes (and downstream TA / SR / SA / DR / IR / ST / IM / ML cells reference) a **one-page priority compliance map**. The set below is the non-exhaustive priority set, sector-specific items are added as applicable. | Priority requirement | Coverage | |---|---| | **EU AI Act** | Art. 26 deployer duties · Art. 50 transparency · Annex III high-risk systems · Art. 9 risk management · Art. 15 accuracy/robustness/cybersecurity | | **NIST AI RMF 1.0 + Playbook** | GOVERN · MAP · MEASURE · MANAGE | | **GDPR** | Art. 28 processor · Art. 22 automated decision-making · Art. 32 security · Art. 33 breach · Art. 44–49 international transfers | | **ISO/IEC 42001** | AI Management System scope + controls | | **ISO/IEC 27001** | A.5 supplier relationships · A.8 asset management · classic controls applicable to AI | | **SOC 2** | CC9.2 vendor management · trust services criteria applicable to AI services | | **Sector-specific (where applicable)** | HIPAA (clinical AI / PHI) · PCI-DSS 12.8 (AI in payment flows) · FINRA / SEC model risk · HHS / FDA AI-enabled medical devices · NYDFS Part 500 · OCC third-party risk guidance | The map's purpose is **traceability**: an auditor or regulator asking "how is Art. 26 addressed?" should reach a single cell in the map and from there one policy and from there one evidence artifact. ### 10.3 Shadow AI as a cross-domain concern Shadow AI, AI/HAI adopted outside the program's visibility, attribution, and governance, is not only a Vendors-domain concern. It appears: - **Vendors**, unsanctioned consumer GenAI, AI-embedded features silently enabled in approved SaaS, AI coding assistants on unmanaged endpoints. *Primary L1 outcome of the Vendors domain.* - **Endpoints**, managed-endpoint AI discovery, browser-extension AI tools. - **Software**, internal unsanctioned AI experiments shipped without security review. - **Data**, unsanctioned data-sharing with AI services, canary-tagged datasets leaving governed stores. - **Infrastructure**, unsanctioned model hosting, GPU-shadow-workloads. - **Processes**, AI embedded in business workflows without governance. Every domain's L1 activities include a shadow-AI discovery mechanism appropriate to that domain. ### 10.4 Five AI vendor archetypes The Vendors domain explicitly enumerates five archetypes. Other domains reference them when the asset in question comes from an AI vendor. 1. **Consumer GenAI**, ChatGPT, Claude, Gemini, Copilot (consumer). 2. **AI-embedded SaaS**, Notion AI, Slack AI, Zoom AI Companion, M365 Copilot, Salesforce Einstein, CRM/ticketing AI add-ons. 3. **AI coding assistant**, Cursor, Windsurf, Copilot (IDE), Tabnine, Cody. 4. **AI API / foundation-model vendor**, OpenAI, Anthropic, Bedrock, Vertex, self-hosted OSS served behind an API. 5. **AI agent / automation platform**, LangChain-based products, Zapier AI, Make AI, custom agents calling external APIs, multi-agent platforms. Threat libraries, requirements packs, reference architectures, and tests are all archetype-keyed. ### 10.5 Metrics taxonomy Every level block carries three metric types. The taxonomy is the canonical vocabulary, examples, targets, and sources are cell-specific. - **Outcome metrics (lagging).** Directly measure whether the level's goal was achieved. "Did we reduce shadow AI?" Typically reported monthly or quarterly. Four-column table: Metric · Baseline · Target · Source. - **Process metrics (leading).** Predict outcome metrics by measuring execution. "Did we run the discovery sweep this month?" Typically reported weekly or at the cadence of the underlying activity. - **Effectiveness metrics (business value).** Measure what the outcome means to the business. "Did we reduce procurement cycle time for sanctioned AI vendors?" Reported quarterly, often qualitative + quantitative. Metric selection follows **SMART** (specific · measurable · achievable · relevant · time-bound) and favors **outcome over output** (results over activity counts). --- ## 11. Reference-framework mapping HAIAMM is not a replacement for classic cybersecurity maturity models or for AI-governance frameworks. It sits between and alongside them. ### 11.1 Lineage - **OWASP SAMM**, HAIAMM borrows SAMM's lifecycle shape (Governance / Construction or Building / Verification / Operations) and its practice-per-function structure. - **BSIMM**, HAIAMM borrows the observational "this is what organizations actually do" posture at higher maturity levels. - **NIST AI RMF 1.0**, HAIAMM aligns its high-level framing (GOVERN corresponds to Governance function, MAP to Building, MEASURE to Verification and Operations, MANAGE to Operations). ### 11.2 Relationship table | Framework | Role alongside HAIAMM | |---|---| | **OWASP SAMM** | Classic AppSec maturity. HAIAMM extends SAMM into AI-specific territory rather than replacing it. SAMM's Software Development / Construction practices complement HAIAMM's Software-domain Building function. | | **BSIMM** | Observational data on what organizations actually do at each maturity tier. HAIAMM draws on BSIMM-style data collection but organizes findings into prescriptive activities. | | **NIST CSF 2.0** | General cybersecurity functions. HAIAMM assumes CSF-level hygiene; it does not re-teach incident response or identity basics. | | **NIST AI RMF 1.0 + Playbook** | Complementary. NIST AI RMF is risk-management-framework shape; HAIAMM is maturity-model shape. An organization uses NIST AI RMF to decide *what* to govern, and HAIAMM to measure *how mature* its ability to govern it is. See `NIST-AI-RMF-Playbook-Mapping.md`. | | **ISO/IEC 42001** | Management-system standard for AI. HAIAMM supplies the operational practices an ISO 42001 AIMS needs as evidence. | | **ISO/IEC 27001 / 27002** | General ISMS and controls. HAIAMM practices produce evidence that maps to relevant Annex A controls. | | **OWASP LLM Top 10 / ML Security Top 10** | Threat taxonomies. HAIAMM's TA practice consumes these; they are references, not content. | | **MITRE ATLAS** | Adversarial ML kill-chain (Reconnaissance → ML Model Access → ML Attack Staging → Exfiltration → Impact, with Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Collection, ML Attack, Impact tactics). HAIAMM treats ATLAS as the **canonical adversarial-ML reference** and weaves ATLAS technique IDs (`AML.TaXXXX.TXXXX`) through TA, ST, IR, and SR practices. The HAIAMM Threat Modeling Methodology (`Threat-Modeling-Methodology.md` §6, §14) requires each in-scope AI workload to be mapped against ATLAS tactics; the HAIAMM AI Attack Taxonomy (`AI-Attack-Taxonomy.md`) cross-references every entry to ATLAS where applicable. Cloud-infrastructure threats that ATLAS does not cover (standing IAM posture, etc.) live in `Cloud-Threat-Taxonomy.md`. HAIAMM contributes back to ATLAS at L3 (telemetry, candidate techniques). | | **CSA AI Safety Initiative / AI Controls Matrix** | Complementary; HAIAMM contributes to the controls matrix at L3. | ### 11.3 Distinct contributions What HAIAMM contributes that other frameworks do not: - **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. - **Vendors as a first-class domain.** Vendor-provided AI (including AI-embedded SaaS features silently enabled in approved tools) is the fastest-growing shadow surface. HAIAMM gives it a full 12-practice, 3-level treatment. - **HAI-specific TTPs (EA / AGH / TM / RA).** Agentic risk deserves its own category, not a footnote. - **Shipped questionnaires and outcome metrics.** Most frameworks stop at principles. HAIAMM includes the assessment instruments. --- ## 12. Authoring rules Anyone authoring or reviewing a (domain × practice × level) cell follows these rules. ### 12.1 Subject rule If a statement in any HAIAMM v3.0 cell describes AI as the *actor performing* a security task, it is incorrect. Flag it. **The AI is what we are securing.** Examples: - ❌ "AI agents that assess vendor risk" (v2.0 framing) - ✅ "The AI/HAI tools we consume from vendors" (v3.0 framing) - ❌ "AI-powered SAST detects vulnerabilities" - ✅ "The AI/HAI code-gen service the team ships" ### 12.2 Template rule Every cell conforms to §8's skeleton and §8.2's level block schema. No missing sections. No added sections. Authors who find they want a new section should propose a template update rather than deviate in a single file. ### 12.3 Metric rule Metrics are outcome-first. If the table contains only activity counts ("reviews completed," "tickets processed"), it is incomplete. Add outcome metrics that describe what the reviews / tickets *achieved*. ### 12.4 Dependency rule Every level block explicitly names its dependencies. "None" is a valid answer (used for SM L1 in most domains); silence is not. ### 12.5 Traceability rule Threats (TA) trace to requirements (SR) trace to architecture (SA) trace to design review (DR) trace to implementation review (IR) trace to tests (ST) trace to monitoring (ML). Compliance (PC) threads orthogonally through every one. If a threat is not reachable to a test, something is missing. ### 12.6 Tier rule (L2 and up) Once a risk-tier rubric exists (SM L2), every other practice's L2 and L3 content must reflect tier-calibrated activity. A practice that treats all artifacts identically at L2 is not at L2. ### 12.7 Version rule Cell content declared HAIAMM v3.0 must conform to this document's canonical definitions. Cells that do not yet conform carry a banner disclosing the gap. Silent mixing is not acceptable. ### 12.8 Contribution rule New archetypes, new priority compliance items, new through-lines are added here first (in this document), then propagated to the cells that reference them. Cells do not invent new global concepts. --- ## 13. Rewrite status ### By domain | Domain | L1 | L2 | L3 | Questionnaires | |---|:-:|:-:|:-:|:-:| | **Vendors** | ✅ 12/12 | ✅ 12/12 | ✅ 12/12 | ⚠️ banners added, content rewrite pending | | **Software** | ✅ 12/12 | ✅ 12/12 | ✅ 12/12 | ✅ 12/12 v3.0 | | **Data** | ✅ 12/12 | ✅ 12/12 | ✅ 12/12 | ✅ 12/12 v3.0 | | **Infrastructure** | ✅ 12/12 | ✅ 12/12 | ✅ 12/12 | ✅ 12/12 v3.0 | | **Processes** | ✅ 12/12 | ✅ 12/12 | ✅ 12/12 | ✅ 12/12 v3.0 | | **Endpoints** | ✅ 12/12 | ✅ 12/12 | ✅ 12/12 | ✅ 12/12 v3.0 | ### By framework document | Document | Status | |---|---| | **HAIAMM-v3.0-Framing.md** (this doc) | ✅ Canonical | | README.md (repo root) | ✅ v3.0 | | HAIAMM-v3.0-Executive-Summary.md | ✅ v3.0 (authored 2026-05-14) | | HAIAMM-Handbook.md | ✅ v3.0 | | HAIAMM-Quick-Start-Guide.md | ✅ v3.0 | | HAIAMM-Framework-Structure.md | ✅ v3.0 | | HAIAMM-Unified-Metrics-Framework.md | ✅ v3.0 | | NIST-AI-RMF-Playbook-Mapping.md | ✅ v3.0 | | HAIAMM-v2.0-Executive-Summary.md | 🚫 Superseded, kept as historical artifact, banner points to v3.0 | | HAIAMM-v2.0-Implementation-Guide.md | ⚠️ Pending review, reconcile with current handbook content or retire | ### By practice one-pager - **Fully v3.0 canonical: 72 / 72.** All practice one-pagers across all six domains (Vendors, Software, Data, Infrastructure, Processes, Endpoints × 12 practices each) conform to §8.1 skeleton, §8.2 level-block schema, and §8.4 structural rules: canonical `## Maturity Level N` headings; every L1/L2/L3 block has Dependencies, Desired Outcomes, Activities (A/B/C), Outcome Metrics table (four columns), Process Metrics, Effectiveness Metrics, Success Criteria; trailer sections (Key Success Indicators, Common Pitfalls, Practice Maturity Questions) and canonical Document Version stamp present. **The 216-cell (6 domain × 12 practice × 3 level) HAIAMM v3.0 model is structurally complete.** - **Questionnaires: 72 / 72 v3.0**, all assessment instruments now use the canonical 4-tier scoring model (Fully Mature / Implemented / Partial / Not Implemented), with 9 questions per questionnaire (3 per maturity level, one per Activity A/B/C), Evidence Required + Outcome Metrics + Metric Collection Guidance for each, and a Summary Scorecard. Outcome metric rows are sourced verbatim from each one-pager's canonical metrics tables. - **Remaining v3.0 work surface:** ATLAS Azure/GCP companion templates (Phase 5). --- ## 14. How to use this document ### If you are consuming HAIAMM - Start here. Then pick one domain and work through its practices and levels. - Treat Vendors as the exemplar, the other five domains will catch up to it. - Use the questionnaires for formal assessment; use the one-pagers for practitioner guidance. ### If you are authoring a new (domain × practice × level) cell 1. Reread §5 (domain subject), §6 (practice definition), §7 (level intent). 2. Use §8's skeleton and level block schema verbatim. Do not deviate. 3. Check §9 for dependencies and §10 for through-lines your cell must reflect. 4. Follow §12's authoring rules. 5. Drop the v3.0 banner (from other reframed files) at the top until your content conforms; remove the banner when it does. ### If you are rewriting a v2.0 cell to v3.0 1. Identify every statement where AI is the *actor* performing a security task, replace with AI as the *subject* being secured (§12.1). 2. Apply §8.2's level block schema, add Dependencies, Desired Outcomes, Activities (A/B/C), Outcome Metrics table, Process / Effectiveness Metrics, Success Criteria. 3. Tag relevant threats to EA / AGH / TM / RA (§10.1). 4. Reference the priority compliance map where applicable (§10.2). 5. Reflect tier calibration at L2 and up (§12.6). 6. Update the version stamp and remove the pending-reframe banner. ### If you are assessing an organization's maturity 1. Use the practice questionnaire for each (domain × practice) pair in scope. 2. Score each level as achieved / partial / not-achieved from the Practice Maturity Questions. 3. Present findings against the one-pager's Key Success Indicators and Common Pitfalls. 4. Feed observed patterns back into the program owners, HAIAMM expects to be updated by practice. --- ## 14.5 MITRE ATLAS integration (canonical reference) HAIAMM v3.0 elevates **MITRE ATLAS** from "one of several references" to the **canonical adversarial-ML reference** that runs through every threat-relevant practice. Where HAIAMM names an attack, threat, or test case, the corresponding ATLAS tactic / technique ID is provided when one exists. **Practice ↔ ATLAS coverage:** | HAIAMM Practice | Primary ATLAS tactics | |-----------------|----------------------| | Threat Assessment (TA) | All 14 tactics, TA enumerates threats by ATLAS tactic. | | Security Architecture (SA) | TA0006 Persistence, TA0007 Privilege Escalation, TA0008 Defense Evasion (architectural mitigations). | | Secure Requirements (SR) | TA0010 Discovery, TA0011 Collection (data minimization at requirement gate). | | Security Testing (ST) | TA0001 Reconnaissance, TA0004 ML Model Access, TA0012 ML Attack Staging, TA0013 Exfiltration (test surface). | | Issue Management (IM) | TA0014 Impact (response). | | Education & Guidance (EG) | All, ATLAS is taught in EG curriculum. | | Threat Intelligence (TI / TI-equivalent functions inside TA) | TA0001, TA0002 Resource Development. | | Vendor practices | TA0003 Initial Access (third-party vector), supply-chain techniques. | **Companion artifacts (canonical):** - `AI-Attack-Taxonomy.md`, every HAA entry cross-referenced to ATLAS where applicable. - `Cloud-Threat-Taxonomy.md`, covers cloud-infrastructure threats outside ATLAS scope (standing IAM, BadPermissions, BadPrincipal). - `Cloud-Controls-Taxonomy.md`, controls cross-mapped to ATLAS mitigations (`AML.M00xx`). - `Threat-Modeling-Methodology.md`, Phase 3 elicitation requires ATLAS tactic walk; §14 gives the tactic checklist. - `AI-Security-Testing-Methodology.md`, test types mapped to ATLAS tactics; per-archetype batteries reference ATLAS technique IDs. - `threat-models/templates/{AWS,GCP,Azure}/`, per-cloud templates carry an ATLAS-tactic register. **Authoring rule.** When introducing a new attack, threat, or test type into HAIAMM v3.0 content, search ATLAS for an existing technique ID and reference it. Only mint HAIAMM-native IDs (HAA / HCT / HCC / HAI-TTP) when no ATLAS technique fits, typically for cloud-IAM standing risks (HCT.BadPermissions.\*) and agent-loop concerns (HAI-TTP RA / EA / AGH / TM, partially overlapping with `AML.T0053`). --- ## 15. Change log - **3.0.7 (2026-05-15), Questionnaires fully v3.0 (Phase 2 + Phase 3 complete).** All 72 assessment questionnaires (6 domains × 12 practices) rewritten end-to-end in a single mega-wave (12 parallel agents × 6 questionnaires each, one agent per practice). Canonical questionnaire pattern: v3.0 banner pointing to source-of-truth one-pager and canonical model; 4-tier Evidence + Outcome Metrics scoring (Fully Mature 1.0, Implemented 0.67, Partial 0.33, Not Implemented 0.0); 3 maturity levels × 3 questions (one per Activity A/B/C) = 9 questions per file; Evidence Required (5-7 bullets per question) derived from one-pager Activities; Outcome Metrics table (4-col, Met?+Notes added) pulled verbatim from one-pager L1/L2/L3 outcome-metric tables; Metric Collection Guidance per metric; Answer (4-tier checkbox); Evidence Location + Validation Date + Notes fields; Summary Scorecard with practice maturity statement; canonical Document Version stamp. Verification: 72/72 pass (3/3 canonical Maturity Level headings, 9/9 questions, stamp present, 0 AI-as-actor §12.1 leaks). With this, **HAIAMM v3.0 is fully assessable**, every practice in every domain has a working v3.0 questionnaire derived from its canonical one-pager. - **3.0.6 (2026-05-14), Entry-point and framework doc reframe complete (Phase 4).** README.md rewritten to v3.0 subject framing (216-cell model, 6 domains × 12 practices × 3 levels, HAI TTPs, ATLAS canonical reference). HAIAMM-v3.0-Executive-Summary.md authored from scratch as the canonical synthesis of v3.0. HAIAMM-Quick-Start-Guide.md rewritten as a 30-60 day L1 sprint playbook with beachhead-domain and at-risk-archetype decision aids. HAIAMM-Framework-Structure.md rewritten as the structural quick-reference (pointer to canonical framing doc). HAIAMM-Unified-Metrics-Framework.md rewritten as the canonical metrics taxonomy (3 metric types, 9 cross-domain metric families, SMART criteria, anti-patterns). NIST-AI-RMF-Playbook-Mapping.md rewritten with full 72-subcategory mapping to HAIAMM cells (53 full / 13 partial / 6 declared-out-of-scope). HAIAMM-v2.0-Executive-Summary.md banner updated to fully supersede; file retained as historical artifact. §13 framework-doc table updated. - **3.0.5 (2026-05-14), Infrastructure, Processes, Endpoints domain rewrites complete (Phase 1c/1d/1e). Practice one-pager model now structurally complete.** All 36 remaining non-Vendors/Software/Data one-pagers rewritten end-to-end to v3.0 framing in a single mega-wave (12 parallel agents × 3 practices each). HAIAMM v3.0 model now has **72/72 one-pagers fully canonical**, completing the 216-cell (6 domain × 12 practice × 3 level) structural model. Infrastructure archetypes locked: inference endpoint, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infrastructure, AI-specific CI/CD, feature store. Processes archetypes: decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow. Endpoints archetypes: AI assistant/copilot on managed endpoint, browser-based AI tool, chatbot/conversational UI, multi-modal AI interface, AI-augmented productivity (SaaS-AI), mobile AI app, edge AI device. Cross-domain dependency graph (§9.3) functional: SM-domain L2 rubrics established for all six domains; every other practice L2 inherits the rubric from its domain's SM. Remaining v3.0 work surface: questionnaires (Phase 2/3), entry-point framework docs (Phase 4), ATLAS Azure/GCP templates (Phase 5). - **3.0.4 (2026-05-14), Data domain rewrite complete (Phase 1b).** All 12 Data one-pagers rewritten end-to-end to v3.0 framing in a single parallel-agent wave (4 agents × 3 practices each). Data inventory archetypes locked across all 12 cells: training corpus / training dataset, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation / test set. SM-Data L2 risk-tier dimensions: data classification, lineage/provenance, volume/criticality, cross-border flows, training-vs-inference use, decision-affecting use (Annex III / Art. 22), subject-access-rights exposure. Three priority policies established: AI Data Use Policy, Data Acceptable Use (AI), Data Intake / Sanction Gate. ATLAS data-attack techniques anchored throughout TA-Data (AML.T0010 ML Supply Chain Compromise, AML.T0019 Publish Poisoned Datasets, AML.T0020 Poison Training Data, AML.T0024 Exfiltration via ML Inference API, AML.T0025 Exfiltration via Cyber Means, AML.T0048, AML.T0051 LLM Prompt Injection). §13 rewrite-status updated (36 / 72 fully canonical, 36 / 72 v2.0 body under banner). - **3.0.3 (2026-05-13), Software domain rewrite complete (Phase 1a).** All 12 Software one-pagers rewritten end-to-end to v3.0 framing per the Vendors-exemplar pattern. SM L2 now provides the canonical AI/HAI software risk-tier rubric and tier-treatment matrix that all other Software-domain L2 practices inherit (per §9.3). Software inventory archetypes locked: LLM-integrated app, AI agent, RAG pipeline, fine-tuning/training workload, eval harness, model-serving service, classical ML. §13 rewrite-status counts updated (24 / 72 fully canonical, 48 / 72 v2.0 body under banner). Software joins Vendors as a complete domain exemplar; Data, Infrastructure, Processes, and Endpoints can now replicate from two reference domains (Phase 1b–1e). - **3.0.2 (2026-05-12), Vendors exemplar Phase 0 complete.** All 12 Vendors one-pagers brought to full canonical conformance per §8.1 skeleton, §8.2 level-block schema, §8.4 structural rules, and §12.1 subject-rule cleanliness. §13 rewrite-status counts corrected (12 / 72 fully canonical, 60 / 72 v2.0 body under banner). Vendors now serves as the proven template for the five remaining domain rewrites (Phase 1a–1e). - **3.0.1 (2026-04-16), MITRE ATLAS integration.** Promoted ATLAS to canonical adversarial-ML reference; added §14.5 with practice ↔ tactic coverage and authoring rule. Cross-referenced new companion artifacts (`AI-Attack-Taxonomy.md`, `Cloud-Threat-Taxonomy.md`, `Cloud-Controls-Taxonomy.md`, `Threat-Modeling-Methodology.md`, per-cloud TM templates). - **3.0 (2026-04-23), Model master document.** Expanded from 129-line anchor to full master document covering mission, scope, architecture, 4 Business Functions, 6 Domains, 12 Practices (canonical one-paragraph definitions), 3 Maturity Levels, canonical cell template, level block schema, dependency graph, through-lines, reference-framework mapping, authoring rules, rewrite status, and usage guidance. - **3.0-draft (2026-04-23), Initial canonical v3.0 framing.** One-page anchor introduced to serve as v3.0 source of truth while the rest of the model migrated. Superseded by the master document. --- *End of HAIAMM v3.0 Model Master Document.*