The AI Vendor Security Questionnaire: 38 Questions Procurement Should Actually Ask

TL;DR

• Procurement should assess the AI request boundary, not rely on a standard SOC 2 questionnaire with two added AI questions.
• A vendor should identify exact model versions, provider retention by feature, tenant isolation, and region-specific processing.
• Each AI decision should record identity, model, outcome, policy version, data classification, timestamp, and tamper evidence.
• The service should fail closed on policy errors, detect prompt injection before model action, and provide customer-controlled audit exports and policies.

Below are 38 questions to send an AI vendor, grouped into seven categories, each one paired with the answer a defensible vendor gives and the answer that should trigger a deeper look. If you only have time for six, use questions 1, 4, 13, 18, 20, and 35: model coverage, provider retention, audit contents, policy state at decision time, fail-closed behaviour, and AI-layer incident response.

A typical AI vendor security questionnaire is a SOC 2 procurement template with two AI questions tacked on the end. The process surfaces well-formatted SOC 2 reports while leaving the AI-layer risks unmapped. The questions a CISO or compliance lead should actually ask sit at a different layer than the SOC 2 template covers: the AI request boundary, the model coverage, the per-decision audit, the policy enforcement, the prompt-injection handling, the data residency, the regulatory alignment, and the incident response that fires when something at the AI layer breaks.

Category 1: Model coverage and isolation (Questions 1-6)

The first category surfaces which models the vendor uses, how the vendor isolates customer data from the model provider's training pipelines, and what happens when the vendor changes its model.

1. Which model providers and which specific model versions does the service call?

A defensible answer names the providers (OpenAI, Anthropic, Google, AWS Bedrock, Azure OpenAI, self-hosted) and the specific model versions in production. A vague answer ("we use leading LLM providers") should trigger a deeper review.

2. How does the vendor pin model versions and notify customers of model changes?

A defensible vendor pins versions per-tenant or per-route and gives customers a notice window before changing the underlying model. A vendor that silently rotates models leaves the customer exposed to behavior changes that affect compliance posture.

3. What contractual terms with the model provider prevent customer data from being used for model training?

Most major model providers offer enterprise-tier APIs with no-training guarantees. The vendor's contract should reference the specific term. A vendor that cannot point to the specific clause is operating on assumption.

4. Are customer prompts and responses subject to the model provider's retention?

The answer depends on the provider contract, and both major providers changed their published position during 2025 and 2026, so a vendor quoting an older figure is quoting a stale one.

OpenAI retains API inputs and outputs for up to 30 days by default for abuse monitoring. Zero data retention is available for eligible customers on eligible endpoints, subject to prior approval and applied at the project level, so it holds only where a vendor has actually been approved and has configured it (OpenAI data controls).

Anthropic does not retain conversation content by default on the Claude API, and offers a ZDR arrangement enabled per organization. The exclusions matter more than the headline. Batch processing holds jobs for 29 days, the Files API holds files until deleted, code execution containers hold data up to 30 days, the MCP connector falls outside ZDR entirely, and content flagged by trust and safety systems can be held for up to 2 years regardless of arrangement (Anthropic API and data retention).

The procurement lesson generalizes past both vendors. Retention is now set per feature rather than per provider, so a vendor that answers with a single number for its whole stack has not read its own contract. Ask which features the service uses, then ask for the retention on each.

5. How does the vendor isolate tenants at the model call layer?

The vendor either uses per-tenant API keys, per-tenant deployments, or shared keys with logical isolation. The latter pattern carries the most cross-tenant risk. Ask for the isolation diagram.

6. Can the customer route AI traffic through the customer's own provider account?

A vendor that allows BYO model account (the customer brings their own OpenAI workspace, their own Bedrock account, etc.) puts the customer in direct control of the model provider's data terms. A vendor that requires its own model account makes the customer dependent on the vendor's contract with the provider.

Category 2: Identity and authorization (Questions 7-12)

7. How does the service receive and verify the end-user identity making a request?

Most AI services receive an API key from the customer application, with the end-user identity passed as a payload field. Verification depends on the customer trusting the application to forward the identity correctly. Ask whether the vendor supports OIDC, SAML, or signed identity tokens that the vendor verifies directly.

8. What identity attributes are available for policy decisions?

The richer the identity context, the more granular the policy. A vendor that only sees a tenant ID and a user ID cannot enforce role-based or department-based policy. A vendor that consumes the customer's SSO claims (role, department, clearance) can enforce policy at the granularity the customer needs.

9. How does the vendor enforce least privilege at the AI request layer?

The answer should describe the per-route, per-role policy model the vendor implements. A vendor that says "we follow least privilege" without specifying the policy primitives is using a phrase, not a control.

10. How does the service handle service-account and agent identities?

Agent identities are the operative pattern in agentic deployments. The vendor should describe how it treats agent identities, what authorization model applies, and how it distinguishes an authenticated agent from a compromised one.

11. What is the authentication mechanism between the customer application and the service?

The answer should reference an industry-standard authentication pattern: mTLS, OAuth 2.0 with rotating tokens, signed JWT with short expiry. API keys without rotation are a procurement red flag.

12. How are administrative actions on the vendor's service authenticated and audited?

The vendor's administrative actions are the highest-risk path. The answer should describe MFA-required administrative access, separate-channel audit logs for admin actions, and SCIM-based access provisioning.

Category 3: Per-decision audit and traceability (Questions 13-18)

13. For each AI request, what is captured in the audit record?

The defensible record includes the requester identity, the policy version in force, the data classification of the prompt, the model called, the decision outcome, and a timestamp. A vendor that records only "request processed" produces evidence that fails the EU AI Act Article 12 traceability test.

14. Are the audit records tamper-evident?

Tamper-evident records carry a cryptographic signature or a hash chain that lets an inspector confirm the record has not been modified. The defensible answer references the specific tamper-evidence mechanism. "We use append-only storage" is a weak proxy, because the storage layer's guarantees say nothing about what the writer put there. Audit log immutability covers the mechanisms worth accepting.

15. Who has write access to the audit records?

If the application that produces the AI decision also writes the audit log, the customer has a self-attestation problem. The defensible architecture separates the write path from the application. The audit record exists regardless of what the application does after the fact.

16. How long are audit records retained, and who controls the retention period?

Retention should be a customer-configurable policy. Six months is the floor EU AI Act Article 26 sets for deployer logs. HIPAA's Security Rule documentation requirement runs six years under 45 CFR 164.316(b)(2)(i). Financial-services regimes often require longer, and the vendor should support the customer's regulatory regime rather than a single default.

17. Can the customer export the raw audit records?

The customer needs the ability to export records for regulatory inspection, internal audit, or migration. A vendor that locks audit records inside its own dashboard creates a single point of failure for compliance evidence.

18. Does the audit record include the policy state at the moment of the decision?

The policy state at the moment of decision is the difference between a defensible record and a useless one. A record that captures "request blocked" without the policy that made the block cannot reconstruct the decision under inspection. The defensible record pins the policy version to each decision.

Category 4: Policy enforcement and prompt-injection handling (Questions 19-24)

19. What policy primitives does the service expose?

The primitives are the building blocks the customer's compliance team will reason with. The defensible set includes per-route policy, per-role policy, per-data-classification policy, per-model-target policy, and per-tenant policy. A vendor with only on-off enforcement at the tenant level is operating at a coarse granularity.

20. How does the service handle policy ambiguity or evaluation failure?

The defensible posture is fail-closed: when the policy evaluation cannot complete, the request is denied. The reader should ask for the specific default and the configuration options. Fail-open defaults are a procurement red flag.

21. How does the service detect and respond to prompt injection?

The defensible answer includes signal-level detection (classifiers, pattern matching), policy-level enforcement (data classification escalation, route fail-closed), and audit-level evidence (the detection signal recorded with the decision). A vendor that says "our model is fine-tuned to resist prompt injection" is relying on the model rather than enforcing at the request layer.

22. How does the service handle indirect prompt injection in retrieved content?

The retrieved content path is the most common indirect injection surface. The defensible answer describes a content classification step on retrieved data, with the classifier output feeding the policy decision. A vendor that processes retrieved content without classification is exposed. Ask specifically whether the classification runs on the retrieved chunk before it enters the prompt, since running it on the final response catches the damage after the model has already acted.

23. What is the latency overhead of the policy enforcement?

For a real-time deployment, the latency budget for enforcement is typically under 100ms. The vendor should be able to cite a specific number from internal benchmarking, and the customer should be able to verify it in a proof-of-concept.

24. Can the customer bring its own policy?

Customer-authored policy is the path to a defensible compliance position. The customer's compliance team should be able to express the policy in a primitive the vendor implements, without relying on the vendor to interpret the regulatory regime correctly. A vendor that only supports vendor-curated policy leaves the regulatory interpretation in vendor hands.

Category 5: Data residency and processing locations (Questions 25-29)

25. In which geographies is the customer data processed?

The defensible answer is specific by region and by data type. A vendor that says "we operate in multiple regions" leaves the customer exposed to data localization regimes like the EU AI Act, the Data Protection Act in the UK, and sector-specific rules.

26. Can the customer pin processing to a specific region?

EU customers typically need EU-only processing, especially under the EU AI Act high-risk regime. The vendor should support region pinning at the model-call layer, the audit-storage layer, and the support-access layer. The third one gets skipped most often: a vendor pinned to Frankfurt whose support engineers read customer prompts from Bangalore has an unpinned path through its own help desk. Data residency controls covers the enforcement points.

27. Does the model provider's data processing also stay in the pinned region?

A vendor that pins its own processing to the EU but calls a model API that processes in the US has not satisfied region pinning. The vendor should be able to demonstrate the model call routes to a region-aligned endpoint.

28. What is the data classification taxonomy the service applies to prompts and responses?

The defensible taxonomy includes PII, PHI, payment card data, source code, intellectual property, and customer-defined classes. A vendor that classifies only on a "sensitive / not sensitive" binary cannot support most regulated workflows.

29. How does the service handle data subject rights under GDPR for prompts that contain personal data?

The defensible answer describes the process for handling access, rectification, erasure, and portability requests against data that flowed through prompts. The audit records support the process; a vendor without per-decision records cannot satisfy the rights without manual reconstruction.

Category 6: Regulatory alignment (Questions 30-34)

30. How does the service support EU AI Act Article 12 traceability?

The defensible answer references the per-decision audit records, the retention configuration, the export capability, and the deployer-vs-provider obligation split. A vendor that says "we are EU AI Act ready" without specifying the Article 12 mechanism is producing a marketing answer.

31. How does the service support HIPAA audit requirements for AI-mediated decisions on PHI?

The defensible answer references the BAA, the per-decision audit records that include PHI access metadata, the six-year retention, and the access controls that align with the HIPAA Security Rule.

32. How does the service support the NIST AI Risk Management Framework?

The defensible answer maps the service's capabilities to the GOVERN, MAP, MEASURE, and MANAGE functions, with specific reference to which artifacts the service produces for each function.

33. How does the service support Fannie Mae LL-2026-04 governance requirements for AI-supported lending decisions?

The defensible answer (for vendors selling into lending) references the per-decision records the lender needs to demonstrate AI-supported decisions and the policy enforcement that bounds the AI's influence on the decision.

34. What is the vendor's position on state-level AI legislation (Colorado SB 189, Texas TRAIGA, California SB 942)?

The three acts sit at three different stages, and a vendor answering about all of them in one sentence is not tracking any of them.

• Colorado SB 189: signed 14 May 2026, effective 1 January 2027. Asks vendors for disclosure and transparency around automated decision-making systems.
• Texas TRAIGA: in force since 1 January 2026, with civil penalties and Attorney General enforcement.
• California SB 942, as amended by AB 853: covered-provider obligations operative 2 August 2026, requiring latent and manifest disclosures and a public AI-detection tool.

Colorado deserves specific attention because the answer a vendor gave last year is now wrong twice over. SB 25B-004 pushed the original 1 February 2026 date to 30 June 2026. SB 189 then moved it again to 1 January 2027 and rewrote the substance, dropping the duty of care against algorithmic discrimination, the deployer risk-management programs, the impact assessments, and several Attorney General reporting obligations in favour of a narrower disclosure regime (Hunton analysis of the amendment).

A vendor that built its Colorado story around impact assessments has a product feature aimed at a requirement that no longer exists. Ask what changed in the roadmap after 14 May 2026. The answer separates monitoring from marketing.

California's AB 853 also moved SB 942's operative date from 1 January 2026 to 2 August 2026, with large online platforms phased in on 1 January 2027 and capture-device manufacturers on 1 January 2028. A vendor still quoting the January 2026 date is reading a superseded source.

Category 7: Incident response (Questions 35-38)

35. What is the vendor's incident response process for an AI-layer compromise?

The defensible answer references the AI-layer incident classes (prompt injection in production, indirect prompt injection, agent tool-call escalation, model extraction, LLM-driven post-exploitation), the detection signals, the containment actions, and the customer notification timeline.

36. How is the customer notified of an incident affecting the customer's data or workloads?

The notification timeline should be specified by SLA in the contract. The notification channel should be more reliable than email-only. The customer should receive enough detail to begin its own incident response.

37. How does the vendor coordinate with the customer's SOC during an incident?

The defensible answer references a runbook, a contact path, and the data the vendor can share with the customer's SOC during an incident. A vendor without a SOC coordination plan delays the customer's response.

38. What is the vendor's process for post-incident review and customer post-mortem?

The defensible answer includes a written post-mortem within a specified time window, with the root cause, the remediation, and the changes the vendor will make to prevent recurrence. Post-mortems are part of the vendor's evidence trail and should be available to the customer's audit and compliance teams.

AI on both sides of the questionnaire

By 2026 the questionnaire itself runs through AI at both ends, which changes what the answers are worth.

On the vendor side, response tools draft answers by retrieving from a corpus of past questionnaires, policy documents, and SOC 2 reports. A well-written answer therefore tells you the vendor has a document corpus and a tool. It says nothing about whether the control exists. Procurement teams who used fluency as a maturity signal have lost that signal, and the replacement is to ask for the artifact instead of the assertion.

Four requests that a retrieval tool cannot fake:

• A sample audit record for a single AI decision, with values redacted and field names intact.
• Whichever policy file produced a block, in the format the vendor's own system consumes.
• Configuration showing fail-open or fail-closed behaviour as set in the running environment.
• The last AI-layer incident post-mortem, or a written statement that none has occurred.

On the buyer side, scoring 38 answers across a slate of vendors is the kind of work an LLM handles well. A prompt that produces a usable score names the evidence standard rather than asking for an opinion. Give the model the question, the vendor's answer, and instructions along these lines: classify the answer as artifact-backed, specific-but-unevidenced, or generic; quote the exact span that carries the specificity; name the follow-up request that would convert the answer to artifact-backed; withhold a score where the answer cites a document you have not been given. Run it per question rather than per vendor, so a strong answer in one category cannot carry a weak one in another.

Both directions carry a governance consequence people miss. Pasting a vendor's completed questionnaire into a public chat assistant sends third-party confidential material to a model provider under whatever terms that assistant carries, and it happens inside procurement teams that would block the same file at the email gateway. The traffic is ordinary HTTP to an LLM endpoint, which means it is visible to the same controls that cover the rest of your AI use, and invisible without them. Finding shadow AI covers the discovery side.

DeepInspect

This is the architecture DeepInspect is built on. DeepInspect sits at the AI request boundary as a stateless proxy between authenticated users or agents and the LLM endpoints, enforces identity-bound policy on every request, and records per-decision audit records with policy version, identity context, data classification, and decision outcome.

For procurement teams running an AI vendor security review, DeepInspect answers the questions that touch the AI request boundary: named model providers and pinned versions, signed identity tokens, customer-authored policy, tamper-evident per-decision records, and region pinning at the model-call layer. Questions about a vendor's internal practices, support access, tenant isolation, retention inside the vendor's own stack, post-mortems, are each vendor's to answer about itself, and the questionnaire above is built to surface them.

If you are running the procurement gate on an AI deployment and the questions above surface gaps in the vendor's answers, those gaps are the finding. Book a demo today.

Beyond the questionnaire

The questionnaire is not the end of the procurement gate. The defensible procurement process includes a proof-of-concept that runs the vendor's service against the customer's own traffic, an audit-evidence review that confirms the audit records meet the customer's regulatory regime, and a contractual review that pins the data terms, the retention, the region, and the incident response SLA.

The vendor's answers to the questionnaire are the input to the process. The proof-of-concept and the contract are where the answers get tested.