The 5 Questions Most Vendor Security Questionnaires Don't Ask

The Checklist Trap

Most organisations send a vendor security questionnaire and call due diligence done. You know the drill. A 200-question spreadsheet lands in a procurement inbox, someone ticks boxes for SOC 2, ISO 27001, and encryption at rest, and the vendor gets a green light. If you're doing AI procurement this way, you're asking the wrong questions.

Standard infosec questionnaires were built for SaaS. They ask about firewall rules, access controls, and patch management. They were not built for systems that learn from data, update themselves autonomously, and route prompts through chains of third-party processors you've never heard of. The gap between what these questionnaires ask and what actually matters for AI risk is wide enough to drive a regulatory finding through.

ISO/IEC 42001:2023, the international standard for AI management systems, dedicates its entire Annex A to controls that most procurement teams never think to audit. The NIST AI Risk Management Framework maps similar ground. And regulators are paying attention. APRA's CPS 234 already requires regulated entities to manage information security risks across their supply chain, and AI vendors sit squarely in that chain.

Here are the five questions your current questionnaire almost certainly doesn't ask, and why each one matters more than the 200 you're already sending.

Question 1: Where Did Your Training Data Come From, and Can You Prove It?

Vendors love talking about model accuracy. They rarely volunteer where the training data originated. This matters in ways that accuracy benchmarks don't capture. Was the training data scraped from public websites without consent? Does it include copyrighted material, personal data from jurisdictions with strict privacy laws, or synthetically generated data that inherited biases from its own parent model?

ISO 42001 Annex A controls require organisations to maintain documented information about AI system resources, including data provenance and lineage. If your vendor can't produce a training data manifest that traces data sources through to the model you're licensing, they're not compliant with the standard's operational planning requirements. They might not even know what's in there.

Ask for a data provenance statement that covers source, licensing, filtering methodology, and any third-party datasets incorporated. If the vendor built their model by fine-tuning on a foundation model (GPT-4, Claude, Llama), ask for the provenance statement for those base models too. Most vendors will struggle with this. The ones who have it ready are the ones who've done the work.

Question 2: What Is Your Model Update Cadence, and How Do You Validate Retrained Models Before Deployment?

Software gets patched. AI models get retrained. The difference is that a model update can silently change behaviour across every output, including outputs in regulated domains where accuracy was previously validated. If your vendor retrains quarterly, every three months you're effectively running a new system that hasn't been through your risk assessment.

ISO 42001 requires organisations to plan and control changes to AI systems, including changes to models, data, and algorithms. The NIST AI RMF's Govern function explicitly maps the need for ongoing monitoring and validation after deployment. Standard questionnaires ask about change management for infrastructure. They don't ask about change management for model weights.

The question to ask here is specific: "Describe your model versioning policy. How do you test retrained models against previous versions before release? Do we get a regression test report comparing model performance on our use case?" If the answer is "we run standard benchmarks and ship it," you have a supplier who doesn't understand operational AI risk. Benchmark scores on generic test sets tell you nothing about whether your specific workflow still produces compliant outputs after an update.

Question 3: Who Are Your Subprocessors, and Do Any of Them Have Access to Our Inference Data?

This is where the AI supply chain gets genuinely opaque. Your vendor might contract with a cloud provider for compute, a model routing service for fallback, a content moderation API for output filtering, and a logging platform for observability. Each link in that chain may receive your inference data, prompts, and outputs, processed outside the jurisdiction you negotiated in the contract.

Standard vendor questionnaires ask about subprocessors in the context of data hosting. They rarely capture the AI-specific subprocessor layer: the vector database that stores your embeddings, the evaluation platform that scores your outputs, the fine-tuning service that processes your feedback data, the human review team that reads flagged prompts. Each of these is a subprocessor under ISO 42001's operational control requirements and under privacy regulations like the Privacy Act 1988 for Australian entities or GDPR for European data subjects.

Ask for a complete subprocessor list that explicitly covers AI workflow components, not just infrastructure. For each subprocessor, ask what data flows through it, whether it's in the same jurisdiction, and whether data is retained after processing. If the answer is a link to a generic Trust page with 50 subprocessors and no AI-specific detail, your due diligence isn't done.

Question 4: What Data Is Retained in Your Inference Logs, for How Long, and Who Can Access It?

Every AI vendor logs prompts and outputs. The question is what they log, how long they keep it, and who has access. Some vendors retain full prompt and completion text indefinitely for model improvement. Some store embeddings of your data that can be reconstructed. Some share logs with foundation model providers under terms that give those providers rights to use your data for training.

ISO 42001 Annex A controls covering documented information and monitoring require organisations to define what data is collected from AI systems, how it's stored, and for what purpose. If your vendor's inference logs contain personal data, health information, or commercially sensitive prompts, the retention policy isn't just an operational concern. It's a regulatory exposure. Under the Notifiable Data Breaches scheme in Australia, if those logs are breached and contain personal information, you're the one notifying the OAIC, not your vendor.

The specific ask: "Provide your data retention schedule for inference logs. Does it distinguish between prompt metadata and full prompt content? Are logs segregated by customer, or co-mingled? Can we opt out of having our inference data used for model training or improvement?" If the answer to that last question is no, price the regulatory risk into your procurement decision.

Question 5: What Happens If You Switch Foundation Model Providers?

Most AI vendors today are wrappers around a foundation model from OpenAI, Anthropic, Google, or Meta. What happens when the vendor decides to switch from GPT-4 to Claude, or from a proprietary model to an open-weight alternative? Do you get notified? Do your prompts get routed through a different model without your knowledge? Does the vendor re-validate your use case against the new model's safety characteristics?

This isn't a hypothetical. Foundation model pricing, capabilities, and availability change rapidly. Vendors have commercial incentives to switch providers. ISO 42001 requires organisations to plan changes to AI systems and assess their impact. If your vendor doesn't have a documented foundation model change policy, they're not managing a key operational risk.

Ask for the vendor's policy on foundation model changes. Specifically: notification period, re-validation process, regression testing against your use case, and the right to terminate if the new model doesn't meet your requirements. If the vendor treats model switching as equivalent to a routine infrastructure change, they don't understand what they're switching.

What Most Organisations Get Wrong When Asking These Questions

There are three common failure modes when organisations attempt to fill these gaps in their vendor assessment process.

Asking the question but accepting a weak answer. A vendor says "we use industry-standard data sources" and the assessor ticks the box. Industry-standard doesn't mean compliant. It means common. Push for documented evidence, not assurances. A data provenance statement without source-level detail is a marketing document.

Treating AI risk as an IT problem. Procurement sends the questionnaire to the vendor's security team, who know their firewall rules but may not know the training data pipeline or the subprocessor chain for model inference. AI risk spans legal, compliance, data governance, and operational risk. The questionnaire needs to reach the people who built the product, not just the people who secure the infrastructure.

Not mapping answers to your own risk appetite. A vendor discloses that they use five subprocessors for AI inference, retain prompt data for 18 months, and can't guarantee training data provenance beyond their own fine-tuning. That's not automatically a dealbreaker. What matters is whether your organisation has assessed those answers against its risk appetite and documented the acceptance of residual risk. ISO 42001 requires organisations to define risk tolerance for AI systems. If you can't point to that documentation, the questionnaire answers don't matter because nobody knows what "good enough" looks like.

What to Do With the Answers

Collecting answers to these five questions creates a decision, not a checklist. Once you have the responses, do three things.

Map gaps to your regulatory obligations. If the vendor retains inference logs containing personal data for longer than your data retention policy allows, you have a compliance gap. If subprocessors operate outside your jurisdiction, you have a cross-border data flow to manage. Map each gap to a specific regulatory requirement (CPS 234, Privacy Act, GDPR) so the risk isn't abstract.

Price the residual risk. A vendor who can't provide training data provenance faces higher legal risk from copyright claims. A vendor who switches foundation models without customer notification creates operational unpredictability. These aren't theoretical concerns. They affect what you should pay, what contractual protections you need, and whether you need a backup supplier.

Build these questions into your standard procurement process. The five questions above should sit alongside your existing vendor security questionnaire as an AI-specific supplement. If your organisation uses AI vendors (and it almost certainly does, even if procurement doesn't know it), these questions belong in every new vendor assessment and every contract renewal.

The organisations that get this right aren't necessarily the ones with the biggest compliance teams. They're the ones that stopped treating AI procurement like SaaS procurement and started asking questions the standard questionnaire was never designed to answer.

Internal Resources

If you're building or reviewing your AI vendor assessment process, BizThriveAI can help. Contact us to discuss bespoke AI vendor audits grounded in ISO 42001 methodology. Or review our pricing and download a sample vendor compliance report to see what a proper assessment looks like.

Further reading from our blog: AI Governance for the Board: What Directors Need to Know and Ask and AI Governance Platforms: Tool vs. Compliance for more on building robust AI oversight. Browse all AI governance articles for practical guidance on regulatory compliance and vendor risk management.

Written by David Swan, reviewed and fact-checked against primary regulatory sources. AI-assisted but human-directed.