How to Answer the AI Questions on Security Questionnaires

Enterprise security questionnaires in 2026 converge on three AI questions: does customer data train your models, which model providers sit behind your product as sub-processors, and what AI governance framework do you follow. You do not need an ISO 42001 certificate to answer them. You need four documented artifacts: an AI usage policy, an inventory of your AI features and the models behind them, a current sub-processor list that names your model providers, and a short written statement of alignment to a named framework such as the NIST AI Risk Management Framework. The thing that actually stalls a review is having nothing written down, not lacking a certificate, and the fastest way to lose a week is to answer these questions from memory in a spreadsheet cell.

This article covers what each question is really asking, how to word the answer, what evidence to attach, and what to do when the honest answer is bad.

Key takeaways

• Three questions dominate: training data, model sub-processors, and governance framework.
• Four artifacts clear most reviews: AI policy, AI system inventory, sub-processor list naming model providers, and a written framework alignment statement.
• A certificate is rarely the blocker. Documented alignment usually is enough, and nothing written down never is.
• Answer once, centrally, and reuse. Divergent answers across two questionnaires are worse than a weak answer given consistently.
• If the honest answer is bad, say so with a remediation date. Discovered later, a confident wrong answer is a contract problem.

Question one: does our data train your models?

This is the question reviewers care most about, and it is the one most often answered wrongly by accident, because the person filling in the questionnaire is not the person who configured the API call.

Answer it in three parts. First, whether customer data is used to train or fine-tune any model you control. Second, whether customer data is sent to a third-party model provider at inference time, which is a different question and is almost always yes for anyone using a foundation-model API. Third, what contractual and configuration controls prevent that provider from training on it. Every major model provider publishes enterprise data-usage and retention commitments; cite the provider's own published terms rather than paraphrasing them, and link the reviewer to the page.

The wording that clears reviews is specific and bounded. "Customer content is not used to train or fine-tune any model. Customer content is transmitted to [provider] at inference time under our enterprise agreement, which excludes it from provider training, with a retention window of [X] as documented at [link]." The wording that fails is "we do not train on customer data," full stop, when your product sends prompts containing customer data to somebody else's API. Reviewers notice, and the follow-up costs you more time than the precise answer would have.

Go and check the configuration before you answer. This is the single most common place we see a good-faith wrong answer, because the default settings on some APIs are not the ones the sales team believes are in place.

Question two: which model providers are your sub-processors?

This one is administrative, and it is failed administratively.

If you call a third-party model, that provider is processing customer data on your behalf, and it belongs on your sub-processor list with everyone else. Reviewers under GDPR obligations need it for their Article 28 chain, and reviewers with no European exposure at all now ask anyway because model providers have become the most-scrutinized category of vendor in the stack.

Publish the list at a stable URL, name each provider, state the processing purpose, state the data categories, and state the processing region. Add a change-notification mechanism, because most enterprise data processing agreements require notice before you add a sub-processor, and adding a model provider mid-contract without notice is a real breach of a real term rather than a paperwork nicety.

Two failure modes to avoid. The first is a sub-processor list that names your cloud provider and your email tool but not the model API your core feature depends on, which reads as either carelessness or concealment. The second is naming the provider but not the region, which stalls any reviewer with a data-residency requirement.

Question three: what AI governance framework do you follow?

Reviewers ask this to find out whether AI risk is governed at all, and a short honest answer beats an aspirational one.

If you have nothing, the cheapest true answer to get to is NIST AI RMF alignment. The framework is free, it is structured around four functions (Govern, Map, Measure, Manage), and a written alignment statement mapping your controls to those functions is an artifact you can produce in weeks rather than months. If you hold an ISO/IEC 42001 certificate, say so and attach it. If you are mid-implementation, say that, with the target date, and do not imply the certificate exists.

What reviewers will not accept is a framework named without evidence. "We follow the NIST AI RMF" with nothing behind it invites the follow-up question that costs you the week. Attach the statement, the policy and the inventory, and the question usually ends there. We work through how the two frameworks differ, and when a certificate is genuinely required, in NIST AI RMF vs ISO 42001: Which Do You Need?.

One thing to be clear about internally: a SOC 2 report is not an answer to this question. It is strong evidence of general security control, and reviewers want it, but the AICPA Trust Services Criteria contain no AI-specific criteria. We cover what auditors do and do not test in Does SOC 2 Cover AI? What Auditors Now Test.

The four artifacts, and what each has to contain

AI usage policy. Approved tools, data rules mapped to your classification tiers, prohibited uses, human review requirements for AI output, a vetting path for new tools, and one named owner. Two pages is the right length. Reviewers read the first page and check that the owner exists.

AI system inventory. Every AI feature in your product, the model behind it, whether that model is yours or a third party's, what data it processes, whether any output drives an automated decision, and who owns it. This is the artifact that makes the other three answerable, and it is the one companies most often do not have.

Sub-processor list. As above: stable URL, providers named, purposes, data categories, regions, change notification.

Framework alignment statement. Two to four pages mapping your existing controls to the four AI RMF functions, with honest gaps named. A statement that claims full coverage of a framework you adopted last quarter is less credible than one that names three open items with dates.

Keep all four in one place, keep them current, and route every questionnaire through the same source. The most avoidable failure we see is two questionnaires answered by two people three weeks apart, giving materially different answers about the same product, and the reviewer who notices is the one who was going to sign.

Formats you will actually be sent

The questionnaires themselves have caught up with AI faster than most respondents have.

The Cloud Security Alliance's AI Controls Matrix reached version 1.1 in July 2026 with 247 control objectives across 18 domains, accompanied by a 320-question AI-CAIQ self-assessment questionnaire. The Shared Assessments SIG has carried AI content for some time as well. So the common claim that the standard instruments have no AI questions is simply out of date, and if you are told otherwise, check the version.

What has not changed is that 320 questions produce fatigue rather than signal, and most reviewers will accept a completed AI-CAIQ, a filled SIG, or your own four artifacts plus a call. Offer the artifacts first. They are cheaper for you to maintain and easier for the reviewer to read than a spreadsheet nobody finishes.

What to do when the honest answer is bad

Sometimes customer data is in a training set. Sometimes there is no policy. Sometimes an AI feature makes a decision with no human in the loop and nobody wrote that down.

Say so, in writing, with what you are doing about it and by when. A reviewer who receives "partially implemented, policy in draft, target 30 November" can risk-accept it, escalate it, or ask for a contractual commitment. A reviewer who receives a confident yes and then discovers the truth during a later audit or an incident has a contract problem, and so do you, because that answer usually lives inside a representation in the agreement.

This is not a moral point, it is a commercial one. The deals that die are rarely the ones with a gap disclosed early. They are the ones where the gap surfaced after signature.

When you should not build any of this yet

If you have no AI in your product and no employees using AI tools on customer data, you do not need an AI governance program, and you can answer these questions with one accurate sentence saying so. Some vendors will still try to sell you a program. Decline.

If your AI exposure is entirely employees using public chatbots, the correct scope is an acceptable use policy and a tool allowlist, not a management system and not a certification. That is days of work.

And if a single customer is asking, ask them what evidence they will accept before you build anything. In more of these conversations than you would guess, the answer is a policy and a sub-processor disclosure, and the program someone quoted you was scoped for a question nobody asked.

Where Top Floor fits

We build these four artifacts as a bounded piece of work, not as an open-ended program: the policy, the inventory, the sub-processor disclosure and the NIST AI RMF alignment statement, sized to what a reviewer actually reads. Where a customer has genuinely named a certificate, our ISO 42001 practice picks it up from there.

For companies answering these questionnaires continuously rather than once, compliance as a service covers keeping the answers current, which is the part that decays fastest: model providers change, features ship, and the inventory quietly stops matching production.

How to decide this week

• Pull the last three questionnaires you answered and compare the AI answers. If they disagree, fix that before anything else.
• Verify your model provider configuration against what you have been telling customers. Check the setting, do not ask the vendor's sales team.
• Publish or update the sub-processor list, with regions, at a stable URL.
• Draft the AI policy to two pages and give it a named owner.
• Write the framework alignment statement, and name the gaps with dates rather than claiming coverage you do not have.

Frequently asked questions

Do I need ISO 42001 to pass an enterprise AI security review?

Usually not. Most enterprise reviewers are trying to establish that AI risk is governed and that their data is not training somebody's model, and four documented artifacts answer that: an AI usage policy, an AI system inventory, a sub-processor list naming your model providers, and a written statement of alignment to a named framework such as the NIST AI RMF. A certificate becomes necessary when a customer, regulator or partner names one specifically, which does happen and is worth asking about directly. What never works is naming a framework with no evidence behind it.

How should I answer "do you train on customer data"?

Answer it in three parts, because the question hides three. State whether customer data trains or fine-tunes any model you control; state whether customer data is sent to a third-party model provider at inference time, which is almost always yes if you call a foundation-model API; and state the contractual and configuration controls that stop that provider training on it, linking the provider's own published data-usage terms. Verify the configuration before you answer rather than trusting what the product team believes is set, because a good-faith wrong answer here is the most common failure we see and it lives inside a contractual representation.

Are AI questions part of standard security questionnaires now?

Yes. The Cloud Security Alliance published AI Controls Matrix v1.1 in July 2026 with 247 control objectives across 18 domains and a companion 320-question AI-CAIQ, and the Shared Assessments SIG carries AI content as well, so the claim that the standard instruments lack AI coverage is out of date. The practical problem is length rather than absence: a 320-question self-assessment is heavy for both sides, and most reviewers will accept a well-maintained set of core artifacts plus a call instead.

What do I say if we have not written anything down yet?

Say that, name a date, and start with the inventory. An honest "in progress, policy in draft, target date X" can be risk-accepted, escalated or made contractual by the reviewer; a confident yes that unravels during a later audit or an incident is a contract problem rather than a compliance one. Deals rarely die because a gap was disclosed early. They die when the gap surfaces after signature.