Organisations that deploy AI governance platforms are 3.4 times more likely to achieve high effectiveness in AI governance than those that do not, according to a February 2026 Gartner survey of 360 enterprises. That gap matters most at the perimeter of your AI estate the third-party AI systems embedded in your procurement stack, HR tooling, compliance workflows, and customer-facing products that your internal governance programme may not yet cover.
IBM’s 2025 Cost of Data Breach Report found that 13% of organisations reported breaches involving AI models or applications, and 97% of those organisations lacked proper AI access controls. [VERIFY exact figure from IBM 2025 report] When a vendor’s AI system fails through bias, drift, a data breach, or a training data compliance violation your organisation inherits that exposure. The EU AI Act and ISO/IEC 42001:2023 are now explicit: deployer obligations extend to the AI systems you procure, not just the ones you build.
This guide gives procurement and GRC teams a structured AI vendor risk assessment questionnaire framework mapped to ISO 42001 Annex A.10, EU AI Act Article 17, and NIST AI RMF GOVERN 6.2 along with a vendor tiering model, red-flag signal guide, and the contractual provisions that should follow.
Why Your Standard Vendor Questionnaire Falls Short with AI
Standard third-party risk management questionnaires SIG, CAIQ, most bespoke TPRM templates were designed for a world where vendors delivered defined software with predictable outputs. AI systems do not behave that way.
| What an AI Vendor Risk Assessment Questionnaire Is An AI vendor risk assessment questionnaire is a structured due diligence instrument that extends standard third-party risk management to cover AI-specific risks that generic vendor questionnaires miss. These include training data provenance (where and how the vendor sourced training data), model explainability (whether the AI can explain its decisions), algorithmic bias controls, model drift monitoring, and AI-specific incident response procedures. Unlike a standard security questionnaire, an AI-specific assessment also evaluates the vendor’s governance posture against ISO/IEC 42001 Annex A.10, EU AI Act Article 17 and NIST AI RMF GOVERN 6.2. |
Three dimensions separate AI due diligence from standard vendor risk:
First, model behaviour is non-deterministic. A chatbot that performs well in a sandboxed evaluation may generate biased, factually wrong, or legally non-compliant outputs at scale. A standard questionnaire asking about uptime SLAs and access controls cannot capture this risk.
Second, training data is the liability vector most procurement teams overlook. If a vendor trained their model on unlicensed data, data from protected groups, or data with quality or provenance gaps, those problems travel with every output the system produces including outputs used in your regulated workflows.
Third, AI systems change continuously. Models get retrained, fine-tuned, or replaced without the transparency of a traditional software update cycle. Your due diligence at procurement time may not reflect what the system does six months after go-live.
There is also the silent AI problem: vendors embedding AI into SaaS products without explicit disclosure. A document review tool, a compliance monitoring platform, or a hiring tool may contain AI decision-making that the vendor’s marketing materials describe as “smart” or “automated” without specifying what’s actually running underneath. Your questionnaire needs to surface this.
How to Tier AI Vendors Before Sending Any Questionnaire
Not every AI vendor warrants the same level of scrutiny. Applying full due diligence to a low-stakes productivity tool consumes resources that should go toward vendors whose AI directly affects regulated outcomes. A tiering model solves this.
| Tier | AI Use Case Examples | Due Diligence Requirement |
| Tier 1 – Critical AI Vendors | Credit decisions, fraud detection, compliance screening, regulatory reporting, hiring decisions, patient triage | Full AI-specific due diligence: all nine question areas, independent documentation review, enhanced contract provisions, annual reassessment |
| Tier 2 – Material AI Vendors | AI-assisted document review, risk monitoring tools, workflow automation touching customer data, AI co-pilots used in regulated functions | Standard AI questionnaire plus targeted deep-dive on training data and explainability; biennial reassessment; AI-specific contract clauses |
| Tier 3 – Standard AI Vendors | Internal productivity AI (scheduling, drafting), low-stakes automation, AI features in tools where AI is incidental to the service | AI supplement to existing vendor questionnaire; confirm disclosure obligations; annual standard review only |
Tiering starts with your AI system inventory. Before you can classify a vendor, you need to know which of your vendors are using AI and for what purpose. Ask existing vendors a single screening question: “In what ways does your service incorporate artificial intelligence or machine learning?” The answers or the silence tell you where to focus.
One practical signal: vendors that resist this question, or provide non-specific answers like “we use AI to improve the product,” belong in Tier 1 scrutiny regardless of their nominal risk profile. Opacity at screening is a risk indicator in itself.
The Nine Areas Every AI Vendor Questionnaire Must Cover
The following question areas form the core of a defensible AI vendor due diligence process. Each area maps to ISO 42001 Annex A.10 supplier controls, EU AI Act obligations for high-risk AI deployers, or NIST AI RMF third-party risk categories detailed in the framework mapping section below.
| Area | Core Questions to Ask | ISO 42001 Clause | Evidence to Request |
| 1. AI Disclosure & System Scope | Does this product use AI or ML? What functions does the AI perform? Is the AI decision-making, recommendation, or automation? | Annex A.10.1 | Written AI system description; product documentation; model scope statement |
| 2. Training Data Provenance | Where was training data sourced? Was it licensed? Does it include personal data, and under what legal basis? How is data quality verified? | Annex A.6 / A.10.2 | Data provenance documentation; data governance policy; DPA if personal data involved |
| 3. Model Explainability & Transparency | Can the model explain its outputs? Is an explanation available to affected individuals or regulators? Is a model card published? | Annex A.10.2 | Model card; explainability methodology documentation; sample explanation outputs |
| 4. Bias Testing & Mitigation | What bias testing methodology is used? How frequently are bias audits conducted? What were the findings of the most recent bias evaluation? | Annex A.6.1 / A.10 | Bias audit report; fairness metrics methodology; most recent audit results |
| 5. Security Controls (AI-Specific) | How is the model protected against data poisoning? Is there protection against adversarial inputs or model extraction attacks? What is the access control model for the AI system? | Annex A.10 / Clause 6.1 | Security penetration test results covering AI components; threat model documentation |
| 6. Performance Monitoring & Drift Detection | How is model performance monitored post-deployment? What thresholds trigger model review or retraining? How are customers notified of material performance changes? | Annex A.10.3 | Monitoring dashboard access or report; drift detection policy; SLA for model performance |
| 7. AI Incident Response | What constitutes an AI-specific incident (bias discovery, model failure, training data breach)? What is the notification timeline? Has the vendor experienced any AI incidents in the past 24 months? | Annex A.10 / Clause 8.7 | AI incident response plan; incident history (last 24 months); breach notification SLA |
| 8. Human Oversight Mechanisms | Can outputs be overridden by a human? Is there a human review requirement for high-stakes decisions? How is the human override logged for audit purposes? | Clause 6.1.4 / Annex A.10 | Human override documentation; workflow diagrams showing oversight integration points |
| 9. Regulatory Framework Alignment | Which frameworks does the vendor comply with (ISO 42001, EU AI Act, NIST AI RMF, SOC 2 AI controls)? Is there a certificate or third-party audit report to evidence this? | Annex A.10.1 | ISO 42001 certificate (or audit report); SOC 2 Type II report; self-attestation with specific clause references |
Two practical notes on executing this: First, request documentation rather than accepting self-attestation for Areas 2, 4, and 7. Vendors that can only provide verbal assurances about training data provenance or bias testing results should be escalated to a higher tier review. Second, treat Area 9 with precision. “We are ISO 42001 compliant” is not evidence. An ISO 42001 certificate from an accredited certification body is evidence.
Responses collected from AI vendors should feed directly into your AI risk assessment template, helping quantify risks, document mitigation measures, and prioritize remediation activities.
Cross-Framework Clause Mapping: What ISO 42001, EU AI Act and NIST AI RMF Actually Require
The regulatory case for an AI-specific vendor questionnaire is explicit across all three major frameworks, though each approaches supplier oversight from a different angle. Understanding where they converge is what converts your questionnaire from a best-practice exercise into a compliance obligation.
| Question Area | ISO 42001 Clause / Annex | EU AI Act Article | NIST AI RMF Function |
| AI Disclosure & System Scope | Annex A.10.1 – AI system use by suppliers | Art. 17(1)(g) – QMS supplier oversight | GOVERN 6.2 – Policies for AI third-party entities |
| Training Data Provenance | Annex A.6 – Data for AI systems; Annex A.10.2 | Art. 10 – Data governance for high-risk AI | MANAGE 2.2 – AI risk in third-party data |
| Model Explainability | Annex A.10.2 – Supplier documentation requirements | Art. 13 – Transparency and provision of information | GOVERN 6.2 – Transparency requirements for third parties |
| Bias Testing & Mitigation | Annex A.6.1 – Bias identification and management | Art. 10(2)(f) -Examination for biases | MEASURE 2.5 – AI bias evaluation |
| Security Controls | Clause 6.1.2 – AI risk assessment; Annex A.10 | Art. 9 – Risk management system | MANAGE 2.2 – Third-party risk management |
| Performance Monitoring & Drift | Annex A.10.3 – Ongoing supplier monitoring | Art. 72 – Post-market monitoring obligation | MEASURE 2.7 – AI performance evaluation |
| AI Incident Response | Clause 8.7 – AI system incidents; Annex A.10 | Art. 73 – Serious incident reporting | RESPOND 1.1 – Response to AI incidents |
| Human Oversight | Clause 6.1.4 – AI impact assessment; Annex A.10 | Art. 14 – Human oversight for high-risk AI | GOVERN 1.7 – Human oversight processes |
| Framework Alignment | Annex A.10.1 – Supplier responsibility agreements | Art. 17 – QMS documentation obligations | GOVERN 6.2 – Organisational accountability for third parties |
Where these frameworks converge is on supply chain accountability: if you deploy an AI system built or trained by a vendor, you cannot outsource your compliance obligation alongside it. ISO 42001 frames this as a management system control. The EU AI Act frames it as a legal obligation for high-risk AI deployers. NIST AI RMF frames it as an organisational governance responsibility.
One important distinction for US-based procurement teams: NIST AI RMF is voluntary, while EU AI Act obligations apply to any organisation placing high-risk AI systems on the EU market or using them to affect EU-based individuals regardless of where the deploying organisation is headquartered. If your vendor’s AI product touches EU individuals, your due diligence needs to reflect EU AI Act requirements.
Fourth-Party AI Risk: The Dimension Most Due Diligence Processes Miss
Most AI vendor questionnaires stop at the vendor. The more dangerous risk often sits one layer deeper.
Fourth-party AI risk arises when your vendor’s product is built on or fine-tuned from an AI model provided by a different organisation a foundation model from a major AI lab, a specialised model from a data analytics vendor, or a general-purpose language model wrapped into an industry-specific product. You are assessing the vendor’s risk controls, but the model’s actual behaviour, training data provenance, and bias profile belong to a fourth party you may never directly evaluate.
This is not a theoretical concern. A compliance monitoring SaaS vendor whose product surfaces AI-generated risk alerts may be using a general-purpose large language model that was trained on public internet data with no documented bias evaluation. Your questionnaire assessed the SaaS vendor’s security controls. It said nothing about what model is actually making the risk determinations.
Specific questions to add for fourth-party AI risk:
- Which AI models or model providers underlie this product? Please name them specifically.
- Are you using a foundation model (e.g., from OpenAI, Google, Anthropic, Meta) as a base? If so, which version and what fine-tuning has been applied?
- Do you have a model card or equivalent technical disclosure for the base model used in this product?
- If the base model provider changes a model version, what is your notification process to customers?
- Are there any AI subprocessors involved in delivering this service? If so, provide their identities and their compliance certifications.
“We use a third-party AI” without further detail is a red flag that warrants escalation, not acceptance. Under EU AI Act Article 17, high-risk AI deployers must document their supply chain. A vendor who cannot name their foundation model provider is a vendor who cannot support your compliance documentation.
Vendor due diligence is only one part of governance. A comprehensive AI governance checklist helps ensure procurement, risk management, documentation, and oversight activities are audit ready.
Red Flags: What Vendor Responses Should Actually Tell You
A questionnaire is only as useful as your ability to interpret the responses. Most responses to AI due diligence questions fall somewhere between solid evidence and deliberate vagueness. Here is what to look for:
| Red Flag Response | What It Signals | Appropriate Next Step |
| “We are ISO 42001 compliant” (no certificate provided) | The vendor has not been audited against the standard, or the certification has lapsed | Request the actual certificate from an accredited certification body. Self-attestation is insufficient. |
| “We test for fairness and bias” (no methodology or results provided) | Bias testing may be informal or undocumented; unlikely to satisfy a regulatory audit | Request the bias evaluation methodology, last audit date, and summary findings |
| “We use AI to improve outcomes” (no specifics on AI functions) | The vendor is not being transparent about how AI is used in the product | Require a written AI system description before proceeding; consider escalating to Tier 1 scrutiny |
| “Our AI is constantly improving” (no model change notification process) | Model updates could materially change outputs without your knowledge or consent | Require contractual model change notification with minimum 30-day notice before material updates |
| “We rely on our foundation model provider for safety” (no independent controls) | The vendor has outsourced their governance obligations to a fourth party without verification | Request the fourth-party model provider’s documentation; evaluate whether the vendor has independently validated safety claims |
| “We have not had any AI incidents” (no incident response plan provided) | Either the vendor lacks a documented response process or has not recognised AI-specific incidents as a category | Require an AI incident response plan; absence of any incidents from a vendor with significant AI deployment is suspicious, not reassuring |
One thing that consistently separates organisations that pass their first ISO 42001 certification audit from those that do not is the depth of their third-party evidence. Auditors are not interested in whether you sent a questionnaire; they want to see that you evaluated the responses, escalated gaps, and have documented evidence of that process.
Turning Questionnaire Responses into Contract Provisions
The questionnaire is the diagnostic. The contract is the remedy. Without contractual follow-through, your due diligence findings have no enforcement mechanism.
Six clauses should appear in every Tier 1 AI vendor contract, and a risk-tiered subset should appear in Tier 2 agreements:
| Contract Clause | What It Requires | Tier Applicability |
| Model Change Notification | Vendor must notify the deployer with minimum 30 days notice before any material change to the AI model (architecture, training data, performance thresholds) | Tier 1 and 2 |
| Audit Rights | Deployer retains the right to audit the vendor’s AI governance practices, including bias testing results and incident logs, at least annually | Tier 1 |
| Bias and Fairness Reporting | Vendor must provide annual bias evaluation results, including metrics, methodology, and any remediation actions taken | Tier 1 and 2 |
| AI Incident Notification | Vendor must notify the deployer within 72 hours of any AI-specific incident (model failure, bias discovery, training data breach, output error affecting regulated decisions) | Tier 1 and 2 |
| Subprocessor / Fourth-Party Disclosure | Vendor must disclose all AI subprocessors and foundation model providers; must notify the deployer before adding new AI subprocessors | Tier 1 and 2 |
| Certification Maintenance | Vendor must maintain any stated certifications (ISO 42001, SOC 2, ISO 27001) for the term of the contract, with notice if any certification lapses or scope narrows | Tier 1 and 2 |
Contract language is where the risk tier matters most. A foundation model provider in a customer-facing credit decision pipeline warrants all six clauses plus contractual indemnification for AI-specific failures. A low-stakes internal productivity tool can operate on a lighter set disclosure and incident notification at minimum.
Two common gaps in existing vendor contracts: first, most are silent on model change notification. An AI vendor can retrain their model, change their foundation model provider, or fine-tune on new data without technically breaching a contract that only specifies uptime SLAs. Second, incident notification clauses typically cover data breaches but not AI-specific failures a bias discovery that affects your compliance screening outputs, for example, may not trigger any contractual notification under a standard data breach definition.
After Onboarding: Maintaining AI Vendor Oversight Across the Lifecycle
ISO 42001 Annex A.10.3 is explicit: supplier management is not a one-time onboarding exercise. The standard requires ongoing monitoring, not just initial due diligence.
In practice, ongoing AI vendor oversight needs two inputs: a scheduled reassessment calendar and an event-driven trigger set.
| Activity | Tier 1 Cadence | Tier 2 Cadence | Trigger Events (All Tiers) |
| Full AI due diligence re-assessment | Annual | Biennial | Significant model change; ownership or subprocessor change; regulatory enforcement action against vendor |
| Bias and performance review | Quarterly review of vendor-provided metrics | Annual report review | AI incident notification; bias discovery in operational outputs |
| Subprocessor and fourth-party review | Quarterly review against registered baseline | Annual | Vendor adds new AI subprocessor; foundation model version change |
| Contract and SLA compliance review | Semi-annual | Annual | Certification lapse; contractual breach; missed incident notification |
| Regulatory change assessment | Triggered (as new obligations apply) | Triggered | New EU AI Act enforcement milestone; ISO 42001 standard revision |
The EU AI Act introduces a specific post-market monitoring obligation for high-risk AI system providers under Article 72. For deployers, the practical implication is that your vendor should be conducting post-market surveillance on the AI they sell you and your contract should require them to share the results with you on a defined schedule.
Govern365.ai’s vendor oversight module supports this cadence with scheduled reassessment alerts, certificate expiry notifications, and model change log tracking that links directly to your AI risk register and ISO 42001 Statement of Applicability. For GRC teams managing AI vendor populations at scale, this kind of automated oversight is what converts a spreadsheet-based process into something that actually holds up at audit.
Frequently Asked Questions
What is an AI vendor risk assessment questionnaire and how is it different from a standard vendor questionnaire?
An AI vendor risk assessment questionnaire extends standard third-party risk management to cover AI-specific risk dimensions that generic vendor questionnaires miss. Standard questionnaires cover security controls, uptime, and data handling. An AI-specific questionnaire adds training data provenance, model explainability, algorithmic bias controls, drift monitoring, AI incident response procedures, and alignment with frameworks such as ISO/IEC 42001 Annex A.10 and EU AI Act Article 17. The critical difference is that AI vendor risk is dynamic models change, drift, and fail in ways that static software does not.
Which ISO 42001 clauses require AI vendor due diligence?
ISO/IEC 42001:2023 Annex A.10 (AI system use by external parties) is the primary supplier management section. Annex A.10.1 covers the organisation’s responsibilities for AI systems used by external parties; Annex A.10.2 and A.10.3 address supplier documentation requirements and ongoing monitoring. Clause 6.1.2 (AI risk assessment) also applies, as supplier-introduced risks must be included in the AIMS risk register. Clause 8.7 covers AI system incidents, including those originating from vendor AI components.
Does the EU AI Act require deployers to assess their AI vendors?
Yes. EU AI Act Article 17 requires providers of high-risk AI systems to maintain a quality management system that includes supplier oversight. For deployers using high-risk AI procured from a vendor, Article 17(1)(g) explicitly requires that the QMS cover supply chain obligations. Additionally, Article 10 requires data governance controls covering training data quality which, for procured AI, means you must verify your vendor’s training data governance practices.
What is fourth-party AI risk and how do I screen for it?
Fourth-party AI risk arises when your AI vendor’s product is built on AI models provided by another organisation typically a foundation model from a major AI lab. Your due diligence assesses the vendor’s controls, but the model’s training data provenance, bias profile, and governance posture belong to the fourth party. Screen for it by asking vendors to specifically name the AI models underlying their service, disclose any foundation model providers, and provide a model card or equivalent documentation. A vendor who cannot name their model provider cannot support your compliance documentation under EU AI Act Article 17.
How should I tier AI vendors for due diligence purposes?
Classify vendors into three tiers based on the nature and stakes of their AI’s role in your operations. Tier 1 (Critical): AI directly affects regulated decisions credit scoring, compliance screening, hiring, patient triage. Apply full AI-specific due diligence. Tier 2 (Material): AI touches customer data or regulated workflows but is not decision-critical. Apply a standard AI questionnaire with targeted deep-dive questions. Tier 3 (Standard): AI is incidental to the service and low-stakes. Apply a brief AI supplement to your existing vendor questionnaire and confirm disclosure obligations.
What documentation should I request as evidence from AI vendors?
For Tier 1 vendors, request: ISO 42001 certificate from an accredited certification body (or SOC 2 Type II covering AI components), model card or AI system description, bias evaluation report (most recent, with methodology), data provenance documentation for training data, AI incident response plan, and list of AI subprocessors including foundation model providers. Self-attestation is not acceptable as sole evidence for any of these areas. “We follow ISO 42001 principles” without a certificate is meaningless for audit purposes.
How often should AI vendors be reassessed after initial onboarding?
Apply a risk-tiered cadence: Tier 1 vendors should undergo full AI due diligence re-assessment annually, with quarterly reviews of vendor-provided bias and performance metrics. Tier 2 vendors require biennial full re-assessment with annual report review. In addition to scheduled reviews, any of the following should trigger an immediate reassessment for any tier: a material model change, a change in ownership or subprocessor, an AI incident notification, or a regulatory enforcement action against the vendor. ISO 42001 Annex A.10.3 explicitly requires ongoing monitoring, not just onboarding checks.
Conclusion
Third-party AI risk is not a procurement problem it is a governance problem that procurement triggers. The organisations that will pass their ISO 42001 certification audits and demonstrate EU AI Act compliance in the years ahead are the ones building due diligence processes now that treat vendor AI as part of their own governance perimeter, not as a supplier’s internal concern.
A structured AI vendor risk assessment questionnaire, mapped to ISO 42001 Annex A.10, EU AI Act Article 17, and NIST AI RMF GOVERN 6.2, is where that governance perimeter starts. Begin with your vendor inventory, apply a tiering model, and start with your Tier 1 vendors before the next contract renewal cycle.
To operationalise this framework across your full AI vendor population, start your 14-day free trial of Govern365.ai, by the Global AI Certification Council.
