A data processing agreement (DPA) is a legally binding contract between a data controller and a data processor. It sets out how the processor may handle personal data on the controller's behalf. Under GDPR Article 28, it is mandatory whenever a third party processes personal data for you.
Below: what a DPA must say under Article 28, who signs it, when you need one, and what happens if you skip it.
What Is a Data Processing Agreement?
A data processing agreement, also called a data processing addendum, is a written contract that governs how a processor handles personal data for a controller. It documents the processor's instructions, security duties, data-subject-rights support, and end-of-contract data deletion. It is a business-to-business contract about data handling, not a policy shown to your website visitors.
The agreement exists because GDPR Article 28 requires a binding contract wherever a controller uses a processor. Without it, the controller cannot demonstrate that a third party is handling personal data lawfully.
A DPA does not replace your privacy policy or your cookie policy. Those documents tell your users what you collect and why. The DPA governs the separate relationship between you and the vendors that touch your data.
Most SaaS vendors publish a standard DPA that customers can review or countersign, rather than negotiating a bespoke contract per customer. Consently, for instance, publishes its own customer-facing DPA covering how it processes the consent data it collects on your behalf.
What Else Does "DPA" Stand For? (Quick Disambiguation)
DPA is a heavily overloaded acronym. In privacy and business it means a data processing agreement. The table below lists the other common senses you may run into.
| Acronym meaning | Field / context |
|---|---|
| Data Processing Agreement | Privacy and technology (this page) |
| Deferred Prosecution Agreement | Criminal law |
| Down Payment Assistance | Real estate |
| Durable Power of Attorney | Healthcare and finance |
| Defense Production Act | US government |
| Data Protection Authority | Privacy regulation (the regulator, not the contract) |
The rest of this guide is about the data processing agreement, the GDPR-defined contract between a controller and a processor.
Why Is a DPA Required? (GDPR Article 28)
A DPA is required because GDPR Article 28 says a controller may only use a processor under a binding contract. The requirement also carries into UK GDPR and into several US state privacy laws, including CCPA/CPRA.
The contract exists to do three things. It protects data-subject rights by binding the processor to specific duties. It allocates liability between controller and processor if something goes wrong. And it gives the controller documented proof of accountability during a regulator audit. Without a signed DPA, a controller has no contractual mechanism to enforce any of these.
Data Controller vs Data Processor: Who Is Who?
A data controller decides why and how personal data gets processed. A data processor acts only on the controller's documented instructions and has no independent say over the purpose of the processing.
| Role | Decides purpose and means? | Typical example |
|---|---|---|
| Controller | Yes | A website owner collecting visitor data |
| Processor | No, acts on instructions | An email or analytics tool the site uses |
| Sub-processor | No, acts on the processor's instructions (with controller permission) | The processor's own cloud hosting provider |
A website owner running its own site is usually the controller. The tools it plugs in, an email platform, an analytics service, a consent management platform, are usually processors. Those tools' own infrastructure vendors, cloud hosts especially, are sub-processors one level further down the chain.
Per the EDPB's Guidelines 07/2020, the determining test is always decision-making authority. Whoever decides the purpose and means of the processing is the controller. Company size and who drafted the contract do not change that.
What Must a DPA Include? (The Article 28 Clauses)
GDPR Article 28(3) sets out exactly what a compliant DPA must contain. Before the eight processor duties, the contract must first define the scope of the processing.
That scope covers four things.
- The subject matter and duration of the processing
- The nature and purpose of the processing
- The type of personal data and the categories of data subjects involved
- The obligations and rights of the controller
With that scope fixed, the contract must then require the processor to do the following.
- Process personal data only on the controller's documented instructions, including for international transfers
- Keep staff who access the data under confidentiality obligations
- Apply appropriate security measures under Article 32
- Not engage a sub-processor without the controller's prior written authorization, and impose the same data-protection obligations on any sub-processor it does engage
- Help the controller respond to data-subject-rights requests
- Help the controller comply with breach notification, DPIAs, and regulator consultation duties
- Delete or return the personal data once the contract ends
- Allow audits and provide the information needed to prove compliance
The contract itself must be in writing, including in electronic form. A DPA that omits the scope details above or any of these eight duties fails Article 28, however comprehensive it otherwise looks.
When Do You Need a DPA?
You need a DPA whenever another company processes personal data on your behalf. That covers cloud hosting, email marketing, analytics, payroll, CRM, customer support, and any SaaS tool that touches your users' data.
Common scenarios that trigger the requirement:
- Hosting your site or storing customer data with a cloud provider
- Sending marketing or transactional email through a third-party platform
- Running analytics or ad tools that process visitor data
- Using a support desk, CRM, or payroll vendor that stores personal data
- Letting an external agency access your customer database directly
One Reddit user described the moment this becomes unavoidable. A European customer refused to move forward with a trial until a signed DPA was in place, and the request arrived with no warning. That is the typical trigger. A prospective customer, often one covered by GDPR or a US state privacy law, asks for a signed DPA before the deal closes, not after.
Do You Need a DPA in the US?
Yes, increasingly. No single US federal law mandates a DPA the way GDPR Article 28 does. But the requirement now comes from several directions at once. GDPR applies whenever you process EU or UK residents' data. A growing list of US state privacy laws applies too. California's CCPA/CPRA leads that list, alongside Virginia, Colorado, Connecticut, and Utah, each imposing its own controller-processor contract requirement.
Beyond the legal triggers, US organizations routinely demand a DPA from vendors on contractual grounds alone. This holds whether or not a specific law compels it. School systems in particular ask for one as standard vendor due diligence before any tool touches student data.
Who Signs a DPA, and Are You the Controller or the Processor?
Both parties sign a DPA: the data controller and the data processor. Which one you are depends on a single question. Do you decide why and how the data is used (controller), or do you only handle it on someone else's instructions (processor)?
A website owner using third-party tools is usually the controller, signing DPAs with each vendor it relies on. A SaaS vendor is usually the processor, the one its own customers ask to sign.
The determination is fact-specific, not a matter of company size. It depends on who actually decides the purpose and means of the processing. Documenting that determination in writing, whichever role you land in, is the point of the contract either way.
DPAs, Sub-Processors, and International Data Transfers (SCCs)
A DPA also governs the chain below the processor and what happens when data leaves the EU or UK. When a processor hires its own vendors, sub-processors, it needs the controller's permission first, and the same data-protection obligations flow down the chain.
When personal data crosses borders out of the EU or UK, the parties typically rely on standard contractual clauses (SCCs) to keep the transfer lawful. The sub-processor and SCC language in a typical DPA template can read as dense legal jargon. The underlying idea is simple: every party that touches the data, and every border it crosses, needs its own documented, GDPR-compliant safeguard.
DPA vs NDA vs Privacy Policy: What's the Difference?
A DPA, an NDA, and a privacy policy each govern a different relationship and none can substitute for another. The clearest way to separate them: an NDA protects the secret, a DPA protects the data subject.
| Document | What it does | Between whom |
|---|---|---|
| DPA | Governs how personal data is processed and secured | Controller and processor |
| NDA | Protects confidential business information from disclosure | Any two contracting parties |
| Privacy Policy | Tells your users what data you collect and why | You and your users or the public |
A DPA is a regulatory requirement under GDPR and similar laws whenever a processor handles personal data. An NDA, by contrast, is a purely commercial, optional agreement about trade secrets and business information. Neither replaces your privacy policy: that is the user-facing document explaining your own data practices, not a vendor contract.
A DPA is one of several website legal pages every compliant site needs, alongside your privacy and cookie policies.
What Happens If You Don't Have a DPA?
Operating without a required DPA is a GDPR violation that can result in fines. It just as often costs you the deal, since EU and increasingly US customers will not sign until you provide one.
Fines for the most serious breaches run up to 20 million euros or 4% of global annual turnover. Processor-related contract failures typically fall under the lower tier: up to 10 million euros or 2% of global annual turnover.
Beyond the regulatory exposure, missing a DPA is a common deal-breaker. The same Reddit thread that described the surprise DPA request confirmed the practical reality. A European customer is legally compelled to have this agreement with its vendors. A vendor that cannot produce one loses the deal, fine or no fine.
How Consently Supports Your DPA and Consent Compliance
As a processor of the consent data it collects on your behalf, Consently publishes its own customer-facing DPA and subprocessor list. It also gives you, the controller, the tooling to capture and prove lawful consent.
When you run Consently on your site, Consently acts as a processor for the consent data it handles. It publishes a DPA and a public subprocessors list you can review and rely on directly. That is one less contract you have to draft from scratch.
Alongside that DPA, Consently's consent logs give you timestamped, exportable audit records that evidence valid consent. Its automatic cookie scanning with auto-blocking stops trackers from firing before a visitor consents. Together, these form the "prove lawful processing" layer that sits next to your signed DPAs. Consently also hosts data in the EU, in Frankfurt, as an additional data-residency signal.
For the surrounding legal documents, Consently offers a cookie policy template plus privacy and terms generators. These cover the user-facing side of compliance that a DPA does not.
Start your free Consently trial and get a published DPA plus consent proof in one place.
FAQs
What does DPA stand for?
In privacy and business, DPA stands for data processing agreement, a GDPR Article 28 contract between a controller and a processor. The same acronym also covers unrelated meanings, including a Defense Production Act and a Durable Power of Attorney, but neither applies to this context.
Is a DPA legally required?
Yes. GDPR Article 28 requires a written DPA whenever a processor handles personal data on a controller's behalf. Several US state privacy laws, including CCPA/CPRA, impose similar controller-processor contract requirements.
Is a DPA the same as an NDA?
No. A DPA governs how personal data is processed and secured between a controller and a processor. An NDA protects confidential business information from disclosure and applies to any two contracting parties, not specifically to personal data.
Do you need a DPA in the US?
Yes, increasingly. GDPR applies if you process EU or UK residents' data, and a growing list of US state privacy laws impose their own contract requirements. Many US organizations, especially school systems, also demand a DPA contractually regardless of a specific legal trigger.
Who signs a data processing agreement?
Both parties sign: the data controller and the data processor. A website owner using third-party tools is usually the controller; the SaaS vendor supplying those tools is usually the processor.
What is the difference between a DPA and a privacy policy?
A DPA is a business-to-business contract governing how a processor handles data for a controller. A privacy policy is a public, user-facing document that tells your visitors what data you collect and why.
Does a DPA need to be signed?
Yes. GDPR Article 28 requires the contract to be in writing, including electronic form, so an e-signature satisfies the requirement.
What is a data processing addendum?
A data processing addendum is the same thing as a data processing agreement. Many vendors use "addendum" because the document is attached to an existing master service agreement rather than standing alone.
