The AI Vendor Due Diligence Questionnaire (Free Template)

When procurement teams evaluate a new SaaS vendor, their default instruments are the Shared Assessments SIG (Standard Information Gathering) questionnaire and the CSA CAIQ (Consensus Assessments Initiative Questionnaire). Both are serviceable for cloud security: they probe controls around access management, encryption, incident response, and infrastructure resilience. Neither was designed for the era of foundation models, retrieval-augmented generation, or autonomous AI agents.

The gap is not theoretical. A 2025 Secureframe report found that supply chain attacks accounted for nearly half (47%) of all individuals affected by data breaches in the first half of 2025, with third-party vendor and supply chain compromise costing an average of $4.91 million per incident. When your AI vendor gets breached—or when their model hallucinates financial data into a client report, or when a prompt injection attack leaks your customers' PII—you inherit that risk. And because AI systems fail in ways that classical software does not, your existing vendor risk instruments almost certainly leave you exposed.

This post explains precisely where standard questionnaires fall short for AI vendors, what categories of questions you need to add, and then delivers a 30-question AI vendor due diligence questionnaire you can copy, paste, and send today.

Why SIG and CAIQ Aren't Enough for AI Vendors

SIG and CAIQ were designed around a threat model where the primary asset is data at rest or in transit, and the primary adversary is an external attacker exploiting known software vulnerabilities. AI systems introduce at least five failure modes those frameworks don't address:

Model-layer risk. A vendor's underlying model may have been trained on scraped data that includes personal information, copyrighted material, or synthetic propaganda. Gartner predicts that by 2027, more than 40% of AI-related data breaches will result from the improper use of generative AI across borders—a category that traditional TPRM instruments don't map. If the vendor used your competitors' customer data to fine-tune their model, you won't find out from a CAIQ response.

Hallucination and reliability risk. Unlike deterministic software, probabilistic models produce outputs that can be confidently wrong. A vendor claiming "95% accuracy" may be measuring on a benchmark dataset that bears no resemblance to your production use case. Without specific questions about evaluation methodology and hallucination rate, you have no way to verify the claim.

Prompt injection and adversarial input risk. Any system that accepts natural language input can be manipulated by adversarial prompts to override its instructions, leak training data, or exfiltrate information. SecurityScorecard research shows that over 35% of data breaches involve third-party compromises; prompt injection creates new supply-chain attack vectors that traditional questionnaires ignore entirely.

IP indemnification and training data provenance. If a vendor trained on copyrighted material without authorization and their model reproduces that content in your outputs, the copyright liability can extend to you as the deployer. The EU AI Act's GPAI provisions under Article 53 now require foundation model providers to publish training data summaries and copyright compliance policies—but most enterprise AI vendors are not GPAI providers, and no equivalent US standard yet exists.

Data residency and cross-border processing. AI inference requires sending prompts and context to a model endpoint. That endpoint may be hosted in a jurisdiction subject to data localization law. Gartner's prediction about cross-border AI processing failures is consistent with rising enforcement under GDPR, China's PIPL, and India's DPDPA.

Platforms like Credo AI and Holistic AI have built vendor portal functionality specifically to collect AI-specific evidence—including model cards, bias audit results, and regulatory compliance attestations—from third-party vendors. FairNow has likewise published vendor questionnaire guidance that goes beyond standard SIG categories. But most organizations don't yet have those platforms in their stack, which means a well-structured PDF questionnaire remains the practical starting point.

What Categories an AI-Specific DDQ Must Cover

Before the template, here is the conceptual structure. An AI vendor DDQ should go beyond the standard TPRM pillars (data security, access controls, incident response) to include:

1. Model Identity and Provenance You need to know what model the vendor is actually running—not just "an LLM." The underlying model determines capability ceiling, known failure modes, licensing terms, and update cadence. If the vendor is using a third-party foundation model (GPT-4, Claude, Llama), they have upstream dependency risk and may not be able to give you advance notice of model changes that affect your workflow.

2. Training Data Transparency Where did the training data come from? Was it scraped from the web, licensed from a data broker, generated synthetically, or sourced from prior customer interactions? Each answer carries different legal and compliance implications. The ISO/IEC 42001 standard for AI management systems requires organizations to document training data sources and bias mitigation measures—a vendor whose governance aligns with 42001 should be able to answer these questions promptly.

3. Model Evaluation Methodology How was the model tested before deployment? What benchmarks were used, and are those benchmarks representative of your use case? Has the model undergone red-teaming or adversarial testing? Arthur AI and Fiddler AI both offer production monitoring platforms that can track metrics like hallucination rate, toxicity, and drift after deployment—but pre-deployment evaluation documentation should come from the vendor.

4. Security and Adversarial Robustness Beyond standard penetration testing, an AI vendor needs to demonstrate defenses against prompt injection, data poisoning, model extraction attacks, and adversarial inputs. Protect AI and Lakera specialize in AI-specific security tooling—if your vendor can reference use of such tools in their security program, that is a positive signal.

5. Data Handling, Residency, and Opt-Out Does the vendor use your prompts and outputs to train future model versions? Do they retain conversation logs, and for how long? Can you opt out of training use? Where are model inference servers physically located? These questions have become baseline requirements for any enterprise deploying AI in regulated industries.

6. Governance, Compliance, and IP Indemnification Has the vendor obtained an ISO/IEC 42001 certification or conducted a gap assessment? Do they have IP indemnification provisions covering AI outputs? What is their process for complying with the NIST AI RMF or the EU AI Act if applicable? A vendor that cannot answer these questions is unlikely to be a durable compliance partner as regulation tightens.

For organizations building out their internal AI governance posture, our methodology page describes how we assess vendor governance depth in more detail.

The 30-Question AI Vendor Due Diligence Questionnaire

The questions below are organized by category. They are designed to be sent to AI vendors alongside—not instead of—your standard SIG or CAIQ questionnaire. Instructions: ask the vendor to provide written responses with supporting documentation (model cards, audit reports, SOC 2 reports, data processing agreements) where indicated.

Section A: Model Identity and Provenance (Questions 1–6)

1. What AI model(s) power your product? Provide the model name, version, and whether it is proprietary, a fine-tuned commercial model (e.g., GPT-4, Claude 3, Gemini), or an open-source model (e.g., Llama, Mistral). Include the model provider and any sublicensing terms.

1. Do you use different models for different features? If yes, provide a complete list of all AI models used across your product, their roles, and their respective providers.

1. How frequently are models updated or retrained? What is your policy for notifying customers in advance of a material model change that may affect output quality or behavior?

1. Do you fine-tune or customize foundation models? If so, describe the fine-tuning process, the data used, and what additional testing was conducted post-fine-tuning.

1. What third-party AI services or APIs does your product depend on? List all critical upstream AI dependencies (e.g., OpenAI API, Anthropic API, cloud-hosted inference services). What is your contingency plan if a provider discontinues or materially changes a service?

1. Do you maintain a model card or equivalent technical specification for your AI system? Please provide it or a representative excerpt. If you do not maintain a model card, describe what technical documentation you maintain.

Section B: Training Data and IP (Questions 7–12)

1. What are the primary sources of data used to train or fine-tune your AI models? Specify whether data was web-scraped, licensed from a data broker, generated synthetically, sourced from customer interactions, or obtained through academic datasets. Provide documentation of licensing or provenance where available.

1. Does your training data include personal information or data subject to privacy regulation (GDPR, CCPA, HIPAA)? If yes, describe the legal basis for processing, anonymization methods applied, and validation procedures for those methods.

1. Have you assessed your training data for representation bias across demographic groups? Describe your bias detection methodology and provide summary results or cite third-party audit reports.

1. Do you comply with text-and-data mining opt-outs (e.g., robots.txt, the EU Copyright Directive Article 4(3) reservation)? Describe your process for identifying and honoring rights-holder opt-outs in training data collection.

1. What IP indemnification do you provide customers for AI-generated outputs? Does your service agreement indemnify customers against claims that outputs infringe third-party intellectual property rights? If yes, describe the scope and any exclusions.

1. Will you use our organization's data—including prompts, inputs, and outputs—to train or fine-tune any AI model? If yes, describe the purpose, the opt-out mechanism available to customers, and any contractual restrictions on such use.

Section C: Model Performance and Evaluation (Questions 13–18)

1. What benchmarks or internal evaluations do you use to measure model accuracy and reliability? Provide benchmark names, datasets, scoring methodology, and representative results. Clarify how benchmarks relate to your product's production use cases.

1. What is your measured hallucination rate, and how do you define and calculate it? Describe the methodology (e.g., response-level vs. claim-level detection), the dataset used, and any third-party validation of the metric.

1. How do you test model performance across diverse user populations and languages? Describe subgroup evaluation methodology and any known performance disparities across demographic groups, languages, or domains.

1. Have you conducted adversarial testing or red-teaming of your AI system? If yes, describe the testing methodology, who conducted it (internal team vs. external firm), and how findings were remediated. If external, identify the firm.

1. What human oversight mechanisms exist for high-stakes or irreversible AI decisions? Describe human-in-the-loop checkpoints, escalation paths, and any use-case restrictions where automated outputs cannot be acted upon without human review.

1. How do you measure and communicate model confidence or uncertainty? Does your system surface uncertainty signals to end users when outputs are low-confidence? Provide documentation or screenshots.

Section D: Security and Adversarial Robustness (Questions 19–23)

1. What controls do you have in place to defend against prompt injection attacks? Describe input validation, instruction hierarchy enforcement, sandboxing, and any monitoring for attempted instruction overrides.

1. How do you prevent data poisoning or adversarial manipulation of your model during training or fine-tuning? Describe data validation procedures, anomaly detection on training pipelines, and access controls over training infrastructure.

1. Have you undergone AI-specific security testing (beyond standard application penetration testing)? If yes, describe the scope, who conducted it, and when it was last performed. Provide a redacted executive summary if available.

1. What monitoring is in place to detect anomalous model behavior or output drift in production? Describe your observability stack, alert thresholds, and incident response procedures specific to AI system failures.

1. Do you have a published vulnerability disclosure or bug bounty program covering your AI systems? Provide the URL or describe how security researchers can report AI-specific vulnerabilities.

Section E: Data Residency and Privacy (Questions 24–27)

1. Where are your AI model inference servers physically located? List all data centers and cloud regions used for inference, including any third-party providers. Confirm whether data leaves the customer's primary jurisdiction during inference.

1. How long do you retain customer prompts, inputs, conversation history, and AI outputs? Provide your data retention schedule by data type. Describe the deletion mechanism customers can invoke.

1. What encryption standards apply to customer data in transit and at rest within your AI pipeline? Include the encryption protocol and key management approach. Are encryption keys customer-managed or vendor-managed?

1. How do you handle data subject requests (access, deletion, correction) that may involve AI-processed data? Describe your process for identifying AI-processed records in response to GDPR Article 15–17 or CCPA requests.

Section F: Governance, Compliance, and Contractual Protections (Questions 28–30)

1. What AI governance frameworks or standards does your organization align with? Specify frameworks adopted (e.g., NIST AI RMF, ISO/IEC 42001, EU AI Act compliance obligations). Provide certifications, audit reports, or gap assessment documentation.

1. Under the EU AI Act, how do you classify your AI system, and what obligations have you implemented? If your system is used in an EU context, confirm whether it is classified as high-risk under Annex III, and describe compliance measures including technical documentation, conformity assessment status, and logging.

1. Describe your process for notifying customers of material changes, security incidents, or regulatory findings related to your AI system. What SLAs govern incident notification? What contractual commitments do you make regarding AI system reliability, output quality, and regulatory compliance?

Red Flags in Vendor Responses

The questionnaire is only as useful as your ability to evaluate the responses. Several patterns should raise immediate concern:

• "Our model is proprietary" used as a reason to provide no further detail. Legitimate IP protection can coexist with model card disclosure at a summary level.
• No training data documentation. A vendor that cannot describe where their training data came from—even at a high level—lacks the provenance tracking required by both ISO/IEC 42001 and the EU AI Act.
• Benchmark results that don't match your use case. A vendor citing strong performance on MMLU or HumanEval may have a model that performs poorly on your specific domain. Request evidence from domain-relevant evaluations.
• No opt-out from training data use. Major providers including OpenAI, Anthropic, and Google all offer contractual opt-outs from training data use in their enterprise tiers. A vendor that cannot offer the same warrants scrutiny.
• No IP indemnification. As generative AI copyright litigation accumulates, vendors without indemnification provisions are transferring litigation risk to customers.

Governance platforms like Monitaur, Trustible, and WhyLabs can help operationalize ongoing vendor monitoring after initial onboarding—turning a one-time questionnaire into a continuous control.

Key Takeaways

• Standard SIG and CAIQ questionnaires were not designed to assess AI-specific risks including hallucination, prompt injection, training data provenance, or IP liability.
• An AI vendor DDQ should cover six categories: model identity, training data and IP, evaluation methodology, adversarial security, data residency, and governance.
• Ask for documentation, not just attestations: model cards, bias audit reports, SOC 2 reports, and data processing agreements are all standard deliverables from mature AI vendors.
• Red flags include inability to describe training data sources, absence of IP indemnification, benchmark results disconnected from your use case, and no opt-out from training data use.
• The ISO/IEC 42001 AI management system standard and your organization's assessment methodology provide a governance framework for scoring vendor responses consistently across procurement cycles.

Sources

1. Secureframe, supply chain breach statistics (2025): https://www.atlassystems.com/blog/ai-vendor-risk-questionnaire
2. Trustible, AI Vendor Due Diligence 10 Questions: https://trustible.ai/post/navigating-ai-vendor-risk-10-questions-for-your-vendor-due-diligence-process/
3. FairNow, AI Vendor Questionnaire Guide: https://fairnow.ai/ai-vendor-questionnaire-questions/
4. 1up.ai, Top 20 AI Vendor Compliance Questions: https://1up.ai/blog/ai-vendor-questionnaire-example/
5. Responsive.io, Vendor Risk Assessment Checklist (SIG/CAIQ): https://www.responsive.io/glossary/ai/vendor-risk-assessment-a-checklist
6. Delinea, Essential AI Questions for Vendor Security Assessments: https://delinea.com/blog/essential-ai-questions-for-vendor-security-assessments
7. California Governor Newsom, Executive Order N-5-26 on AI Vendor Certification (March 2026): https://www.jdsupra.com/legalnews/california-s-new-executive-order-5050623/
8. ISO/IEC 42001 AI Risk Assessment overview, Schellman: https://www.schellman.com/blog/iso-certifications/how-to-assess-and-treat-ai-risks-and-impacts-with-iso42001
9. Arthur AI, Hallucination Detection Documentation: https://docs.arthur.ai/docs/hallucination
10. ACC, AI Vendor Due Diligence Checklist template: https://www.acc.com/sites/default/files/2024-08/AI---Vendor-Due-Diligence-Checklist-525861.1-.docx