NIST AI RMF revision: what the AI Action Plan changes

NIST is revising AI RMF 1.0 under the White House AI Action Plan, but has not published a revised version. Here is what that means for your program and the laws that cite it.

On this page

NIST AI RMF revision: where it stands and what changes for you

If a contract, customer questionnaire or state law names the NIST AI RMF, the first question is which version it means. As of 17 October 2026, NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan, and no revised version has been published. NIST gives no revision timeline, so you cannot plan around a date it has not stated. Until a revised text appears, the only published version you can point to is AI RMF 1.0, NIST AI 100-1, dated January 2023.

The revision matters most where a law or contract cites the latest version rather than a fixed one. Texas and Montana both point to the most recent or latest text, so a revised NIST document would become the reference point under those laws without any change to the statute. Review each clause that names the framework, record the exact version you assessed against, and note the date. Ask your counsel or the customer to state whether a later revision would apply to your obligations.

Your organization owns its control choices, including which categories and subcategories it adopts and how it documents them. An implementation partner such as DeployOpen can help prepare systems, records and evidence, but NIST does not validate or endorse any organization's use of the framework, and no certification exists. Only an independent assessor, or the party named in your contract, judges conformance to a given version. Confirm with that party which version it will test against before you start.

What the AI Action Plan asked NIST to remove

America's AI Action Plan, published in July 2025, recommends that the Department of Commerce, acting through NIST, revise the AI RMF to eliminate references to misinformation, diversity, equity and inclusion, and climate change. For a program team, the practical point is that the revision targets specific wording in the framework's text, not its four functions or its approach to risk. The plan names the topics to remove, but it does not say which sentences, subcategories or suggested actions will change or how. Read the recommendation as a direction of travel, not as a published edit.

The diversity, equity and inclusion request bears most directly on GOVERN 3, the category on workforce diversity, equity, inclusion and accessibility, which covers team composition for AI risk decisions and the definition of human roles in human-AI configurations and oversight. Some of that category's language may be narrowed or reworded, while the underlying questions about who reviews AI risk decisions and how human oversight is defined remain part of an accountable program. Your governance records should show who makes and reviews AI risk decisions regardless of how the category text reads.

No revised text has been published, so the exact wording changes cannot be known. NIST's AI RMF page says the framework is being revised and lists no revised version. Ask your legal and compliance team to identify which of your internal policies quote or cite AI RMF 1.0 language, including GOVERN 3 references, so those passages can be checked quickly when a draft appears. When a draft is released, compare it line by line with the 1.0 text in NIST AI 100-1 before changing internal policy, and record which changes you adopt and why.

How AI RMF versions are numbered and when the next review is due

NIST AI 100-1 uses a two-number version scheme and commits NIST to a formal community review no later than 2028. Together these two facts tell you which text a contract or policy points to and how long a citation to the current version may stay accurate.

Major revisions move the first number

The first number in an AI RMF label changes only for major revisions, which is why the current text is 1.0. A major revision signals that the structure or core content may have changed, not just wording. Check whether your AI policies name 1.0 explicitly or refer to the framework generically, because a generic reference can silently point to a later major version when NIST publishes one.

Minor revisions add a decimal

A minor revision adds a decimal, such as 1.1, and is the label NIST would use for a narrower update. Minor changes can still alter subcategory wording that your control mapping depends on. Ask your team to record the exact version and date each time a policy, audit response or vendor questionnaire cites the framework, so a later minor release can be reviewed rather than assumed harmless.

Formal review due by 2028

NIST expects a formal review of the framework with input from the AI community no later than 2028. The review is the stated point at which changes are expected to be assessed in a structured way, separate from the current revision under the AI Action Plan. Put a review date in your AI governance calendar and confirm with NIST's AI Risk Management Framework page whether the review has been scheduled earlier.

Version labels in contract clauses

A contract that says the vendor will follow the NIST AI RMF should name the version, the publication date and the NIST AI 100-1 identifier. Without that, a later revision could change what the vendor has promised. Ask counterparties whether they will accept an update clause that moves to a newer version only after both parties review it in writing.

Policy text that cites a version

An internal AI policy that cites the framework should state the version it was written against and name who reviews the citation when NIST publishes a revision. Map each policy section to subcategory numbers in that version. Because the Playbook has not had a content update since August 2023, check whether any Playbook suggestion you rely on still matches the version you cite.

What happens to the Playbook, the Generative AI Profile and other profiles

The NIST AI RMF Playbook is the voluntary online companion to AI RMF 1.0. It offers suggested actions, documentation prompts and references for each subcategory. NIST says the Playbook is neither a checklist nor a set of steps, so it should be read as material to adapt, not as a test to pass. The Playbook is also the artifact most affected by the timing of the revision, because it has not been refreshed since the framework's first release cycle.

  • Last content update: The Playbook's audit log shows its last content update in August 2023.
  • Stated plan: The AI RMF Resource Center (AIRC) says the Playbook will be updated after the AI RMF is revised.
  • Content to expect changes: Suggested actions that reference the topics named in the AI Action Plan may be reworded or removed once the framework changes.
  • Your working copy: Keep a dated copy of the Playbook entries you map to your program, so you can show which version of the guidance you followed.
  • No substitute for the framework text: Treat Playbook suggestions as optional aids that support the framework's categories and subcategories.

Before relying on any Playbook entry in a customer or regulatory response, check the audit log for the current last-update date and confirm with NIST AIRC whether a revised Playbook has been published.

Why laws that cite the latest version make the revision matter

A revised NIST text would become the reference point under both Texas and Montana law, because Texas Section 552.105(e) refers to the most recent version of the NIST Generative AI Profile and Montana Code 2-10-205 refers to the latest version of the NIST AI Risk Management Framework. Neither provision, as supplied, names 1.0 as the text to follow. That matters for any organization that wrote its program against AI RMF 1.0 or AI 600-1 and treated those documents as fixed. Once NIST publishes a revised version, a 'latest version' reference could point to text the organization has not yet mapped its controls against.

The practical first step is to read each law's wording on its own terms. For each statute your organization relies on, confirm whether the language ties to a named version or to 'latest,' and record the date on which your evidence was assessed. If the reference is to 'latest,' plan for a crosswalk from your existing AI RMF 1.0 documentation to the revised subcategory numbering, and check whether NIST publishes a crosswalk of its own through its AIRC crosswalk documents. If NIST has not yet published a revised version, the reader should confirm its status directly with NIST before drafting a mapping, because the October 2026 page gives no revision timeline.

Whether a regulator or court would treat a crosswalk as sufficient is a question for counsel and the relevant attorney general, not something this page can answer. For what each statute requires, read the separate guides on the Texas TRAIGA liability defense and the Montana Right to Compute Act, which cover the duties, the investigation process and the penalties in detail. The decision to make now is whether your evidence set is organized so that a version change can be traced, not whether a revision has already changed your obligations.

What to do while the revision is pending

This sequence gives a compliance lead a record of every AI RMF reference the organization relies on, a documented version position, and a tested path for handling a revised text when NIST publishes one. It keeps the program defensible while the 1.0 text is still the only published version.

  1. Inventory every AI RMF reference

    Search contracts, security questionnaires, internal policies, AI governance charters and state-law obligations for every mention of the AI Risk Management Framework, the Generative AI Profile and the Playbook. Record the clause or document, the exact wording used (for example, whether it says "most recent version" or names 1.0), and the party that requires it. The output is a version register with one row per reference. The step is done when a second reviewer has checked the register against the source documents and found no unlisted reference.

  2. Decide and document the cited version

    Decide which published version your program will cite, based on the wording of each reference and what your customers and counsel have accepted. Record the decision in a short version statement that names AI RMF 1.0 (NIST AI 100-1, January 2023), any profile used, and the date the decision was made and approved. Owners of the statement are the compliance lead and an accountable executive. The step is done when the statement is approved and linked from the version register.

  3. Map existing evidence to 1.0 numbering

    Build a mapping workbook that links each piece of evidence (policies, risk registers, test records, monitoring reports, incident logs, training records) to the AI RMF 1.0 category and subcategory it supports. Use the subcategory numbers from the four Core tables in NIST AI 100-1 and the suggested actions in the Playbook as reference points, and note where a subcategory has no current evidence. Because profiles published so far map to the 1.0 numbering, the workbook can support those profiles too. The step is done when every subcategory your scope claims has an evidence owner and a gap list.

  4. Track NIST sources and log each check

    Monitor NIST's AI RMF page, the AIRC announcements and the Playbook audit log on a fixed schedule set by the compliance lead. For each check, record the date, the source, what it showed (for example, no revised version listed or a new draft posted) and who reviewed it. The Playbook audit log is useful here because it shows when the Playbook content last changed. The output is a monitoring log that proves the organization was watching the source. The step is done when the first entries are recorded and the schedule is assigned to a named owner.

  5. Agree how a revised text will be handled

    Meet with counsel and, where contracts require it, the customers who named the framework to agree how a revised text would be treated. Cover whether the organization would adopt the new version, keep citing 1.0 for a stated period, or report the change in writing, and who has authority to decide. Record the agreed position in the version statement and in any customer correspondence that requires it. The step is done when counsel has reviewed the position and any contract language that needs a change has been identified.

  6. Schedule review on any draft or final text

    Set a trigger for a formal review when NIST publishes a draft or final revised AI RMF text, or a revised Playbook, and assign the review to the mapping owners. The review compares the new numbering and content against the workbook, updates the version register, and states which evidence moves, changes or needs new work. The output is a dated review memo with a decision on adoption. Because AI 100-1 says NIST expects a formal review no later than 2028, the trigger should also be reviewed at each monitoring cycle. The step is done when the trigger is documented and the first review memo template is approved.

What usually goes wrong when a framework revision is pending

A pending revision tempts teams to pause, to cite moving targets, or to lean on stale companion material. The mistakes below share one root cause: treating unpublished or unsettled text as if it were final, or as if it were nothing at all.

Pausing the program during revision

Some teams freeze their AI RMF work until NIST publishes a revised version. NIST's AI RMF page says AI RMF 1.0 is being revised as part of the White House AI Action Plan, but it gives no revision timeline and lists no revised version as of October 2026. Governance, inventory and measurement work built on the 1.0 categories and subcategories still applies today. Keep the program running, log what changes when a revision appears, and map each control to its 1.0 identifier so that updates are a mapping exercise rather than a restart.

Citing the latest version without a version

Contracts and policies often say the program follows the *latest version* of the NIST AI RMF. Without a named version and date, the reference shifts as NIST publishes changes, and nobody can tell which text a customer or assessor expected. Name the exact document, its publication date and the version number, such as NIST AI 100-1 (AI RMF 1.0, January 2023), and state how later versions will be handled. Ask counsel whether the clause should trigger a review, an amendment or nothing at all.

Treating the Playbook as current guidance

The Playbook supplies suggested actions and documentation prompts for each subcategory, but its audit log shows the last content update in August 2023. AIRC has said it will update the Playbook after the AI RMF is revised. Teams that copy Playbook actions into an audit file present outdated wording as current guidance. Date every Playbook reference, note that it predates any revision, and record which suggested actions your organization adopted, adapted or set aside.

Removing controls based on recommended text

America's AI Action Plan (July 2025) recommends that NIST revise the framework to eliminate references to misinformation, diversity, equity and inclusion, and climate change. A recommendation is not a published revision. Teams that delete subcategories or evidence on that basis may lose controls that customers, laws or internal risk policies still require. Keep current 1.0 items in place, record the Action Plan recommendation as a pending change, and confirm with NIST and counsel before any removal is final.

Losing track of the cited version

A revision changes the reference point for laws that cite the latest version, including Texas Section 552.105(e) for the NIST Generative AI Profile and Montana Code 2-10-205 for the AI RMF. If the program does not record which version it followed, it cannot show what it measured when a regulator or investigator asks. Keep a version register that lists each framework document, its version, the date adopted, the owner and the subcategory numbers the evidence supports. Review the register whenever NIST announces a change.

Questions buyers ask about the NIST AI RMF revision

Is there a revised AI RMF yet and when is it due?

No. As of 17 October 2026, NIST has not published a revised version of AI RMF 1.0, and its AI RMF page gives no revision timeline. NIST says the framework is being revised as part of the White House AI Action Plan. The outer date comes from NIST AI 100-1 itself, which expects a formal review with input from the AI community no later than 2028. Until a revised text is published, the January 2023 version is the only one a contract or policy can cite by its number. Check NIST's page before you write a version into a policy or customer questionnaire, because a draft or final text will appear there first.

Does the revision make AI RMF 1.0 invalid?

No. The revision does not make 1.0 invalid, because the framework was never something organizations are required to use. NIST's FAQ states that neither private nor public sector organizations must adopt it, and there is no AI RMF certification, so no body issues a pass or fail against 1.0 or any later version. The practical question is which version your contract, customer questionnaire or law names. Some laws point to whichever version is latest. Texas Section 552.105(e) refers to the most recent version of the NIST Generative AI Profile, and Montana Code 2-10-205 refers to the latest version of the AI RMF, so a revised text would become the reference point under both. Record the framework version, the date and the subcategory numbers you used in every mapping.

Do we have to re-assess our AI program now?

Your organization decides whether and when to reassess. The AI RMF is voluntary, and the supplied facts do not tie any regulator's deadline to the revision. Confirm what each customer, contract and regulator accepts today. If a customer asks for a current assessment, its credibility depends on the assessor. An independent auditor or assessor judges any formal assessment and issues any report. An implementation partner can prepare the program, the mapping and the evidence, but it does not sign off. A practical approach is to keep your current mapping, flag the subcategories touched by the references the AI Action Plan asks NIST to remove, and set a review trigger tied to NIST publishing a revised draft. Document that decision and its reasoning, since the record is evidence in its own right under GOVERN 1.

Who pays for re-mapping to a revised AI RMF and how much?

Your organization pays for its own staff time, and any outside help is paid under a written scope. The supplied facts give no figure for re-mapping, so no price or duration can be stated here. Effort is driven by three factors: how many of the 72 subcategories you map, how much evidence sits behind each one, and how many AI systems and business units are in scope. Mapping one system is a different job from mapping a portfolio of vendor and in-house models. The first mapping is a one-time cost, while updates for each revision cycle and each change in scope recur. Ask any provider for a quote that lists deliverables by function (Govern, Map, Measure and Manage), the systems covered, the evidence to be prepared, and how changes to subcategory wording would be handled.

Can our own team re-map the AI RMF without outside help?

Yes. The AI RMF is voluntary and designed for the organization to apply itself, and NIST's Playbook offers suggested actions and documentation prompts for each subcategory. Your team owns the decisions: risk tolerance, go or no-go determinations, accountability assignments and acceptance of residual risk under GOVERN 2 and MANAGE 1. Staff who know the AI systems should own the MAP and MEASURE evidence, while legal, privacy and security owners confirm the obligations that apply. Outside help is most useful for a gap review, a second check on evidence quality, or preparing systems for an independent assessment. The Playbook's audit log shows its last content update in August 2023, so record the Playbook version you used alongside your mapping.

Does DeployOpen certify us against the NIST AI RMF?

No. DeployOpen does not certify, accredit or endorse any organization against the NIST AI RMF, and no AI RMF certificate exists to issue. DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, and it prepares systems, controls and evidence for compliance assessments. Only an independent auditor, assessor or certification body issues reports, and NIST does not validate any organization's approach. For illustration, a fixed-scope engagement might cover a system inventory, evidence collection for selected subcategories, and documentation for AI systems in scope, with scope, deliverables and timelines agreed in writing before work starts. Ask any partner, including DeployOpen, which parts of the work they perform and who signs off the result.

What happens to the Playbook and Generative AI Profile after the revision?

The Playbook is expected to change after the framework does, and the profiles will need a check against any new numbering. The supplied facts say AIRC will update the Playbook after the AI RMF is revised. NIST says the profiles published so far, including NIST AI 600-1 published July 26, 2024, map to AI RMF 1.0 subcategory numbering. NIST developed AI 600-1 under Section 4.1(a)(i)(A) of Executive Order 14110, which Executive Order 14148 revoked on January 20, 2025, yet NIST still lists the profile on its AI RMF page as of October 2026. Until revised text appears, existing cross-references remain valid. When it does, expect possible renumbering or rewording, so record the profile version next to the framework version and review every cross-reference against the new text.

How DeployOpen works on this

DeployOpen helps organizations prepare for a revised AI RMF by scoping, building and documenting the AI risk management evidence they already produce, so their program can be mapped to whichever version of the framework their contracts or laws cite. DeployOpen does not issue attestations or certifications, and the organization keeps ownership of its risk decisions.

How we scope

  • Written scope names the AI systems, business units and NIST AI RMF categories included before work starts.
  • Scope records which AI RMF 1.0 subcategory numbering your current program and profiles reference.
  • Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.

How we build

  • We configure self-hosted open-source platforms in your own infrastructure to produce AI inventory, risk and monitoring records.
  • We map existing policies and records to AI RMF subcategories, flagging gaps for your teams to resolve.
  • We test the evidence pipeline, including access controls and logging, so records remain reliable if the framework text changes.

How we hand over

  • Documentation covers each in-scope subcategory, the evidence location, the owner and the review date.
  • Handover includes a change log that shows which version references each control, so revisions can be tracked.
  • Your staff receive training on operating the platforms and maintaining evidence without ongoing dependence on us.

How we support

  • Ongoing support, upgrades and continuous testing are available as a retainer after handover.
  • A retainer can include review of the NIST AI RMF revision once NIST publishes a revised text.
  • Confirm with your auditor or assessor which framework version they will accept before you finalize the scope.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.