CrosswalkNIST AI RMF 1.021 October 2026
NIST AI RMF implementation, control by control
To implement the NIST AI RMF in an enterprise, assign each of its 72 subcategories to a control with a named owner, run that control inside the workflow, and keep the record it writes at the moment of action. This page publishes that assignment for our 15 governance controls, with the evidence for each, what NIST leaves to the deployer and the US legal status on 21 October 2026.
On this page
A published crosswalk, testable row by row.
In this document, "we" means Hikari Blue, the firm that installs the Enterprise AI Governance Framework on client engagements and hands it over. The mapping is ours: NIST has not reviewed or endorsed it.
Identifiers and wording follow NIST AI 100-1, Tables 1 to 4: 4 functions, 19 categories and 72 subcategories. GOVERN sets policy and accountability across the organization; MAP establishes the context of each AI system, MEASURE evaluates and tracks its risks, and MANAGE treats them, up to deactivation.
Each row names one control of our framework, the subcategories it gives evidence for, and the artefact an auditor asks for, never a presentation about it.
15 controls, the subcategories they serve, and the proof of each.
Read each row from left to right: the control, the NIST AI RMF 1.0 subcategories it gives evidence for, the artefact an auditor asks for, and the kind of evidence it is. A subcategory can appear in several rows, because one control rarely satisfies it alone.
| Control | NIST AI RMF 1.0 | Evidence an auditor asks for | Evidence type |
|---|---|---|---|
| GOV-P-01 · Use-case register and classification | GOVERN 1.3 · GOVERN 1.6 · MAP 1.1 · MAP 2.1 · MAP 3.3 | The use-case register, each entry with its classification rationale signed by the AI risk owner. | Register |
| GOV-P-02 · Policy as code | GOVERN 1.1 · GOVERN 1.4 · MANAGE 1.3 | The policy repository with its version history and approvals, and the gap log of written rules that no runtime enforces. | Register and log |
| GOV-P-03 · Model selection and change control | GOVERN 6.1 · GOVERN 6.2 · MAP 4.2 · MANAGE 3.1 · MANAGE 3.2 | The routing table, with a primary model, a fallback and a corridor per task class; change entries in the trail; minutes of the quarterly provider review. | Log and review |
| GOV-P-04 · Instructions for use and transparency | GOVERN 4.2 · MAP 2.2 | One instructions-for-use file per system, versioned with the model, and the notice texts shown to affected people. | Register |
| GOV-D-01 · Residency corridor per workload | MAP 4.2 · MEASURE 2.7 · MEASURE 2.10 | The residency map and the denial log of out-of-corridor calls, reviewed weekly. | Register and log |
| GOV-D-02 · Impact assessments before production | MAP 5.1 · MEASURE 2.10 · MANAGE 1.1 | Signed data protection and fundamental rights impact assessments, each linked to its register entry and dated before first production use. | Review |
| GOV-D-03 · Inputs by reference | MEASURE 2.7 · MEASURE 2.10 | Quarterly samples of trail records that hold references or hashes only, and the architecture decision record. | Test |
| GOV-A-01 · One identity per agent | GOVERN 1.6 · GOVERN 2.1 · MEASURE 2.8 | The agent register, reconciled weekly against the enterprise identity provider. | Register |
| GOV-A-02 · Declared scope and budget | MAP 3.3 · MEASURE 2.7 · MANAGE 1.3 | The permission matrix and the denial log, each denial stamped with the policy version that refused the call. | Register and log |
| GOV-A-03 · Human verification of consequential outputs | GOVERN 3.2 · MAP 3.4 · MAP 3.5 | The human verification field of each record, with identity and reason, and the verifier's competence record. | Log |
| GOV-A-04 · Stop path and drill | MEASURE 2.6 · MANAGE 2.3 · MANAGE 2.4 | The kill switch runbook and its drill history, with the measured time from trigger to halt and the restart authorization. | Test |
| GOV-E-01 · Append-only, chained trail | MEASURE 2.4 · MEASURE 2.8 · MANAGE 4.1 | The trail itself, one 9-field record per action, and the daily hash-chain verification result. | Log and test |
| GOV-E-02 · Dated literacy records | GOVERN 2.2 · MAP 3.4 | Dated training records linked to the identities in the agent and operator registers, refreshed annually. | Register |
| GOV-E-03 · Monitoring and incident record | GOVERN 4.3 · MEASURE 3.1 · MANAGE 4.1 · MANAGE 4.3 | The incident register: detection time, stop action, notification decision per regime and root cause for each incident. | Register |
| GOV-E-04 · Quarterly board pack | GOVERN 1.5 · GOVERN 2.3 · MANAGE 1.4 | The signed board pack, each figure linked to the records it counts, and the board minute that received it. | Review |
3 framework sections answer GOVERN as a whole.
Roles, cadence and maturity are not controls. They carry the accountability and review duties that GOVERN places on the organization.
| Framework section | NIST AI RMF 1.0 | Evidence an auditor asks for | Evidence type |
|---|---|---|---|
| 2 · Roles and 3 · Decision rights | GOVERN 2.1 · GOVERN 2.3 · GOVERN 3.2 | The decision rights table signed for each workflow, with one accountable role per decision. | Review |
| 6 · Cadence | GOVERN 1.5 | The calendar of the 5 cadences and the record of each review held. | Review |
| 7 · Maturity model | AI RMF Profiles, AI 100-1 section 6 | The maturity assessment read as a Current Profile, with a dated Target Profile and the gaps between them. | Review |
Evidence types. A log is written by the system at the moment of action. A register is kept by a named owner. A test is run and its result kept. A review is a dated decision by a named person or body.
Control statements, owners and cadences are those of the Enterprise AI Governance Framework v1.0, published on 25 September 2026.
36 of 72 subcategories carry direct evidence. The other 36 belong elsewhere.
A crosswalk that claims all 72 subcategories hides the work left to do. The 15 controls govern, trace and stop; they do not evaluate a model or write a business case.
| Function | Subcategories in AI RMF 1.0 | Direct evidence from the 15 controls | Owned by another program |
|---|---|---|---|
| GOVERN | 19 | 13 | 6 |
| MAP | 18 | 8 | 10 |
| MEASURE | 22 | 6 | 16 |
| MANAGE | 13 | 9 | 4 |
| Total | 72 | 36 | 36 |
Where the other 36 subcategories live.
Model testing and evaluation · 16
MEASURE 1.1 to 1.3, 2.1 to 2.3, 2.5, 2.9, 2.11 to 2.13, 3.2, 4.1 to 4.3, and MAP 2.3.
Test sets, validity, explainability, fairness, environmental impact and the efficacy of the metrics. Model teams and independent assessors produce this evidence; the layer pins the model version it refers to.
Business case and risk tolerance · 9
MAP 1.3 to 1.6, 3.1, 3.2, and MANAGE 1.2, 2.1, 2.2.
Mission, business value, risk tolerance, requirements, costs and non-AI alternatives: diagnostic work that the accountable executive decides before build.
People, culture and outside feedback · 8
GOVERN 3.1, 4.1, 5.1, 5.2, MAP 1.2, 5.2, MEASURE 3.3 and MANAGE 4.2.
Team composition, safety culture, outside feedback and appeal routes for end users. Leadership and system owners hold them; the trail records appeals and overrides once they exist.
Policy content and lifecycle edges · 3
GOVERN 1.2, 1.7 and MAP 4.1.
Trustworthiness written into policy, decommissioning, and the legal and intellectual property risks of third-party components. The AI risk owner holds them, with counsel.
The 36 subcategories, and the controls that evidence them.
Paraphrased from NIST AI 100-1; the official wording governs.
| Subcategory | What NIST asks, in short | Evidenced by |
|---|---|---|
| GOVERN 1.1 | Legal and regulatory requirements for AI are understood, managed and documented. | GOV-P-02 |
| GOVERN 1.3 | The level of risk management activity follows the organization's risk tolerance. | GOV-P-01 |
| GOVERN 1.4 | Risk management runs through transparent policies, procedures and controls. | GOV-P-02 |
| GOVERN 1.5 | Monitoring and periodic review are planned, with roles and frequency defined. | GOV-E-04, Section 6 |
| GOVERN 1.6 | AI systems are inventoried, with resources set by risk priority. | GOV-P-01, GOV-A-01 |
| GOVERN 2.1 | Roles, responsibilities and lines of communication for AI risk are documented. | GOV-A-01, Sections 2 and 3 |
| GOVERN 2.2 | Personnel and partners receive AI risk management training. | GOV-E-02 |
| GOVERN 2.3 | Executive leadership takes responsibility for decisions on AI risk. | GOV-E-04, Sections 2 and 3 |
| GOVERN 3.2 | Roles for human-AI configurations and oversight of AI systems are defined. | GOV-A-03, Sections 2 and 3 |
| GOVERN 4.2 | Teams document the risks and impacts of the AI they use and communicate about them. | GOV-P-04 |
| GOVERN 4.3 | Practices enable AI testing, incident identification and information sharing. | GOV-E-03 |
| GOVERN 6.1 | Policies address AI risks from third-party software, data and supply chains. | GOV-P-03 |
| GOVERN 6.2 | Contingency processes cover failures in high-risk third-party data or AI systems. | GOV-P-03 |
| MAP 1.1 | Intended purpose, context, applicable laws and settings of use are documented. | GOV-P-01 |
| MAP 2.1 | The tasks and methods the AI system supports are defined. | GOV-P-01 |
| MAP 2.2 | Knowledge limits, and how humans use and oversee outputs, are documented. | GOV-P-04 |
| MAP 3.3 | The targeted application scope is specified and documented. | GOV-P-01, GOV-A-02 |
| MAP 3.4 | Operator and practitioner proficiency is defined, assessed and documented. | GOV-A-03, GOV-E-02 |
| MAP 3.5 | Human oversight processes are defined, assessed and documented. | GOV-A-03 |
| MAP 4.2 | Internal risk controls for components, third-party AI included, are documented. | GOV-P-03, GOV-D-01 |
| MAP 5.1 | The likelihood and magnitude of each identified impact are documented. | GOV-D-02 |
| MEASURE 2.4 | System functionality and behavior are monitored in production. | GOV-E-01 |
| MEASURE 2.6 | Safety risks are evaluated; the system can fail safely and failure response times are tracked. | GOV-A-04 |
| MEASURE 2.7 | Security and resilience are evaluated and documented. | GOV-D-01, GOV-D-03, GOV-A-02 |
| MEASURE 2.8 | Transparency and accountability risks are examined and documented. | GOV-A-01, GOV-E-01 |
| MEASURE 2.10 | Privacy risk is examined and documented. | GOV-D-01, GOV-D-02, GOV-D-03 |
| MEASURE 3.1 | Existing, unanticipated and emergent risks are tracked over time. | GOV-E-03 |
| MANAGE 1.1 | A decision is made on whether development or deployment proceeds. | GOV-D-02 |
| MANAGE 1.3 | Responses to high-priority risks are developed, planned and documented. | GOV-P-02, GOV-A-02 |
| MANAGE 1.4 | Negative residual risks are documented. | GOV-E-04 |
| MANAGE 2.3 | Procedures respond to and recover from a previously unknown risk. | GOV-A-04 |
| MANAGE 2.4 | Mechanisms and assigned responsibilities exist to supersede, disengage or deactivate a system. | GOV-A-04 |
| MANAGE 3.1 | Third-party AI risks are monitored and risk controls applied. | GOV-P-03 |
| MANAGE 3.2 | Pre-trained models in use are monitored. | GOV-P-03 |
| MANAGE 4.1 | Post-deployment monitoring, appeal and override, incident response and change management are in place. | GOV-E-01, GOV-E-03 |
| MANAGE 4.3 | Incidents and errors are communicated, tracked and recovered from. | GOV-E-03 |
NIST names the outcome. It leaves the mechanism to you.
NIST published AI RMF 1.0 in January 2023, before AI agents acted inside enterprise workflows. A word search of NIST AI 100-1 finds no occurrence of agent, log or kill switch.
MANAGE 2.4 asks for mechanisms, with assigned responsibilities, to supersede, disengage or deactivate an AI system whose outcomes depart from its intended use. It does not say who may trigger the stop, how fast the system must halt, who authorizes the restart, or which record proves the halt.
The Generative AI Profile adds 4 suggested actions under MANAGE 2.4, from communication plans to deactivation criteria. None of them sets a halt time.
What an operating layer adds.
GOV-A-01 · One identity per agent
Every agent acts under its own identity from the enterprise identity provider, so every action is attributable. Without it, MEASURE 2.8 cannot be evidenced in an agentic workflow.
GOV-A-02 · Declared scope and budget
Each agent's tools, data and spend are declared. A call outside that scope is refused before it runs, and logged with the policy version that refused it.
GOV-A-04 · Stop path and drill
Any named operator or verifier halts an agent, a model or a workflow in one action; only the AI risk owner authorizes the restart. The drill records the time from trigger to halt.
GOV-E-01 · Append-only, chained trail
9 fields per action, chained by hash, exported to a regulator without reconstruction. NIST asks for documentation; this record is the documentation.
GOV-P-02 · Policy as code
A written rule with no enforcement point is logged as a gap, and each record carries the identifier and version of the policy that applied.
Voluntary at NIST, named in Texas law, leaving Colorado's statute.
NIST publishes the framework for voluntary use. Its legal weight comes from the state laws that name it, and that list changed in 2026. Each status below was read in its primary source on 21 October 2026.
| Instrument | What it says about the AI RMF | Status on 21 October 2026 |
|---|---|---|
| NIST AI 100‑1, AI RMF 1.0 | 4 functions, 19 categories, 72 subcategories. NIST states that the framework is intended for voluntary use. | Released 26 January 2023. NIST states that it is being revised under the White House AI Action Plan; version 1.0 remains the published text. |
| NIST AI 600‑1, Generative AI Profile | 12 risks unique to or worsened by generative AI, with suggested actions keyed to AI RMF subcategories. | Released 26 July 2024. Named in Texas law since 1 January 2026. |
| NIST AI RMF Playbook | Suggested actions per subcategory. NIST states that it is neither a checklist nor a set of steps to follow in full. | Updated about twice a year, according to NIST, which will update it after the AI RMF revision. |
| Texas HB 149, Texas Responsible Artificial Intelligence Governance Act | Section 552.105(e)(2)(D) of the Business and Commerce Code: a defendant may not be found liable when it discovers a violation through an internal review process while substantially complying with the latest NIST Generative AI Profile, or another nationally or internationally recognized AI risk management framework. | Signed 22 June 2025, in effect since 1 January 2026. Enforced by the Texas attorney general alone, after a 60-day notice to cure; civil penalties of up to $200,000 per uncurable violation. |
| Colorado SB24-205, Consumer Protections for Artificial Intelligence | Deployer risk programs judged against the latest NIST AI RMF, ISO/IEC 42001 or an equivalent framework (C.R.S. 6-1-1703(2)). An affirmative defense in attorney general actions for those who discover and cure a violation and otherwise comply with the AI RMF and ISO/IEC 42001, or an equivalent (6-1-1706(3)). | Signed 17 May 2024. Requirements moved to 30 June 2026 by SB25B-004, signed 28 August 2025. Since 27 April 2026, a US District Court order bars the attorney general from initiating enforcement until rulemaking concludes and the court rules in X.AI LLC v. Weiser. |
| Colorado SB26-189, Automated Decision-Making Technology | Repeals and reenacts the same part of Colorado law around automated decision-making technology. The enacted text mentions neither the NIST AI RMF nor a framework-based defense. | Signed 14 May 2026. Most provisions take effect on 1 January 2027 and apply to consequential decisions made from that date. |
In Texas, substantial compliance with the Generative AI Profile has conditioned a statutory defense since 1 January 2026, and that compliance is shown with records, not with a policy.
In Colorado, the statutory reference to the AI RMF does not survive the reenactment that takes effect on 1 January 2027, and a court-approved stay has suspended enforcement of the 2024 text since 27 April 2026. Guides that still present the Colorado act as a NIST safe harbor describe a text on its way out.
In both states, the durable asset is the same: records that show what the system did, under which rule, approved by whom.
This is not legal advice. Whether a statute applies to a given system is a question for counsel.
90 days on one workflow, function by function.
We install the framework on one workflow already in production, then extend it. Each block closes on artefacts, and each artefact answers named subcategories.
- 01
Days 1 to 30 · GOVERN and MAP
Register and classify the use cases, name the accountable executive and the AI risk owner, sign the decision rights table and write the instructions for use of the first workflow.
Evidence: use-case register (GOVERN 1.6, MAP 1.1), signed decision rights (GOVERN 2.1, GOVERN 2.3), instructions for use (MAP 2.2), gap list against the 15 controls.
- 02
Days 31 to 60 · MEASURE and MANAGE
Turn the policies into code, give each agent its identity and scope, start the chained trail and run the first kill switch drill.
Evidence: policy repository (GOVERN 1.4), agent register (GOVERN 1.6), live trail (MEASURE 2.4), drill record with measured halt time (MANAGE 2.4).
- 03
Days 61 to 90 · Profiles and reporting
Train and name the verifiers, run the weekly cadence, issue the first board pack from the trail, and read the maturity level as a NIST Current Profile with a dated Target Profile.
Evidence: dated literacy records (GOVERN 2.2), first board pack (GOVERN 2.3), Current and Target Profiles (AI 100-1, section 6).
The 90 days and the maturity levels are those of the governance framework, sections 7 and 8. Transfer to the client team depends on the transfer plan, not on the 90 days.
The questions buyers ask about the NIST AI RMF.
Is the NIST AI RMF mandatory?
No. NIST states that the AI RMF is intended for voluntary use, and the framework carries no penalty of its own. It gains legal weight through laws that name it: since 1 January 2026, one of the Texas liability defenses requires substantial compliance with its Generative AI Profile or another recognized framework. Colorado's 2024 reference to it disappears with the reenacted law that takes effect on 1 January 2027.
Where does a NIST AI RMF implementation start?
With an inventory and one workflow already in production. GOVERN 1.6 asks for an inventory of AI systems and MAP 1.1 for their documented purpose and context; a use-case register with a signed classification answers both. Install the controls on that workflow, keep evidence from its first action, then extend workflow by workflow.
How long does an implementation take?
On one workflow already in production, our adoption path runs 90 days in 3 blocks, each closed on artefacts. Extending it depends on the number of workflows and their risk class, not on the framework.
Can an organization be certified against the NIST AI RMF?
NIST AI 100-1 contains no certification scheme, and NIST writes that its actions do not constitute a checklist. Organizations that need a certificate use ISO/IEC 42001:2023, a management-system standard; the NIST AI Resource Center lists a crosswalk between the two. The same records serve both.
How does the NIST AI RMF relate to the EU AI Act?
The AI RMF is a voluntary framework of outcomes; the EU AI Act is law, with operational duties on deployers. Each of the 15 controls carries both: this crosswalk names its NIST subcategories, and the governance framework names its AI Act articles. One record answers both.
Does the NIST AI RMF cover AI agents?
Not by name. NIST AI 100-1 does not use the word agent, and the Generative AI Profile mentions autonomous agents once, as a security threat to assess. The outcomes still apply: MANAGE 2.4 asks for a way to deactivate a system and MEASURE 2.8 for accountability. Agent identity, tool scope and a per-agent stop path are how a deployer meets them.
Reference documents and primary sources.
Every date and status on this page comes from the sources below, read on 21 October 2026.
Reference documents
- Enterprise AI Governance Framework v1.0 15 controls with owners, cadences, evidence and EU AI Act hooks. CC BY 4.0.
- AI governance Why governance is architecture: policy engine, human oversight loop, audit trail.
- AI Operating Layer Reference Architecture v1.0 4 planes, 4 testable controls and the 9-field record.
- KILLSWITCH by Hikari Blue · Time to Stop Definition and method for timing a stop, in a tabletop Kill Switch Drill.
- The US does not have an AI Act. It has regulators. Briefing of 16 August 2026 on the US regulatory mosaic: NIST, Colorado, sector regulators, the FTC.
Primary sources, consulted on 21 October 2026
- NIST AI 100-1 · Artificial Intelligence Risk Management Framework (AI RMF 1.0) (opens in a new tab) NIST, January 2023. Tables 1 to 4: functions, categories and subcategories. PDF.
- NIST · AI Risk Management Framework (opens in a new tab) Release dates, voluntary use, revision under the White House AI Action Plan.
- NIST AI 600-1 · Generative Artificial Intelligence Profile (opens in a new tab) NIST, July 2024. 12 risks and suggested actions per subcategory, MANAGE 2.4 included. PDF.
- NIST AI Resource Center · AI RMF Playbook (opens in a new tab) Suggested actions per subcategory, voluntary, updated about twice a year.
- NIST AI Resource Center · Crosswalks (opens in a new tab) Crosswalks between the AI RMF and other frameworks, ISO/IEC 42001 included.
- Texas Legislature Online · HB 149, enrolled text (opens in a new tab) Sections 552.101 to 552.105 of the Business and Commerce Code, and the effective date.
- Texas Legislature Online · HB 149, bill history (opens in a new tab) Signed 22 June 2025, effective 1 January 2026.
- Colorado General Assembly · SB24-205 (opens in a new tab) Signed 17 May 2024; sections 6-1-1703(2) and 6-1-1706(3) of the final act.
- Colorado General Assembly · SB25B-004 (opens in a new tab) Signed 28 August 2025; requirements of SB24-205 moved to 30 June 2026.
- Colorado General Assembly · SB26-189 (opens in a new tab) Signed 14 May 2026; final act, section 5 on effective dates.
- Colorado Legislative Council Staff · SB26-189, final fiscal note (opens in a new tab) 8 September 2026. The court order of 27 April 2026 and the effective dates. PDF.
Map one workflow onto the NIST AI RMF.
30 minutes with a named partner. We place one workflow you already run against the 15 controls and the NIST subcategories they serve, and show which evidence exists today and which is missing. You leave with the map, whether or not we ever work together.
- One workflow you already run, mapped to NIST subcategories
- The evidence that exists today, and what is missing
- Who should own each gap