A Data Processing Agreement is one of the few contracts where the law tells you exactly what has to be in it. Article 28(3) of GDPR lists the eight subject-matter requirements explicitly. A vendor whose DPA does not cover all eight is failing a basic statutory test, and that should be the first filter in any review. Beyond the statutory floor, however, the actual quality of a DPA varies enormously, and the differences matter when something goes wrong — a sub-processor breach, a government access request, a contractual termination, or a regulator’s audit.
This checklist is structured for someone who is reviewing a vendor’s standard DPA in a procurement cycle. The goal is to get through the document quickly, flag the issues that need negotiation, and produce a defensible record of why you accepted the version you accepted.
The eight statutory requirements
GDPR Art. 28(3) requires the DPA to set out, in writing, the following.
The subject matter and duration of the processing. A good DPA states this in the recitals or an annex. A red flag is a DPA that says “for the duration of the agreement” without specifying what the processing actually is.
The nature and purpose of the processing. Typically described in an annex listing the processing activities. The list should match what the product actually does. If the DPA says the processor will host customer content, but the master service agreement says the processor will also derive analytics from customer content, those should be reconciled.
The type of personal data and categories of data subjects. Annexed in writing. This determines what counts as personal data under the contract. Watch for DPAs that include “any data the controller chooses to upload” — that puts the onus entirely on you to know what you are sending.
The obligations and rights of the controller. Acknowledged in the DPA.
Processing on documented instructions from the controller. This is the famous Art. 28(3)(a) clause. The processor cannot process personal data except on the controller’s documented instructions. The DPA itself counts as a documented instruction, which is why what the DPA actually authorises matters. Look for processors trying to expand this through clauses like “the processor may process personal data to improve its services” — that needs scrutiny.
Confidentiality obligations on personnel. The processor must ensure that persons authorised to process the personal data have committed themselves to confidentiality.
Security measures (Art. 32). Reference to technical and organisational measures, typically annexed.
Sub-processor terms. Either prior specific or general written authorisation, with mechanisms for notifying the controller of changes and providing an objection window. This is one of the most frequently litigated clauses — see the sub-processor section below.
Assistance with data subject rights. The processor must assist the controller in responding to data subject requests under Chapters III of the GDPR.
Assistance with security incidents, DPIAs, and prior consultation. Specifically Art. 32-36.
Deletion or return of data at contract end. And deletion of existing copies unless retention is required by Union or Member State law.
Audit rights and information requests. The processor must make available all information necessary to demonstrate compliance and allow for audits, including inspections, conducted by the controller or another auditor mandated by the controller.
If any of these eight categories is missing, the DPA does not meet the GDPR floor. Most reputable SaaS DPAs cover all eight, often using language lifted directly from the regulation.
The clauses that actually vary
Once a DPA passes the statutory floor, the substantive variation lives in a smaller set of clauses. These are where review time should be spent.
Sub-processor governance
The minimum is a list of current sub-processors (often by reference to a URL), a commitment to advance notice of changes, and an objection mechanism for the controller. The variation is in the details. How long is the notice period — fourteen days, thirty days, ninety days? What is the consequence of an unresolved objection — can you terminate without penalty, or is the only remedy a refund? Does the vendor commit to flowing down equivalent contractual obligations to its sub-processors? Is the sub-processor list versioned, with a changelog?
The 2021 EU SCC framework requires the sub-processor list to be publicly available — Module Two, Clause 9(c). A vendor that hides the sub-processor list behind a sales conversation is not aligned with the SCCs.
Cross-border transfers
The DPA should specify the transfer mechanism the parties rely on for any onward transfers outside the EEA. For US sub-processors, expect either the 2021 SCCs or the EU-US Data Privacy Framework. For UK sub-processors, the UK Adequacy Decision. For other third countries, SCCs are the default.
Watch for DPAs that are silent on cross-border transfers. That silence does not mean transfers do not happen — it means the contractual mechanism is undocumented.
Data localisation commitments
If the vendor advertises EU data residency, the DPA should bind that commitment. A marketing page claiming “data stays in the EU” is not enforceable unless mirrored in the contract. Look for explicit language: “Customer data shall be stored in [specific regions]” with a defined process for the controller to consent to changes.
Government access requests
The strongest DPA language commits the processor to notify the controller before disclosing personal data in response to a government order, unless legally prohibited from doing so. Stronger still is a commitment to challenge orders the processor considers overbroad or improperly authorised.
The carve-out — “unless legally prohibited” — is real and unavoidable for some jurisdictions. What matters is the vendor’s published transparency report and demonstrated history. A vendor that has never published a transparency report is asking for trust that has not been earned.
Audit rights
Art. 28(3)(h) requires audit rights, but in practice, most vendors do not allow customers to physically inspect data centres. The negotiated middle ground is acceptance of a third-party audit report (typically ISO 27001 or SOC 2 Type II) as discharging the audit obligation, with the right to a remote audit on reasonable notice if the third-party report is insufficient. Watch for clauses that allow the vendor to charge for audits — that is acceptable if reasonable, abusive if used to deter exercise of the right.
Liability and indemnification
DPAs typically incorporate the master agreement’s liability cap. Some vendors push for a separate, lower cap specifically for data protection liability. Push back on this — a major breach can easily exceed any standard cap.
Termination and data return
The DPA should specify the format of data return (export formats, API access window), the retention period for deletion certification, and the cost of return. Vendors who charge significant fees for data export at termination are signalling that they expect to keep customers locked in.
Common red flags
Several patterns appear in DPAs that should slow down or stop a procurement.
A DPA that classifies the vendor as a “joint controller” or “independent controller” for purposes that look like processing. This often appears in analytics and adtech DPAs. The classification has real legal consequences — joint controllers have shared liability, and independent controllers can use the data for their own purposes. If the product is functionally a processor relationship (vendor processes data on your instructions to provide a service), the DPA should reflect that.
A DPA that reserves the right to use personal data in aggregated or anonymised form for the vendor’s own purposes. This is sometimes acceptable, but the anonymisation methodology matters. If the “aggregated” data is recoverable to individuals, it is not anonymised under GDPR. Look for specific technical descriptions of the anonymisation process.
A DPA that requires the controller to indemnify the processor against any third-party claims arising from the processing. This inverts the risk allocation. The processor should indemnify for breaches caused by its own actions; the controller should indemnify only for instructions outside the scope of the DPA.
A DPA without a clear sub-processor objection mechanism, or with an objection mechanism that only allows the controller to terminate (rather than first negotiate, then terminate if unresolved).
A DPA whose security measures annex is purely aspirational — “industry-standard security measures” without specifics. The annex should commit to identifiable controls: encryption at rest, encryption in transit, role-based access control, logging, vulnerability management, incident response.
A practical review workflow
For a typical mid-size SaaS purchase, a DPA review should take two to four hours. The structure that scales is to first run through the eight statutory categories and confirm coverage, then read the sub-processor, cross-border, government access, and audit clauses in detail, then check the data localisation commitments against the vendor’s public statements, then check the liability and termination language against your master agreement.
If you find a substantive issue — a missing statutory requirement, an aggressive carve-out, an inverted liability allocation — flag it in writing to the vendor before signing. Most reputable vendors will negotiate on these points, particularly for enterprise customers. The ones who will not are signalling something useful about the relationship you would have post-signature.
The output of the review should be a short memo: vendor name, DPA version reviewed, statutory compliance confirmed, material issues identified, negotiated changes, residual risks accepted, sign-off. That memo is what an auditor or regulator will eventually ask for.
When the DPA is a side letter to a US vendor
The hardest DPAs to review are the ones attached to US-headquartered vendor contracts where the SaaS agreement is governed by US law and the DPA is a bolt-on. The substantive coverage may be fine, but the integration with the master agreement is often poor — terms in the SaaS agreement contradict terms in the DPA, choice of law clauses fight, dispute resolution mechanisms misalign.
This is one of the practical procurement reasons EU buyers increasingly favour EU-incorporated processors. The DPA and the SaaS agreement are written under the same legal system, by the same lawyers, and the integration tends to be cleaner. The EU Stacks directory exists in part to make this comparison easier — every vendor profile links to the published DPA so you can run this review before the first sales call.
The DPA is the most underrated piece of a SaaS contract. It is often the single document a regulator will read first if something goes wrong, and it is one of the few places in the buyer-vendor relationship where the law gives the buyer real leverage. Use it.