A Data Processing Agreement (DPA) is a legally mandatory contract between a data controller and a data processor under GDPR. For a practical guide to the vendor assessment process that should precede any DPA, see our GDPR vendor management guide. Without one, both parties face significant fines, reputational damage, and regulatory scrutiny. This guide breaks down what a DPA must contain, who needs one, how the rules differ across the EU, UK, and USA, and how to manage your DPAs without drowning in paperwork.
As of March 2025, EU data protection authorities had issued more than 2,200 fines under the GDPR totalling roughly 5.6 billion euros, with failures to implement adequate controller-processor safeguards under Article 28 among the most frequently cited infringements (EDPB, 2025 enforcement statistics).
What Is a Data Processing Agreement?
TL;DRA Data Processing Agreement is a binding contract required under GDPR Article 28 between a controller and any third party that processes personal data on its behalf. It defines the scope, purpose, and duration of processing, sets security obligations, and allocates responsibilities. Without a valid DPA in place before processing begins, both parties face regulatory exposure.
A Data Processing Agreement (DPA) is a binding legal contract that governs how a data processor handles personal data on behalf of a data controller. It is a cornerstone of GDPR compliance and exists to confirm that personal data is processed only in ways that the controller has explicitly authorised, and that both parties understand their respective responsibilities.
The obligation is straightforward. If your company shares personal data with a third party that processes it on your behalf, whether a cloud provider, a payroll service, or an email marketing platform, you need a DPA in place before any processing begins.
Controllers vs. Processors: A Quick Refresher
TL;DRA data controller decides why and how personal data is processed. A data processor carries out the processing on the controller's behalf. Many organisations act as both, depending on the data flow. Correctly identifying your role in each relationship is the first step toward structuring a compliant DPA and avoiding misattributed liability.
Before diving deeper, it helps to clarify these two key roles:
Data Controller: The entity that determines the purposes and means of processing personal data. Example: a UK-based e-commerce company that collects customer purchase data.
Data Processor: The entity that processes personal data on behalf of the controller. Example: the shipping logistics company the e-commerce business uses to deliver orders.
In many modern business relationships, the lines can blur. A company may act as a controller for some data flows and a processor for others. That is why understanding your role in each relationship is critical, and why tools like Whisperly help organisations map these relationships automatically.
Why DPAs Are Legally Mandatory Under GDPR
TL;DRArticle 28 GDPR requires that all processing by a processor be governed by a binding contract. This is not guidance or best practice; it is a legal obligation with enforcement consequences. The same requirement applies under the UK GDPR and the Swiss nFADP, while US state privacy laws impose comparable contractual duties.
Article 28 of the EU General Data Protection Regulation (GDPR) makes it unambiguous: processing by a processor shall be governed by a contract or other legal act. This is not optional. It is not best practice. It is the law.
The same requirement is mirrored in the UK GDPR (retained post-Brexit under the Data Protection Act 2018) and the Swiss Federal Act on Data Protection (nFADP).
In the US, while there is no single federal equivalent to GDPR, sector-specific laws and state privacy regulations (more on this below) impose similar contractual obligations.
What Must a GDPR-Compliant DPA Include?
TL;DRArticle 28(3) GDPR specifies eight mandatory provisions for any DPA: documented instructions, confidentiality obligations, Article 32 security measures, subprocessor controls, assistance with data subject rights, breach notification support, data deletion or return at contract end, and audit access. Omitting any single element renders the agreement non-compliant.
Under Article 28(3) GDPR, a DPA must stipulate that the processor shall:
Process data only on documented instructions from the controller, including transfers of personal data to third countries, unless required by EU or Member State law.
Maintain confidentiality: persons authorised to process the data must be bound by a confidentiality obligation.
Implement appropriate technical and organisational security measures under Article 32.
Respect conditions for engaging sub-processors: the processor cannot engage another processor without prior written authorisation from the controller.
Assist the controller in fulfilling obligations related to data subject rights (access, erasure, portability, etc.).
Assist the controller with security obligations, breach notifications, DPIAs, and prior consultations.
Delete or return all personal data at the end of the service relationship.
Make available all information necessary to demonstrate compliance and allow for audits.
Practical Example
Imagine a Berlin-based HR software company ("HRSoft") that uses a US-based cloud infrastructure provider ("CloudCo") to host employee payroll data for its EU clients. HRSoft is the processor for its clients (the controllers), and simultaneously acts as a controller vis-a-vis CloudCo (which becomes a sub-processor). HRSoft needs a DPA with each client, and a separate sub-processing agreement with CloudCo. If HRSoft fails to get written authorisation from its clients before engaging CloudCo, it is in direct breach of Article 28 GDPR.
What Is a Subprocessor: And Why Does It Matter?
TL;DRA subprocessor is any company engaged by a processor to carry out part of the processing on behalf of the original controller. The same Article 28 obligations flow down the chain. Controllers must be notified of subprocessor changes, retain the right to object, and verify that subprocessor contracts mirror the protections in the primary DPA. Weak subprocessor governance is a leading cause of compliance gaps.
One of the most commonly overlooked aspects of DPA compliance is the sub-processor chain. When a processor engages another company to help carry out processing on behalf of the controller, that company becomes a sub-processor, and the same Article 28 obligations apply down the chain.
Controllers must:
- Be notified (and have the right to object) when a processor changes sub-processors.
- Verify that the processor's contract with the sub-processor mirrors the protections in the main DPA.
A real-world failure point: many SaaS vendors list their sub-processors in a webpage annexe and reserve the right to update it with minimal notice. Controllers should review these clauses carefully and negotiate meaningful notification windows where possible.
Controllers should therefore:
- Carefully review sub-processor clauses in DPAs and terms of service
- Negotiate reasonable prior notice periods (e.g. 15 to 30 days)
- Verify a genuine right to object, including practical remedies (such as termination rights if objection is upheld)
- Assess whether critical sub-processing (e.g. hosting, support, analytics) aligns with their data protection and transfer requirements
Sub-processors are not just a downstream detail. They are a core part of GDPR accountability. Weak governance at this level can expose controllers to compliance gaps, even where the primary processor relationship is fully documented and contractually compliant.
DPA Penalties in the EU: The Numbers Are Serious
TL;DRFailing to have a valid DPA, or maintaining a deficient one, exposes organisations to fines of up to 10 million euros or 2% of global annual turnover under Article 83(4) GDPR. Supervisory authorities across the EU have already imposed multimillion-euro penalties for controller-processor failures, and a missing DPA can serve as an aggravating factor in unrelated breach investigations.
Failing to have a valid DPA in place, or having an inadequate one, can attract significant sanctions under GDPR. Under Article 83(4) GDPR, infringements of Article 28 (processor obligations) are subject to fines of up to 10 million euros, or 2% of the total worldwide annual turnover of the preceding financial year, whichever is higher.
These are not theoretical risks. Supervisory authorities across the EU have sanctioned organizations for deficiencies in controller-processor relationships, including failures to implement adequate contractual safeguards under Article 28 GDPR. For example, the Spanish AEPD fined Vodafone Espana 8 million euros for unlawful processing involving insufficient compliance measures, while the Polish UODO imposed a 250,000 euro fine on Cyfrowy Polsat for inadequate safeguards in its cooperation with a processor. Such cases demonstrate that failures to properly structure and document processing arrangements, typically through a compliant Data Processing Agreement, can lead to significant enforcement action.
Beyond the direct financial penalty, a missing or deficient DPA can also constitute an aggravating factor in investigations that involve separate breaches, effectively compounding your risk exposure.
DPAs in the UK Post-Brexit
TL;DRThe UK GDPR retains the same DPA requirements as EU GDPR Article 28. The key difference is the transfer mechanism: UK-to-third-country transfers require the IDTA rather than EU SCCs. The ICO can impose fines of up to 17.5 million pounds or 4% of global turnover for the most serious violations.
Since the UK's departure from the EU, UK GDPR operates as a standalone regime under the Data Protection Act 2018. The requirements for DPAs under UK GDPR are substantively identical to EU GDPR Article 28. The ICO (Information Commissioner's Office) has published template DPA clauses that organisations can use.
Key UK-specific considerations:
International Data Transfers: The UK has its own transfer mechanism, the International Data Transfer Agreement (IDTA), which replaces the EU's Standard Contractual Clauses (SCCs) for UK-to-third-country transfers. If your DPA involves data flowing from the UK to, say, a US-based processor, you need to use the IDTA (or an addendum to the EU SCCs) rather than EU SCCs alone.
Fines: The ICO can fine up to 17.5 million pounds or 4% of global annual turnover (the higher figure) for the most serious GDPR violations, and up to 8.7 million pounds or 2% of global turnover for Article 28-type infringements, broadly mirroring the EU's tiered approach.
For US Companies Working With EU/UK Clients
TL;DRUS-based processors handling personal data of EU or UK data subjects must comply with GDPR regardless of their location. This means signing a GDPR-compliant DPA with each European client and relying on approved transfer mechanisms such as EU Standard Contractual Clauses or the EU-US Data Privacy Framework to legitimise the cross-border data flow.
If you are a US-based processor handling personal data of EU or UK data subjects on behalf of a European controller, the EU/UK GDPR applies to you. You will need to sign a GDPR-compliant DPA with your European clients, and you may need to rely on transfer mechanisms such as EU Standard Contractual Clauses (SCCs) or the EU-US Data Privacy Framework to legitimise the data transfer.
Example: A San Francisco-based analytics SaaS tool whose clients are German e-commerce companies must execute GDPR-compliant DPAs with each client, regardless of the SaaS company's US location.
Standard Contractual Clauses (SCCs) and DPAs: How They Interact
TL;DRStandard Contractual Clauses are pre-approved contractual terms issued by the European Commission for transferring personal data outside the EEA. The 2021 SCCs include a controller-to-processor module (Module 2) that can simultaneously function as a compliant Article 28 DPA, reducing duplication for legal teams managing large vendor portfolios.
Standard Contractual Clauses (SCCs) are pre-approved contractual clauses issued by the European Commission that provide a lawful basis for transferring personal data outside the EEA to countries without an adequacy decision (like the US, in many scenarios). Crucially, the 2021 EU SCCs include a controller-processor module (Module 2) that can serve as, or be incorporated into, a DPA.
This means that if you are a European controller engaging a US processor, your SCC agreement (using Module 2) can simultaneously function as your Article 28 DPA, provided it contains all the required clauses. This is an important efficiency for legal teams managing large vendor portfolios. For processor-to-controller transfers (for example, when a non-EU processor returns personal data to an EU controller), the relevant clauses are set out in SCC Module 4.
Common DPA Mistakes to Avoid
TL;DRThe most frequent DPA failures are vague processing scope descriptions, missing subprocessor provisions, restricted or absent audit rights, no data deletion or return clause, and failing to update agreements after the scope of processing changes. Any one of these gaps can render an otherwise well-intentioned DPA non-compliant under Article 28(3).
Even when companies have DPAs in place, they are frequently deficient. Watch out for these common errors:
Vague scope of processing: The DPA should specify the subject matter, duration, nature and purpose of processing, the type of personal data, and the categories of data subjects. Generic language like "processing as required by the services" will not pass regulatory scrutiny.
No sub-processor provisions: Failing to list sub-processors or require prior authorisation is a frequent gap.
Missing audit rights: Controllers must have the contractual right to audit their processors. Many vendor-form DPAs try to limit this to third-party certifications only, which may not be sufficient under GDPR.
No deletion/return clause: The DPA must address what happens to data at contract end. "We delete it after 90 days" in a service agreement is not the same as a contractual obligation in a DPA.
Not updating DPAs after scope changes: If a processor starts handling a new category of data (e.g., a vendor begins processing health data when they previously only handled contact information), the DPA must be updated.
How Whisperly Simplifies DPA Management
Managing DPAs across dozens, or hundreds, of vendors is one of the most operationally demanding aspects of GDPR compliance. Whisperly is a GRC platform with purpose-built data protection compliance modules designed to take the friction out of exactly this challenge.
With Whisperly, you can:
- Map your controller-processor relationships and identify where DPAs are missing or outdated.
- Maintain a centralised DPA register with status tracking, renewal alerts, and version history.
- Link DPAs to your Records of Processing Activities (RoPA) so your compliance picture is always coherent, a requirement under Article 30 GDPR.
- Track sub-processor chains and get notified when vendors update their sub-processor lists.
- Conduct vendor risk assessments prior to onboarding, confirming DPAs are in place before any processing begins.
Whether you are a controller managing a large supply chain of processors, or a processor needing to maintain compliant agreements with dozens of clients, Whisperly gives your team a single source of truth for your data protection obligations.
Key Takeaways
- A DPA is legally mandatory under EU GDPR, UK GDPR, and multiple US state privacy laws whenever personal data is processed by a third party on your behalf.
- Both controllers and processors bear responsibility: processors who accept work without a DPA are equally exposed to regulatory sanction.
- Penalties in the EU can reach 10 million euros or 2% of global turnover for Article 28 violations, per the official GDPR text.
- DPAs must be kept current: a DPA signed three years ago may no longer reflect the actual scope of processing.
- Tools like Whisperly make DPA lifecycle management scalable, auditable, and far less painful.
Frequently Asked Questions
Does every vendor relationship require a DPA?
Only where that vendor processes personal data on your behalf. If a vendor processes data for their own purposes (i.e., as an independent data controller), a DPA is not the right instrument. You would need a data sharing agreement instead. For help identifying which vendor relationships require a DPA, review your Records of Processing Activities.
Can a processor refuse to sign a DPA?
Under GDPR, a processor that refuses to sign a compliant DPA cannot legally be used for processing personal data. If a vendor will not sign, you face a choice: negotiate, or find an alternative vendor. Consider conducting a supplier due diligence assessment before onboarding any new processor.
What if we use a vendor's own DPA template?
You can, but scrutinise it carefully. Vendor templates are often written to limit the vendor's obligations. Check it against the Article 28(3) requirements and your own internal standards before signing. An AI vendor risk assessment can help identify gaps in vendor-supplied agreements.
How often should we review our DPAs?
At minimum, annually, and whenever there is a material change in the scope of services, the types of data processed, or applicable law. Linking your DPAs to your GDPR compliance programme helps surface review triggers automatically.
A signed DPA is one of the 12 areas regulators examine in every GDPR compliance audit. See the full GDPR audit readiness checklist for what to have ready.
Further Reading on Whisperly
Reviewed by: Tijana Zunic, Attorney at Law, AI Law and Data Protection Specialist