NIST AI RMF (Risk Management Framework) BETA

Govern is the first of the four functions in the AI RMF and the foundation the other three depend on. It establishes the culture, policies, processes, accountability structures, and oversight mechanisms that enable an organisation to manage AI risks across the AI lifecycle.

Where Map identifies risks, Measure analyses them, and Manage addresses them, Govern is the standing infrastructure that makes those activities possible and ensures they connect to organisational decision-making.

The function is organised into six categories:

Govern 1 — Policies, processes, procedures, and practices

Policies and processes for AI risk management are in place, transparent, implemented effectively, and reviewed periodically.

Govern 2 — Accountability structures

Accountability structures are in place so that the appropriate teams and individuals are empowered, responsible, and trained for mapping, measuring, and managing AI risks.

Govern 3 — Workforce diversity, equity, inclusion, and accessibility

Workforce diversity, equity, inclusion, and accessibility processes are prioritised in the mapping, measuring, and managing of AI risks throughout the lifecycle.

Govern 4 — Organisational culture

Organisational teams are committed to a culture that considers and communicates AI risk.

Govern 5 — Engagement with AI actors

Processes are in place for robust engagement with relevant AI actors.

Govern 6 — Third-party processes

Policies and procedures are in place to address AI risks and benefits arising from third-party software and data and other supply chain issues.

Each category contains subcategories — typically two to four — that specify the outcomes the organisation should achieve.

The Playbook provides suggested actions for each subcategory.

What this means in practice

Govern produces the standing architecture of AI risk management.

Four deliverables emerge:

AI risk management policies

Documented policies covering AI risk tolerance, AI risk management processes, and how AI risk management connects to broader organisational risk management. Reviewed periodically and updated as the AI portfolio, regulatory environment, and risk landscape change.

Accountability assignments

Named ownership for AI risk management across the lifecycle — who is responsible for risk identification, who for assessment, who for mitigation, who for monitoring, who for incident response. Authority must match responsibility.

Workforce and culture practices

Training, diversity, equity, inclusion, and accessibility considerations integrated into AI development and deployment teams. The framework treats workforce diversity as a substantive risk management measure, not a separate HR concern — diverse teams identify risks homogeneous teams miss.

Third-party governance

Processes for managing AI risks introduced through third-party software, models, data, and services. Covers due diligence, contractual provisions, ongoing monitoring, and incident communication across supply chain relationships.

The engagement category (Govern 5) is the requirement most often under-implemented because it bridges into product, customer success, and external affairs functions that sit outside risk management.

NIST AI RMF framework expects organisations to engage with AI actors — including affected communities, end users, civil society, and domain experts — and to integrate that engagement into risk management processes.

Engagement performed once at design and never repeated does not satisfy the function.

Why it matters

Govern is the function that determines whether AI risk management is an organisational capability or a project.

The other three functions can be performed competently in isolation — risks mapped, measurements taken, treatments applied — and still produce no durable change if Govern is absent.

The framework places Govern first because it provides the structures within which Map, Measure, and Manage are continuously performed.

Three specific failure modes recur:

Govern as policy without process

Organisations produce AI policies and risk management statements without the underlying processes, accountability structures, and review cycles that make the policies operative.

Govern requires the standing architecture, not the documentation.

Accountability without authority

Roles are assigned for AI risk management — AI ethics officer, responsible AI lead, AI governance committee — without the decision rights, budget, or escalation paths to perform the role.

Govern 2 requires authority to match responsibility.

Third-party AI treated as procurement, not risk management

Foundation models, AI-enabled SaaS, and AI components from suppliers are inside the AI RMF scope when the organisation develops or deploys with them.

Govern 6 requires these to be managed as AI risks, not handled exclusively through ordinary vendor management. The framework is explicit that supply chain AI risk is integral to organisational AI risk.

Map is the second of the four functions and the one that establishes context. Where Govern provides standing infrastructure, Map produces the situational understanding on which Measure and Manage depend: what the AI system is, what it does, where it operates, who is affected, what could go wrong, and what risks are worth attending to.

The function is organised into five categories:

Map 1 — Context

Context is established and understood, including intended purposes, settings in which the AI system will be deployed, the specific set of users along with their expectations, and potential impacts of system use.

Map 2 — Categorisation of the AI system

Categorisation of the AI system is performed, including its capabilities, targeted usage, goals, and expected benefits and costs compared with appropriate benchmarks.

Map 3 — AI capabilities, targeted usage, goals, and expected benefits and costs

AI capabilities, targeted usage, goals, and expected benefits and costs are understood relative to comparable benchmarks.

Map 4 — Risks and benefits

Risks and benefits are mapped for all components of the AI system including third-party software and data.

Map 5 — Impacts on individuals, groups, communities, organisations, and society

Impacts to individuals, groups, communities, organisations, and society are characterised.

Each category contains subcategories specifying outcomes the organisation should achieve. Map is the function most directly concerned with the what and who of the AI system; the substantive risk analysis that Measure performs depends on the context Map establishes.

What this means in practice

Map produces the foundational documentation an AI risk management programme operates on. Five deliverables emerge:

System context documentation

Intended purpose, deployment setting, user populations, expected interaction patterns, operational environment, and the broader sociotechnical context in which the AI system operates. The framework treats AI systems as sociotechnical — system performance depends on the context of use, not only on technical characteristics — and Map 1 captures that context explicitly.

System categorisation

Type of AI (rule-based, machine learning, foundation model, multi-agent), task domain (classification, generation, recommendation, control), risk-relevant attributes (autonomy level, adaptiveness, opacity), and benchmarks against which performance and risk will be assessed.

Capability and goal articulation

What the system is intended to do, the goals it serves, expected benefits, and expected costs — including costs to those outside the organisation. The benefit-cost framing distinguishes Map from a pure risk identification exercise; the framework expects organisations to articulate why the system is being built and against what alternatives.

Component-level risk and benefit mapping

Risks and benefits attributable to specific components of the AI system, including third-party models, datasets, libraries, and infrastructure. The supply chain dimension is explicit — risks introduced through foundation models, AI-enabled SaaS, and external data are mapped at component level.

Impact characterisation

Effects on individuals, groups, communities, organisations, and society. The five-level scope is the framework’s most distinctive feature in Map and the requirement most often under-implemented. Impact characterisation in the AI RMF is broader than impact assessment in ISO 42001 — it extends explicitly to organisational and societal levels alongside individual and group levels.

The categorisation work under Map 2 and Map 3 produces the labels and benchmarks the rest of the framework relies on.

An AI system categorised inadequately — described too generically, mismatched to its actual technical type, or measured against inapplicable benchmarks — produces Measure outputs that cannot be interpreted and Manage decisions that cannot be justified.

Why it matters

Map is the function that determines whether subsequent risk management is grounded in reality. The framework places Map second because it is the prerequisite for Measure and Manage — measurements without context produce numbers without meaning, and management without understanding produces actions without targets.

Three specific points are worth flagging:

Map is iterative, not one-off

The framework expects Map activities to be repeated as the AI system, its deployment context, and the broader environment change.

Map performed once at inception and never revisited produces a context document that decays as the system and its environment evolve.

Map 5 is the NIST AI RMF analogue to ISO 42001’s impact assessment, with broader scope

Where ISO 42001 Clause 6.1.4 addresses effects on individuals, groups, and societies, Map 5 explicitly adds organisations and communities as distinct levels of impact analysis. Organisations using both frameworks typically structure impact assessment to cover all five levels, satisfying both requirements through a single methodology.

The sociotechnical framing is substantive, not rhetorical. Map’s emphasis on context, user populations, and deployment setting reflects the framework’s position that AI risk cannot be assessed from technical characteristics alone. The same model deployed in different contexts presents different risks, and the framework requires Map activities to capture context at a level of specificity that supports context-dependent risk analysis.

Three specific failure modes recur:

Categorisation by technology rather than by function

Systems categorised as “machine learning model” or “large language model” without articulating task, deployment context, and user population produce Map outputs that do not differentiate one system from another.

The framework expects categorisation specific enough to support distinct risk analysis per system.

Impact analysis truncated to individual leve

Map 5 requires impact analysis across five levels — individuals, groups, communities, organisations, society. Analyses that stop at individual harms (privacy violations, biased decisions affecting specific users) miss the group, community, and societal effects the framework treats as integral to AI risk.

Third-party components mapped at vendor level rather than component level

Risks introduced through foundation models or third-party AI services are mapped as supplier risks rather than as risks attributable to specific model behaviours, training data limitations, or capability boundaries. Map 4 expects component-level analysis, not vendor-level summary.

Measure is the third of the four functions and the one that produces evidence. Where Map establishes context and identifies what could go wrong, Measure analyses, assesses, benchmarks, and monitors AI risks through quantitative and qualitative methods.

It is the function that turns the contextual understanding from Map into testable claims and ongoing observations.

The function is organised into four categories:

Measure 1 — Appropriate methods and metrics

Appropriate methods and metrics are identified and applied for the AI system’s intended purpose and deployment setting.

Measure 2 — Evaluation of AI systems for trustworthy characteristics

AI systems are evaluated for trustworthy characteristics — validity and reliability, safety, security and resilience, accountability and transparency, explainability and interpretability, privacy enhancement, and fairness with managed bias.

Measure 3 — Mechanisms for tracking identified AI risks

Mechanisms for tracking identified AI risks over time are in place.

Measure 4 — Feedback about efficacy of measurement

Feedback about the efficacy of measurement is gathered and assessed.

Each category contains subcategories specifying outcomes the organisation should achieve.

Measure is the function where the seven trustworthy AI characteristics most directly translate into operational activity — each characteristic produces measurement requirements that subcategories under Measure 2 elaborate.

What this means in practice

Measure produces the evidence base AI risk management operates on. Five deliverables emerge:

Measurement methodology

Selected methods and metrics appropriate to the AI system’s intended purpose, deployment setting, and risk profile. The framework does not prescribe methods — selection is the organisation’s responsibility — but expects the chosen methods to be appropriate, documented, and justified against the system and its context.

Trustworthy characteristic evaluations

Documented evaluations of the AI system against each of the seven trustworthy characteristics where applicable:

• Validity and reliability through performance testing;
• Safety through hazard analysis;
• Security and resilience through adversarial testing;
• Accountability and transparency through documentation and audit trail;
• Explainability and interpretability through method-appropriate techniques;
• Privacy enhancement through privacy-preserving design and assessment;
• Fairness through bias measurement and mitigation analysis.

Risk tracking mechanisms

Standing processes for monitoring identified risks over time — including drift detection, performance monitoring, incident tracking, and reassessment triggers. The framework expects measurement to be ongoing, not a one-off pre-deployment activity.

Measurement of impacts

Where Map characterises impacts, Measure quantifies and tracks them. Impact metrics — on individuals, groups, communities, organisations, and society — must be developed and applied where the system’s potential impacts warrant tracking.

Feedback on measurement efficacy

Documented assessment of whether the chosen measurement methods are actually producing useful information. Measure 4 is the framework’s loop closure — methods that produce metrics nobody acts on, or that fail to detect risks they were chosen to detect, must be reassessed.

The seven trustworthy characteristics under Measure 2 deserve specific attention because they are the framework’s substantive content. Each requires its own measurement approach:

The characteristics are not independent. The framework explicitly notes that they interact — improvements in one may reduce performance against another, and trade-offs must be made consciously and documented.

A system optimised for explainability may sacrifice predictive performance. A system optimised for fairness across groups may produce worse outcomes for some groups than an unconstrained alternative.

Measure activities must surface these trade-offs, not obscure them.

Why it matters

Measure is the function that produces the evidence on which Manage decisions are based. Without Measure, AI risk management operates on assertion rather than observation — risks are claimed to be addressed without verification that they have been.

The framework places Measure third because it requires Map to have established what to measure and Govern to have established the structures within which measurement is conducted and acted on.

Three specific points are worth flagging:

Measure is method-agnostic but not method-neutral

The framework does not prescribe specific measurement techniques, but it expects methods to be appropriate to the system, the context, and the characteristic being measured.

Generic measurement applied uniformly across all systems is the most common Measure failure — accuracy metrics applied to systems where calibration matters more, bias metrics applied at population level where group-level analysis is required, drift metrics chosen for convenience rather than for the actual drift modes the system exhibits.

The seven characteristics are the framework’s substantive vocabulary

Where ISO 42001 sets out objectives and risk sources in Annex C, the AI RMF embeds substantive content in the trustworthy characteristics under Measure 2.

Organisations using both frameworks typically adopt the seven characteristics as their working vocabulary because the AI RMF specifies them in operational detail that Annex C does not.
Measurement efficacy itself must be measured.

Measure 4 — feedback about efficacy of measurement — is the requirement most often skipped

The framework treats measurement as a system that itself requires evaluation: are the metrics producing actionable information; are they detecting the risks they were chosen to detect; are stakeholders using the outputs. Organisations that produce measurement without assessing its efficacy accumulate metrics that nobody acts on.

Three specific failure modes recur:

Measurement of characteristics not relevant to the system

Organisations apply the full set of seven characteristics to every system, including characteristics that are not applicable. The framework expects relevance to be determined per system based on intended use, deployment context, and identified risks — not applied as a checklist.

Pre-deployment measurement without operational measurement

Systems are evaluated thoroughly before deployment and monitored superficially after. Measure 3 requires ongoing tracking of identified risks; performance, drift, and incident metrics must be collected and analysed throughout the deployment lifecycle, not only at gates.

Fairness measurement at aggregate level only

Bias and fairness are measured across the user population without disaggregation by the groups most likely to experience disparate effects. The framework expects fairness measurement to be method-appropriate to the system and the relevant protected, marginalised, and affected groups — aggregate metrics often mask group-level disparities.

Manage is the fourth and final function in the AI RMF and the one that produces action. Where Govern establishes structure, Map establishes context, and Measure produces evidence, Manage allocates resources to address identified risks and responds when things go wrong. It is the function that converts the framework’s analytical work into operational decisions and interventions.

The function is organised into four categories:

Manage 1 — AI risks are prioritised, responded to, and managed

Identified AI risks are prioritised based on impact, likelihood, available resources, and other factors, and responses are planned and executed.

Manage 2 — Strategies to maximise AI benefits and minimise negative impacts

Strategies to maximise AI benefits and minimise negative impacts are planned, prepared, implemented, documented, and informed by input from relevant AI actors.

Manage 3 — AI risks and benefits from third-party entities are managed

AI risks and benefits arising from third-party resources are regularly monitored, and risk controls are applied and documented.

Manage 4 — Risk treatments are documented, monitored, and improved

Risk treatments — including response and recovery, and communication — are documented and regularly monitored, and improvement processes are in place.

Each category contains subcategories specifying outcomes the organisation should achieve. Manage is the function most directly concerned with decisions and trade-offs — which risks to prioritise, which to accept, which to escalate, and which to remediate.

What this means in practice

Manage produces the operational decisions and responses that AI risk management produces.

Five deliverables emerge:

Risk prioritisation and response decisions

Identified risks ranked according to impact, likelihood, organisational risk tolerance, and resource constraints. The framework expects prioritisation to be explicit and documented — not implicit in which risks happen to be addressed first.

Benefit maximisation and impact minimisation strategies

Documented strategies that explicitly weigh AI benefits against negative impacts and articulate how the balance will be maintained operationally. The framework treats this as a substantive analytical exercise, not a marketing statement — the strategies must produce decisions that can be tested against outcomes.

Third-party risk treatments

Risk controls applied to AI components, models, data, and services sourced from third parties — including ongoing monitoring, contractual enforcement, and incident communication. Manage 3 makes operational what Govern 6 establishes as policy.

Response and recovery procedures

Documented procedures for responding to AI incidents, recovering from failures, and communicating with affected parties. The framework expects these to cover both anticipated failures (modes identified in Map and Measure) and unanticipated ones.

Continuous improvement of risk treatments

Treatments monitored for effectiveness, updated as the system and context change, and retired when no longer relevant. Manage 4 is the framework’s loop closure — risk treatments that are implemented and never reviewed become drag rather than protection.

The prioritisation work under Manage 1 deserves specific attention. The framework does not prescribe a risk ranking method — organisations are expected to choose an approach appropriate to their context — but expects the chosen method to be documented, applied consistently, and revisited as risks evolve.

Prioritisation by exception, where high-visibility risks are addressed and others ignored without explicit decision, fails this requirement even when the visible risks are correctly identified.

The benefit-cost framing under Manage 2 is distinctive to NIST AI RMF. Where ISO 42001 focuses on managing risks introduced by AI systems, the AI RMF places benefit maximisation alongside risk minimisation as a co-equal management objective.

Manage 2 expects organisations to articulate AI benefits explicitly, design strategies that pursue those benefits, and accept that some risk is justified when benefits warrant it. The framing is not “minimise all risk” but “manage risk in pursuit of articulated benefits.”

Why it matters

Manage is the function that determines whether AI risk management changes what the organisation does. The other three functions can produce structures, context, and evidence without altering operational decisions — Manage is the function that requires the analytical work to translate into action.

Three specific points are worth flagging:

Manage is decision-oriented, not documentation-oriented

The framework expects Manage activities to produce decisions: which risks to treat, how, with what resources, on what timeline.

Documentation of the decisions is required, but the decisions themselves are the point. Organisations that produce extensive Manage documentation without traceable decisions miss the function’s purpose.

Third-party AI is operationally managed, not delegated

Manage 3 makes explicit that the organisation remains responsible for managing risks introduced by third-party AI components even where the components themselves are outside the organisation’s control.

The framework expects ongoing monitoring, applied controls, and documented response — not reliance on supplier representations or one-off due diligence at procurement.

Recovery and communication are part of management

Manage 4 includes response, recovery, and communication as integral risk treatments. Incident response procedures, recovery capabilities, and communication plans for affected parties are part of the risk management infrastructure — not separate concerns handled by incident response or public relations functions in isolation.

Three specific failure modes recur:

Prioritisation by visibility rather than by analysis

Risks that attract leadership attention or external scrutiny are addressed; risks identified through systematic analysis but lacking visibility languish. Manage 1 expects prioritisation to follow from impact, likelihood, and resource analysis — not from political salience.

Benefit articulation absent

Organisations document risks extensively under Map and Measure and document risk treatments under Manage 1 and Manage 4, without articulating the benefits the AI system is intended to produce. Manage 2 expects benefit-cost balancing to be explicit; treatments designed only to minimise risk, without reference to benefits, produce over-cautious systems or under-justified deployments.

Treatments implemented and not reviewed

Risk treatments are applied at deployment and then assumed to remain effective. Manage 4 requires monitoring of treatment effectiveness, updating as conditions change, and retirement when treatments become obsolete. Static treatments in dynamic AI deployments lose their value quickly.

The AI RMF Playbook is the companion implementation guide to AI RMF 1.0. Where the framework specifies what an organisation should achieve under each of the four functions — Govern, Map, Measure, and Manage — the Playbook suggests how to achieve it.

The Playbook provides, for each subcategory of the framework, a set of suggested actions the organisation may take, references to supporting literature and resources, documentation considerations, and transparency considerations.

The Playbook is published by NIST alongside the framework and is treated as a living document. It is updated as practice evolves, as new resources become available, and as community input refines the suggested actions.

The Playbook is voluntary in the same sense as the framework itself — it is guidance, not requirement, and organisations are expected to select the actions appropriate to their context rather than apply the Playbook as a checklist.

What this means in practice

The Playbook serves four functions in operational use:

Implementation starter for each subcategory

Each framework subcategory — Govern 1.1 through Manage 4.3 — receives Playbook content covering suggested actions, supporting references, and considerations.

Organisations beginning AI RMF adoption typically use the Playbook to translate framework outcomes into operational activities without designing each activity from scratch.

Reference library for AI risk management

The Playbook’s references — to NIST publications, academic literature, sector guidance, technical standards, and other frameworks — function as a curated entry point into the broader AI risk management literature.

Organisations use the references to deepen specific areas (bias measurement, robustness testing, explainability methods) without surveying the field independently.

Transparency and documentation guidance

The Playbook’s transparency and documentation considerations specify what should be recorded about each subcategory’s implementation — supporting both internal accountability and external attestation.

For organisations using AI RMF alignment as evidence to customers, partners, or regulators, the documentation guidance is the most actionable part of the Playbook.

Adaptation reference for profiles

Profiles that adapt the AI RMF to specific use cases or sectors typically build on Playbook content, selecting and modifying suggested actions appropriate to the use case.

The Generative AI Profile (NIST AI 600-1) follows this pattern, and sector-specific profiles produced by external organisations commonly do the same.

The Playbook is not a methodology. It does not prescribe how to perform bias measurement, how to conduct adversarial testing, or how to structure an AI impact assessment. It points to methods, references organisations that have developed methods, and identifies the considerations that method selection should address.

Organisations seeking step-by-step methodology guidance need to combine the Playbook with sector-specific or technique-specific resources it references.

Why it matters

The Playbook is the resource that makes the AI RMF operationally usable for most organisations. The framework itself, at roughly 50 pages, specifies outcomes at a level of generality that allows broad applicability but provides limited implementation guidance.

The Playbook fills that gap without converting the framework into a prescriptive standard — it preserves the framework’s flexibility while making adoption practical.

Three points are worth flagging:

Playbook actions are suggested, not required

The framework is voluntary; the Playbook is voluntary guidance about how to apply voluntary guidance. Organisations select Playbook actions appropriate to their context — system type, deployment setting, risk profile, organisational maturity — and document their selections.

Applying the full Playbook as a checklist over-implements; ignoring the Playbook under-implements.

The Playbook is a living document

Unlike the framework itself (version 1.0, January 2023), the Playbook is updated as practice evolves. Organisations relying on Playbook content should check the current version periodically rather than treating an initial download as definitive.

The Playbook is not equivalent to a control list

Unlike ISO 42001 Annex A, which specifies controls that must be considered for inclusion in the AIMS, the Playbook does not specify controls and does not produce an equivalent to a Statement of Applicability.

Organisations using both AI RMF and ISO 42001 should treat the Playbook as methodology guidance for ISO 42001 Clauses 6 and 8 rather than as a substitute for Annex A.

One specific failure mode recurs:

Playbook adoption as box-ticking

Organisations work through Playbook suggested actions subcategory by subcategory, marking each as addressed, without applying the contextual judgement the framework requires.

The Playbook is designed to support judgement, not to replace it; treating it as a compliance checklist produces uniform implementations that miss context-specific risks and over-implement context-irrelevant ones.

NIST AI RMF Crosswalks are mappings between the NIST AI Risk Management Framework and other AI governance instruments — international standards, regulatory frameworks, sectoral guidance, and adjacent risk management frameworks. They are published by NIST as supporting resources alongside the framework, and additional crosswalks are produced by external organisations, professional bodies, and consultancies working across multiple frameworks.

A crosswalk is a structured mapping that identifies where the AI RMF and another instrument address similar concerns, where they diverge, and where evidence produced under one supports the other. Crosswalks do not collapse the differences between instruments — they make the differences navigable.

What this means in practice

The crosswalks NIST has published or supported cover the instruments organisations most commonly encounter alongside the AI RMF.

The headline mappings include the OECD AI Principles, ISO/IEC standards (notably ISO/IEC 42001 and ISO/IEC 23894), the EU AI Act, and a range of US federal and sector-specific frameworks.

Crosswalks to additional instruments — sector codes, national AI strategies, professional society guidance — are produced by external organisations and frequently referenced alongside the NIST-published versions.

The crosswalks function in three operational ways.

They support evidence reuse

An organisation operating under multiple frameworks can use a crosswalk to identify where a single piece of evidence — a risk assessment, a system documentation artefact, a monitoring procedure — satisfies requirements under more than one framework.

Without a crosswalk, the organisation either produces duplicate evidence or maintains an internal mapping that may not align with how external auditors and regulators interpret the instruments.

They support gap identification

Where one framework imposes a requirement that another does not address, the crosswalk surfaces the gap explicitly.

An organisation transitioning from informal AI governance to ISO/IEC 42001 certification, for example, can use the AI RMF to ISO 42001 crosswalk to identify ISO 42001 requirements not covered by existing AI RMF implementation.

The crosswalk does not perform the implementation work but identifies where it is needed.

They support communication across audiences

Regulators, customers, partners, and internal stakeholders frequently use different framework vocabularies. The crosswalks let an organisation describe its AI risk management work in the vocabulary appropriate to each audience without restructuring the underlying work.

A risk identified through AI RMF Map activities can be communicated to an EU customer as supporting Article 9 of the EU AI Act, to an ISO 42001 auditor as evidence for Clause 6.1.2, and to a US federal partner as alignment with the corresponding AI RMF subcategory — all referencing the same underlying activity.

Why it matters

The crosswalks are the most practically useful of the AI RMF supporting documents for organisations operating under multiple governance instruments.

The AI RMF is technology-neutral, sector-neutral, and use-case agnostic by design — which means that in practice, organisations adopting it almost always operate alongside other frameworks that are not. The crosswalks make that coexistence manageable.

Three points are worth flagging.

The crosswalks are mappings, not equivalences

A crosswalk entry indicating that an AI RMF subcategory corresponds to an ISO 42001 control does not mean implementing the subcategory satisfies the control, or vice versa. The instruments differ in legal status, scope of obligation, and substantive requirement, and the crosswalk identifies correspondence without collapsing the differences.

Using a crosswalk to argue equivalence — claiming AI RMF adoption alone satisfies ISO 42001, or claiming an ISO 42001 SoA covers all AI RMF subcategories — misreads what crosswalks are designed to do.

Crosswalks evolve as the underlying instruments evolve

The EU AI Act came into force after AI RMF 1.0 was published; the original AI RMF crosswalk to the Act was developed retrospectively and continues to be refined as Act implementation guidance emerges. ISO/IEC 42001 was published after AI RMF 1.0; crosswalks between them have been published and refined since.

Organisations relying on crosswalks should check the publication date and confirm that the underlying instruments have not changed materially since.

Crosswalks are produced by multiple parties with varying levels of authority. NIST-published crosswalks have official status; crosswalks produced by ISO, by professional bodies, by certification bodies, and by consultancies have varying weight.

For high-stakes work — regulatory submissions, certification audits, contractual representations — the authoritative source for each instrument is the instrument itself, not the crosswalk. Crosswalks are useful planning and communication tools; they are not legal interpretations.

One specific failure mode recurs.

Organisations occasionally adopt a single crosswalk and treat its mapping as definitive across all uses

Crosswalks reflect the author’s interpretation of how the instruments correspond, and reasonable interpretations differ. Using a single crosswalk for evidence reuse, gap analysis, audit preparation, and regulatory submission simultaneously — without checking how each audience interprets the same correspondences — produces inconsistencies the organisation only discovers when an auditor or regulator disagrees with the mapping.

The discipline of using crosswalks well is recognising that they are tools for navigation, not authoritative statements of equivalence.

Use Case Profiles are adaptations of the AI RMF to specific contexts — particular use cases, sectors, technologies, or AI actor roles. Where the core framework is deliberately technology-neutral, sector-neutral, and use-case agnostic, profiles specify what the framework’s functions, categories, and subcategories look like when applied to a defined context.

Profiles are the mechanism by which the framework’s generality is converted into context-specific guidance.

The concept of profiles is established in AI RMF 1.0 itself. The framework distinguishes between use case profiles, which apply to specific applications or deployment contexts, and target profiles, which describe a desired state an organisation is working toward.

Both share the same underlying structure: a profile selects, prioritises, and elaborates the framework’s subcategories for a specific context, rather than treating all subcategories as equally applicable.

The Generative AI Profile (NIST AI 600-1), published in July 2024, is the most prominent example of a use case profile to date.

Additional profiles — published by NIST, by other federal agencies, by sector bodies, and by external organisations — extend the framework to other contexts as the practice of profile development matures.

What this means in practice

A profile typically does four things.

The profile identifies the risks distinctive to the context

The Generative AI Profile, for example, identifies twelve risks specific to generative AI; a profile for AI in healthcare diagnostics would identify risks specific to clinical decision support; a profile for AI in financial services would identify risks specific to credit, fraud detection, or trading.

The risk identification is the substantive starting point — it tells users of the profile what they are managing in this context.

Profile selects and prioritises framework subcategories

Not all of the framework’s subcategories bear equally on every context. A profile identifies which subcategories are most relevant, which apply with modifications, and which may be less applicable to the context.

This selection makes the framework operationally usable for the context without requiring users to determine subcategory relevance from first principles.

Profiles provide context-specific actions

Where the AI RMF Playbook provides suggested actions for general use, a profile provides suggested actions tailored to the context.

The actions reference techniques, methods, and considerations specific to the use case — adversarial testing methods relevant to generative AI, validation approaches relevant to clinical AI, monitoring techniques relevant to financial AI.

Profiles support comparison and benchmarking

Organisations operating in the same context can use the same profile, which produces a shared reference for risk management practice in that context. Customers, regulators, and partners can use the profile as a common frame for assessing organisations operating in the context.

Profiles vary in formality and authority. NIST-published profiles carry official status and reflect substantial development effort, including community engagement and public comment.

Profiles published by other US federal agencies, by sector regulators, or by international bodies carry varying authority depending on their origin.

Profiles produced by industry groups, professional bodies, and consultancies are useful but should be evaluated for fit and rigour before adoption.

Why it matters

Profiles are the mechanism that makes the framework’s deliberate generality workable.

Without profiles, every organisation adopting the framework would need to determine independently which subcategories apply to its context, what risks distinctive to its context warrant attention, and what context-specific actions support each subcategory. The work would be duplicative across organisations operating in similar contexts and would produce uneven results.

Three points are worth flagging.

Profiles are adaptations, not replacements

A profile assumes the core framework is being applied and adds context-specific content to that application.

Organisations adopting a profile must also implement the core framework — the four functions, the categories, the supporting Govern infrastructure — because the profile depends on the framework’s structure for its content to operate. Profile adoption in isolation from the core framework produces fragmented implementation.

Profile coverage is uneven and evolving

As of mid-2026, profiles published by NIST cover a limited set of contexts. The Generative AI Profile is the most developed; profiles for additional contexts — sectors, technologies, deployment types — are at various stages of development or have been produced by external organisations.

Organisations operating in contexts without a published NIST profile commonly use a combination of the core framework, sector-specific guidance from regulators and industry bodies, and profiles produced by external organisations.

Profiles are most useful when the context they describe matches the organisation’s situation

A profile developed for one industry may apply with modifications to an adjacent industry, but the fit must be assessed rather than assumed. Adopting a profile because it is the only one available, without confirming that its context analysis matches the organisation’s situation, produces guidance that may not reflect the organisation’s actual risk landscape.

One specific failure mode recurs.

Organisations occasionally treat a profile’s risk list as exhaustive

A profile identifies risks distinctive to its context as a starting point, not as a complete enumeration.

Organisations adopting the Generative AI Profile, for example, are expected to consider the twelve identified risks and to add risks specific to their systems and deployment contexts.

Treating the profile’s risk list as the full inventory of relevant risks produces under-scoped risk management that misses context-specific issues the profile authors could not have anticipated.

The profile is a structured starting point; the organisation’s own analysis remains essential.