Answering AI Security Questionnaires

Why this matters now

If your company ships an AI feature, sells software to the enterprise, or handles another organization's data through a model, you have already met — or soon will meet — the AI security questionnaire. It arrives as a spreadsheet or a portal invitation, usually from the buyer's security or procurement team, and it can decide whether a signed contract is weeks away or quarters away.

For most of the last decade, vendor security reviews were a known quantity. A buyer sent a standardized questionnaire, your security team pulled from a bank of prior answers and a SOC 2 report, and the review closed. Then generative AI moved from experiment to production, and the questions changed. Buyers began appending a new section — sometimes a handful of rows, sometimes an entire tab — asking pointed questions about how your models are trained, whether their data trains your systems, how you defend against prompt injection, and how you would detect and respond to an AI-specific incident. Those questions do not map cleanly to the answers most vendors already had on file, and answering them badly, or slowly, stalls deals.

This article is a working guide for the people who have to respond: security leads, GRC and trust teams, heads of AI, sales engineers, and the founders who still own security review at smaller companies. It explains why procurement is now gating on AI security, which established questionnaire frameworks the AI questions are being grafted onto, the specific categories buyers probe, and — most usefully — how to build a reusable evidence library so you can answer accurately and fast. It closes by showing how to map your answers to SOC 2 and the NIST AI Risk Management Framework, and how a well-run questionnaire process becomes a sales advantage rather than a tax.

Why enterprise procurement now gates on AI security

A questionnaire is not an academic exercise. It exists because the buyer's own risk function has decided that adopting your software creates exposure it must account for. Understanding why that exposure grew sharply with AI helps you answer with the right framing — and helps you anticipate the follow-up questions that a thin answer will provoke.

The buyer inherits your AI risk

When an enterprise adopts a vendor's AI feature, it is not just buying functionality. It is extending its own attack surface and its own regulatory obligations into a system it does not control. If your model can be manipulated to leak data, the buyer's data may be the data that leaks. If your training pipeline ingests customer inputs, the buyer's confidential information may end up shaping a model that serves its competitors. If your AI supply chain includes a compromised third-party model, the buyer inherits that compromise. Procurement teams have internalized this, and the questionnaire is how they measure it before signing.

Regulation raised the floor

The regulatory environment has moved quickly. The EU AI Act introduced risk-based obligations for AI systems, with real duties around high-risk use cases, transparency, and governance. Sector regulators in finance, healthcare, and the public sector have issued AI guidance that flows down to vendors. And frameworks like the NIST AI Risk Management Framework and ISO/IEC 42001 — the first international management-system standard for AI — gave buyers a vocabulary to ask precise questions. A large enterprise's own compliance program now depends on being able to show that its vendors are governed, so it pushes those requirements down the supply chain through the questionnaire.

The threat model is genuinely new

Traditional vendor security asked whether you patch, encrypt, and control access. Those questions still matter, but AI added a category of risk that older controls do not address. Prompt injection lets an attacker smuggle instructions into a model through untrusted input. Training-data governance determines whether sensitive inputs persist in a model. Model provenance determines whether the weights you deploy can be trusted at all. Buyers know their existing tooling was not built for these risks, so they ask you directly. To go deeper on the underlying threats and controls, see our overview of AI governance and compliance.

The net effect is that AI security has become a gate rather than a nice-to-have. In many enterprise deals, the security review now runs in parallel with commercial negotiation, and a stalled review holds the whole deal. The vendors that win are not always the ones with the strongest security — they are the ones that can demonstrate their security clearly and quickly.

The frameworks buyers build on: SIG, CAIQ, and VSA

Very few buyers write an AI questionnaire from scratch. Instead, they extend one of the established vendor-assessment frameworks that their security teams already use. Knowing these frameworks tells you what structure to expect and lets you pre-map your evidence to the questions before they arrive.

SIG — Standardized Information Gathering

The SIG, maintained by Shared Assessments, is one of the most widely used third-party risk questionnaires. It is organized into risk domains — covering areas such as access control, application security, cloud, data governance, incident management, and more — and is published in tiers so a buyer can send a lighter "SIG Lite" or a comprehensive "SIG Core" depending on how much risk the relationship carries. Shared Assessments has been expanding the SIG's content to reflect emerging risks, and buyers increasingly add AI-specific questions within the relevant domains: data governance for training use, application security for model behavior, and so on. If you receive a SIG, expect a domain-by-domain structure and prepare evidence that maps to each domain.

CAIQ and CSA STAR

The CAIQ (Consensus Assessments Initiative Questionnaire) is published by the Cloud Security Alliance and is built directly on the CSA Cloud Controls Matrix. It is a set of yes/no and explanatory questions that let a cloud customer assess a provider's controls. A completed CAIQ is also the foundation of a CSA STAR self-assessment or certification listing, which many buyers check first. The Cloud Security Alliance has been active in AI security, publishing guidance and working groups focused on AI controls, so expect CAIQ-style assessments to incorporate AI-specific control questions over time. If your product is cloud-delivered, keeping a current CAIQ and STAR entry answers a large share of questions before a buyer even asks.

VSA — Vendor Security Alliance

The VSA questionnaire, from the Vendor Security Alliance, is a streamlined assessment created by a coalition of companies to standardize vendor security reviews. It comes in versions oriented toward core security practices and toward privacy, and it is designed to reduce the redundant, bespoke questionnaires that vendors otherwise face. The VSA has publicly signaled attention to emerging technology risk, and AI-specific content fits naturally into its practice areas. Because the VSA is intentionally concise, an answer here needs to be tight and evidence-backed rather than exhaustive.

How AI-specific questions are being added

The important pattern is that AI questions are rarely a separate framework. They are additions to these existing instruments — new rows inside a data-governance domain, a new tab labeled "Artificial Intelligence" or "Machine Learning," or supplementary questionnaires attached to the main assessment. Some buyers also send a purpose-built AI addendum drawn from the NIST AI RMF or ISO/IEC 42001. In practice this means an AI questionnaire is usually 80% familiar security questions with an AI framing, and 20% genuinely AI-specific questions. Your job is to answer the familiar 80% instantly from your existing evidence, and to have credible, prepared answers for the specialized 20%.

What buyers actually probe

Across frameworks, the AI-specific questions cluster into a predictable set of categories. If you prepare evidence for each of these, you will have an answer ready for almost anything a buyer sends. The rest of this section walks through them in the order buyers tend to weight them.

• Data handling and training use — what happens to the data a customer sends your AI, and whether it trains your models.
• Model provenance and supply chain — where your models come from and whether they can be trusted.
• Prompt injection and output controls — how you prevent manipulation and stop sensitive data from leaving in a response.
• Encryption — how data is protected at rest and in transit, and increasingly whether you are prepared for post-quantum threats.
• Access control — who and what can reach models, prompts, and data.
• Logging and monitoring — whether you can see what your AI did and detect abuse.
• Incident response — how you would contain and disclose an AI-specific incident.
• Governance and compliance mapping — how your program maps to recognized frameworks.

The following sections take each cluster in turn, describe what buyers are really asking, and outline the evidence that answers it well.

Data handling and training use

This is the first question buyers ask and the one they weight most heavily, because it goes to the heart of what they are afraid of: that their confidential data will be absorbed into your model and resurface somewhere they cannot control. Expect questions phrased as "Is customer data used to train your models?", "Do you retain prompts and outputs, and for how long?", and "Can we opt out of any data use for model improvement?"

Answer the training-use question unambiguously

The strongest answer here is a clear, categorical statement of policy backed by a control. If customer data does not train your models, say so plainly and point to the contractual term and technical control that enforce it. If some data is used under specific conditions, describe those conditions precisely and describe the opt-out. Vague or hedged answers here are the single most common reason an AI review escalates, because the buyer will assume the worst and send follow-ups. Precision closes the question.

Data flow, retention, and residency

Buyers want a clear picture of the data lifecycle. Where does a prompt go once it enters your system? Which sub-processors — including any third-party model providers — see it? How long is it retained, and how is it deleted? Is it processed or stored in specific regions to meet data-residency requirements? A simple, accurate data-flow diagram answers a dozen questionnaire rows at once and is one of the highest-leverage pieces of evidence you can maintain.

Third-party model providers

If your feature calls a hosted foundation model, the buyer's data governance now depends on that provider's terms. Buyers will ask which providers you use, whether those providers train on your data, and what contractual and technical guarantees are in place. Be ready to name your providers and to reference their enterprise data-handling commitments. This overlaps with supply chain, covered next.

Model provenance and supply chain

Buyers increasingly treat models the way they treat any other software dependency: as something that can be tampered with, backdoored, or poisoned before it ever reaches your environment. The questions here probe where your models come from and how you verify them.

Provenance and integrity

Expect to be asked whether you use open-weight, commercial, or self-trained models; how you verify the integrity of model weights you download; and whether you track a bill of materials for the models and datasets in your pipeline. A model pulled from a public repository without verification is a genuine supply-chain risk — weights can carry backdoors that trigger on specific inputs, and datasets can be poisoned to bias behavior. Buyers who understand this will ask, and a prepared answer describing your verification and sign-off process is reassuring.

Dependencies and fine-tuning data

The AI supply chain extends past the base model to the frameworks, libraries, embeddings, and fine-tuning datasets around it. Questions may cover how you vet fine-tuning data for poisoning, how you manage the open-source dependencies in your inference stack, and how you would respond to a disclosed vulnerability in a model or library you rely on. Framing your answer around an existing vulnerability-management and vendor-vetting process — extended to cover models — shows maturity. Deflected's governance and compliance work is built around exactly this kind of documented, defensible supply-chain posture.

Prompt injection and output controls

This is the category that most clearly separates an AI questionnaire from a traditional one, and it is where thin answers are most exposed. Buyers who employ security engineers will ask specifically how you defend against prompt injection and how you prevent sensitive data from leaving through model output.

Prompt injection

Prompt injection is the defining AI vulnerability: when untrusted input — from a user, or from a document your system retrieved — is placed into a model's prompt, an attacker can hide instructions in that input to hijack the model's behavior. It is to AI what SQL injection was to databases. Buyers will ask what controls you have in place: input inspection, separation of trusted instructions from untrusted content, constraints on what tools an AI agent can call, and testing against known injection techniques. There is no single control that eliminates the risk, so the credible answer describes layered defenses and ongoing adversarial testing rather than a silver bullet.

Output filtering and data-leak prevention

An AI system can leak sensitive information simply by generating it. A model with access to internal documents or customer records can be led into revealing them in a response. Buyers will ask how you inspect model output before it reaches a user, how you detect regulated data or secrets in responses, and how you prevent a model from being coaxed into exfiltrating its own context. Describe your output-side controls, and be honest that this is a defense-in-depth problem, not a solved one.

Jailbreaks, agents, and tool use

Where your product uses AI agents with tools — the ability to call APIs, run code, or take actions — the stakes rise, and buyers know it. Expect questions about how you constrain agent permissions, how you prevent a jailbreak from escalating into an unauthorized action, and how you sandbox tool execution. The principle to convey is least privilege applied to AI: an agent should be able to do only what the task requires, and every action should be logged. An inline control such as a policy-enforcing AI gateway that inspects prompts and responses in real time is strong evidence to offer here, especially when paired with continuous adversarial testing.

Encryption, including post-quantum readiness

Encryption questions appear in every security questionnaire, and AI does not change the fundamentals — but it does raise the stakes, because AI systems concentrate large volumes of sensitive data in prompts, embeddings, and logs. Increasingly, sophisticated buyers also ask about post-quantum readiness, because much of the data flowing through AI systems will still be sensitive a decade from now.

The baseline answer

Buyers expect strong, standard encryption everywhere. The baseline answer is that data is encrypted in transit with modern TLS and at rest with AES-256, with documented key management. State this plainly and reference the control. Most encryption rows on a questionnaire are answered by this single, well-evidenced statement.

The post-quantum question

A growing number of enterprise and public-sector buyers now ask about the quantum horizon, because of a threat known as harvest now, decrypt later: adversaries can capture encrypted data today and store it to decrypt once quantum computers can break classical public-key cryptography. Any data that will still be sensitive in five or ten years is effectively exposed today unless it is protected with post-quantum algorithms. If your platform is prepared for this, it is a strong differentiator. Deflected encrypts data using the standards finalized by the U.S. National Institute of Standards and Technology (NIST):

• ML-KEM-1024 (formerly CRYSTALS-Kyber, NIST FIPS 203) for key encapsulation, providing a high post-quantum security level.
• Hybrid X25519 + ML-KEM key exchange, which runs a proven classical algorithm alongside the post-quantum one, so data stays protected even if either scheme is later weakened.
• AES-256 for symmetric encryption of data at rest and in transit.

Being able to answer the post-quantum question with specifics — rather than "we use industry-standard encryption" — signals a level of forward planning that separates you from the field, especially in finance, healthcare, and government reviews where long data-sensitivity horizons are the norm.

Access control, logging, monitoring, and incident response

These categories are the backbone of any security questionnaire, and they carry over almost unchanged into AI reviews — with a few AI-specific twists. This is where your existing SOC 2 evidence does most of the work.

Access control

Buyers ask who can access models, prompts, training data, and logs, and how that access is governed. The expected answer covers role-based access control, least privilege, multi-factor authentication, and periodic access reviews. The AI twist is that access control now extends to non-human identities: the service accounts and agents that call models and tools. Be ready to describe how you scope and rotate the credentials your AI systems use, and how an agent's permissions are limited to its task.

Logging and monitoring

Traditional logging captures infrastructure and application events. AI systems need an additional layer: the ability to see what went into a model and what came out. Buyers will ask whether you log prompts and responses, whether those logs are immutable and access-controlled, and whether you monitor for anomalous AI behavior such as a spike in blocked injection attempts or unusual tool calls. An audit-quality log of AI decisions is both a security control and a compliance artifact — and it is exactly what an incident investigation or a regulator will want to see.

Incident response

Buyers want to know that you can detect, contain, and disclose an incident — including one that is AI-specific, such as a successful prompt injection, a model leaking data, or a poisoned model in your pipeline. Expect questions about your incident-response plan, your detection capabilities, your notification timelines, and whether you have run tabletop exercises. The credible answer extends your existing incident-response process to explicitly cover AI incidents, names who is responsible, and describes how you would notify affected customers. If you have expert response available on retainer, say so — it materially reassures a buyer that a real AI incident would be handled by people who understand the failure mode.

Governance and compliance mapping

Finally, buyers ask how your program maps to recognized frameworks. This is the question that ties the whole questionnaire together, and it is covered in depth in the mapping section below. The short version: point to your SOC 2 report for general security, and to the NIST AI RMF or ISO/IEC 42001 for AI-specific governance, and show the crosswalk between them.

Building a reusable evidence library

Everything above describes what buyers ask. This section describes how to answer it without a fire drill every time. The single highest-leverage investment a vendor can make is a reusable evidence library: a curated, versioned source of vetted answers, each tied to a piece of evidence. Done well, it turns a multi-week questionnaire into a same-week response.

What an evidence library is

An evidence library is a structured repository — a well-organized document, a knowledge base, or a purpose-built tool — where each entry contains a question or topic, an approved answer, the evidence that backs it, an owner, and a review date. When a questionnaire arrives, most rows map to an existing entry and can be answered by reuse. Only the genuinely new questions require fresh work, and those become new library entries so you never answer them cold twice.

What goes in it

Stock your library with the artifacts buyers repeatedly ask for:

1. Approved answers to each common question, written once and vetted by security and legal.
2. Your SOC 2 report and the mapping of its controls to common questionnaire rows.
3. A data-flow diagram showing how customer data moves through your AI, including sub-processors and retention.
4. A model and data inventory — the provenance, verification, and sign-off record for the models you deploy.
5. Policies covering AI usage, data handling, access control, and incident response.
6. Framework crosswalks mapping your controls to the NIST AI RMF, ISO/IEC 42001, SOC 2, and where relevant the EU AI Act.
7. Encryption and key-management details, including your post-quantum posture, stated precisely.

How to keep it accurate

An evidence library is only valuable if it is true. Assign an owner to each entry, set a review cadence, and never let an answer drift from reality — an inaccurate questionnaire answer is worse than a slow one, because it becomes a contractual representation and, if wrong, a liability. When your architecture changes, update the library first. Treat the library as a living security artifact, not a sales convenience.

The workflow that makes it fast

With a library in place, the response workflow is simple: intake the questionnaire, auto-match or manually map each row to a library entry, flag the small number of genuinely new questions for expert review, assemble the response, and have security sign off before it goes back. The first questionnaire you answer this way still takes real effort; the tenth takes hours. That compounding speed is the entire point.

Mapping answers to SOC 2 and the NIST AI RMF

The most efficient way to answer a questionnaire is to have already mapped your controls to the two frameworks buyers trust most: SOC 2 for general security, and the NIST AI Risk Management Framework for AI-specific governance. Together they cover nearly every question an AI questionnaire can ask.

SOC 2 covers the security backbone

SOC 2 is an attestation, performed by an independent CPA firm, against the Trust Services Criteria — the criteria for security and, optionally, availability, confidentiality, processing integrity, and privacy. Its controls supply the evidence for a large share of any questionnaire: access control, encryption, change management, logging, vendor management, and incident response all live here. When a questionnaire asks how you control access or protect data at rest, the answer is your SOC 2 control plus a one-line summary. Maintaining a current SOC 2 report and a crosswalk from its controls to common questionnaire rows is the highest-return compliance investment most AI vendors can make. Our companion guide on SOC 2 for AI companies goes deeper on scoping it for an AI product.

The NIST AI RMF covers the AI-specific layer

SOC 2 was not designed for AI-specific risk, which is where the NIST AI Risk Management Framework comes in. The AI RMF organizes AI risk management into four functions — Govern, Map, Measure, and Manage — that align neatly with the AI-specific questions on a questionnaire:

• Govern — your policies, accountability, and culture around AI risk. This answers governance and oversight questions.
• Map — understanding context and identifying risks, including data provenance and intended use. This answers data-handling and supply-chain questions.
• Measure — evaluating and testing AI systems, including adversarial testing for prompt injection and monitoring. This answers questions about how you assess model behavior.
• Manage — prioritizing and responding to risks, including incident response and ongoing monitoring. This answers operational and response questions.

Mapping each of your AI controls to an AI RMF function gives you a ready structure for the AI-specific rows and demonstrates to a buyer that your governance is systematic rather than ad hoc. Where a buyer uses ISO/IEC 42001 vocabulary instead, the same controls map across; maintaining both crosswalks future-proofs your answers.

The crosswalk in practice

The practical artifact is a crosswalk table that maps each common questionnaire question to the framework control and the piece of evidence that answers it. When a SIG, CAIQ, or VSA arrives, you are matching its rows to your crosswalk rather than composing answers from memory. This is what lets a two-person security team answer an enterprise questionnaire in the same week it arrives — and answer it consistently, so two questionnaires from two buyers never contradict each other. Deflected builds exactly these crosswalks as part of an AI governance and compliance engagement, and ties them to the broader compliance program a buyer expects to see.

Turning the questionnaire into a sales accelerator

Most vendors experience the AI security questionnaire as friction — a tax on every deal that arrives at the worst possible moment, late in the cycle, when momentum is fragile. But the same questionnaire, handled well, is one of the clearest ways to differentiate from competitors who handle it badly. Here is how the framing flips.

Speed is a signal

When you return a complete, precise, evidence-backed questionnaire within days, you send the buyer's security team a message that no marketing claim can: you take security seriously and you have done the work. A slow, hedged, or incomplete response signals the opposite and invites deeper scrutiny. In competitive deals, the vendor whose review closes first often wins simply because the buyer's champion can move forward without waiting.

Get ahead of the questionnaire

The most advanced vendors do not wait to be asked. They publish a trust center, keep a current SOC 2 report and a CAIQ or CSA STAR entry available, and offer a pre-filled questionnaire or AI security summary proactively. This shrinks the review before it starts and lets sales lead with security as a strength. For companies selling AI features into the enterprise, this is increasingly table stakes — and an area where SaaS companies that get it right pull ahead of those that treat security as an afterthought.

Consistency builds trust across deals

Because a reusable evidence library produces the same answers every time, buyers who compare notes — and in regulated industries they do — see a consistent, credible story. Inconsistent answers across deals are a red flag that triggers re-review; consistent, well-evidenced answers compound into a reputation for being an easy, trustworthy vendor to onboard. That reputation shortens future reviews.

The compounding return

Every questionnaire you answer improves the library that answers the next one. Over a year, a process that began as a scramble becomes a repeatable capability that closes deals faster, requires less senior time per deal, and turns your security posture into a line item in the win column. The questionnaire stops being the thing that slows deals down and becomes part of why you win them.

Frequently asked questions