2 tables · 10 columns
Workflow process map template
One row per handoff: who does it, what goes in and out, the system, touch time and wait time.
AI vendor security questionnaire
This AI vendor security questionnaire lists 40 neutral questions to ask any AI vendor, including us: data handling, model providers, approvals, logging, testing and exit. It is for security, legal and operations reviewers. Put the vendor's name on it, send it, then rate each answer and ask for evidence.
At a glance
- Format
- 40 questions · 7 columns
- Best for
- Security, legal, procurement and operations reviewers assessing an AI vendor
- Copy as
- CSV, tab-separated for Sheets, or Markdown
- Last updated
- October 16, 2026
The template
Send the questions to every vendor you shortlist, us included. Our own answers on data, models and approvals are on the trust center.
AI vendor security questionnaire
Free to copy. No email and no download.
CSV and Sheets copies hold the fill-in tables. The Markdown copy includes the guides.
- Vendor
- Legal name.
- Product or service
- What exactly is in scope.
- Use case and data
- What it will do and what data it will see.
- Reviewer and date
- Who rated the answers, and when.
Questions
Fill inSend everything except the last column to the vendor. Keep your rating private.
| ID | Question | Why we ask | A good answer includes | Vendor responseYes, Partly, No or N/A, plus a line. | EvidenceDocument name or link. | Your ratingMeets, Partly, Gap or Dealbreaker. |
|---|---|---|---|---|---|---|
| A. Scope and use case | ||||||
| A1 | What will the system do with our data, step by step? | Every other answer depends on the data flow. | A diagram or written flow that names each system, model and storage location the data touches. | |||
| A2 | Which steps are AI models and which are fixed rules? | Models and rules fail differently and are tested differently. | Each step labeled, with the model's job stated. | |||
| A3 | Which actions can the system take without a person approving? | Autonomy is where an error becomes a loss. | A list of allowed actions, with payments, deletions, record changes and external messages gated by a named approver. | |||
| A4 | What is the system not allowed to do, and where is that enforced? | A rule written only in a prompt can be talked around. | Limits enforced in configuration or permissions, not only in instructions to the model. | |||
| B. Data handling and residency | ||||||
| B1 | Where is our data stored and processed, by region and provider? | Residency affects law and latency. | Named regions per component, including backups and logs. | |||
| B2 | Is our data used to train or fine-tune any model, yours or a provider's? | Training can move your data into a shared asset. | A clear no, written into the contract, with the provider terms that say so. | |||
| B3 | How long do you keep our inputs, outputs and logs, and can we set it? | Retention is exposure. | A period for each data type, and whether the customer can change it. | |||
| B4 | Which fields can be masked or kept out of the model? | Some data never needs to reach a model. | A list of maskable fields, such as national IDs or card numbers, and how the masking is tested. | |||
| B5 | How do you delete our data when the contract ends, and how do we confirm it? | Deletion you cannot verify is a promise. | A deletion period and written confirmation, covering backups and logs. | |||
| C. Models and subprocessors | ||||||
| C1 | Which model providers do you use, and for which steps? | Each provider is a party that may see your data. | Named providers and models per step. | |||
| C2 | What do those providers do with prompts and outputs: retention, human review, training? | Provider terms differ and change. | The provider terms, plus any zero-retention or limited-retention option in use. | |||
| C3 | Can we restrict the model route, for example to our own cloud account or a self-hosted model? | Some data must stay inside your boundary. | The options listed, with the trade-offs in quality and cost. | |||
| C4 | Who are your subprocessors, and how do you tell us when the list changes? | Silent changes break your own compliance. | A current list, advance notice and a right to object. | |||
| C5 | What happens if a model provider has an outage or changes a model version? | Behavior can shift without a code change. | A fallback route, version pinning and testing before a new version goes live. | |||
| D. Access and tenancy | ||||||
| D1 | How is our data separated from other customers' data? | Cross-customer leakage is a basic failure. | A description of the isolation model (separate environments, accounts or logical tenancy) and how it is tested. | |||
| D2 | Who at your company can see our data, and how is that access granted and reviewed? | Staff access is the quiet risk. | Role-based, least-privilege, time-limited and logged, with a review schedule. | |||
| D3 | Do you support single sign-on and role-based permissions for our users? | Your users should sit under your identity controls. | SSO through SAML or OIDC, and roles that map to who can approve what. | |||
| D4 | How are the system's own credentials and API keys stored and rotated? | An agent with a leaked key can act as you. | Secrets in a vault, scoped per system, rotated on a schedule. | |||
| E. Human oversight | ||||||
| E1 | Which decisions need a named person to approve, and can we change that list? | Approval is the main safety control. | A default list, with the customer able to add gates. | |||
| E2 | What does the approver see when they approve? | A rubber stamp is not oversight. | The source document, the extracted or drafted result, the reason or confidence and what happens on approval. | |||
| E3 | What happens to cases the system is unsure about? | Silent guessing is the worst outcome. | Routed to a queue with an owner and a time limit. | |||
| E4 | Can the system be paused immediately, and by whom? | You need a stop button before you need it. | A pause the customer can use, and a clear rule for items already in flight. | |||
| F. Logging, audit and monitoring | ||||||
| F1 | What do you log for every action? | Logs are how you reconstruct what happened. | Input, model used, output, tool calls, approver, timestamp and result. | |||
| F2 | Can we export the logs, and how long are they kept? | Your auditors need them, not only the vendor. | Export in a documented format and a stated retention period. | |||
| F3 | How do you monitor quality after go-live? | Quality drifts as data and models change. | Sampled review against a test set, drift checks and alerts on error rates. | |||
| F4 | How do you detect an incident involving our data, and how soon do you tell us? | Notice periods are negotiable only before signing. | A defined detection process, a notification window in the contract and a written summary afterward. | |||
| G. Testing and AI-specific risk | ||||||
| G1 | How do you measure accuracy on our own data before go-live? | A vendor demo is not a test on your cases. | A test set built from your past cases, with thresholds agreed in writing. | |||
| G2 | How do you test for prompt injection, including instructions hidden in documents or emails? | Content the system reads can carry attacks. | Adversarial cases in the test set, and permissions that stop injected text from triggering sensitive actions. | |||
| G3 | Which risks in the OWASP Top 10 for LLM Applications apply here, and what controls cover each? | A shared checklist makes answers comparable. | A short mapping of each applicable risk to a control, for example for sensitive information disclosure and excessive agency. | |||
| G4 | How are prompts, model versions and configuration changed, tested and rolled back? | A prompt edit is a production change. | Versioned changes, tested against the test set, with a rollback path. | |||
| G5 | What are the known limits and failure modes of this system? | A vendor that cannot name any has not measured. | An honest list, such as unsupported languages, document types and the accuracy range. | |||
| H. Security program | ||||||
| H1 | Which independent attestations or certifications do you hold, and can we see the reports? | Independent evidence beats a claim. | Current reports with a scope that covers the product you would use, or a plain statement of what you do not hold and the controls in place instead. | |||
| H2 | Do you run penetration tests, how often, and can we see a summary? | Tests find what design reviews miss. | A test cadence, an independent tester and a summary of findings and fixes. | |||
| H3 | How do you manage vulnerabilities and patching across the stack? | Old libraries are an easy way in. | A patch policy with time targets by severity. | |||
| H4 | How are your staff screened and trained on handling customer data? | People are part of the attack surface. | Background checks where lawful, onboarding training and a refresher schedule. | |||
| I. Privacy, contract and exit | ||||||
| I1 | Will you sign a data processing agreement, and which privacy laws apply to our data? | Roles and obligations belong in writing. | A DPA offered up front, and the regimes named for the regions concerned. | |||
| I2 | Who owns the outputs, prompts, workflows and any assets trained on our data? | Ownership disputes surface at exit. | The customer owns its data and outputs, and terms for the vendor's own tooling are clear. | |||
| I3 | What do we get if we leave: exports, documentation, runbooks? | Lock-in is a security risk too. | Workflows, configuration and data exportable in documented formats. | |||
| I4 | What are the contract's limits of liability, and what insurance do you carry? | Know who pays if it goes wrong. | The limits stated in the contract, and a certificate on request. | |||
| I5 | How do you handle a regulator's or law enforcement's request for our data? | You may be legally the data owner. | Notify the customer unless the law forbids it, and challenge requests that are too broad. | |||
Scroll sideways to see every column.
Rating key
ReferenceUse the same four ratings on every answer so reviewers compare like with like.
| Rating | What it means | What to do |
|---|---|---|
| Meets | A clear answer, backed by a document or a contract term. | Record it and move on. |
| Partly | An answer, but the evidence is missing or the scope is narrower than your use case. | Ask for the document and set a date. |
| Gap | The control is absent, or the vendor cannot say. | Decide whether a contract term, a configuration or a workaround closes it. |
| Dealbreaker | For example, your data trains a shared model, or sensitive actions have no approval step. | Stop until it is fixed in writing. |
Scroll sideways to see every column.
How to fill it in
6 steps, in the order that saves rework.
- 1
Fill in the header and scope it
Name the vendor, the exact product and the data it will see. Answers about a vendor's marketing site tell you little about the product you will actually use.
- 2
Send everything except your rating
Keep the rating column private. Ask the engineers who will build and run the system to answer, not only the sales team.
- 3
Ask for evidence with every answer
A document name or a contract clause beats a sentence. Where a vendor cannot share a report, ask what they can share, such as a summary or a call with the person who owns the control.
- 4
Rate every answer with the same key
Use Meets, Partly, Gap or Dealbreaker. Treat vague answers such as "we take security seriously" as a Gap until a document arrives.
- 5
Turn gaps into actions
For each Gap, decide whether a contract term, a configuration change or a smaller scope closes it. Put the owner and a date next to it.
- 6
Run the same questions on every shortlisted vendor
Comparing two vendors on different questions is guesswork. Keep the sheet as the record you show your auditors.
A worked example
A made-up case, so you can see what a filled-in version looks like. None of the numbers are real.
Illustrative
Four rated answers
Illustrative. The vendor answers below are made up to show how ratings and follow-ups work.
| ID | Vendor response | Rating | Follow-up |
|---|---|---|---|
| B2 | No. We do not train on customer data. Provider terms attached. | Meets | Check that the contract says the same. |
| E1 | Sensitive actions need approval. | Partly | Ask which actions count, and whether the list can be changed. |
| G2 | We are protected against prompt injection. | Gap | No evidence. Ask for the adversarial test cases and the results. |
| H1 | We are preparing for an audit later this year. | Gap | Ask what controls exist today and what the audit will cover. Consider a contract term. |
Scroll sideways to see every column.
How to read it. The vague answers are the finding. A confident sentence with no document behind it is a Gap, and a promise about the future is not a control today. A Gap is not a rejection. It is a list of things to close before you share data.
Use it with
- PageScenox trust centerOur own answers on data, models, approvals and audit logs.
- BlogAI guardrails for business systemsInput, output and action controls.
- BlogHuman in the loop AIDesign patterns for approvals and exceptions.
- BlogHow to choose an AI automation agencyA buyer's checklist for shortlisting.
- SolutionPrivate AI modelsModels that run inside your own boundary.
- TemplateAI project requirements templateCarry the answers into the statement of work.
Questions about this template
What is an AI vendor security questionnaire?
A set of written questions a buyer sends to an AI vendor before sharing data. It covers the usual vendor security topics, such as access control and incident response, plus AI-specific ones: which models see the data, whether it trains anything, who approves actions and how the system is tested.
How is it different from a standard vendor questionnaire?
Standard questionnaires such as SIG or CAIQ cover company-wide security well but say little about model providers, training on your data, prompt injection or approval gates. Use this alongside them for AI vendors, not instead of them.
Will you answer it too?
Yes. We expect buyers to ask us these questions. We complete customer questionnaires with the engineers who build the system, and our current answers on data, models and approvals are on the trust center.
Should we rule out a vendor with no certifications?
Not automatically. A certification shows a process was independently audited, and it does not prove a given product handles your data safely. Ask what controls exist today, what the audit scope covers, and decide against the sensitivity of your use case.
Which answers are red flags?
Your data trains shared models. Sensitive actions run with no approver. There are no logs you can export. The vendor cannot name a limitation of its own system. Every answer is a marketing sentence with no document behind it.
More free templates
All 6 templates3 tables · 12 columns
Automation opportunity scoring template
Score each candidate workflow on five criteria, weigh it against hours spent, and pick the first pilot.
3 tables · 8 columns
RAG evaluation test set template
Questions, gold answers, sources and expected behavior, plus a run log for every release.
1 table · 9 columns
Month-end close task inventory template
A master list of every close task with owner, reviewer, due day, evidence and automation fit.
1 table · 35 items
AI project requirements template and SOW checklist
What to settle before signing: outcome, workflow, data, test thresholds, security, delivery and support.
Send us this questionnaire. We will answer it.
A 30-minute call with an engineer. You will leave knowing what a system could do for that workflow and what it would take to build.
What happens next
- 1
Strategy call
We learn how the workflow runs today and what a good outcome would be.
- 2
Workflow audit
We map the process and measure where a system would save the most time.
- 3
Proposal
A written scope, timeline and fixed price for your first system. No obligation to build.