Key takeaways
- Standard vendor security questionnaires miss the risks that are specific to AI: prompt injection, excessive permissions for agents, model-provider data terms and output that changes records.
- The UK NCSC splits secure AI development into four stages: secure design, secure development, secure deployment and secure operation and maintenance. A useful questionnaire covers all four.
- Ask for evidence, not yes/no answers: a permissions table, a sample log, a prompt-injection test report, the sub-processor list.
- Data questions matter most for UK and EU buyers: where data is processed, which model providers see it, whether it is used for training and what the processor contract covers.
- Send the questionnaire before the build starts, so the answers shape the design rather than delay the launch.
The security questions to ask an AI vendor cover four areas: how the system is designed to resist misuse, how it is built and what it depends on, how it is deployed and who can reach it, and how it is monitored and updated once live. Add a fifth area for data protection. Ask for evidence with every answer, such as permission tables, logs and test reports, because AI-specific risks like prompt injection rarely show up in a standard vendor questionnaire.
This post gives you 30 questions you can send as they are, grouped by the four stages in the UK National Cyber Security Centre's Guidelines for secure AI system development, with notes on what a strong answer includes. For the wider vetting process, including contracts and pricing, see our guide to choosing an AI automation agency.
Why AI needs its own security questions
Your existing questionnaire still applies: hosting, encryption, access control, staff vetting, incident response. What it usually misses are the risks that come from the model itself and from what the system is allowed to do.
The OWASP Top 10 for LLM applications lists them. Prompt injection is first, sensitive information disclosure second, improper output handling fifth and excessive agency sixth. In practical terms: a supplier's invoice or a customer's email can contain text that tries to redirect the model, the system may expose data it should not, its output may change records without checks, and an agent may hold more permissions than its job needs.
The NCSC guidelines, published in November 2023, organize secure AI development into four stages: secure design, secure development, secure deployment, and secure operation and maintenance. We use the same four stages below, plus a data protection section for UK and EU buyers.
- 01Secure designUnderstand the risks, model the threats and decide what the system may and may not do.
- 02Secure developmentSecure the supply chain, document models and data, and manage technical debt.
- 03Secure deploymentProtect infrastructure and models, plan incident response and release responsibly.
- 04Secure operation and maintenanceLog and monitor, manage updates and share what you learn.
Source: NCSC, Guidelines for secure AI system development (November 2023)
BufferSol Technologies · buffersoltech.com
Secure design: 8 questions
- What is the system allowed to do on its own, and which actions require human approval? Ask for the list.
- Which systems does it connect to, and with what permissions for each? Ask for a permissions table showing read and write access per tool.
- What untrusted text does the system read (emails, documents, web pages, chat messages), and how is that text kept from changing the system's instructions?
- How is every model output checked before it changes a record, sends a message or triggers a payment?
- Have you done a threat model for this system? Can we see a summary?
- What happens when the system is unsure or fails repeatedly? Where does the case go, and with what context?
- Are there limits on volume, spend and the number of actions per task?
- Which framework does your design process follow (for example the NCSC guidelines, OWASP or the NIST AI RMF), and how does this system map to it?
A strong answer to questions 1 and 2 is a short table, not a paragraph. In our AI customer support agent, for example, the agent can look up orders and create return labels within policy, while refunds above a set threshold go to a person with a summary. That kind of boundary should be written down before the build and enforced in code.
Secure development: 7 questions
- Which model providers and model versions does the system use, and how is a version change tested before release?
- Which third-party libraries, frameworks and services are in the stack, and how are they kept up to date?
- Is there an evaluation set built from our real examples, and is it re-run before every release?
- Have you tested the system against prompt injection and other hostile inputs? Can we see the results?
- Where are prompts, configuration and evaluation data stored, and who can change them?
- How are secrets such as API keys and credentials stored and rotated?
- Is the code reviewed, version-controlled and stored in a repository we will own?
For question 11, ask what the evaluation set contains and how results are reported. Our enterprise knowledge assistant, for example, runs an evaluation suite that measures answer accuracy before each release.
Secure deployment: 7 questions
- Where is the system hosted: your cloud, ours or the model provider's? In which regions?
- How do users sign in, and does access follow our existing permissions (for example through single sign-on)?
- Can a user ever see data, documents or answers they would not be allowed to see in the source system?
- How are credentials scoped, so that each component holds only the access its job needs?
- What is your incident response process for an AI-specific incident, such as a successful prompt injection or an unexpected action?
- How will the system be rolled out: shadow mode, staged rollout or full launch?
- Can the system be switched off or limited quickly if something goes wrong? Who can do that?
Secure operation and maintenance: 4 questions
- What is logged for each run (inputs, tool calls, outputs, decisions, approvals), and for how long?
- Who monitors the system, which alerts exist, and what are the response times?
- How are model upgrades, prompt changes and rule changes tested and approved before they go live?
- How will you tell us about vulnerabilities or incidents that affect our system?
Data protection: 4 questions
- Which personal data does the system process, and is any of it sent to a model provider?
- Is our data used to train any model, by you or by the provider? Ask for the relevant contract terms.
- Who are your sub-processors, including model providers, and in which countries do they process data?
- Will you sign a data processing agreement that covers the terms UK GDPR Article 28 requires?
The ICO's guidance on what needs to be included in the contract lists the minimum terms for a controller-processor contract: processing only on documented instructions, a duty of confidence, appropriate security, rules on sub-processors, help with data subjects' rights, assistance to the controller, end-of-contract provisions, and audits and inspections.
What good answers look like
| Weak answer | Strong answer | |
|---|---|---|
| Permissions | The agent only has the access it needs | A table of every tool, read or write, with the approval rule for each |
| Prompt injection | The model provider handles that | Untrusted text is treated as data; test results with hostile inputs attached |
| Quality | We test thoroughly before launch | An evaluation set from your examples, re-run before every release, with scores |
| Logging | Everything is logged | A sample trace showing inputs, tool calls, outputs and approvals for one run |
| Training data | We don't train on your data | Contract clauses from each model provider, and the sub-processor list |
| Updates | We keep the models current | A written process: test on the evaluation set, review, staged release |
Source: BufferSol checklist, based on the NCSC guidelines and the OWASP Top 10 for LLM applications
BufferSol Technologies · buffersoltech.com
In each row, the strong answer includes something you can inspect. If a vendor cannot produce it, ask when they will have it, and make it a condition of launch.
How BufferSol answers these questions
On our own builds, the default design gives each component scoped tool access, puts approval steps in front of risky actions, redacts personal data where it is not needed and keeps full trace logs, so every action can be reviewed. For generative AI work we use enterprise API terms that exclude client data from model training, and we can deploy in the client's own cloud account or with self-hosted models when that is required. We sign NDAs and data processing agreements on request.
In the US, the NIST AI Risk Management Framework is a common shared vocabulary for these conversations. It is voluntary and organizes risk work into four functions: govern, map, measure and manage. Many security teams find it useful to map vendor answers onto those four functions.
If you want help using this questionnaire in your vendor reviews, or want us to answer it for a system you are planning, our AI agents, generative AI and autonomous workflows teams can help. You can also talk to an engineer.
Frequently asked questions
Why isn't our standard vendor security questionnaire enough for AI?
Standard questionnaires cover hosting, access control, encryption and incident response, which still matter. They usually miss the AI-specific risks: text in emails or documents trying to redirect the model, agents holding more permissions than their job needs, model outputs changing records without checks, and data passing to model providers under their own terms. Add an AI section rather than replacing what you have.
Which AI security frameworks should a vendor follow?
There is no single mandatory standard for most business AI systems. Useful references include the UK NCSC's Guidelines for secure AI system development, the OWASP Top 10 for LLM applications and the NIST AI Risk Management Framework. Ask the vendor which they use and how their process maps to it, then check the answers against evidence such as test reports and permission tables.
When should we send an AI security questionnaire?
Before the build starts, ideally during discovery. The answers shape design decisions such as where the system is hosted, which model providers are used, which actions need approval and how logs are kept. Sending it after the build often means rework or a delayed launch. Share it alongside the data processing agreement so legal and security review happen together.
Sources
- Guidelines for secure AI system development, National Cyber Security Centre (UK)
- 2025 Top 10 Risk & Mitigations for LLMs and Gen AI Apps, OWASP Gen AI Security Project
- What needs to be included in the contract?, Information Commissioner's Office
- AI Risk Management Framework, NIST
Cite this article
BufferSol Editorial Team (2026). AI Vendor Security Questionnaire: 30 Questions to Ask Before You Sign. BufferSol Technologies. https://buffersoltech.com/blog/ai-vendor-security-questionnaire
BufferSol Editorial Team
AI & software engineering team
Senior engineers, AI specialists and product leads at BufferSol Technologies who design, build and run AI agents, autonomous workflows and custom software for companies in the US, UK and Europe.
