The AI section your vendor security questionnaire is missing

Standard questionnaire frameworks — whether built on the Shared Assessments SIG, CAIQ, or a bespoke internal template — share a common design assumption: the vendor processes data using defined software logic, and the security review is about how that logic and its supporting infrastructure are protected.

That assumption breaks down for AI vendors in three specific ways. First, the “software logic” of an AI product includes a model whose behaviour can change independently of the product's versioning cycle. A vendor can update the underlying model — changing its capabilities, its failure modes, and its data handling at inference — without any corresponding change to the software version number.

Second, the data processing agreement covers how the vendor processes customer data in its systems. For an AI vendor, customer data may also be processed by a third-party model provider that is not a named party to the DPA. The subprocessor disclosure clause in a standard DPA typically covers infrastructure subprocessors; it may not capture an AI model provider whose infrastructure receives inference requests containing customer data.

Third, standard questionnaires ask about incident notification — but “incident” in that context means security incidents: data breaches, unauthorised access, system outages. For AI vendors, a material change in model behaviour — the model starts producing outputs it previously would not, or stops producing outputs it previously did — may be operationally significant to customers without triggering any of the conditions a standard incident notification clause is written to cover.

The AI gap in vendor questionnaires is the set of questions that standard frameworks were not designed to ask. It covers four domains: model governance, AI incident notification, re-assessment rights, and AI-specific data handling.

Each domain addresses a risk that is specific to AI systems and has no adequate proxy in conventional security review. A vendor can answer every question in a standard questionnaire accurately and completely — and leave every one of these risks unaddressed.

The four domains below are not exhaustive — there are additional AI-specific risks that matter in specific deployment contexts — but they represent the minimum set of questions that every vendor questionnaire should include when the vendor's product includes an AI component.

Model governance questions address who decides how the model changes and what notification process exists when it does. These questions have no equivalent in standard questionnaires because software versioning is assumed to track all material product changes.

The specific questions to add:

• Model identity: What model or models power the AI component of this product? Specify provider, model family, and version.
• Change authority: Who within your organisation has authority to change the underlying model? What internal approval process governs a model change?
• Change frequency: How frequently do you update the model powering this product? Do model updates follow the same release cadence as software updates, or are they managed on a separate schedule?
• Material change definition: How do you define a material model change? What changes — base model switch, major version upgrade, fine-tuning dataset change, significant capability addition or removal — would you classify as material?
• Customer notification: What is your process for notifying customers of a material model change? What notice period do you provide?

These questions establish the vendor's model governance baseline. A vendor with no defined model change approval process or no customer notification procedure for model updates presents a re-assessment risk: the security review that justified the original deployment may become stale without the customer's knowledge.

Standard incident notification questions cover data breaches and system outages. AI vendors need an additional tier: notification for model behaviour changes that affect customers.

The specific questions to add:

• AI incident definition: How do you define an AI incident? Does your incident classification include model behaviour changes, unexpected output patterns, or capability degradation?
• Behaviour change notification:If the model's behaviour changes in a way that materially affects outputs — whether through a model update, a discovered misalignment, or a third-party provider change — what notification obligation do you have to customers, and within what timeframe?
• Third-party model incidents: If the third-party model provider powering this product has a security incident, model change, or service disruption, what is your process for notifying affected customers?
• Historical AI incidents: In the past 24 months, have you experienced any model behaviour incidents — unexpected or harmful outputs, model degradation, or discovered capability misalignment — that affected customers? If so, what was the impact and how was it resolved?

The re-assessment clause is the most important addition to a vendor questionnaire for AI products. It establishes the customer's right to request updated security information when the vendor's AI system changes materially.

Without a re-assessment clause, a security review justifies deployment at a point in time. With one, the review remains valid against a defined set of conditions — and the customer has a contractual right to refresh the assessment when those conditions change.

The specific questions to include in the questionnaire, which should translate into contractual commitments:

• Re-assessment right: Does your agreement with customers include a right to request updated security information following a material model change?
• Response commitment: If a customer requests updated AI security documentation following a model change, what is your committed response time?
• Model version logging: Do you provide customers with a record of which model version was in use at any given point in time? This is relevant for incident investigation and evidence record maintenance.
• Assessment documentation: What AI security documentation do you make available to customers — model cards, red-team summaries, capability evaluations, alignment documentation?

The answers to these questions should determine whether the vendor assessment includes a re-assessment trigger in the disposition record — specifically, a trigger that fires when the vendor makes a material model change.

Standard data handling questions in vendor questionnaires cover processing location, encryption, retention periods, and deletion rights. For AI vendors, additional questions are required to cover the AI-specific data handling risks.

The specific additions:

• Training data use: Is any customer data — including prompts, completions, user interactions, or uploaded documents — used to train, fine-tune, or evaluate your model or any third-party model that powers your product? If yes, describe the process, the legal basis, and the opt-out mechanism.
• Inference data retention: How long is inference data — prompts sent to the model and completions returned — retained by your system? By any third-party model provider you use?
• Inference data access: Who within your organisation, and within any third-party model provider you use, has access to inference data containing customer content?
• Subprocessor AI chain: Provide a complete list of third-party model providers or AI infrastructure providers that receive customer data as part of the inference process. For each, describe what data they receive, how long they retain it, and whether customer data is used in their model training.

The questions in the previous sections should be added as a dedicated AI Security Supplement to your standard vendor questionnaire. The supplement should apply to any vendor whose product includes an AI component — whether the AI is the primary product feature or an embedded capability in a broader platform.

The supplement should be triggered by a flag in the standard questionnaire intake process: “Does this product include an AI component that processes customer data or makes recommendations that influence business decisions?” If yes, the AI Security Supplement applies.

The supplement does not replace the standard questionnaire — it adds to it. The standard questionnaire continues to cover infrastructure security, access controls, incident response, and data handling. The supplement covers the AI-specific layer that the standard questionnaire cannot reach.

Responses to the supplement should be evaluated against the same standard as the rest of the questionnaire: factual, specific, and verifiable. Vague answers — “we take model governance seriously”, “we follow industry best practices for AI safety” — are not acceptable responses to questions about specific governance processes, notification timelines, or contractual rights. Flag them as incomplete and request specifics.

The disposition record for the vendor assessment should document whether the AI Security Supplement was completed, what the vendor's responses indicated about their AI governance maturity, and what re-assessment trigger has been registered to track material model changes going forward. A vendor that cannot answer the model governance and re-assessment questions is a vendor whose AI component will not remain within the scope of any security review that justified its approval.

For organisations looking to go further, the supplemental assessment for AI features embedded in existing SaaS products — where the original vendor review predates the AI component — is covered in Assessing the AI feature inside SaaS you already bought.