From Sidhant Tamrkar | Product & Market Analysis
An AI Security Questionnaire RFP Template, Mapped to the NIST AI RMF
On this page
Most AI security questionnaires are SaaS questionnaires with a few AI questions added at the end. This post replaces that with 24 RFP questions, each tied to a named NIST AI RMF subcategory and each paired with the evidence a vendor should be able to hand over. The AI security questionnaire below is built to be pasted into an RFP.
Short answer
A good AI security questionnaire asks about 4 things the SaaS form skips: who supplies the model, what was tested against attack, how failures are escalated, and when the system gets switched off. Group them under the NIST AI RMF functions Govern, Map, Measure and Manage, and make every question name the artifact that proves the answer.
Key takeaways
- The template has 24 questions across the 4 NIST AI RMF functions. Govern carries 7, Map 5, Measure 6 and Manage 6, and each question cites a framework subcategory or a Generative AI Profile action ID.
- Third-party supply is where SaaS questionnaires fail AI vendors. A public index of NIST's Generative AI Profile lists 19 actions under GOVERN 6 alone, covering contracts, inventories, fallback plans and incident response for third-party models.
- Ask for an artifact, never an assurance. Each question names evidence such as a dated red-team summary or a subprocessor list that names the model provider, because NIST labels its own actions as suggestions and not proof of conformance.
- NIST's own action counts disagree between sources, so cite IDs and verify them. NIST's AI Resource Center says more than 400 actions, while a public index of the Profile lists 261 requirements.
Why a SaaS questionnaire misses AI vendors
The standard security questionnaire was designed for a bounded application. It asks where data is stored, who can access it, how it is encrypted and whether the vendor holds a SOC 2 report. Those remain good questions. They are no longer sufficient.
An AI feature changes the shape of the product. Your content often travels to a model provider you never contracted with. The model can produce output that leaks, misleads or takes action. And the vendor's behaviour can change overnight when the model underneath it is swapped.
One vendor-authored guide argues that SIG, CAIQ and in-house forms treat a product as a bounded application, and that AI products break this by sending data to model providers and inference infrastructure. The author sells security software, so treat that as Tier 3 and directional. I agree with the direction of the argument and would not rely on its detail.
The AI RMF 1.0, released on 26 January 2023, is voluntary guidance organised into 4 functions. Govern is cross-cutting. Map sets context. Measure analyses and tracks risk. Manage treats it and responds. The Generative AI Profile, AI 600-1, followed on 26 July 2024 and adds suggested actions specific to generative systems.
| Standard question | AI-aware replacement | Why it matters |
|---|---|---|
| List your subprocessors. | List every third party that processes customer content, including the model provider and its hosting. Date the list. | The standard version stops at cloud hosting. |
| Is data encrypted at rest and in transit? | State whether customer content trains or fine-tunes any model, per data class, and quote the opt-out clause. | Encryption does not answer the training question. |
| Do you run annual penetration tests? | Provide a dated summary of AI red-team testing, covering prompt injection and training-data extraction. | A penetration test targets infrastructure, not model behaviour. |
| Do you have an incident response plan? | Does the plan cover failure or compromise of your third-party model, and when was it last tested? | The plan may not mention the model at all. |
| Do you hold a SOC 2 Type II report? | Keep this question unchanged. | Where the old form wins: it is still the cheapest signal of baseline control hygiene. |
How the template works
Every question in the template has three parts: the question itself, the NIST source it traces to, and the evidence a vendor should be able to produce. If a vendor cannot produce the evidence, the answer to the question is "no", whatever the prose says.
Sources come in two kinds. A subcategory such as MEASURE 2.7 comes from the AI RMF Core. An action ID such as MS-2.7-007 comes from the Generative AI Profile, where the prefix names the function: GV for Govern, MP for Map, MS for Measure and MG for Manage.
NIST is clear that these are optional. Its Playbook entries are suggestions that do not by themselves establish conformance. That is why the template converts each one into a request for evidence. A vendor saying it follows the framework tells you nothing. A vendor producing a dated artifact tells you something.
Use all 24 for any vendor that sees confidential content or can act on your systems, and the Govern and Map questions alone for the rest.
| Function | Questions | Main NIST sources | What it catches |
|---|---|---|---|
| Govern | 7 | GOVERN 1.2, 4.3, 6.1, 6.2 | Missing policy, hidden model providers, weak contracts |
| Map | 5 | MAP 1.1, 4.1, 4.2, 5.1 | Unknown components, unstated training data use |
| Measure | 6 | MEASURE 2.5, 2.7, 2.10, 3.1 | Untested claims, stale security evidence |
| Manage | 6 | MANAGE 2.3, 2.4, 3.1, 3.2, 4.3 | No kill switch, silent model changes, quiet incidents |
Govern: 7 questions on policy, contracts and third parties
Govern is the cross-cutting function. In NIST's framing it covers the policies, accountability and culture that make the other three functions possible. For a vendor review that reduces to three things: written policy, control over third parties, and a path for incidents.
G1. Do your written AI risk policies cover the third-party models you embed, as well as models you train?
NIST source: GOVERN 1.2, whose Playbook actions include verifying that formal AI risk policies cover deployed and third-party AI systems. Evidence: the policy document, with owner and revision date.
G2. Describe the due diligence you perform before adopting a new generative AI vendor or model.
NIST source: GOVERN 6.1, action GV-6.1-009, on updating due diligence for generative AI acquisition and procurement. Evidence: the procedure and the checklist from the last model onboarded.
G3. Do you assess suppliers with a framework tied to the specific use case, and when did you last assess your model provider?
NIST source: GOVERN 6.1, action GV-6.1-005, a use-case-based supplier risk assessment framework. Evidence: the most recent assessment of the model provider, redacted as needed.
G4. Which third parties can access customer content, and which generative AI providers are approved for it?
NIST source: GOVERN 6.1, action GV-6.1-007, on inventorying third parties with access to organisational content and keeping an approved list. Evidence: a dated subprocessor list that names the foundation model provider and its hosting.
G5. Which contract clauses let us evaluate your third-party model processes, and what service levels do you commit to?
NIST source: GOVERN 6.1, actions GV-6.1-004 on contracts and service level agreements and GV-6.1-006 on evaluation clauses. Evidence: the clause text from your standard agreement. See the companion piece on data processing agreement clauses for AI for wording.
G6. What happens to our service if your model provider fails, changes terms or ends access?
NIST source: GOVERN 6.2, whose actions include incident response plans for third-party systems (GV-6.2-003), rollover and fallback testing (GV-6.2-006) and avoiding arbitrary termination of critical technologies (GV-6.2-007). Evidence: the fallback plan and the date of the last failover test.
G7. How do you record AI incidents and share what you learn with customers and peers?
NIST source: GOVERN 4.3, covering policies for reporting and documenting incident response, plus GV-4.3-003 on feedback and information sharing. Evidence: the incident reporting policy and an anonymised incident register summary.
What a good Govern answer looks like
Look for documents with dates and owners. A policy with no revision date was probably written for your questionnaire. A subprocessor list that omits the model provider is the exact gap this template was built to catch, and I would treat it as disqualifying until it is fixed.
Map: 5 questions on inventory, context and training data
Map establishes context. It asks what the system is for, what it is built from and what could go wrong. In a procurement setting, Map questions force the vendor to write down components it may prefer to leave vague.
M1. What is the intended purpose of the feature, and what uses do you prohibit?
NIST source: MAP 1.1, on documenting intended purpose, context and prospective settings. Evidence: an intended-use statement and the acceptable use policy that backs it.
M2. Provide an inventory of the foundation models, open-source components and datasets the feature depends on.
NIST source: MAP 4.1, where the Playbook suggests inventorying third-party hardware, open-source software, foundation models and data. Evidence: a bill of materials for the AI feature. The post on the AI bill of materials disclosure template shows a workable format.
M3. Is customer content used to train, fine-tune or evaluate any model, and what are your data retention and quality rules?
NIST source: MAP 4.1, actions MP-4.1-004 on documenting training data curation, MP-4.1-005 on collection and retention policy, and MP-4.1-010 on diligence on training data use. Evidence: a training data statement and the contractual opt-out. For retention comparisons, see how AI vendors rank on data retention.
M4. How do you review risk when a model you depend on is updated, or when you fine-tune on top of it?
NIST source: MAP 4.2, which suggests applying traditional procurement, security and privacy controls to acquired third-party technology, with MP-4.1-007 on re-evaluating fine-tuned models. Evidence: the change review procedure and the record of the last model update.
M5. Which harms to users and customers have you identified, and how did you score their likelihood and magnitude?
NIST source: MAP 5.1, on documenting likelihood and magnitude of each impact, with scales applied uniformly. Evidence: the impact register or risk assessment, with scoring scale and date.
What a good Map answer looks like
A good vendor can name its model provider in one sentence. A good vendor can also say what happens to your data after the response is generated.
Measure: 6 questions that demand test evidence
Measure is where claims meet evidence. The function covers how a vendor tests, benchmarks and monitors its system. These are the questions most likely to produce an empty folder, which is itself a useful finding.
S1. Provide a summary of your most recent AI red-team exercise: scope, date, and the findings that were closed.
NIST source: MEASURE 2.7, with MS-2.7-007 on red-teaming for abuse and the Playbook suggestion to use red-teaming to find mismatches between claimed and actual performance. Evidence: a dated report summary. The guide to running a red-teaming programme for agents describes what a credible one covers.
S2. Which security metrics do you track for the AI system, and what were they over the last four quarters?
NIST source: MEASURE 2.7, whose Playbook example metrics include red-teaming activity, rate of anomalous events, downtime, incident response times and time-to-bypass, plus MS-2.7-006 on how quickly security recommendations are implemented. Evidence: a metrics extract covering 4 quarters.
S3. After you last fine-tuned or changed the model, how did you verify that safety and security controls still hold?
NIST source: MEASURE 2.7, actions MS-2.7-008 on verifying that fine-tuning does not compromise controls and MS-2.7-009 on regularly confirming security measures remain effective. Evidence: regression test results from the last change.
S4. How do you test whether the model can output training data or personal information, and what were the results?
NIST source: MEASURE 2.10, with MS-2.10-001 on red-teaming for outputting training data samples and MS-2.10-003 on deduplicating training data. Evidence: test results and the privacy assessment for the feature.
S5. Under what conditions was the system validated, and what do you log when it is used outside them?
NIST source: MEASURE 2.5, whose Playbook actions include defining validation conditions and logging input and configuration whenever the system is used beyond its well-defined range. Evidence: the validation report with its stated limits, and a sample log entry. The audit log specification sets out useful fields.
S6. How do you compare customer feedback with your internal performance measures to find emerging risks?
NIST source: MEASURE 3.1, on tracking existing, unanticipated and emergent risks, including comparing end-user feedback with internal measures. Evidence: the review cadence and one monitoring report with a decision recorded.
What a good Measure answer looks like
Ask for the date on every test. Security evidence goes stale as models change. A red-team report from before the last model swap says little about the system you would be buying. The Profile's action on fine-tuning exists for exactly this reason.
Manage: 6 questions on incidents, switching off and model change
Manage covers what happens after something goes wrong, or before the vendor changes something under you.
N1. Who can switch the AI feature off for us, how fast, and on what criteria?
NIST source: MANAGE 2.4, with MG-2.4-004 on criteria that warrant deactivation. The Playbook suggests protocols and metrics for decisions to supersede, bypass or deactivate a system. Evidence: the runbook, with a named role and a time target.
N2. How are AI incidents escalated to your risk owners, and how are the underlying issues remediated?
NIST source: MANAGE 2.4, actions MG-2.4-002 on escalation procedures and MG-2.4-003 on remediation of issues that trigger incident response. Evidence: the escalation matrix and one worked example.
N3. How do you respond to a risk nobody had identified before, and how often are your response plans reviewed?
NIST source: MANAGE 2.3, covering procedures to respond to and recover from previously unknown risks, with regular review of treatment and response plans. Evidence: the plan and the date of its last review.
N4. How do you monitor your third-party AI systems for negative impacts, and how often?
NIST source: MANAGE 3.1, on regularly monitoring third-party AI resources and applying risk controls, with GV-6.2-004 on continuous monitoring policy. Evidence: a monitoring schedule and the output of the last review.
N5. How are pre-trained models tracked, and how much notice do you give us before a model is replaced?
NIST source: MANAGE 3.2, on monitoring pre-trained models as part of regular maintenance and decommissioning those that exceed risk tolerances. Evidence: a model change log and the contractual notice period. The agent procurement checklist covers the commercial side.
N6. How and when do you tell customers about incidents, and how do you handle deletion and rectification requests in your data?
NIST source: MANAGE 4.3, on communicating incidents to affected parties and keeping a database of errors and near-misses, with MG-4.1-006 on tracking dataset modifications such as deletions. Evidence: the notification commitment in hours, an anonymised incident log and the deletion procedure.
What a good Manage answer looks like
The test for N1 is simple. Ask the vendor to switch off the feature in a sandbox tenant while you watch. A vendor with a real kill switch will say yes. A vendor with a plan to build one will explain why a demonstration is not possible.
Where this template is weakest
A template like this is easy to oversell. Here is where it fails.
A questionnaire is a claim collector
Every answer is still the vendor's statement about itself. Asking for evidence narrows the gap, but a dated document can be accurate about something narrower than the question. A red-team summary can be real and cover only one of five features.
NIST alignment is not a certification
The framework is voluntary and there is no audit that confers it. A vendor saying it is "aligned with the NIST AI RMF" has said something close to nothing, and I would not give any score for that sentence alone. Standards that do offer a certification route, such as those discussed in the post on ISO 42001 readiness, carry more weight on that dimension. The template complements them and does not replace them.
The sources are partly secondary
This is the part of the argument I am least comfortable with. The AI RMF 1.0 and the Generative AI Profile PDFs could not be read as text during research for this post. The subcategory wording for the AI RMF Core comes from a public mirror of the Playbook, and the Profile action IDs come from a third-party index that truncates each action after about 100 characters. The IDs and short descriptions are used here as pointers. Check each against AI 600-1 before you send the template.
NIST's own pages also disagree with each other. The AI Resource Center says the Profile centres on 13 risks and more than 400 actions, while public guides describe 12 risks and a public index lists 261 requirements. I could not reconcile these, so this post does not rest any claim on a risk count.
The case against a long questionnaire
Many procurement teams will say 24 questions is too many, and for low-risk vendors they are right. The counter is risk-based routing: send the short set to most vendors and the full set only to those who touch confidential content.
Scoring the answers
A template without a scoring rule produces a folder of PDFs and no decision.
| Score | What the vendor supplied | How to read it |
|---|---|---|
| 3 | A dated artifact that matches the question and names its scope | Verified claim. Record the date and expire it after 12 months. |
| 2 | A real artifact that covers part of the question | Partial. Ask a follow-up and note the gap in the file. |
| 1 | A written answer with no artifact | Unverified claim. Treat as a contract term to negotiate. |
| 0 | No answer, a refusal or a reference to marketing material | Treat as a finding, not a neutral result. |
Rules I would hold to
A blank answer scores 0, never neutral. I would also end an evaluation if a vendor refuses to name its model provider, since every other answer depends on knowing who that is. And I would not average scores across functions. A 3 on Measure does not offset a 0 on Govern 6, because the third-party gap is the one you cannot fix after signature.
Set a pass line per function, not one for the total. For a vendor handling confidential content, I would require no score of 0 on G4, G6, M3 or N1. Those four cover who sees your data, what happens if the provider fails, whether you are training someone's model, and whether you can stop the feature.
Frequently asked questions
What is the NIST AI RMF?
The NIST AI Risk Management Framework, AI 100-1, is voluntary guidance released on 26 January 2023. It organises AI risk work into 4 functions: Govern, Map, Measure and Manage. It carries no certification and no enforcement mechanism. Organisations use it as a shared structure for policies, testing and incident handling, and buyers use it to structure vendor questions.
What is NIST AI 600-1?
NIST AI 600-1 is the Generative AI Profile of the AI RMF, released on 26 July 2024. It names risks specific to or worsened by generative AI and attaches suggested actions to the four functions. Each action has an ID such as GV-6.1-005. Not every subcategory of the framework is covered, and the actions are suggestions.
How many questions should an AI security questionnaire have?
Use about 10 for low-risk vendors and all 24 for vendors that see confidential content or can act on your systems. Length matters less than evidence. A 10-question form that demands dated artifacts will teach you more than a 100-question form answered from a template. Route by risk instead of sending one form to everyone.
Does NIST AI RMF alignment replace SOC 2 or ISO 42001?
No. SOC 2 gives an independent opinion on general control operation, and ISO 42001 offers a certifiable management system for AI. The NIST framework is a voluntary structure with no certification route. Keep your SOC 2 question and add the AI-specific questions from this template on top. Treat NIST alignment as the vocabulary, not the proof.
What evidence should an AI vendor provide in an RFP?
Ask for dated artifacts: a subprocessor list that names the model provider, the contract clauses on training and retention, a red-team summary with scope, a metrics extract, a model change log, an escalation matrix and an anonymised incident register. Each should carry an owner and a date. Evidence older than 12 months, or from before the last model change, should score lower.
Where to start this week
Pick the one AI vendor that sees your most sensitive content. Send it only the 8 questions you think matter most: G4, G6, M3, N1 and any four from the Measure set. Score what comes back with the rubric above and note which answers needed a follow-up.
Then open the NIST publication and check the five action IDs you rely on against the source text. If one is wrong or reworded, correct the template before it goes into a live RFP.
Related checklists
Pair this template with the post on SOC 2 evidence for AI systems and the agent procurement checklist.
References
- NIST, AI Risk Management Framework, read 13 October 2026. Used for the release dates of AI RMF 1.0 (26 January 2023) and AI 600-1 (26 July 2024).
- NIST AI Resource Center, Technical Reports, read 13 October 2026. Used for the "13 risks and more than 400 actions" statement.
- NIST, AI 600-1, Generative AI Profile, July 2024. Primary source for action IDs. Not machine-readable in this research session; see the note below.
- NIST, AI 100-1, Artificial Intelligence Risk Management Framework 1.0, January 2023. Primary source for the Core.
- NIST AI Resource Center, AI RMF Playbook, Govern, read 13 October 2026. Used for GOVERN 1.2 wording.
- StigViewer, AI RMF controls, MEASURE 2.7 and related pages, read 13 October 2026. Third-party mirror of Playbook text. Used for subcategory statements and Playbook actions.
- myctrl.tools, NIST AI 600-1 index, read 13 October 2026. Third-party mirror, truncated text. Used for action IDs and the 261 and 19 counts.
- Reco, AI vendor security questionnaire, read 13 October 2026. Vendor-authored, Tier 3. Used only to illustrate the claim that standard forms assume a bounded application.
The weakest part of this source base: the Core and Profile wording reaches this post through two third-party mirrors, because the NIST PDFs could not be read as text. Verify every action ID against the PDF before use. Figures reflect sources as read on 13 October 2026.
Related reading