How to answer the AI section of a security questionnaire honestly
The security questionnaire used to be twenty questions about encryption and backups. Now there is a section on AI, it was written by somebody with a template, and three of the questions do not quite apply to what you built. The deal is waiting on it.
Published 22 September 2026. Written by the SecHB practice, Greater Vancouver, British Columbia.
The short version
The answers that survive follow-up are the ones with an artifact behind them — a configuration, a log, a contract clause, a ticket, a report — because the second round of diligence asks for the artifact and not for the sentence. That is the whole discipline. Everything below is about knowing which artifact belongs to which question, and what to do when the artifact does not exist yet.
Which questions actually get asked?
Templates vary, but the AI section almost always lands in six groups. Working out which group a question belongs to is most of the work, because the wording is often borrowed from a framework and does not match your architecture.
| Group | What they are asking | The artifact behind the answer |
|---|---|---|
| Data handling | What leaves your environment, to whom, under what agreement, what is retained and for how long, and whether anything you send is used to train a third-party model. | The provider contract clause, the configuration showing training and retention settings, and a data-flow description per feature. |
| Model provenance | Which models are in the path, self-hosted or hosted, what version, and where any downloaded artifact came from. | A model inventory with version, source and the integrity check applied to each artifact. |
| Testing | What has been examined, against what, by whom, and when — and what was found. | The review or test report with its scope statement, plus the remediation tickets it produced. |
| Agent permissions | What the system can do without a person approving it, under whose credentials, and what the blast radius is when it acts wrongly. | The tool inventory with the permissions and identity of each, and the approval points in the flow. |
| Governance | Who owns AI risk, who approves a new use, what policy exists, and how staff are told what is allowed. | The named owner, the approval record for recent uses, and the policy with its effective date. |
| Incident process | How an AI-specific failure would be noticed, who is called, and what telemetry exists to reconstruct it. | The runbook, the on-call route, and a sample of the prompt, retrieval and tool-call logs that exist today. |
The technical groups map cleanly onto the OWASP Top 10 for LLM Applications, which is worth saying explicitly in the answer: naming the checklist you worked against tells the reviewer what your coverage was, and saves a round trip. The governance group maps onto the GOVERN function of the NIST AI Risk Management Framework (AI RMF 1.0) — ownership, policy, decision rights and the record of them.
The question about staff putting data into prompts
This one appears in almost every template and is answered badly more often than any other, usually with a sentence about employee training. The Canadian Centre for Cyber Security states the risk plainly in ITSAP.00.041: Users may unknowingly provide sensitive corporate data or personally identifiable information (PII) in their AI queries and prompts.
Its guidance to individuals is equally direct — Do not share private information with AI tools unless you understand what they are doing with your data.
A reviewer reading your answer is testing whether you have a control or a hope. Training is a hope. A sanctioned tool that staff can actually use, an agreement with the provider covering retention and training, and a technical boundary that makes the unsanctioned route inconvenient — those are controls, and they are what the answer should describe.
How to answer honestly when the answer is no
A no with a date beats a yes that falls apart. The pattern that works has four parts and fits in a small box: what is true today, what compensates for the gap, what is planned, and by when.
For example, where no testing has been done: say that the feature has been reviewed against a named checklist and describe what that covered, name the compensating control if one exists, and give the quarter in which testing is scheduled. A reviewer can accept that. What a reviewer cannot accept is discovering in month three that “yes, tested annually” meant a scan of the marketing site.
Two things to keep off the page entirely. Do not claim a credential you do not hold, and do not let a supportive adjective do the work of a fact — “enterprise-grade” and “industry-standard” are read by professional reviewers as the absence of a specific answer.
Writing a roadmap commitment you can keep
A commitment in a questionnaire is a representation, and it often ends up attached to a contract. Three rules keep that from becoming a problem. Name a quarter rather than a month, because a month you miss by three weeks is a broken promise and a quarter is not. Name the outcome rather than the activity, because “a written AI use policy in force” is checkable and “working towards improved AI governance” is not. And do not commit to anything that depends on a third party doing something.
Where the questionnaire feeds contract language, warranty or representation wording is work for the client’s counsel, not for the security team and not for this page.
The answer patterns that cost deals
- Vagueness. An answer with no noun in it. Reviewers are trained to read this as “no”, and they are usually right.
- Borrowed vendor language. Pasting your model provider’s security page into an answer about your own system. Reviewers recognize it, and it raises the question of what else was copied.
- Claims about the provider you cannot substantiate. Only as far as your contract with them says, and you should quote it rather than paraphrase it. What you can answer for is your own configuration: which model and version you call, what you send it, what you have turned off, and what your agreement says about retention and training.
- Answering a question you were not asked. A long paragraph about infrastructure security where the question was about model provenance reads as evasion.
- Inconsistency across deals. Two answers to the same question, six months apart, that contradict each other. Buyers share templates.
Keeping the answers current
The sustainable version of this is one maintained source of answers rather than a new document per deal: one row per question, the current answer, the artifact it points to, the date it was last confirmed, and the owner. Reviewed when a model changes, a tool is added, or a quarter passes.
Two failure modes to watch. The first is answers that quietly go stale because the system changed and the document did not — which is why the date and the artifact pointer matter more than the prose. The second is a questionnaire answered entirely by the sales team from an old copy, which is how a false statement reaches a customer with nobody intending it.
Say so, and answer the underlying question instead. A buyer asking about an AI policy wants to know whether AI use here is deliberate; an accurate list of sanctioned uses, the named owner who approves new ones, and a date for the written policy beats a borrowed document nobody follows. Not always, but you do need a truthful answer about what has been examined and by whom. A review against a named checklist, with findings and a remediation plan, answers most testing questions; where the buyer specifically wants proof an attack was attempted, only testing produces that, and it is carried out only with signed authorization.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
Testing and adversary simulation are carried out only with signed authorization, to a scope agreed in writing.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
Can we answer on behalf of our model provider?
Only as far as your contract with them says, and you should quote it rather than paraphrase it. What you can answer for is your own configuration: which model and version you call, what you send it, what you have turned off, and what your agreement says about retention and training.
What if we have no AI policy yet?
Say so, and answer the underlying question instead. A buyer asking about an AI policy wants to know whether AI use here is deliberate; an accurate list of sanctioned uses, the named owner who approves new ones, and a date for the written policy beats a borrowed document nobody follows.
Do we need a test report to answer the testing question?
Not always, but you do need a truthful answer about what has been examined and by whom. A review against a named checklist, with findings and a remediation plan, answers most testing questions; where the buyer specifically wants proof an attack was attempted, only testing produces that, and it is carried out only with signed authorization.
What makes an answer survive follow-up?
The answers that survive follow-up are the ones with an artifact behind them — a configuration, a log, a contract clause, a ticket, a report — because the second round of diligence asks for the artifact and not for the sentence.
Where to go from here
If the governance answers are the weak ones, AI governance readiness builds the owner, the policy and the record. If you cannot list what AI is in use, AI use discovery and vendor risk comes first, because every other answer depends on the inventory. If the technical answers are the weak ones, an AI security assessment produces them, and what an assessment covers says what to expect from it. The evidence pack is the deliverable that keeps the artifacts together. Other pieces are indexed under Writing.
Send the AI section and a description of what you have built, and the reply will say which answers need an artifact before they go back.