Vendor security review for AI: 12 questions before signing an MSA

Reading time: approx. 11 minutes. Cluster: vendor-eval. Author: Fryderyk.

Short answer first

Before you sign an MSA with an AI vendor, you need answers to twelve questions that separate a real security review from ticking a box. It is not about whether the vendor holds a certificate, but about where your data physically goes, who else can reach it, what happens during an incident, and how you look on the day you want to leave. The twelve questions fall into four blocks: data flow and location, the sub-processor chain, operational security, and exit terms. If the vendor answers all four blocks concretely, you have a partner you can audit. If they brush off questions about data location or portability, that is not a matter of contract form, it is a warning sign. This note breaks each of the twelve questions down into what you are really looking for in the answer.

Table of contents

1. Why a standard security questionnaire is not enough
2. Block A: data flow and location (questions 1 to 3)
3. Block B: the sub-processor chain (questions 4 to 6)
4. Block C: operational security (questions 7 to 9)
5. Block D: exit terms (questions 10 to 12)
6. Table: 12 questions and red flags
7. Where the vendor type fits into all this
8. FAQ
9. Disclosure and biases
10. What I am not covering here
11. Related notes

Why a standard security questionnaire is not enough

Most organizations have a ready-made vendor security questionnaire and send the same file to a hosting company, a CRM vendor, and an AI vendor. That is a mistake, because an AI system has a risk profile the classic questionnaire does not catch. It asks about encryption and certificates, but not about whether your queries are used to train the model, where the context passed to the model resides, and who has access to the prompt logs.

The second weakness of the standard questionnaire is the yes-no format. The vendor ticks "yes, we encrypt data" and the box is checked, even though you do not know whether that means in transit, at rest, or both, with which keys and who manages them. A real security review is a conversation about specifics, not a collection of declarations.

The twelve questions below are built so that none of them can be answered with a bare "yes." Each forces a description of a mechanism, and it is in the description of the mechanism that you see whether the vendor genuinely thought about security or merely assembled certificates for the sale.

Block A: data flow and location (questions 1 to 3)

Question 1: Where is my data physically processed, and where does it reside at rest?

You are looking for a specific location, not the generality "in secure data centres." You ask about the region, the jurisdiction, and whether data can leave the stated area under any scenario, including failover processing or technical support. For an entity in scope of NIS2, the location of processing maps directly onto the supply-chain and exposure assessment.

Question 2: Are my queries, inputs, or outputs used to train or fine-tune the model?

This is the question that differentiates vendors fastest. The answer must be unambiguous and written into the contract, not into a privacy policy the vendor can change. If data is used for training, you ask about the opt-out mechanism and whether it is on by default. An unclear answer here is a serious red flag.

Question 3: What does the full data-flow map look like, from my user to the model and back?

You ask for a diagram or a description: which way the query travels, where it is buffered, where it is logged, what is stored and for how long. This single artifact reveals more than ten yes-no questions, because it forces the vendor to name every point at which your data is visible or persisted.

Block B: the sub-processor chain (questions 4 to 6)

Question 4: Who are your sub-processors, and what does each of them process?

An AI vendor is rarely a monolith. Underneath there is often an infrastructure provider, a base-model provider, sometimes an external content moderator. Each of them is a link in your supply chain within the meaning of Art. 21. You ask for the current list and for how you are informed of changes.

Question 5: Do you use an external model API, or do you host the model yourself?

This distinction decides how many entities touch your data. If the vendor wraps a public model API, your data passes through another organization, with its own jurisdiction and its own policy. If they host the model in their own or your environment, the chain is shorter. Neither option is better by definition, but you must know which one you are buying.

Question 6: How do you contractually pass down to sub-processors the security commitments you make to me?

Your contract with the vendor is worth only as much as their contracts with their sub-processors. You ask whether the commitments on data location, no-training, and incident reporting are passed down the chain, or whether they stop at the first level.

Block C: operational security (questions 7 to 9)

Question 7: What does access control look like on your side, which of your people can see my data?

You ask about privileged access: whether the vendor's engineers can view your queries, under what circumstances, whether such access is logged, and whether you can see those logs. In AI systems, prompts are often a window onto sensitive data, so access to prompt logs is a real risk surface.

Question 8: How are incidents logged and detected, and what is the contractual notification time?

You need a specific time window written into the contract, not a declaration of "without undue delay." For an entity in scope of NIS2, the notification time from the vendor has to let you meet your own reporting obligations to the CSIRT. If the vendor gives itself 72 hours and you have an initial report due in 24, you have an arithmetic problem.

Question 9: How do you manage updates and model changes, and am I informed of them?

Changing the model underneath can change the system's behaviour and its risk profile, even if the interface looks the same. You ask whether you get advance notice, whether you have a window to validate, and whether you can stay on the previous version if the change does not suit you.

Block D: exit terms (questions 10 to 12)

Question 10: How do I get my data back at the end of the relationship, and in what format?

You ask about a specific export format, a time window, and whether the export also covers derived data, such as embeddings or indexes, if you paid for them. The absence of a clear export path is a classic trap I described in the note on vendor lock-in.

Question 11: How and when is my data permanently deleted after the contract ends?

The mirror image of question 10. You need confirmation of permanent deletion, a deadline, and coverage of backups and data held by sub-processors. You ask whether you get written confirmation of deletion.

Question 12: What happens to my deployment if you cease trading or are acquired?

The continuity question most buyers skip. You are looking for a mechanism: whether there is a code or model escrow, whether the contract passes to the acquirer on the same terms, whether you have an exit right on a change of control. For a deployment a business process depends on, this is a business-continuity question within the meaning of NIS2.

Table: 12 questions and red flags

#	Question	Red flag in the answer
1	Where data is processed and stored	"In secure data centres" with no region named
2	Whether data goes to model training	Answer only in the privacy policy, not the contract
3	Full data-flow map	No ready diagram or description
4	List of sub-processors	Reluctance to share a current list
5	External API or self-hosting	Evasive answer about architecture
6	Passing commitments down the chain	Commitments stop at the vendor
7	Privileged access to data	No logging of staff access
8	Incident notification time	No specific window in the contract
9	Model-change management	No advance notice or validation window
10	Data export on exit	No defined format or window
11	Permanent data deletion	No written confirmation
12	Continuity on failure or acquisition	No mechanism of any kind

Where the vendor type fits into all this

The answers to these twelve questions line up differently depending on the vendor category, and in the on-prem AI market for European manufacturing you can see several such categories today. On one side are DIY solutions on open models, where you control the answers to blocks A and B in full, because you are the operator, but the whole of the operational security in block C rests on your team. On the other side are productized platforms, which take on part of block C but add their own contractual commitments that you have to probe with block D. There are also hybrid hyperscaler offers, where blocks A and B tend to be the hardest, because the data passes through the most hands.

The conclusion is not that one category wins. Productized platforms make sense when you want to shorten the chain from block B and shift part of the block-C operations onto the vendor, but then you pay in attention to block D, because you are tying yourself to a specific vendor. DIY makes sense when you have a team that can carry block C and you want full control. The twelve questions work as a common language you use to interrogate every category against the same set of criteria, instead of comparing apples to oranges.

FAQ

Do these 12 questions replace a formal security questionnaire?

They do not replace it, they complement it. A standard questionnaire collects certificates and declarations, these twelve questions force a description of mechanisms specific to an AI system. It is best to ask them as a deepening step, in a conversation, where an evasive answer is harder.

Which question matters most if I only have time for one?

Question 2, about training on your data, and question 1, about location. These two eliminate vendors incompatible with the requirements of a NIS2-covered entity fastest, before you invest time in the rest of the review.

With an on-prem deployment, do some of these questions fall away?

Some get simpler, they do not fall away. With self-hosting, blocks A and B are shorter, because data does not leave the perimeter, but blocks C and D still apply, because the platform vendor still delivers updates, support, and a licence.

Do the answers have to go into the contract?

The ones that concern commitments, yes. Data location, no-training, incident notification time, and exit terms should be in the MSA or DPA, not in a policy the vendor can change unilaterally.

// disclosure & biasesDisclosure and biases

I write from the perspective of someone working on AI solutions run outside the public cloud, so I naturally emphasise control over data flow and a short supply chain. I have tried to present all vendor categories with their pluses and minuses, rather than promoting one. This text is not legal advice. Consult a lawyer on the specific wording of MSA and DPA clauses.

What I am not covering here

I do not cover the commercial aspects of MSA negotiation here, such as pricing, SLAs, or contractual penalties, because that is a separate topic. I do not go into technical penetration testing of the model itself, or into assessing answer quality. I also leave out the details of the AI Act, which overlap with this review but are governed by their own categories.

Related notes

• Vendor lock-in in AI: three layers, two contractual traps
• NIS2 and the AI vendor in the supply chain: mapping Art. 21 for key entities
• ISO 27001 and the AI vendor: three controls worth mapping today
• Audit readiness NIS2 plus AI: 7 documents you produce before the auditor