This article is part of the Ask a Compliance Expert series.
Key takeaways
- Article 28(3) GDPR requires five framing details plus eight specific processor duties in points (a) to (h). Any data processing agreement review starts with that list, because it is incomplete more often than you would expect in 2026.
- Failing to check and monitor a processor carries a fine. Germany's federal regulator, the BfDI, fined Vodafone a total of EUR 45 million in 2025, of which EUR 15 million was solely for inadequate vetting and supervision of partner agencies under Article 28(1) GDPR.
- Sub-processors are the critical part. Under Article 28(4) GDPR the same data protection obligations must be imposed on the sub-processor, and the first processor remains liable to you for its failures.
- A contractual liability cap only binds the parties to the contract. Under Article 82(4) GDPR each party involved is liable to the data subject for the entire damage.
- Whether an imperfect data processing agreement is acceptable is a management decision, not the DPO's. The DPO informs and advises under Article 39(1)(a) GDPR; the controller carries the risk decision under Article 24(1).
What do you check first in a data processing agreement?
Whether the mandatory contents required by Article 28(3) GDPR are actually all there. That sounds basic, and it is the point where most contracts fail.
The first question in every review is the same one: does the contract contain every element the GDPR prescribes? You might assume this stopped being an issue in 2026, now that a clean first draft takes minutes to produce. In practice it has not.
Article 28(3) first sentence sets out five framing details: the subject matter and duration of the processing, the nature and purpose of the processing, the type of personal data, the categories of data subjects, and the obligations and rights of the controller. The second sentence then lists eight specific processor duties. The table below shows what to look for in each one.
A common misconception: because the vendor supplied the contract, someone must have checked it. The opposite is true. Article 24(1) GDPR places the burden of demonstrating compliance on the controller, which is you. And Article 28(1) requires you to actively use only processors that provide sufficient guarantees.
The Vodafone case shows what ignoring that duty can cost. In 2025 the German Federal Commissioner for Data Protection and Freedom of Information imposed fines totalling EUR 45 million on Vodafone GmbH. EUR 15 million of that related solely to partner agencies acting for Vodafone that had not been adequately vetted and supervised, a breach of Article 28(1) GDPR. The fines were accepted and paid in full, as set out in the authority's press release.
What makes the case instructive is that it did not turn on a missing contract. It turned on missing oversight. Where Article 28 sits among the regulation's other duties is covered in our complete GDPR guide for companies.
Why are sub-processors the most critical part of a DPA?
Because that is where the data actually ends up, and because the chain rarely stops where the contract does.
Any serious review concentrates on the sub-processors. Almost no vendor delivers its product alone any more; further providers sit in the processing chain handling the same data. Two questions decide everything: which data goes to those providers, and where does that data sit?
Two paragraphs govern this. Article 28(2) GDPR requires prior specific or general written authorization. If you work with a general authorization, which is the normal case in practice, you must be informed of every intended change and keep a right to object. That notice and objection right is exactly what vendor contracts tend to define away. Article 28(4) then requires the same data protection obligations to be imposed on the sub-processor; if it fails to meet them, the first processor remains liable to you.
So check three things: the current sub-processor list, the processing location for each one, and the mechanism by which you find out about changes. A newsletter nobody subscribed to is not a mechanism. The chain itself belongs in your record of processing activities, otherwise you cannot say where the data sits when a data subject asks.
The second common misconception concerns EU hosting. Teams see a contract with the Irish subsidiary of a US vendor, read "data is hosted in the EU", and end the review there. That is not a place to stop. Behind the subsidiary stands the US parent company, and US law can permit access to data that subsidiary processes in the EU.
This reading is neither new nor exotic. The European Data Protection Board and the European Data Protection Supervisor stated in their joint response to the LIBE Committee of 10 July 2019 that a US disclosure order under the CLOUD Act does not by itself provide a lawful basis for a transfer. Contracting with the EU subsidiary is an advantage, then, but not the end of the review. When that turns into a separate transfer impact assessment is a topic of its own and outside the scope of this article.
Which clauses are drafted in the vendor's favor?
Most often contractual penalties for breaching the DPA, and liability caps. Neither is inherently unlawful, and both belong in a two-step review.
Vendor contracts frequently contain the mandatory elements but shape them in the provider's favor. Penalties that apply if the customer breaches the DPA are one example, liability caps another.
The first step is whether the clause is permissible at all. A provision that hollows out a mandatory duty from Article 28(3), such as an audit right that exists only on paper, is not. The second step is the commercial question of whether you want to accept it.
With liability caps it is worth looking at what they actually limit. Under Article 82(4) GDPR each controller and each processor involved in the same processing is liable to the data subject for the entire damage. A cap in the DPA does not change that. It only operates at the next level, in the internal recovery claim under Article 82(5). So accepting a liability cap of one annual fee does not mean your own exposure is capped. It means you carry most of it yourself if something goes wrong.
A third point rarely makes it into clause review but belongs there: Article 28(10) GDPR. A processor that determines the purposes and means of processing in breach of the regulation is considered a controller for that processing. Clauses granting the vendor its own use of your data, for product improvement for instance, shift exactly that role. For you it means the processing you documented as processor activity is at least partly no longer that.
The full text of the article is available in the official version of the regulation.
What do you do when the vendor refuses to amend the DPA?
You document the deviation, assess the risk, and put the decision where it belongs, with management.
Take a 30-person SaaS company using a marketing tool from a very large US vendor. The DPO finds three deviations in the DPA: an audit right reduced to producing a certificate, a general sub-processor authorization with no effective right to object, and a liability cap set at the annual fee. They write to the vendor's privacy address. They get a form reply.
That is the rule, not the exception. A 30-person company sending specific amendment requests to a very large US vendor's privacy address will almost never get the outcome it wants. The negotiating power is simply not there, and no amount of additional review changes it.
At this point many teams make the same mistake. They treat the outcome as a pure compliance question and expect the DPO to say yes or no to the tool. That is not the DPO's role.
You will not be able to conclude a fully GDPR-compliant data processing agreement in every case. The question then becomes whether the outcome is acceptable for your business, and that decision belongs to management. The DPO advises and supports the assessment; the leadership has to carry the decision.
The regulation splits the roles this way explicitly. Under Article 39(1)(a) GDPR the DPO informs and advises; under Article 24(1) the controller bears responsibility and must be able to demonstrate it. In practice this means the DPO delivers a written assessment listing the specific deviations, the risk attached to each, and, where possible, compensating measures such as data minimization, pseudonymization, or dropping particular data categories. Management signs off. That sign-off is itself evidence under Article 5(2) GDPR and belongs in the file, not in a Slack thread.
If you cannot or would rather not fill that role internally, an external data protection officer takes it on. In law, an external appointment is equivalent to an internal one.
What changes when a DPA covers AI components?
The review method stays the same, but one question is added that older contracts never had to answer.
AI components are increasingly part of data processing agreements, specifically providers supplying AI models. The detail question then becomes: what happens to your data once it enters those models?
Two commitments decide almost everything here. First, are your inputs used to train the model? The exclusion is usually standard in enterprise and business contracts, often absent in self-service tiers, and it belongs in the contract rather than on an FAQ page. Second, is there zero data retention, meaning processing only to generate the output and deletion at the provider afterwards? That shortens the retention period and removes a good part of the risk with it.
Neither is purely a contract question. The European Data Protection Board clarified in its Opinion 28/2024 of 17 December 2024 that an AI model is not anonymous merely because it is not a database, and that the lawfulness of the development phase can carry through to later processing. For your DPA review the practical consequence is one thing above all: the commitments you rely on have to be in the contract and have to be verifiable.
As long as the purpose of your processing does not change, using an AI provider needs no separate new legal basis; the Article 28 data processing agreement is the basis for the transfer. If the purpose does change, the six lawful bases in Article 6(1) apply, which we work through individually in the GDPR guide.
How does Kertos support data processing agreement reviews?
The Kertos platform holds the vendor landscape in one place. For each provider the data processing agreement, the sub-processor chain, the processing location, and the risk assessment sit on the same record, and the processing activity is linked to the Article 30 record. Vendor management is the part that is most often missing in practice: not the individual contract, but the overview of which contracts exist and when each was last reviewed.
The review itself stays expert work. Kertos customers work with a named contact from a team of certified experts who assesses the contract, sets out the deviations, and prepares the paper that goes to management. Where a customer wants it, Kertos takes on the external data protection officer mandate in full.
To see what that looks like for your own vendor landscape, book a demo.
Frequently asked questions
What must be included in a data processing agreement?
Article 28(3) GDPR requires five framing details: the subject matter and duration of the processing, the nature and purpose of the processing, the type of personal data, the categories of data subjects, and the obligations and rights of the controller. On top of that come eight processor duties in points (a) to (h), running from the instruction requirement through the technical and organizational measures to deletion or return of the data when the service ends.
Who is responsible for putting a DPA in place, the customer or the vendor?
Both sign it, but the duty to make sure it exists and is complete sits with the controller. Article 24(1) GDPR requires the controller to demonstrate that the processing is lawful. In practice the vendor almost always supplies the draft, which does nothing to move the review obligation away from the customer.
Is a data processing agreement valid without a signature?
Yes. Article 28(9) GDPR requires written form but expressly permits an electronic format. An accepted online agreement or a contract document confirmed by email is sufficient; a handwritten signature is not required. What matters is that you can produce the version in force at any time.
What happens if there is no data processing agreement in place?
The breach falls under Article 83(4) GDPR and carries fines of up to EUR 10 million or 2 percent of worldwide annual turnover, whichever is higher. That supervisory authorities use this range is clear from the Vodafone case, with EUR 15 million for inadequate oversight of service providers alone. Liability to data subjects under Article 82 GDPR comes on top.
Do sub-processors have to be named in the DPA?
The regulation does not require a list of names in the contract itself. Article 28(2) GDPR requires prior specific or general written authorization. With a general authorization, the processor must inform you of every intended change and give you the opportunity to object. A maintained, linked sub-processor list with change notifications is the usual way to implement that.
Legal position as at 20 August 2026. This article reflects the review practice of the Kertos data protection officers and is intended as professional orientation. It does not replace legal advice on an individual case.
