Where to start with the NIST AI RMF implementation roadmap
When a customer, contract or regulator points to the NIST AI RMF, start with Govern outcomes, then move to Map, using a current profile scored against the 72 subcategories. NIST's AI RMF 1.0 (NIST AI 100-1) is voluntary and has no certification, so nothing you adopt here produces a badge or a pass. NIST says most users start with Map after putting Govern outcomes in place, then continue to Measure or Manage, and it explicitly does not treat the framework as a checklist or an ordered set of steps. The first practical task is therefore to decide which categories and subcategories apply to you, based on your resources and capabilities, rather than working through all 72 in numerical order.
The right first steps depend on three things you should establish before scoping any work: what controls and policies already exist (many AI-relevant practices may sit in privacy, security or model risk programs), what your AI system inventory looks like (you cannot map systems you have not listed), and how much risk each system carries. A current profile records how AI risk is managed today, a target profile records the outcomes you need, and the gap between them becomes an action plan. Ask your team to score each subcategory from 1 (new, no action yet) to 4 (established and constantly improving), then prioritize by assessed impact. The City of San Jose used this scoring approach across all 72 subcategories, which is a useful model for the exercise, not a benchmark for your results.
Keep the division of responsibilities clear from the start. Your organization owns its AI governance, risk decisions and controls. An implementation partner can help prepare systems, map existing controls, draft policies and assemble evidence, but it does not decide your risk tolerance or sign off on your conclusions. NIST notes that the framework does not prescribe risk tolerance, so where sector rules are silent you must define a reasonable one yourself. If a customer wants independent assurance, only an independent auditor or assessor can issue a report, and you should confirm with that provider exactly which framework and evidence it will test before work begins.
How the AI RMF adoption sequence works, phase by phase
The sequence moves from governance outcomes to a documented view of AI risk, then to prioritized gaps and ongoing measurement and management, so each phase produces an input the next one needs. NIST describes the order as a starting pattern rather than a fixed checklist.
Establish Govern outcomes first
Leadership sets the governance foundation before any system is assessed. Executive sponsors, the risk or AI governance owner and product owners agree on a written AI policy covering roles, responsibilities and AI principles, and they document how the organization defines risk tolerance. Where sector rules set risk criteria, those rules apply; where none exist, the organization defines a reasonable tolerance itself. The output is an approved policy set, a named accountability structure and a risk tolerance statement. The step is done when each Govern category has a named owner and a document a reviewer can read.
Inventory the AI systems in use
The team builds a register of every AI system the organization builds, buys, embeds or depends on, including third-party models and AI features inside existing software. Procurement, IT, business units and engineering each contribute, because shadow tools often sit outside the official stack. The output is an inventory with an owner, purpose and status for each entry. The step is done when the business units have confirmed the list and no known system is missing from it.
Map context and categorization for priority systems
Using the inventory, the team ranks systems by potential impact and maps the Map function for the highest-priority ones first. For each system it records intended purpose, the people affected, the operating context, the tasks and methods involved, known knowledge limits and how humans use its outputs. NIST notes that most users start with Map once Govern outcomes are in place, so this is where the framework's sequencing begins to shape daily work. The output is a context and categorization record per priority system. The step is done when the system owner and a reviewer agree that the record describes how the system is actually used.
Build the Current Profile across subcategories
The team scores how AI risk is managed today against the 72 subcategories, using a consistent scale for each one. The City of San Jose used a 1 to 4 scale running from new, with no action yet, to established and constantly improving, and that scale is one option rather than a required method. Evidence is gathered per subcategory so each score can be defended. The output is a Current Profile showing where practice exists, where it is partial and where it is absent. The step is done when every subcategory the organization chose to apply has a score and a supporting reference.
Define the Target Profile
Leaders describe the outcomes the organization needs for its AI systems, based on its mission, its regulatory obligations and its risk tolerance. The Target Profile sets the desired state for each relevant subcategory, which may differ between a low-impact internal tool and a system that affects customers or safety. The output is a Target Profile approved by the executive sponsor. The step is done when the target states are specific enough that someone could tell whether a subcategory has reached them.
Prioritize gaps by risk and assign actions
The team compares the Current and Target Profiles to list the gaps and ranks them by the assessed risk level and potential impact of the affected AI systems. NIST cautions that eliminating negative risk entirely can be counterproductive, so the ranking decides where resources go first rather than promising to close every gap. Each priority gap gets an owner, an action and a review date set by the organization. The output is a prioritized action plan. The step is done when the executive sponsor has accepted the ranking and the resourcing decisions behind it.
Move into Measure and Manage
With priorities set, the team selects metrics for the most significant mapped risks and tests the trustworthiness characteristics those risks touch. Results then feed Manage decisions: go or no-go determinations, risk treatment, residual risk documentation and monitoring after deployment. NIST says the functions can be performed in any order once governance is in place, so teams often loop back to Map as systems change. The output is a measurement plan, a set of risk treatment decisions and a monitoring schedule. The step is done when each priority system has documented metrics, a current treatment decision and a named owner for ongoing review.
Why Govern comes first and what it must produce
Govern comes first because NIST describes it as a cross-cutting function that sets the structure the other three functions depend on. NIST AI 100-1 says the functions can be performed in any order once a governance structure is in place, and that most users start with Map after Govern outcomes are established. In practice, that means the executive team should not treat Govern as paperwork to finish later. Map and Measure produce findings that have nowhere to go unless someone with authority has already decided who owns them, which policy they are tested against, and how much risk the organization will accept.
The outcomes to establish first are a documented AI policy, named accountability and roles, a stated risk tolerance, and an AI inventory. The policy should set principles, scope and executive sponsorship. Accountability means naming the owners who can approve a go or no-go decision and escalate risks. The AI inventory is the list of systems the rest of the work will assess, so it should be complete before scoring begins. Risk tolerance is the decision most often skipped. AI 100-1 says the framework does not prescribe a tolerance. Organizations should follow any sector rules that set risk criteria and, where none exist, define a reasonable tolerance themselves. Confirm with legal and sector regulators whether such rules apply before the executive signs off.
Ask the executive sponsor to approve four items in writing: the policy, the accountable owners, the risk tolerance with its basis, and the inventory scope and owner. Each one should carry a review date, since AI 100-1 encourages periodic evaluation of whether the framework is improving risk management. Keep these decisions short and specific. A policy that names no owner or tolerance will not give the Map and Measure teams anything to test against, and it will be difficult to explain to a customer or regulator later.
How to score a current profile against all 72 subcategories
The City of San Jose scored its AI governance against all 72 AI RMF subcategories on a 1 to 4 scale, then compared where it stood with where it needed to be. The four steps below show how to repeat that work in your own environment, from gathering evidence to turning gaps into action plans.
Gather evidence for each subcategory
Before scoring, collect the policies, meeting records, test results, inventories and tickets that show how each subcategory is handled today. Work through the subcategories in the order of the four functions, and note for each one where the evidence lives and who owns it. A subcategory with no traceable evidence is a signal in itself, so record the absence instead of inferring a score. The NIST Playbook's documentation prompts are a practical starting list of artifacts to look for.
Assign scores with a second reviewer
Score each subcategory from 1 (new, no action yet) to 4 (established and constantly improving), using the same scale across every AI system in scope. Have a second person who did not gather the evidence review each score, because a single reviewer tends to rate their own team's work too generously. Calculate category averages only after the individual scores are settled, so the results show where the program is weakest.
Record the rationale for each score
Write one or two sentences beside every score explaining why it was given, citing the evidence reviewed and the date of review. A score of 2 for MEASURE, for example, should say which evaluations exist and which are missing. These notes make the assessment repeatable in the next cycle and give auditors, customers or regulators a traceable basis for the result. Store the scoring sheet under version control so changes between cycles remain visible.
Turn gaps into action plans
Set a Target Profile describing the outcomes your organization needs, then compare it with the Current Profile to find the gaps. AI 100-1 Section 6 says prioritization should follow the user's needs and risk management processes, so rank gaps by the risk and impact of the AI systems they affect rather than by how easy they are to close. San Jose's gaps led to a formal citywide policy, cross-department education, feedback mechanisms and evaluation procedures, which is the pattern to copy: each gap gets an owner, a plan and a review date.
What the City of San Jose and Workday did first
The City of San Jose and Workday offer two NIST-documented examples of how an organization can begin with the AI RMF. Neither is guidance on what you will find in your own environment, but both show a starting move that is easy to copy: measure where you stand against the framework before you decide what to build. San Jose assessed its AI governance against all 72 AI RMF subcategories, scoring each from 1 (new, no action yet) to 4 (established and constantly improving). Its average scores were Govern 2.3, Manage 2.3, Map 2.8 and Measure 1.7. The lowest score, in Measure, pointed to evaluation work that had not yet been formalized. From that review, the city identified four gaps: a formal citywide AI policy covering roles and responsibilities, executive sponsorship and AI principles; AI education across departments; formal end-user feedback mechanisms; and evaluation procedures covering robustness testing, drift, stress testing, error documentation and decommissioning.
Workday's privacy and data engineering team took a different route into the same exercise. It first mapped the AI RMF to Workday's existing common control framework, identifying which existing controls and processes already corresponded to AI RMF categories and subcategories, and which areas could be refined. The practical lesson is that many AI RMF outcomes may already be partly covered by controls you run for privacy, security or model risk, so your first task is to find that overlap and avoid building duplicate processes. Before you copy either approach, confirm three things in your own organization: who owns the scoring exercise, which existing control catalog you will map against, and what evidence an assessor or customer would expect for each subcategory you score as established. Keep in mind that NIST describes the AI RMF as voluntary, and that a scoring exercise produces an internal baseline, not a certificate.
Prioritizing by risk when you cannot do everything at once
NIST AI 100-1 lets organizations choose which categories and subcategories to apply based on their resources and capabilities, and it ties policy and resource decisions to each system's assessed risk and potential impact. The four criteria below help you rank AI systems so that the first pass of Govern, Map and Measure work lands where a mistake would cost the most.
System impact on people
Start by asking who is affected if the system is wrong and how badly. A system that informs hiring, credit, clinical triage or benefits decisions carries more weight than an internal summarization tool used by a few staff. Record the people affected, the decisions the output feeds, and whether a person reviews the output before it takes effect. Systems with direct effects on individuals usually move to the front of the Map and Measure queue, because the impact on individuals sets the depth of testing you need before any deployment decision.
Sector rules
AI 100-1 says the framework does not prescribe risk tolerance. Where a sector already sets risk criteria or tolerance, follow those rules first and treat the framework as the structure around them. Where no sector rule exists, your organization must define a reasonable tolerance itself and document it under the Govern work. Confirm with your legal, compliance and sector regulators which requirements apply to each system before you rank it, since a regulated use case may move up the list regardless of its technical complexity.
Dependence on third-party models
Systems built on models, data or software you do not control need early attention because your team may have limited visibility into training data, testing and failure modes. Ask whether the vendor supplies documentation, evaluation results and change notices, and whether you can test the system yourself. A dependence on opaque third-party components often means the Govern 6 and Manage 3 outcomes must be addressed before Measure work can produce reliable evidence. Ask vendors for these artifacts in writing and note any gaps as residual risk.
Gaps that block go or no-go decisions
Some gaps stop a deployment decision outright: no named owner, no documented purpose, no way to stop or roll back the system, or no test results for the risks you identified. Treat these as blockers and resolve them before work on lower-priority systems. Mapping and measurement can still proceed in parallel, but a system without a documented go or no-go decision should not reach production. Review these blockers at each governance meeting until they close, and record who accepted any residual risk that remains.
Where to start depends on your organization's starting point
If your organization has no written AI policy, no named owner for AI risk and no inventory of AI systems, start with the Govern function. AI 100-1 describes Govern as cross-cutting, so its outcomes support every later step. Without them, Map and Measure results have no owner, no decision point and no place to go.
- Name an accountable executive: Assign a sponsor with authority to approve or stop AI use cases, and document the roles that report to them.
- Draft a baseline AI policy: Cover scope, principles, roles and how risk tolerance will be set. Use GOVERN 1 and GOVERN 2 as the checklist of outcomes to address.
- Build an AI inventory: List every system in use, in development or procured, including tools staff adopted without approval. This list drives every later scoring exercise.
The main risk of skipping these moves is scoring a framework nobody is accountable for. Teams then produce Map documents that no decision-maker reads, and the first serious incident finds no approved owner. Confirm with your leadership which risk criteria already exist in sector rules before you define your own tolerance.
If you already run a common control framework, a risk register or a set of privacy and security controls, you may not need to build AI governance from nothing. The Workday pattern in NIST's use case is to map the AI RMF against controls you already operate, identify which AI RMF categories are already covered, and mark the gaps where existing processes need refinement.
- Build the crosswalk first: Map each AI RMF category and subcategory to an existing control, process or owner. Record where the match is partial.
- Score the current profile: Score each subcategory on a 1 to 4 scale, as the City of San Jose did, so the gaps are visible rather than assumed.
- Test AI-specific gaps: Existing controls often cover data and access but miss model evaluation, drift monitoring and end-user feedback. Flag those as the first refinement candidates.
The main risk is treating a mapping as proof of coverage. A control written for conventional software may not test for bias, robustness or drift, so a green crosswalk can hide the AI-specific gaps. Ask the control owners to show evidence for each mapped line, not only the document that describes it.
If you procure AI from vendors rather than building models, many Measure outcomes assume access to training data and model internals that you do not have. Your first work is to define what you can verify, what you must contract for and who in your organization owns each vendor system. AI 100-1 gives you the flexibility to select the categories that fit your role.
- Inventory vendor AI: Record each procured system, the vendor, the use case and the people affected by its outputs.
- Set procurement requirements: Ask vendors for documentation of intended use, known limits, evaluation results and change notices before purchase.
- Assign an owner for the deployment context: The configuration, data you supply and decisions you make with outputs remain your responsibility, even when the model is not yours.
- Plan for vendor exit: Document a contingency for failure or withdrawal of a high-risk third-party system, covered by GOVERN 6 and MANAGE 3.
The main risk is accepting a vendor's assurance in place of your own evidence about the deployment. Vendor testing describes its own setting, not yours. Confirm with each vendor which evaluations they have run, under what conditions, and what they will share with you.
If you plan to deploy or run generative AI, add the Generative AI Profile, NIST AI 600-1, to your starting set. Published July 26, 2024, it defines 12 generative AI risks and lists suggested actions, each tied to an AI RMF subcategory. Use it to decide which generative risks apply to your use case before you pick measurement methods.
- Select applicable risks: Review the 12 generative AI risks and mark which ones your use case can realistically produce, such as confabulation, data privacy exposure or information integrity.
- Map the suggested actions: For each applicable risk, pull the linked subcategory and record which actions you will adopt, adapt or decline with reasons.
- Set evaluation procedures early: Define robustness tests, error documentation and a process for end users to report problems before go-live.
The main risk is launching a generative tool on general governance alone. Without risk-specific actions, the first failure will expose gaps in testing and reporting that a policy document cannot cover. Confirm which of the 12 risks your vendor or model documentation addresses, and where you must test yourself.
What to have in place before the Map and Measure work starts
Map and Measure produce useful results only when someone owns the answers and the starting picture is written down. The cards below are readiness checks the organization performs itself, in roughly the order they unlock the next step. An independent assessor, not an implementation partner, is the party that gives any assurance view on the results.
Named executive sponsor
Confirm one executive owns AI risk decisions before any scoring begins. AI 100-1 places governance outcomes ahead of the Map work, and San Jose's review ended with a call for executive sponsorship. Check that the sponsor has written authority to approve, pause or retire an AI system, and that this authority appears in a document the organization can produce on request.
Started AI system inventory
Begin a list of every AI system in use, in build, or procured from a vendor, including systems embedded in other software. Record the owner, purpose and business unit for each entry. An incomplete inventory is the most common reason a Current Profile understates risk, so treat the list as a living record that the Map work will extend rather than a finished artifact.
Draft Current Profile
Write a first Current Profile that describes how AI risk is managed today. AI 100-1 defines it as the baseline against which a Target Profile is compared to reveal gaps. Score each subcategory with the organization's own scale, mark the evidence behind each score, and flag subcategories where no evidence exists. A draft with honest gaps is more useful than a polished profile that overstates current practice.
Named owners for each function
Assign one accountable owner for each of Govern, Map, Measure and Manage, and record who works on each category. Owners are the people who answer questions when a customer or regulator asks how a subcategory is met. Confirm that each owner has the time and the authority to act, since a function without a named owner tends to stall at its first disagreement.
Playbook used as a reference
Use the Playbook for suggested actions and documentation prompts, and record which entries your organization adopts, adapts or sets aside. NIST says the Playbook is neither a checklist nor a set of steps, and its audit log shows the last content update in August 2023, with an update planned after the AI RMF is revised. Note in your records which version of the Playbook you used so later reviewers can see what guided each decision.
Plan for the pending revision
NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan and has not published a revised version. Record which version your program is built on, list the subcategories most likely to change, and set a review date to compare the program against any new release. Confirm with legal counsel whether any law or contract you operate under names a specific version of the framework.
Questions teams ask before starting the AI RMF
Is the NIST AI RMF required, and can we get certified against it?
No. The AI RMF is voluntary, and there is no certification for it. NIST's FAQ says neither private nor public sector organizations are required to use it, and NIST does not validate or endorse any organization's use of the framework. A customer or regulator may still ask you to show how you manage AI risk, so you can describe your program against the framework and back it with evidence. Only an independent auditor or certification body can issue a report or certificate for a specific standard. If a customer wants a certificate, ask which standard they mean, since the AI RMF cannot be certified. For that case, see the ISO/IEC 42001 question below.
How long does the first phase of the AI RMF take?
NIST does not set a duration for adoption, so the timeline depends on your scope. The main drivers are how many AI systems are in scope, how much governance already exists, how many teams hold relevant records, and whether you need to build an AI inventory from scratch. Start by agreeing on the systems and business units covered, then ask any implementation partner for a written schedule tied to those deliverables. Confirm with your own environment and leadership how much time is available before you commit to a date.
Do we need outside help to score our Current Profile?
Not necessarily. NIST describes Current and Target Profiles as a way to record how AI risk is managed today and what outcomes you need, and an internal team can complete this work. The City of San Jose scored its governance against all 72 subcategories on a 1 to 4 scale, which shows how a scoring exercise can be structured. Outside help is most useful for an independent view, since scores set by the team that runs the program can be optimistic. Ask any partner to explain how scores will be evidenced and who will challenge them. Note that the AI RMF does not issue or endorse scores, so the value lies in the internal decisions they support.
Can we start with one AI system instead of the whole portfolio?
Yes. NIST's AI 100-1 says users may select from among the categories and subcategories or apply all of them, based on their resources and capabilities. A common approach is to pilot the Govern outcomes across the organization, then apply Map and later Measure and Manage to one high-impact system. Keep the governance policies and roles organization-wide so the pilot does not create a separate process. Choose the first system based on its potential impact on people and the business. Confirm with your leadership which systems are in scope before you write the first Target Profile.
Which parts of the AI RMF should we keep in-house and which should we outsource?
Keep decisions in-house. The organization owns its risk tolerance, governance roles, go or no-go determinations and residual risk acceptance. These are business and accountability choices that an outside party cannot make for you. Consider outside help for work that benefits from separation or specialized skill: an independent view of the Current Profile, testing of AI systems by a team separate from the developers, red teaming and evaluation procedures. NIST's AI 100-1 notes that the AI RMF can prioritize risk but does not set risk tolerance, so follow sector rules where they exist and define a reasonable tolerance where they do not. Ask any partner to state clearly which deliverables they prepare and which decisions remain yours.
How does the AI RMF relate to ISO/IEC 42001 if a customer asks for a certificate?
The AI RMF is a voluntary risk framework, while ISO/IEC 42001 is a management system standard that an accredited certification body can audit and certify. They address overlapping topics, such as governance, impact assessment and monitoring, but they are not interchangeable. If a customer asks for a certificate, you need an ISO/IEC 42001 certification audit, and the AI RMF work can inform the management system design. Confirm the exact requirement in the contract, ask which standard and version the customer means, and check the certification scope with the certification body. Do not assume that AI RMF work alone will satisfy a certificate request. See the linked ISO/IEC 42001 information for the standard's requirements.
What should we confirm before writing the first Current Profile?
Confirm four things first. Agree the scope, meaning which AI systems, business units and vendors are covered. Confirm who will be accountable for each Govern outcome, since NIST treats Govern as a cross-cutting function that supports the rest. Gather existing documents, such as common control frameworks and policies, so you can map what you already have. Settle how each subcategory will be scored and what evidence supports each score. The Workday use case shows that mapping existing controls to AI RMF categories can reveal what already works and what needs refining. Ask any implementation partner to deliver these inputs in writing before work starts.
How DeployOpen helps teams plan the AI RMF roadmap
DeployOpen works on a fixed scope agreed in writing before any work starts. For a roadmap that begins with Govern outcomes and a Current Profile scored against the 72 subcategories, that scope usually names which functions and categories are covered, which systems and business units are included, what documents will be produced, and who on each side signs off. DeployOpen can help prepare the systems, controls and evidence that the program will rely on, such as policy drafts for the Govern 1 outcomes, AI inventory records, and the technical records that Measure outcomes depend on. A quote follows the written scope, and DeployOpen does not publish a price list, so the most useful thing to bring to a first conversation is a draft list of AI systems and the functions you already want covered.
Some roadmap work involves testing rather than documentation. Where the scope calls for it, DeployOpen can run security testing of AI systems and agents, including the adversarial testing that supports the secure and resilient characteristic. Testing scope should be set against the risks you have prioritized in the Map and Measure steps, and it should be agreed separately from any work that changes the system under test. Confirm with DeployOpen during scoping which test types are in and which are out, what access will be provided, and how findings will be handed over.
DeployOpen does not issue attestations, reports or certificates, and there is no NIST AI RMF certification to pursue. Your organization owns its AI risk decisions and its controls, and any assurance about them comes from an independent assessor you select. Before you engage anyone, confirm with the assessor what evidence they will test and which parts of the roadmap they will review, so that the work DeployOpen prepares matches what the assessor needs to see.
