NIST AI RMF for AI vendors and SaaS providers: what buyers review

How AI vendors use the NIST AI RMF for enterprise AI risk reviews

For an AI vendor or SaaS provider, using the NIST AI RMF means mapping the controls and documentation you already run to the framework's Govern, Map, Measure and Manage functions, so that a customer's risk review can read your evidence against familiar categories. No certificate is issued at the end. The *NIST AI Risk Management Framework* is voluntary, and NIST states that it does not validate or endorse any organization's use of it. The answer you give a customer depends on your product, the data flows it creates, the customers you serve and how mature your evidence is. Your organization owns its controls and their outcomes. An implementation partner can help prepare systems, documentation and evidence for the mapping, but only an independent auditor or assessor issues a report, and a vendor should be clear with buyers about which of its materials fall into each category.

Start with a decision about scope. Decide which AI features a customer review will cover, which models are your own and which are third-party components, and which customer data those features touch. Then confirm with your team that each in-scope feature has an owner, an intended purpose and a documented set of known limitations. Under the Map function, the framework expects this context to be recorded before measurement begins. Check that your third-party model and data suppliers are named in the same inventory, since the framework's Govern and Manage material on third-party AI expects you to know which upstream resources can change your risk profile. Confirm these facts against your own environment before you describe them to a buyer.

Expect buyers to ask for evidence in the Generative AI Profile language if your product generates content. The profile's Appendix A.1.3 notes that existing risk controls can be applied to third-party generative AI through procurement due diligence, requests for software bills of materials, service level agreements and SSAE attestation reports, and action GV-6.1-004 suggests contracts that address content ownership, usage rights, quality, security and provenance. Decide which of these you can supply, and which you would need to create. Also decide how you will disclose negative residual risk, the unmitigated risk that MANAGE 1.4 asks you to document for downstream acquirers and end users. Ask your counsel and security lead to agree on that wording before a customer asks for it.

How Workday anchored its responsible AI practice in the AI RMF

Workday's account, published through NIST's AI RMF use cases, shows one enterprise software vendor building its responsible AI practice on the framework. The cards below follow its three anchored artifacts, the control mapping behind them, and its stated goal of showing customers how its governance works.

Responsible AI guidelines as the anchor

Workday reports that it anchored its responsible AI guidelines in the AI RMF, so the internal policy that product teams follow is organized around the framework's categories and subcategories. For an AI vendor, this is the document a buyer will ask to read first. Check whether the guidelines state which AI RMF categories they cover, who approves exceptions, and how often they are reviewed.

Product risk evaluation tied to the framework

Workday also anchored its product risk evaluation in the AI RMF, so each AI feature is assessed against framework expectations before and during release. This is where the Map and Measure functions become working practice rather than policy text. Ask a vendor to show a completed evaluation for one feature, including the risks it identified, the metrics it tracked and the decision it recorded.

Third-party risk questionnaire built on the framework

Workday anchored its third-party risk questionnaire in the AI RMF, which means the questions it asks of its own suppliers reflect the same framework it uses internally. For a SaaS provider, the same questionnaire logic is what enterprise customers will send back to you. Confirm that your answers can be traced to a named control or document, not only to a yes or no.

Mapping the framework to the existing common control framework

Workday's privacy and data engineering team began by mapping the AI RMF to its existing common control framework. The team identified controls and processes that already corresponded to AI RMF categories and subcategories, then marked the areas that needed refinement. Vendors without a common control catalog can use the same method: list current controls, map each to a subcategory, and record gaps as work items.

Starting from controls already in place

The mapping did not begin with a blank page. Existing controls were credited where they matched the framework, and refinement effort went to the gaps. This keeps the program tied to evidence the organization already produces, such as access reviews and change records, instead of creating parallel paperwork. Ask whether the vendor can show which existing control covers each AI RMF area it claims.

Communicating governance rigor to customers

Workday states that one goal is to communicate the rigor of its AI governance approach to enterprise customers. The framework gives both sides a shared vocabulary for risk reviews, which can shorten questionnaire cycles. Note that this is Workday's own description of its purpose. NIST does not validate or endorse Workday's approach, and the AI RMF has no certification that a vendor can display.

Which evidence to offer for each type of customer review

This table compares four common reviews a vendor faces, the AI RMF functions each one draws on, the evidence buyers usually request, and what to prepare before the request arrives. Buyers choose which items they need, so the list is a menu to prepare from, not a fixed package.

Review type	AI RMF functions drawn on	Evidence the buyer usually asks for	What the vendor should prepare in advance
Security questionnaire	Govern 6, Manage 3, Measure 2 (security characteristics)	Security policies, access controls, vulnerability management records, incident response contacts, subprocessor list	A maintained questionnaire library with answers tied to documented controls and current evidence dates
AI-specific risk review	Map 1, Map 2, Map 5, Measure 2, Measure 3	Intended purpose and limits, model or system description, TEVV summaries, known risks, human oversight design, end user reporting channels	A system card or documentation pack for each AI feature, with known limitations stated plainly and a record of recent evaluations
Procurement due diligence	Govern 1, Govern 6, Manage 3	Software bill of materials (SBOM) requests, service level agreements, SSAE attestation reports, content ownership and provenance terms, data use terms	Standard contract language on data and model training use, a current SBOM for the AI stack, and the SSAE attestation report the vendor can share
Acquirer diligence	Govern 1, Manage 1 (residual risk), Manage 4	AI inventory, documented negative residual risks, open incidents, third-party dependencies, governance records and decision logs	A residual risk register following MANAGE 1.4, an AI inventory with owners, and a summary of unresolved risks ready for disclosure

How to build the AI risk evidence pack before the first review

This sequence turns scattered AI governance practice into a single, owned evidence pack that answers an enterprise customer's AI risk questionnaire with records rather than assertions. Each phase produces an artifact the next phase depends on.

Inventory AI systems and third-party components
Product, engineering and security leads list every AI system you build, deploy or resell, including the models, APIs, datasets and open-source components each one depends on. The output is an AI inventory with a named system owner, the customer-facing features that use each system, and the upstream providers behind it. You know this step is done when a reviewer can trace any customer-facing AI feature to a system record and its supplier list.
Map existing controls to AI RMF categories
Compliance and security staff compare your current control set, such as your common control framework, security policies and third-party risk questionnaire, against the Govern, Map, Measure and Manage categories and subcategories. Workday's published approach started from its existing common control framework, which shows the method: first identify controls that already correspond, then mark the gaps to refine. The output is a crosswalk workbook listing each subcategory, the control that addresses it, and the gap owner. This step is done when every subcategory has a status of covered, partial or open.
Document intended use and known limitations
Product and risk owners write a short intended-use statement for each inventoried system, covering its purpose, the users and deployers it serves, the decisions it informs, and the conditions where its output should not be relied on. They also record known limitations and the human oversight expected at each point. The output is one system card per AI system, reviewed and signed by the product owner. This step is done when a customer could read the card and understand where the system is and is not appropriate to use.
Define residual risk and disclosure content
Risk owners record the risks each system still carries after mitigation and decide what must be disclosed to downstream acquirers and end users. MANAGE 1.4 in NIST AI 100-1 calls for documenting negative residual risks, defined as the sum of all unmitigated risks, to those parties. The output is a residual risk register per system and a disclosure summary that legal and product teams approve together. This step is done when every open risk in the crosswalk has a residual entry or a documented acceptance.
Collect test, evaluation and monitoring records
Engineering and security teams gather records that show how each system was tested and is watched in production, mapped to the MEASURE subcategories. This includes evaluation reports, red team or adversarial test results, bias and performance checks, and incident and end user feedback logs. Where your records use a developer's metrics, note that the developer's methodology may differ from your own, as AI 100-1 warns. The output is a dated test and monitoring index linked to each system card. This step is done when each measurement claim in a system card points to a retrievable record.
Gather third-party and contract evidence
Procurement and legal teams collect the supplier-side evidence that backs your own claims: supplier due diligence responses, software bills of materials where available, service level agreements, security attestation reports and contract clauses on content ownership, data use and provenance. The GAI Profile action GV-6.1-004 suggests drafting contracts that cover these points. The output is a supplier evidence folder with an expiry date for each document. Confirm with each supplier which attestations they can actually provide before you promise them to customers.
Assign owners and set the review cadence
Leadership names one accountable owner for each artifact in the pack, along with a backup, and agrees how often each one is reviewed and who approves changes. Set the review interval internally based on your release cadence and contractual commitments, since no fixed timeline applies here. The output is an ownership register and a change log that records every update to a system card, crosswalk row or disclosure. This step is done when a reviewer can see who answers for each artifact and when it was last confirmed.

What the Generative AI Profile asks vendors to show buyers

For an AI vendor or SaaS provider, the most useful part of the Generative AI Profile is its procurement guidance. NIST AI 600-1, published July 26, 2024, defines 12 generative AI risks and attaches suggested actions to subcategories of the AI RMF, so a vendor can trace each buyer question back to a named function and subcategory. The actions that matter most in an enterprise review are the ones about third parties and contracts, because enterprise customers will ask about them directly, often before they ask about model behavior.

The clearest example is GV-6.1-004, which suggests drafting and maintaining contracts and service level agreements that specify content ownership, usage rights, quality standards, security requirements and content provenance expectations. Before promising any of these terms, a vendor should confirm what it can actually supply: who owns generated output under its terms, what rights customers have to use it, which quality and security measures it can commit to in writing, and whether it can describe how content provenance is handled. Each commitment should map to a control the vendor operates and can evidence, not to a clause the legal team hopes engineering can meet.

AI 600-1 Appendix A.1.3 also says existing risk controls can be applied to proprietary or open-source generative AI and to third-party providers. That means a vendor should inventory which of its models and components are built in-house, which rely on open-source or licensed models, and which depend on upstream providers, then decide what evidence it can offer for each. Typical items named in the profile include procurement due diligence, software bills of materials (SBOMs), service level agreements and SSAE attestation reports. Confirm with your own engineering, security and legal teams which of these exist today, who signs off on them and how often they are refreshed, so the response to a buyer questionnaire matches the contract.

Which contract terms enterprise buyers negotiate for AI systems

Enterprise buyers often turn an AI risk review into contract terms, so the vendor's answers to the AI RMF questions need to appear in the agreement. The cards below cover the terms that GV-6.1-004 and the AI 600-1 procurement items point to, with the decisions vendors should settle before negotiation and the evidence buyers usually request.

Content ownership

Decide before negotiation who owns inputs, prompts, outputs and any derived artifacts, and whether the vendor may use customer content to train or improve models. Buyers usually ask for a written statement of ownership for outputs and a clear list of what the vendor retains. Confirm the position on fine-tuned models and logs with counsel, because these often sit outside the default wording of a standard order form.

Usage rights and permitted uses

Define what the customer may do with generated content and what the vendor may do with customer data, including sublicensing to subprocessors and any use for product analytics. Buyers look for an explicit list of prohibited uses that matches the acceptable use policy the vendor publishes. Vendors should confirm that the grant covers the customer's affiliates and downstream users, since AI outputs often move into products the vendor never sees.

Quality standards

Decide which accuracy, reliability and evaluation metrics the vendor will commit to, and how it will report them. Buyers typically ask for the test methods behind any stated figure, the evaluation results for the use case they are buying, and the process for handling output that fails those tests. Commit only to metrics the vendor measures in production, because a warranty without monitoring evidence creates exposure that the vendor's own MEASURE records cannot support.

Security requirements

Set the security controls the vendor must maintain, such as access control, encryption, vulnerability management and secure development practices for the model and its supporting systems. Buyers often ask for an SSAE attestation report, a current penetration test summary and the vendor's answers to a security questionnaire, which AI 600-1 lists among procurement due diligence items. Vendors should confirm which of these they can provide on request and under what confidentiality terms.

Content provenance

Decide what information the vendor can give about the origin of training data, third-party models, and generated content, including any watermarking or metadata that marks AI-generated output. Buyers may request a software bill of materials for the components they run and documentation of the data sources the vendor is permitted to disclose. Where the vendor relies on upstream model providers, agree in advance what provenance details those providers must supply to the vendor.

Service levels and incident communication

Agree the availability targets, support response commitments and the timeline for notifying the customer of AI incidents, errors or material model changes. Buyers usually ask for the incident process, the named contacts and how the vendor communicates residual risks that remain after mitigation. Ask counsel to align the notice periods with the customer's own regulatory duties, since a short contractual window may not match what the buyer must report to its regulator.

Disclosing residual AI risk to acquirers and end users

MANAGE 1.4 asks vendors to document negative residual risks, meaning the sum of all unmitigated risks, and to share that documentation with downstream acquirers of the AI system and with end users. For an AI vendor or SaaS provider, this is the point where internal risk work becomes something a customer can rely on. A residual risk register that stays inside the engineering or risk team does not meet the subcategory's intent. The practical first step is to decide which residual risks exist after your controls, evaluations and Manage-stage responses are applied, and to write them down in terms a customer's risk committee can read. Those risks include known failure modes, populations or use cases where performance is weaker, and risks your team has accepted but not eliminated.

AI 100-1 also notes that the organization developing an AI system may use risk metrics or methodologies that do not align with those of the organization deploying or operating it, and that the developer may not be transparent about them. A buyer can therefore read a clean accuracy figure or a passing safety score and draw conclusions the metric was never designed to support. The vendor should state which metrics it uses, what each one measures, the test data and conditions behind it, and what it does not measure. Confirm with your own evaluation and measurement owners whether those limits are written down anywhere a customer can find them, and whether the statements match what the MEASURE results actually show.

Residual risk disclosure usually appears in two places. In acquisition diligence, it surfaces as answers to AI risk questionnaires, data room documents and, for enterprise deals, representations in the commercial agreement. In product documentation, it appears as model cards, intended use and out-of-scope use statements, known limitations and guidance for human oversight. Whether and how much to disclose is a legal and business decision for the vendor, made with counsel and the executives who own the risk. The NIST framework does not decide that question for you, but the Manage function expects the decision to be made deliberately, recorded and reviewed as the system changes.

Who owns the controls, who prepares the evidence and who issues the report

The vendor owns the AI risk management program. NIST AI 100-1 is voluntary and has no certification, so the vendor decides which Core categories and subcategories it adopts, how it documents them, and what it tells customers about them. The vendor's leadership also makes the go or no-go decisions for AI features and accepts the residual risk that remains after controls are applied. Those decisions cannot be delegated to a consultant or auditor without losing their meaning in a customer review.

Governance and accountability: Named owners for AI policy, risk tolerance, the AI inventory and executive sign-off on AI risk decisions, mapped to GOVERN 1 and GOVERN 2.
Contract terms: Customer-facing terms on data use, security, provenance and service levels, drafted with legal counsel and aligned with the GAI Profile action GV-6.1-004.
Residual risk disclosure: A documented statement of negative residual risks shared with downstream acquirers and end users, as MANAGE 1.4 describes.
Third-party components: Ownership of decisions on the models, data and software the vendor depends on, including SBOM requests and supplier monitoring.

Before any review, confirm that each claim in your questionnaire answer traces to a named internal owner and a document that person maintains.

Why AI risk reviews stall and how vendors avoid it

Enterprise customers review AI vendors with the same questions again and again, and the reviews slow down when the answers are improvised. The cards below cover the pitfalls that most often stall these reviews, what causes each one, and the practical fix that ties back to the evidence pack and contract terms.

Answering every questionnaire from scratch

Each customer sends a different third-party risk questionnaire, and teams rebuild answers from memory. The result is inconsistent claims across deals and reviews that restart whenever a new product team joins. Map your answers to AI RMF categories once, in a single evidence pack, then reuse that pack and update only the items that changed. Check whether your questionnaire answers match what your Govern and Map records actually show.

Claiming NIST AI RMF certification

Some vendors state they are "NIST AI RMF certified" to speed up reviews. No such certification exists, and NIST does not validate or endorse any organization's use of the framework. A claim like this invites a challenge that damages credibility. Describe the framework as voluntary, state which functions and categories you use, and point to independent audit reports for the controls they cover.

Missing documentation for third-party models

Reviewers ask which foundation models, datasets and libraries sit inside the product, and who documented their limits. Vendors often hold only the upstream provider's marketing material. Under GOVERN 6 and MAP 4, keep a component inventory with each third-party model's version, source, known limits and the contract that governs it. Confirm what each upstream provider will share before you promise it to a customer.

Undocumented negative residual risks

Customers expect to know what risk remains after controls are applied, and vendors that cannot describe it lose trust quickly. MANAGE 1.4 calls for documenting negative residual risks, defined as the sum of all unmitigated risks, for downstream acquirers and end users. Keep a residual risk register per product, with an owner and review date for each entry. Disclose it in the evidence pack so buyers see it before they ask.

Evidence that goes stale

A Playbook-style evidence set written for one release is out of date after the next model change, prompt update or incident. Reviewers then find test results and policies that no longer describe the product they are buying. Assign each evidence item an owner and a trigger for refresh, such as a model swap, a material incident or a changed data flow. Record the date of the last review on every page of the pack.

Contract terms set without product input

Sales teams often agree to service levels, content provenance promises or data use terms before security and product staff have reviewed them. Later, the product cannot meet what was promised. Under GV-6.1-004, draft contracts and service level agreements that cover content ownership, usage rights, quality, security and provenance, and route every AI-specific clause through product and security owners before signature. Keep a standard clause library so negotiated exceptions are visible.

Questions AI vendors ask before a customer requires the NIST AI RMF

Can the NIST AI RMF be certified?

No. The NIST AI RMF has no certification, accreditation or conformity assessment program. NIST does not validate or endorse any individual organization or its approach to using the framework, so a vendor cannot earn an AI RMF certificate. What a customer can accept instead is evidence that your organization has mapped its AI systems to the framework's Govern, Map, Measure and Manage functions: a documented governance policy, an AI system inventory, risk assessments, test and monitoring records, and a completed questionnaire or self-assessment that shows which categories and subcategories you applied. If a vendor or consultant offers an AI RMF certificate, ask who issued it and what standard it tests against before accepting it.

How long does the evidence work take, and what drives it?

The duration depends on how many AI systems you ship, how much of your existing security and privacy program you can reuse, and how many customer questionnaires you need to answer. NIST does not publish a timeline for AI RMF adoption, so treat any figure you see from a vendor as a quote to be checked against your own scope. The main drivers are the size of your AI system inventory, whether you already have documented risk management and third-party risk processes to map from, the depth of testing records you keep for model behavior, and whether you have to cover the Generative AI Profile in addition to the core framework. Ask for a written scope with deliverables and dates before work starts.

Can we do the AI RMF work in-house?

Yes, many vendors do the mapping themselves, since the framework is voluntary and NIST's Playbook supplies suggested actions and documentation prompts for each subcategory. Two things make in-house work harder: the Playbook is neither a checklist nor a set of steps, so your team must decide which actions apply, and its audit log shows the last content update in August 2023 while NIST's AI RMF revision is pending. A useful split is to keep ownership of controls, risk decisions and sign-off in-house, and consider an outside implementation partner for preparing systems, collecting evidence and documenting how controls operate. Confirm in your own environment whether your team has capacity for both the build and the ongoing evidence.

What does the work need from engineering, legal and security staff?

The work spreads across three groups, and each owns different evidence:

Engineering documents system purpose, data flows, model versions, evaluation methods, test results and production monitoring, and records how metrics are chosen.
Legal reviews contract terms with customers and suppliers, including content ownership, usage rights, quality standards, security requirements and provenance expectations, which the Generative AI Profile action GV-6.1-004 suggests specifying in contracts and service level agreements.
Security reviews third-party software and data, requests software bills of materials, and maintains incident handling and vulnerability processes for AI components.

The framework also expects accountable roles and documented decisions, so product and risk owners must sign off on go or no-go determinations and residual risks.

Is the NIST AI RMF required by law?

No. NIST states that neither private nor public sector organizations are required to use the AI RMF, and AI 100-1 describes it as intended for voluntary use. Some state laws do name the framework or its Generative AI Profile, however, and where a law does, using it may matter for compliance or for a safe harbor. Whether a specific law applies to you depends on where you operate, what your system does and whether you are a developer or deployer. Confirm the applicable state laws with counsel, and note that NIST plans to revise AI RMF 1.0, which may affect laws that cite the latest version.

How should we disclose residual AI risk to customers and acquirers?

The framework calls for documenting negative residual risks, defined as the sum of all unmitigated risks, and communicating them to downstream acquirers of AI systems and to end users. In practice, this means keeping a register of risks you have accepted or not mitigated, with the reason, the affected users and the monitoring that applies. Buyers and acquirers usually want this in a form they can review during diligence, so align the register with your customer-facing documentation. AI 100-1 also notes that developers and deployers may use different risk metrics and that a developer may not be transparent about its own, so state clearly which parts of the risk picture you can and cannot see.

How do we choose an implementation partner?

Start by asking what the partner will own and what it will not. A reputable partner prepares systems, controls and evidence, and does not issue reports or certificates, since no AI RMF certificate exists and only the organization owns its controls. Ask for a written, fixed scope with deliverables, timelines and the evidence each deliverable produces. Check whether the partner can map to the Playbook, the Generative AI Profile and your existing common control framework, and how it handles model testing and third-party AI risk. Request references you can verify, and ask how ongoing monitoring and updates are handled after the AI RMF revision is published.

How DeployOpen prepares AI risk evidence for vendor reviews

DeployOpen helps AI vendors and SaaS providers turn their NIST AI RMF practices into evidence that enterprise customers can review. We prepare systems, controls and documentation inside the client's own infrastructure, while the organization owns its controls and any report or attestation comes from an independent assessor.

How we scope

Engagements are fixed-scope, with the AI systems, customer-facing questionnaires and framework areas agreed in writing before work starts.
The written scope names which AI RMF categories and subcategories the work covers and which Generative AI Profile actions apply to your products.
Scope also records which third-party models, data and components sit inside each reviewed system, so supply chain evidence is defined up front.
Ask for the scope to state who owns each control, who reviews the evidence and what the customer-facing deliverables are.

How we build

We map your existing common controls and policies to AI RMF categories, identifying what already corresponds and where gaps need work.
We help draft or refine responsible AI guidelines, product risk evaluations and third-party AI questionnaire answers against the framework.
Testing of AI systems, APIs and agents can be run as part of the work, with findings documented against the subcategories they affect.
Platform work runs inside your own cloud accounts, data centers or air-gapped networks, using self-hosted open-source tooling where it fits.

How we hand over

Deliverables include the mapped control inventory, risk documentation, evidence packages and the procurement answers agreed in scope.
Residual risk documentation is prepared for downstream acquirers and end users, covering the negative residual risks that remain after mitigation.
Contract-facing material, such as SLA and security requirement language, is documented so your legal team can review and negotiate it.
Everything is handed over in your environment so your team can maintain it, and we confirm which artifacts an independent assessor will need.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope work is complete.
Retainers can keep evidence current as models change, new customers ask new questions, or the framework and its Playbook are revised.
We do not issue attestations or certifications. Confirm with your customers and any independent assessor which reports they will accept.
Before you rely on any AI RMF claim in a sales or procurement context, confirm its wording with your legal and compliance advisers.