NIST AI Risk Management Framework: A Practical Guide

The NIST AI Risk Management Framework (AI RMF 1.0, published as NIST AI 100-1) is a voluntary, non-sector-specific resource that helps organizations manage risks in AI systems and build trustworthiness into them, according to NIST's own framework document. It organizes the work into four functions, Govern, Map, Measure and Manage, and it is increasingly the vocabulary your customers use when they ask how you control AI risk. This guide explains what is in it, how to apply it without drowning in paperwork, and how to answer the questions it now generates in security reviews.

TL;DR

• The AI RMF 1.0 (NIST AI 100-1) is voluntary guidance for managing AI risk and supporting trustworthy AI, and it is not tied to any one sector.
• It has four functions: Govern (the cross-cutting foundation), Map, Measure and Manage.
• It describes seven trustworthiness characteristics, from valid and reliable to fair with harmful bias managed.
• You apply it through the Core's categories and subcategories and document your current state, target state and gaps in a Profile.
• The Generative AI Profile (NIST AI 600-1) is a companion for generative AI risks. Expect buyers to ask about both in questionnaires.

Table of Contents

• What the framework is and who it is for
• The seven trustworthiness characteristics
• The four functions: Govern, Map, Measure, Manage
• How to apply the Core and write a Profile
• Companion guidance: AI 600-1 and the AIRC
• Is the AI RMF mandatory or certifiable?
• Where the AI RMF shows up in security questionnaires
• Our perspective
• Turning your AI RMF work into faster answers
• Common mistakes to avoid
• FAQ
• Sources

What the framework is and who it is for

NIST developed the AI RMF to help manage risks to individuals, organizations and society that come with artificial intelligence, and it keeps the framework and its related material on its AI Risk Management Framework page. Three properties matter in practice.

It is voluntary. Nothing in the document makes it a law or a regulation. It is written for organizations that choose to use it, which is why you will see it referenced in contracts, procurement language and due diligence questionnaires rather than in statutes.

It is not sector-specific. A bank, a healthcare software vendor and a startup building a support chatbot can all use the same structure. What changes is how much rigor each applies and which risks matter most to them.

It is built for many roles. NIST describes a "collective responsibility" among the different AI actors, and argues that multidisciplinary teams are essential to surfacing emergent risks that homogeneous teams tend to miss. In a software company, that means the framework is not only for the data science team. Security, legal, privacy, product, compliance and the people who answer customer questionnaires all have a part in it.

If you are a CISO, a GRC lead or a solutions engineer, you will meet the framework from two directions. Internally, it gives you a structure for governing the AI features you build or buy. Externally, customers use it as a reference when they ask how you manage AI risk.

The seven trustworthiness characteristics

The framework is organized around the idea that trustworthy AI has several properties, and that they sometimes pull against each other. NIST lists seven: valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. The point of managing them is to reduce risks that affect individuals, organizations, society and the environment.

Here is how each one tends to show up in a real review of an AI-enabled product:

Treat the table as a checklist for conversations, not a scoring sheet. The framework itself does not give you a pass mark. It asks you to decide, document and be able to defend your trade-offs.

The four functions: Govern, Map, Measure, Manage

The core of the framework is four functions. In NIST's description, GOVERN is a cross-cutting foundation that builds an AI risk culture, MAP identifies risks in context, MEASURE analyzes and tracks them, and MANAGE puts risk-mitigation actions into practice. They are interconnected processes, not a waterfall, so you will loop between them.

Govern: set the rules and the culture

Govern runs underneath everything else. It covers policies, roles, accountability, risk tolerance and the culture that decides whether people raise concerns about an AI system or keep quiet. If you do only one thing first, write down who is accountable for each AI system, who can approve a new use case and who can stop one.

Practical starting points:

1. Maintain an inventory of AI systems, including third-party models and AI features inside vendor tools.
2. Assign a named owner to each system.
3. Define which uses need review before launch, such as anything touching customer data or affecting decisions about people.
4. Set an escalation path for incidents and complaints.

Map: understand context and identify risks

Map is where you describe what a system is for, who uses it, who it affects and what could go wrong. A risk that looks minor in the lab can be serious in a specific deployment, so context comes first. For each use case, record the intended purpose, the data involved, the people affected, the known limitations and the assumptions you are making.

A useful test: could a new colleague read your Map entry and understand why the system exists, where it must not be used and what the worst plausible failure looks like? If not, the entry is not finished.

Measure: analyze, assess and track

Measure turns the risks you mapped into something you can evaluate and watch over time. That may include testing for accuracy, robustness, security weaknesses, privacy leakage and bias, along with monitoring after release. The key habit is to choose metrics tied to your mapped risks rather than collecting whatever is easy to measure, and to repeat the measurements, because models, data and usage drift.

Manage: prioritize and act

Manage is where you decide what to do about the risks you have measured: mitigate, transfer, accept or avoid, then follow through. It also covers incident response, updates and decommissioning. Document the reasoning behind each decision, including risks you accept, because that record is what a customer or auditor will ask for.

How to apply the Core and write a Profile

The Core breaks each function into categories and subcategories. You are not expected to treat every subcategory as a mandatory control. NIST's approach is that organizations use the categories and subcategories to tailor their activities to their own needs, then record the result in a Profile that captures the current state, the desired target state and the gaps between them.

A workable path for a mid-sized B2B software company looks like this:

1. Scope. Pick one to three AI systems or use cases, ideally the ones customers ask about most.
2. Inventory and owners. List each system, its data sources, its vendors and its accountable owner.
3. Select relevant subcategories. Mark which ones apply to your use case and which do not, and note why.
4. Describe the current state. For each selected subcategory, write what you do today and where the evidence lives, such as a policy, a test report or a ticket.
5. Define the target state. Decide what good looks like given your risk tolerance, customer commitments and regulatory exposure.
6. List the gaps and rank them. Turn each gap into an owned, dated work item.
7. Review on a schedule. Revisit the Profile when you launch a new feature, switch model providers or change the data a system uses.

Profiles can be specific to a sector, a use case or a point in time. A security software vendor might keep one Profile for its customer-facing assistant and another for internal tooling, since the risks and affected people differ.

Keep the output lightweight. A shared document or spreadsheet with subcategory, current practice, evidence link, owner and target date is enough to start. The value comes from the discipline of keeping it current, not from the format.

Companion guidance: AI 600-1 and the AIRC

The AI RMF 1.0 is not the only NIST material you will meet. The Generative AI Profile, NIST AI 600-1, is a cross-sectoral companion resource that defines risks specific to generative AI and suggests actions to manage them. If your product uses large language models, or your employees use them, it is the natural second document to read.

NIST also launched the Trustworthy and Responsible AI Resource Center (AIRC) in March 2023 to support implementation of the framework and give access to related resources. Because guidance and companion documents are updated over time, check NIST's pages for the current set before you build a program around a particular version.

Is the AI RMF mandatory or certifiable?

The framework document describes itself as intended for voluntary use. That has two consequences for your program.

First, no one can require you to "be NIST AI RMF compliant" in the way a regulation can, though a customer can write alignment into a contract or a questionnaire. When they do, ask what they mean: do they want a documented Profile, named owners, evidence of testing, or all three?

Second, we are not aware of a certificate issued by NIST for the framework, so it is best described as something you align with and can evidence, not something you hold a badge for. If a buyer needs an independent attestation, ask which standard they have in mind, since other management-system standards exist for that purpose. Either way, the evidence you gather under Govern, Map, Measure and Manage is what makes your answers credible.

The AI RMF is also separate from the NIST Risk Management Framework in SP 800-37, which readers often confuse with it because the names are close. If a questionnaire cites "NIST RMF," check which document it means before you answer. For a broader view of how security teams choose among frameworks, see our guide to IT risk management frameworks, and for a phased approach to combining NIST and ISO, see applying ISO and NIST risk assessments in 90 days.

Where the AI RMF shows up in security questionnaires

For vendors, the most immediate effect of the framework is on the questionnaires you receive. Buyers have long asked about encryption, access control and incident response. Now they add AI-specific questions, and many of them map neatly to the four functions:

• Govern: Do you have an AI policy? Who is accountable for AI risk? Do you keep an inventory of AI systems and third-party models?
• Map: Which customer data does the AI feature process? Is customer data used to train models? What are the intended and prohibited uses?
• Measure: How do you test accuracy, security and bias? How often? What do you monitor in production?
• Manage: How do you handle AI incidents, model changes and customer complaints? Can customers opt out?

Three habits make these questionnaires much easier:

1. Keep one source of truth. Write approved answers once, with an owner and a review date, rather than rewriting them for each customer.
2. Answer in the framework's language. If a buyer uses Govern, Map, Measure and Manage, structure your answer the same way and point to evidence.
3. Do not overclaim. If you have not completed a bias evaluation, say what you have done and what is planned. Inconsistent answers across questionnaires cause more trouble than honest gaps.

We cover the broader shift in our pieces on AI in risk management for security questionnaires and how AI transforms compliance for security questionnaires.

Our perspective

We spend our days inside security questionnaires, so we see the AI RMF from the receiving end. Over the past period, AI governance questions have moved from an occasional extra section to a regular part of reviews, and the questions are often phrased around the same concepts: accountability, context, testing and response.

What we have learned is that the teams who answer well are not necessarily the ones with the largest programs. They are the ones who can say the same true thing the same way every time and show where the evidence lives. That is a knowledge management problem as much as a governance one. If your AI policy lives in one document, your testing results in another and your data-handling answers in the last questionnaire someone filled out, every new request becomes a scavenger hunt.

Our own approach is to keep approved answers in a searchable knowledge base, have the AI draft from those answers only, and show a confidence score so a human reviews what is uncertain instead of re-reading everything. The framework asks you to be accountable and transparent, and we think questionnaire answers should meet the same bar: traceable to a source, reviewed by an owner and consistent across customers.

If you are starting out, our advice is modest. Pick one AI system, write its Profile, assign owners and turn the result into reusable answers. Then extend. Please feel free to reach out if you would like to compare notes.

— Gaspard

Turning your AI RMF work into faster answers

Once your Profile exists, the challenge becomes reuse. Skypher's Questionnaire Automation Tool ingests questionnaires in any format, drafts answers from your approved knowledge base with a confidence score, and lets security, legal and sales collaborate in real time. The Smart Security Knowledge Base keeps your AI governance answers versioned and in one place, and the Trust Center lets customers see your security and compliance posture before they send a questionnaire at all.

For teams that handle due diligence requests from investors and financial counterparties, our DDQ automation applies the same approach to those longer documents. We do not publish pricing, so the quickest way to see whether it fits is to book a demo from the site.

Common mistakes to avoid

• Treating it as a checklist. The framework is meant to be tailored. Applying every subcategory equally to every system wastes effort and obscures the risks that matter.
• Starting with tooling. Software helps with measurement and evidence, but without owners and risk tolerances, it records activity without managing risk.
• Ignoring third-party AI. Models and AI features inside vendor products are part of your risk. Your inventory should include them, and your vendor reviews should ask about them. Our tips for third-party risk assessment can help.
• One-time exercises. A Profile that is written once and never updated will not survive a model change or a new feature.
• Leaving out the non-technical voices. Legal, privacy, product and customer-facing teams catch risks that engineers do not.

FAQ

What is the NIST AI Risk Management Framework?

It is a voluntary, non-sector-specific framework from NIST, published as AI RMF 1.0 (NIST AI 100-1), that helps organizations manage AI risks and promote trustworthy AI. It is organized around four functions: Govern, Map, Measure and Manage.

Is the NIST AI RMF mandatory?

No. The framework is intended for voluntary use. Customers or partners may still ask you to align with it through contracts or questionnaires, so it often becomes a practical expectation even though it is not a regulation.

What is the difference between the AI RMF and the NIST AI 600-1 profile?

The AI RMF 1.0 is the general framework for any AI system. NIST AI 600-1, the Generative AI Profile, is a companion resource that defines risks specific to generative AI and suggests actions to manage them. Use the two together if you build or use generative AI.

Is the NIST AI RMF the same as NIST SP 800-37?

No. They are separate NIST publications with similar names. If a questionnaire asks about the NIST RMF, confirm whether it means the AI framework or the SP 800-37 document before answering.

Sources

• Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1
• Audience, NIST AI Resource Center
• AI Risk Management Framework FAQs, NIST
• AI Risk Management Framework, NIST
• Artificial Intelligence Risk Management Framework: Generative AI Profile, NIST AI 600-1

Recommended

• IT Risk Management Frameworks: Choose and Implement the Right One
• Key AI advantages in risk management for tech and finance
• Risk Management Framework Examples for Security Teams
• Risk management guide for tech and finance pros