NIST AI RMF: What It Asks and Your First 30 Days

Answer “Do you follow the NIST AI RMF?” with evidence for a named AI system: who owns its risks, what you tested, what you allow it to do, and what happens when it fails. The framework has 4 functions and is voluntary; your first 30 days should establish a working risk process and an accurate account of its gaps. NIST’s framework supplies the structure.

The National Institute of Standards and Technology (NIST) AI Risk Management Framework (AI RMF) helps organizations address risks to people, organizations and society when designing, developing, deploying or using AI. It applies beyond the model: the people, data, permissions and setting around a system matter too. AI RMF 1.0 describes that broader scope.

For a company with 20 to 200 people putting large language models, or LLMs, into production, the useful starting point is a scoped implementation. Pick a consequential feature, connect its risks to decisions and records, then expand. Buying a model from another company does not tell a customer how you control the feature built around it.

Source check: 26 October 2026. The framework, Playbook and Generative AI Profile were checked against NIST’s live pages and publications. NIST’s framework page says AI RMF 1.0 is being revised and still links that version. That statement is not a published replacement or a replacement release date.

How the NIST AI RMF Framework Works

The framework asks you to connect accountability, context, evidence and action throughout a system’s life. Think of a building’s fire-safety plan: knowing the exits is useful, but you also need someone responsible for keeping them clear, a way to check them, and a response when something goes wrong.

NIST AI 100-1: The Core Document

NIST AI 100-1 is the publication identifier for AI RMF 1.0, released on 26 January 2023. Its first part explains risk and trustworthiness; its second part contains the Core and Profiles. The Core organizes risk management into Govern, Map, Measure and Manage, each with categories and subcategories. These describe outcomes and actions rather than a universal pass-or-fail audit checklist. NIST framework and release information; AI RMF 1.0, Parts 1 and 2.

The trustworthiness characteristics cover whether a system is valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair with harmful bias managed. A fluent answer alone establishes none of those things. NIST discusses the characteristics and their tradeoffs in AI RMF 1.0, Section 3.

For example, a support assistant might answer product questions accurately while exposing another customer’s records. A useful assessment must examine both the answer and the access boundary. Measuring only answer quality would miss the more consequential failure.

NIST AI RMF Playbook: Choose Actions That Fit

The NIST AI RMF Playbook adds suggested actions, references and guidance for achieving the Core’s outcomes. NIST explicitly allows organizations to use the suggestions that fit their needs; it does not expect every organization to implement everything. The Playbook is not an ordered checklist. NIST Playbook; NIST Playbook FAQs.

Use it when a risk needs a practical response. If your support assistant can expose private records, look for actions concerning data, access, measurement and incident handling. Record what you selected, why it fits and how you know it operates. Copying every suggestion into a spreadsheet creates work without deciding whether the feature should ship.

The Four Functions and the Records a Small Team Keeps

Keep the functions connected. Govern applies across Map, Measure and Manage, and the work is iterative across the AI lifecycle. You may revisit the context after a test exposes a new risk or change a policy after an incident. NIST does not prescribe a one-way sequence. NIST AI RMF Core.

The following artifact mapping is our proposed small-team implementation. NIST defines the outcomes; these record formats and owners are practical choices for producing evidence of them. An artifact can support several functions.

The identifiers and outcome descriptions above come from the NIST Core’s function tables. They are selected anchors, not a claim that this table covers every subcategory.

Govern: Give Someone Authority to Say Stop

Govern establishes policies, accountability and the culture needed to manage risk. NIST includes documented roles, executive responsibility, staff training and human oversight within this function. NIST Core, Govern.

In a hypothetical 40-person software company, the founder could own the risk policy, the support lead could own the assistant, and an engineer could own its access controls. Those people need authority as well as names on a page. Specify who can pause the feature and who can accept the risk left after safeguards are applied, called residual risk.

An executable human-oversight rule might say: “The assistant may draft replies using approved support material. A support employee must check the source and recipient before sending. The assistant has no permission to issue refunds or change account access. The support lead can disable it; restart requires the engineering owner and support lead.”

That rule is an illustrative design choice. A different workflow may justify different permissions. What matters is that the deployed access and review behavior match the rule.

Map: Describe the Feature, Not Just the Model

Map establishes the context needed to understand risks and impacts, including system components and third parties. It also supports deciding whether an AI solution is appropriate in the first place. NIST Core, Map.

Give the support assistant its own inventory entry. Record its purpose, owner, audience, data categories, retrieval sources, connected systems, model or service identifier, permitted actions and approval status. Add people affected by its mistakes, including customers who never interact with the assistant directly.

Then write a risk as a cause, event and consequence: “An incorrect account filter retrieves another customer’s ticket; the assistant includes it in a draft; a reviewer sends confidential information to the wrong customer.” “Privacy risk” alone does not tell an engineer what to fix.

Keep the proposed safeguards beside the scenario, with an owner, status and evidence link. A changed purpose or new permission deserves a new assessment even if the underlying model stays the same.

Measure: Test the Risk You Named

Measure uses quantitative, qualitative or mixed methods to assess risks and trustworthiness. NIST includes testing under conditions similar to deployment, documenting limitations, and evaluating areas such as security, privacy and harmful bias. NIST Core, Measure.

For the support assistant, keep cases for an ordinary question, missing source material, conflicting policies, another customer’s records, and a malicious instruction embedded in retrieved text. Prompt injection means an attacker supplies instructions intended to redirect the system’s behavior; NIST’s Generative AI Profile, Section 2.9 discusses both direct attacks and attacks through material the system retrieves.

Each evaluation record should identify the configuration tested, case inputs, expected behavior, actual output or action, reviewer and result. Link a failed case to the risk it exposes. Preserve sensitive evidence under appropriate access controls rather than copying customer data into a general-purpose report.

Write acceptance criteria before reviewing results. In this example, a cross-customer disclosure blocks release even if the rest of the answers look good. That is a proposed release rule, not a NIST threshold. A small test set can find a failure; passing it does not establish that failures cannot occur.

Manage: Turn Findings Into Decisions

Manage prioritizes risks and allocates resources to address them. NIST includes decisions about whether development or deployment should proceed, options such as mitigating or accepting risk, mechanisms to deactivate systems, and ongoing monitoring and incident response. NIST Core, Manage.

If the account-boundary test fails, disable the affected retrieval path, fix the authorization control and retest before restoring access. If a failure is less consequential, document why a limited release with monitoring is acceptable and who made that decision. “Accepted” without a rationale or accountable approver is weak evidence.

Maintain an incident log with the detection time, affected system and configuration, known impact, containment, evidence location, communications, corrective action and restart approval. Record near misses too. When nothing has happened, an empty log is honest; pair it with a clearly labeled rehearsal showing that someone can execute the response.

NIST AI 600-1: What the Generative AI Profile Adds

NIST AI 600-1, the Generative Artificial Intelligence Profile, applies the framework to risks unique to or intensified by generative AI. Published on 26 July 2024, it is a companion to AI RMF 1.0, not a replacement framework or a separate certification. NIST publication page.

The Profile identifies 12 risk areas and offers suggested actions mapped to the framework. Its development focused on governance, content provenance, testing before deployment and incident disclosure. Content provenance concerns where content came from and its history. Those considerations help connect generated outputs to accountable operating practices. NIST AI 600-1, Introduction, Section 2 and Appendix A.

For the support assistant, begin by translating relevant risks into specific failure cases:

• Confabulation: A confident but false answer invents a refund entitlement. Keep the expected policy answer and check whether the system’s cited material supports it.
• Data Privacy and Information Security: Customer data leaks, or malicious retrieved content redirects the assistant. Test both data-access boundaries and behavior under hostile inputs.
• Human-AI Configuration: A reviewer over-trusts a polished draft. Give that person the underlying source, rejection criteria and authority to stop the action.
• Harmful Bias or Homogenization: Service quality differs across relevant user groups or languages. Examine the contexts you actually serve and document the limits of the evidence.
• Value Chain and Component Integration: A model, data source or integration changes without your understanding its effect. Keep dependency and change records, then reassess affected risks.

These are implementation examples drawn from the Profile’s risk descriptions, not a reduced official checklist. The other named areas are CBRN Information or Capabilities (chemical, biological, radiological or nuclear); Dangerous, Violent, or Hateful Content; Environmental Impacts; Information Integrity; Intellectual Property; and Obscene, Degrading, and/or Abusive Content. Consider their relevance to your system and document your reasoning. The full definitions are in NIST AI 600-1, Section 2.

A useful way to work through the Profile is to record the applicable risk, chosen action, owner and evidence, then explain material exclusions. For an agent that can take actions through connected software, evaluate the action path as well as the text it generates. An accurate draft does not demonstrate that an account change was authorized.

Your First 30 Days: A Suggested Operating Plan

Aim for a demonstrable process on a defined scope. This schedule is our recommendation, not a NIST deadline, maturity level or guarantee of completion. Keep governance active throughout it; the calendar is a way to organize the first month, not a sequence imposed by the framework.

1. 1

   Days 1-5: Establish scope and ownership

   Name an accountable executive and a system owner. Inventory current AI uses, including features embedded in software you already buy. Choose a production feature with meaningful customer, data or action risk for the first detailed assessment.

   Write its purpose and boundaries, identify affected people, and collect the existing release, access and incident procedures. Record gaps in discovery rather than declaring the inventory complete without evidence.

   Keep: The initial inventory, named responsibilities and a human-oversight rule checked against the feature’s actual permissions.

2. 2

   Days 6-10: Map failures and choose responses

   Walk the chosen feature with its builder and the person who operates the workflow. Include someone able to challenge assumptions about customer impact. Trace inputs, retrieved material, outputs and connected actions.

   Write harm scenarios in the risk register. Use the Generative AI Profile to challenge the list. Prioritize by potential impact and likelihood, including uncertainty, and assign a treatment owner. Decide which failures block release and which require a narrower operating scope.

   Keep: The system description, risk register, selected actions, evidence gaps and proposed acceptance criteria.

3. 3

   Days 11-20: Evaluate the deployed design

   Run representative, failure and adversarial cases against the configuration you intend to use. Record model or service identifiers, prompts, retrieval settings and tool permissions to the extent they are available. If a provider hides a relevant detail, preserve that limitation in the assessment.

   Include the human handoff: can a reviewer recognize a bad answer, find the source and reject it? Fix failures and record the retest. Get a reviewer other than the builder where feasible; a tiny company can use a suitably qualified outside reviewer for consequential decisions.

   Keep: Versioned evaluation records, unresolved findings and links to the associated risks. Do not turn an untested assumption into a passing result.

4. 4

   Days 21-30: Decide, rehearse and report

   Approve, narrow or pause the feature based on the evidence. Name the person who accepts remaining risk and set review triggers for changes to data, models, purpose or permissions.

   Rehearse an incident: a customer reports another account’s information in an answer. Confirm who can disable access, preserve evidence, assess impact, coordinate communications and authorize restart. Label the exercise as a rehearsal.

   Keep: A documented release decision, monitoring responsibility, incident log and a short customer or board statement distinguishing operating controls from unfinished work.

NIST AI RMF Training: Rehearse a Decision

Train people for the decisions they own. GOVERN 2.2 addresses risk-management training for personnel and partners; the outcome is being able to perform their responsibilities. NIST Core, Govern.

For a support lead, that means recognizing an unsafe disclosure, pausing the assistant and escalating it. For an engineer, it means knowing which permission change requires reassessment. Keep the scenario, attendees, decisions and follow-up actions from a rehearsal. A course completion record alone does not demonstrate that the production response works.

NIST also describes Current Profiles and Target Profiles, which capture existing and desired risk-management outcomes. Comparing them exposes work still to do. A small company can use that distinction in its evidence index: implemented, partially implemented, planned, or not applicable with a rationale. Those status labels are our suggestion. AI RMF 1.0, Section 6.

What to Tell a Customer, Auditor or Board

Describe the scope and maturity of your work before using an alignment label. A customer evaluating a support assistant needs to know whether your evidence covers that feature, the current configuration and its permitted actions.

If implementation is still under way, say so. For example:

We are implementing NIST AI RMF practices for our customer-support assistant. Ownership, system inventory and risk assessment are in place. Evaluation and incident-response rehearsal remain open. The feature stays within its existing restricted scope until those decisions are complete.

If the practices operate and the records support it, a fuller answer could be:

We use NIST AI RMF 1.0 to organize risk management for our customer-support assistant, with relevant actions from the Generative AI Profile. We maintain ownership and oversight rules, system and risk records, evaluation evidence, and incident procedures. Our scope statement identifies the configurations assessed, known limitations, open actions and next review. This is our description of implementation, not NIST certification.

These are illustrative statements to adapt to your actual evidence. Do not copy the stronger one while its supporting controls remain planned.

Send a short evidence index with document owners, dates and access-controlled links. For each claim, distinguish the policy from a record showing it happened. The oversight rule describes what should occur; a reviewed release or approval record shows operation. Share a redacted assessment where the underlying evidence contains customer data or sensitive security details.

For the board, emphasize consequential unresolved risks, decisions needed and who owns them. A percentage of spreadsheet rows completed can hide the single open issue that should prevent deployment.

What Builders, Operators and Buyers Should Do Differently

Builders: Treat new authority as a design change. Adding refund access to a drafting assistant changes the risk even when the model and prompt stay fixed. Update the system description, permission tests and approval decision before enabling it.

Operators: Keep feedback connected to the risk register. A recurring complaint about invented policy should become an investigated failure pattern, an evaluation case and a decision about continued use. Assign someone to close that loop.

Buyers and founders: Ask for the assessed scope, recent evaluation evidence and remaining limitations. A supplier’s alignment statement should explain what they control and what you must configure or monitor yourself.

Act now when a feature touches sensitive information, affects a consequential decision, sends material to customers or can change external records. Keep a lighter process for a bounded experiment using public or synthetic information with no external action. Wait to expand autonomy when you cannot demonstrate the permission boundary, review path or stop mechanism. These are proposed prioritization rules, not NIST risk classifications.

A framework revision does not make known exposures disappear. Continue managing them while keeping the version used in your documentation explicit.

Where ISO/IEC 42001 and the EU AI Act Fit

Use the documents for their distinct purposes. ISO/IEC 42001:2023 specifies requirements for an organizational AI management system. Organizations can seek independent certification of that management system; ISO itself does not issue certificates. ISO’s standard overview; ISO’s explanation of certification.

The European Union AI Act imposes legal obligations according to the relevant role, system and use. AI RMF records may support your work, but alignment does not establish compliance with the Act. Check the European Commission’s AI Act guidance for the applicable rules and timetable, and use our EU AI Act page for the related site coverage.

Our AI governance framework supplies the company-level ownership layer; the AI acceptable use policy supplies employee-facing rules. Connect those to system evidence rather than maintaining disconnected policies for each framework.

What’s Overhyped: Certificates, Completion Scores and Safe Models

The biggest overstatement is that adopting the framework establishes that a system is safe. NIST’s guidance organizes risk management; the useful evidence remains specific to the system, context and decisions. Its Core is explicitly flexible and iterative. NIST AI RMF Core.

NIST AI RMF Certification Is Not a NIST Credential

NIST does not certify organizations against the AI RMF. Describe your implementation, scope and evidence; do not claim “NIST-certified.” An independent assessment can be useful, but its report should state who assessed what and against which criteria. It does not become a NIST-issued certificate. The official starting point is NIST’s voluntary AI RMF.

A completed checklist is not a risk decision. NIST does not specify a universal risk tolerance, and the Playbook does not require every suggested action. Choose acceptance criteria appropriate to the potential harm and explain them. AI RMF 1.0, Section 1.2.2; Playbook guidance.

A supplier’s evidence does not cover your whole application. Your retrieval data, access controls, integrations and users add context. NIST expressly addresses third-party components and their ongoing management; retain supplier evidence while testing your own operating design. NIST Core, Map and Manage.

Human review is not a magic safeguard. A reviewer needs the source, time, relevant knowledge and authority to intervene. If your workflow makes approval automatic in practice, change the workflow before describing it as effective oversight.

Frequently Asked Questions

Why is an AI RMF necessary?

AI risk involves the interaction of technology, people and deployment context. The framework helps organizations manage those interactions across the lifecycle, including impacts on people beyond the direct user. It is a voluntary resource, not a legal requirement to adopt it. NIST AI RMF 1.0.

What are 5 risks of AI?

For a generative AI feature, five useful examples are false but confident outputs, privacy leakage, harmful bias, over-reliance by people, and attacks that redirect system behavior. These correspond to areas discussed in the Generative AI Profile; they are not its complete risk list. NIST AI 600-1, Section 2.

What is the main purpose of the NIST risk management framework (RMF)?

For the AI RMF discussed here, the purpose is to help organizations manage AI risks and incorporate trustworthiness into development and use. Specify “AI RMF” in a customer response so the framework you mean is clear. NIST framework overview.

Is NIST AI RMF mandatory?

The framework itself is voluntary. Check any separate contractual, procurement or legal commitments applicable to your business; adopting a voluntary framework does not settle those obligations. NIST framework overview.

What is RMF being replaced with?

For the AI RMF, NIST’s page checked on 26 October 2026 says version 1.0 is being revised and continues to link it. Do not infer a released successor from that notice. NIST AI 600-1 is a companion Generative AI Profile. NIST framework page.

Will Frm be replaced by AI?

You cannot infer whether financial risk management work will be replaced from the AI RMF. This framework addresses how organizations manage AI risks, including human responsibilities and oversight; it does not establish a forecast about replacing a profession. NIST Core, Govern.

What are the top 3 cybersecurity frameworks?

There is no universal top-three ranking for every organization. Choose cybersecurity guidance according to your systems, obligations and assurance needs. For this decision, use the AI RMF to address AI-specific risks alongside your existing security program; its security and resilience outcomes do not cover the whole cybersecurity function. NIST AI RMF 1.0.

Is cybersecurity a dying field?

Introducing AI does not remove your need for security work. The AI RMF includes evaluating security and resilience, managing third-party risks and responding to incidents. For a production operator, those remain responsibilities to assign and demonstrate. This is an operating consequence, not a labor-market forecast. NIST Core.

What is the #1 cybersecurity threat today?

No single threat deserves that ranking for every company. Prioritize what can cause harm in your deployment. For the support assistant example, unauthorized data access and prompt injection deserve explicit tests; their priority depends on the data and permissions involved. NIST Generative AI Profile, Section 2.9.

The Monday Move

Open the inventory with the owner of your most consequential AI feature. Choose a plausible failure, identify who could be harmed, and trace it to a test, a release decision and a stop procedure. If the connection breaks, make that gap the next action with a named owner.

That gives your next customer answer a concrete foundation: the system in scope, the evidence that exists, and the work still required.

For practical notes on putting AI into production, join the newsletter.