Publish date
September 16, 2026
{x} minute read
Written by
Reviewed by
Table of contents

Security leaders who already use the NIST Cybersecurity Framework often assume it covers AI, but it doesn't. The Cybersecurity Framework (CSF) protects the confidentiality, integrity, and availability of the systems around a model. Outcome risk from model decisions is a different job.

The NIST AI Risk Management Framework (AI RMF 1.0) helps you govern AI use and test model risk, with clear ownership before systems create harm. NIST published it as NIST.AI.100-1 on January 26, 2023, as voluntary guidance built on four functions: Govern, Map, Measure, and Manage. Because it's voluntary guidance rather than a certification program, it doesn't produce a compliance badge, and a team that "already does NIST" via CSF has not implemented this framework for AI risk.

The official designation is NIST.AI.100-1, voluntary guidance designed to improve trustworthiness across an AI system's lifecycle. NIST published it along with several companion materials to help teams apply the framework in practice: the AI RMF hub and the full NIST.AI.100-1 document, the AI RMF Playbook, the Roadmap, the Crosswalk, and the Generative AI Profile (NIST.AI.600-1, released in July 2024).

The four functions: Govern, Map, Measure, Manage

The framework organizes AI risk work into four functions that run throughout the AI lifecycle; here's what each one means:

Function Job in one sentence Example action a team of two to 10 people can do
Govern Build risk culture and leadership accountability for AI. Name an AI oversight owner and publish a written AI acceptable-use and risk-tolerance policy.
Map Contextualize each system's purpose, its stakeholders, and potential harms. Inventory approved and known AI systems, including vendor models, and document intended use and data classes.
Measure Analyze and evaluate risk through testing and ongoing monitoring. Define pre-deploy bias and privacy checks plus security testing, then require a minimum evidence pack before go-live.
Manage Prioritize and treat risks, then feed lessons back into policy. Assign a system owner and an escalation path for changes to models, prompts, or vendors.

These functions are interconnected and iterative across the AI lifecycle. They aren't a one-time checklist or a numbered vendor roster. NIST organizes the framework's details into a structure called the Core, which breaks each function into categories and subcategories you can tailor by system risk.

The official AI RMF Playbook offers voluntary action suggestions mapped to those subcategories. It's neither a full checklist nor a mandate to complete every item. Teams use it after they know which systems are in scope and who owns the risk decisions.

NIST also publishes an AI RMF Roadmap for research and measurement priorities and AI RMF Crosswalks that align the Core with other standards and frameworks. Use those companions after the four functions are clear; they do not replace Govern, Map, Measure, or Manage.

Govern comes first for a reason. Without an owner, documented risk tolerance, and accountability, Map inventories remain incomplete, and Measure tests become optional theater. Tooling helps after policy exists, but it doesn't replace the four functions.

Lean security teams often forward the table above as the working artifact because it captures the essential actions without requiring deep familiarity with NIST's full Core structure. The rest of the Core, NIST's detailed breakdown of categories and subcategories within each function, adds specificity after you know who owns what, which matches how questions actually arrive from auditors and boards. First comes "who owns AI risk," then "show the inventory and evidence."

How the AI RMF addresses AI risk (and what "trustworthy" means here)

The AI RMF addresses AI risks by iterating through Govern, Map, Measure, and Manage to mitigate potential harm to people, organizations, and ecosystems. It steers design toward NIST's trustworthiness characteristics. That path goes beyond security controls alone.

Those three harm categories stay concrete in practice. For people, harm can include impacts on rights, safety, economic opportunity, and discrimination. For organizations, harm can include operational and financial harm, as well as reputational damage when model outputs fail or leak sensitive data. At the ecosystem level, harm can include failures that cascade across interdependent systems and the shared infrastructure across supply chains.

The seven trustworthiness characteristics from NIST are the design and evaluation targets for that work:

  1. Valid and reliable means that outputs and behavior perform consistently under expected conditions and within documented limits.
  2. Safe means that systems do not create an unacceptable safety risk in their intended context of use.
  3. Secure and resilient systems can withstand, detect, and recover from adversarial and operational stress.
  4. Accountable and transparent roles and decisions make responsibility visible.
  5. Explainable and interpretable means that stakeholders can understand how and why the system produced outputs at the level required by the use case.
  6. Privacy-enhanced means handling personal and sensitive data in ways that limit unnecessary exposure and misuse.
  7. Fair, with harmful bias managed, teams assess outcomes for harmful bias and treat it as a managed risk.

"Trustworthy" here is an engineering and governance target, not a marketing label. A model can sit behind strong access control and still fail fairness, privacy, or reliability tests. The CSF alone doesn't force you to run those tests.

For generative systems, NIST later extended AI RMF 1.0 with a Generative AI Profile covering prompt- and model-specific risks. That profile maps generative-specific risks onto the same four functions. It doesn't replace the base framework. Use it when prompts, foundation models, or retrieval pipelines change the harm surface, and don't treat it as a second parallel program.

AI RMF vs the NIST Cybersecurity Framework

CSF-fluent teams protect the model's environment. They rarely have a parallel motion for the model's decisions. For a deeper walkthrough of CSF itself, see the NIST Cybersecurity Framework guide.

Framework Primary focus Scope
NIST Cybersecurity Framework Protecting data, networks, and systems The information technology environment around the model
NIST AI RMF Risks inherent to the model and its outcomes The AI lifecycle and impacts on people and organizations, including bias, opacity, and privacy harm

CSF isn't obsolete, and the AI RMF isn't a replacement. You still need CSF-class controls protecting model endpoints and training data. You need the AI RMF to decide go or no-go, with evidence and ongoing monitoring behind it.

In practice, CSF-fluent teams already know how to protect a model endpoint. The gap shows up when a customer questionnaire or board pack asks whether the company "does NIST AI RMF." Access reviews and vulnerability scans answer the environment question. They do not answer whether anyone owns the model's harm scenarios or its evaluation evidence.

Fairness and explainability gaps clearly show the split. Securing an API doesn't tell you whether a scoring model disadvantages a group or whether operators can justify a high-stakes decision. Outcome risk needs its own owner and tests.

How to implement NIST AI RMF in three phases

You can implement the framework in three phases:

  1. Establish oversight and a written AI policy (Govern): Put ownership and policy in place first, so AI risk decisions have authority and documented guardrails.
  2. Map each system and test it before deployment (Map and Measure): Document context and harms, then gate go-live on evidence.
  3. Assign owners and a feedback loop (Manage): Give every system an owner and a review cadence so owners act on risks and feed lessons back into policy.

Phase 1: establish oversight and policy (Govern)

Start with accountability, not software. Put someone, or a small body, in charge of AI risk tolerance. That body should approve high-impact use cases and halt deployments lacking evidence.

Publish a written AI policy covering acceptable use, data handling, and who approves exceptions. Define roles with a RACI matrix spanning security, legal, and the business. Integrate AI risk into your existing GRC rhythms so it doesn't become a parallel silo.

Do not start by buying a tool. Platforms and questionnaires help later, but they cannot invent ownership or risk appetite for you. A purchase without Govern leaves you with dashboards and no decision rights when a use case fails its evidence gate.

When teams eventually evaluate AI governance platforms, those tools should support the four functions you already defined rather than stand in for them.

Phase 2: inventory, map, and test (Map and Measure)

Create an inventory that includes every AI system your organization owns, procures, or integrates. Document each system's intended purpose, the sensitivity of the data it processes, and the impact of its decisions. Third-party vendor models and hosted APIs belong in Map too: accountability for how external model outputs are applied remains with your organization, regardless of who trained the underlying weights.

For each system in scope, document its context and the potential harms it could cause. Record what the system is intended to do and what falls outside that scope. Poor mapping creates dashboards that appear thorough but overlook the decision paths where harm actually occurs.

Before go-live, insist on a minimum evidence pack. Include the relevant fairness and security tests, documented limitations, and the human oversight model. Treat evaluation as a gate, not a slide in a design review.

Unsanctioned tools still belong in Map when they process company data or influence decisions. Shadow AI creates the same outcome risk as approved systems when no one has mapped data flows or failure modes. That exposure is why teams track shadow AI data leaks as inventory and measurement problems, not just acceptable-use violations.

Phase 3: owners and feedback (Manage)

Assign a system owner for every in-scope AI system, with an escalation path for changes and incidents. Prioritize residual risk against your published tolerance and fund mitigations on a standing cadence rather than a one-time sign-off.

Monitor for drift, including unexpected outputs and vendor control failures. Incorporate lessons into Govern to keep policies, RACI, and risk tolerance up to date. Manage is where the framework becomes operational. Without owners and feedback, Map and Measure decay into static documents.

If you need external visibility into exposed assets and unsanctioned AI-related exposure on your attack surface, UpGuard's Breach Risk provides that view.

To operationalize vendor questionnaires against the same four functions, use the NIST AI RMF security questionnaire.

What this is not (voluntary, not a certificate)

AI RMF 1.0 is voluntary guidance, meaning NIST frames it as a way to build trustworthiness into AI systems rather than as a compliance mandate. The full AI RMF 1.0 document (NIST.AI.100-1) serves as the primary reference text for teams implementing the framework.

It doesn't make your organization "NIST AI compliant." It also doesn't replace CSF or broader NIST compliance program work.

Legal regimes such as the European Union AI Act impose different, binding obligations. The AI RMF isn't a substitute for them. Similarly, ISO/IEC 42001 is a separate, certifiable AI management system standard—another instrument, not a renaming of AI RMF 1.0.

Use it to structure ownership, evidence, and outcome risk, not to earn a badge.