Every AI vendor questionnaire your procurement team sends in 2026 is a governance document: it decides where your data can travel, which fourth parties can touch it, and whether a model is quietly learning from your customers — and most questionnaires still ask the questions that mattered for SaaS in 2019.
Why AI vendors break the classic third-party risk model
The classic vendor risk model assumed a stable product: a vendor ships version N, it gets assessed, the assessment holds for a year or two. AI products violate every clause of that assumption. The model behind the API can be replaced without a version you control. The vendor's model can change behaviour — tone, refusal patterns, factual reliability — through a silent update or a safety retraining. Your prompts and files can, under some contracts and configurations, become part of the vendor's training corpus. And a single AI product may chain several models and data services across several jurisdictions, meaning your "vendor" is actually a supply chain.
The consequences show up in the breach data. IBM's Cost of a Data Breach (2025) puts the global average at roughly USD 4.4 million, and breaches that originate in third-party or supply-chain compromise consistently take longer to identify and contain — because the victim organisation lacks visibility into someone else's environment. Gartner (2025) has repeatedly estimated that third-party-related security incidents are among the fastest-growing breach categories. Meanwhile, regulation is catching up to the pattern: the EU AI Act's staged obligations (2024 onward) impose deployer duties, the HKMA's supervisory expectations (2024 onward) treat outsourced AI much like outsourcing itself, and data-protection authorities increasingly ask who processed what, where, and under which lawful basis.
The organisational failure this exposes is a boundary problem, not a tooling problem. Security teams own the questionnaire; AI adoption often runs through business units buying tools with credit cards; and data governance sits somewhere in between. In most mid-sized firms we observe, a meaningful share of AI tools in daily use never went through any assessment at all. The framework below assumes one design principle: the questionnaire is only worth what its enforcement mechanism is — every question must map to a contract clause, a technical control, or a reason to walk away.
Enforcement starts with inventory, because you cannot assess what you have not found. Before sending a single new questionnaire, most CISOs should run a discovery pass over what is already in use: SSO logs and SaaS-management exports will surface AI tools the security team never knew about, and the results are usually sobering — tools with customer data in them, no DPA signed, no exit clause. Rank the discovered tools by data sensitivity times usage depth, then push the assessment effort down that ranking. The framework below applies to new procurement, but in practice its first six months are usually spent retrofitting it onto an inherited estate — and that retrofit is where most of the actual risk reduction happens.
The unit of assessment is no longer the vendor; it is the data flow. Ask where a specific field of your data can travel, and every other question becomes concrete.
The questionnaire, part one: data residency and retention
Start with the questions that determine the blast radius of any future incident: where does the data physically and legally live, and how long does it persist.
Residency. Ask where inference happens (which regions the processing endpoints run in), where storage happens, where backups live, and where support staff with data access sit. These are four different answers and vendors conflate them unless you ask separately. For a Hong Kong-headquartered firm, the practical standard is: processing and storage in-region by default, cross-border transfer only with named jurisdictions and a documented transfer mechanism. Pin the answer to the contract — "we generally support in-region processing" is not an answer; a clause stating processing regions for your tenancy is.
Retention. The retention question has three layers that questionnaires routinely merge into one, and the distinction changes your risk materially. Input retention: how long are your prompts, uploads and queries stored after processing? Output retention: are responses logged? Operational retention: logs, telemetry, error traces and — the layer most often overlooked — backups, which have their own lifecycle and often their own region. Get each layer's duration and deletion mechanics in writing: is deletion on demand possible, is it verified, and does it propagate to backups within a stated window? A vendor that cannot state a concrete number of days for each layer is telling you their data lifecycle is unmanaged.
| Question | What a good answer looks like | What a vague answer hides |
|---|---|---|
| Where does inference run? | Named regions for our tenancy, contractual commitment | "Global infrastructure with smart routing" |
| How long are inputs retained? | Concrete days per data type; deletion on request with verification | "Only as long as necessary" |
| Where do backups live? | Same region or named list; backup deletion window stated | No answer — backups usually outlive production deletion |
| Who can access production data? | Named role count, background checks, access logging | "Access is restricted" — restricted by whom, logged where? |
The questionnaire, part two: sub-processors and training on your data
These two topics generate the most contractual friction, and rightly so — they are where your data acquires a life outside your control.
Sub-processors. An AI product is almost always a chain: the vendor you contract with may call a foundation-model provider, a vector-database service, a transcription service, a cloud platform, and a support-ticketing tool with your screenshots in it. Demand the full sub-processor list — entity names, processing purpose, processing locations — and two rights that matter more than the list itself: advance notification of changes (30 days is the workable standard) with a right to object, and flow-down of security obligations so the vendor, not you, carries the contractual responsibility for its fourth parties. Review the list annually and after every notified change. A vendor who cannot enumerate its own chain is not a vendor you can defend in front of a regulator or an insurer.
Training on your data. The question is not "do you train on customer data" — it is a decision tree. Ask, in order: (1) Is any of our content — prompts, files, queries, feedback — used for model training or fine-tuning, by default or opt-in? (2) If not used for training, is it used for any other model improvement, including human review, prompt analytics, or evaluation sets? (3) If human review exists, who reviews, under what confidentiality terms, and can we opt out? (4) Are customer tenancies isolated such that our content can never appear in another customer's outputs? Each "yes" needs a contractual boundary, a technical mechanism and an opt-out. The 2026 default posture for most enterprises is zero training use, human review opt-out exercised, and the vendor's contractual commitment to non-training put in writing — because vendor UI toggles and product roadmaps change faster than contracts do.
The cross-border wrinkle in the GBA context deserves its own sentence: a vendor that trains in one jurisdiction and serves another may lawfully move your content through regions your data policy never contemplated. Residency (part one) and training (part two) must therefore be answered jointly — "we don't train on your data, but we route it through three continents for inference" is not a clean answer either.
Access control: SSO, RBAC and the principle you can actually enforce
Access questions are the ones you can verify technically rather than take on faith, which makes them the highest-yield part of the assessment.
SSO and identity. SAML or OIDC single sign-on against your identity provider should be a non-negotiable for any tool touching internal data — it converts offboarding from a ticket-and-pray process into an automatic one, and it puts authentication logs in a system you own. Ask which SSO features sit behind which pricing tier: vendors routinely gate SAML for enterprise plans and leave mid-market customers with shared passwords, and that tier boundary is itself a risk decision you should make consciously. SCIM or automated user provisioning closes the loop; without it, your SSO and the vendor's internal access control drift apart within months.
RBAC granularity. "Admin and user" is not role-based access control. The questions that matter: can roles be scoped to data domains (this team sees only its data), to actions (view, export, administer), and to AI-specific capabilities — because in AI products, model access is an access class of its own. Who can create or edit prompts? Who can connect new data sources to the model? Who can export conversation history? A product where every user can attach any data source to any query has effectively made every user a data administrator, whatever the RBAC page in the marketing deck says.
Audit logs. The log standard is the same reconstructability test used in any serious security programme: who did what, to which data, when, from where — covering authentication events, data access, exports, admin changes and model interactions. Ask where logs live, how long they are retained, whether you can stream them to your own SIEM, and whether they are immutable. If log retention is shorter than your incident-investigation horizon, you are funding the vendor's storage savings with your own forensics capability.
Two AI-specific access questions complete this section, and both are easy to underestimate. First, data-source connection: who can attach new data repositories to the model, and is there an approval path — because in conversational AI products, the permission to connect a repository is functionally the permission to expose everything inside it to every prompt the connector allows. Second, egress control: what does the product's export surface look like — bulk download, API pull, copy-to-clipboard — and can it be rate-limited or integrated with your DLP? A retrieval product that summarises ten thousand documents into one chat window has changed your exfiltration math, and your access-control review should say so explicitly rather than treating the product as ordinary storage.
Breach history, incident response and vendor stability
Security questionnaires tend to ask "have you ever had a breach" and receive the answers the form was designed to receive. Better questions produce better signal. Ask for a summary of security incidents over the past 24 months including near-misses and responsible-disclosure reports — vendors who can discuss incidents candidly have an incident culture; vendors who answer "none" to everything have a form culture. Ask how notification timelines align with your regulatory clock: under Hong Kong's data-protection expectations and the contractual norms of 2026, you need notification to you fast enough that you can meet your own downstream obligations — 24 to 72 hours is the defensible range to contract for.
Incident response maturity shows in specifics: is there a named security officer, a tested response plan, a bug-bounty or external pen-test programme with a summary report you may see, and a SOC 2 Type II or ISO 27001 certificate — with the report or statement of applicability actually reviewable, not merely citable? The certificates matter less than your right to read what is behind them. For AI-specific incident classes, ask how the vendor handles model-abuse reports (their product being used for fraud or disinformation) and model-failure reports — an AI vendor without an answer for its own model misbehaving has not thought about its product the way you think about risk.
Vendor stability rounds out the picture, because the fastest-growing risk in AI tooling is not breach but abandonment: a funded startup pivots, deprecates the product, and your data and workflows are in a winding-down platform. IBM's (2025) supply-chain findings apply here with a twist — the third-party risk that costs the most is not always compromise; sometimes it is custody loss. Ask for financial-stability indicators you can reasonably obtain, data-egress guarantees in machine-readable formats, and, for smaller vendors, a source-code or data escrow conversation. If the answers get vague, that is signal too.
Scoring rubric: turning answers into a decision
A questionnaire produces text; a rubric produces a decision. Weight the domains by the blast radius of their failure, not by how easy they are to verify. The weights below reflect a common enterprise posture for tools that touch sensitive internal data — adjust for your context, but keep training use and residency as the highest-weighted items, because they are the hardest to remediate after the fact.
| Domain | Weight | 5 — Strong | 3 — Acceptable | 1 — Fail |
|---|---|---|---|---|
| Training on your data | 25% | Contractual non-training, tenancy isolation, verified | Training disabled by default, opt-out available | Training use by default, or answer evasive |
| Data residency & retention | 20% | Named regions in contract; retention days specified per data type | Regions documented in policy only; retention partial | No regional commitment; "as long as necessary" |
| Sub-processors | 15% | Full current list, 30-day change notice, flow-down obligations | List provided; no change-notification right | Cannot enumerate chain |
| SSO / RBAC | 15% | SAML/OIDC + SCIM on your tier; AI-specific role scoping | SSO available; two-tier RBAC only | Shared-credential access; no role model |
| Audit logs | 10% | Immutable, SIEM-streamable, retention ≥ your investigation horizon | Exportable logs; limited retention | Logs internal-only or absent |
| Incident response | 10% | Tested plan, contractual 24–72h notice, evidence reviewable | Plan exists; notification timing undefined | No named officer; "none" to everything |
| Vendor stability | 5% | Escrow/egress guarantees; sustainable funding | Egress documented; stability unverifiable | No egress commitment |
Apply two scoring rules the table cannot encode. First, any single domain scoring 1 caps the overall decision at "pilot only with compensating controls" or "reject" — a brilliant product with unresolved training-use terms is still unresolved. Second, evidence beats attestation at every step: a policy PDF is worth 2, a contract clause worth 3, a technical verification (your own log inspection, a test deletion request you actually track) worth 5. Rubrics fail when they reward articulate vendors; verification is the antidote.
Red flags, compensating controls and the cadence
Some answers should end the conversation. The red-flag list that practitioners converge on: refusal or inability to commit to non-training on your data in the contract; no sub-processor list or no change-notification right; retention expressed only as "as long as necessary"; no SSO on your pricing tier for a tool that touches internal data; audit logs you cannot access; SOC 2 claimed but report unreviewable; and any pattern of answers that read like marketing rather than security documentation.
Not every flag must end the relationship — some should reshape it. The compensating-control pattern for a vendor you want but cannot fully trust: restrict the tool to non-sensitive data domains by policy and by network controls; disable file upload and confine usage to structured queries; run it under a dedicated tenancy with your own SSO and log streaming; and set a re-assessment date tied to the vendor closing the gap. Make the trade-off explicit and time-boxed, in writing, to the business owner who wants the tool — risk acceptance is legitimate only when a named person owns it.
One last application of the rubric that is easy to forget: it should also govern renewals, not just new purchases. The vendor who scored 4s two years ago may have been acquired, repriced, or rebuilt on a different foundation model — a renewal that auto-signs without re-running the high-weight domains is the single most common way a well-governed estate drifts into an ungoverned one. Put the rubric results into the procurement calendar as a renewal precondition, the same way insurance certificates are handled in facilities management.
Finally, the cadence, because assessment decays. Stanford HAI (2025) documents how quickly models and products change under AI-market pressure; an annual questionnaire cycle is too slow for a category where behaviour can change monthly. A workable 2026 rhythm: full assessment before first contract; automated log and configuration review continuously; sub-processor list re-check on every notified change; abbreviated re-assessment every six months for high-weight domains (training use, residency, retention); and a full re-assessment on any material product change, acquisition or price-tier shift. Gartner (2025) estimates that third-party incidents will keep climbing as AI adoption deepens — the organisations that treat vendor assessment as a standing control rather than a procurement gate are the ones that find out before the regulator does.
