Help Me Answer the AI Section of a Security Questionnaire

Reviewers test four things: whether you use AI in your service, what data reaches it, what controls sit around that use and which third parties are involved. Answer each in two or three evidenced sentences naming an owner and a date. A short honest answer beats assurance language every time.

This page is for the operations, sales or compliance lead with a questionnaire open and a contract waiting, including those whose honest answer is that they are at the beginning. The patterns below come from client questionnaires, anonymised. General guidance, not legal or compliance advice.

Reviewed by Jason Holloway, Director, QL Security.

What is the AI section of a security questionnaire actually asking for?

It asks whether you have decided anything about AI, or whether AI is simply happening to you. A short accurate answer naming an owner, a policy approval date and a review cycle scores better than a page of assurance language with nobody accountable. Treat the section as a small audit of your AI governance.

How do we answer “do you use AI?” when we are not certain what our staff are using?

Answer for what you can evidence, then state the boundary. “AI is used in two places in the service: X and Y. Employee use of general-purpose assistants is governed by our acceptable use policy and restricted to approved tools.” Do not write “no” unless you have checked; a reviewer who later finds an AI feature in your product distrusts every other answer. Sales tools, support desks and developer assistants are where Shadow AI usually surfaces. Our Shadow AI discovery FAQ sets out a first pass you can complete in a week.

What if the honest answer is “we are early”?

Say so, then say what happens next with a date attached. “We do not yet hold an AI-specific certification. Our AI acceptable use policy was approved last quarter, an inventory of AI systems is maintained by the Head of Operations and a gap assessment against ISO 42001 is scheduled for Q3.”

Reviewers accept immaturity far more readily than vagueness, because immaturity with a plan is a manageable risk while vagueness is an unknown one. Commit only to what you would evidence, name the person accountable and keep dates realistic, because reviewers check them at renewal.

How specific should we be about the data going into AI tools?

Specific enough to name categories, not so specific that you publish your architecture. State the data class, the direction and the retention position: “Customer support transcripts, which may include names and email addresses, are processed by an AI summarisation feature. No special category data is permitted. Provider retention is 30 days and training on customer data is contractually disabled.” If you do not know whether your inputs train a third-party model, establish that before answering. Where the same question arises about records you already hold, our guidance on using AI on customer data covers the purpose analysis.

What controls do reviewers expect to see?

Reviewers expect five controls, roughly in priority order:

• An approved AI acceptable use policy.
• An inventory of AI systems and features.
• A human review step for consequential outputs.
• Access control and logging around AI integrations.
• A supplier assessment process covering AI providers.

Reviewers ask whether each control exists, who owns it and when it was last reviewed. Where one is absent, name the compensating measure. “No automated output monitoring; all AI-generated client deliverables are reviewed by a named consultant before release” is a legitimate answer. Our AI Security Programmes pillar shows how these controls fit together.

Do we have to declare AI subprocessors, and how far down the chain?

Declare every third party that processes customer data through an AI capability, including AI features inside tools you already list. Second-tier providers, such as the model provider behind your SaaS vendor, should be named where your contract or the vendor’s documentation identifies them. Where neither does, flag the relationship as inherited.

The common failure is a subprocessor list written two years ago that omits AI features the vendor has since switched on without a contract change. Refresh the list before you respond and record the refresh date; reviewers ask for that date next. Where onward transfer detail is unconfirmed, state what you have asked the vendor and when you expect a reply.

How should we handle questions about ISO 42001 and the EU AI Act?

Separate certification status from applicability assessment. On ISO 42001, state the position plainly: certified, in implementation with a target date, gap assessed or not yet in scope with a review date. Avoid “aligned to” unless you define what that means, because reviewers read it as unsubstantiated. On the EU AI Act, give a conclusion plus reasoning: “We have assessed our AI use as limited risk under the Act. We do not operate high-risk systems as defined in Annex III. Transparency obligations for AI-generated content are met by X.” A reasoned conclusion closes the question; a blank invites escalation.

Is “not applicable” ever a safe answer?

Only when you can state why in one line. A bare “N/A” reads as avoidance and generates a follow-up call. Write “Not applicable: we operate no automated decision-making affecting individuals”. The same applies to “confidential”: say what you can share and on what basis. Contradictions between your questionnaire, your website and your data processing agreement turn a review into a longer diligence exercise.

A deal is blocked this week. What can we realistically produce?

A defensible response set is short: a one-page AI acceptable use policy, an inventory of AI systems and features, an updated subprocessor list and consistent answers across the four themes above. Each is achievable at short notice provided someone owns it. You cannot produce a certification or a year of evidence, so claim neither. If the questionnaire is the trigger, use it as the scope for a short assessment, because the same artefacts will answer the next one. For a blocked response, contact us and we will review the actual questions.

Related reading: our FAQ on what a client’s AI policy request is really testing and the AI Security Gap Analysis service page.