Security Questionnaire Answer Library
Published in full. No email, no sign-up.
Twenty-three questions that come up in AI security reviews, with an answer shape for each one. Compliance review is the single most common thing that stalls an AI deal. Buyer-side question lists are free all over the internet. Seller-side answer libraries are not, because the answers are competitive information, which is exactly why a practitioner community can build one.
Read this before you use it. These are answer shapes, not claims about your product. Every bracketed field is something only you can assert, and a wrong answer in a security questionnaire is a compliance problem rather than a bad template.
Is our data used to train your models?
No. Customer data submitted to [PRODUCT] is not used to train or fine-tune any model, ours or a provider's. We contract this with our model providers under zero-retention terms and can name them. Where a customer opts into improvement programmes, that is explicit, separately consented and revocable.
The most-asked question in AI security review and the fastest to lose. Know your provider's exact retention terms and whether your tier has zero-retention. Never answer 'we don't train on it' if a sub-processor might.
Which sub-processors touch our data, and where are they?
Full sub-processor list at [URL], with the processing location and purpose of each. We give [N] days notice of additions and you may object. Model inference runs in [REGIONS]. Inference and data-at-rest may be in different regions, stated explicitly below.
Buyers assume storage region equals inference region. Say it plainly before they discover it. This is where residency answers most often fall apart.
What is your data retention and deletion policy for prompts and outputs?
Prompts and outputs are retained for [N] days for [abuse monitoring / debugging / your audit access], then deleted. You can configure [shorter / zero] retention at [tier]. On termination, all customer data is deleted within [N] days and we provide written confirmation.
Distinguish YOUR retention from your model provider's. Buyers ask once and mean both.
Can you guarantee data residency in [region]?
Data at rest resides in [region]. Inference runs in [region(s)]. If those differ, we state which components leave the region and under what safeguards. Transfers rely on [mechanism]. We can provide a data-flow diagram naming every crossing.
The honest answer beats the confident one. An architect who finds an undisclosed crossing later will kill the deal.
How do you prevent one customer's data appearing in another's outputs?
Tenant isolation is enforced at [layer]. No customer data enters a shared index, a shared fine-tune or a shared cache. Retrieval is scoped to the tenant at query time, not filtered after retrieval. Evidence: [pen-test finding, architecture doc, SOC 2 control ref].
For retrieval products this is THE question. 'Filtered after retrieval' is a real and common weakness. If that is your architecture, say so and describe the compensating control.
Which models do you use, and can we pin a version?
We currently use [models] from [providers]. Version pinning is available where the provider supports it, at [tier]. Where pinning is unavailable we commit to [N] days notice of a version change, regression testing against your evaluation suite before promotion, and [N] days of rollback availability.
See the Model-Change brief. Never claim immunity to model change unless you self-host. Their architect knows the difference.
What happens if your model provider deprecates a model you depend on?
We maintain [N] supported models and can migrate a customer between them. Migration triggers a regression run against your eval suite with results shared before cutover. Our contractual commitment is to a quality floor measured on your criteria, not to a specific model version.
Committing to a measured quality floor rather than a model version is both more honest and easier to hold. This is the answer that separates serious vendors.
Do you fine-tune on our data, and who owns the resulting weights?
We do not fine-tune on customer data. Where we do, fine-tuning is opt-in per customer, the resulting adapter is tenant-isolated, never serves another customer, and is deleted on termination. You retain ownership of your training data. Weights derived from it are [ownership position].
Get legal to write the ownership sentence. Do not improvise it in a questionnaire.
How do you evaluate model quality, and can we see the results?
We run [suite] pre-release and on every model change, covering [dimensions]. For your deployment we build an evaluation set from your own data and share results including failures. We do not publish a single accuracy number because it is not meaningful outside a defined task and dataset.
Refusing to give a context-free accuracy number is a credibility gain, not a loss, provided you offer the alternative in the same breath.
How do you prevent hallucination?
We reduce and bound it rather than eliminate it, because it is a property of the technology, not a defect we can patch. Controls: [grounding and retrieval constraints], [output validation against source], [confidence thresholds and abstention], [human review at defined points]. We measure residual rate on your data and report it.
The strongest answer in the whole library. Never claim elimination. A security reviewer who hears 'we prevent hallucination' stops believing everything else you said.
What is your defence against prompt injection?
Layered: [input sanitisation and provenance separation], [privilege separation so retrieved content cannot invoke tools], [output validation before any action], [least-privilege scoping of every tool the model can call]. We red-team this at [cadence] and can share the summary. We do not claim it is solved. It is an open research problem and our architecture assumes injection will sometimes succeed.
Rising fast in questionnaires. The 'our architecture assumes it will sometimes succeed' framing is what a serious reviewer wants to hear.
How do you stop the system taking a harmful or unauthorised action?
Actions are scoped by [permission model]. Irreversible actions and actions touching [money or systems of record] require [approval gate]. There is a per-[tenant, use-case or action-type] kill switch, effective within [time]. Every action is logged immutably with the triggering context.
See the Agent Autonomy brief. If you sell anything agentic this is now the question that decides the deal.
What does the system do when it does not know the answer?
It abstains rather than guesses. Below [threshold] it [declines, escalates or returns no result] and says so to the user. We measure abstention correctly-triggered rate as a first-class metric, because a confident wrong answer is more damaging than a refusal.
Buyers rarely ask this well, and volunteering it lands hard. It is also the criterion most POCs forget to test.
Can outputs be reviewed or overridden by a human?
Yes. [Describe the human-in-the-loop points, who can override, whether overrides are captured as training or eval signal, and what the audit trail records.]
Say whether overrides feed back into anything. Buyers increasingly ask, and 'we discard them' is a wasted asset.
How do you handle bias and fairness?
We test for performance disparity across [cohorts relevant to the use case] as part of the evaluation suite, and report per-cohort results rather than aggregates. Where a disparity exists we state it. We support [documentation requirement].
Per-cohort reporting rather than an aggregate is the substantive answer. Aggregates hide exactly what the question is about.
Voice: how do you handle call recording consent and voice biometrics?
[Consent mechanism and where it is captured]. We do not create or store voiceprints, or voiceprints are created only under [condition] and stored as [form]. PCI-sensitive segments are [paused or redacted]. Transcripts are retained [N] days and are [in or out of] scope for deletion requests.
Only answer the block that applies to you. Delete the ones that do not, because a padded questionnaire response reads as evasive.
Code: does our source code leave our environment, and can generated code create licensing exposure?
[Egress position: what leaves, what stays, VPC and on-prem options]. On licensing, generated code is [position on provenance]. We [do or do not] provide a filter against verbatim reproduction of training data and [do or do not] indemnify.
Licence contamination is the question that stalls copilot deals and most vendors answer it badly. Get legal to write the indemnity sentence.
Retrieval: are permissions enforced at index time or query time?
At query time. The retrieval layer resolves the requesting user's live entitlements before returning any chunk. Revocation takes effect within [time]. We do not rely on index-time filtering, because permissions change after indexing.
If you DO rely on index-time filtering, say so and give the revocation lag honestly. This is the single most common serious finding in retrieval security reviews.
Agents: what is the blast radius if the agent misbehaves?
[Enumerate write scopes.] Irreversible actions require [gate]. Rate limits cap [N] actions per [window]. Rollback is available for [action classes] within [window]. The kill switch operates at [granularity] within [time].
Answer with specifics or do not answer. Vagueness here reads as 'we have not thought about it'.
Which certifications do you hold?
[SOC 2 Type II, ISO 27001, ISO 42001, HIPAA and so on], report available under NDA at [URL]. Where a certification is in progress, target date [date], current stage [stage]. We do not claim certifications we are pursuing.
ISO 42001 for AI management systems is increasingly asked for specifically. Never list an in-progress certification as held.
How is data encrypted?
In transit: [TLS version]. At rest: [algorithm and key management]. Customer-managed keys available at [tier].
Standard, but answer it precisely. A vague encryption answer makes reviewers dig elsewhere.
What is your incident response and disclosure commitment?
[Detection, triage, notification timeline in hours, who is notified, what the notice contains, post-incident report commitment.] AI-specific incidents, meaning model behaviour causing customer harm, follow the same path and are explicitly in scope.
Stating that model-behaviour incidents are in scope is unusual and reassuring. Most vendors leave it ambiguous.
Do you carry insurance covering AI-caused loss?
[Policy types, limits, whether AI-specific exclusions exist.]
Check your policy for AI exclusions before answering. Several standard tech errors-and-omissions policies now carve out generative AI.
This is the artifact most likely to go stale, because the questions change every quarter as buyers learn what to ask. If you get asked something that is not in here, post it in the room with the answer you gave. Good ones get added and the entry carries your name. If you find an answer here that would not survive your own security team, say so. Being wrong in this document is more expensive than being wrong anywhere else.
Use this on a live deal this week, then tell the room what happened. Not that it looked useful. What you changed, what the buyer did, whether it worked. If it didn't work, that's the more valuable post.
Get the next one when it ships, plus the benchmark at 200 responses.