Skip to content

Data processing agreement

A data processing agreement is the contract between a controller and a processor setting out what personal data may be processed, for what purpose, under whose instructions, with what security, for how long and with which sub-processors. It is a required document rather than an optional annexe.

A processor cannot bring in another processor without the controller's written authorisation, which is why the sub-processor list is the part worth reading.

Why it matters when the plan changes

The agreement is where the promises made in a sales conversation either become enforceable or do not. Purpose, retention, access and sub-processing are all settled here, and they are the four questions a works council, a data protection officer and a procurement team will ask independently. Article 5 of the General Data Protection Regulation ties later use to the purpose originally recorded, so a vague purpose clause weakens every later use case rather than only the current one. A clear agreement answers all three audiences at once.

The tension is between flexibility and assurance. A supplier wants room to change infrastructure and improve the product; a controller wants to know what will happen to the data and to be told before it changes. Article 28 sets the baseline: a processor may not engage another processor without prior specific or general written authorisation, and must inform the controller of intended changes. The workable position is a specific agreement with a defined notification route rather than broad permissions.

In practice

A procurement review approves a supplier on the strength of a security summary. The data protection officer reads the agreement and finds a general authorisation for sub-processors with no notification requirement. Nothing improper has happened and the controller has no way to know where the data will sit next quarter.

Evidence

What it cannot tell you

A data processing agreement records what is permitted; it does not verify what is actually happening to the data. It does not confirm the sub-processor list is current, that instructions are followed, or that the controller and processor roles are correctly assigned. It is also silent on separate regimes, such as AI Act obligations, which the agreement does not and cannot cover.

Questions

In an employment context the employer is normally the controller, deciding why and how personal data is processed; the supplier is the processor acting on documented instructions. Article 28 of the General Data Protection Regulation (2016) sets out the processor's obligations, including the terms this agreement must contain.

The purpose, the retention period, the access model and the sub-processor arrangements. Those four settle what actually happens to the data. Security descriptions are important and are rarely where the surprises are, because they are the part everyone expects to be examined.

Permission, under Article 28 of the General Data Protection Regulation (2016), for a processor to add sub-processors without asking each time, provided the controller is informed of intended changes and can object. It is workable only when the notification route is specific rather than implied.

No. They are separate regimes with separate requirements. A complete agreement says nothing about whether a system is high-risk under the AI Act, what documentation it needs or whether human oversight is adequate. Treating one as covering the other leaves the second unanswered.

Before signature, and again whenever the purpose, the data, the sub-processors or the retention changes. In practice it is read once during procurement and then relied on for years, during which every one of those four things may have moved without anyone rereading it.