When an undertaking has personal data processed by an external party, a DPA (Data Processing Agreement) is not an optional formality. Under the GDPR, processing by a processor must be governed by a binding contract or other legal act when that party processes personal data on behalf of the controller.
Think, for example, of an external payroll provider, cloud supplier, CRM platform, IT service provider or marketing partner that processes personal data according to your undertaking’s instructions.
The first question is therefore not: “Do we work with personal data?”, but rather: “What role does each party have?”
Establishing responsibilities
Not every external supplier is automatically a processor. A controller determines why and in what manner personal data are processed. A processor processes those data, by contrast, on behalf of the controller.
That distinction is crucial, because only when there is genuinely a processor relationship does Article 28 GDPR apply and a DPA must be concluded. A supplier that itself determines the purposes and essential means of the processing can itself be a controller.
Calling a contract a “DPA” does not change that legal characterisation. What is more: when a processor itself starts determining the purposes and means of a processing operation, the GDPR regards that party as controller for that processing.
A DPA must be far more concrete than “complying with the GDPR”
A correct DPA does not merely state that the parties will respect privacy legislation. Article 28 GDPR requires, among other things, that the following be recorded:
- the subject-matter and duration of the processing;
- the nature and purpose of the processing;
- the types of personal data that are processed;
- the categories of data subjects concerned;
- the rights and obligations of the controller.
In addition, the processor must among other things undertake to process only on documented instructions, to ensure confidentiality, to take appropriate security measures and to assist the controller with certain GDPR obligations.
A one-page DPA whose only message is “the processor respects the GDPR” is therefore legally particularly thin.
Data breaches: make arrangements before things go wrong
One of the most critical parts of a DPA is the incident protocol. Under the GDPR, a processor must inform the controller without undue delay as soon as a data breach is discovered. The controller after all has only 72 hours to notify the supervisory authority and must assess whether the data subjects concerned must also be warned.
“Without undue delay” is too vague in practice. A sound DPA makes this operational: within how many hours does the supplier report the incident (for example within 24 or 48 hours)? Which technical details are supplied immediately? Who investigates the cause and who bears the costs of remedial measures and external communication? By locking this down contractually in advance, you avoid costly loss of time during a crisis.
You cannot fully contract out of GDPR liability
Here lies an important difference between commercial arrangements and statutory liability. Parties can make contractual arrangements on liability, indemnities and the mutual allocation of costs. But such a clause cannot simply switch off the statutory rights of data subjects under the GDPR.
The GDPR has its own liability rules for damage resulting from an infringement. Concrete liability depends among other things on the role of each party, the nature of the infringement and the circumstances of the file. That means an undertaking cannot fully protect itself by simply writing in a DPA that “all responsibility lies with the processor”.
A sound DPA therefore allocates contractual risks, but does not automatically change the statutory responsibilities vis-à-vis data subjects or supervisory authorities.
Sub-processors: who actually sits behind your supplier?
An often underestimated point is the use of sub-processors. A processor may not simply engage another party for the processing. Prior specific or general written authorisation of the controller is required. In the case of general authorisation, the controller must moreover be informed of planned changes, so that it can object.
That is especially relevant for cloud and software providers. You contract, for example, with one SaaS provider, but several hosting, support or analytics tools may sit behind that service. Moreover, the first processor remains fully liable vis-à-vis the controller for the performance of the data-protection obligations of its sub-processor when the latter falls short.
Where are your data located?
The geographic location of data processing also deserves attention.
When personal data are transferred outside the European Economic Area, additional rules on international transfers apply. A DPA alone therefore does not automatically make such a transfer lawful. In practice it is therefore necessary to examine which parties have access to data, where systems are hosted and whether additional mechanisms or safeguards are required. That makes the list of sub-processors and the IT infrastructure used legally far more relevant than it may at first appear.
What happens after the end of the collaboration?
A DPA should also regulate what happens to personal data when the service ends.
The GDPR provides that the processor must, at the choice of the controller, erase or return personal data after the end of the services, and must delete existing copies, unless the law requires further retention.
That is an important exit point in practice. Can you technically get your data back? In which format? How quickly? Are backups also erased? What happens to data in the event of a dispute or the supplier’s insolvency? A strong DPA therefore looks not only at today’s collaboration, but also at its end.
A DPA is not a substitute for a privacy policy or an NDA
A DPA, a privacy policy and an NDA each have a different function.
A DPA regulates the relationship between a controller and a processor. A privacy policy or privacy notice concerns, among other things, how personal data are processed and which information must be given to data subjects. An NDA, in turn, protects confidential information in a broader sense. Those documents can complement one another, but they are not legally interchangeable.
A collaboration agreement or management agreement can also contain privacy clauses, but when Article 28 GDPR applies, the mandatory elements of the processor agreement must be present. The European Commission has even adopted standard contractual clauses that parties can use in whole or in part.
A standard template is rarely the whole story
A generic DPA can be a good starting point, but the real value lies in alignment with the concrete processing. A payroll provider processes different data and carries different risks than a cloud hoster or a marketing agency. Security measures, retention periods, sub-processors, international transfers and support with data-subject requests can also differ substantially.
It is therefore useful not only to ask whether “a DPA” exists, but also whether that agreement corresponds to what actually happens in practice. A professionally drafted DPA not only ensures compliance, but also makes clear who bears which responsibility when personal data are processed, an incident occurs or the collaboration ends. And that is precisely where the legal added value lies: not in as many clauses as possible, but in arrangements that align with the undertaking’s actual data flows and risks.
