Answer AI security questions you can stand behind
Customers now ask what your AI does with their data. Give each AI answer an owner, evidence and a change trigger, and know which answers can end up in the contract.
On this page
Answering the AI section of a security questionnaire well comes down to one discipline: split every AI answer into what your product controls and what your model provider controls, then give your part one owner, the evidence behind it and a trigger that sends it back for approval whenever a model or provider changes. Drafting the words is the easy part. The hard part is giving every customer the same approved answer and being able to show later who approved what was promised, because some of these answers can end up in the contract. The work runs in six stages: reading the customer's duty behind each question, mapping owners, building the evidence, handling questions that don't fit, routing commitments to legal and keeping answers current.
Who answers and what you need before starting
The bid or proposal manager runs the AI section and signs off the response, but the content of each answer belongs to one of four leads: security, product, data protection or legal. Your job is to get each question to the right one, hold all four to the same standard of evidence and make sure nothing goes out that nobody owns.
AI questions arrive either as an extra section in the security review you already answer or as a separate set, which goes by names such as AI vendor questionnaire, AI vendor security questionnaire or AI vendor risk assessment questionnaire. One published set is the Cloud Security Alliance's AI-CAIQ, the questions mapped to its AI Controls Matrix. If a customer sends SIG or CAIQ, check the version it sends for AI questions rather than assuming either way.
Before the first question goes to an owner, have these to hand:
- the customer's questionnaire, with its instructions on format, evidence and attachments
- your current approved security answers so that the AI answers can be checked against them
- a short description of each AI feature in scope, naming the model and provider behind it
- your current sub-processor list
- the model provider's contract terms and its documentation on data use, retention and hosting
- a named person in each of security, product, data protection and legal, with their time agreed for this response
Read each AI question for the customer's own duty
Read each AI question for the duty it serves on the customer's side, because an answer that meets that duty closes the question and one that only describes your product invites a follow-up. Customers ask about your AI to meet their own obligations, and some of those obligations are written down.
In the EU, Article 26 of the AI Act requires deployers of high-risk AI systems to assign human oversight to people with the competence, training and authority for it and to keep the logs the system generates, where those logs are under their control, for at least six months unless other law provides otherwise. A customer deploying such a system has a direct reason to ask where a person reviews your output and how long prompts and outputs are kept.
The list of risks customers manage is also getting longer. In McKinsey's 2025 global survey on the state of AI, 51% of respondents from organisations using AI said they had seen at least one negative consequence, and respondents reported acting on an average of four AI-related risks, against two in 2022.
So translate the question before you route it. For example, read "how long are prompts and outputs retained?" as "can we hold what we need, for as long as we need it?", and answer that: where the logs sit, for how long, who can see them and whether the customer can export them. Read "is there human review of AI output?" as "can we show oversight by someone with authority?", and answer with the point in the work where a person checks the output and who that person is.
Map the recurring questions to owners
Map every recurring AI question to one owner who signs its content, and record beside it which part rests on your model provider. That record is what lets you answer consistently across customers and defend an answer later.
What you own and what your provider owns
The AI Controls Matrix splits responsibility by role. An application provider, a company building end-user AI applications on top of models, is accountable for the controls in its own infrastructure and in the products and services it develops and offers. If your product calls a third-party model, that is your position: you answer for how your product sends data to the model, logs it, limits what the model can reach and puts output in front of a person. What happens inside the provider's service you can only evidence from the provider's own documents and contract.
That split changes the wording. "Customer data is not used to train models" is two claims: one about your configuration and one about your provider's terms. Write the answer so a reader can see which is which, and so the owner signs only the part they control.
The ownership map
These are the families of questions a customer asks about the AI in a product. Use the table as a starting point and set the owners to fit your organisation.
| Question family | Owner who signs | Provider's share | Evidence |
|---|---|---|---|
| Which models and providers the service uses | Product lead | Model family, versions and hosting region, from the provider's documentation | AI system description, sub-processor list |
| What customer data reaches the model and where it is stored | Data protection lead | Where the provider processes and retains data | Data-flow description, provider's data processing terms |
| Whether customer data trains any model | Data protection lead | The provider's contract terms on using inputs | Provider terms, record of your own configuration |
| How prompts and outputs are logged and who sees them | Security lead | Any logging on the provider's side | Logging and access policy, retention settings |
| How prompt injection and wrong output are tested | Security lead, with product for output quality | The provider's own published testing | Test plan, dated results |
| Where a person reviews AI output | Product lead | None: this sits in your product | Product documentation of the review step |
| Which standards back the answers | Security lead | The provider's certifications | Certificates and their scope |
Build the evidence behind each answer
Attach evidence to each AI answer before its owner approves it, because an answer the customer can't check is one it will ask about again. The standard is the same as for any defensible security questionnaire answer; what changes is the set of documents behind it.
The evidence pack
- a description of the AI system: each feature, the model and provider behind it, what it can access and what it does with its output
- a data-flow description showing what customer data reaches the model, where it is processed and stored, and for how long
- your sub-processor list, with each AI provider that handles personal data on it
- the policies the answers cite, such as AI use, data retention and access control
- the latest test results, dated, with what was found and what was fixed
- the certificates and reports you hold, such as ISO 27001, SOC 2 Type II or ISO/IEC 42001, the international standard for AI management systems
Prompt injection, wrong output and human review
Don't write that testing prevents prompt injection. The UK's National Cyber Security Centre puts the effort where an honest answer can put it: reducing the risk and impact of prompt injection and driving up resilience across AI supply chains. Word your answer the same way: what you test, when, what limits the damage if an injection succeeds, and when you last tested. A template to fill from your own test records:
We test [feature] against prompt-injection attempts [before each release and after each model change]. Testing aims to reduce the likelihood and impact of a successful injection; [what limits the feature's access or actions] restricts what an injection could reach. The most recent test was completed on [date], and a summary is available on request.
Wrong output gets the same treatment. In McKinsey's survey, nearly one-third of all respondents reported consequences from AI inaccuracy, the AI risk respondents most often experienced. Don't answer with an accuracy figure you can't measure and aren't prepared to be held to. Answer with the point where a person validates output before it's used. When a customer asks about human review, they want to see a written process, so attach it.
In SEQUESTO: SEQUESTO's agentic operating system (aOS) searches your evidence library by meaning for each AI question and ranks the matches with a confidence score from 0 to 100, where a low score names the kind of document that would close the gap. Only documents tagged as shareable are suggested for an external submission, so an internal test report stays out until someone tags it for release.
Answer questions that do not fit your product
Answer every question that doesn't fit with a reason and a pointer, never a bare "not applicable", because an unexplained N/A reads as a gap and can come back as a follow-up question. A generic question set covers several kinds of AI suppliers, so a supplier that builds on someone else's model can meet questions meant for the party that trains it, such as how training data is curated.
A misfit answer holds when it does three things: says why the question doesn't apply, says what applies instead, and carries its owner's approval. Where the question belongs to your model provider's role, say so and answer from the provider's evidence rather than leaving it blank.
For example, a supplier that doesn't train or fine-tune models might answer a question on training data curation like this:
We do not train or fine-tune models. [Feature] uses [provider]'s [model family] through its API, and the provider is responsible for the data that model was trained on. [The provider's documentation on training data] is attached.
Route answers that become contract terms to legal
Send any AI answer that states a level, a period or a promise to legal before it goes out, because a customer can carry those answers into the contract.
Whether an answer binds you is decided by the contract, not the questionnaire, so treat any promise in it as one you may be held to.
A rule for what goes to legal
Send an answer to legal if it does any of these:
- states a number or level, such as an accuracy rate, a retention period or a notification time
- promises to do or not do something in future, such as not training on customer data or giving notice of a provider change
- describes a right the customer has, such as to audit, inspect or export logs
- names where data is processed or who processes it
An answer that describes current practice, with evidence attached and no promise, needs only its owner's approval. For the rest, legal asks whether the business can keep the commitment for the life of the contract, including after the next model change.
Keep AI answers current and consistent
Re-approve an AI answer whenever something it depends on changes, without waiting for its review date, because a model upgrade or a new sub-processor can make last month's approved answer wrong. Then check that the AI answers still agree with the security answers around them.
Review on every change
AI answers depend on things that change on someone else's schedule. Record against each answer what it depends on, so that when one of these changes, you can find every answer it touches:
- the model or model version changes
- the provider changes, or adds a sub-processor
- data is processed or stored in a new region
- a policy the answer cites is updated
- a new AI feature ships
Give one person the job of watching the provider's change notices and sub-processor updates, and the authority to reopen the affected answers with their owners. Each answer still keeps an owner and a review date, so one that no change has touched still gets checked. An answer library that records owner, evidence and review date is where those dependencies live.
Line up with your standard security answers
The same reviewer reads the AI section and the rest of the questionnaire, and the frameworks overlap. CSA's FAQ on the AI Controls Matrix says the matrix incorporates elements of its Cloud Controls Matrix, ISO/IEC 42001, ISO/IEC 27001, NIST AI RMF 1.0 and BSI AIC4. Where an AI question touches access control, logging, incident response or supplier management, start from your approved ISO 27001 answer and add only what the AI feature changes. Then reuse your standard security answers with the same care, so a stale one doesn't contradict a fresh AI answer two pages later.
Where general-purpose AI helps
General-purpose AI, whether ChatGPT, Microsoft Copilot, Claude, Gemini or an in-house build on one of them, writes a decent first draft of these answers fast for whoever is typing. The team still assembles and maintains the process around the draft: the owner for each answer, the route to the security, data protection and legal leads who approve it, the approved wording with its review date and dependencies, and the record of who approved what was promised to which customer. That record is what a customer's audit clause can test, whatever drafted the words.
In SEQUESTO: each approved AI answer in the Knowledge Hub keeps its owner, review cycle and expiry date, and expired material is flagged before it reaches a draft. When a new version of a document comes in, every answer that cited the old version is flagged for review.
Checklist before the AI answers go out
Tick each statement before you sign off the AI section:
- Each AI question has been read for the customer's duty behind it, and the answer meets that duty.
- Each answer has one owner who signs its content, and the part resting on the model provider is marked as the provider's.
- Each answer has its evidence attached, and every testing answer describes reducing risk and impact rather than removing it.
- Each question that doesn't fit says why, says what applies instead and carries its owner's approval.
- Each answer that states a level, a period, a promise, a customer right or a processing location has been cleared by legal.
- Each answer records what it depends on and its review date, and agrees with the standard security answers in the same questionnaire.
Start with the AI section you sent most recently: run it against this list now, before the next questionnaire arrives and the same answers go out again.
Frequently Asked Questions
Sources
- AI Controls Matrix v1.1 – Cloud Security Alliance
- Article 26: Obligations of deployers of high-risk AI systems – European Commission (AI Act Service Desk)
- The state of AI in 2025: Agents, innovation, and transformation – McKinsey & Company
- ISO/IEC 42001 explained – ISO
- Mistaking AI vulnerability could lead to large-scale breaches, NCSC warns – National Cyber Security Centre (NCSC)
- AICM and AI-CAIQ FAQ – Cloud Security Alliance

