NIST CSF vs NIST AI RMF: A Migration Guide

We keep meeting the same reasonable assumption: a security team that has run the NIST Cybersecurity Framework for years sees AI moving into the business, notices that the obvious framework for it also comes from NIST, and concludes that the AI Risk Management Framework will be a gentle next step, mostly a matter of copying the CSF playbook across. That instinct is partly right, because the governance operating model you built for CSF genuinely carries over and it is the expensive part, so you are not starting from scratch. It is also partly wrong, because most of the substance of AI RMF is new, since governing an AI system is a different problem from securing one. This post is written for the CSF-mature team: what transfers, what you build new, and why doing the work once on connected infrastructure becomes a running start on ISO 42001 and the EU AI Act too.

The assumption that breaks

The clearest authority on this is NIST itself. The AI RMF includes an appendix, "How AI Risks Differ from Traditional Software Risks", that sets out what established frameworks like the CSF are unable to do for AI: manage harmful bias, confront generative-AI risks, comprehensively address machine-learning attacks such as evasion, model extraction and membership inference, account for the AI attack surface, or handle third-party AI, transfer learning and off-label use. The point is narrow: AI introduces risks a cybersecurity framework was never built to see, so a team that treats AI RMF as another CSF profile will find the gaps the hard way.

What CSF and AI RMF share

Start with what does transfer, because it is more than it first appears. Both are NIST frameworks, both are voluntary and outcome-based instead of prescriptive, and both are organised the same way, around a Core of functions that break into categories and subcategories, with Profiles that compare a current state to a target state and drive a gap analysis. If you run the CSF you already operate that machine: a governance body, a risk register with an agreed rating method, an asset-inventory discipline, supply-chain risk practices, a cadence of review with the board, and an incident-response muscle. The two frameworks even share a Govern function now, since CSF 2.0 added one in February 2024, and NIST's own Appendix B points to the CSF as a resource you can lean on for the "secure and resilient" and "privacy-enhanced" characteristics of trustworthy AI. The operating model, in short, is already built, and rebuilding it is the part that usually takes a year.

Where they diverge

The divergence is in the substance. The most useful way to see it is that everything your CSF program governs, the entire domain of cybersecurity, maps to roughly one of the seven characteristics of trustworthy AI that the AI RMF asks you to manage. Those seven are valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. Your cybersecurity work lands squarely on "secure and resilient" and touches "privacy-enhanced"; the rest is new ground, and most of it has no clean analog in a security program.

	NIST CSF 2.0	NIST AI RMF 1.0
Risk it governs	Cybersecurity risk to information systems	Risks of AI systems, across seven trustworthiness characteristics
Core functions	Govern, Identify, Protect, Detect, Respond, Recover (6)	Govern, Map, Measure, Manage (4)
Risk model	Asset and threat centric	Sociotechnical: harm to people, organisations and ecosystems
Maturity model	Four Implementation Tiers	None
Binding status	Voluntary, outcome-based	Voluntary, outcome-based

Two of the four AI RMF functions, Map and Measure, have no clean CSF equivalent at all. Map is the discipline of framing an AI system's context, intended purpose, stakeholders and potential impacts before you build, enough to make an honest go or no-go call. Measure is the sociotechnical testing, evaluation, verification and validation of the system against those seven characteristics, the work of quantifying bias, robustness, explainability and drift, and red-teaming a generative model. A CSF shop has detection and monitoring, but it has nothing that measures whether a model is fair or whether its explanations hold. One familiar comfort is also missing: the CSF gives you four Implementation Tiers to rate maturity against, and AI RMF ships no tier ladder at all, so the instinct to ask "what tier are we at on AI RMF" has nothing to answer it.

The Govern false friend

The most seductive trap is the word the two frameworks now share. Govern appears in CSF 2.0 and in AI RMF, and it is tempting to assume your CSF Govern outcomes simply extend to AI. They do not, because the two are wired differently. In the CSF, Govern sits at the centre of the wheel and informs how the other five operational functions are carried out, the strategy and oversight layer above Identify, Protect, Detect, Respond and Recover. In AI RMF, Govern is a culture that runs through Map, Measure and Manage all at once, sitting inside them instead of above them, and it carries responsibilities a security charter does not, around AI-specific accountability, workforce competence, stakeholder engagement and third-party AI. The shared word hides a different governance machine, and mapping CSF Govern onto AI RMF Govern one-to-one is the quickest way to leave accountability, competence, stakeholder-engagement and third-party-AI responsibilities uncovered.

The migration journey for a CSF shop

So what does the move actually look like? Reuse the CSF operating model as the governance chassis, then add the AI-specific work that makes AI RMF operational.

What you reuse is the scaffolding, and it is most of the cost of any governance program: the governance body and enterprise-risk charter, the risk register and rating method, the asset-inventory habit from Identify, the supply-chain discipline from CSF 2.0's Govern, the current-to-target Profile workflow and its gap analysis, the incident-response playbook, and the board reporting cadence. None of that needs reinventing for AI.

What you add is the AI-specific work, in roughly this order: build an honest AI system inventory that includes the AI embedded in the SaaS tools your teams already adopted, the generative features switched on inside products, and the shadow AI nobody registered, because the models and agents you cannot see are the ones already creating exposure; run Map on the systems that matter most, framing each one's context, purpose and potential harms; stand up Measure, the trustworthiness testing your security program does not have, covering bias, robustness, explainability, drift and, where generative AI is in use, red-teaming; put Manage in place, with human oversight sized to the stakes, an AI-specific incident response and a decommissioning path; write the policies and name the roles that do not yet exist, from acceptable-use and model-development standards to AI data governance and third-party AI procurement, with model cards or impact assessments as the evidence; then wire all of it into the cadence you already run, so that a retrain, a model swap or a new use case triggers a re-assessment. Where generative AI is in scope, layer NIST's Generative AI Profile on top.

The pitfall worth stating plainly is the one the original assumption sets up: AI risk is broader than the confidentiality, integrity and availability triad, so the CISO is the right convener but cannot own it alone, and a bias or a safety failure will never surface on a security dashboard. Treat AI risk as only a security problem and you will govern the one characteristic you already knew how to govern while missing the other six.

What the AI RMF work carries over to

The work you do for AI RMF has second-use value, because the inventory, the context records from Map, the measurements and the management evidence are the same artefacts the other AI governance regimes ask an organisation to produce, so one well-run program can feed several without rebuilding the evidence base.

The boundary is worth keeping explicit. NIST has authored a trustworthiness-characteristics crosswalk covering the OECD AI Principles and the 2021 proposed EU AI Act, and a separate crosswalk from AI RMF 1.0 to ISO/IEC 23894, and those are the cleanest alignments to claim. The EU AI Act mapping is characteristics-level and tracks the 2021 proposed text, so it works as a directional guide that predates the final EU AI Act enacted in Regulation 2024/1689. For ISO/IEC 42001, the widely circulated crosswalk on NIST's AI resource centre was contributed by a third party; NIST did not author it, so AI RMF practices are reusable input to a 42001 management system, which wraps them in a certifiable shell, and the two are not officially mapped.

The EU AI Act deserves the same precision. Running AI RMF produces the evidence its provider obligations lean on, the risk records, the data governance, the logging and monitoring, the technical documentation, while conformity itself runs through harmonised standards being written by CEN-CENELEC, which give a presumption of conformity under Article 40 once they are cited in the Official Journal and to the extent they cover the relevant requirements; the European Commission has said ISO 42001 as it stands is not aligned with the Act's quality-management-system requirement, which is why a dedicated European standard is in development. The leverage is concrete: you produce the evidence once and spend it across frameworks.

The moment to do it

The timing is worth taking seriously. The EU AI Act's high-risk obligations begin to apply on 2 August 2026, and NIST has published an initial public draft, the Cybersecurity Framework Profile for AI (NIST IR 8596), the literal meeting point of the two frameworks this post is about, so the convergence is no longer hypothetical. CSF shops are closer to AI RMF than they think, and the real win is choosing to do it on infrastructure that turns that single effort into ISO 42001 and EU AI Act progress too.

Modulos runs the NIST AI RMF, ISO 42001, the EU AI Act and the frameworks you already report against in one connected Governance Graph, so the controls and evidence you build for AI RMF carry across the others instead of being rebuilt each time. If you want to see your CSF program mapped to AI RMF and onward, request a demo and we will walk you through it.

Frequently asked questions

What is the difference between NIST CSF and NIST AI RMF? NIST CSF governs cybersecurity risk to information systems, while NIST AI RMF governs the risks of AI systems across seven trustworthiness characteristics, of which security is only one. They share NIST's voluntary, outcome-based structure and both now have a Govern function, but AI RMF adds context-framing (Map), trustworthiness measurement (Measure), a sociotechnical view of harm, and an AI lifecycle the CSF does not cover.

Can I reuse my NIST CSF program for AI RMF? The governance operating model transfers; the AI-specific substance still has to be built. The governance body, risk register, inventory discipline, supply-chain practices, Profile workflow and board cadence carry over and need extending for AI scope, roles and lifecycle triggers, while the AI inventory, the Map and Measure functions and the trustworthiness controls are new.

Does NIST AI RMF help with ISO 42001 and the EU AI Act? It helps by producing reusable evidence: the inventory, risk records, measurements and management evidence feed an ISO 42001 management system and the EU AI Act's provider obligations, while EU AI Act conformity still runs through harmonised standards and Article 40, so neither AI RMF adoption nor ISO 42001 certification produces it on its own.

Is there an official NIST crosswalk from AI RMF to ISO 42001? There is no official NIST crosswalk from AI RMF to ISO/IEC 42001. NIST authored crosswalks to the OECD AI Principles, ISO/IEC 23894 and the proposed 2021 EU AI Act, while the ISO/IEC 42001 crosswalk circulated on NIST's AI resource centre was contributed by a third party.