Fernside Studio
Background
Archive
Journal Entry

AI Vendor Security Assessment: Essential Questions

Documented
Capacity
6 MIN READ
Domain
AI & Automation

Standard vendor security questionnaires miss AI-specific risks entirely. Is your data used for training? Can prompt injection reach another customer’s data? What happens to your data if the model gets updated? A proper vendor security assessment for an AI supplier needs to ask questions a generic IT questionnaire never covers.

Most procurement teams still run AI vendors through the same checklist built for a CRM or accounting tool, SOC 2 badge, uptime SLA, data processing agreement, done. That checklist catches infrastructure risk. It doesn’t catch what happens when your data enters a model.

AI-Specific Security Risks Most Assessments Miss

Traditional vendor risk assessment frameworks were built before large language models were embedded in everyday business tools. They don’t ask about the risks unique to AI systems, which include:

Training data contamination. If a vendor uses customer inputs to fine-tune or improve their model, your business data: including anything commercially sensitive: could influence outputs shown to other customers, or worse, be reconstructible from the model itself.

Prompt injection. A malicious input crafted to manipulate an AI system’s behaviour can, in poorly isolated systems, cause the model to ignore its instructions, leak system prompts, or in multi-tenant setups, surface data belonging to another customer. This is now a recognised OWASP Top 10 risk for LLM applications.

Model inversion and data leakage. Some model architectures can be probed to extract fragments of their training data. If your data was used for training without proper safeguards, this is a live risk, not a theoretical one.

Multi-tenant data leakage. Shared AI infrastructure means your data and a competitor’s data might pass through the same inference pipeline. Vendors need to demonstrate genuine isolation, not just assert it.

Credential exposure in prompts. Teams routinely paste API keys, customer records, or internal documents into AI tools without realising where that data is logged, cached, or retained.

The NCSC’s supply chain security guidance sets out 12 principles for assessing supplier risk generally: understand the risk, establish control, check your arrangements, and improve continuously. AI vendors need all of that, plus the questions below layered on top.

Data Handling Questions

Ask every AI vendor these before you sign anything:

  1. Where is our data physically stored, and does it ever leave that jurisdiction? Data residency matters for UK GDPR compliance, especially if the vendor routes requests through US infrastructure.
  2. How long is our data retained, and can we set a shorter retention period?
  3. Is our data used to train or fine-tune models, theirs or a third party’s? Get this in writing, not just verbal assurance.
  4. Who are the sub-processors, and where can we see the current list? Vendors should publish this, not make you ask each time.
  5. What encryption standards apply, both in transit and at rest?
  6. What happens to our data on contract termination: is it deleted, and within what timeframe, with proof provided?

We cover the broader compliance picture in AI and GDPR: what UK businesses need to know and go deeper on data flows in AI data handling best practices.

Infrastructure Questions

This is the section that overlaps with traditional vendor security assessments, and it still matters:

  1. Do they hold current SOC 2 Type II or ISO 27001 certification: and can you see the actual report, not just a badge on the website?
  2. How often is penetration testing carried out, and by whom?
  3. What’s their documented incident response time, and what counts as a notifiable incident?
  4. What uptime guarantee is contractual, not aspirational?
  5. What’s their disaster recovery plan, and has it been tested in the last 12 months?

A vendor that can’t produce a recent penetration test report or a named incident response owner is telling you something, regardless of what the sales deck says.

AI-Model-Specific Questions

This is the section most vendor questionnaires skip entirely:

  1. How is our data isolated from other tenants at the model and infrastructure level?
  2. What protections are in place against prompt injection attacks?
  3. Is there output filtering to catch data leakage or unsafe content before it reaches the end user?
  4. If they use a third-party model provider (OpenAI, Anthropic, etc.), what’s that provider’s own data handling policy, and does it flow through to you?
  5. Can you get an audit log of what data was sent to the model and when? See our note on AI audit trails for why this matters for compliance, not just security.

If a vendor can’t answer questions 12 to 15 with specifics, that’s a gap worth pausing on before you commit budget or customer data.

Contractual Security Requirements

Questions alone don’t protect you, the contract does:

  1. Does the DPA name all sub-processors and require notice before new ones are added?
  2. What’s the breach notification timeline? UK GDPR expects controllers to notify the ICO within 72 hours, so your vendor needs to notify you fast enough to make that possible.
  3. Are liability caps proportionate to the sensitivity of data involved, or capped at 12 months’ fees regardless of impact?
  4. Do you have audit rights, the ability to request evidence of controls, not just take their word for it?

What This Costs You in Time

A proper assessment against these 20 questions takes a few hours per vendor if you already have the checklist, most of the delay comes from chasing vendors who don’t have ready answers. Treat that delay itself as a data point. A vendor with mature security practices can usually produce a SOC 2 report, sub-processor list, and DPA within a day. One that takes weeks to answer basic questions is showing you their actual security maturity, not just their sales process.

This is the same discipline we recommend before signing any AI tool: covered in more general terms in how to evaluate AI vendors, which looks at accuracy, pricing, and exit costs alongside security.

Next Steps

Run every AI vendor touching customer or business data through this list before signing, not after. If a vendor resists specifics, vague answers on sub-processors, no penetration test report, no clarity on training data use, treat that as your answer.

If you want a second pair of eyes before you commit budget to an AI vendor, Fernside Studio’s advisory service helps CTOs, CISOs, and procurement leads stress-test vendor claims and build a security assessment tailored to the tool in question.

Need vendor security assessment support? Get in touch and we’ll help you build the right questions for your specific vendor and data.

Sources