A Data Processing Agreement under the GDPR is not optional, and it is not a rubber stamp. Article 28 of the GDPR sets out specific requirements for what a DPA must contain when a controller engages a processor to handle personal data on its behalf. Those requirements are concrete: the DPA must specify the subject matter and duration of processing, the nature and purpose of processing, the type of personal data involved, and the categories of data subjects. It must impose specific obligations on the processor and give the controller specific rights.
In practice, many DPAs that circulate between organizations, particularly vendor-supplied templates, technically satisfy the Article 28 requirements at the surface level while leaving substantive gaps that would matter in an investigation or enforcement proceeding. This article is about identifying those gaps and understanding which clauses carry real compliance weight versus which are boilerplate that could be accepted or modified without material risk.
We are not offering legal advice. If your organization processes significant volumes of EU personal data, the specific DPA terms you accept or reject should involve qualified legal counsel familiar with GDPR. What we are offering is a framework for what legal-ops and procurement reviewers should be looking for when a vendor DPA comes across the desk.
The Article 28(3) Checklist and Why It Is Not Enough
Article 28(3) GDPR specifies eight categories of obligations that a DPA must impose on the processor. Briefly, these require the processor to: act only on documented instructions from the controller; ensure that authorized personnel are subject to confidentiality obligations; implement appropriate security measures under Article 32; respect the conditions for engaging sub-processors (Article 28(2) and (4)); assist the controller with data subject rights requests; assist with security obligations, breach notifications, and DPIAs; delete or return data at end of service; and make available all information necessary to demonstrate compliance and allow audits.
A vendor DPA that includes clauses addressing all eight of these categories is technically compliant with the Article 28(3) minimum. The question is whether the specific language in each clause gives the controller meaningful rights or merely states the obligation in a way that is difficult to enforce.
The difference matters. Consider the audit right, which Article 28(3)(h) requires. A DPA might state: "Processor will make available to Controller information demonstrating compliance with this Agreement and will permit Controller to conduct audits." That satisfies the literal requirement. It does not tell you: how much notice you must give before an audit, whether you can conduct on-site audits or only document reviews, whether audit costs are borne by the processor or the controller, and whether you can use a third-party auditor or must conduct the audit yourself. Vendors who prefer not to be audited will push language that makes the right technically present but practically difficult to exercise.
Sub-Processor Controls: Where Most Gaps Appear
The sub-processor provisions of a DPA are where we most commonly see gaps in vendor templates. Article 28(2) requires the processor to obtain the controller's authorization before engaging sub-processors, and Article 28(4) requires that sub-processors be subject to the same data protection obligations as the processor, such that if the sub-processor fails to fulfill its obligations, the processor remains fully liable to the controller.
Vendor DPAs typically present one of three approaches to sub-processor authorization: specific prior written consent for each sub-processor, a general authorization with a maintained list and notification of changes, or a blanket authorization without a list. Article 28(2) allows both specific and general written authorization; the EDPB guidelines clarify that general authorization is permissible if the processor maintains a list of sub-processors and notifies the controller before engaging a new one, giving the controller an opportunity to object.
The practical issues arise in how change notification and objection rights are structured. Some vendor DPAs provide notification of sub-processor changes by posting an update to a public webpage, with no obligation to proactively notify the controller. Controllers who do not monitor the vendor's website will miss the update. The objection period in many templates is 14 to 30 days; controllers who object after that window has passed may have no contractual right to challenge the sub-processor engagement even if it materially changes the risk profile of the processing.
What to push for: a proactive notification requirement (email to a named contact, not just a webpage update), a meaningful objection window (30 days minimum from active notification), and a right to terminate the relevant services if the objection is not resolved to the controller's satisfaction. Vendors who handle EU personal data professionally will accept these terms. Those who resist are signaling something worth examining.
Security Obligations and the Article 32 Reference
Article 28(3)(c) requires the DPA to address security measures under Article 32. Article 32 itself requires the controller and processor to implement "appropriate technical and organisational measures" taking into account the state of the art, costs, nature and purposes of processing, and the risk to data subjects. The standard is explicitly risk-based and context-dependent, not a fixed technical checklist.
The problem is that many vendor DPAs satisfy this requirement with a clause that simply restates the Article 32 standard without specifying what measures the processor actually implements. "Processor will implement appropriate technical and organisational measures in accordance with Article 32 GDPR" is a circular obligation that tells the controller nothing about the actual security posture of the processor.
More useful DPA language specifies the categories of measures the processor maintains: encryption of personal data in transit and at rest, access control architecture, personnel security (training, background checks where applicable), incident response and breach detection procedures, regular testing and evaluation of security measures. Not every measure needs to be documented at contract level, but the DPA should reference a security annex or a documented security policy that the controller can request and review.
This is not about requiring the vendor to expose proprietary security architecture. It is about the controller having a documented basis for assessing whether the processor's security controls are appropriate for the risk level of the processing before committing to the relationship.
Breach Notification Timing and Scope
Article 33(2) requires processors to notify controllers of personal data breaches "without undue delay" after becoming aware of a breach. The EDPB has interpreted "without undue delay" as meaning notification should occur as soon as possible and in any case within 72 hours where feasible. Controllers face their own 72-hour notification obligation to supervisory authorities under Article 33(1), which means the processor notification needs to arrive early enough to give the controller time to assess and report.
Vendor DPAs vary significantly in how they specify breach notification obligations. Some commit to notification within a specific timeframe (24 hours, 48 hours, 72 hours after processor awareness). Others use "without undue delay" language that mirrors the GDPR text without adding specificity. A few attempt to limit breach notification to incidents that meet a materiality threshold the processor defines unilaterally, which is not consistent with GDPR obligations.
The content of breach notifications also matters. A notification that says "we had a security incident affecting some customer data" is not sufficient for the controller to comply with Article 33(3), which requires notification to supervisory authorities to include the nature of the breach, the categories and approximate number of data subjects affected, the likely consequences, and the measures taken to address the breach. Push for DPA language that requires the processor to provide this information at notification, or as soon as it is available, rather than leaving the controller to extract it through back-and-forth after the fact.
Deletion and Return of Data
Article 28(3)(g) requires the DPA to address deletion or return of personal data at the end of the service. The standard language typically offers the controller a choice: return data in a usable format, or certify deletion. The practical questions are about timing, format, scope, and verification.
Timing: how long does the processor retain data after termination before deletion? Cloud service vendors sometimes retain data for 30 to 90 days post-termination for backup and recovery purposes. That retention window should be disclosed and limited, and the DPA should specify that backup copies are also included in the eventual deletion scope.
Format: if the controller requests data return, in what format will it be provided? A format that requires the vendor's own software to read is not a meaningful return right. Structured, machine-readable formats (CSV, JSON, standard database exports) are the appropriate standard.
Verification: a deletion certification from the processor is a contractual commitment, not independent verification. For high-risk processing, controllers may want the right to request a third-party audit or independent technical verification of deletion. This is rarely negotiated into DPAs but is worth requesting for relationships involving sensitive personal data categories under Article 9.
International Transfers and the Schrems II Context
If any processing under the DPA involves transfer of EU personal data to countries outside the EEA without an adequacy decision, Article 46 GDPR requires an appropriate transfer mechanism. Following the Court of Justice of the EU's Schrems II decision in 2020, standard contractual clauses (SCCs) remain the primary mechanism for most organizations, but with the added requirement of a transfer impact assessment (TIA) before relying on SCCs.
DPAs for processors based outside the EEA, or processors who use sub-processors outside the EEA, should incorporate the 2021 European Commission SCCs (the updated version that replaced the pre-2021 standard clauses). The DPA should also commit the processor to maintaining the transfer mechanism for the duration of the relationship and notifying the controller if the transfer mechanism is no longer valid, for example if the legal framework in the destination country changes in a way that compromises the SCCs.
We are not suggesting that every international data transfer is automatically high-risk. But the DPA needs to be the document that traces the legal basis for the transfer and the conditions under which that basis is maintained. If this is not addressed in the DPA, the controller may lack documentation to demonstrate compliance if a supervisory authority requests it.
Operationalizing DPA Review in Legal-Ops Workflows
The challenge for legal-ops teams reviewing significant numbers of vendor DPAs is building a consistent review process that catches material gaps without requiring full attorney review of every agreement. The practical approach is a tiered review process based on data risk: low-risk processing (no special category data, limited scope, mature vendor with standard controls) gets a checklist review against the Article 28(3) minimum; higher-risk processing gets a detailed review by someone with GDPR-specific expertise before sign-off.
The checklist for minimum review should explicitly cover: sub-processor list and notification procedure, breach notification timing, deletion scope and timing, audit rights, and international transfer mechanism where applicable. These are the provisions most likely to contain material gaps in vendor templates and the ones that will matter most if a regulatory issue arises.
DPAs should be linked in the contract repository to the underlying service agreement and tagged with the data categories processed under them. That linkage enables the compliance team to quickly inventory which vendor relationships involve EU personal data, which DPAs are in place, and when they may need to be updated (for example, if new sub-processors are added or if the scope of processing changes). Without that inventory, the first question a supervisory authority asks in a data protection inquiry is very difficult to answer quickly.