NIST AI Risk Management Framework: Enterprise Implementation Guide

What Is the NIST AI RMF?

In short

The NIST AI RMF (AI 100-1) is a voluntary, technology-neutral framework for managing AI risks, structured around four core functions: GOVERN, MAP, MEASURE, and MANAGE. It was published January 26, 2023, and is increasingly referenced by regulators globally.

The NIST AI Risk Management Framework (AI RMF 1.0) is a voluntary framework published by NIST on January 26, 2023, authored by Elham Tabassi. It is structured around four core functions — GOVERN, MAP, MEASURE, MANAGE — designed to help organizations identify, assess, and reduce AI-related risks across the full AI lifecycle.

The framework is not a checklist. It is a flexible, risk-based approach that organizations adapt to their size, sector, and specific AI use cases.

Voluntary — But With Real Consequences

Despite being voluntary, the AI RMF has become a de facto governance standard. It is referenced in US federal AI policy, EU AI Act risk management provisions, and federal procurement requirements for AI systems.

NIST developed the framework over two years through a multi-stakeholder process involving industry, academia, and civil society — giving it broader legitimacy than most government-issued guidance documents.

On July 26, 2024, NIST published a Generative AI Profile authored by Autio, Schwartz, Dunietz et al., extending the framework specifically for LLMs and foundation models. This profile introduces 12 unique risk categories not covered in the original 2023 document.

AI RMF vs. ISO/IEC 42001: Key Differences

NIST publishes formal crosswalk documents that map AI RMF categories to ISO/IEC 42001, OECD AI Principles, and EU AI Act requirements. This reduces duplication for enterprises operating under multiple frameworks simultaneously.

Why Enterprises Are Adopting the NIST AI RMF in 2025–2026

Regulatory convergence is the primary driver. The EU AI Act, which entered into force in August 2024, requires documented risk management systems for high-risk AI — the NIST AI RMF provides a ready-made structure that satisfies these requirements when properly documented.

US federal agencies are required to align AI procurement with AI RMF principles per OMB Memorandum M-24-10, issued in 2024. For enterprises selling to government or regulated sectors — finance, health, defense — AI RMF alignment is increasingly a commercial prerequisite.

• EU AI Act (August 2024): High-risk AI systems require documented risk management — AI RMF provides a recognized structure.
• OMB M-24-10: US federal agencies must align AI procurement with AI RMF principles.
• OECD AI Catalogue (July 2024): Notes the framework's growing international adoption beyond the US.
• Enterprise procurement: Government and regulated-sector customers are requiring AI RMF alignment as a vendor qualification criterion.

For a broader view of how AI governance integrates with enterprise strategy, see our guide on what is AI governance and how it maps to organizational risk management.

The Four Core Functions of the NIST AI RMF

In short

The NIST AI RMF core consists of four functions — GOVERN, MAP, MEASURE, MANAGE — each subdivided into categories and subcategories that define specific risk management outcomes for organizations to achieve.

The four functions are not sequential phases. GOVERN is a cross-cutting function that operates continuously, while MAP, MEASURE, and MANAGE follow a logical progression through the AI risk lifecycle.

Each function is subdivided into categories and subcategories — 72+ subcategories in total across the framework — with specific outcomes organizations are expected to demonstrate.

GOVERN: The Foundation of Everything

GOVERN establishes the organizational culture, policies, and accountability structures that make risk management possible. Without GOVERN in place, MAP, MEASURE, and MANAGE have no mandate or authority.

Key GOVERN activities include:

• AI Risk Policy: Publish a formal policy defining acceptable AI use, risk tolerance thresholds, and accountability chains.
• Roles & Responsibilities: Assign explicit ownership — who is accountable for each AI system's risk profile.
• Third-Party AI: Extend governance to vendor-supplied AI tools, APIs, and embedded models.
• Workforce Readiness: Ensure teams have the training to identify and escalate AI risks.

MAP: Know What You Have

MAP requires organizations to identify every AI system in use, document its context, and classify potential risks. Most enterprises discover significantly more AI deployments during this step than they expected — including shadow AI tools.

For a structured approach to identifying undisclosed AI usage across your organization, see our analysis of what is shadow AI and how it surfaces during AI risk mapping exercises.

• AI System Inventory: Catalog all AI systems including third-party tools, embedded models, and experimental pilots.
• Context Documentation: For each system, document purpose, data inputs, decision outputs, and affected populations.
• Risk Identification: Flag potential failure modes — bias, drift, security vulnerabilities, regulatory exposure.

MEASURE: Quantify the Risk

MEASURE converts identified risks into assessable, trackable metrics. This is where qualitative risk descriptions become quantitative data that can inform prioritization decisions.

• Bias Testing: Run structured evaluations for demographic parity, equalized odds, and disparate impact across model outputs.
• Performance Monitoring: Track model accuracy, drift indicators, and output quality against defined thresholds.
• Evaluation Documentation: Every assessment must be documented with methodology, results, and sign-off — not just flagged in a meeting.

MANAGE: Act on What You Find

MANAGE is where identified and measured risks become concrete response actions. This includes risk treatment decisions, control deployment, incident response planning, and ongoing monitoring cadence.

• Risk Response Plans: For each significant risk, document the chosen response: accept, mitigate, transfer, or avoid.
• Residual Risk Tracking: After controls are deployed, document what risk remains and who has accepted it.
• Incident Response: Maintain an AI-specific incident response plan with defined escalation paths and communication protocols.
• Continuous Monitoring: Set review cadences — quarterly for high-risk systems, annually for low-risk — and automate alerts where possible.

Step 1 — Build Your AI Governance Structure

In short

Effective AI RMF implementation starts with a formal governance structure: an AI Risk Committee, defined ownership roles, and a published AI risk policy — all under the GOVERN function.

Before you can map or measure AI risk, you need an accountable structure. The GOVERN function requires organizations to establish who owns AI risk decisions, at what level, and with what authority.

In our experience across 100+ enterprise AI governance deployments at Alice Labs, the organizations that move fastest through implementation are those that appoint a named AI Risk Owner in the first two weeks — not a committee, a person.

Establish an AI Risk Committee

The AI Risk Committee is the cross-functional body that reviews, approves, and monitors AI risk decisions. It should meet monthly during implementation and quarterly thereafter.

Recommended committee composition:

• Chief AI Risk Officer (or designate): Chairs the committee, owns the AI risk policy, reports to the board.
• Legal & Compliance: Monitors regulatory requirements, owns regulatory mapping to EU AI Act and sector rules.
• IT / Security: Bridges AI RMF with the existing NIST Cybersecurity Framework deployment.
• Data & Analytics: Owns model documentation, evaluation results, and data governance.
• Business Unit Representatives: Bring use-case context and flag emerging AI deployments before they become shadow AI.
• HR / Ethics: Covers workforce impact, bias governance, and internal AI use policy enforcement.

Publish an AI Risk Policy

The AI risk policy is the governing document that defines your organization's risk tolerance, acceptable use boundaries, and accountability expectations. It must be board-approved and published internally before MAP activities begin.

A production-ready AI risk policy covers six elements:

1. Scope: Which AI systems and use cases are covered.
2. Risk tolerance: Explicit thresholds for acceptable vs. unacceptable AI risk by category.
3. Accountability: Named owners for each AI system and risk category.
4. Third-party AI: How vendor-supplied AI is evaluated and approved.
5. Incident escalation: What triggers an AI incident report and who receives it.
6. Review cadence: How often the policy itself is reviewed and updated.

Integrate with Existing ERM and Cybersecurity Governance

The AI RMF is not a standalone program — it integrates with your existing Enterprise Risk Management (ERM) framework and cybersecurity governance. NIST explicitly designed the AI RMF to complement the NIST Cybersecurity Framework, not replace it.

Map AI risk categories to your existing ERM taxonomy in the first 30 days. This prevents duplicate governance structures and makes AI risks visible to the board through existing reporting channels.

For context on how AI governance fits within a broader enterprise AI strategy, our guide on enterprise AI strategy framework covers the organizational design decisions that precede formal governance deployment.

Step 2 — Map Your AI System Portfolio

In short

The MAP function requires building a complete AI system inventory, documenting each system's context and risk profile, and classifying systems by risk tier — typically high, medium, and low.

MAP is where many enterprises discover the true scale of their AI exposure. Most organizations we work with at Alice Labs find 30–50% more AI systems during the MAP phase than their IT inventory recorded — primarily due to shadow AI and embedded third-party models.

The output of the MAP function is a risk-categorized AI system inventory that feeds directly into MEASURE prioritization.

Build a Complete AI System Inventory

An AI system inventory is not an IT asset list. It captures the context, purpose, and risk profile of each AI deployment — not just its technical specifications.

For each AI system, document:

• System name and owner: Named individual accountable for this system's risk profile.
• Purpose and use case: What decision or task does this system support?
• Data inputs: What data does the system consume — including PII, sensitive categories, or third-party data feeds?
• Decision outputs: What actions or recommendations does the system produce, and who acts on them?
• Affected populations: Who is impacted by this system's outputs — employees, customers, regulated individuals?
• Deployment environment: Production, pilot, or experimental?
• Third-party components: Vendor models, APIs, or embedded AI features?

Classify Systems by Risk Tier

Not all AI systems carry equal risk. Use a three-tier classification to prioritize MEASURE and MANAGE resources toward the systems with the highest potential for harm.

Align Risk Tiers with EU AI Act Categories

If your organization operates in the EU or serves EU customers, align your risk tier classification with EU AI Act categories from the start. High-risk AI systems under the EU AI Act require technical documentation and conformity assessments that the AI RMF MAP output directly supports.

Our EU AI Act compliance checklist maps directly to the AI RMF MAP outputs, reducing duplication for enterprises managing both frameworks simultaneously.

Step 3 — Measure AI Risk with Quantitative and Qualitative Methods

In short

The MEASURE function uses structured evaluation methods — bias testing, performance benchmarking, explainability assessments, and red-teaming — to convert identified risks into documented, trackable metrics.

MEASURE is the function that separates governance programs from governance theater. Without documented, repeatable measurement, risk claims are unverifiable and unactionable.

Apply MEASURE to high-risk systems first. Medium-risk systems follow within 60 days of completing high-risk assessments. Low-risk systems can use lightweight self-assessment checklists.

Quantitative Risk Metrics

Quantitative MEASURE activities produce numbers that can be tracked over time:

• Bias metrics: Demographic parity difference, equalized odds, disparate impact ratio — measured across protected characteristics.
• Model performance: Accuracy, precision, recall, F1 score against defined thresholds — with degradation alerts when performance drops below baseline.
• Drift monitoring: Statistical distance between training data distribution and live inference data — tracked weekly for high-risk systems.
• Incident rate: Number of AI-related incidents or escalations per quarter, categorized by system and risk type.

Qualitative Risk Assessment Methods

Not all AI risks are quantifiable. Qualitative methods capture risks that metrics alone miss — particularly in explainability, trust, and stakeholder impact dimensions.

• Red-teaming: Adversarial testing by a team attempting to produce harmful, biased, or incorrect outputs — document findings and reproduce in test environments.
• Stakeholder impact assessment: Structured interviews with affected populations or their representatives — required for high-risk systems under EU AI Act Article 9.
• Explainability review: Assess whether outputs can be explained to affected individuals in plain language — critical for regulated decisions.
• Scenario analysis: Tabletop exercises testing system behavior under edge cases, adversarial inputs, and failure modes.

Document Every Evaluation

Every MEASURE activity must produce a documented artifact — not a meeting note, a formal evaluation record with methodology, results, reviewer sign-off, and date.

This documentation is the evidence base for regulatory audits, board reporting, and incident investigations. Undocumented evaluations provide no governance value regardless of what they found.

For context on how MLOps tooling can automate parts of the MEASURE function, see our guide on what is MLOps — continuous evaluation pipelines reduce manual MEASURE overhead by instrumenting monitoring directly into deployment infrastructure.

Step 4 — Manage and Respond to Identified AI Risks

In short

The MANAGE function converts measurement results into formal risk response decisions — accept, mitigate, transfer, or avoid — with documented controls, monitoring cadences, and incident response plans.

MANAGE is not just about deploying controls. It is about making explicit, documented decisions about what level of risk is acceptable — and who has accepted it.

Every risk identified in MAP and quantified in MEASURE must receive a MANAGE disposition. Undispositioned risks are the governance equivalent of unfiled incident reports.

Four Risk Response Options

For each identified AI risk, the risk owner selects one of four responses aligned with standard ERM practice:

• Mitigate: Deploy controls to reduce likelihood or impact — most common response for medium and high-risk findings.
• Accept: Document that residual risk is within tolerance — requires named sign-off at the appropriate authority level.
• Transfer: Shift risk through contractual means — vendor indemnities, insurance, or liability clauses in AI procurement contracts.
• Avoid: Discontinue the AI system or use case — appropriate when risk exceeds tolerance and cannot be adequately mitigated.

Build an AI Controls Library

An AI controls library documents every technical and organizational control deployed against identified risks. It maps controls to specific risk categories and tracks their effectiveness over time.

AI Incident Response Plan

Every organization deploying high-risk AI systems needs a written AI incident response plan before those systems go live. The plan defines what constitutes an AI incident, who is notified, within what timeframe, and what remediation steps follow.

An AI incident response plan covers five elements:

1. Incident definition: Specific criteria for what triggers an AI incident report — not vague thresholds.
2. Escalation chain: Named contacts at each level — team lead, AI Risk Officer, Legal, Board if material.
3. Response timeline: Maximum hours from detection to notification for each severity level.
4. Containment procedures: Steps to limit harm — including system suspension authority and customer notification protocols.
5. Post-incident review: Root cause analysis format and required changes to the AI RMF documentation.

Understanding why AI deployments fail is critical context for incident response planning. Our analysis of why AI projects fail identifies the governance gaps most commonly implicated in AI incidents across enterprise deployments.

The 2024 NIST Generative AI Profile: Extending the Framework for LLMs

In short

Published July 26, 2024, the NIST Generative AI Profile extends the AI RMF to address 12 unique risk categories specific to GenAI systems — including hallucination, data poisoning, homogenization, and CBRN information risks.

The original AI RMF 1.0 was designed for AI systems broadly — it did not anticipate the specific risk profile of large language models and foundation models. The 2024 GenAI Profile, authored by Autio, Schwartz, Dunietz et al. at NIST, fills this gap.

Organizations deploying LLMs, generative AI tools, or foundation model-based applications must apply the GenAI Profile as a supplement to the core framework — not as a replacement.

The 12 Unique GenAI Risk Categories

The NIST Generative AI Profile (July 2024) identifies 12 risk categories that are unique to or significantly elevated in GenAI systems compared to traditional AI:

• Hallucination: Generation of factually incorrect, fabricated, or misleading content presented as accurate.
• Data poisoning: Adversarial manipulation of training data to produce systematically biased or harmful outputs.
• Homogenization: Convergence of perspectives, outputs, or cultural representations due to shared foundation models — reducing epistemic diversity at scale.
• Confabulation: Generation of plausible-sounding but unverifiable citations, sources, or authorities.
• Data privacy: Memorization and reproduction of personal data from training sets — including PII, proprietary information, and sensitive content.
• CBRN information: Generation of content that could assist in chemical, biological, radiological, or nuclear harm.
• Obscene or harmful content: Unrestricted generation of content that violates legal or ethical norms without adequate safeguards.
• Intellectual property: Reproduction or paraphrasing of copyright-protected material in model outputs.
• Harmful bias and homogeneity: Systematic amplification of demographic biases encoded in training data at inference scale.
• Value chain and component integration: Risks introduced through fine-tuning, RAG pipelines, plugins, or tool-use integrations.
• Unpredictable behavior: Emergent capabilities or failure modes not present during evaluation — particularly in larger models.
• Accountability gaps: Unclear responsibility chains when foundation model providers, fine-tuners, and deployers all contribute to a harmful output.

Applying the GenAI Profile to Enterprise LLM Deployments

For each GenAI system in your AI inventory, run the 12-category assessment as an additional MEASURE layer on top of the standard AI RMF evaluation. Document which categories apply, at what severity, and what controls address each.

Pay particular attention to value chain risks if you are building on top of third-party foundation models — the accountability gap risk category is most acute when your organization deploys a fine-tuned or RAG-augmented version of a public model.

For a technical deep-dive on RAG architectures and the data governance implications for MEASURE activities, see our guide on what is RAG — it covers the data pipeline security and provenance tracking practices that directly address the GenAI Profile's value chain risk category.

Enterprise Implementation Roadmap: 3–6 Month Timeline

In short

A structured enterprise AI RMF implementation runs 3–6 months across three phases: governance setup (weeks 1–4), full MAP and MEASURE cycles (weeks 5–16), and MANAGE deployment with continuous monitoring (weeks 17–24).

Based on Alice Labs' experience across 100+ enterprise AI governance deployments, the organizations that achieve durable AI RMF compliance do so in three structured phases. Organizations that attempt to run all four functions simultaneously typically stall in week six.

The 3–6 month range reflects organizational complexity — a 500-person company with 10 AI systems can complete implementation in 12–14 weeks; a 10,000-person enterprise with 80+ AI deployments typically requires the full 6 months.

Phase 1: Governance Foundation (Weeks 1–4)

The first four weeks are entirely focused on GOVERN. No MAP activities begin until the AI risk policy is board-approved and the AI Risk Committee has its first formal meeting.

Week-by-week Phase 1 priorities:

• Week 1: Appoint AI Risk Owner, schedule board briefing on AI RMF adoption rationale.
• Week 2: Identify committee members, draft AI risk policy first version.
• Week 3: First committee meeting — review policy draft, confirm risk tolerance positions, assign MAP team.
• Week 4: Board approval of AI risk policy, integrate AI risk taxonomy with existing ERM framework.

Phase 2: MAP + MEASURE (Weeks 5–16)

Weeks 5–8 focus entirely on MAP. The goal is a complete, risk-tiered AI system inventory — including shadow AI discovered during the process.

Weeks 9–16 begin structured MEASURE evaluations, starting with all high-risk systems. Medium-risk evaluations begin in parallel in week 12 if high-risk evaluations are on track.

Phase 3: MANAGE + Continuous Monitoring (Weeks 17–24)

Phase 3 converts the risk register into action. Every identified risk receives a formal response decision by week 20. Controls are deployed, monitoring is instrumented, and the first AI incident tabletop exercise runs in week 22–23.

By week 24, the organization should have a functioning AI governance program — not just a document set. Monthly committee reviews begin immediately following completion.

For a broader view of how AI governance implementation fits within a full AI maturity journey, our AI maturity model maps governance capability development from Level 1 (ad hoc) through Level 5 (optimizing) — AI RMF implementation typically moves organizations from Level 2 to Level 4.

Continuous Monitoring: Keeping the AI RMF Live After Launch

In short

Continuous monitoring means quarterly reviews for high-risk systems, bi-annual reviews for medium-risk, annual reviews for low-risk, plus event-triggered reassessments when AI systems are significantly updated or incidents occur.

The most common AI RMF failure pattern we observe in the field is treating implementation as a project with an end date. The AI RMF is a governance program — it requires ongoing operation, not one-time completion.

Organizations that establish review cadences in writing, assign named owners to those cadences, and track adherence as a KPI achieve measurably better outcomes than those that complete implementation and then deprioritize maintenance.

Establish Review Cadences by Risk Tier

• High-risk systems: Full MEASURE re-evaluation quarterly. Monitoring dashboards reviewed weekly. Incident log reviewed at every committee meeting.
• Medium-risk systems: Structured evaluation bi-annually. Monitoring dashboards reviewed monthly. Risk register updated quarterly.
• Low-risk systems: Self-assessment annually. No automated monitoring required unless system scope expands.

Event-Triggered Reassessments

In addition to scheduled reviews, four event types must trigger immediate reassessment regardless of cadence:

• Significant model update: Any retrain, fine-tune, or architecture change to a high or medium-risk system resets the MEASURE cycle.
• New regulatory requirement: Changes to EU AI Act implementation guidance, sector regulations, or OMB memoranda may change a system's risk tier.
• AI incident: Any incident meeting the threshold defined in your incident response plan triggers root cause analysis and controls review.
• Scope expansion: Deploying an existing AI system to a new use case, geography, or population requires fresh MAP and MEASURE activities.

Board-Level AI Risk Reporting

The AI Risk Committee should produce a quarterly board report covering: number of AI systems by tier, MEASURE findings summary, open risk response items, incident summary, and regulatory compliance status.

Boards are increasingly held accountable for AI governance failures. A documented, regular reporting cadence creates the audit trail that demonstrates active oversight — critical for both regulatory defense and director liability protection.

For practical guidance on securing board-level commitment to AI governance investment, see our guide on how to get board buy-in for AI — it covers the financial and risk framing that resonates with boards in regulated sectors.

NIST AI RMF vs ISO/IEC 42001 vs EU AI Act: 9-Dimension Comparison

In short

NIST AI RMF (US, voluntary, function-based) is best for risk-management structure; ISO/IEC 42001 (international, certifiable AIMS) is best for third-party-audited assurance; the EU AI Act (binding regulation, risk-tier based) is mandatory for EU-market AI. The three are complementary — NIST gives the operational framework, ISO 42001 gives the auditable management system, and the EU AI Act gives the legal floor.

Enterprises serving regulated industries, US federal customers, and the EU single market must increasingly evidence compliance against all three governance instruments. They address overlapping risks but differ on enforceability, scope, certification model, and documentation depth. The table below maps the nine dimensions that determine which instrument you must adopt, voluntarily align with, or treat as a binding legal obligation.

Primary references for this comparison: the NIST AI Risk Management Framework hub (nist.gov/itl/ai-risk-management-framework), the official ISO catalogue entry ISO/IEC 42001:2023 — AI management systems (iso.org/standard/81230.html), and the European Commission's Regulatory framework proposal on AI (digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai).

How to Stack NIST AI RMF + ISO/IEC 42001 + EU AI Act

In short

Use NIST AI RMF as the operating model (GOVERN/MAP/MEASURE/MANAGE), ISO/IEC 42001 as the certifiable management-system wrapper (AIMS, internal audit, management review), and the EU AI Act as the binding legal layer (risk classification, Annex IV technical documentation, conformity assessment). Build once, evidence three times — using NIST's crosswalk documents to avoid duplication.

Most enterprises do not need to choose between these three instruments — they need to stack them. The cost of running three parallel programs is unnecessary and the duplicate documentation slows audits. The pattern Alice Labs deploys across regulated Nordic and European enterprises is a layered build that maps to all three using a single set of artefacts.

The Layered Build (NIST inside ISO inside EU AI Act)

Think of it as concentric layers. The EU AI Act sets the outer legal envelope. ISO/IEC 42001 sits inside as the certifiable management-system wrapper. NIST AI RMF sits at the core as the day-to-day operational framework that produces the evidence both outer layers consume.

• Layer 1 — EU AI Act (legal floor): Establish risk classification per Annex III, build Annex IV technical documentation, complete conformity assessment for high-risk AI, and meet the August 2, 2025 GPAI obligations if you build or distribute general-purpose AI. See the European Commission AI policy hub for the canonical text and the European AI Office's implementation timeline.
• Layer 2 — ISO/IEC 42001 (certifiable wrapper): Wrap the EU AI Act obligations inside an AIMS — define scope, policy, objectives, risk-treatment plan, Statement of Applicability against Annex A controls, internal audit programme, and management review cycle. The AIMS makes the EU AI Act evidence externally auditable and reusable for ISO 27001, ISO 27701 and ISO 9001 integrations. See the ISO listing at iso.org/standard/81230.html.
• Layer 3 — NIST AI RMF (operational core): Run GOVERN/MAP/MEASURE/ MANAGE as your day-to-day operating model. NIST publishes formal crosswalks mapping AI RMF subcategories to ISO/IEC 42001 clauses and to EU AI Act articles — meaning evidence produced once for NIST RMF can be re-used for both the ISO audit and the EU AI Act technical file. Reference: NIST AI RMF hub.

Six-Step Stack Implementation

1. Inventory and classify (NIST MAP → EU AI Act risk tier): Build a single AI system inventory. For each system, tag both the NIST risk tier (low/medium/high) and the EU AI Act category (prohibited / high-risk / limited / minimal). The same inventory feeds Annex IV documentation and ISO AIMS scope.
2. Define one governance committee (ISO AIMS + NIST GOVERN): A single AI Risk Committee fulfils both ISO 42001 top-management requirements and NIST GOVERN accountability requirements. Avoid creating separate committees per framework.
3. Use NIST crosswalks to reduce duplication: NIST's official AI RMF → ISO/IEC 42001 and AI RMF → EU AI Act crosswalk documents map subcategories one-to-one where possible. Document evidence once and tag it against all three indices.
4. Build the Annex IV technical file as MEASURE output: The EU AI Act Annex IV technical documentation is largely a re-formatting of NIST MEASURE evaluation records plus model-card data. Build it as a by-product of MEASURE, not as a separate workstream.
5. Internal audit covers all three (ISO 42001 driven): Run a single annual internal audit programme against ISO 42001 clauses; the audit evidence demonstrates ISO conformance, EU AI Act post-market monitoring, and NIST MANAGE continuous monitoring simultaneously.
6. Management review = board AI risk report: The ISO 42001 management review meeting doubles as the board-level AI risk report covering NIST GOVERN outcomes and EU AI Act serious-incident summary. One meeting, three audit trails.

For a deeper view of how the EU AI Act conformity assessment dovetails with this stack, see our EU AI Act compliance checklist 2026 and the broader what is AI governance overview.

Frequently Asked Questions: NIST AI RMF

In short

Common questions about the NIST AI RMF covering implementation, scope, regulatory alignment, and the 2024 GenAI Profile.

The following questions represent the most common points of confusion enterprises encounter when beginning AI RMF implementation. Answers are based on NIST AI 100-1 (January 2023) and the NIST Generative AI Profile (July 2024).