EU AI Vendor Security Questionnaire: 45 Questions Before You Sign

An AI vendor security questionnaire should do more than collect policy links. It should force the supplier to name the data path, produce evidence, accept contract controls and identify who carries each EU AI Act responsibility. The 45 questions below turn those requirements into a procurement decision.

Use this after you have a real use case and a shortlisted supplier. It is a procurement artifact, not a legal classification tool. Our EU AI Act cost guide explains the regulation, while our EU data residency guide maps where AI data can travel. This page tests whether one vendor can meet your operating and contractual requirements.

Use the indexable checklist here, or take it into procurement

The HTML page is the complete and canonical version. The spreadsheet adds owners, status, evidence links, scores and decision notes.

 Download the multilingual spreadsheet

How to score an enterprise AI vendor assessment

Score the answer, the evidence and the contract together. A polished policy with no product evidence is not a pass. This scoring model is a Wavect procurement aid, not a regulatory standard. If your team needs an independent technical review, our AI enablement service can turn the evidence into a risk register and contract-ready decision.

• 76 to 90: procurement candidate, subject to legal, security and business approval.
• 58 to 75: conditional approval only with named remediation, an owner and a deadline.
• 0 to 57: pause. The buyer is accepting too much unpriced risk.
• Any hard stop overrides the total score.

Eight hard stops before signature

• Customer content can be used for training or evaluation without explicit opt-in and a binding exclusion.
• The vendor cannot identify every processor, subprocessor, model provider and hosting region in the data path.
• Sensitive prompts or outputs are retained indefinitely, or deletion excludes logs, backups, embeddings or fine-tunes without a justified limit.
• The service lacks tenant isolation, least-privilege administration or the identity controls your risk tier requires.
• Material model, safety, region or subprocessor changes can happen without notice, re-evaluation or rollback.
• Incident notification has no contractual clock, minimum content or evidence-preservation duty.
• The vendor has no representative use-case evaluation or refuses to disclose methods, versions, limits and results.
• The parties cannot agree who is provider, deployer or another actor under the EU AI Act for the intended use.

Training and retention of customer data: Questions 1 to 4

A no-training claim is too narrow if feedback, abuse monitoring, human review or a subprocessor can still reuse customer content. Ask about every data class and every copy, including any fine-tuning workflow.

1. Are prompts, files, outputs, feedback or telemetry used to train, fine-tune, distil or evaluate any model, including by a subprocessor?

Evidence to request: A data-use matrix by data class, purpose, model and receiving party, plus the current product setting and policy version.

Put in the contract: No customer-content use beyond delivering and securing the service unless the customer gives separate, explicit opt-in consent.

2. Is model-improvement use off by default, and at what level can the buyer enforce the setting?

Evidence to request: Screenshots or API documentation for organisation, workspace, project and endpoint controls, with an administrator test.

Put in the contract: The exclusion applies to every account, API, support channel and future feature under the agreement.

3. What are the default and configurable retention periods for prompts, outputs, uploads, embeddings, logs, backups and abuse-monitoring copies?

Evidence to request: A retention schedule that separates live systems, logs, caches, backups, support tickets and safety review queues.

Put in the contract: Maximum periods, permitted purposes and any non-configurable exception are written into the DPA or order form.

4. Can the vendor prove that the promised data-use and retention settings are effective for this tenant?

Evidence to request: Tenant configuration export, control test, audit result or signed attestation tied to the contracted service tier.

Put in the contract: A misconfigured or bypassed exclusion is a security incident, with correction, notice and deletion duties.

Subprocessors: Questions 5 to 7

The EDPB says controllers should have the identity of all processors and subprocessors readily available and must assess whether they provide sufficient guarantees. A generic category list is not enough for a real data path.

5. Who are all processors and subprocessors, what does each one do, where are they established and which data can they receive?

Evidence to request: A current register with legal name, address, service, country, data categories and processing location.

Put in the contract: The register is incorporated by reference and must remain complete for the services in scope.

6. How much advance notice is given before adding or replacing a subprocessor, and can the buyer object or terminate?

Evidence to request: The notification workflow, notice history and a sample change notice.

Put in the contract: A defined notice period, a reasoned objection process and a no-penalty exit if no reasonable alternative exists.

7. Do equivalent security, confidentiality, transfer, assistance and deletion duties flow down the full chain?

Evidence to request: Relevant contract extracts, independent assurance scope and evidence that the vendor monitors critical subprocessors.

Put in the contract: The vendor remains liable for its subprocessors and provides evidence needed to demonstrate compliance.

Model and infrastructure location: Questions 8 to 10

A storage-region promise does not answer where inference, logging, support access or disaster recovery occurs. Map the complete request path using the controls in our EU AI data residency guide.

8. In which countries do inference, storage, logging, backup, support and failover occur?

Evidence to request: An architecture and data-flow diagram with named services, regions and cross-region replication paths.

Put in the contract: Approved locations are listed by processing activity, not described only as EU available.

9. Can the region be locked, and under which support, safety or disaster-recovery conditions can data leave it?

Evidence to request: Configuration documentation, tested routing behaviour and the exception procedure.

Put in the contract: No location change or remote access outside approved countries without a documented legal mechanism and agreed controls.

10. What is the exact model, gateway, cloud and support chain, and which transfer mechanism covers every non-EEA leg?

Evidence to request: Supplier chain, transfer impact assessments where relevant, SCC modules and supplementary measures.

Put in the contract: The vendor maintains valid transfer documentation and notifies the buyer if a mechanism or destination changes.

Prompt and output logging: Questions 11 to 13

Logging can support security and auditability while creating a second sensitive dataset. Separate content from operational metadata and define access.

11. What exactly is logged at the application, gateway, model-provider and infrastructure layers?

Evidence to request: A field-level log schema showing payloads, metadata, redaction, hashing and correlation identifiers.

Put in the contract: Only agreed fields and purposes may be logged, with sensitive-field redaction before persistence.

12. Can prompt and output content logging be disabled while retaining necessary security and operational telemetry?

Evidence to request: A tenant-level control test and examples of the resulting logs.

Put in the contract: The chosen logging mode and any mandatory safety exception are fixed for the service tier.

13. Who can read prompt and output logs, for which purpose, with which approval and for how long?

Evidence to request: Role matrix, privileged-access workflow, access review and sample audit record.

Put in the contract: Named access purposes, least privilege, review frequency and retention apply to vendor staff and subprocessors.

Permissions: Questions 14 to 17

Enterprise AI inherits the permissions of every source and tool it can reach. A strong model behind weak identity controls is still a weak system, especially when RAG permissions span SharePoint, Confluence or Drive.

14. Does the service support the required SSO, MFA, SCIM and role-based access controls?

Evidence to request: A feature demonstration, role catalogue and test of joiner, mover, leaver and emergency-access workflows.

Put in the contract: Required identity features are included in the purchased tier and cannot be removed during the term.

15. How is tenant isolation enforced and tested across storage, retrieval, caches, fine-tunes and support tools?

Evidence to request: Isolation design, penetration-test scope, test results and encryption-key architecture.

Put in the contract: Cross-tenant access is a security incident, and critical isolation controls are subject to independent testing.

16. Are source permissions preserved through RAG, connectors, caches, generated links and exports?

Evidence to request: A negative-permission test showing that revoked or unauthorised content cannot be retrieved, cited or exported.

Put in the contract: Retrieval must enforce current source permissions before search results reach the model.

17. Can API keys, agents and service accounts be scoped, rotated, revoked and attributed to an owner?

Evidence to request: Key-management controls, scope model, rotation log and usage attribution.

Put in the contract: No shared unowned credentials; rotation and revocation deadlines match the buyer's security policy.

Audit logs: Questions 18 to 20

The buyer needs enough traceability to investigate an outcome, prove a control and meet any applicable retention duty without turning the audit trail into unlimited surveillance.

18. Which authentication, configuration, data-access, model, policy and administrative events appear in the audit trail?

Evidence to request: A sample export covering logins, role changes, connector access, model changes, safety settings and administrator actions.

Put in the contract: The agreed event catalogue remains available and materially complete for the term.

19. Do events include reliable time, actor, tenant, action, object, result, before-and-after values and a correlation ID?

Evidence to request: A field-level sample that reconstructs one prompt or action from request to outcome.

Put in the contract: Clock synchronisation, integrity protection and privileged-log access controls are maintained.

20. Can the buyer export logs to its SIEM and retain them for the required period?

Evidence to request: API or streaming documentation, export test, rate limits and retention configuration. For applicable high-risk systems, test whether the buyer can keep provider-generated logs for at least six months.

Put in the contract: Access, export format, latency and retention match the buyer's incident and regulatory obligations.

Model changes: Questions 21 to 23

A silent model update can invalidate an evaluation, change output behaviour or alter the legal and security profile. Treat model change like a production dependency change.

21. Which model, system-prompt, safety, region and subprocessor changes trigger advance notice?

Evidence to request: Change policy, release notes and examples of past notices tied to materiality criteria.

Put in the contract: A defined notice period applies to changes that can affect performance, risk, data flow or compliance.

22. Can the buyer pin a version, test a canary, approve rollout and roll back?

Evidence to request: Versioning API, deployment workflow and a demonstrated rollback with preserved logs.

Put in the contract: Critical workflows receive a supported validation window and rollback path.

23. What compatibility and deprecation window applies, and what re-evaluation evidence accompanies a material change?

Evidence to request: Support policy, migration guide, delta evaluation and known-limitations update.

Put in the contract: No forced material migration before the agreed test window, except for a documented urgent security reason.

Incident response: Questions 24 to 27

Traditional breach language may miss prompt injection, unsafe tool use, model corruption and harmful automated outcomes. Define AI incidents before one occurs.

24. What counts as an AI security or safety incident?

Evidence to request: An incident taxonomy covering data exposure, cross-tenant retrieval, prompt injection, tool abuse, harmful output, model or policy tampering, outage and unauthorised change.

Put in the contract: The definition covers confidentiality, integrity, availability, safety and fundamental-rights impact, not only confirmed personal-data breaches.

25. How quickly will the vendor notify the buyer, through which channel and with what minimum facts?

Evidence to request: Response plan, escalation tree, sample notice and severity-specific clocks.

Put in the contract: An initial notification deadline, named channel, minimum content and update cadence are explicit.

26. Will the vendor preserve evidence, support investigation and provide root-cause and corrective-action reports?

Evidence to request: Forensic retention procedure, chain-of-custody practice and a redacted post-incident report.

Put in the contract: Evidence preservation, cooperation, regular updates and a final report have defined deadlines.

27. How are response plans exercised, and what relevant incidents have occurred?

Evidence to request: Latest tabletop or simulation record, remediation tracking and disclosure of materially similar incidents within an agreed lookback period.

Put in the contract: Regular exercises and material control regressions are reportable assurance events.

Human review: Questions 28 to 30

A human-in-the-loop label means little unless the reviewer has time, information, authority and a real stop control.

28. Can authorised people review, override, stop and appeal an AI-assisted outcome?

Evidence to request: A workflow demonstration including a failed model output, escalation and safe shutdown.

Put in the contract: The service will not bypass mandatory approval gates or make an irreversible action before required review.

29. What information and training help reviewers understand limitations and avoid automation bias?

Evidence to request: Instructions for use, limitation notices, reviewer training and interface evidence that uncertainty is not presented as certainty.

Put in the contract: The vendor keeps instructions and training material current after material system changes.

30. Are review, override and escalation decisions recorded without collecting unnecessary personal data?

Evidence to request: Decision-log schema, access rules and privacy review.

Put in the contract: Records support accountability and appeal while following purpose limitation and retention controls.

Evaluation evidence: Questions 31 to 34

Generic benchmarks are not acceptance evidence. NIST's AI RMF calls for documented, repeatable testing in conditions similar to deployment and regular evaluation in operation. Define acceptable hallucination rates and budget for the recurring work described in our LLM evaluation cost and ROI guide.

31. Has the exact system been evaluated on representative tasks, languages, users and failure conditions for this use case?

Evidence to request: Test-set design, sampling rationale, model and prompt version, results, error analysis and limits.

Put in the contract: Production acceptance depends on agreed use-case tests, not a general model leaderboard.

32. Which metrics and thresholds cover quality, hallucination, bias, security, robustness, latency and cost?

Evidence to request: Metric definitions, baseline, confidence or uncertainty treatment, thresholds and current scorecard.

Put in the contract: Critical thresholds, monitoring frequency and remediation triggers are acceptance criteria or service levels.

33. Who performed the evaluation, and how independent were they from the delivery team?

Evidence to request: Reviewer roles, external assurance where proportionate, reproducible methods and access to material limitations.

Put in the contract: The buyer can review methods and receive enough evidence to reproduce critical tests without exposing unrelated trade secrets.

34. Has the vendor tested prompt injection, data exfiltration, unsafe tool use and model-specific abuse, and are tests rerun after changes?

Evidence to request: Threat model, red-team scope, findings, remediation and regression results on the current version.

Put in the contract: Critical AI security tests are repeated after material changes and unresolved high-risk findings block rollout.

Data deletion: Questions 35 to 37

Delete must cover the derived and operational copies created by an AI system, not only the original upload.

35. Can the vendor delete customer data from production, logs, embeddings, fine-tunes, caches, support systems and backups?

Evidence to request: Deletion map, system-specific timelines, backup expiry and tested deletion procedure.

Put in the contract: The scope, completion time and narrow exceptions are listed for every data store.

36. Can deletion target one data subject, record, workspace or tenant and propagate to subprocessors?

Evidence to request: Deletion API or operational workflow, subprocessor propagation and a sample completion trace.

Put in the contract: The vendor assists with relevant data-subject requests and confirms downstream completion.

37. What deletion evidence is provided, and how is deleted data prevented from returning through backup restore?

Evidence to request: Deletion certificate, exception register, restore controls and re-deletion procedure.

Put in the contract: Certification names scope, date, residual legal holds and the control applied to restored backups.

Exit and portability: Questions 38 to 40

The EU Data Act establishes switching duties for covered data-processing services. Even where its exact scope needs legal review, procurement should define what leaves, in which format, how fast and at what cost. Treat those answers as part of the buyer's technical due diligence record.

38. Can the buyer export inputs, outputs, configuration, prompts, evaluation sets, logs, metadata and other customer-controlled assets?

Evidence to request: A complete export sample and data dictionary in commonly used, machine-readable formats.

Put in the contract: Exportable categories and justified exclusions are exhaustively listed before signature.

39. Which APIs, tools, limits, timeframes, assistance and fees apply to switching?

Evidence to request: Exit guide, API documentation, volume test, estimated timeline and current fee schedule.

Put in the contract: Switching support, continuity, security, notice, retrieval period and charges comply with applicable law and agreed service levels.

40. Can the buyer run a safe transition, validate a replacement and delay deletion until export is confirmed?

Evidence to request: Exit-plan walkthrough covering read-only access, parallel run, model substitution, export validation and final deletion.

Put in the contract: A defined transition and retrieval window prevents lockout or premature erasure.

EU AI Act responsibilities: Questions 41 to 45

The AI Act allocates obligations by role and use, not by whichever party drafted the MSA. Article 25 can make a deployer or other third party the provider of a high-risk system after rebranding, substantial modification or a changed intended purpose.

41. For the intended use, which party is provider, deployer, importer, distributor, GPAI provider or downstream system provider?

Evidence to request: A signed responsibility matrix tied to the product, model, intended purpose and EU market route.

Put in the contract: Each duty has one accountable owner and named cooperation obligations.

42. What documented analysis covers prohibited practices, high-risk classification, Article 50 transparency and GPAI obligations?

Evidence to request: Current classification memo, assumptions, exclusions and version date, with counsel review where proportionate.

Put in the contract: The vendor must notify the buyer when a change could alter the analysis.

43. Will the vendor provide the information the buyer needs for instructions, logging, human oversight, limitations, incidents and downstream compliance?

Evidence to request: Instructions for use, technical documentation, model information, contact paths and sample compliance pack.

Put in the contract: Necessary information, capabilities, technical access and assistance are deliverables, with update duties.

44. Who operates post-market monitoring, serious-incident reporting, transparency controls, AI literacy and any required fundamental-rights assessment?

Evidence to request: Lifecycle responsibility map, procedures, trained owners and authority contact list.

Put in the contract: Notification and cooperation clocks leave the legally responsible party enough time to act.

45. What happens if branding, modification or intended-purpose changes shift provider responsibility to the buyer?

Evidence to request: Change-control scenario, substantial-modification assessment and handover package.

Put in the contract: No responsibility-shifting change without approval, updated documentation, technical assistance, cost allocation and an exit right.

How to turn 45 answers into a procurement decision

1. Run a 45-minute scope call first. Freeze the use case, data classes, users, tools, regions and impact before sending the form.
2. Ask the vendor to answer in the spreadsheet and attach evidence. Policy URLs alone score no higher than Partial.
3. Have security, privacy, legal, product and the operational owner review only the sections they can accept or reject.
4. Convert every gap you accept into a contract control, remediation item, owner and date.
5. Before production, test the five controls that matter most to your use case. Repeat after a material model or data-path change.

Why this questionnaire is evidence-based

The structure follows the EU AI Act's allocation of value-chain responsibilities, deployer oversight, logging and incident duties; GDPR processor-chain and deletion requirements; EU Data Act switching terms; NIST AI RMF testing and third-party risk practices; and ENISA's layered approach to AI cybersecurity. It deliberately asks for system evidence because a certification or policy cannot prove how your configured tenant behaves.

Primary sources and research basis

1. Regulation (EU) 2024/1689, the EU AI Act. Articles 12, 14, 15, 25, 26, 50, 72 and 73; value-chain responsibilities, logging, oversight, robustness, transparency, monitoring and incidents.
2. European Commission, AI Act overview and implementation timeline. Current Commission summary of provider, deployer, GPAI and transparency obligations, checked 17 July 2026.
3. Regulation (EU) 2016/679, the GDPR. Articles 28 and 32; processor contracts, subprocessors, audits, deletion or return, and security of processing.
4. EDPB Opinion 22/2024 on obligations following reliance on processors and subprocessors. Processor-chain identity, sufficient guarantees and transfer documentation.
5. EDPB Opinion 28/2024 on AI models. Anonymity, legitimate interest and consequences of unlawfully processed personal data in AI model development and use.
6. Regulation (EU) 2023/2854, the Data Act. Articles 23 to 30; contract, export, transition, retrieval, deletion and charge rules for switching covered data-processing services.
7. NIST AI Risk Management Framework Core. Third-party risk, human oversight, documented testing, independent assessment and production monitoring.
8. ENISA Multilayer Framework for Good Cybersecurity Practices for AI. Cybersecurity foundations, AI-specific controls and sector-specific controls across the AI lifecycle.