Gains:
- Ability to evaluate an AI vendor on certification, storage, data residency and sub-processor axes
- Ability to verify assurances with documents and contract clauses and not rely on verbal words
- Ability to tie DPA and opt-out/deletion conditions to pre-purchase security review
Most organizations do not train their own models; uses a provider's API. This doesn't eliminate the risk — it just transfers it to someone else, and it's your responsibility to evaluate the risk you're transferring. Every third party your data goes to is an extension of your security boundary. In this unit you will learn how to evaluate an AI supplier; We will learn how to conduct a pre-purchase security review through compliance certificates, data processing agreement (DPA), data storage, data domicile and sub-processors.
Why Third Party Risk?
In the event of an audit or a breach, the defense of "we did not process the data, the provider did" will not save you. You are the data controller; The provider is the data processor. KVKK and GDPR make this distinction, but most of the responsibility remains with you. That's why choosing a supplier is not a purchasing decision, but a security decision.
Caution: "A large and well-known provider" is not a guarantee of security. Assurance comes from signed contractual clauses and verifiable certifications; not because of the reputation of the brand.
Evaluation Axes
Examine an AI vendor on seven axes:
- Compliance certifications: SOC 2 Type II (independent audit of an organization's security controls), ISO/IEC 27001 (information security management standard) and increasingly ISO/IEC 42001 (artificial intelligence management system standard).
- Data retention: How long is the prompt/response retained? Is ZDR (zero data retention) offered?
- Use in training: Is your data used to train the model? (Usually "no" at corporate levels.)
- Data residence: In which country/region is the data processed and stored?
- Subprocessors: What other companies does the provider use (cloud, monitoring)? They are also part of your boundary.
- Security features: Encryption (in transit/at rest), access control, audit log, event notification time.
- Contract and exit: Is there a DPA? Is your data guaranteed to be deleted if the service ends? What is the risk of lock-in?
Step by Step: Supplier Review
- Submit a security survey. Turn the axes above into a list of questions.
- Ask for evidence. Verify claims with documentation (SOC 2 report, ISO certificate, DPA draft).
- Map the data flow. Which data goes where and for which process?
- Negotiate the DPA. Do not start production without signing a data processing agreement (the legal text that specifies how the provider will process the data).
- Review subprocessors. Consider the entire chain.
- Set up a reevaluation schedule. Supplier risk should be re-examined at least once a year.
Four Copiable Templates
Supplier security survey core:
Things to ask the provider:1. What compliance certifications do you have? (SOC 2 Type II, ISO 27001/42001) Can you share the report?2. How much request/response data is retained? Is there a ZDR option?3. Is our data used in model training? Is it written in the contract?4. In which region is the data processed/stored? Can we choose a region?5. Who are your subprocessors? How do you notify when it changes?6. What is your notification period in case of violation?7. How and when is our data deleted when the contract ends?
Evidence verification check rule:
For each claim, “is there evidence?” check:- Certification claim -> have I seen the current report/certificate number?- ZDR/storage claim -> is it written in the contract clause?- Non-use in training -> Is there an open clause in the DPA? Mark every claim without evidence as "NOT VERIFIED"; Do not accept verbal words.
Dataflow mapping prompt:
Extract the data flow for the following integration: {{ scenario }}Specify at each step: which data (does it contain PII), where it goes (which company/region), for what purpose, how much is stored. Mark each step and sub-processors that cross the enterprise boundary.
Supplier risk scorecard:
Score each axis with a score of 0-2 (0=none, 1=partial, 2=full):certificate, ZDR/retention, do not use in training, data residency, sub-processor transparency, violation notification, exit/deletion. If total < 10 or any axis is 0: "RISK HIGH, put into production".
Weak Prompt / Strong Prompt
poor approach
Strong approach
Assuming "big company, safe"
Verify certificate and DPA with document
relying on verbal assurances
Linking every assurance to the contract clause
Just review the provider
Also consider the sub-processor chain
choose once and forget
Annual reassessment calendar
Three Mini Cases
Case 1 — Project started without DPA was stopped. A retail company quickly brought an assistant into production; The legal team subsequently discovered there was no signed DPA with the provider. The project was suspended while customer data was being processed, the DPA was negotiated and reopened after data domicile was fixed in the EU region.
Case 2 — Subprocessor chain throws a surprise. A healthcare company had approved the primary provider; However, data flow mapping revealed that the provider was using a company in a third country for monitoring. This violated the data residency requirement. The company added in-region stay to the contract.
Case 3 — Scorecard eliminated the cheap bid. Three proposals were evaluated. The cheapest provider received 0 (no SOC 2) on the certification axis. The scorecard rule "if any axis is 0, put it into production" was eliminated; A 22% more expensive but fully rated provider was selected and the decision was documented for audit.
Tip: Never confuse two different guarantees: "our data is not stored (ZDR)" and "our data is not used in training" are separate clauses. A provider may offer one but not the other; Ask for both clearly in the contract.
Common mistakes
- Considering the size/brand of the provider as security assurance.
- Relying on word of mouth without verifying claims with documentation.
- Going into production without signing a DPA.
- Ignoring the subprocessor chain (data residence is pierced there).
- Thinking that ZDR and the "not used in education" guarantee are the same.
- Approving the supplier once and not re-evaluating annually.
In summary
- You are the data controller; Supplier selection is a security decision, not a purchasing decision.
- Evaluate on seven axes: certification, retention/ZDR, educational use, data residency, sub-processors, security features, contract/exit.
- Verify each assurance by document and contractual clause; Brand and word of mouth are not enough.
- Also consider the sub-processor chain; data residence is often pierced there.
- Do not start production before a DPA is signed and re-evaluate the supplier annually.
Application task
Fill out the security survey above for an AI vendor you use (or evaluate) and ask “is there proof?” for each answer. Tick the column. Then map the data flow and mark each step that crosses the enterprise boundary. Finally, score the seven axes and produce a risk scorecard and ask “is it suitable for production?” Write the reasons for your decision.
checklist
- [ ] I have documented the provider's compliance certifications (SOC 2 / ISO 27001).
- [ ] Data storage, ZDR and "non-use in education" clauses are written in the contract.
- [ ] It meets my data residence requirement (KVKK/GDPR).
- [ ] I mapped and evaluated the sub-processor chain.
- [ ] I did not go into production without a signed DPA.
- [ ] I set up an annual re-evaluation calendar for the supplier.