A vendor has just sent you a proposal. The AI tool looked impressive in the demo, the pricing is within reach, and the team is keen to try it. What you probably haven’t done yet is ask them about security.
That gap is common in owner-managed firms. Without a legal or security specialist in the room, vendor reviews tend to focus on features and cost. But once an AI tool touches customer data, financial records, or staff information, you’re in regulated territory. Under UK GDPR, you remain responsible for what any processor does with your data, regardless of what their marketing says about security.
What security questions should you put to an AI vendor?
Six question areas cover the ground. Ask where data is stored and processed, whether the vendor uses your inputs to train their models, what certifications they hold, how they handle encryption in transit and at rest, what their incident notification timelines are, and whether they will sign a UK GDPR-compliant data processing agreement. The NCSC treats these as the baseline for any AI deployment.
Start with data location. If data is processed outside the UK and EEA, you need to know which transfer mechanism the vendor relies on, whether the EU Standard Contractual Clauses or the UK’s International Data Transfer Agreement. The training question is equally important. Many AI vendors use customer inputs to fine-tune their models by default. The ICO is clear that you must know what a processor does with your data, including any training use, and getting a contractual opt-out in writing is a straightforward ask that credible vendors will accommodate.
On certifications, ISO 27001 and SOC 2 are the two most commonly cited by credible vendors. Neither guarantees security in practice, but they indicate a managed programme is in place. Vendors who can’t answer a direct question about certifications are a signal to pause. On incident response, look for contractual notification timelines rather than vague commitments. The IBM Cost of a Data Breach 2023 report puts the average time to identify and contain a breach at 277 days, which makes early vendor notification one of the few controls you can actually enforce through a contract.
Why do AI vendors carry different security risks than standard software?
AI vendors introduce a category of risk that standard SaaS suppliers don’t. Give a payroll system your staff data and the relationship is clear: it stores and processes on your behalf, and the scope is defined. Give an AI vendor the same data and it may train models on it, pass it to unnamed sub-processors, or retain inputs long after the task is done. Standard software reviews weren’t designed to surface those risks.
The scale of what third-party exposure can cost puts this in context. IBM’s Cost of a Data Breach 2023 report estimates the global average breach cost at $4.45 million, with incidents involving third-party compromise costing on average 12.3% more than those without. The 2023 MOVEit vulnerability, where a single supplier flaw affected more than 2,700 organisations and 95 million individuals, including UK victims such as the BBC and British Airways, illustrates what third-party risk looks like in practice.
AI tools also introduce attack surfaces that standard SaaS doesn’t. Model inversion and extraction attacks can allow adversaries to reconstruct training data. Adversarial inputs can make models misclassify or reveal information they shouldn’t. Poisoning attacks can corrupt outputs. When NCSC published guidance on using AI models for vulnerability discovery in 2024, it highlighted all three as specific concerns for any organisation deploying AI in security-adjacent workflows.
Where in the vendor relationship do security gaps typically appear?
The gaps cluster in predictable places. Many appear where owners assume protections exist but the vendor’s terms say otherwise: training data use buried in the terms of service, sub-processors not listed in documentation, encryption applied to data in transit but not at rest, and incident notification windows measured in weeks rather than hours. Covering these points explicitly before signing resolves them far more efficiently than discovering them after you’ve committed.
The ICO’s enforcement history shows what happens when this due diligence is skipped. The Ticketmaster UK fine in 2020 (£1.25 million) followed a third-party chatbot integration that led to payment card data being compromised. The ICO found that Ticketmaster UK had failed to adequately monitor and secure the supplier. The tool was AI-adjacent, the failure was a procurement and oversight gap, and Ticketmaster paid.
Beyond regulatory risk, operational defaults are worth checking too. NCSC recommends that AI tools be sandboxed, given minimum necessary access to production systems, and separated from development and test environments. Many vendors offer these configurations but they’re often not the default. If you don’t ask, you get the permissive settings rather than the cautious ones. Data residency matters here as well: UK or EEA storage gives you clearer regulatory coverage, while US-based processing requires transfer mechanisms to be in place and documented before you go live.
When do you need a full questionnaire, and when is a lighter approach enough?
Depth of due diligence should match what you’re putting in. A vendor handling general enquiry emails needs less scrutiny than one processing financial records or employment decisions. The EU AI Act’s risk tiering is a useful frame: high-risk applications, those touching employment, credit, or access to essential services, require documented risk management and explainability; lower-risk uses carry fewer obligations. Matching your scrutiny to the risk level keeps the process proportionate.
For lower-risk use cases, a three-question shortlist covers the essentials. Where is data stored and processed, do they use your inputs to train models, and will they sign a data processing agreement? If any of those returns a vague or evasive answer, move to a fuller questionnaire before proceeding.
For higher-risk deployments, or any tool touching personal data on customers, staff, or clients, the fuller question set is worth the hour it takes. UK Government research shows that 32% of businesses already outsource some cyber security. The question isn’t whether to assess vendor security but how rigorously to do it, given what’s at stake. If you’re FCA-regulated, the question answers itself: the FCA has confirmed that its existing rules on operational resilience and outsourcing apply directly to AI tools and third-party AI deployments. That obligation isn’t optional, and the regulator expects documented due diligence.
What else should be in place alongside the vendor questions?
The questionnaire is the starting point. Alongside it, you need a signed UK GDPR-compliant data processing agreement that names sub-processors, sets out your documented instructions, specifies security measures, and gives you audit rights. The ICO’s controller-processor guidance is explicit: a vendor’s website terms of use don’t substitute for a formal data processing agreement, and without one your personal data processing has no contractual foundation.
Two frameworks add structure beyond the questionnaire itself. ISO 27001 tells you a vendor has a managed security programme reviewed by an external auditor. NIST’s AI Risk Management Framework addresses the AI-specific risks that standard security frameworks weren’t built for, covering model governance, bias monitoring, and adversarial robustness. If a vendor can reference both, you have stronger grounds for confidence than questionnaire answers alone provide.
Build a simple scoring record as you go. Rate each question area green, amber, or red, and note any mitigations you’ve agreed, such as a contractual commitment to no model training on your data, or a restriction to staging environments only. That record is your evidence if a client or regulator asks how you chose your AI vendor. It takes an hour to build and becomes your documented due diligence. Ask the vendor directly whether they can provide logs of AI inputs and outputs when you need to demonstrate traceability to a regulator. If they can’t, that’s a risk to weigh before you sign anything.
