Security Questionnaires for AI Vendors: What to Ask in 2026

Your standard security questionnaire was written for a world where vendors stored your data in a database and processed it with deterministic code. AI vendors break both assumptions. Your data may become training material. The processing logic is a probabilistic model that can be manipulated through its inputs. The vendor's most important subprocessor may be a foundation model provider you never see named in a contract. And the system's failure modes — hallucination, prompt injection, data leakage across contexts — do not appear anywhere in a SIG or CAIQ template.

If you are buying AI products, or your procurement team is fielding a wave of "we added AI" announcements from existing vendors, you need questionnaire content built for AI-specific risk. This guide covers why standard questionnaires fall short, the nine question categories that matter, concrete sample questions for each, a master checklist you can lift directly into your vendor assessment process, and a risk-tiering table so you scale scrutiny to actual exposure.

Why Standard Questionnaires Miss AI Risks

Traditional questionnaires assess confidentiality, integrity, and availability of stored and transmitted data. They do this reasonably well. What they do not assess:

• Training and retention semantics. "Do you encrypt data at rest?" tells you nothing about whether your prompts are retained for model improvement, used to fine-tune shared models, or memorized and potentially regurgitated to other customers.
• A new attack surface. Prompt injection, jailbreaking, and adversarial inputs attack the model through its intended interface. No firewall question covers an attacker exfiltrating data by hiding instructions in a document the AI is asked to summarize.
• Probabilistic failure. Deterministic software either works or errors. Models confidently produce wrong answers. Reliability questions built for uptime SLAs miss hallucination rates, output validation, and fitness-for-purpose in high-stakes use.
• The hidden supply chain. Many "AI vendors" are thin layers over third-party foundation models. Your data flows to a subprocessor whose retention and training policies may differ from the vendor's — and change without notice.
• Silent capability change. Model versions change behavior in ways configuration changes never did. A vendor swapping model versions can materially change accuracy, safety behavior, and data handling with no visible "change" to review.
• Emerging legal exposure. The EU AI Act, ISO/IEC 42001, and sector rules create obligations that flow down to you as a deployer. A vendor with no AI governance posture becomes your regulatory problem.

The fix is not to abandon your existing questionnaire — data security fundamentals still apply — but to add an AI-specific module. Here is what it should contain.

The Nine Question Categories (with Sample Questions)

1. AI Governance

Establishes whether the vendor governs AI deliberately or ships whatever the product team wants.

• Do you maintain a formal AI governance policy, and who owns it at the executive level?
• Do you maintain an inventory of AI systems and models used in your product, including third-party models?
• How do you risk-classify AI features before release, and what review gates apply?
• Do you conduct AI-specific risk assessments (e.g., aligned to NIST AI RMF), and can you share a summary?

2. Training Data Handling and Provenance

The category with the highest contractual stakes.

• Is customer data used to train, fine-tune, or evaluate any model — shared or customer-specific? Is this opt-in, opt-out, or contractually excluded?
• What are the provenance and licensing of your training data? How do you handle copyrighted or personal data within it?
• How long are prompts, outputs, and embeddings retained, and can retention be set to zero?
• Can you honor deletion requests for data that has influenced a trained model, and what does deletion actually mean in that case?
• Do your foundation model subprocessors retain or train on data we send through your product?

3. Model Security

The new attack surface: prompt injection, jailbreaks, and data leakage.

• What defenses do you implement against direct and indirect prompt injection (e.g., instructions embedded in retrieved documents or emails the model processes)?
• How do you prevent cross-tenant data leakage through shared models, caches, or embedding stores?
• Have you conducted adversarial testing / AI red-teaming? By whom, how recently, and can you share results under NDA?
• How do you constrain model access to tools and data (least privilege for agents, sandboxing of code execution, allow-listed actions)?
• What controls prevent the model from being manipulated into revealing system prompts, other customers' data, or internal credentials?

4. Model Lifecycle and Versioning

• How are model updates and version changes tested, approved, and communicated to customers?
• Can we pin a model version, and how much notice do we get before deprecation?
• What evaluation suite must a new model version pass before deployment (accuracy, safety, regression tests)?
• Do you document models (model cards or equivalent) covering intended use, limitations, and known failure modes?

5. Monitoring and Incident Response

• How do you monitor model behavior in production (drift, abuse, anomalous outputs, injection attempts)?
• Do your incident response procedures cover AI-specific incidents — data leakage via model output, successful jailbreak, harmful content generation? Have you exercised them?
• What are your notification commitments and timelines for AI-related incidents affecting our data?
• Do you log prompts and outputs in a way that supports forensic investigation, and who can access those logs?

6. Reliability and Hallucination Controls

• What is the measured accuracy/error rate of the AI features we would rely on, and how is it evaluated?
• What guardrails validate outputs before they reach users or downstream systems (grounding, citations, confidence thresholds, human review gates)?
• For agentic features: what actions can the system take autonomously, and what requires human approval?
• How do you communicate model limitations to end users at the point of use?

7. Compliance and Certifications

• Do you hold SOC 2 Type 2, ISO 27001, and/or ISO/IEC 42001 certifications? Do their scopes cover the AI features in question?
• How have you classified your system under the EU AI Act, and what provider/deployer obligations have you mapped? (See our EU AI Act guide.)
• Where are models hosted and inference performed, and can data residency requirements be met?
• How do you support our obligations as a deployer (documentation, logging access, transparency artifacts)?

8. Responsible AI

• How do you test for bias and unfair outcomes in features that affect people (scoring, screening, recommendations)?
• What content safety measures prevent generation of harmful, defamatory, or infringing output?
• Is AI-generated content disclosed to end users where they might reasonably assume a human produced it?
• What human oversight mechanisms exist for consequential decisions influenced by the system?

9. Customer Data Usage and Intellectual Property

• Who owns the outputs generated from our data and prompts?
• Do you offer indemnification for IP infringement claims arising from model outputs?
• Can our data or fine-tuned artifacts derived from it ever benefit other customers or the vendor's own products?
• On termination, what happens to our prompts, outputs, embeddings, and any customer-specific model artifacts?

Master Checklist: AI Vendor Assessment

A condensed, copy-ready checklist. Every "no" or vague answer is a finding to risk-accept or negotiate.

• Formal AI governance policy with named executive owner
• Complete inventory of models, including third-party foundation models and their providers
• Contractual exclusion of customer data from shared model training (or explicit, controllable opt-in)
• Documented retention periods for prompts, outputs, and embeddings; zero-retention option available
• Foundation model subprocessor terms flow down (no training, defined retention)
• Prompt injection defenses described concretely, including for indirect injection
• Tenant isolation for models, caches, and vector stores explained and tested
• AI red-team or adversarial testing performed within the last 12 months; results shareable under NDA
• Least-privilege scoping for any agentic/tool-using capabilities
• Model version pinning offered; advance notice for model changes and deprecations
• Pre-deployment evaluation suite for model updates (accuracy, safety, regression)
• Production monitoring for drift, abuse, and anomalous outputs
• AI-specific incident response scenarios documented and exercised; notification SLAs defined
• Measured accuracy/error rates for relied-upon features; methodology available
• Output guardrails: grounding/citations, validation, human-in-the-loop for consequential actions
• SOC 2 Type 2 (minimum); ISO 27001 and ISO/IEC 42001 scope covers AI features
• EU AI Act classification completed; deployer-support artifacts available
• Data residency for inference and storage documented and contractually committed
• Bias testing for people-affecting features; content safety controls in place
• Output ownership assigned to customer; IP indemnification offered
• Termination handling covers prompts, outputs, embeddings, and derived artifacts

Risk-Tiering: Scale Scrutiny to Exposure

Not every AI vendor deserves the full interrogation. Tier vendors by data sensitivity and decision impact, then apply proportionate depth.

Two tiering rules worth enforcing:

1. Agentic capability escalates the tier. Any vendor whose AI can take actions (send emails, modify records, execute code) is at least Tier 2 regardless of data sensitivity, because manipulated actions are an incident even when data is not.
2. AI features added to existing vendors trigger reassessment. The vendor you approved in 2024 that "added AI" in 2026 is, for risk purposes, a new vendor. Require notification of material AI feature additions in your contracts.

Practical Tips for Running the Process

Ask for evidence, not attestations. "We defend against prompt injection" is worth little. Ask how, ask for red-team summaries, and ask what happened the last time a defense failed.

Sequence the questionnaire to fail fast. Send the training-data and retention questions first, or flag them as gating. If the vendor trains shared models on customer data with no contractual opt-out, nothing else in the assessment matters — you have your answer in one email instead of a three-week review cycle. The same applies to tenant isolation for Tier 1 vendors: a vague answer there ends the evaluation early and cheaply.

Read the subprocessor list first. The foundation model provider's terms often matter more than the vendor's. If the vendor cannot tell you which model providers touch your data and under what retention terms, stop there.

Negotiate the four contract points that matter most: no training on your data, defined (ideally zero) retention, output ownership, and AI incident notification. Questionnaire answers change; contracts bind.

Reuse your own answers. If you are an AI vendor yourself, expect these exact questions from your customers — and consider publishing the answers proactively in a trust center. Companies that answer AI questions before they are asked close enterprise deals measurably faster. Our guide for AI companies covers building that posture, and our customer trust platform comparison evaluates the tools that automate it.

Frequently Asked Questions

Do I really need AI-specific questions if the vendor has SOC 2?

Yes. SOC 2 evaluates security controls against the Trust Service Criteria; it does not test whether your data trains shared models, whether prompt injection defenses exist, or whether outputs are reliable. A SOC 2 Type 2 report is a strong baseline signal — and its absence is disqualifying for serious vendors — but it answers almost none of the nine categories above.

What is indirect prompt injection and why does it matter for procurement?

Indirect prompt injection is when an attacker plants instructions in content the AI will later process — a web page, an email, a document — causing the model to follow the attacker's instructions instead of the user's. It matters because any AI feature that reads external or user-supplied content inherits this risk, and defenses vary enormously between vendors. It should be a standard question for any Tier 1 or Tier 2 vendor.

Should I refuse vendors that train on customer data?

Not categorically, but the default answer for confidential data should be contractual exclusion from shared model training. Customer-specific fine-tuning that benefits only your tenant is a different, often acceptable arrangement — provided isolation, retention, and deletion semantics are clearly documented.

Which certifications should AI vendors have in 2026?

SOC 2 Type 2 as table stakes; ISO 27001 for international buyers; and ISO/IEC 42001 as the emerging differentiator specifically covering AI management systems. For vendors serving the EU market, evidence of EU AI Act readiness — risk classification, technical documentation, transparency measures — increasingly matters as much as any certificate. See our EU AI Act framework guide.

How do I assess an existing vendor that just added AI features?

Treat it as a scoped new assessment: send the AI module of your questionnaire (categories 1–9 above), confirm whether the AI features are on by default, verify whether your existing contract's data terms cover the new processing, and check whether new subprocessors were added. Many vendors enable AI features by default with data settings you would never have accepted in the original deal.

How often should AI vendors be reassessed?

Tier 1 annually and upon any model or subprocessor change; Tier 2 annually; lower tiers on a 24-month or renewal cadence. The "upon change" trigger is the important one — model swaps change risk profiles in ways traditional software updates do not.

How AuditXYZ Helps

Assessing AI vendors — and being assessed as one — both come down to having the right infrastructure. AuditXYZ helps on both sides: our customer trust platform comparisons evaluate the questionnaire-automation and trust-center tools that let vendors answer assessments like this in hours instead of weeks, and our compliance automation directory compares the platforms that keep the underlying evidence continuously current. When third-party attestation is the missing piece, our auditor directory helps you find firms experienced with SOC 2, ISO 42001, and AI-heavy environments. Compare the platforms, compare the auditors, and make AI vendor risk a process instead of a scramble.