AI Vendor Due Diligence: A Security Checklist

Stop asking whether they are trustworthy. Ask what is in the breach.

AI vendor due diligence goes wrong because buyers run it as a trust exercise. Certifications are collected, a questionnaire comes back complete, everybody feels reassured, and nobody has written down what this supplier could actually reach on a bad day. Run it as a blast-radius exercise instead. Assume the vendor will be compromised at some point, because suppliers are compromised routinely and yours is not special, then ask what of yours is inside that event. A vendor with a wall of certifications and standing production access is a larger exposure than one with no certification at all and read-only access to a single table in a sandbox. Scope beats paperwork, every time.

AI vendor security starts with access scope and credentials

Write down what they can reach, in systems and in rows. Not “access to the CRM”. Which objects, which fields, read or write, production or a copy. Most AI build work needs read access to a sample and write access to exactly one place, and vendors accept a narrow scope more often than buyers expect, because nobody has ever asked them.

Credentials belong to named individuals, never to the company. A shared login is an account you cannot revoke selectively and cannot attribute afterwards. Ask which named people will hold access, insist on your own identity provider where the system supports it, and agree in writing that you are told within one working day when one of them leaves the supplier.

Give access an expiry date at the moment you grant it. The most common finding in any review of this kind is a supplier from two projects ago whose key still works. Time-bound the credential to the engagement, diary the revocation, and test that it actually happened rather than assuming the ticket was closed correctly.

Production access should be the exception you argue about. If a supplier says they need it to build, ask what specifically cannot be done against anonymised or sampled data. Sometimes the answer is legitimate, and it should be a decision with a date on it rather than the default arrangement for the whole engagement.

The sub-processor chain, retention, and what gets used for training

An AI vendor is rarely one party. They are a firm, plus a cloud provider, plus a model provider, plus whatever sits in between for logging, monitoring or error tracking. Each is a sub-processor in your chain and each is a place your data comes to rest. Ask for the list by name, with what each one does and which region it runs in, and ask how you are notified when it changes. A supplier who cannot produce that list in a week has not thought about it, which is itself the answer.

Three questions settle most of the remaining risk. How long is data retained at each hop, and can it be set to zero where the workflow allows. Is anything used to train or improve a model, at any layer, and is that exclusion in the contract rather than in a marketing page. And what happens to the logs, which are the layer everyone forgets: prompts and outputs frequently contain the personal data that the careful architecture upstream was designed to protect. The wider version of this question, including how the deployment path changes the answer, is in GDPR and LLMs.

Be proportionate about where the sensitivity actually sits. A public-facing system can still carry a real obligation: Memórias do Jamor accepts photo uploads from anonymous members of the public, which means images of identifiable people arriving with no account attached, and the handling questions there (consent, what is stripped before storage, what the moderation queue can see) are the same questions in a different costume. Our case studies each carry a version of the answer.

Incident response, exit, and what the insurance actually covers

Notification, with a number of hours in it. “Promptly” is not a term. You need a stated window, a named contact who is not a sales address, and an obligation to tell you about incidents at their sub-processors rather than only at their own perimeter. Under GDPR your own notification clock starts when you become aware, so a supplier who tells you late has spent your budget of time.

Exit written before you need it. Data returned in a documented format within a stated number of days, deletion confirmed in writing, access revoked on a schedule, and the code and documentation in your hands. This overlaps almost entirely with the ownership question, and the artefacts that make an exit survivable are the same five that make owning the system after launch real. Negotiating the exit at the start costs an email. Negotiating it during a dispute costs considerably more.

Insurance, read rather than confirmed. Professional indemnity and cyber liability are different policies covering different failures, and a supplier who says they are insured has answered a question you did not ask. Ask which policies, at what limit, and whether the limit is per claim or in aggregate across all their clients for the year. An aggregate limit shared with forty other customers is a smaller comfort than it sounds. Then compare the figure to what a bad day would actually cost you, because for a small supplier it is frequently a fraction of it, and that is a real part of the AI vendor risk you are accepting rather than a reason to walk away.

Twelve questions to paste into an email

Send these before the second meeting, to every supplier, in the same order. The speed and specificity of the reply tells you as much as the content does.

• Which systems will you access, at what level, and against production or a copy?
• Which named individuals will hold credentials, and how are we told when one of them leaves?
• Will access be time-bound to the engagement, and who revokes it?
• What specifically cannot be built against anonymised or sampled data?
• List your sub-processors by name, purpose and region.
• How are we notified when that list changes, and can we object?
• What is retained at each hop, for how long, and can retention be set to zero?
• Is any of our data used to train or improve a model, at any layer? Where does the contract say so?
• What is captured in prompt and output logs, who can read them, and how long are they kept?
• Within how many hours are we notified of an incident, at you or at a sub-processor, and to which named contact?
• On exit: what format, how many days, what deletion confirmation, and does the code and documentation come with it?
• Which insurance policies, at what limit, and is the limit per claim or aggregate?

A good supplier answers most of these from memory and says plainly which ones they cannot meet. That last part is the signal worth paying for. We have been on the receiving end of this list and the questions we find hardest are the ones about aggregate insurance limits and sub-processor change notification, which is worth saying out loud rather than discovering in a procurement round.

When this checklist is the wrong amount of work

A €5,000 project that reads a folder of public documents does not need a twelve-question procurement round, and running one signals that you will be expensive to work with. Scale the process to the blast radius: for a supplier who never touches personal data and never gets production access, four questions cover it, and they are the sub-processor list, retention, incident notification and exit.

The reverse error is worse and more common. A small, friendly engagement grows into standing production access over eighteen months without anybody redoing the assessment, because the original decision was made when the scope was trivial. Re-run the questions when the access changes, not when the contract renews. That is also the moment to check whether the credential from the first phase was ever revoked, and our audit writes the access scope into the engagement document precisely so there is something to compare against later.