Data Processing Agreements (DPAs) — Checklist and Guide for DPOs

Data Processing Agreements under Article 28 GDPR are the contractual backbone of any controller-processor relationship. For external DPOs, reviewing, managing, and tracking DPAs across multiple clients is a core responsibility. This guide covers what a DPA must contain, common mistakes to avoid, and how to manage them efficiently at scale.

When Is a DPA Required?

A DPA is required whenever a controller engages a processor to process personal data on its behalf. The distinction between controller and processor is crucial: a controller determines the purposes and means of processing, while a processor acts only on the controller's instructions. Common processor relationships that require a DPA include: cloud hosting providers, email marketing platforms, payroll service providers, CRM systems, analytics tools, IT support companies with access to personal data, and external call centers. Not every vendor relationship requires a DPA. If a company uses a service where no personal data is processed (e.g., purchasing office supplies), no DPA is needed. Similarly, if two parties independently determine the purposes of processing, they are joint controllers under Article 26 and need a joint controller agreement instead of a DPA. For external DPOs, one of the most common audit findings is incomplete DPA coverage. Clients often have 20-30 processor relationships but only 10-15 DPAs in place. A systematic inventory of all vendor relationships is the essential first step.

Mandatory DPA Clauses (Art. 28)

Article 28(3) GDPR specifies the minimum content a DPA must include. Every DPA must contain: the subject matter and duration of processing, the nature and purpose of processing, the types of personal data and categories of data subjects, and the obligations and rights of the controller. Beyond these basics, the DPA must stipulate that the processor: processes data only on documented instructions from the controller, ensures that authorized personnel are bound by confidentiality obligations, implements appropriate technical and organizational measures (Article 32), engages sub-processors only with prior authorization and equivalent contractual obligations, assists the controller with DSAR responses, assists with security breach notification and DPIA obligations, deletes or returns data at the end of the contract, and makes available all information necessary to demonstrate compliance including allowing audits. Many organizations use template DPAs provided by the processor (e.g., AWS, Google, Microsoft). While these templates often cover the mandatory clauses, they may contain provisions that are unfavorable to the controller — such as broad sub-processing rights, limited audit access, or minimal liability caps. Always review processor-provided DPAs critically.

Common DPA Mistakes

The most frequent mistake is having no DPA at all for existing processor relationships. Many organizations signed contracts with SaaS providers years before GDPR enforcement and never added a DPA. These gaps are among the easiest audit findings for supervisory authorities to identify. Another common issue is outdated DPAs that do not reflect current processing activities. A DPA signed when a company used a service for basic email might not cover the expanded use case that now includes marketing automation, profiling, and cross-border data transfers. Sub-processor management is frequently neglected. Under Article 28(2), the controller must authorize sub-processors — either specifically or generally with a right to object. Many processors maintain lists of sub-processors that change regularly (especially large cloud providers). DPOs should ensure clients have a process for reviewing sub-processor changes. Finally, the end-of-contract provisions are often overlooked. Does the DPA specify deletion or return of data? Within what timeframe? In what format? These details become critical when switching providers or when a processor relationship ends.

Managing DPAs at Scale

For external DPOs managing 10-20 clients, each with 15-30 processor relationships, tracking DPAs manually becomes impractical. That is potentially 200-600 DPAs to monitor for expiry dates, sub-processor changes, and compliance gaps. A systematic approach starts with a central repository. For each client, maintain a list of all processor relationships with the corresponding DPA status: in place, missing, expired, or under review. Link each DPA to the relevant processing activities in your RoPA — this creates a complete compliance picture. Set expiry alerts for fixed-term DPAs. Many DPAs are tied to the underlying service contract and renew automatically, but some have fixed terms. An expired DPA means processing without a valid legal arrangement — a clear GDPR violation. Standardize your DPA review checklist. Rather than reading each DPA from scratch, check for the Article 28(3) mandatory elements, evaluate sub-processor provisions, verify data transfer safeguards (especially post-Schrems II), and confirm end-of-contract terms. Trustee.eu lets you track all of this per client with status indicators and deadline reminders.

Pro Tip: Start with the Top 5 Processors

When onboarding a new client, do not try to review all 30 DPAs at once. Identify the 5 processors that handle the most sensitive or the largest volume of personal data — typically payroll, CRM, cloud hosting, email, and HR software. Get those DPAs reviewed and compliant first, then work through the rest systematically.