GDPR Data Processing Agreements: The Clauses That Actually Carry Weight

Why the DPA exists

Under the GDPR the controller decides why and how personal data is processed; the processor acts on the controller's documented instructions. Article 28 requires a written contract between them whenever a processor touches personal data, and it lists what that contract must contain.

That list is a floor, not a template. A signed agreement that reproduces all ten items in boilerplate and then leaves the annexes empty is, functionally, no agreement at all.

The mandatory content

Article 28(3) requires the contract to state the subject matter, duration, nature and purpose of processing, the type of personal data and the categories of data subjects, and the obligations and rights of the controller. It then requires ten specific processor duties:

1. Process only on documented instructions from the controller, including for transfers to third countries.
2. Ensure persons authorised to process are under confidentiality obligations.
3. Take the security measures required by Article 32.
4. Respect the conditions for engaging another processor.
5. Assist the controller in responding to data subject rights requests.
6. Assist with breach notification, security and impact assessments.
7. Delete or return personal data at the end of the service.
8. Make available all information necessary to demonstrate compliance.
9. Allow and contribute to audits and inspections.
10. Inform the controller of any conflicting legal requirement before processing.

A DPA missing any of these is incomplete on its face. But completeness is the easy test — the harder question is whether the clauses are operationally true.

The annexes carry the weight

Three annexes do the real work. The processing description annex must actually describe the processing, not repeat the contract's recitals. The technical and organisational measures annex must list the concrete safeguards, because it is the document an auditor compares against reality. The sub-processor list must be current and complete, because a processor may not engage a new sub-processor without authorisation and must give the controller the chance to object.

The failure pattern is consistent: the measures annex says "encryption at rest and in transit" while a backup bucket sits unencrypted, or the sub-processor list is two years stale because nobody owns it. Both are findings that read as carelessness rather than bad faith, and both are entirely avoidable.

Sub-processors and international transfers

A processor that engages a sub-processor must impose the same data protection obligations by contract. The authorisation can be specific or general; if general, the controller must be able to object, and the processor must inform the controller of intended changes in time for that objection to mean something.

Transfers outside the European Economic Area need their own legal basis — an adequacy decision, or appropriate safeguards such as the 2021 standard contractual clauses. A DPA on its own does not authorise a transfer. If sub-processors are in third countries, the transfer mechanism must be documented in the same architecture as the processing itself, not bolted on later.

Making the DPA real

Three practices separate a working DPA from a filed one. First, keep the sub-processor list under version control with a named owner and a review date. Second, tie each entry in the measures annex to a named control that appears in your security documentation, so the two can be compared. Third, run an annual verification that the annex still describes what happens — because the value of a DPA is not in its signature, it is in whether the person reading it would recognise your operation.