Is the NIST AI RMF mandatory for your organization?
A customer questionnaire, a contract clause or a regulator's letter now names the NIST AI RMF, and you need to know whether that makes it mandatory. NIST says that neither private nor public sector organizations are required to use the framework, and there is no certification program for AI RMF 1.0. The framework becomes binding only when a specific statute, a contract term or a sector rule adopts it by name. Whether any of those apply depends on where you operate, which sector you serve, how you use AI and which customers ask for evidence. Start by listing every instrument that names the framework and recording the exact wording of each reference.
Responsibility splits three ways. Your organization owns its AI risk program, including the policies, the accountable roles and the decisions to accept, treat or stop a risk. An implementation partner such as DeployOpen can help prepare systems, documentation and evidence against the framework's subcategories, but it cannot set your risk tolerance or sign off on conformance. Only an independent auditor or assessor can report on conformance, and no assessor issues a NIST AI RMF certificate. If a customer asks for a certificate, confirm in writing which standard they mean, since a certificate request usually points to a different standard such as ISO/IEC 42001.
Three checks settle most cases. First, review the statutes where you operate. The Texas HB 149 enrolled text links a liability defense to substantial compliance with the most recent NIST Generative AI Profile or another recognized framework, and Montana's Right to Compute Act requires deployers of critical AI systems that control critical infrastructure to consider the NIST AI RMF in a risk policy. Colorado's SB24-205 referenced the framework, but the signed text of SB26-189 does not, so confirm which law applies to you. Second, read each customer clause and regulator letter for the exact phrase used. Third, if you work in financial services, check whether the Treasury's February 19, 2026 Financial Services AI Risk Management Framework applies. Ask counsel to confirm each conclusion in writing.
Which state laws name the NIST AI RMF and what each one asks
Texas HB 149, the Texas Responsible Artificial Intelligence Governance Act, added Section 552.105(e) to the Business and Commerce Code. The provision does not require any organization to adopt the NIST AI RMF. It gives a defendant a liability defense if the defendant substantially complied with the most recent NIST Generative AI Profile or another nationally or internationally recognized AI risk management framework, and the violation was discovered through specified channels.
- Covered discovery channels: The defense applies when the violation is found through feedback, adversarial or red-team testing, state agency guidelines, or an internal review process.
- Substantial compliance: The text requires substantial compliance at the time of the violation, so a paper policy without operating controls is unlikely to support the defense.
- Generative AI Profile reference: The named benchmark is the most recent NIST Generative AI Profile, which is NIST AI 600-1, or another recognized framework.
- Liability, not a duty: The statute shapes what a defendant can argue after a violation. It does not create a standalone obligation to run an AI risk program.
- Evidence trail: Keep dated records of the framework mapping, testing results and internal reviews that would show substantial compliance.
Ask counsel whether your systems fall within the statute's scope and which framework version is the most recent when you rely on it.
Montana Code 2-10-205, enacted through the Right to Compute Act (Chapter 150, Laws of 2025), applies to a narrow class of systems. It targets the deployer of a critical artificial intelligence system that controls critical infrastructure facilities in whole or in part. That deployer must develop, after deployment, a reasonable risk management policy. The statute says the policy must consider the latest NIST AI Risk Management Framework, the ISO/IEC AI standard (written in the statute as "ISO/IEC 4200") or another recognized AI risk management framework.
- Narrow trigger: The duty applies to critical AI systems that control critical infrastructure facilities, not to AI use in general.
- Deployer role: The obligation sits with the deployer that operates the system, so vendors who only supply the model may face different questions in contracts.
- Timing after deployment: The policy is developed after deployment, so the organization needs a documented post-deployment review path.
- Framework choice: Organizations may cite the NIST AI RMF, the ISO/IEC standard or another recognized framework, and the text does not rank them.
- Latest version: The reference to the latest NIST framework matters because NIST is revising AI RMF 1.0, so track the version in force when you write the policy.
Confirm with counsel whether your facilities and systems meet the statutory definitions before treating this as an applicable duty.
Colorado SB24-205, signed May 17, 2024, required a deployer of a high-risk AI system to maintain a risk management policy and program. It required that program to be reasonable considering the guidance in the latest version of the NIST AI Risk Management Framework, ISO/IEC 42001 or another nationally or internationally recognized framework that is substantially equivalent or more stringent. That framework-based language gave deployers a recognized way to show reasonableness. The signed SB26-189 replaced that act, and its signed text does not mention NIST, ISO/IEC 42001 or any AI risk framework, so the framework-based program and affirmative defense language is not carried into the replacement law.
- Original structure: SB24-205 tied the deployer's risk program to named frameworks, so a documented mapping to those frameworks was the expected evidence.
- Replacement: SB26-189 does not carry forward the framework references, so do not assume that NIST or ISO alignment satisfies any Colorado requirement today.
- Historical relevance: Contracts, policies and internal programs written around SB24-205 may still cite it, so review them against the current text.
- Deployer scope: The original act focused on deployers of high-risk systems, a term defined in the statute, which organizations should compare with their own system inventory.
- Current status check: Confirm the operative law and any effective dates with counsel before making compliance statements to customers.
Check the signed SB26-189 text and any later amendments with counsel before updating a policy that still references SB24-205.
What changed when Colorado replaced SB24-205 with SB26-189
The original Colorado act, SB24-205, signed May 17, 2024, tied a deployer's risk management policy and program for high-risk AI systems to a reasonableness test. Under that text, a program was measured against the latest version of the NIST AI Risk Management Framework, ISO/IEC 42001, or another recognized framework that was substantially equivalent or more stringent. For organizations that deployed high-risk systems in Colorado, adopting the NIST AI RMF was therefore a direct way to show reasonable care, and the statute gave the framework a concrete role in that showing.
The signed text of SB26-189 does not mention NIST, ISO/IEC 42001 or any AI risk management framework. The framework-based risk program language and the related affirmative defense of SB24-205 do not carry into the replacement law. The NIST AI RMF remains available as a voluntary approach that any organization can use, but a Colorado obligation no longer points to it. If your Colorado compliance plan cited the framework as the statutory benchmark, that reference needs to be removed or reworded in the plan, the policy and any board or customer materials.
Ask counsel to confirm the current obligations, effective dates and any remaining deployer duties under SB26-189 before you change the program, and record that advice in your governance file. Keep the AI risk management program documented regardless of the statute. Customers, procurement teams and other regulators may still ask for a written risk policy, an inventory of AI systems and evidence of testing and monitoring, and the NIST AI RMF is a common structure for those answers. Documentation that already maps to the framework's Govern, Map, Measure and Manage functions will be easier to reuse than a program rebuilt from scratch.
Where the framework becomes a practical expectation
The NIST AI RMF stays voluntary in law, but it reaches organizations through questionnaires, contracts, sector rules and state statutes. Each channel asks for something different, so the same governance evidence often has to be packaged several ways.
Customer security and third-party questionnaires
Enterprise buyers often add AI questions to security and third-party risk questionnaires and ask whether the vendor uses the AI RMF to govern its AI. Workday, a public NIST use case, anchored its responsible AI guidelines, product risk evaluation and third-party risk questionnaire in the framework and used it to show enterprise customers how its governance works. Requesters usually want to see a mapped governance structure, an AI inventory, and how risks are measured and tracked. Product security and the GRC or compliance lead usually answer, with legal reviewing any statements about the framework.
Enterprise procurement clauses
Contracts may require the supplier to follow a named AI risk framework, or to give notice of material changes to its AI risk program. Clauses that name the framework make the NIST AI RMF a contractual duty even though no law requires it. Check whether the clause requires adherence, a self-attestation, or evidence an assessor can review, and whether it names the version. Legal, procurement and the account owner usually negotiate these terms, while the security or AI governance lead confirms the organization can meet them.
Sector frameworks built on the AI RMF
Sector regulators and industry bodies sometimes adapt the framework to their own rules. The U.S. Treasury released the Financial Services AI Risk Management Framework on February 19, 2026, and Treasury says it adapts the NIST AI RMF to financial services. Banks, fintechs and their vendors should read the sector text first, because it can add expectations the general framework does not. Chief risk officers, model risk teams and the CISO usually own the response, and they should confirm which sector text their supervisor expects.
State laws that name the framework
Some state statutes refer to the NIST AI RMF, and the reference can matter for liability or for the reasonableness of a risk program. Texas HB 149 ties a liability defense to substantial compliance with the most recent NIST Generative AI Profile or another recognized framework. Montana's Right to Compute Act asks critical infrastructure deployers to consider the latest NIST AI RMF in their risk policy. Colorado's SB24-205 referenced it, but the signed SB26-189 does not. Legal counsel should confirm whether a statute applies to the organization and which version it cites.
Which response fits when a customer asks for NIST AI RMF alignment
This table compares four responses to a customer request for NIST AI RMF alignment, with the output each one produces and who produces it. No NIST AI RMF certificate exists, so read the output column as the document a reader can actually receive. The main takeaway is that an internal self-assessment and an independent review are both useful, but neither is a certificate.
| Response | When it fits | Who produces the output | What the output is called |
|---|---|---|---|
| Internal self-assessment | The customer asks how you govern AI and wants a mapped answer to the 72 subcategories without a formal review. | The organization, with optional help from an implementation partner preparing evidence. | Self-assessment against the AI RMF Core, often a Current and Target Profile gap report. |
| Independent third-party review of the self-assessment | The customer or contract expects outside scrutiny, but no certifiable standard is required. | An independent reviewer chosen by the organization. NIST does not validate or endorse individual organizations. | Independent review report of the AI RMF self-assessment. It is not a NIST certificate. |
| Sector adaptation | The organization operates in a sector with a published adaptation, such as financial services under the FS AI RMF. | The organization applies the adaptation, with its sector regulator or customer setting expectations. | Sector-specific self-assessment mapped to the adaptation. Confirm which adaptation the customer accepts. |
| ISO/IEC 42001 certification | The customer asks for a certifiable AI management system standard rather than a voluntary framework. | An accredited certification body issues the certificate. The organization and its implementation partner prepare the management system. | ISO/IEC 42001 certificate issued by a certification body, separate from any AI RMF work. |
| Customer questionnaire response only | The request is a short vendor questionnaire, and the customer accepts a narrative description of practices. | The organization, with its security or compliance lead. | Written response to the customer questionnaire, with supporting policy and governance documents. |
How to respond when a customer or regulator asks for NIST AI RMF evidence
This sequence turns a customer or regulator request into a dated, scoped written response that names the evidence behind each claim. It separates what the law or contract actually requires from what the organization chooses to show, so the response holds up when the reader checks it.
Confirm whether the request is a legal duty
Start by reading the request itself and sorting it into one of two buckets: a legal duty that a statute or regulation imposes, or a contractual expectation that a customer writes into a questionnaire, order form or master agreement. The NIST AI RMF is voluntary at the federal level, so a request that cites only the framework is usually a contract question, not a statutory one. Legal counsel should confirm which bucket applies. The output is a one-paragraph classification note naming the requesting party, the document that makes the request and whether it is binding. Done when counsel has signed off on the classification.
Identify the exact clause or statute
Pin down the specific provision that mentions the framework. A state law may reference the NIST AI RMF as one of several acceptable frameworks, and the wording of that reference determines what must be shown. Record the citation, the operative verb (for example, whether the text says a policy must consider a framework or must follow it) and any defined term that limits the duty. Where the request is a customer questionnaire, record the exact question numbers. The output is a citation register with one row per requirement. Done when every row quotes or paraphrases the operative language and names its source.
Agree on the scope of AI systems covered
Write down which AI systems the response covers. Many requests are broader than the systems the organization actually runs, and a response that claims more than it can evidence is the most common reason a written answer fails review. Decide with the requester whether scope means systems the organization builds, systems it buys from vendors, systems used in a specific product line or systems that affect a particular class of people. Legal and business owners make this decision, and the scope should be confirmed in writing. The output is a signed scope statement listing included systems, excluded systems and the reason for each exclusion. Done when the requester has acknowledged the scope in writing.
Inventory the AI systems and their owners
Build a register of every AI system inside the agreed scope, with a named business owner, a technical owner, the purpose of the system, the data it uses and whether it is built internally or supplied by a third party. Vendor-supplied systems need the same entry, along with the contract or documentation that describes what the vendor provides. An implementation partner can help assemble the register from cloud accounts, code repositories and procurement records, but the organization must confirm each entry and its owner. The output is a current inventory with an owner sign-off date. Done when no system in scope lacks an owner.
Map existing controls and documents to the four functions
For each inventoried system, match existing policies, procedures, test records, monitoring outputs and incident logs to the four AI RMF functions: Govern, Map, Measure and Manage. Use the category and subcategory references in the NIST AI RMF Playbook as prompts for what to look for, but treat its suggested actions as optional, since NIST says the Playbook is neither a checklist nor a set of steps. Gaps are recorded as gaps, not filled with aspirational text. An implementation partner can prepare the mapping workbook and collect evidence, while the organization decides which controls are adequate and accepts residual gaps. The output is a mapping workbook with a status and an evidence reference for each row. Done when every in-scope system has at least one evidence reference per function or a recorded gap.
Deliver a dated written response with named evidence
Write the response as a dated document that answers the request in the requester's own question order. For each claim, name the evidence (document title, version, date and owner), state the scope and state the known gaps and the plan for them. Avoid the word certified: NIST does not certify organizations, and only an independent auditor or assessor can issue a report on conformance. The response should say the organization self-assessed against the framework unless an independent party reviewed it, and should name that party if one did. Legal review should happen before release. The output is a signed response with an evidence annex and a version number. Done when the requester can trace every claim to a named document in the annex.
Does the planned NIST revision change who must follow it?
As of October 2026, NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan, and it has not published a revised version or a revision timeline. The July 2025 Action Plan recommends revising the framework to remove references to misinformation, diversity, equity and inclusion, and climate change. NIST also says the Playbook will be updated after the AI RMF is revised, and the Playbook's last content update is dated August 2023. For a team planning its program, the practical point is that the document is in flux while its content is still the version most organizations cite. Confirm the current text on the NIST AI Risk Management Framework page before you finalize any policy that quotes it.
Some state laws refer to the latest version of the NIST AI RMF rather than to a fixed edition. If a revision is published, a law written that way may point to the new document, and the content your program was built against could change under you. Record the exact version, publication date and section references your governance policy relies on, and keep a dated copy of the Playbook pages you used. Assign one owner to watch NIST's AI RMF page and the AI Risk Management Framework FAQs, and set a review trigger for any published revision so the mapping from policy to subcategories is updated in one pass.
The revision does not, by itself, create a legal duty. A pending change to a voluntary framework leaves in place the framework's voluntary status, and it does not add a certification program or an assessor role that NIST has not described. Obligations still come from the statute, contract or sector rule that references the framework, and each of those should be read for the version it names. Ask counsel whether the law in your jurisdiction cites a fixed or a latest version, and ask each customer whether its contract points to a specific edition.
Who owns the obligation, who prepares the evidence and who attests
The organization owns every decision the framework asks for. NIST describes the AI RMF as voluntary, so no regulator or standards body assigns these duties by default. They arise when a customer contract, a state law or a sector rule makes the framework a practical expectation. Whatever the trigger, the decisions about AI risk stay with named people inside the organization, and a partner or auditor cannot make them on the organization's behalf.
- AI risk decisions: Senior leaders decide the risk tolerance, the go or no-go determination for each AI system and how residual risk is accepted. These are Govern and Manage outcomes, and they need named owners.
- AI inventory: The organization maintains the list of AI systems in use, including systems bought from vendors and systems built in-house, with their purpose and owner.
- Governance and approval: Policies, roles and escalation paths are approved internally and reviewed on a schedule the organization sets.
- Residual risk sign-off: Accepted risks are documented with the approver's name, date and the conditions attached to the acceptance.
Confirm that each decision has a named owner who can explain it to a customer or assessor without referring to a consultant.
An implementation partner prepares the systems and records that the organization's decisions rely on. For self-hosted AI systems running in the client's own cloud accounts, data centers or air-gapped networks, this work is technical and continuous. The partner does not decide whether a risk is acceptable and does not sign any statement about compliance. Its output is material the organization reviews and adopts.
- Documentation: Drafting system descriptions, data flow records and model documentation that the organization reviews and approves.
- Testing evidence: Running and recording evaluations, security tests and results so the organization can show what was measured and when.
- Logging and monitoring: Configuring logging, alerting and monitoring for self-hosted AI systems so that production behavior and incidents leave a record.
- Playbook-based gap work: Walking through the Playbook suggested actions against the organization's Current and Target Profiles and listing where evidence is missing.
- Independence boundary: The partner cannot issue reports, attestations or certificates, and it should not assess its own build as independent evidence.
Ask the partner to state in writing which deliverables it prepares and which decisions remain with the organization.
An independent auditor or assessor tests the organization's program against a stated scope and issues whatever report the engagement defines. This party is separate from both the organization's decision makers and the people who built the systems. Its value comes from that separation, and it is only useful if the scope and the report type are agreed before testing starts.
- Scope testing: The assessor tests the controls, records and systems named in the engagement terms, not the framework in general.
- Report issuance: The assessor issues only the report or statement the engagement defines, with the wording it chooses.
- No NIST endorsement: NIST states that it does not validate or endorse any individual organization or its approach to using the AI RMF, so no NIST statement can serve as proof of conformance.
- No AI RMF certificate: No accredited AI RMF certificate exists. Any certificate offered for the framework should be treated as unverified until its issuer and scope are checked.
- Independence boundary: The assessor must not design the controls it tests or prepare the evidence it reviews.
Confirm the assessor's independence policy, the report type and the exact scope before signing an engagement.
Questions buyers ask about NIST AI RMF obligations
Does any federal law require the NIST AI RMF?
No federal law that NIST's own materials identify requires the NIST AI RMF. NIST's FAQ states that neither private nor public sector organizations are required to use the framework, which NIST produced as a voluntary framework after Congress directed it to work with the private and public sectors. That answer does not cover sector rules. Regulators in banking, healthcare, critical infrastructure and public procurement can name AI risk management expectations in their own guidance or contract terms, so check the rules that apply to your sector with your regulator or counsel before concluding that the framework is optional for you.
Do Texas or Montana AI laws apply to a company based outside Texas?
It depends on where your AI systems are deployed, who uses them and what they do, so the answer needs a legal reading of each statute. Texas adds Section 552.105(e) to its Business and Commerce Code through HB 149, which limits liability for a defendant that discovers a violation through testing or internal review while substantially complying with the most recent NIST Generative AI Profile or another recognized AI risk management framework. Montana Code 2-10-205, added by the Right to Compute Act, applies to deployers of a critical artificial intelligence system that controls critical infrastructure facilities in whole or in part. Ask counsel whether your activities fall within either statute's definitions before relying on either one.
Can a customer require the NIST AI RMF in a contract?
Yes. The framework is voluntary for regulators, but a customer can write it into a contract, security questionnaire or procurement requirement, and then it becomes an obligation under that contract. Workday, an enterprise cloud applications provider, told NIST it anchored its responsible AI guidelines, product risk evaluation and third-party risk questionnaire in the AI RMF, which shows how vendors use it to answer enterprise customers. When a contract names the framework, define the version, the scope of systems covered, the evidence you will provide and who verifies it. Otherwise the term can be read more broadly than your program supports.
Is there a NIST AI RMF certification, and what should customers ask for instead?
No. NIST does not validate or endorse any individual organization or its approach to using the AI RMF, and its framework materials describe no certification, accreditation or conformity assessment program. Customers should ask for a written self-assessment mapped to the 72 subcategories, the Current and Target Profiles behind it, the documentation kept in line with the Playbook, and any independent review the organization has commissioned. If a customer asks for a certificate, ask which accredited body issued it and under which standard, because a certificate for a different standard, such as ISO/IEC 42001, answers a different question.
Can our own staff do the NIST AI RMF readiness work?
Yes, many organizations do the readiness work internally, because the framework is voluntary and NIST lets users choose which categories and subcategories to apply. The work needs people who own AI systems, people who understand the data and model risks, and someone who can write and maintain governance documents and keep them current. It also needs an owner for risk decisions and time for testing and monitoring. Staff without prior AI risk experience will usually need to learn the four functions and the Playbook before they can judge the gaps. An implementation partner can prepare systems and evidence, but the organization owns its controls and decisions.
How long does NIST AI RMF readiness work take?
No supplied figure exists for how long this work takes, so ask any partner or internal lead to scope it before you commit. The duration depends on the number of AI systems in scope, how much governance documentation already exists, how mature your testing and monitoring practices are and whether you start with a Current Profile or a Target Profile. Ask for a written scope that lists the systems covered, the functions and categories included, the deliverables, the review points and the staff time you must provide. A fixed scope with agreed deliverables makes the timeline easier to check against progress.
What changes after NIST revises AI RMF 1.0?
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, so the content could change. The July 2025 AI Action Plan recommends removing references to misinformation, diversity, equity and inclusion, and climate change. NIST also expects a formal review no later than 2028, and the Playbook will be updated after the revision. Keep your mapping tied to the version you adopted, record the date of each review, and watch how state laws that cite the latest version respond, since those laws may point to the revised text once it is published.
When should outside counsel be involved in AI RMF decisions?
Involve counsel before you rely on any state statute, sector rule or contract clause that names the framework, and before you describe your program to a regulator, customer or court. Counsel can confirm whether a law applies to your deployments, what substantial compliance means under that law and whether a liability defense depends on specific documentation. Involve them early when a contract requires the framework, when your AI systems affect critical infrastructure or regulated financial or health decisions, and when a sector adaptation such as the Treasury's FS AI RMF applies to your business. Counsel does not replace an independent assessor for any technical or audit claim.
How DeployOpen scopes NIST AI RMF readiness work
DeployOpen works on the question of whether the NIST AI RMF applies to your organization by first mapping the contracts, customer questionnaires and state laws that bring it up. We then prepare the systems, controls and documentation that a written scope defines, inside your own infrastructure. We do not decide legal applicability and we do not issue any assessment or certificate.
How we scope
- We list the customer contracts, questionnaires, sector rules and state laws that reference the framework, and confirm which ones bind your organization.
- The written scope names the AI systems, business units and AI RMF categories or subcategories in play, so the work has defined boundaries.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and a quote follows from that scope.
How we build
- We help you set up an AI system inventory and a Current Profile that records where each subcategory stands today.
- We prepare Playbook-based documentation templates, risk records and evidence locations inside your own systems and cloud accounts.
- Where the scope includes it, we run security testing of AI applications, APIs and agents and document the findings against the relevant subcategories.
How we hand over
- You receive the documented configuration, policies, evidence register and gap list named in the written scope, so your staff can maintain them.
- We walk your governance owners through the artifacts and record who is accountable for each one.
- We state plainly which items still need an independent assessor's view, since DeployOpen does not issue reports or certificates.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial scope is delivered.
- We can refresh the Current Profile when NIST publishes a revised AI RMF or a new profile, and confirm the impact on your scope.
- Questions about legal applicability should be confirmed with your counsel, and independent assessment should be arranged with a qualified assessor of your choice.
Sources and further reading
- NIST: AI Risk Management Framework FAQs ↗
- NIST AIRC: AI RMF use cases ↗
- Texas HB 149 (Texas Responsible Artificial Intelligence Governance Act), enrolled text ↗
- Montana Code Annotated 2025, 2-10-205, Infrastructure controlled by critical artificial intelligence system ↗
- Colorado SB24-205, signed act ↗
- Colorado SB26-189, signed act ↗

