AI Vendor Due Diligence Questionnaire Template and Evidence Matrix

A practical AI vendor due-diligence questionnaire and evidence register that buyers can adapt to a named AI product and use case.

AI vendor due diligence questionnaire template

Use this reusable questionnaire to request evidence from a supplier of a named AI product. It covers AI-specific risks that a generic SaaS review may miss: model providers, training and retention practices, retrieval and agents, independent testing, and changes after contract award. It is not a certification, legal opinion or substitute for risk-based assessment.

Copy the following headings into your procurement evidence register: Requirement ID; Question; Supplier response; Evidence URL or document; Product/version covered; Evidence date; Reviewer; Verification level; Residual issue; Decision or mitigation; Recheck date.

Section A — Supplier, service and intended use

1. What is the contracting legal entity and who provides support and incident escalation? 2. What exact product, service tier, version and deployment configuration is being proposed? 3. Which uses and user groups are supported, restricted or explicitly prohibited? 4. Which critical suppliers, sub-processors, model hosts and other fourth parties will deliver the service? 5. What customer references or deployment claims can be verified independently?

Evidence: company particulars, product specification, support schedule, architecture, third-party inventory and appropriately consented references.

Section B — Models, data and dependencies

6. Which model families and providers may process our data, and where is processing hosted? 7. What changes in model version, provider, routing or fallback are permitted without notice? 8. Are customer prompts, retrieved documents, responses or logs used for training or improvement? Under which contract terms and defaults? 9. What data is stored, for how long, where, by whom and under what deletion process? 10. Which international transfers occur and what safeguards are provided where applicable? 11. How are model, retrieval, API and subprocessor changes evaluated and communicated to customers?

Evidence: dated model/dependency inventory, data-flow map, data processing terms, retention schedule, subprocessors and change log. Follow the ICO's AI data-protection guidance where relevant.

Section C — Security, agents and operations

12. How are identities, privileged accounts, service credentials and tenant access controlled? 13. How are prompt injection and malicious instructions in retrieved documents or tool responses tested? 14. Which external tools can agents invoke, with what permissions, safeguards and human approvals? 15. How are tool actions, incidents and material model changes logged and investigated? 16. What security testing, penetration testing, red teaming and vulnerability remediation support the specific production architecture? 17. What happens if a model host, external API or security control fails?

Evidence: threat model, agent permission matrix, test summaries and remediation evidence, logging specification, incident response and resilience plan. See the NCSC secure AI system development guidance.

Section D — Quality, governance and users

18. What representative evaluation tasks, datasets, baselines and thresholds support claims of accuracy and reliability? 19. How are unsafe, inaccurate, biased or non-compliant outputs detected and escalated? 20. Where can a trained person review, override or challenge consequential outputs? 21. What user-facing limitations, warnings, accessibility provisions and training are supplied? 22. How are operational performance, quality drift and complaints monitored over time?

Evidence: evaluation protocol, testing report, product limitations, human-oversight workflow, monitoring and complaints records.

Section E — Contracts, assurance and exit

23. What contract terms govern data use, confidentiality, security incidents and audit rights? 24. Who is responsible when models or subprocessors change after signature? 25. How can data, prompts, outputs, logs and customer configuration be exported at termination? 26. What deletion verification, continuity arrangements and transition support are available? 27. If a certificate or independent assurance report is cited, what entity, activity, product and period does it actually cover? 28. What evidence expires, and which events require a reassessment?

Evidence: proposed contract, service levels, exit schedule, certificate scope and assurance report. ISO/IEC 42001 relates to an AI management system; it does not automatically validate the named AI product.

Classify each answer before approving the supplier

| Verification level | Meaning | Buyer action | |---|---|---| | Claim only | Assertion without adequate supporting evidence | Request source or mark unverified | | Documented | Relevant policy, contractual or technical record is supplied | Check applicability, date and ownership | | Demonstrated | A control is shown operating for the proposed product or environment | Record method, result and limitations | | Independently examined | A suitable independent reviewer has checked evidence for a stated scope | Check reviewer, scope, dates and exclusions |

Do not treat missing answers as passed requirements. A high-impact deployment needs proportionately stronger buyer-side testing and governance, and sometimes specialist legal or technical review.

Related procurement resources

The AI vendor due diligence checklist explains the process; the supplier evaluation framework compares candidates; AI security due diligence covers technical risks. For independent examination of a named product, review AI TrustMark assurance and how assessments work. An examination is not a guaranteed result or a substitute for buyer responsibility.