Framework guide / NIST AI 100-1

NIST AI RMF: a practical guide.

The NIST AI Risk Management Framework (AI RMF) is a voluntary framework for managing risks from AI to individuals, organizations, and society. Its four functions—Govern, Map, Measure, and Manage—help connect the context of an AI system to the evidence and decisions needed throughout its lifecycle.

Use the framework to make a consequential AI decision clearer: what is acceptable, what has been demonstrated, and what still needs to change.

Understand the framework See a worked example

The implementation test

What changes
because this risk was reviewed?

A defined useIdentify the decision, users, and people affected.
Relevant evidenceExamine results, limitations, and working controls.
An accountable responseRecord the action, owner, and reassessment trigger.

This practical review lens connects the framework to an operational decision.

By InfoSecuredSource review: 29 September 2026Sources & approach

01 / What it is & who it helps

A common structure for AI risk decisions.

NIST’s AI RMF gives organizations a shared language for identifying, assessing, and responding to AI risks. It covers more than technical model performance: the people, processes, operating context, and consequences of use matter too. It can support development, procurement, deployment, and evaluation across sectors. [1]

Issuer & publication: National Institute of Standards and TechnologyAI RMF 1.0, published January 2023 as NIST AI 100-1.
Type: Voluntary risk-management frameworkDesigned to be tailored to the organization and use case. Its functions and outcomes are not a universal implementation checklist.
Edition used here: AI RMF 1.0As checked on 29 September 2026, NIST continues to publish 1.0 and states that a revision is in progress. This guide does not treat an announced revision as a replacement edition. [2]
Best fit: A common approach across AI teams and decisionsUseful when risk, technology, procurement, operations, and leadership need to agree what should be assessed, who owns it, and how findings change the use of a system.

For a buyer, the framework can organize questions about a supplier’s AI and the local controls needed around it. For a developer, it can connect design and evaluation to foreseeable consequences. For a reviewer, it can make a claim about the system easier to challenge. The work should be proportionate to the significance of the use, rather than the number of documents a team can produce.

Reading boundary: NIST defines the framework and its outcomes. The evidence examples, proposed working method, and fictional scenario below are InfoSecured’s implementation guidance, not mandatory NIST forms.

02 / The four functions

Govern, Map, Measure, and Manage work together.

The AI RMF Core organizes outcomes into four functions, then into categories and subcategories. They are connected activities, not four stages to complete once. Govern runs across the other functions; new evidence or a changed use can send a team back to reconsider context, evaluation, or treatment. [1]

GOVERN: Who is accountable, and what rules guide the work?Establish responsibilities, policies, risk tolerance, competence, and communication. Practical output: a clear decision authority, known escalation routes, and a way to verify that policies are used in real decisions.
MAP: What is the system doing, for whom, and in what setting?Describe the purpose, users, affected people, dependencies, benefits, and potential harms. Practical output: a bounded use case and concrete failure scenarios, including assumptions about how the system will actually be used.
MEASURE: What can the evidence tell us about the risks?Select and apply appropriate qualitative or quantitative evaluation, examine trustworthiness, and track risks over time. Practical output: relevant results with their methods, limitations, and uncertainty—not just a favorable aggregate score.
MANAGE: What should happen in response?Prioritize risks, determine treatments, and manage continued use, monitoring, and recovery. Practical output: an accountable decision tied to actions, operating conditions, and triggers for reassessment.

For example, an evaluation might show that a system performs poorly for a previously overlooked user group. That finding can change the Map analysis, require a Manage restriction, and reveal a Govern gap in who was consulted. Repeating that loop is part of implementation, not evidence that the team followed the functions in the wrong order.

Source: AI RMF 1.0, §5 and Tables 1–4, printed pages 20–33. The practical outputs above are illustrative applications of the functions.

03 / What to evaluate

Trustworthiness goes beyond accuracy.

NIST describes seven characteristics of trustworthy AI. Their importance and the tradeoffs between them depend on context. Addressing a characteristic in isolation does not establish the trustworthiness of the entire system. [1] [5]

Valid & reliable: Does it work for the intended purpose?Examine the relevant conditions, populations, repeatability, and limits of generalization.
Safe: Can it avoid or contain harmful outcomes?Consider foreseeable misuse, consequential errors, intervention, and behavior when operating limits are reached.
Secure & resilient: Can it resist threats and recover from disruption?Examine the model, data, interfaces, dependencies, and surrounding service.
Accountable & transparent: Can people understand the process and identify responsibility?Provide appropriate information and a clear route for questions, decisions, and challenge.
Explainable & interpretable: Can the mechanism and output be understood appropriately?Distinguish an explanation of how the system works from what an output means for a particular decision.
Privacy-enhanced: How are privacy risks managed?Examine data use, exposure, access, and the effects of privacy protections in the application.
Fair, with harmful bias managed: Who experiences different performance or consequences?Consider affected groups, organizational practices, and relevant evaluation evidence.

For a complaint-routing tool, average classification performance says little about whether urgent cases wait too long, whether staff can correct a misroute, or whether particular language groups receive worse service. Select measures that address the actual consequences. Record important gaps and tradeoffs instead of compressing everything into a single “trustworthiness score.”

04 / Profiles & the Playbook

Tailor the work to a specific use.

An AI RMF Profile applies selected functions, categories, and subcategories to a particular setting. NIST also describes Current Profiles, which capture existing outcomes, and Target Profiles, which describe the desired state. Comparing them helps identify and prioritize gaps. AI RMF 1.0 does not prescribe a single profile template. [1]

Current: What can we substantiate today?For example: analysts can correct complaint priority, but the reason for a correction is not retained and there is no systematic review of missed urgent cases.
Target: What outcome does this use need?For example: corrections are attributable, significant errors reach an accountable owner, and review covers cases that the system assigned low priority.
Gap & action: What must change, and who will verify it?Name the operational change, owner, evidence needed, and completion criterion. “Write a policy” is incomplete if the desired outcome also requires a working intervention.

The NIST AI RMF Playbook supplies suggested actions and documentation considerations aligned to subcategories. NIST explicitly says it is neither a checklist nor a sequence to follow in full. Use it to develop a suitable approach, then evaluate whether that approach achieves the intended outcome. [3]

Do not assume a blank mapping cell means a control failed. Distinguish an applicable outcome with missing evidence from a justified exclusion or an outcome covered elsewhere. Record why the selected scope is appropriate, and revisit it when the system or its context changes.

05 / Outcomes to evidence

Connect a framework outcome to something reviewable.

The following selected mappings illustrate how a team could prepare evidence for review. They are a starting set, not full AI RMF coverage. The subcategory identifiers come from NIST; the proposed artifacts and owner roles are InfoSecured suggestions. [1]

GOVERN 1.3: How much risk-management effort is appropriate?A recorded risk-tolerance rationale that explains the consequences the organization is prepared to accept, the constraints it must respect, and who can authorize exceptions. Suggested owner: Risk owner and decision authority. NIST reference, p. 22.
GOVERN 2.1: Who owns the decisions and handoffs?A role map linking the system owner, reviewers, escalation contacts, and approval authority, supported by evidence that a test escalation reaches the right person. Suggested owner: Business owner. NIST reference, p. 23.
MAP 1.1: What use and operating context are being assessed?A use-case record identifying the purpose, users, affected people, deployment setting, anticipated benefits and harms, assumptions, and relevant obligations. Suggested owner: System owner with domain specialists. NIST reference, p. 26.
MAP 3.5: Can a person intervene effectively?An oversight design and a workflow test showing what reviewers see, what they can change, and how a disputed outcome is escalated. Suggested owner: Operations and oversight owners. NIST reference, p. 27.
MEASURE 2.1 / 2.3: Can the evaluation support the proposed use?Versioned test data, methods, metrics, tools, and results, plus an explanation of how the evaluation reflects deployment conditions and where coverage is weak. Suggested owner: Evaluation team and qualified reviewers. NIST reference, p. 29.
MANAGE 1.1: Should development or deployment proceed?A decision record explaining the basis to proceed, restrict, defer, or stop, with the relevant findings, unresolved issues, and decision-maker. Suggested owner: Authorized decision-maker. NIST reference, p. 32.
MANAGE 4.1: What happens after release?A monitoring and response plan that connects indicators, user feedback, overrides, incidents, recovery, and changes to named owners and actions. Suggested owner: Service owner and control owners. NIST reference, p. 33.

Keep each evidence item connected to the system version, use, date, and claim it supports. An approval from a previous configuration is not automatically evidence for a new one. Preserve contrary results and incomplete coverage alongside favorable findings so the decision-maker can see the actual uncertainty.

An artifact’s existence also differs from a control’s effectiveness. A reviewer-role chart describes intended authority; observing a reviewer stop an inappropriate action provides different evidence. Both can matter, but they support different conclusions.

06 / A worked example

Should an AI prioritization tool enter service?

A fictional service organization proposes an AI tool to rank customer complaints for staff review. The tool will not resolve complaints, but its ranking changes waiting times. The owner wants approval based on a vendor demonstration and a favorable overall accuracy result.

Complaint prioritizationIllustrative example

An original AI RMF application

The important question is whether the queue remains safe and workable when the ranking is wrong.

Govern / decision authority

The service owner identifies who can approve use, which operational constraints apply, and who can restrict the tool. Operations, evaluation, privacy, and relevant customer-facing specialists contribute. Staff need clear authority to raise a case’s priority and report concerns.

Map / consequences

The team describes what enters the queue, the available complaint information, language coverage, and the people affected by delay. One failure scenario is that an urgent complaint receives low priority because the customer expresses the problem indirectly. The system boundary includes assignment and staff workload, not only the model.

Measure / relevant evaluation

The review asks for evaluation on representative complaint types and operating conditions, with separate examination of missed urgent cases and relevant language groups. The team also tests overrides, queue-age alerts, and an outage fallback. Overall accuracy is retained as one result, with its limits made explicit.

Manage / the unresolved gap

Assume, for illustration, that testing identifies a weak complaint category and that the fallback has not been demonstrated at expected volume. The owner records the issue, mitigation options, and required follow-up. A confident vendor presentation does not close either finding.

Review decision

Defer unrestricted use. Consider a bounded trial only if the authorized decision-maker finds the remaining risks acceptable and the proposed safeguards are demonstrated. Record the permitted scope, evidence, conditions, and stop triggers.

An illustrative trial plan could preserve the existing route for urgent cases, add review of low-priority cases, and use queue-age triggers to identify harmful delay. The owner would need to justify the coverage and staffing: calling a safeguard “human review” does not establish that it can operate at the required volume.

If the trial reveals further failures, update the Current Profile and revisit the Target Profile or deployment decision. If the vendor changes the ranking model or an upstream data field, reassess which results remain relevant. The framework helps organize that reasoning; it does not supply a universal acceptance threshold.

All organizations, findings, and decisions in this example are fictional. No empirical performance, client engagement, or NIST endorsement is claimed.

07 / A practical starting method

Start with one consequential decision.

A focused first application can reveal governance gaps without beginning with a large documentation exercise. The sequence below is an InfoSecured working method; tailor it to existing processes and the significance of the proposed use.

Define the review boundary

Select one use and one decision: acquisition, trial, deployment, expansion, or continued operation. Name the system version, intended benefit, affected people, and decision-maker.
Build a focused profile

Review the Core for relevant outcomes. Record the present state, desired state, evidence available, and reasons for exclusions. Bring in the people who understand the workflow and its consequences.
Close the decision-critical gaps

Choose the evidence most likely to change the decision. Assign the necessary testing, investigation, or operational change, with an owner and completion criterion. Do not equate document count with readiness.
Record the response and keep it current

Document the decision, limits, unresolved risks, and responsibilities. Specify what will trigger a new review: a material change, incident, performance shift, or evidence that actual use has moved beyond the assessed context.

At the end, a reviewer should be able to trace a few important risks from the use case to evaluation, action, and ongoing oversight. That is a stronger first result than a fully populated spreadsheet whose entries never affect a decision.

08 / Limits & related resources

Use the right tool for each part of the problem.

The AI RMF does not determine the organization’s acceptable level of risk. NIST leaves risk tolerance dependent on context and applicable constraints. A completed mapping also cannot establish that a system is lawful, safe in every setting, or free from failure. [1]

Legal applicability: Identify the actual obligations separately.Use qualified interpretation of the relevant law, role, jurisdiction, and activity. Treat an AI RMF mapping as support for risk management, not evidence that every legal duty has been satisfied.
Generative AI: Add the NIST Generative AI Profile where relevant.NIST AI 600-1 supplements the RMF with risks and suggested actions for generative AI. It is a companion profile, not a replacement for AI RMF 1.0. If the complaint tool adds generated summaries, evaluate that capability and its effects on reviewers. [4]
Evaluation & assurance: Test the claims that matter in the actual setting.A framework identifies outcomes to pursue; it does not perform the evaluation. The AI Assurance guide explains how evidence can support a bounded conclusion.
Suppliers & oversight: Connect the framework to operating responsibilities.Use Vendor AI Risk for supplier dependencies and Human Oversight for authority, intervention, and reviewer conditions.

Keep the record of the edition and source material used for a decision. When NIST publishes a revision, assess what changed before replacing mappings or conclusions. Preserve the original basis for historical decisions and identify which current uses need reassessment.

09 / Common questions

Questions about applying the NIST AI RMF.

Is the NIST AI RMF mandatory?

NIST publishes it as a voluntary framework. Separately, an organization may adopt it in policy or encounter a contract or other applicable requirement that refers to it. Identify the authority behind such an obligation rather than treating voluntary guidance itself as law. [2]

Does an AI RMF assessment mean the system is NIST-approved?

No. Mapping evidence to the framework does not itself establish an approval or endorsement from NIST. Any assessment should identify its author, scope, methods, findings, and limitations.

Must every Playbook action be implemented?

No. The Playbook supplies voluntary suggestions. Select and justify actions that fit the setting, while ensuring that important risks are not excluded merely because they are difficult to evaluate. [3]

Does AI RMF 1.0 apply only to generative AI?

No. It addresses AI risk broadly. The Generative AI Profile adds more specific material for generative systems; it does not redefine the whole framework around large language models. [1] [4]

Can a small organization use it?

Yes. NIST intends the framework to be scalable across organizational sizes. Start with a bounded use case, clear accountability, and proportionate evidence. Limited resources make prioritization important; they do not make missing evidence equivalent to low risk. [5]

10 / Resources & next steps

Make the next risk decision reviewable.

Read the official AI RMF 1.0 alongside the NIST Playbook. Use the Frameworks & Standards directory to understand where other instruments may complement it.

For organizing claims and supporting material, the AI Assurance Evidence Review Kit is a general evidence-review resource. It is not a complete AI RMF implementation package or a NIST assessment. The Evidence Library lists the available resources and their versions.

A useful next step is to choose one unresolved AI risk decision and complete the selected outcome-to-evidence mapping above. Identify which missing result could change the decision, then give that work a named owner.

11 / Sources & approach

Sources & editorial approach

This guide explains NIST AI RMF 1.0 using NIST’s freely available framework, Playbook, program information, and companion resources. NIST-defined functions and subcategory references are distinguished from InfoSecured’s original evidence suggestions and worked example. No implementation, certification, or legal conclusion is implied by a completed mapping.

NIST AI 100-1 — Artificial Intelligence Risk Management Framework (AI RMF 1.0), January 2023Primary reference. Executive Summary; §1.2.2, risk tolerance; §3, trustworthiness; §5 and Tables 1–4, Core; §6, Profiles. Printed pages 1–3, 7, 12–18, and 20–34. PDF viewer page numbers are five higher than printed page numbers.
NIST — AI Risk Management Framework program pageEdition/status check, 29 September 2026: AI RMF 1.0 remains linked as the published framework; NIST states that a revision is in progress.
NIST AI Resource Center — AI RMF PlaybookSuggested actions and documentation considerations. NIST describes the Playbook as voluntary and not a checklist or mandatory sequence.
NIST AI 600-1 — Generative Artificial Intelligence Profile, July 2024Companion profile for generative AI; introduction and risk overview. Used here to explain the relationship between the publications, not to present a full GenAI implementation guide.
NIST — AI Risk Management Framework FAQsQuestions 1–5: purpose, trustworthiness tradeoffs, intended audience, scalability, and voluntary use.

Reviewed 29 September 2026. Examples, review questions, and record structures are InfoSecured’s practical synthesis; they are not prescribed templates from the cited organizations. Editorial standards.

Back to the beginning