What a good DPA does
A DPA should match the real processing, not only repeat Article 28 GDPR. For an AI or data-heavy vendor, map roles, instructions, data, subprocessors, security, incidents, transfers, retention, deletion and whether prompts, outputs or logs are used for training or another purpose.
A vendor can offer a polished DPA and still leave the important operating questions unanswered. The decisive evidence often sits in the service description, security schedule, subprocessor list, privacy notice, retention documentation and product configuration.
The vendor and AI DPA risk map
| Area | Question to answer | Red flag |
|---|---|---|
| Role | Which purposes and essential means does each party determine? | the contract calls every activity “processor” work while the vendor uses data for its own purposes |
| AI use | Are prompts, files, outputs, telemetry or support logs used for training or improvement? | secondary use is hidden in a general privacy notice or can change unilaterally |
| Subprocessors | Who receives data, where, for what service and under which change process? | no current list, no notice, or no meaningful objection process |
| Transfers | What transfer mechanism and supplementary measures cover each data flow? | the DPA says “SCCs apply” without identifying the transfer, module or parties |
| Exit | Can data be exported and deleted across active systems, logs and backups? | retention is undefined or deletion applies only to the visible workspace |
1. Confirm controller, processor and independent-use roles
Labels do not decide roles by themselves. The EDPB describes controller and processor concepts as functional: assess who determines purposes and essential means for each processing activity.
A vendor may process customer content on instructions and act differently for account administration, security, abuse prevention or product analytics. Record the role and legal basis for each material purpose instead of forcing the entire relationship into one label.
2. Make the processing description concrete
Article 28 requires the contract to set out subject matter, duration, nature, purpose, personal-data types, data-subject categories, and controller rights and obligations. For AI services, list prompts, uploaded files, retrieved context, outputs, embeddings, feedback, telemetry, support content and security logs where applicable.
3. Separate service delivery from training and improvement
Ask whether customer data, personal data, prompts or outputs are used to train, fine-tune, evaluate or improve models. If the answer changes by plan, feature, region or setting, make that condition explicit. Also check whether the vendor’s model provider receives the content and for what purpose.
4. Treat the subprocessor list as a live data map
Record the legal entity, service, location and function of each relevant subprocessor. General written authorisation under Article 28 requires notice of intended additions or replacements and an opportunity to object. The DPA should also explain the practical consequence of a valid objection.
5. Connect security promises to evidence
Article 32 uses a risk-based standard. Review access control, encryption, tenant separation, secrets, vulnerability management, secure development, logging, backup, resilience, testing and incident response against the actual data and service. Certification can help but does not replace the scoped controls and exclusions.
6. Make incident cooperation operational
The processor must notify the controller without undue delay after becoming aware of a personal-data breach. The contract should identify the notification channel, minimum facts, update sequence, evidence preservation, cooperation duties and how service-security incidents that are not personal-data breaches are handled.
7. Identify each international transfer
Map exporter, importer, countries, data, purpose and onward transfers. Do not confuse the Commission’s Article 28 controller-processor clauses with the separate SCCs for third-country transfers. Where transfer SCCs are used, select the correct module and document relevant supplementary measures.
8. Test deletion, return and portability
Ask what the customer can export, in which format, and how long access remains after termination. Then map deletion from production, replicas, logs, support tools, model-provider systems and backups, including any limited retention required by law or security.
9. Control changes to AI features and data use
A DPA should not allow the vendor to introduce a new model, region, subprocessor or training purpose without the notice and controls promised in the agreement. Link material changes to documentation, notice, objection or termination rights that the customer can actually exercise.
10. Align liability and audit language with the main agreement
Check hierarchy, liability caps, indemnities, audit scope, third-party reports, regulator access and cost allocation across the DPA and main service agreement. A strong data schedule can be weakened by an inconsistent liability or precedence clause elsewhere.
Primary sources checked
- Regulation (EU) 2016/679, GDPR — Official Journal 4 May 2016; checked 31 July 2026; locator: Articles 28 and 32 and Chapter V.
- EDPB Guidelines 07/2020 on controller and processor concepts — final version 7 July 2021; checked 31 July 2026; locator: Parts I and II.
- European Commission publications on Standard Contractual Clauses — publication 4 June 2021; checked 31 July 2026; locator: controller-processor and international-transfer clause sets.
Test the vendor’s DPA against the real product. See what needs attention in Contract Review, including clauses and questions that may need privacy counsel.
This guide is for general information only and is not legal advice. It was prepared by Outlex using public legal sources and product context. For advice on your specific situation, speak with a qualified lawyer.
