How to Implement the NIST AI RMF | The Four Core Functions

What Is the NIST AI Risk Management Framework?

The NIST AI Risk Management Framework (AI RMF) is voluntary guidance from the U.S. National Institute of Standards and Technology, created at Congress's direction, that helps organizations manage AI system risks and promote trustworthy use. It is designed to work across sectors, organization sizes, and AI use cases. NIST released version 1.0 in January 2023.

AI RMF 1.0 (NIST AI 100-1) at a glance

The U.S. National Institute of Standards and Technology released AI RMF 1.0 on January 26, 2023, as publication NIST AI 100-1. It gives organizations that design, develop, deploy, or use AI a practical way to manage AI risk and build trustworthiness into those systems. Congress directed NIST to produce it through the National Artificial Intelligence Initiative Act of 2020.

The document has two parts: background on AI risk and trustworthiness, followed by the core, which is the four functions of Govern, Map, Measure, and Manage. NIST also publishes a companion Playbook, Roadmap, and Crosswalk.

The development process was unusually broad. NIST spent more than 18 months drafting and received about 400 sets of formal comments from over 240 organizations. That breadth is one reason industry treats the framework as a common reference point.

Is the NIST AI RMF mandatory or voluntary?

The NIST AI RMF is voluntary. NIST describes it as voluntary guidance, and it does not create a legal obligation for private organizations.

Voluntary does not mean consequence-free, though. Colorado's AI Act gives developers and deployers an affirmative defense for following a recognized AI risk management framework, and it ties a presumption of reasonable care to compliance with the NIST AI RMF or ISO 42001. Coverage of Texas's AI law describes a similar defense for organizations that adhere to the NIST framework. Colorado's timeline has been unstable. A federal court paused enforcement in April 2026 while lawmakers considered amendments, so confirm the current status with counsel before relying on that defense.

Who should use the NIST AI RMF?

Any organization that builds, deploys, or buys AI systems can use it. NIST positions the framework for organizations of all sizes and in all sectors. The value differs by role.

Developers and model teams lean on Map and Measure to document intended use, known limitations, and test results before release. Deployers, such as a fintech adding an LLM assistant to its customer app, rely more on Govern and Manage to assign ownership, set usage limits, and monitor the system after launch. Regulated sectors such as financial services, healthcare, and critical infrastructure use it as a defensible method when regulators, auditors, or boards ask how they control AI risk. NIST's April 2026 concept note for a critical infrastructure profile points to more sector-specific guidance.

Vendors answering procurement questionnaires use the framework as the structure for their replies. Be precise there: describe your practices as aligned with or mapped to the framework, not certified against it.

NIST AI RMF vs NIST RMF (SP 800-37): the naming confusion

These are two different documents for two different jobs. The AI RMF manages the risks that AI systems pose to people, organizations, and society. The NIST Risk Management Framework in SP 800-37 Rev. 2 is a seven-step lifecycle federal agencies and contractors use to categorize systems, select and implement controls, and obtain a formal authorization to operate.

Both are abbreviated "RMF," so searches often return the wrong one. If a contract mentions an authorization to operate, it means the SP 800-37 process. An AI system running inside a federal environment can fall under both.

NIST AI, AI RMF, and NIST AI framework: which document people mean

In almost every case, all three phrases point to AI RMF 1.0 (NIST AI 100-1). "AI RMF" is simply the shorthand. "NIST AI" more broadly refers to NIST's AI program and its Trustworthy and Responsible AI Resource Center, and "NIST AI framework" is sometimes used for companion documents rather than the framework itself.

The companions are separate publications with their own IDs: the Generative AI Profile (NIST AI 600-1), released July 26, 2024, the Playbook, and NIST's adversarial machine learning taxonomy (AI 100-2). When a source cites a document, check the ID and date. NIST says AI RMF 1.0 is being revised, and I couldn't find an official successor name. Treat any "AI RMF 2.0" label as unofficial until NIST uses it.

Why the NIST AI RMF Matters

The NIST AI RMF matters because AI systems can fail in ways traditional software controls were not built to catch. It also gives customers, boards, and regulators a recognized yardstick for judging whether those failures are managed. It supplies a shared vocabulary and a defensible method for managing AI risk without prescribing specific technology.

How AI risk differs from traditional software risk

AI risk differs because an AI system's behavior comes from training data and statistical patterns rather than fixed rules. It can fail without any code defect, change after deployment, and resist exhaustive testing. Traditional software does what its code says, so testing the code largely tests the system.

A fraud-scoring model, for example, can pass every pre-release test and then degrade quietly as attacker behavior drifts away from its training data. A language model can be steered by crafted input, such as prompt injection, without exploiting any conventional vulnerability. AI systems can also leak training data, produce biased outcomes, or make decisions no one can easily explain. None of those are bugs in the usual sense.

Classic security still matters, though. IBM's 2026 Cost of a Data Breach Report found that the most common causes of AI-related breaches were weaknesses around the AI system, such as compromised APIs, plug-ins, and cloud misconfigurations, rather than flaws in the models themselves. That mix is why the AI RMF has continuous Measure and Manage functions instead of a one-time pre-launch review.

Why procurement teams, boards and regulators ask for AI RMF alignment

They ask because the framework is the most widely recognized shorthand for "this organization manages AI risk deliberately." It gives each audience something concrete to check.

Procurement teams, especially in banks and other regulated buyers, increasingly add AI questions to vendor security reviews, and a mapped answer is easier to defend than an ad hoc one. Boards need to know who owns AI risk and what evidence exists that it is controlled, which is what the Govern function is built to produce. The gap is common: IBM's 2026 report found that 68% of breached organizations lacked policies to oversee AI use or manage shadow AI.

Regulators come at it from the legal side. No single global AI law exists, so voluntary frameworks often serve as the reference point. Colorado's AI Act, for example, gives an affirmative defense for following a recognized framework and ties a presumption of reasonable care to the NIST AI RMF or ISO 42001. NIST also publishes a Crosswalk to help organizations connect the framework to other standards and laws. That lets teams already working under ISO 42001 or EU AI Act obligations reuse their work instead of building a separate program for each.

The Four Core Functions: Govern, Map, Measure, Manage

The AI RMF Core has four functions: Govern, Map, Measure, and Manage. Govern sets the policies, accountability, and risk tolerance that apply across the organization. Map defines each AI system's context and risks, Measure tests and tracks those risks, and Manage prioritizes and treats them. NIST's structure treats Govern as cross-cutting. Map, Measure, and Manage are applied iteratively across the AI lifecycle, so they form a loop, not a one-time checklist.

Summary table: function → purpose → example outputs

Each function answers a different question, and the earlier ones feed the later ones. The outputs below are illustrative artifacts teams commonly produce. NIST doesn't mandate these specific documents.

Govern: accountability, human oversight, and the AI risk register

Govern establishes who is accountable for AI risk and what the organization is willing to tolerate. It is the only function that spans the whole organization, which is why NIST positions it above Map, Measure, and Manage.

In practice, it produces named owners, an AI policy, and an inventory of AI systems. The first category covers understanding legal and regulatory requirements. It sets human oversight as policy and then applies it per system. A Map subcategory requires oversight processes to be defined, assessed, and documented in line with Govern policies.

NIST doesn't prescribe a risk register format, but a register is the most practical way to evidence Govern outcomes. Each entry would typically hold the system, the risk, the owner, the tolerance, the treatment, and a review date.

Map: context, intended use, and impact identification

Map establishes what an AI system is for, who it affects, and what could go wrong before anyone measures anything. NIST states that Map outcomes are the basis for Measure and Manage, so weak mapping weakens everything downstream.

Teams document the system's purpose, intended users, expected benefits and costs, and known limits. The five Map categories also cover categorizing the system and understanding impacts on individuals, groups, and society. One subcategory calls for documenting the likelihood and magnitude of those impacts. A customer-facing LLM assistant at a fintech, for instance, would be mapped for misleading financial answers, data leakage, and prompt manipulation, not just for accuracy.

Measure: reliability metrics, testing, and evaluation

Measure tests AI systems before deployment and throughout operation, using the risks identified in Map as its targets. It turns risks into numbers or structured judgments that can be tracked.

Evaluate valid and reliable behavior across the Measure categories, and cover fairness and bias evaluation in a dedicated subcategory. Typical metrics include accuracy and error rates by user group, drift against a baseline, and, for language models, the rate of unsupported answers. Security evidence belongs here too. Adversarial testing such as red teaming shows how a system behaves under attack, which functional testing can't show. Whatever the method, define the metric and threshold in advance so results can trigger a decision.

Manage: prioritization, mitigation, and monitoring

Manage allocates resources to the risks that Map and Measure surfaced, then keeps watching after release. Its first category covers prioritizing identified risks and responding appropriately. Common response options include mitigating, transferring, avoiding, or accepting a risk, with the decision documented.

Manage also covers life after launch. One subcategory calls for post-deployment monitoring, appeal and override mechanisms, change management, and decommissioning. This is where an incident response plan for AI failures belongs, covering who is notified, who can switch the system off, and what evidence is kept.

Categories and subcategories

The AI RMF Core contains 19 categories and 72 subcategories across its four functions, laid out in Tables 1 through 4 of NIST AI 100-1. Categories are numbered by function (GOVERN 1, MAP 2), and subcategories add a decimal (GOVERN 1.1).

NIST intends the subcategories to be tailored, not applied all at once. Prioritize them by system, lifecycle stage, and risk tolerance. The Playbook adds suggested actions for each.

The Seven Characteristics of Trustworthy AI

NIST names seven characteristics of trustworthy AI: valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. Valid and reliable is the base the others rest on. Accountability and transparency relate to all of the rest. How much each one matters depends on the system's context of use.

Table of the seven characteristics, each with a plain-English test and an example failure

Each characteristic below has a one-line test you can ask about a system and an illustrative failure. The tests and examples are hypothetical teaching aids, not NIST text.

NIST treats validity and reliability as necessary conditions of trustworthiness and uses them as the foundation. It defines validity as performing properly for the intended use, confirmed with objective evidence, and reliability as performing without failure over time under given conditions. NIST also makes clear that a system strong in one characteristic isn't trustworthy by default. Highly secure but unfair systems, accurate but opaque ones, and inaccurate but secure and transparent ones are all undesirable.

Trade-offs between characteristics

The characteristics can pull against each other, and NIST says managing that tension is part of the work. It states that trade-offs are usually involved, that all characteristics rarely apply in every setting, and that some will matter more or less in any given situation. One example is the tension between interpretability and privacy. It also notes that privacy-enhancing technologies and data minimization can reduce privacy risk, but they may affect other characteristics such as accuracy.

Practitioners often add a familiar one: a simpler model is easier to explain, but a more complex one may be more accurate. NIST doesn't use that example, but it follows the same logic. The fix is to decide deliberately per system and write the decision down. A lender making credit decisions may favor explainability, because reasons often have to be given to applicants. A spam filter can lean toward accuracy, because no one needs a per-message explanation. That decision belongs in the Map and Govern outputs: the context that justifies it, the owner who accepted it, and the tolerance it was measured against.

NIST AI RMF Playbook, Roadmap, Crosswalk, and Resource Center

NIST publishes several free companion resources alongside the AI RMF. The Playbook suggests actions for each subcategory, the Roadmap outlines how NIST plans to advance the framework, and the Crosswalks relate it to other standards. The Trustworthy and Responsible AI Resource Center hosts them. All are voluntary, and NIST says it is revising the framework behind them.

What the Playbook contains and how to use it

The Playbook provides suggested actions to achieve each outcome in the AI RMF Core, aligned to every subcategory across Govern, Map, Measure, and Manage. Alongside the actions, each entry carries transparency and documentation guidance and references for further reading. NIST states that the Playbook is neither a checklist nor a set of steps to follow in full. Organizations can borrow as many or as few suggestions as fit their use case.

That voluntary design means you need your own method for using it. A workable one runs in four steps:

1. Start with Govern, since its outcomes support the other three functions.

2. Pick the subcategories that match the risks you identified for a given system.

3. For each one, choose the suggested actions you can actually carry out and record an owner, the evidence produced, and a review date.

4. Use the transparency and documentation notes as your evidence list, so an auditor or procurement team can see what exists.

Treat the references as a literature sample, not a definitive source list, because NIST describes them that way and says the suggested actions are not meant to be comprehensive.

Check how current your copy is. NIST's Playbook FAQ now says the Playbook will be updated after the AI RMF revision, so don't assume the older "roughly twice a year" update rhythm still applies.

Official downloads (link out to NIST; no mirrored PDFs)

Always download the AI RMF and its companions directly from NIST. A mirrored copy of AI RMF 1.0 can go stale once NIST publishes its revision, and a citation to your own copy is a weaker source than a citation to NIST. NIST's AI RMF page also lists the other companions: the Roadmap, which sets out initiatives NIST hopes the community will advance independently or with the agency; Crosswalks, which relate the framework to other standards and documents; and Perspectives, which are statements of support from organizations. NIST launched the Resource Center on March 30, 2023, to support implementation and international alignment, and it also collects use cases showing how other organizations apply the framework.

• AI RMF 1.0 (NIST AI 100-1): doi.org/10.6028/NIST.AI.100-1

• AI RMF Playbook: airc.nist.gov/airmf-resources/playbook

• NIST AI RMF program page (Roadmap, Crosswalks, Perspectives, and the latest status notes): nist.gov/itl/ai-risk-management-framework

• Trustworthy and Responsible AI Resource Center: airc.nist.gov

The Generative AI Profile (NIST AI 600-1)

NIST AI 600-1, the Generative AI Profile, is a companion to the AI RMF that NIST finalized on July 26, 2024. It applies the framework's Govern, Map, Measure, and Manage structure to generative AI by identifying 12 risks unique to the technology or made worse by it. It then pairs those risks with suggested actions. Like the AI RMF itself, it is voluntary.

Risks the profile adds for generative AI

The profile identifies 12 risks that generative AI creates or intensifies: CBRN information or capabilities, confabulation, dangerous, violent, or hateful content, data privacy, environmental impacts, harmful bias and homogenization, human-AI configuration, information integrity, information security, intellectual property, obscene, degrading, or abusive content, and value chain and component integration.

They fall into four practical groups:

• Output reliability: Confabulation is NIST's term for confident but false output, often called hallucination. Harm arises when users believe and act on it. Information integrity covers false or misleading content at scale, and harmful or abusive content covers material the model should not produce.

• Data and security: Information security includes attacks that run through language, such as prompt injection and data poisoning. Data privacy and intellectual property cover what a model memorizes, reveals, or reproduces. Value chain and component integration covers the risk that opaque third-party models, datasets, and APIs reduce accountability and spread errors downstream. See AI supply chain security for how to assess those dependencies.

• People and society: Human-AI configuration covers over-reliance and automation bias, such as staff approving a model's answer without checking it, which is one reason security awareness training should cover AI tools. Harmful bias and homogenization covers skewed or uniform outputs. Environmental impacts cover the energy and carbon cost of training and running large models.

• Severe misuse: CBRN information or capabilities covers the risk of a model helping someone access information on chemical, biological, radiological, or nuclear weapons.

A customer-facing LLM assistant at a fintech touches most of these at once. It can state a wrong fee, be steered by a crafted prompt, repeat another customer's data, and lean on a third-party model its owner can't inspect.

When to use the profile instead of the core framework alone

Use the profile alongside the core framework, not instead of it, whenever you build, fine-tune, or deploy generative AI. That includes LLM assistants, image or code generators, and any product that sends user input to a third-party generative model. The base functions still apply in full, and the profile adds generative-AI-specific risks and suggested actions on top. The core alone is enough for systems with no generative component, such as a classification or scoring model working on structured data.

In practice, run Govern and Map with the core framework, then use the profile's 12 risks as a screening list during Map to decide which apply to your system. Carry the matching suggested actions into Measure and Manage. Third-party model APIs deserve special attention, because the value chain risk applies even when you never trained the model. A hybrid system, such as a traditional pipeline with an LLM step inside it, should use the profile for that component only.

NIST says AI RMF 1.0 is being revised, and the profile is written against version 1.0, so check NIST's page for changes before you rely on it.

How to Implement the NIST AI RMF, Step by Step

To implement the NIST AI RMF, inventory your AI systems and name an owner for each, record risks in a register, score them by likelihood and impact, assign controls under each function, and collect test evidence. Then repeat the cycle on a schedule and whenever a system changes. NIST doesn't prescribe this exact sequence, so treat it as a practical path through the Playbook's suggestions.

Inventory AI systems and assign owners

Start with a complete list of AI systems, including third-party and unofficial tools, and assign each a named owner. You can't govern what you can't see, and the unofficial ones are a real exposure. IBM's 2025 Cost of a Data Breach Report found that one in five organizations had a breach caused by shadow AI. Attack surface management is a practical way to find AI endpoints nobody registered. The Playbook's guidance on an AI inventory points to system documentation, incident response plans, data dictionaries, links to source code or implementation software, and contact details for responsible people. A workable record also notes the purpose, the model or vendor, what data it touches, who it affects, and its lifecycle stage. The owner should be an accountable person, not a team alias, with authority to accept or reject risk for that system.

Build an AI risk register (fields, scoring, review cadence)

An AI risk register is a living table of what could go wrong with each system, how bad it would be, and who owns it. NIST doesn't mandate a format, but a register is the practical way to evidence your Govern and Manage work.

Useful fields include a risk ID, the system, a plain description, the trustworthiness characteristic affected, likelihood, impact, score, owner, existing controls, residual score, treatment decision (mitigate, transfer, avoid, or accept), status, review date, and the related AI RMF subcategory. As a starting cadence, review high-scoring risks monthly or quarterly and everything else at least annually. Also trigger an out-of-cycle review when the model, its data, or its vendor changes, after any incident, and when a relevant regulation changes.

AI risk assessment framework: scoring likelihood and impact

A simple five-point scale for likelihood and impact, multiplied together, gives you a consistent score. The Map function's impact guidance calls for documenting both the likelihood and the magnitude of potential impacts, and a scale makes that repeatable across teams.

AI risk mitigation controls by function

Controls are the actions that lower a risk score, and they map naturally to the four functions. The examples below are illustrative, not an NIST-mandated set.

Choose controls from the Playbook's suggested actions where they fit. NIST describes the Playbook as neither a checklist nor an ordered set of steps, so select what matches your risks instead of working through everything.

Where security testing and AI red teaming supply evidence for Measure

Security testing shows how a system behaves under attack, which functional testing can't show. That makes it direct evidence for the Measure function, which includes evaluating the system's security and resilience. The Generative AI Profile also treats red-teaming as a testing approach for generative systems.

A useful engagement tests realistic scenarios against the deployed system: prompt injection, data exfiltration through connected tools, jailbreaks, and agents taking actions beyond their intended scope. The output that counts as evidence is a report with scope, scenarios, severity-rated findings, reproduction steps, and retest results after fixes. Each finding should link back to a register entry, so a high-scoring risk gets a tested control and a rescore.

Femto Security AI agentic pentesting and red teaming services produce this kind of evidence, and red team vs penetration testing explains how the two approaches differ. 

The code and infrastructure around the model need the same scrutiny, through penetration testing of the application and API layer (see methods, types, and tools) and source code review of the integration code. One caution: a test is a snapshot. It supports Measure for that date and scope, and it doesn't replace monitoring under Manage.

Common mistakes(H3)

Checkbox compliance. Treating the Playbook or the framework as a list to tick off produces documents, not risk reduction. NIST states that the Playbook is not a checklist, so tie every action to a risk you've actually scored.

One-time assessments. An assessment done once at launch goes stale as models, data, prompts, and vendors change. Build the review triggers into the register and into your release process, the way a vulnerability management program rescans on a cycle instead of once.

No owner. A risk with a team name beside it, or none, doesn't get treated. Every system and every register entry needs one accountable person.

Ignoring third-party models. Your risk includes models and APIs you didn't build. Inventory them, and ask vendors what testing and controls they can provide evidence of.

Worked Example: Applying the AI RMF to a Customer-Facing LLM Assistant

This worked example applies the NIST AI RMF to a hypothetical support assistant at a fintech or crypto exchange. Map defines what the assistant may and may not do and where it could hurt customers, Measure tests the highest risks, and Manage assigns controls and monitoring. It is an illustrative scenario, not a client case, and it contains no real test results.

Map, Measure, and Manage entries for one hypothetical fintech or crypto exchange assistant

The scenario. An exchange adds an in-app assistant, built on a third-party hosted language model, that answers customers' questions about fees, deposit and withdrawal status, and account verification. It can look up the signed-in customer's own account data through a read-only tool. It cannot move funds or change account settings. Investment advice and price predictions are out of scope.

Govern comes first. A named product owner is accountable for the system and approves launch, and legal and compliance have documented the applicable regulatory requirements. The entries below assume that groundwork is done.

Map: context, limits, and risks. The Map record documents the purpose, users, data touched, boundaries, and who could be harmed. The four risks below are the ones this example follows through all three functions. They engage five of the Generative AI Profile's 12 risks: confabulation, information security, data privacy, human-AI configuration, and value chain and component integration. Scores use the 1–5 likelihood and impact scale from the previous section and reflect the scenario's assumptions. A real owner would assess their own.

Measure: how each risk gets tested. Each metric needs a threshold the system owner sets before testing, so results can trigger a decision. No thresholds are filled in here, because inventing them would imply results.

Manage: treatment, owners, and monitoring. Controls come first, then the target score after they're in place. The targets are goals, not outcomes.

A good implementation leaves evidence the owner can show: the inventory entry, these register rows, the evaluation and red-team reports, and a monitoring plan. Test results then feed back into the register, so scores move based on evidence, not assumption.

NIST AI RMF vs ISO/IEC 42001, the EU AI Act, and Other Frameworks

The NIST AI RMF is voluntary risk guidance, ISO/IEC 42001 is a certifiable management system standard, and the EU AI Act is binding law. OWASP's LLM Top 10 and MITRE ATLAS are security references for specific attack types. They complement each other. Most organizations use the AI RMF as the working method and the others as proof, legal obligation, or testing input.

Comparison table: type, certifiable?, scope, best use

NIST AI RMF vs ISO 42001

ISO/IEC 42001 is a certifiable standard, and the NIST AI RMF is not. 42001 specifies requirements for establishing, implementing, maintaining, and continually improving an AI management system. An accredited body can audit that system and issue a certificate. The AI RMF is voluntary guidance with no certification scheme, registrar, or accreditation.

The structure differs too. ISO 42001 follows the familiar management system pattern of clauses plus an Annex A set of controls, which one source counts at 38. The AI RMF supplies methodology: four functions, the Playbook, and the Generative AI Profile. 

Many organizations use the AI RMF to structure how they identify and treat AI risk, then certify the resulting system against 42001 for audited assurance. 

If you already hold ISO 27001, the shared management system structure reduces the work. The comparison in ISO 27001 vs SOC 2 vs PCI DSS shows where those certifications differ.

Choose the AI RMF when you need a free, usable method now. Choose 42001 when customers or regulators ask for an independent certificate. Many organizations do both.

One caution: ISO 42001 isn't a harmonised standard under the EU AI Act, so a certificate carries no presumption of conformity with the Act.

How it maps to EU AI Act obligations

The AI RMF can supply the working method behind several EU AI Act requirements, but it is not a route to compliance. The AI Act (Regulation (EU) 2024/1689) is binding law, and its obligations depend on how a system is classified.

For high-risk systems, the requirements around risk management, data governance, human oversight, and accuracy, robustness, and cybersecurity have natural counterparts in the AI RMF. Risk management maps to the whole Govern, Map, Measure, Manage loop. Data governance maps to Map and Measure. Human oversight maps to Govern policies and Map's oversight processes. Accuracy, robustness, and cybersecurity map to Measure and Manage. Use NIST's crosswalks for the detailed mapping and treat the AI Act's text as the authority.

Timing has shifted. The high-risk rules were due to apply from August 2, 2026. On May 7, 2026, the EU's Council and Parliament reached a provisional agreement to defer them to December 2, 2027 for standalone Annex III systems and August 2, 2028 for systems embedded in regulated products. Annex III includes credit scoring, which matters for fintech. Prohibited-practice and general-purpose AI obligations that began applying in 2025 weren't changed, and the Article 50 transparency obligations are largely unaffected. A customer-facing chatbot typically faces transparency duties, such as telling users they're talking to AI, rather than the high-risk regime, unless its use falls into an Annex III category.

Where OWASP and MITRE ATLAS fit in

OWASP and MITRE ATLAS aren't risk management frameworks. They give your AI RMF process concrete attack knowledge. The OWASP Top 10 for LLM Applications, maintained by the OWASP GenAI Security Project, lists ten risks for LLM apps in its 2025 edition: prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption.

MITRE ATLAS is a knowledge base of adversarial tactics and techniques against machine learning systems, modeled on MITRE ATT&CK. OWASP targets developers and application security teams, and ATLAS targets red teams and threat modelers. They connect: prompt injection is OWASP's LLM01 and also appears in ATLAS as a technique.

In an AI RMF program, these feed Map (identifying threats) and Measure (building test cases). Use them to populate your risk register and plan security testing.

Related NIST AI security work (Cyber AI Profile, control overlays)

NIST is developing two cybersecurity-focused AI documents, and as far as I could find both are still drafts. The Cyber AI Profile (NIST IR 8596) is a Cybersecurity Framework 2.0 community profile. Its preliminary draft appeared on December 16, 2025, and it addresses three focus areas: securing AI system components, conducting AI-enabled cyber defense, and thwarting AI-enabled cyber attacks. Comments closed on January 30, 2026, and NIST published a workshop summary report (NIST IR 8607) in August 2026 to inform the next draft.

The SP 800-53 Control Overlays for Securing AI Systems (COSAiS) project is building overlays on NIST's SP 800-53 controls. Its concept paper came out in August 2025, and a discussion draft outline for using and fine-tuning predictive AI followed in January 2026. The overlays draw on SP 800-218A, a draft NIST AI 800-1, and NIST AI 100-2e2025.

Think of the AI RMF as the broad method for AI risk and trustworthiness, and these as the cybersecurity layer underneath: the Cyber AI Profile for program-level outcomes, and the overlays for control-level selection if you already use 800-53. Check NIST's pages for final status before you rely on either.

Is There a NIST AI RMF Certification?

No. NIST doesn't offer a certification for the AI RMF, and no NIST certificate exists that an organization can earn. The framework is voluntary guidance. Recognized ways to show your practices externally include ISO/IEC 42001 certification for an AI management system, an independent assessment, or training credentials for individual staff. Each proves something different.

Framework alignment vs certifiable standards

"Aligned with the NIST AI RMF" is a claim you make about your own practices, and "certified" is a verdict someone else issues. Alignment means you've mapped your work to the framework's functions and can show the evidence: an inventory, a risk register, test reports, named owners. NIST states that the framework is intended for voluntary use and provides no conformance or certification mechanism, so organizations assess themselves against its functions and categories.

A certifiable standard works differently. With ISO/IEC 42001, an accredited certification body audits your AI management system and issues a certificate. One source describes the certificate as typically valid for three years, maintained through annual surveillance audits.

Assessments sit between the two. Internal teams, auditors, or consultants can assess an organization against the AI RMF, and the resulting report can be useful evidence, for example in a customer review or an ISO 42001 audit. It is still not a NIST certification, and it does not result in a NIST-recognized credential.

What AI risk management training certificates do and don't prove(H3)

A training certificate proves that a person studied the framework and passed an exam. It doesn't prove that any organization's AI systems are safe or that its program meets a standard. Private training organizations offer credentials such as a "NIST AI RMF 1.0 Architect" certification, and a course of this kind appears in CISA's NICCS training catalog. NIST itself does not issue these. A catalog listing isn't a NIST certification either.

What a credential does show is individual knowledge: the four functions, the vocabulary, and how to use the Playbook. That is useful when you're staffing risk owners, assessors, or an AI governance lead. What it doesn't show is any system's performance, your program's maturity, regulatory compliance, or that a third party tested your controls. ISO/IEC 42001 works the same way. Lead implementer courses train people, while organizational certification comes only from an accredited body's audit.

When you evaluate a credential, check who issues it, whether NIST is involved (it isn't), whether the exam is proctored, what the accreditation covers, and whether it requires renewal. Treat "NIST AI RMF certified" on a vendor's website as a prompt to ask for evidence, such as their mapping, test reports, and named owners.

Adoption Beyond the U.S. (Including the GCC)

Yes, organizations outside the U.S. can use the NIST AI RMF. It is voluntary, sector-agnostic, and written for organizations of all sizes, so it travels well. It doesn't replace local law, though. In the GCC, treat it as the working method and map national and regulator guidance on top as the obligations you actually have to meet.

Using a voluntary U.S. framework as a global baseline

The AI RMF works as a baseline because it isn't tied to a jurisdiction's legal definitions. NIST describes it as voluntary, rights-preserving, non-sector specific, and use-case agnostic, offering flexibility to organizations of all sizes and sectors. Its Resource Center was launched partly to support international alignment, and NIST publishes crosswalks to other documents.

That makes it a useful common language when a multinational has to answer to several regimes at once. One inventory, one risk register, and one set of test evidence can then serve several audiences, with each local requirement added as a column or tag. The framework can't tell you which local rules apply or decide whether you comply. I didn't find any GCC regulator that designates the AI RMF as a required framework, so treat it as your method, not your legal standard.

Where data residency or national control matters, the question becomes AI sovereignty. Securing sovereign AI infrastructure covers the security side, and sovereign LLMs and sovereign AI agents covers the model layer.

Sectors: financial services, fintech, Web3, government, critical infrastructure

The same four-function loop applies across sectors, but the pressure points differ.

Financial services. Regulators already expect AI governance, and the AI RMF fits the pieces they ask for: a model inventory with risk ratings, human oversight, and accountability that stays with the institution even when functions are outsourced. DFSA's survey, as reported by a law firm, found generative AI usage among financial institutions rose 166% between 2024 and 2025, which is why supervisors are paying attention.

Fintech. Customer chatbots, fraud scoring, and credit decisions are the usual AI uses. Credit scoring is a listed high-risk category in the EU AI Act, so a fintech serving EU customers has an extra reason to document Map and Measure work carefully.

Web3. Exchanges and wallets use AI for support bots, fraud and transaction monitoring, and, increasingly, agents that take actions. The AI RMF doesn't address blockchain specifics, which is the job of smart contract auditing, but its Manage function covers the same questions: what an agent may do, who can stop it, and how its actions are logged. Your existing security obligations continue to apply alongside it, including VARA cybersecurity requirements for virtual asset businesses in Dubai (see the requirements checklist and vCISO support for VARA compliance).

Government. Procurement is the lever. Saudi Arabia's SDAIA, for example, has issued generative AI guidelines for government employees on handling government data. A shared framework gives agencies and vendors a common way to describe controls.

Critical infrastructure. NIST released a concept note for an AI RMF profile on trustworthy AI in critical infrastructure in April 2026. Operators in energy, utilities, and transport should follow its development.

GCC and regional AI regulation

The GCC picture is a mix of binding data rules and non-binding AI guidance, and which applies depends on your jurisdiction and licence. The items below are the ones I could verify. The list isn't exhaustive, and it doesn't cover Bahrain, Oman, or Kuwait.

UAE (federal). The UAE Charter for the Development and Use of AI, adopted in 2024, is non-binding and supports the National Strategy for AI 2031. The Central Bank of the UAE issued a Guidance Note on Consumer Protection and Responsible Adoption and Use of AI and ML in February 2026 for licensed financial institutions. Its principles are non-binding, and institutions remain bound by existing consumer protection rules the note interprets. Commentary on it highlights rating the risk of each AI system, human oversight, and retained responsibility for outsourced functions. For the wider picture, see UAE cybersecurity regulations and UAE data protection law.

DIFC. Regulation 10 of the DIFC Data Protection Regulations, introduced in late 2023, governs personal data processed by autonomous and semi-autonomous systems and supplements the DIFC Data Protection Law. It introduces general and system-specific certification requirements and stricter obligations for high-risk processing, with further guidance from the Commissioner expected in 2026.

Saudi Arabia. SDAIA issued its AI Ethics Principles in September 2023 and has since updated them, along with two generative AI guidelines in January 2024. The Personal Data Protection Law, in force since September 2023, applies to personal data in AI systems.

Qatar. The Qatar Central Bank published an AI Guideline for licensed financial institutions in September 2024.

In practice, add a "regulatory driver" field to each register entry and tag it with the applicable rule or guidance, such as a CBUAE expectation, DIFC Regulation 10, or SDAIA principles. That keeps the AI RMF as your method and the local rule as your obligation.

Current Status and Updates to the AI RMF

NIST states that it is revising AI RMF 1.0 as part of the White House AI Action Plan. No successor document ID, public draft, or schedule had been published as of July 24, 2026, so AI RMF 1.0 (NIST AI 100-1, January 26, 2023) remains the current version. On April 7, 2026, NIST also released a concept note for a Critical Infrastructure profile.

The revision traces to America's AI Action Plan of July 23, 2025. That plan told NIST to revise the framework to remove references to misinformation, diversity, equity and inclusion, and climate change. The Critical Infrastructure concept note is a separate track. It describes a profile to guide infrastructure operators toward specific risk management practices when they use AI-enabled capabilities. The Generative AI Profile (NIST AI 600-1) has been final since July 26, 2024, and nothing in NIST's current announcements replaces it.

What the revision means for teams adopting now

Adopt AI RMF 1.0 now rather than waiting. NIST has published no replacement structure, and the Govern, Map, Measure and Manage functions describe a risk management cycle that a revision is more likely to refine than discard. That is an inference, not a NIST statement, so check it against any new publication. Procurement questionnaires and regulators already ask about alignment with the current version, and work built on it carries over to whatever follows.

Three habits make a later revision cheap to absorb:

• Cite precisely. Reference AI RMF 1.0 and its subcategory identifiers by name, so any future successor shows up as a clear delta.

• Keep the mapping in one place. Hold your risk register's links to framework subcategories in a single table you can update, rather than scattering them through policy documents.

• Watch the scope signals. If you rely on the bias, fairness or misinformation language in your own controls, expect that wording to change, and don't depend on those passages staying as written.

Treat any "AI RMF 2.0" label as unofficial. NIST has not used that name, and this article won't either unless it does.

Limitations of the NIST AI RMF

The NIST AI RMF is deliberately abstract: it tells organizations what outcomes to pursue, not which controls, thresholds, or tests to use, so every adopter must supply those specifics. It is also voluntary, but that does not make it unenforceable, because contracts, procurement terms and state laws now turn on whether you can show alignment.

Abstract by design, and what you must add yourself

NIST describes the framework as intended for voluntary use and built to work across sectors, AI types and organization sizes. That flexibility is why it travels well, and it is also its main weakness as a working tool. The Govern, Map, Measure and Manage subcategories describe results such as "risks are documented" or "systems are evaluated." They don't say how often to test, what failure rate is acceptable, who signs off, or what evidence an auditor will accept. Two companies can both claim alignment while running very different programs.

Closing that gap is your job, and it comes down to a handful of decisions the framework leaves open:

• Risk tolerance. Decide what level of harm each use case can accept, and set your likelihood and impact scoring scale to match.

• Test methods and thresholds. Choose the evaluations, red-team scope and pass/fail criteria that satisfy the Measure function for your system.

• Ownership. Name an accountable person for each system and each risk register entry.

• Evidence. Define what records you keep, such as test results, review minutes and incident logs, and for how long.

• Third parties. Push these requirements down to model providers and vendors, since the framework covers your entire AI supply chain but sets no contract terms.

The Playbook offers suggested actions for each subcategory, but treat them as a menu to adapt, not a checklist that proves compliance. The Generative AI Profile (NIST AI 600-1) adds risk-specific detail for LLM systems, but it works the same way: actions to consider rather than required controls.

Voluntary doesn't mean unenforceable

Voluntary describes NIST's authority, not your exposure. Customers write AI RMF alignment into security questionnaires and contracts, which turns a claim into a commitment you can be held to. Regulators and plaintiffs can also use your stated framework as the yardstick for whether you acted reasonably, and a claim of alignment you can't back with evidence can be framed as a misrepresentation.

State law makes this concrete. Texas's Responsible AI Governance Act took effect on January 1, 2026, and a person is not liable under it if they substantially comply with the NIST AI RMF or a similar recognized framework. The Texas Attorney General enforces the act, with civil penalties ranging from $10,000 to $200,000. That is an affirmative defense, not immunity. You still have to show the substantial compliance, and practitioners stress that what counts is keeping evidence that you actually follow the framework, not a binder that merely names it. Colorado's AI Act takes a similar approach, creating a rebuttable presumption of reasonable care for deployers who comply with NIST AI RMF or ISO 42001, although its effective date has shifted more than once and should be confirmed with official sources.

Frequently Asked Questions (FAQs)

What is the NIST AI RMF in one sentence?

The NIST AI Risk Management Framework (AI RMF 1.0, NIST AI 100-1) is a free, voluntary framework, released January 26, 2023, that helps organizations manage AI risks through four functions: Govern, Map, Measure and Manage. It applies to any organization that designs, develops, deploys or uses AI systems.

Is the NIST AI RMF mandatory?

No. NIST intended it for voluntary use, and no federal law requires you to adopt it. It can still become binding in practice: Texas's Responsible AI Governance Act, effective January 1, 2026, gives an affirmative defense to organizations that substantially comply with the AI RMF, and customers frequently write alignment into contracts.

What are the four functions?

Govern establishes the policies, accountability and culture for managing AI risk. Map defines a system's context, intended use, and potential impacts; Measure tests and tracks those risks with metrics and evaluations; and Manage prioritizes, mitigates, and monitors them. Govern runs across the full lifecycle, while Map, Measure, and Manage apply to each AI system.

Does the AI RMF apply outside the U.S.?

Yes. The AI RMF is U.S. guidance, but it is voluntary, sector-neutral and not tied to a jurisdiction, so organizations anywhere can use it as a baseline. NIST publishes Arabic and Japanese translations of the framework. It does not replace local law such as the EU AI Act, so map it to the rules that apply where you operate.

What is the difference between the AI RMF and ISO 42001?

The AI RMF is a voluntary risk management framework that cannot be certified. ISO/IEC 42001 is an AI management system standard with auditable requirements, and certificates come from accredited external certification bodies, not from ISO itself. Many teams use the AI RMF to build their risk practice and ISO 42001 to demonstrate it to outside parties.

What is the Generative AI Profile?

The Generative AI Profile (NIST AI 600-1), released July 26, 2024, is a companion to the AI RMF that helps organizations identify risks unique to or amplified by generative AI, such as confabulation, harmful content and data leakage, and proposes actions organized around the four functions. Use it alongside the core framework, not instead of it.

Is the AI RMF being updated?

Yes. NIST states that AI RMF 1.0 is being revised as part of the White House AI Action Plan, but no successor document or public draft had been published as of this article's last review. On April 7, 2026, NIST also released a concept note for an AI RMF profile on trustworthy AI in critical infrastructure.

How is the AI RMF different from NIST's RMF?

They are separate documents. NIST's RMF (SP 800-37) is a process for managing security and privacy risk in information systems, widely used in U.S. federal compliance. The AI RMF addresses risks that AI systems pose to people, organizations and society, such as bias, unreliability and lack of transparency, and the two can be used together.