# HAIAMM v3.0, NIST AI RMF 1.0 Playbook Mapping

**Version:** 3.0 (2026-05-14)
**Status:** Current
**Canonical reference:** [`HAIAMM-v3.0-Framing.md`](HAIAMM-v3.0-Framing.md) §11 (reference-framework mapping), §10.2 (priority compliance map)
**NIST AI RMF version:** 1.0 (AI 100-1) + Playbook (AI 600-1)

---

## Purpose

This document maps HAIAMM v3.0 practices, domains, and cells to the NIST AI Risk Management Framework 1.0 and its companion Playbook. It answers a specific question: **if an organization already uses NIST AI RMF, where exactly does HAIAMM v3.0 sit alongside it?**

The relationship is complementary, not duplicative:

- **NIST AI RMF** is a risk-framework shape, it tells organizations *what* to govern, *what* to map, *what* to measure, and *what* to manage across the AI risk landscape.
- **HAIAMM v3.0** is a maturity-model shape, it tells organizations *how mature* their ability to govern, build, verify, and operate AI/HAI actually is, practice by practice, domain by domain, with outcome metrics specific enough to assess.

An organization using NIST AI RMF answers the question "are we governing AI risk?" HAIAMM tells them how well, against a calibrated scale, across the six surface areas where AI/HAI actually lives.

**What this document does not do.** It does not reproduce NIST AI RMF content. It does not claim HAIAMM replaces NIST AI RMF. It does not provide a compliance checklist. It provides a mapping so practitioners can trace NIST AI RMF subcategories to the HAIAMM cells that carry them, understand where HAIAMM goes deeper, and understand where NIST AI RMF goes broader than HAIAMM's security-assurance scope.

---

## 1. NIST AI RMF 1.0 Structure Recap

NIST AI RMF 1.0 organizes AI risk management into four **core functions**:

| Function | Intent | Subcategory count |
|---|---|---|
| **GOVERN** | Establish accountability, policies, culture, and processes for AI risk management across the organization. | 19 |
| **MAP** | Categorize AI systems by context, purpose, and risk; map applicable risk dimensions before deployment. | 16 |
| **MEASURE** | Evaluate AI systems against trustworthiness characteristics using analysis, testing, and monitoring. | 18 |
| **MANAGE** | Treat prioritized risks; respond to incidents; communicate outcomes; track residual risks. | 19 |

Total: **72 subcategories** with 450+ suggested Playbook actions across the four functions.

Each subcategory is identified as `FUNCTION N.M` (e.g., GOVERN 1.1, MEASURE 2.7). This document maps at the subcategory level and, for selected high-importance subcategories, at the Playbook-action level.

---

## 2. High-Level Function-to-HAIAMM Mapping

| NIST AI RMF Function | HAIAMM Business Function | HAIAMM Practices |
|---|---|---|
| **GOVERN**, Policies, accountability, culture, workforce | **Governance** | SM (Strategy & Metrics), PC (Policy & Compliance), EG (Education & Guidance) |
| **MAP**, Context, categorization, risk and benefit mapping | **Building** | TA (Threat Assessment), SR (Security Requirements), SA (Secure Architecture) |
| **MEASURE**, Testing, monitoring, evaluation | **Verification** + part of **Operations** | DR (Design Review), IR (Implementation Review), ST (Security Testing), ML (Monitoring & Logging) |
| **MANAGE**, Treatment, incident response, communication | **Operations** | EH (Environment Hardening), IM (Issue Management), ML (Monitoring & Logging) |

The mapping is not one-to-one. NIST AI RMF MEASURE overlaps with both HAIAMM's Verification and Operations functions because Verification catches gaps before deployment and Operations monitors what is running in production. NIST AI RMF MANAGE maps to Operations but also pulls in Verification practices for ongoing TEVV (testing, evaluation, validation, verification) activities.

---

## 3. Subcategory-Level Mapping

The tables below map each NIST AI RMF subcategory to the HAIAMM cells that address it. Coverage ratings:

- **Full**, the HAIAMM cell(s) directly and completely address the subcategory's intent
- **Partial**, HAIAMM addresses the security dimensions; other dimensions (fairness, societal impact, transparency) require supplemental frameworks
- **Gap**, the subcategory is outside HAIAMM's scope (see §7)

### GOVERN Function

#### GOVERN 1: Policies, Processes, and Procedures

| NIST Subcategory | HAIAMM Cells | Coverage | Notes |
|---|---|---|---|
| **GOVERN 1.1**, Legal/regulatory requirements | PC-{all 6 domains} L1; PC L2 (compliance gate); EG L1 (compliance literacy) | Full | PC L1 publishes the priority compliance map (EU AI Act, NIST AI RMF, GDPR, ISO/IEC 42001, SOC 2, sector-specific) per §10.2 of the framing |
| **GOVERN 1.2**, Trustworthy AI characteristics | SM-{all 6 domains} L1 (charter + scope); PC L1; SA L1 (reference patterns carrying trustworthiness properties) | Full | HAIAMM's HAI TTPs (EA/AGH/TM/RA) address trustworthiness at the agentic-risk level |
| **GOVERN 1.3**, Risk tolerance and resource allocation | SM-{all 6 domains} L2 (tier rubric and tier-treatment matrix); TA L2 (risk dimensions) | Full | SM L2 is the canonical source of risk-tier calibration in HAIAMM; it translates risk tolerance into differential program intensity |
| **GOVERN 1.4**, Transparent risk management | SM L2 (documentation policies, governance log); DR L1 (written decisions); SM L3 (continuous improvement) | Partial | HAIAMM covers internal transparency; public disclosure policies require supplemental governance process |
| **GOVERN 1.5**, Ongoing monitoring and review | ML-{all 6 domains} L1–L2 (detection sets, logging baselines); IM L1–L2 (issue backlog and incident playbook) | Partial | HAIAMM does not address end-user recourse or opt-out mechanisms; these require supplemental user-rights policies |
| **GOVERN 1.6**, AI system inventory | SM-{all 6 domains} L1 (mandatory inventory with named owning team, archetype, approval status, tier, linked artifacts); SM L3 (continuous inventory automation) | Full | HAIAMM's SM L1 is more prescriptive on inventory than NIST AI RMF, fields, discovery signals, and reconciliation cadence are all specified |
| **GOVERN 1.7**, Decommissioning and phase-out | IM L2 (lifecycle closure in the unified backlog); EH L2 (perimeter cleanup) | Partial | HAIAMM covers the security-relevant aspects of decommissioning; artifact archiving and record preservation are out of scope |

#### GOVERN 2: Accountability Structures

| NIST Subcategory | HAIAMM Cells | Coverage | Notes |
|---|---|---|---|
| **GOVERN 2.1**, Roles and responsibilities | SM-{all 6 domains} L1 (executive sponsor, working group, decision rights); SM L2 (roles in the tier-treatment matrix) | Full | SM L1 requires named executive sponsor, cross-functional working group, and explicit decision rights (who can approve, block, exception, go-live) |
| **GOVERN 2.2**, Personnel training | EG-{all 6 domains} L1–L3 (literacy program, role-based practitioner training, certification pathways at L3) | Full | EG is HAIAMM's dedicated education practice; the HAIAMM AI Assurance Education Program operates here |
| **GOVERN 2.3**, Executive leadership responsibility | SM-{all 6 domains} L1 (executive sponsor co-signed); SM L2 (program sponsor owns tier governance); SM L3 (board/exec ROI narrative) | Full | HAIAMM requires named co-sponsorship (CISO + CTO/CAI Officer) as a Success Criterion at L1 |

#### GOVERN 3: Workforce Diversity

| NIST Subcategory | HAIAMM Cells | Coverage | Notes |
|---|---|---|---|
| **GOVERN 3.1**, Diverse team decision-making |, | Gap | HAIAMM is scoped to security-assurance competency, not workforce diversity or HR practice |
| **GOVERN 3.2**, Human-AI configuration oversight | SR-{all 6 domains} L1 (least-agency principle; human-oversight requirements in requirements packs); SM L2 (HAI paradigm) | Full | The Human-Assisted Intelligence paradigm is foundational to HAIAMM; human-oversight requirements are threaded through SR, TA (EA/AGH TTPs), and ML |

#### GOVERN 4: Safety-First Culture

| NIST Subcategory | HAIAMM Cells | Coverage | Notes |
|---|---|---|---|
| **GOVERN 4.1**, Critical thinking and safety-first culture | SR L1 (security-by-design); ST L2–L3 (red-team exercises); EG L1–L2 (security-awareness curriculum) | Full | HAIAMM's Education & Guidance practice builds the security-first culture; ST's adversarial testing operationalizes challenge |
| **GOVERN 4.3**, AI testing and incident identification | ST-{all 6 domains} L1–L3 (foundational test battery, regression corpora, red-team); IM-{all 6 domains} L1–L2 (incident playbook, post-incident review) | Full | ST and IM together cover the full test-and-respond cycle; IM L2 requires post-incident review feeding back to SA, SR, EG, ML |

#### GOVERN 5: Stakeholder Engagement

| NIST Subcategory | HAIAMM Cells | Coverage | Notes |
|---|---|---|---|
| **GOVERN 5.1**, External stakeholder feedback | ST L3 (external red-team and bug-bounty engagement); SM L3 (external benchmarking) | Partial | HAIAMM covers the security-relevant externally-engaging activities; broad public engagement and stakeholder representation are outside security-assurance scope |
| **GOVERN 5.2**, Organizational risk tolerance communication | SM L2 (tier rubric published; working-group governance); IM L2 (regulatory SLA communication) | Partial | HAIAMM communicates risk tolerance internally via the tier rubric and tier-treatment matrix; external communication is partial |

#### GOVERN 6: Third-Party Management

| NIST Subcategory | HAIAMM Cells | Coverage | Notes |
|---|---|---|---|
| **GOVERN 6.1**, Third-party risks | SA-Vendors L1–L2; TA-Vendors L1–L2; SR-Vendors L1; PC-Vendors L1–L2 (intake gate and procurement gate) | Full | The Vendors domain is HAIAMM's purpose-built first-class treatment for third-party AI; all five archetypes (Consumer GenAI, AI-embedded SaaS, AI coding assistant, AI API/foundation-model vendor, AI agent/automation platform) are explicitly addressed |
| **GOVERN 6.2**, Third-party failure contingencies | SA-Vendors L2 (fallback architecture patterns); IM-Vendors L2 (vendor-breach-notification SLA tracking; pre-established coordination channels) | Full | IM-Vendors L2 requires pre-established vendor-coordination channels and tracks vendor-breach-notification SLAs |

---

### MAP Function

#### MAP 1: Context Establishment

| NIST Subcategory | HAIAMM Cells | Coverage | Notes |
|---|---|---|---|
| **MAP 1.1**, Intended purpose and deployment context | SM-{all 6 domains} L1 (charter + scope + in-scope archetypes); SR L1 (requirements pack tied to archetype + purpose) | Full | HAIAMM's archetype-keyed treatment (five Vendor archetypes, six Software archetypes, etc.) is more specific than NIST AI RMF's general "intended purpose" guidance |
| **MAP 1.5**, Organizational risk tolerance applied to categorization | PC-{all 6 domains} L1–L2 (priority compliance map); TA L2 (risk dimensions); SM L2 (tier rubric) | Full | The SM L2 tier rubric translates risk tolerance into auditable, deterministic tier assignments |
| **MAP 1.6**, Practices for engagement | EG L1–L2 (practitioner training enabling engagement at intake and review) | Partial | HAIAMM covers practitioner competency; broader organizational engagement practices require supplemental process |

#### MAP 2: AI System Categorization

| NIST Subcategory | HAIAMM Cells | Coverage | Notes |
|---|---|---|---|
| **MAP 2.1**, Scientific and established principles | SR L1 (testable requirements); ST L1–L3 (TEVV battery) | Full | HAIAMM's TEVV coverage (ST) is comprehensive; it requires per-archetype test batteries, regression corpora, and red-team exercises |
| **MAP 2.2**, AI system categorization documented | SM L1 (inventory fields including archetype, purpose, data class, approval status, tier); DR L1 (written design record) | Full | |
| **MAP 2.3**, Scientific integrity and TEVV | ST L1–L3; DR L1–L2; IR L2 (configuration-drift detection) | Partial | HAIAMM covers security-relevant TEVV thoroughly; bias-measurement techniques (MAP 2.3's bias content) require dedicated fairness framework |

#### MAP 3: Capabilities Understanding

| NIST Subcategory | HAIAMM Cells | Coverage | Notes |
|---|---|---|---|
| **MAP 3.3**, AI system capabilities documented | SA L1 (reference patterns covering scope, data boundary, identity, traffic path, logging, controls); DR L1 (written design record) | Full | |
| **MAP 3.4**, Operator and practitioner proficiency | EG L1–L2 (role-based training); EH L1 (operational documentation); SM L2 (roles matrix) | Full | |
| **MAP 3.5**, Organizational risk tolerance applied to context | SM L2 (tier rubric); TA L2 (per-tier deep threat modeling); PC L2 (compliance gate calibrated to tier) | Full | |

#### MAP 4: Risk and Benefit Mapping

| NIST Subcategory | HAIAMM Cells | Coverage | Notes |
|---|---|---|---|
| **MAP 4.1**, Third-party risk inventoried | SA-Vendors L1 (review third-party audit reports, DPA, SOC 2); SM-Vendors L1 (sanctioned-vendor catalog) | Full | |
| **MAP 4.2**, Third-party risk assessed | TA-Vendors L1–L2 (archetype-level and per-vendor deep threat models); SR-Vendors L1 (requirements pack covering EA/AGH/TM/RA) | Full | |
| **MAP 5.1**, Likelihood and impact characterization | TA-{all 6 domains} L1–L2 (threat snapshot; risk dimension scoring); IM L2 (severity tagging; SLA-calibration by tier) | Full | |
| **MAP 5.2**, Practices that assess impact | SM L2 (tier dimensions include decision-affecting use, user exposure); TA L2 (per-artifact deep model for high-tier cases) | Full | |

---

### MEASURE Function

#### MEASURE 1: Methods and Metrics

| NIST Subcategory | HAIAMM Cells | Coverage | Notes |
|---|---|---|---|
| **MEASURE 1.1**, AI risk measurement approach | ML-{all 6 domains} L1–L2 (detection set targeting top TA threats); TA L1–L2 (threat library maintained); SM L1–L2 (outcome metrics by default) | Full | HAIAMM's Unified Metrics Framework (this document's companion) provides the canonical metric taxonomy; every level block carries outcome, process, and effectiveness metrics |
| **MEASURE 1.3**, Independent assessor involvement | ST L2 (scheduled red-team exercises, independent reviewer); IR L2 (implementation review separate from the team that built); DR L2 (full-lane architect review) | Partial | HAIAMM separates Verification (DR/IR/ST) from Building (TA/SR/SA) by design; it does not prescribe external-assessor qualifications |

#### MEASURE 2: Trustworthy Characteristics Evaluation

| NIST Subcategory | HAIAMM Cells | Coverage | Notes |
|---|---|---|---|
| **MEASURE 2.4**, Production monitoring | ML-{all 6 domains} L1–L3 (logging baseline, detection set, evidence trail; prompt/completion events, tool-call events, admin-audit events, identity events) | Full | ML is HAIAMM's dedicated monitoring practice; it establishes the logging baseline per archetype and operates the detection set |
| **MEASURE 2.5**, AI system dependability | SA L1 (reference patterns include traffic path and logging); EH L1–L2 (perimeter and identity controls); IR L2 (configuration-drift detection) | Full | |
| **MEASURE 2.6**, Safety risk evaluation | ST L2–L3 (stress testing, chaos approaches for AI-specific failure modes); ML L1–L2 (real-time production monitoring); IM L1–L2 (incident documentation and response) | Full | |
| **MEASURE 2.7**, Security and resilience evaluation | ST-{all 6 domains} L1–L3 (foundational test battery: data-egress canaries, no-train verification, prompt-injection probes, tool-scope boundary, logging-completeness, kill-switch; regression corpora in CI; scheduled red-team at L2; continuous adversarial at L3); IR-{all 6 domains} L1 (configuration and code verification at go-live); EH L1–L2 (environment hardening, DLP, SSO, CASB) | Full | ST is the most comprehensive HAIAMM match to MEASURE 2.7; red-team results feed IM and back to SA per the traceability chain (§12.5 of framing) |
| **MEASURE 2.8**, Transparency and accountability | ML L1–L2 (audit logs, retention, exportability meeting longest applicable regulation); IM L2 (regulatory SLA tracking; evidence trail on demand); SM L2 (governance log; escalation paths) | Partial | HAIAMM is strong on operational transparency and audit readiness; external-facing transparency (model cards, public disclosures) requires supplemental process |
| **MEASURE 2.9**, Model explanation and validation | DR L2 (output interpretability verified at design review) | Partial | HAIAMM addresses explainability where it intersects security (misleading outputs that enable social engineering or trust exploitation); standalone explainability and algorithmic transparency require dedicated frameworks |
| **MEASURE 2.10**, Privacy risk | SA-Data L1–L2 (data boundary in reference patterns; regulated-data handling); EH-Data L1 (access controls); ML-Data L2 (query monitoring for PII patterns) | Partial | HAIAMM addresses privacy through a security lens (data-boundary enforcement, access control, DLP); privacy-enhancing techniques like differential privacy require supplemental data-science practices |
| **MEASURE 2.11**, Fairness and bias |, | Gap | HAIAMM is a security-assurance maturity model, not a fairness model. HAIAMM addresses bias only where it intersects security obligations (GDPR Art. 22 automated-decisioning safeguards, EU AI Act FRIA triggers); standalone bias measurement requires dedicated AI fairness frameworks |
| **MEASURE 2.12**, Environmental impact |, | Gap | Out of HAIAMM v3.0 scope |

#### MEASURE 3: Risk Tracking

| NIST Subcategory | HAIAMM Cells | Coverage | Notes |
|---|---|---|---|
| **MEASURE 3.1**, Existing and emergent risks | TA L2–L3 (deep per-artifact threat models; emerging threat integration); ML L2–L3 (detection-set evolution tracking emerging failure modes) | Full | |
| **MEASURE 3.2**, Difficult-to-assess risks | TA L3 (novel archetype threat modeling; contribution to MITRE ATLAS for uncharted techniques) | Full | |
| **MEASURE 3.3**, Risk tracking over lifecycle | IM-{all 6 domains} L1–L3 (unified backlog with lifecycle tracking; SLA-bound findings; post-incident review loop); ML L2 (drift detection) | Partial | HAIAMM tracks security risks through the unified IM backlog; end-user feedback channels and systemic risk tracking for societal impacts require supplemental processes |

#### MEASURE 4: Efficacy Reporting

| NIST Subcategory | HAIAMM Cells | Coverage | Notes |
|---|---|---|---|
| **MEASURE 4.1**, TEVV findings reported | IM-{all 6 domains} L2 (every finding severity-tagged, SLA-bound, reported to program sponsor); SM L2 (quarterly scoreboard to executive sponsor) | Full | |
| **MEASURE 4.2**, Risk management efficacy | SM L3 (external benchmarking brief; ROI narrative); ST L3 (adversarial testing efficacy measured); ML L3 (detection efficacy metrics) | Full | |

---

### MANAGE Function

#### MANAGE 1: Risk Prioritization

| NIST Subcategory | HAIAMM Cells | Coverage | Notes |
|---|---|---|---|
| **MANAGE 1.1**, Risk treatment and response | IM-{all 6 domains} L1–L2 (tier-calibrated SLA: Critical ack ≤4h/mitigate ≤48h; response playbook; post-incident review); ST L1–L3 (TEVV corpora) | Full | |
| **MANAGE 1.3**, Residual risk documented | TA L2 (accepted-gap tracking with owner and expiry in the REM); IM L2 (residual-risk documentation in the unified backlog) | Full | |
| **MANAGE 1.4**, Risk response plans | IM-{all 6 domains} L1 (tier-calibrated incident playbook; pre-established vendor-coordination channels for Critical tier) | Full | |

#### MANAGE 2: Benefit Maximization and Deployment Risk

| NIST Subcategory | HAIAMM Cells | Coverage | Notes |
|---|---|---|---|
| **MANAGE 2.1**, Deployment risk management | SM L2 (tier-treatment matrix); SA L1–L2 (reference patterns as the safe default path); DR L1 (intake gate before build-out) | Full | |
| **MANAGE 2.2**, Risk controls implemented | EH-{all 6 domains} L1–L2 (perimeter hardening: SSO/IdP, DLP, browser policy, endpoint inventory, CASB, SASE, per-tenant isolation, zero-trust AI access); SA L1–L2 (reference architectures with controls mapped to SR requirements) | Full | |
| **MANAGE 2.3**, TEVV implemented | ST-{all 6 domains} L1–L3 (full test battery per archetype; regression corpora in CI; red-team exercises) | Full | |
| **MANAGE 2.4**, Production monitoring | ML-{all 6 domains} L1–L3; IR-{all 6 domains} L2 (configuration-drift detection continuous for high-tier) | Full | |

#### MANAGE 3: Third-Party Risk

| NIST Subcategory | HAIAMM Cells | Coverage | Notes |
|---|---|---|---|
| **MANAGE 3.1**, Third-party resource monitoring | ML-Vendors L1–L2 (logging baseline and detection set for vendor tools); IM-Vendors L2 (vendor-breach-notification SLA tracking; monitoring for negative impacts); SA-Vendors L2 (continuous monitoring of no-train and retention settings via vendor admin APIs) | Full | |
| **MANAGE 3.2**, Pre-trained model monitoring | SM-Vendors L1 (pre-trained models in the sanctioned-vendor catalog with archetype and tier); TA-Vendors L2 (deep threat model for AI API / foundation-model vendor archetype); ML-Vendors L2 (continual monitoring of foundation-model behavior) | Full | |

#### MANAGE 4: Risk Treatment and Communication

| NIST Subcategory | HAIAMM Cells | Coverage | Notes |
|---|---|---|---|
| **MANAGE 4.1**, Post-deployment monitoring | ML-{all 6 domains} L1–L3 (logging baseline → detection set → automated continuous detection at L3); ST L2–L3 (post-deployment TEVV, red-team at scheduled intervals) | Full | |
| **MANAGE 4.2**, Incident response | IM-{all 6 domains} L1–L3 (incident playbook; tier-calibrated SLAs; post-incident review → feeds SA, SR, EG, ML; pre-established coordination channels) | Full | IM L1 is HAIAMM's primary MANAGE 4.2 mapping; it requires a written playbook at L1, tier-calibrated response at L2, and automated post-incident learning loops at L3 |
| **MANAGE 4.3**, Incident communication and tracking | IM-{all 6 domains} L2–L3 (incident database: dates, frequency, impact; system change database; version history); ML L2 (logging produces the evidence trail for regulatory reporting); DR L1 (version history in design records) | Full | |

---

## 4. Evidence Patterns

The following table maps what a NIST AI RMF auditor or regulatory examiner typically expects to see, to where HAIAMM v3.0 produces the evidence artifact.

| What the auditor asks for | HAIAMM evidence artifact | Producing cell(s) |
|---|---|---|
| AI system inventory with named owners, purpose, and risk classification | Inventory export with archetype, tier, approval status, owning team, linked artifacts | SM-{all domains} L1–L2 |
| Published AI governance policy with executive sign-off | Program charter + AI Acceptable Use Policy + priority compliance map | SM L1 / PC L1 |
| Risk management process documentation | Tier-treatment matrix; tier rubric with auditable dimensions | SM L2 |
| Threat assessment records | Threat snapshot per archetype/artifact, tagged to HAI TTPs and MITRE ATLAS tactics | TA L1–L2 |
| Security requirements traceability | Requirements-Evidence Map (REM) linking pack requirements to evidence, accepted gaps, compensating controls | SR L1–L2 |
| Architecture review records | Reference pattern documentation; DR written decisions (approve/conditions/send-back) with timestamps | SA L1 / DR L1 |
| Security testing records | ST test-run logs; prompt-injection regression corpus with last-run timestamps; red-team reports | ST L1–L3 |
| Implementation review records | IR finding log with severity tags and SLA timers; configuration-drift detection telemetry | IR L1–L2 |
| Production monitoring evidence | ML logging baseline documentation; detection-set registry; prompt/completion + tool-call + admin-audit log retention confirmation | ML L1–L2 |
| EU AI Act Art. 26 deployer-duty evidence | Logging baseline + retention documentation + rights-request SLA confirmation + bias/robustness testing records | ML L1 / ST L1 / PC L1 |
| GDPR Art. 33 breach notification readiness | IM incident playbook with regulatory SLA section; ML logging with exportable breach-scope evidence | IM L2 / ML L2 |
| ISO/IEC 42001 AIMS operational evidence | Unified IM backlog; post-incident learning loop; program charter; quarterly scoreboard | IM L2 / SM L1–L2 |
| Training and competency records | EG LMS completion records; role-based practitioner assessment scores | EG L1–L2 |

---

## 5. Playbook Activity Cross-References

NIST AI RMF Playbook activities are the implementation-level actions under each subcategory. The following table cross-references selected high-importance Playbook activities to the HAIAMM activity that satisfies them.

| NIST Playbook Activity (selected) | HAIAMM Satisfying Activity |
|---|---|
| Establish and maintain AI system inventory with risk attributes | SM-{domain} L1 Activity B, Build the AI/HAI inventory and discover shadow AI |
| Define AI system lifecycle stages and governance touchpoints | SM-{domain} L1 Activity A, Charter the program (decision rights); DR L1 Activity A, Intake gate |
| Establish risk tolerance thresholds for AI systems | SM-{domain} L2 Activity A, Define the risk-tier rubric with auditable dimensions |
| Define roles responsible for AI risk management | SM-{domain} L1 Activity A, Executive sponsor, working group, decision rights |
| Establish AI-specific training programs | EG-{domain} L1 Activity A–C, HAIAMM AI Assurance Education Program |
| Conduct threat assessments for AI systems | TA-{domain} L1 Activity A, Archetype-level threat snapshot; Activity B, HAI TTP mapping (EA/AGH/TM/RA) and MITRE ATLAS tactic walk |
| Define security testing procedures for AI | ST-{domain} L1 Activity A, Foundational test battery (data-egress, no-train, prompt-injection, tool-scope, logging-completeness, kill-switch) |
| Establish monitoring for AI system performance and incidents | ML-{domain} L1 Activity A, Logging baseline; Activity B, Detection set |
| Define incident response procedures for AI-specific incidents | IM-{domain} L1 Activity A, Tier-calibrated incident playbook |
| Establish data governance for AI training and inference data | SA-Data / PC-Data / ML-Data L1 (data boundary, data-use policy, logging baseline) |
| Review and document third-party AI systems | SA-Vendors L1 Activity A–C, Sanctioned-vendor catalog, vendor intake gate, DPA and audit review |
| Establish red-team and adversarial testing for AI | ST-{domain} L2 Activity B, Scheduled red-team per tier; TA-{domain} L2 Activity C, Adversarial-ML overlay |
| Establish controls for AI model access and use | EH-{domain} L1–L2, SSO, DLP, browser policy, CASB, SASE, per-tenant isolation |
| Document and track AI incidents and system changes | IM-{domain} L2, Unified backlog with lifecycle tracking; ML L2, Audit log and admin-audit events |
| Share AI risk findings with relevant stakeholders | SM L2, Quarterly executive scoreboard; IM L2, Post-incident review distributed to SA, SR, EG, ML |
| Conduct post-deployment assessments | ST L2–L3, Scheduled red-team; IR L2, Annual plus material-change implementation reviews |

---

## 6. Coverage Summary

| NIST Function | Subcategories | Full HAIAMM Coverage | Partial HAIAMM Coverage | Gap |
|---|---|---|---|---|
| **GOVERN** | 19 | 14 (74%) | 3 (16%) | 2 (10%) |
| **MAP** | 16 | 12 (75%) | 3 (19%) | 1 (6%) |
| **MEASURE** | 18 | 11 (61%) | 5 (28%) | 2 (11%) |
| **MANAGE** | 19 | 16 (84%) | 2 (11%) | 1 (5%) |
| **Total** | **72** | **53 (74%)** | **13 (18%)** | **6 (8%)** |

Overall: **53 of 72 subcategories at full HAIAMM coverage; 13 partial; 6 gap.**

---

## 7. Gap Notes

### 7.1 Areas Where NIST AI RMF Goes Broader Than HAIAMM

| NIST Area | HAIAMM Coverage | Reason for Gap |
|---|---|---|
| **Fairness and bias (MEASURE 2.11)** | Gap | HAIAMM is a security-assurance model. Bias measurement is addressed only where it intersects security obligations (Art. 22, Annex III triggers). Organizations need a dedicated AI fairness framework alongside HAIAMM. |
| **Explainability and interpretability (MEASURE 2.9)** | Partial | HAIAMM addresses output-integrity from a security angle (misleading outputs that enable attacks). Standalone algorithmic explainability for affected users requires supplemental frameworks (EU AI Act Art. 13, XAI toolkits). |
| **Workforce diversity (GOVERN 3.1)** | Gap | HR practice and team-diversity policy are outside HAIAMM's security-assurance scope. |
| **End-user recourse and opt-out (GOVERN 1.5)** | Gap | HAIAMM is practitioner-facing, not end-user-facing. User-rights mechanisms require separate policy and legal process. |
| **Environmental impact (MEASURE 2.12)** | Gap | Not in HAIAMM v3.0 scope. |
| **Public stakeholder engagement (GOVERN 5.1)** | Partial | HAIAMM covers the security-relevant externally-engaging activities (red-team, benchmarking, industry contributions). Broad public engagement is outside scope. |
| **Decommissioning (GOVERN 1.7)** | Partial | HAIAMM covers security-relevant decommissioning actions in IM L2 (backlog closure) and EH L2 (perimeter cleanup). Artifact archiving and record preservation sit in adjacent IT and legal processes. |

### 7.2 Areas Where HAIAMM Goes Deeper Than NIST AI RMF

| HAIAMM Capability | NIST AI RMF Treatment |
|---|---|
| **Six-domain decomposition**, Software, Data, Infrastructure, Vendors, Processes, Endpoints each get a full 12-practice, 3-level treatment | NIST AI RMF treats "the AI system" as a unit; no domain decomposition |
| **Vendors as a first-class domain**, five AI-vendor archetypes (Consumer GenAI, AI-embedded SaaS, AI coding assistant, AI API/foundation-model vendor, AI agent/automation platform) with full practice coverage; shadow AI prevention as primary L1 outcome | NIST AI RMF treats third-party risk in GOVERN 6 and MANAGE 3; no archetype decomposition |
| **HAI-specific TTPs (EA/AGH/TM/RA)**, Excessive Agency, Agent Goal Hijack, Tool Misuse, Rogue Agents, tagged in TA threat libraries, mitigated in SA, tested in ST, detected in ML | NIST AI RMF 1.0 is pre-agentic; agentic risk is not explicitly addressed |
| **Prompt-injection testing**, mandatory in ST foundational test battery for all archetypes involving LLM input paths | Not addressed in NIST AI RMF 1.0 (addressed partially in NIST AI 600-1 GenAI Profile) |
| **Requirements-Evidence Map (REM)**, per-artifact traceability from threat to requirement to architecture to review to test to monitoring | NIST AI RMF suggests traceability but provides no format |
| **Outcome metrics with baseline, target, and source**, every level block carries a four-column metrics table; activity counts are not metrics | NIST AI RMF suggests measurement; provides no metric structure |
| **Risk-tier-driven calibration**, SM L2 tier rubric drives differential intensity across all downstream practices; Critical gets the full program, Low gets the fast track | NIST AI RMF addresses risk tolerance but provides no practice-calibration mechanism |
| **MITRE ATLAS as canonical adversarial-ML reference**, ATLAS tactics TA0001–TA0014 walked per archetype; AML.TaXXXX.TXXXX technique IDs in TA, SA, ST, IR | NIST AI RMF references adversarial ML conceptually; no ATLAS integration |
| **Shipped assessment instruments**, 72 questionnaires, one per (domain × practice) pair, with outcome-metrics scoring | NIST AI RMF provides no assessment tooling |

---

## 8. Implementation Guidance

### For Organizations Using NIST AI RMF Who Want to Add HAIAMM

1. **Map existing NIST AI RMF compliance to HAIAMM practices** using §3 above. Identify which HAIAMM cells your existing NIST AI RMF activities already cover (partially or fully).

2. **Add HAIAMM's six-domain assessment layer.** Apply HAIAMM across Software, Data, Infrastructure, Vendors, Processes, Endpoints, the domain decomposition is the primary differentiator. A NIST AI RMF program that treats "the AI system" as a unit cannot distinguish between a Critical-tier customer-facing agent and a Low-tier internal-only RAG prototype; HAIAMM's SM L2 tier rubric creates that distinction.

3. **Implement HAIAMM outcome metrics.** Replace NIST AI RMF's general measurement guidance with HAIAMM's specific four-column outcome metrics tables per cell. The Unified Metrics Framework companion document defines the metric vocabulary.

4. **Address NIST AI RMF areas HAIAMM does not cover**, fairness, explainability, end-user recourse, environmental impact, with dedicated supplemental frameworks (EU AI Act Art. 13, AI fairness toolkits, XAI approaches). HAIAMM's §2 scope declaration (HAIAMM-v3.0-Framing.md) identifies these as out-of-scope by design.

### For Organizations Using HAIAMM Who Want to Document NIST AI RMF Coverage

1. Use the subcategory-level mapping in §3 to trace each HAIAMM cell to the NIST AI RMF subcategory it addresses.

2. Use the evidence-patterns table in §4 to identify which HAIAMM artifacts satisfy what a NIST AI RMF auditor expects.

3. Address the gap areas in §7.1 with supplemental frameworks. Document these in the priority compliance map (PC L1) as requirements that HAIAMM carries partially or not at all.

### For Organizations Starting From Scratch

Begin with HAIAMM's Governance practices (SM → PC → EG in the dependency order from §9 of the framing), which address the full NIST AI RMF GOVERN function. The SM L1 program charter, PC L1 priority compliance map, and EG L1 training program collectively establish the foundation. From there, HAIAMM's Building function (TA → SR → SA) addresses the MAP function, and Verification + Operations address MEASURE and MANAGE.

---

## 9. Cross-Reference to Canonical

**§11 of HAIAMM-v3.0-Framing.md** is the canonical reference-framework mapping. §11.2 is the relationship table; §11.3 identifies HAIAMM's distinct contributions.

**§10.2 of HAIAMM-v3.0-Framing.md** is the priority compliance map that PC cells publish at L1. NIST AI RMF 1.0 + Playbook (GOVERN, MAP, MEASURE, MANAGE) is a named item in that map.

**§12.1 of HAIAMM-v3.0-Framing.md** is the subject rule. Every HAIAMM v3.0 cell describes AI as the *subject being secured*, not as an actor performing security tasks. This document applies the same rule: NIST AI RMF subcategories are mapped to HAIAMM cells that govern, build, verify, and operate AI/HAI systems, not to cells that use AI as a security tool.

---

**Document Version:** HAIAMM v3.0 / **Last Updated:** 2026-05-14 / **Author:** Verifhai