Teardown 01 · July 2026
Six security-questionnaire questions that stall AI vendors — with model answers
These six questions, in one form or another, appear in nearly every enterprise vendor security review — the standard industry questionnaires (like the Cloud Security Alliance's CAIQ) all probe the same ground. They are also the six where AI vendors most often stall. For each: why the enterprise asks, what a small AI company can honestly say, and the trap.
1. Where is customer data stored, and who can access it?
Why they ask: the reviewer is testing whether you actually know your own architecture. A vague answer here colors every answer that follows.
A model answer for a small AI SaaS: "Customer data is stored in [cloud provider], [region]. Data is encrypted at rest (AES-256) and in transit (TLS 1.2+). Production access is limited to [n] named engineers via role-based access with MFA; all access is logged. We do not store customer data on employee devices."
The trap: answering "AWS" without a region. Enterprises with data-residency obligations read a missing region as "they don't know" — and they are usually right.
2. Is customer data used to train your models?
Why they ask: their legal team fears their confidential data resurfacing in someone else's output. This is currently the single most emotionally loaded question in AI vendor reviews.
A model answer: "No. Customer data is not used to train or fine-tune any model, ours or a third party's. Where we call external model APIs, we use [provider]'s zero-retention / no-training configuration, contractually confirmed in our agreement with them. Customer data is processed transiently for inference only."
The trap: saying "no" while your LLM provider's default terms say otherwise. The reviewer will check your subprocessor's terms even if you didn't. Verify the actual contractual setting before you answer — this is the most common false "no" we see.
3. Provide your list of subprocessors.
Why they ask: your security is capped by your weakest vendor. They also want to know whom their data visits on its journey.
A model answer: a simple, current table: subprocessor, purpose, data touched, location, and the safeguard (DPA signed, SOC 2 report held, zero-retention config). For an AI product that table must include the model provider — omitting it reads as either ignorance or concealment.
The trap: treating your model API as "just infrastructure" and leaving it off. To an enterprise reviewer, the LLM provider is the most interesting subprocessor on the list.
4. Provide your SOC 2 report.
Why they ask: a SOC 2 report lets their security team approve you without auditing you themselves. It is a workload question as much as a trust question.
A model answer when you don't have it yet (the common case): "We are mid-way through SOC 2 Type II readiness with [platform/auditor], observation window starting [month]; report expected [month, year]. In the interim we can share: our security overview, penetration-test summary, and policies under NDA — and we will contractually commit to delivering the report by [date]."
The trap: the bluffed "in progress" with no date, no auditor, and no interim evidence. Reviewers hear "in progress" a dozen times a week; the ones with dates and artifacts pass, the vague ones stall. Honesty with a schedule beats optimism without one, every time.
5. Describe your incident-response process and breach-notification commitment.
Why they ask: regulators give them notification deadlines, so they need you to feed the chain fast enough.
A model answer: "We maintain a written incident-response plan with named roles, severity levels, and escalation paths, tested [annually]. For incidents affecting customer data, we notify affected customers within [72 hours / contractual period] of confirmation, with a written post-incident report to follow."
The trap: promising "immediate notification". It sounds strong and is contractually reckless — you cannot notify before you have confirmed. Sophisticated reviewers prefer a realistic 72 hours over an impossible "immediately"; the realistic answer signals you have actually thought about incident handling.
6. What guardrails prevent your AI from misuse or harmful output?
Why they ask: their risk team must show internal governance that the AI tools they buy are controlled. "Trust us, it's fine" is not filed easily in a risk register.
A model answer: "Guardrails operate at three layers: input filtering [what], output filtering [what], and monitoring [what is logged, what triggers review]. These controls are documented in our AI governance summary, which we share under NDA, along with our model provider's safety documentation."
The trap: having guardrails but no document. In a security review, an undocumented control does not exist. Half of what an enterprise-readiness engagement produces is not new controls — it is written evidence of the controls already there.
Closing
Notice the pattern across all six: the passing answers are not the most impressive ones — they are the most specific and honest ones, with dates, names, and documents behind them. That is genuinely good news for small vendors: readiness is mostly a preparation problem, and preparation is fast when done in the right order.
Answering two hundred of these — accurately, fast, and in a way that moves the deal — is our day job. If a review is blocking a deal right now, the fixed-price Enterprise-Readiness Audit exists for exactly that. Or start with the free 12-point self-check.