Pyralink™ Prove It · Secure AI Toolkit · pyralink.co.uk/newsletter/toolkit/ai-vendor-security-questionnaire · Last reviewed 31 October 2026. General information, not legal advice.
Send these questions to any supplier whose AI tool or AI feature will touch your data, or will take actions in your systems. Adapt the length to the risk: a tool that only sees public information needs far fewer questions than one connected to your mailbox, code or customer records.
For every answer, ask for evidence you can check (a policy, a report, a contract clause, a settings screenshot) rather than a statement of intent. Keep the answers: they are your record of due diligence.
Not legal advice. This is a general-purpose questionnaire. It is not a substitute for the checks your contracts, regulator or insurer require. Take legal advice on contract terms and data protection roles.
Supplier: ______________ Product: ______________ Date: ______________ Assessed by: ______________
A. Who they are and how they govern AI
| # | Question | A good answer looks like | Red flags |
|---|---|---|---|
| A1 | Who owns and operates the service, and in which countries do they operate? | Named legal entity, clear ownership, a security contact | Vague answers, no legal entity named |
| A2 | Who is accountable for AI security on your side, and what do they report to? | A named role with senior reporting | "Everyone is responsible" |
| A3 | Which AI models do you use: your own, or third-party? Which providers? | A clear list, including any sub-processors that see our data | "We can't say" |
| A4 | Do you follow a recognised secure AI approach (for example the NCSC guidelines for secure AI system development, the UK AI Cyber Security Code of Practice, ETSI EN 304 223, ISO/IEC 42001, or the NIST AI RMF)? | Specific: which parts, how they were assessed, and evidence | Names a standard but cannot say what they do |
| A5 | What is your policy if our data or use is the subject of a regulator enquiry or legal request? | A documented process and notification commitment | No process |
B. Our data
| # | Question | A good answer looks like | Red flags |
|---|---|---|---|
| B1 | What data does the tool collect and keep: prompts, files, outputs, metadata, logs? | A data map, with retention periods | "Everything, for as long as needed" |
| B2 | Is our data used to train or improve models, yours or anyone else's? Can we switch that off, and is that the default for our plan? | Clear: no training on our data by default, or an enforceable opt-out in the contract | Training on by default with no contractual protection |
| B3 | Where is our data processed and stored? Which sub-processors can access it? | Named locations and a current sub-processor list with a change-notification process | No list, or changes without notice |
| B4 | Who at the supplier can see our prompts and outputs, and under what conditions? | Access limited, logged and justified | Broad staff access, no logging |
| B5 | How long do you keep our data, and how do we delete it? What happens to backups and logs? | Documented retention, self-service or on-request deletion with confirmation | "We never delete" |
| B6 | If you are acquired or change ownership, what happens to our data? | Contractual commitments carry over | Not addressed (the NCSC highlights ownership change as a risk for stored queries) |
C. Security controls
| # | Question | A good answer looks like | Red flags |
|---|---|---|---|
| C1 | Do you support single sign-on and multi-factor authentication for all users, and can we enforce them? | Yes, included in the plan we are buying | Only on top-tier plans, or optional with no enforcement |
| C2 | What roles and permissions exist? Can we limit who can use which features, connectors and agents? | Granular roles, admin controls and audit trails | One shared admin role |
| C3 | How is data encrypted in transit and at rest, and who holds the keys? | Modern encryption, key management described | Cannot describe |
| C4 | Which independent assurance do you hold and can share (for example a recent ISO/IEC 27001 certificate with its scope, or a SOC 2 Type II report)? | Current reports, scope covers this product | Logo only, out-of-date, or scope excludes the product |
| C5 | How do you find and fix vulnerabilities? How quickly do you patch critical issues? Do you run independent penetration tests? | A process, target timelines and a recent test summary | No testing, no timelines |
| C6 | How do you protect your own build pipeline and dependencies? (for example pinned, verified dependencies, signed releases, protected credentials) | Specific controls and a response plan for supply-chain incidents | "We trust our open-source packages" |
| C7 | What logs do we get access to? (sign-ins, admin changes, prompts, tool calls, data exports) | Exportable logs, retention you can set | No customer-visible logs |
D. AI-specific security
| # | Question | A good answer looks like | Red flags |
|---|---|---|---|
| D1 | How do you defend against prompt injection, including instructions hidden in documents, web pages and emails that the tool reads? | Layered design: least privilege, limits on what the model can do, human approval for risky actions, monitoring. Honest that it cannot be eliminated | "Our filter blocks it" |
| D2 | If the tool can take actions (send, edit, buy, run code), what can it do by default? Can we limit it? Which actions need human approval? | Least privilege by default, per-action controls, approvals | Broad permissions by default |
| D3 | How is the model's access to our connected data limited (mailbox, drives, repositories, CRM)? | Scoped connectors, our permissions respected, no cross-customer mixing | Admin-level connectors for all |
| D4 | How do you stop one customer's data appearing in another's results? | Tenant isolation described and tested | Cannot explain |
| D5 | How do you handle model output before it is used by other systems or shown to users? | Output is treated as untrusted and validated | Output executed directly |
| D6 | Do you test for AI-specific attacks and misuse? How often, by whom, and can we see a summary? | Regular adversarial testing, summary of findings shared | No testing |
| D7 | How do you manage model and data supply chain risk: provenance of models, training data and plug-ins? | Documented provenance, review of third-party components | Unknown |
| D8 | How do we switch the AI features off, limit them to some users, or shut down an agent quickly? | Admin controls and documented emergency shutdown | Not possible |
E. Legal and compliance
| # | Question | A good answer looks like | Red flags |
|---|---|---|---|
| E1 | Will you sign a data processing agreement that reflects UK GDPR requirements? Which transfer mechanism applies for international transfers? | Yes, with a clear transfer mechanism | Refusal or "our terms cover it" |
| E2 | Who is the controller and who is the processor for each type of processing in your tool? | A clear position per activity. (The ICO has said controller status can follow from who decides the means of processing.) | Contradictory answers |
| E3 | If the EU AI Act applies to the product, what is your role (provider or deployer) and what is your compliance position and timeline? | A specific, current answer | "Not applicable" without explanation |
| E4 | Do you have intellectual property terms covering inputs and outputs? Do you indemnify for claims over outputs? | Clear terms | Silence |
| E5 | Which security and AI-related changes will you notify us of, and how? | Contractual change-notification | None |
F. Incidents and exit
| # | Question | A good answer looks like | Red flags |
|---|---|---|---|
| F1 | How and when will you tell us about a security incident or data breach? What is the contractual notification deadline? | A defined short deadline, a named contact, a tested process | "As soon as reasonably practicable" with no process |
| F2 | Have you had a security incident in the last three years that affected customer data? What changed? | Honest, specific answer | Evasion |
| F3 | If our credentials or API keys for your service are exposed, how do we revoke and rotate them quickly? | Self-service rotation, usage alerts, spend limits | Manual, slow |
| F4 | How do we leave? Can we export our data and configuration, and when is it deleted? | Documented export and deletion with timelines | Lock-in, fees or no export |
| F5 | What is your business continuity position if you or your model provider has an outage? | Documented, tested | No plan |
Scoring and decisions
Do not turn this into a number you cannot defend. A simple traffic-light summary works well:
- Green: the answers are specific, evidenced and consistent. Proceed, with the conditions you have noted.
- Amber: gaps you can live with if the use is limited (for example, only public or low-sensitivity data) or the supplier commits to close them.
- Red: gaps on data use, access control, incident notification or exit that you cannot accept for the data involved. Do not proceed for that use.
Record the decision, who made it, and the conditions (for example "no personal data", "agents disabled", "review in 6 months").
Sources
- NCSC, Guidelines for secure AI system development (27 November 2023).
- UK DSIT, AI Cyber Security Code of Practice, and ETSI, EN 304 223 announcement (14 January 2026).
- NCSC, ChatGPT and large language models: what's the risk? (14 March 2023): provider visibility of queries, ownership changes, cloud-provided LLM questions.
- NCSC, Prompt injection is not SQL injection (it may be worse) (8 December 2025).
- NCSC, Managing the cyber risk of agentic AI (20 August 2026).
- OWASP, Top 10 for LLM Applications.
- ISO, ISO/IEC 42001:2023. NIST, AI RMF.
- Freshfields, AI agents and UK data protection law (22 October 2026): summary of the ICO's controller position.
Get one practical fix every Monday
Pyralink™ Prove It is a free weekly email on cloud and AI security, with a link for every claim.
Subscribe by email