Data Processing Agreements Explained: What to Check Before You Sign

A data processing agreement is usually the least read document in a software deal. It arrives as an attachment to the main contract, it looks standard, and someone clicks accept. Then a breach happens, or a regulator asks who had access to what, and the DPA becomes the most important document in the file.

This guide explains when you need one, what it must say, what you can negotiate, and the additional questions AI vendors raise.

Controller, processor and why it matters

Under the GDPR, the controller decides the purposes and means of processing personal data. The processor processes personal data on the controller’s behalf and on its instructions. A SaaS platform hosting a customer’s client records is normally a processor for those records; the customer is the controller.

The roles decide the obligations. Article 28 requires a controller to use only processors that provide sufficient guarantees, and to bind them by a contract containing specific terms. The European Data Protection Board’s guidelines on controller and processor concepts explain how to identify the roles, including where a provider acts as a controller for some data (its own billing and account data) and a processor for other data (the customer’s content).

When a DPA is required

You need a DPA whenever a controller subject to the GDPR or UK GDPR engages a processor to handle personal data. Typical examples include cloud hosting, CRM and email platforms, payroll and HR systems, customer support desks, analytics providers acting as processors and, increasingly, AI tools that process prompts and documents containing personal data.

Processors must also impose equivalent terms on their own sub-processors.

The mandatory terms: Article 28(3)

A compliant DPA must set out the subject matter, duration, nature and purpose of the processing, the types of personal data and categories of data subjects, and the controller’s obligations and rights. It must require the processor to:

1. process personal data only on the controller’s documented instructions, including on international transfers;
2. ensure people authorised to process the data are bound by confidentiality;
3. take the security measures required by Article 32;
4. respect the conditions for engaging sub-processors (prior authorisation, specific or general, with notice and a right to object to changes) and flow down the same obligations;
5. assist the controller in responding to data subject rights requests;
6. assist the controller with security, breach notification, impact assessments and prior consultation;
7. delete or return all personal data at the end of the services, at the controller’s choice;
8. make available all information necessary to demonstrate compliance and allow for audits and inspections.

If any of these are missing, the DPA is not compliant, however polished the rest of it looks.

The negotiable clauses

Within the mandatory framework, several terms are genuinely commercial.

Sub-processors. Most providers ask for general authorisation with a published list and notice of changes. Check the notice period, how you are told, and what your remedy is if you object (often termination of the affected service).

Audits. Providers usually offer third-party reports and certifications first, with on-site audits limited to specific circumstances and at the controller’s cost. That is common and often acceptable, provided you can still obtain the information Article 28 requires.

Breach notification. The GDPR requires processors to notify the controller “without undue delay”. Because controllers have 72 hours to notify the regulator in many cases, controllers often negotiate a fixed outer limit, such as 24 or 48 hours, and a minimum content for the notice.

Liability. Many providers apply the main agreement’s liability cap to data protection claims. Controllers handling sensitive data may seek a higher cap or a separate super-cap for data breaches.

Deletion. Agree timelines for deletion after termination, including backups, and whether a certificate of deletion is provided.

International transfers

If the processor or its sub-processors access personal data from outside the EEA or UK, a transfer mechanism is needed.

• Adequacy. The European Commission has recognised some countries as providing adequate protection. For the United States, the EU-US Data Privacy Framework adequacy decision of 10 July 2023 covers transfers to companies certified under the framework. The EU General Court dismissed a challenge to it on 3 September 2025 (Case T-553/23, Latombe v Commission); an appeal to the Court of Justice (Case C-703/25 P) was filed on 31 October 2025. Check the company’s certification on the official Data Privacy Framework list.
• Standard contractual clauses (SCCs). The Commission’s 2021 SCCs (Implementing Decision (EU) 2021/914) are the most common safeguard for transfers to countries without adequacy. They come in modules for different relationships, such as controller to processor and processor to processor, and must be accompanied by a transfer risk assessment.
• The UK. UK transfers use the UK’s own mechanisms, such as the International Data Transfer Agreement or the UK Addendum to the EU SCCs, and the UK extension to the Data Privacy Framework for certified US companies.

A DPA that says only “appropriate safeguards will be used” without identifying them is incomplete.

The extra questions for AI vendors

AI services process the content you give them, which often contains personal data and confidential information. Before signing, check:

• Training. Does the vendor use your inputs or outputs to train or improve its models? The DPA, or the main terms, should prohibit it or give you a clear opt-out.
• Retention. How long are prompts, files and outputs retained, including for abuse monitoring? Can retention be reduced?
• Model sub-processors. Is the underlying model provided by a third party? It should appear on the sub-processor list, with its location.
• Data location. Where is processing performed, and can you choose a region?
• Human review. Can vendor staff view your content, and under what controls?
• Outputs. Are outputs treated as your data for deletion and confidentiality purposes?

The free AI Vendor Terms Red-Flag Scanner highlights training, retention, confidentiality and liability language in a vendor’s terms or DPA in seconds, without sending the text anywhere.

A pre-signature checklist

• Roles correct: who is controller and who is processor, for which data?
• All Article 28(3) terms present.
• Description of processing (data types, data subjects, purposes, duration) accurate.
• Sub-processor list reviewed; notice and objection mechanism acceptable.
• Security measures described in an annex, specific rather than generic.
• Breach notice period and content defined.
• Audit and information rights workable.
• Transfer mechanism identified for every non-EEA location.
• Deletion and return terms, including backups.
• For AI vendors: no training on your data, retention limits, model sub-processors disclosed.
• Liability position understood and acceptable for the data involved.

The bottom line

A DPA is short, technical and easy to ignore until it is the only thing that matters. Check that the mandatory terms are present, negotiate the handful of clauses that are genuinely commercial, identify every transfer mechanism, and ask AI vendors directly about training and retention. Ten minutes of review at signature can save months of explanation later.