AI Vendor Risk Assessment: A Due Diligence Questionnaire

An AI vendor risk assessment answers one question your existing security questionnaire was never designed to ask: what happens to your data, your customers and your compliance obligations once a third party's AI model sits in the middle of a business process. The short answer is that you tier the vendor first, send a questionnaire sized to that tier, score the answers against evidence rather than assurances, and then write the answers into the contract so they stay true after signing.

This guide gives you all four pieces. It maps what bank, insurance and healthcare regulators actually expect from third-party AI oversight as of October 2026, including a September 2026 federal proposal that would rewrite bank third-party guidance. It includes a five-factor tiering matrix, a 42-question AI vendor due diligence questionnaire with the evidence to request and the red flags to watch for, a scoring rubric, and the contract terms that make the answers enforceable.

It is written for the people who sign off on these decisions at small and mid-sized regulated companies: CIOs, CISOs, compliance officers, vendor managers and COOs. It is a practitioner's guide, not legal advice; confirm the specifics for your institution with counsel and your compliance team.

Why an AI vendor risk assessment is different from a normal vendor review

Most third-party questionnaires were built for software that does the same thing every time. They ask about encryption, access management, backups, SOC 2 reports and breach history. Those questions still matter, but AI products add risks that a standard review does not reach.

• Your data may become someone else's training data. The question is no longer only "who can see our data" but "does our data change the product other customers receive."
• There is usually a vendor behind the vendor. Many AI products are built on a foundation model from a separate provider, often hosted by a third company. Each one may process your data under its own terms.
• The product changes without a release note you would notice. A model upgrade can change accuracy, tone, refusal behavior and bias characteristics overnight, while the contract and the user interface look identical.
• Outputs can be wrong in a confident voice. A traditional system either works or throws an error. A generative system can produce a fluent, plausible and incorrect answer that flows into a customer letter, a claim note or a care plan.
• Some products now act, not just answer. Agentic features read your systems, call APIs and take steps on their own, which turns a data-protection question into an authority question.

The breach data supports treating this as a priority rather than a paperwork exercise. Verizon's 2025 Data Breach Investigations Report, based on 12,195 confirmed breaches, found that third-party involvement in breaches doubled to 30%. IBM's 2025 Cost of a Data Breach study of 600 breached organizations found that 13% reported breaches of AI models or applications, that 97% of those reported not having AI access controls in place, and that 63% of breached organizations either had no AI governance policy or were still developing one.

Regulated buyers are also heavily dependent on vendor AI. The NAIC's survey of 93 health insurers across 16 states found that 55% use third-party components in their AI/ML systems and 15% rely entirely on third-party AI/ML solutions. Asked whether their third-party contracts include conditions that would limit disclosure or transparency to regulators, 11 companies (13%) said yes.

Key takeaway: An AI vendor risk assessment is not a longer security questionnaire. It adds four topics security reviews skip: data reuse, the model supply chain, output quality over time, and the authority the system has to act.

What regulators expect from third-party AI risk management

No federal regulator has issued a rule that applies only to AI vendors. The expectations come from existing third-party, model risk, cybersecurity and privacy frameworks, which all apply to AI products the same way they apply to any outsourced activity. The table summarizes where each sector's expectations come from.

Banks and credit unions

The 2023 interagency guidance from the Federal Reserve, FDIC and OCC remains the operative text as of October 2026. Its core sentence applies directly to AI purchases: "A banking organization's use of third parties does not diminish its responsibility to meet these requirements to the same extent as if its activities were performed by the banking organization in-house." It lists 14 due diligence factors, from strategies and goals to reliance on subcontractors and insurance coverage, and 17 contract considerations, from the right to audit to regulatory supervision.

On September 15, 2026, the OCC, Federal Reserve and FDIC, joined by the NCUA (which was not a party to the 2023 guidance), published proposed replacement guidance in the Federal Register. The agencies say the 2023 guidance "frequently has been interpreted in an overly broad manner" and propose four components instead: identify and assess risks, oversee them in proportion to their significance, make informed decisions about residual risk, and establish governance. Risk is framed as the magnitude of harm and the likelihood it occurs. The proposal states that "there are no generally applicable expected contract terms for third-party relationships--even for higher-risk relationships." It would also retire the 2024 community bank guide. Comments close November 16, 2026, and nothing changes until the agencies finalize it.

Two points matter for AI buyers. The proposal does not mention artificial intelligence at all, so AI vendors are simply third parties assessed on their risk. And it keeps the hard edge: where a vendor "is unable or unwilling to provide information or other cooperation reasonably necessary" for due diligence and monitoring, alternative information sources may not be enough to stay within your risk appetite. A lighter process is not a license to accept silence from a vendor that touches customer data.

Model risk guidance points the same way. SR 26-2, which replaced SR 11-7 in April 2026, gives vendor products their own section: proprietary components may mean a bank does not receive the vendor's code, data or methodology, but "the principles of model risk management remain applicable," and sound practice includes understanding the vendor model's conceptual soundness, design, development data and performance. Its footnote 3 places generative and agentic AI outside the guidance and hands them back to the bank's own governance. Our SR 26-2 explainer covers what that carve-out does and does not mean.

New York adds a cybersecurity layer. The NYDFS industry letter of October 16, 2024 imposes no new requirements beyond 23 NYCRR Part 500, but it calls third-party service provider policies one of the most important requirements for combating AI-related risks. It says covered entities should require providers to give timely notice of cybersecurity events, "including threats related to AI," and should consider additional representations and warranties on the secure use of nonpublic information when providers use AI.

Insurers

Section 4.0 of the NAIC Model Bulletin, adopted December 4, 2023, is the most specific vendor language any US regulator has published on AI. It asks insurers to perform due diligence that ensures decisions made or supported by third-party AI systems "will meet the legal standards imposed on the Insurer itself," and, where appropriate and available, to include contract terms that provide audit rights or audit reports and that require the vendor to cooperate with regulatory inquiries about the insurer's use of the product. In an examination, the bulletin says insurers should expect requests for the due diligence, the vendor contracts (including representations, warranties, data security and privacy, data sourcing and cooperation terms), any audits performed, and validation and drift-testing documentation. Our NAIC bulletin checklist walks through the full program.

Healthcare organizations

If an AI vendor creates, receives, maintains or transmits protected health information on your behalf, HIPAA requires a business associate agreement. Under 45 CFR 164.504(e), that contract may not authorize the vendor to use or disclose PHI in a way that would violate the Privacy Rule if you did it yourself, must require subcontractors to agree to the same restrictions, must make the vendor's books and records available to HHS, and must provide for return or destruction of PHI at termination where feasible. For AI products that means the model provider underneath your vendor needs to be covered too.

Separately, 45 CFR 92.210 gives covered entities "an ongoing duty to make reasonable efforts to identify" patient care decision support tools that use race, color, national origin, sex, age or disability as inputs, and to make reasonable efforts to mitigate the resulting discrimination risk. Buying the tool does not move that duty to the vendor, so your questionnaire needs to ask what the inputs are. Our HIPAA-compliant AI development checklist covers the rest of the healthcare control set.

Step 1: Tier the AI vendor before you send a questionnaire

Sending every vendor the full questionnaire wastes everyone's time and teaches business teams to route around you. Both the current and the proposed bank guidance tie the depth of due diligence to the level of risk, and FS-ISAC's Generative AI Vendor Risk Assessment Guide uses the same logic: it scores five domains (use case, business integration, confidential data, business resiliency and potential for exposure) and recommends one of three due diligence levels based on the highest risk level selected in any domain.

The matrix below adapts that idea into five factors you can score in a 20-minute intake call with the business owner.

A few calibration notes from applying it:

• Data is usually the deciding row. An AI writing assistant that only sees marketing copy is Tier 1. The same assistant rolled out to loan officers who paste in borrower files is Tier 3, even though it is the same product.
• "A person reviews it" is weaker than it sounds. If reviewers approve hundreds of AI outputs a day, the human check is real only if you can show they catch errors. Score decision impact on what reaches the customer, not on the org chart.
• Autonomy and integration often arrive later. Many vendors add agent features to existing products. A Tier 2 vendor that ships "auto-resolve" for support tickets has just become a Tier 3 vendor.
• Exit difficulty is the factor teams forget. If the vendor holds your fine-tuned model, your vector index or years of conversation history in a proprietary format, you need exit terms before you need them.

The AI vendor due diligence questionnaire (42 questions)

The questionnaire is grouped into seven sections. Tier 1 vendors answer sections A and B. Tier 2 and Tier 3 vendors answer all seven, with Tier 3 vendors providing evidence for every answer. Each section lists what to ask, the evidence that makes an answer credible, and the answers that should stop or slow the deal. The structure overlaps with the seven categories in the FS-ISAC workbook and with NIST's guidance, so you can map it to either.

Section A: AI use and the model supply chain

1. Which features of the product use AI or machine learning, and which are generative or agentic?
2. Which foundation models power each feature, and who provides them?
3. Where are those models hosted, and by whom?
4. Can the vendor switch the underlying model or model provider without notifying you?
5. Which subprocessors receive your data because of AI features, and in which countries?
6. Can AI features be turned off per user, per workspace or per data type?

Evidence to request: an AI feature inventory, the subprocessor list with AI providers identified, architecture or data-flow diagrams.

Red flags: "we use proprietary AI" with no named model or provider; subprocessor lists that omit the model provider; no ability to disable AI features.

Hosting arrangements matter more than vendors admit. Microsoft's own documentation for models sold through Azure, for example, says "Global" deployments may process prompts and responses in any geography where the model is deployed, and describes abuse monitoring in which flagged prompts and completions can be reviewed by authorized Microsoft employees unless the customer is approved for modified abuse monitoring. Your vendor's configuration choices at that layer become your data residency and confidentiality posture.

Section B: Data use, retention and training

7. Is any of our data (prompts, files, outputs, feedback, metadata) used to train, fine-tune or improve any model? Is that the default, and how is it disabled?
8. How long are prompts, outputs and logs retained by the vendor and by each model provider, and for what purposes?
9. Who at the vendor or its providers can view our prompts and outputs, and under what conditions (support, abuse monitoring, quality review)?
10. Is our data logically or physically separated from other customers' data, including in vector databases and caches?
11. How is our data deleted at termination, including from backups, indexes and fine-tuned models, and will you certify deletion?
12. Are de-identified or aggregated versions of our data used for any purpose, including benchmarking?
13. Where is our data stored and processed, and can we restrict it to the United States?

Evidence to request: the data processing addendum, the AI-specific terms of service, provider-level retention settings, and a deletion certificate template.

Red flags: opt-out (rather than opt-in) training on customer data; retention described as "as long as necessary"; no answer on provider-level human review; fine-tuned models that cannot be deleted.

Section C: Security, access and agent permissions

14. Provide your most recent SOC 2 Type II report or ISO/IEC 27001 certificate, and state whether AI components are within its scope.
15. How do you test for and mitigate prompt injection, including instructions hidden in documents, emails or web pages the system reads?
16. What permissions does the AI system hold in our environment, and are they scoped to the minimum needed per user?
17. For agentic features, which actions can the system take without human approval, and can we configure approval gates?
18. Are AI interactions logged with user, timestamp, inputs, outputs, model version and actions taken, and can we export those logs?
19. How do you notify us of security incidents, including AI-specific ones such as model compromise or data leakage through outputs, and within what time?
20. Have you commissioned adversarial testing (red teaming) of the AI features, and can we see a summary?

Evidence to request: the SOC 2 report with its scope section, a penetration or red-team test summary, a sample log export, and the incident response policy.

Red flags: AI features carved out of the SOC 2 scope; agents that run under a shared service account with broad permissions; no exportable logs.

Logging deserves its own conversation, because it is how you will reconstruct a disputed decision later. Our guide to AI audit trail requirements lists the fields regulators tend to ask for.

Section D: Performance, testing and change management

21. How do you measure accuracy for our use case, on what test data, and with what results?
22. How are hallucinations or unsupported answers measured and limited, for example by grounding answers in cited sources?
23. How do you monitor for drift or degradation after release?
24. How much notice do you give before changing the model, prompts or retrieval logic, and can we test before the change reaches production?
25. Can we pin a model version, and for how long?
26. What are the documented limitations and out-of-scope uses of the product?

Evidence to request: model or system cards, evaluation reports on data similar to yours, release notes, and the change notification policy.

Red flags: accuracy claims with no test set described; silent model upgrades; no limitations documentation.

SR 26-2's language fits here even for non-bank buyers: sound practice involves ongoing monitoring and outcome analysis to assess whether vendor models "are accurate, remain fit for purpose, and continue to be reliable." You cannot do that without notice of changes.

Section E: Fairness and consumer impact

27. Does the system make or support decisions about individuals (credit, coverage, claims, pricing, employment, care)?
28. What input variables does it use, and do any measure or proxy for protected characteristics?
29. What bias or disparate impact testing have you performed, by which method, and how often?
30. Can the system produce reasons or explanations sufficient for adverse action notices or consumer inquiries?
31. Will you support our own outcome testing with the data and access we need?

Evidence to request: bias testing methodology and results, the variable list or feature documentation, and sample explanations.

Red flags: "our model does not use protected attributes, so it cannot be biased"; refusal to support customer-side testing; no explanation capability for a decisioning use case.

This section is where the NAIC bulletin's "legal standards imposed on the Insurer itself" and the Section 1557 duty to identify sensitive input variables come in. Skip it only for Tier 1 vendors with no individual-level decisions.

Section F: Governance and accountability

32. Who at your company is accountable for AI risk, and to whom do they report?
33. Do you follow a recognized AI risk or management framework, such as the NIST AI Risk Management Framework or ISO/IEC 42001, and is any certification independently audited?
34. How do you assess and monitor your own AI providers (your nth parties)?
35. Will you cooperate with our regulators' inquiries about our use of your product, including producing documentation?
36. What insurance do you carry that would respond to losses from AI errors, data incidents or intellectual property claims?
37. Have you had regulatory actions, lawsuits or material complaints related to your AI features?

Evidence to request: the governance policy, framework mapping or certificate, provider due diligence summaries, and certificates of insurance.

Red flags: no named owner for AI risk; contract terms that limit disclosure to regulators; insurance that excludes the exposures you care about.

ISO/IEC 42001:2023 specifies requirements for an AI management system: the policies, objectives and processes an organization uses for the responsible development, provision or use of AI. A certificate is useful evidence that a vendor runs a governance process. It is not evidence that a specific product is accurate or fair for your use.

Section G: Resilience and exit

38. What happens to our service if your model provider has an outage or terminates your access?
39. Do you have a fallback model or a manual mode, and has it been tested?
40. What are your uptime and support commitments for AI features specifically?
41. In what format can we export our data, configurations, prompts, fine-tuning data and logs?
42. What transition support do you provide at termination, and for how long?

Evidence to request: the business continuity plan, the service level agreement, and a sample export.

Red flags: single-provider dependency with no fallback; AI features excluded from the SLA; proprietary export formats.

NIST's Generative AI Profile (NIST AI 600-1, July 2024) covers this ground under GOVERN 6.2, suggesting organizations document over-reliance on third-party data and identify fallbacks, and test rollover and fallback technologies, "acknowledging that rollover and fallback may include manual processing."

How to score an AI vendor's answers

FS-ISAC's guide is candid that its questionnaire responses "do not yield a risk rating," and leaves rating to each institution. That is the right call, but it leaves most teams without a method. A simple rubric keeps reviewers consistent.

Then apply three rules:

1. Mark must-have questions. For a Tier 3 vendor, questions 7, 8, 11, 16, 17, 24, 35 and 41 might be must-haves. A score below 2 on any must-have blocks approval, regardless of the total.
2. Average the rest by section. A section averaging below 1.5 needs a remediation plan or a compensating control before go-live.
3. Record the decision, not just the score. Use four outcomes: approve, approve with conditions, approve for a limited pilot with restricted data, or decline. Write down who decided and why.

The 2023 interagency guidance says banks should "identify and document any limitations" of due diligence, understand the resulting risks and consider alternatives. The scoring sheet is where that documentation lives.

Contract terms that make the answers enforceable

A vendor's questionnaire answers describe today's product. The contract decides whether those answers still hold after the next model upgrade. The table maps the clauses that matter most for AI purchases to the sources that mention them.

If the September 2026 proposal is finalized, banks will no longer face examiner expectations about specific contract terms. That does not make the terms less useful. It makes them your choice, sized to the risk. The proposal itself notes that institutions with limited negotiating power can focus on "a narrow subset of contractual provisions" most relevant to the relationship, and may gain leverage by negotiating as a group. For an AI vendor touching customer data, the first three rows of the table are that narrow subset.

Key takeaway: Questionnaire answers expire. Contract terms do not. Every must-have answer should map to a clause, or to a documented reason why you accepted the risk without one.

Ongoing monitoring: AI vendors change faster than annual reviews

Traditional vendor reviews run on an annual calendar. AI products change on a weekly one. NIST's AI RMF addresses this directly in MANAGE 3.1, "AI risks and benefits from third-party resources are regularly monitored," and MANAGE 3.2, which calls for pre-trained models used in development to be monitored as part of regular system monitoring and maintenance.

In practice, monitoring an AI vendor means four habits:

• Subscribe to the vendor's change channels (release notes, subprocessor update notices, trust center alerts) and route them to the vendor owner, not a shared inbox.
• Keep a small test set of your own. Twenty to fifty representative questions or cases with known good answers, re-run after every notified model change, will catch most regressions before customers do.
• Watch your own usage. The fastest way a Tier 1 vendor becomes Tier 3 is internal scope creep. Your AI acceptable use policy should say which data classes each approved tool may receive.
• Re-tier on any trigger. If any of the six events in the figure occurs, rescore the five factors. If the tier rises, the vendor answers the additional sections before the change goes live.

When the vendor won't answer, or you have no leverage

Small buyers rarely get large AI providers to fill in custom questionnaires. That is a fact of the market, and both versions of the bank guidance acknowledge it. The workable response has four parts.

1. Use public evidence first. Large providers publish trust centers, data-use documentation, SOC 2 reports under NDA, and model documentation. Map those documents to your questions before asking for anything custom.
2. Test it yourself. For performance and fairness, your own evaluation on your own cases is often better evidence than the vendor's benchmark.
3. Shrink the exposure. If you cannot verify how a tool handles customer data, do not give it customer data. Restrict the use case until it fits the evidence you have.
4. Write it down. Record what you asked, what you could not obtain, the compensating controls, and who accepted the residual risk. An examiner can disagree with a documented judgment; an undocumented one is simply a gap.

There is a point where these steps stop working. If a vendor will not say whether your data trains its models, or where your data goes, and the use case involves customer information, the honest answer is to decline or to build an alternative where you control the data path. A private deployment is not right for every company, but it is the usual answer when the vendor's terms and your obligations cannot be reconciled.

Common mistakes in third-party AI risk management

• Assessing the brand, not the configuration. The same platform can be safe in one configuration and unacceptable in another. Assess the deployment you will actually use: region, retention setting, abuse-monitoring status, connected data sources.
• Missing embedded AI. AI features increasingly arrive inside tools you already approved, through a product update. NIST AI 600-1 suggests updating procurement assessments to address solutions that may rely on embedded generative AI. Add a renewal question: "What AI features were added since our last review?"
• Letting the questionnaire become the control. A completed questionnaire is evidence of diligence, not a control. The controls are the contract terms, your access restrictions, your testing and your monitoring.
• Ignoring the vendor's vendors. The 2023 guidance lists reliance on subcontractors as a due diligence factor and flags dependency on a single provider for multiple activities. In AI, a handful of model providers sit beneath a large share of products, which is a concentration risk your inventory should show.
• Treating the 2026 proposal as already final. As of October 2026 it is a proposal. Plan for a lighter, risk-based regime, but keep running the current one.

Putting it into practice this quarter

An AI vendor risk assessment does not need a new department. It needs a short intake that tiers each vendor, a questionnaire sized to the tier, a scoring rubric that turns answers into decisions, contract language that holds the vendor to those answers, and triggers that bring the vendor back for review when the product changes.

A realistic first quarter looks like this: inventory every vendor product with AI features (including features added to tools you already use), tier them with the five-factor matrix, send sections A to G to the Tier 3 vendors first, and bring the first three rows of the contract table into every AI renewal from now on.

If you are weighing an AI product for a regulated workflow, or deciding whether to buy or build because no vendor can meet your data terms, our AI compliance team can help you assess the options; we offer a free discovery call and a specialist replies within one business day. For anything else, talk to a specialist.