A DPA (data processing agreement) is a contract between a data controller and a data processor that sets out how the processor may handle personal data on the controller's behalf. Under Article 28 of the EU GDPR, and the same article of the UK GDPR, a written contract with specific mandatory terms is required whenever a processor handles personal data for a controller. It is also called a data processing addendum, because it is usually attached to a main services agreement.

Is a DPA legally required?

Yes, whenever one organisation processes personal data on behalf of another under the EU or UK GDPR. Article 28(3) requires processing by a processor to be governed by a contract or other legal act that binds the processor and sets out specific terms, and Article 28(9) says it must be in writing, which includes electronic form. Missing or incomplete terms breach the obligations of both parties, and Article 83(4) allows fines of up to 10 million euros or 2 percent of worldwide annual turnover for breaches of these obligations.

What is the difference between a DPA and an NDA?

An NDA protects confidential business information such as pricing, plans, or trade secrets, and its content is almost entirely up to the parties. A DPA governs personal data about identifiable people, and much of its content is dictated by law: GDPR Article 28(3) lists terms it must contain, including processing only on documented instructions, security measures, sub-processor rules, assistance with data subject rights, and deletion or return at the end. An NDA does not satisfy Article 28, even if it mentions personal data.

What is the difference between a DPA and a BAA?

Both are data protection contracts between a customer and a service provider, but under different laws. A DPA is required by the EU and UK GDPR and covers any personal data. A BAA (business associate agreement) is required by the US HIPAA rules and covers only protected health information handled by a business associate of a covered entity such as a healthcare provider or health plan. A vendor serving European healthcare customers and US hospitals may need to sign both.

Who drafts the DPA, the customer or the vendor?

Either can, and in practice it follows bargaining power. Most SaaS vendors publish a standard DPA and expect customers to sign it, while large customers often insist on their own processor terms. Legally, the controller is responsible for ensuring the contract meets Article 28, so a customer that signs a vendor's DPA still needs to check it. The European Commission also published standard contractual clauses for controller to processor contracts in Implementing Decision 2021/915, which either side can use.

Does a DPA cover international data transfers?

Not by itself. Article 28 covers the controller and processor relationship, while transfers of personal data outside the EU or UK need a separate transfer mechanism, such as an adequacy decision, the EU standard contractual clauses under Decision 2021/914, or the UK IDTA or UK Addendum. Most vendor DPAs incorporate the transfer mechanism as an annex, so reviewing the DPA means reviewing that annex too.

What does DPA mean legally?

In contract and privacy law, DPA almost always means data processing agreement: the legally binding contract GDPR Article 28 requires between a controller and a processor. The same letters are also used for a data protection authority (the regulator the GDPR calls a supervisory authority) and, in criminal law, for a deferred prosecution agreement. In a vendor contract or a procurement checklist, it means the data processing agreement.

What is a DPA in healthcare?

In European healthcare, a DPA is the same GDPR Article 28 contract, used whenever a hospital, clinic or health app shares patient data with a processor such as a cloud, records or telehealth vendor. Health data is a special category under Article 9 GDPR, so the security annex deserves extra scrutiny. In US healthcare, the equivalent contract for protected health information is a HIPAA business associate agreement (BAA), covered in the comparison table in this guide.

What Is a DPA? Data Processing Agreements Explained

September 28, 202612 min read

What Is a Data Processing Agreement (DPA)? GDPR Article 28 Explained

What is a DPA?

A data processing agreement (DPA) is the legally binding contract between a data controller (the organisation that decides why and how personal data is processed) and a data processor (the organisation that processes that data on the controller's behalf). It sets the rules the processor must follow: what it may do with the data, how it keeps it secure, which subcontractors it may use, and what happens to the data when the contract ends. Under Article 28 of the EU GDPR, and the equivalent article of the UK GDPR, a DPA is not optional: any processing by a processor must be governed by a written contract containing a defined list of terms.

You will also see it called a data processing addendum, a data protection agreement, or simply "processor terms". They mean the same thing. In practice a DPA is usually an addendum to a main agreement, such as a SaaS subscription or a services contract, and it applies whenever that main agreement involves personal data: employee records in an HR tool, customer contacts in a CRM, or signatories' names and emails in a contract platform.

This guide explains what a DPA must contain, how it differs from an NDA and a US business associate agreement (BAA), what to push back on from each side of the table, and a review checklist you can use on the next vendor DPA that lands in your inbox.

DPA at a glance

Required by: Article 28 GDPR (EU and UK), whenever a processor handles personal data for a controller
Form: In writing, and electronic form counts (Article 28(9))
Mandatory contents: Listed in Article 28(3); missing terms are a compliance breach for both parties
Sub-processors: Need the controller's prior written authorisation (Article 28(2))
Transfers outside the EU or UK: Need a separate mechanism, usually annexed to the DPA

When is a DPA required, and when is it not?

Is a DPA mandatory?

Yes, whenever a processor handles personal data on behalf of a controller under the EU or UK GDPR: Article 28(3) requires the processing to be governed by a contract or other legal act, and Article 28(9) requires it in writing. It does not matter how small the vendor is or how little data is involved; a newsletter tool holding a list of email addresses needs one just as a payroll provider does.

A DPA is not the right document in three common situations:

Situation	Why Article 28 does not apply	What you need instead
The recipient decides for itself why and how it uses the data	It is an independent controller, not a processor	A data sharing agreement, or the main contract's data protection clause, setting out each side's duties
Two organisations jointly decide the purposes and means	They are joint controllers	An arrangement under Article 26 GDPR allocating responsibilities
No personal data is involved (for example, genuinely anonymous or purely company data)	The GDPR only covers personal data	Confidentiality terms or an NDA

Where the line between processor and controller sits is a question of fact, not labels, which is why the EDPB's Guidelines 07/2020 are worth reading before you decide a vendor does not need a DPA.

Do US privacy laws require a DPA?

Some do, under a different name. The California Consumer Privacy Act requires a business that discloses personal information to a service provider or contractor, or sells or shares it with a third party, to enter into an agreement that limits the use to specified purposes, obliges the recipient to comply with the Act and provide the same level of privacy protection, lets the business take steps to ensure compliant use and stop unauthorized use, and requires the recipient to say if it can no longer meet its obligations (Cal. Civ. Code § 1798.100(d)).

Controller vs processor: who is who?

Everything in a DPA follows from the two roles, which Article 4 of the GDPR defines. The controller determines the purposes and means of processing. The processor processes personal data on behalf of the controller. The European Data Protection Board's Guidelines 07/2020 on the concepts of controller and processor are the authoritative explanation of where the line sits.

Question	Controller	Processor
Who decides why the data is processed?	Yes	No, it follows the controller's instructions
Who decides the essential how (which data, how long, who gets access)?	Yes	Only non-essential technical choices
Typical example	A company using an HR platform for its employees	The HR platform vendor
Who must ensure a compliant DPA exists?	Both, but the controller must only use processors with sufficient guarantees (Article 28(1))	Both

The roles are about what an organisation actually does, not what the contract calls it. A vendor that uses customer data for its own purposes (for example, to train its own products) is acting as a controller for that purpose, and the DPA should either forbid it or deal with it openly. A company can also be a controller for some data and a processor for other data in the same relationship.

What a DPA must contain: the Article 28(3) checklist

Article 28(3) is the heart of every DPA. It requires the contract to describe the processing and then to impose eight specific obligations on the processor. If any of these is missing, the DPA is not compliant, regardless of how long or polished it is.

First, the description of the processing. The contract must set out the subject matter and duration of the processing, its nature and purpose, the types of personal data, the categories of data subjects, and the obligations and rights of the controller. Most DPAs put this in an annex, often called "Details of Processing".

Second, the eight processor obligations:

Article 28(3) point	The processor must	Look for in the draft
(a) Documented instructions	Process only on your documented instructions	No processing for the vendor's own purposes
(b) Confidentiality	Bind its people to confidentiality	Stated, not implied
(c) Security	Meet Article 32 security	A concrete security annex
(d) Sub-processors	Follow Article 28(2) and 28(4)	List, notice of changes, right to object
(e) Data subject rights	Help you answer requests	A defined process and who pays
(f) Compliance assistance	Help with Articles 32 to 36	Breach notice with an outer limit in hours
(g) End of contract	Delete or return the data	Your choice, a timeline, deletion certificate
(h) Audits and information	Show compliance, allow audits	Certifications first, on-site audits as backup

Instructions also cover international transfers, and the vendor may process beyond them only where law requires. Assistance under (f) spans security, breach notification, impact assessments and prior consultation; breach notice should come "without undue delay", ideally with a fixed limit. Under (g) storage continues only where law requires it.

Article 28(3) also requires the processor to immediately tell the controller if, in its opinion, an instruction infringes data protection law. That sentence is short and often missing from vendor templates.

The breach notification clock

Under Article 33 GDPR, the controller must notify the supervisory authority within 72 hours of becoming aware of a personal data breach, where feasible, and the processor must notify the controller "without undue delay". Because the controller's 72 hours can start when the processor tells it, customers commonly ask for a fixed processor deadline such as 24 or 48 hours, so the controller keeps enough of its own window.

Sub-processors and flow-down

Almost every vendor uses sub-processors: cloud hosting, email delivery, support tools, and increasingly AI model providers. Article 28(2) says a processor may not engage another processor without the controller's prior specific or general written authorisation. Under general authorisation, which is what most SaaS DPAs use, the processor must inform the controller of intended changes and give it the opportunity to object.

Article 28(4) adds two rules that matter in a negotiation. The same data protection obligations in the DPA must be imposed on each sub-processor by contract (the flow-down), and if a sub-processor fails, the original processor remains fully liable to the controller. A DPA that limits the vendor's responsibility for its sub-processors is contradicting the regulation, not negotiating a commercial point.

What a workable sub-processor clause looks like:

A current list of sub-processors, with what each does and where it processes data.
Advance notice of new sub-processors, commonly 30 days, through a channel you will actually see.
A right to object on reasonable data protection grounds, with a real remedy (for example, termination of the affected service with a refund of prepaid fees) if the objection cannot be resolved.
Flow-down of obligations "no less protective" than the DPA itself.

International transfers: the annex most people skip

A DPA governs the controller and processor relationship. It does not, on its own, make a transfer of personal data out of the EU or UK lawful. That needs a separate transfer mechanism under Chapter V of the GDPR, and most DPAs incorporate it as an annex.

Transfer	Common mechanism	Source
EU to a country with an adequacy decision	No extra contract needed for the transfer itself	European Commission adequacy decisions
EU to a US company certified under the Data Privacy Framework	Adequacy via the EU-U.S. Data Privacy Framework	Check the vendor's certification on the DPF list
EU to other third countries	EU standard contractual clauses (SCCs), with the right module (controller to processor is Module 2)	Commission Implementing Decision (EU) 2021/914
UK to third countries	The UK IDTA, or the UK Addendum to the EU SCCs	ICO guidance on the IDTA and the Addendum

Two points worth knowing in 2026. The Data Privacy Framework was upheld by the EU General Court in September 2025, and an appeal is pending before the Court of Justice, which invalidated both of its predecessors, as reported by IAPP and WilmerHale. Many customers therefore ask for SCCs as a fallback that applies automatically if the framework falls. And the ICO has said it will update the IDTA and the UK Addendum during 2026, with the current versions staying in use until then (ICO, January 2026).

Do not confuse the two sets of Commission clauses. Decision 2021/914 contains the SCCs for international transfers. Decision 2021/915 contains standard clauses for the controller and processor contract itself under Article 28(7), which some organisations use as their whole DPA.

DPA vs BAA vs NDA

These three are often mixed up because all of them "protect data". They protect different things under different rules.

	DPA	BAA	NDA
Protects	Personal data about identifiable people	Protected health information (PHI)	Confidential business information
Required by	EU GDPR and UK GDPR, Article 28	US HIPAA Privacy and Security Rules	Nothing, it is voluntary
Parties	Controller and processor	Covered entity (or business associate) and business associate	Any parties sharing confidential information
Content fixed by law?	Largely, Article 28(3) lists mandatory terms	Largely, HHS lists required provisions	No, freely negotiated
Official model	SCCs under Decision 2021/915	HHS sample business associate provisions	None

An NDA never replaces a DPA. Even an NDA that mentions personal data lacks the Article 28(3) obligations. And a BAA does not replace a DPA either: a US health tech vendor serving European customers typically signs both, because each law asks for its own terms. If NDAs are a big part of your contract volume, our guide to automating NDAs covers how to take them off legal's desk.

What to push back on

The same DPA reads very differently depending on which side you are on. Here are the points that come up most often.

If you are the customer (controller):

Vague security. "Industry standard measures" is not an Article 32 commitment. Ask for the security annex, and accept current certifications (such as ISO 27001 or a SOC 2 report) as evidence where they cover the service you are buying.
Open-ended breach notification. "Without undue delay" is the legal floor. Ask for a fixed outer limit so your own 72-hour clock is protected.
Use of your data for the vendor's own purposes. Product improvement, analytics, or AI model training on your personal data turns the vendor into a controller for that purpose. If you do not want it, say so explicitly.
Sub-processor changes by website update only. Ask for notice to a named contact and a real right to object.
DPA liability inside a low general cap. Data protection breaches are often carved out of, or given a higher, liability cap. See our guide on limitation of liability clauses for the usual positions.

If you are the vendor (processor):

Unlimited on-site audits. Offer certifications and audit reports first, with on-site audits limited to once a year, on reasonable notice, at the customer's cost, unless there is a breach or a regulator requires it.
Customer-drafted DPAs that conflict with your platform. A bespoke DPA per customer is impossible to operate. Push for your standard DPA, with a short side letter for true exceptions.
Uncapped indemnities for any data protection issue. Tie any indemnity to your own breach of the DPA or of the law, as covered in our indemnification clause guide.
Deletion deadlines that ignore backups. Agree a timeline that reflects backup rotation, with the data kept secure until overwritten.

A DPA review checklist

Use this list on any incoming DPA. Each line maps to the regulation or to a common negotiation point.

Confirm the roles: are we controller, processor, or both?
Check the processing details annex is complete
Tick off all eight Article 28(3) obligations
Read the security annex, not just the promise
Check sub-processor list, notice, and objection right
Check breach notification timing
Check the transfer mechanism annex matches where data goes
Check deletion or return at the end, with certification
Check audit rights and who pays
Check liability and indemnity for data protection breaches

A worked example: a sales team wants to buy a call-recording tool that stores customer contacts and recordings. You are the controller, the vendor is the processor. The vendor's DPA covers points (a) to (h), but its security section says only "appropriate measures", breach notice is "without undue delay", the sub-processor list is on a web page with no notification, and the transfer annex relies only on the Data Privacy Framework. A reasonable response: ask for the security annex and the vendor's ISO 27001 certificate, a 48-hour breach notice limit, email notice of new sub-processors with a right to object, and the Module 2 SCCs as an automatic fallback. None of these are unusual asks, and most vendors will accept them.

Not legal advice

This guide is general information about the EU and UK GDPR and common negotiation positions. It is not legal advice and not a substitute for counsel reviewing your specific agreement, processing, and governing law. Bind is not a law firm.

How to do this in Bind

Here is how the review in the worked example above runs in Bind, from the vendor's DPA arriving to a signed copy in the right space.

1/review in the chat2Review plan: decide on each issue3Review your decisions and Submit4Tracked changes with comments

Step by step, with the names you will see in Bind:

Open the DPA. Upload the vendor's Word or PDF file and open it next to the chat. If the DPA refers to the main services agreement, attach that too; you can attach up to 20 files to one chat message.
Type /review and say what matters, for example "We are the controller. Focus on breach notification and sub-processors." Bind works out which party you are from the contract and asks if it cannot tell.
Choose your playbook. Bind asks which of your matching templates and playbooks to check against, or reviews against general market practice if none match.
Work through the review plan. Each issue shows the problem, where it is, a suggestion with a Severity, and Show reasoning. In this example that would include the vague security wording, the open-ended breach notification period and the missing sub-processor notice. Accept a suggestion or type your own in Something else, then Submit.
Send the tracked changes. Bind edits the DPA itself: every change is a tracked change with a comment written for the vendor, and the comments never reveal your playbook positions. Run /check for drafting slips before it goes out.
Negotiate the rounds. Choose Actions → Start negotiation. When the vendor's reply comes back, click Upload their redline; Bind reads their changes, including any made without tracked changes, and prepares your response in a new review plan.
Sign and file. Choose Mark as final, then Actions → Send for signature. The signed PDF stays with the DPA in its space, where fields such as counterparty and end date can be filled by AI autofill.

Bind itself is ISO 27001 certified, SOC 2 Type I compliant, and GDPR compliant. It is used by in-house legal teams at companies including Atria, listed on Nasdaq Helsinki, and Outdoor Holding, listed on Nasdaq in the US.

Ready to simplify your contracts?

See how Bind helps teams manage contracts from draft to signature in one platform.

Get a demo

Frequently asked questions

What is a DPA?: A DPA (data processing agreement) is a contract between a data controller and a data processor that sets out how the processor may handle personal data on the controller's behalf. Under Article 28 of the EU GDPR, and the same article of the UK GDPR, a written contract with specific mandatory terms is required whenever a processor handles personal data for a controller. It is also called a data processing addendum, because it is usually attached to a main services agreement.
Is a DPA legally required?: Yes, whenever one organisation processes personal data on behalf of another under the EU or UK GDPR. Article 28(3) requires processing by a processor to be governed by a contract or other legal act that binds the processor and sets out specific terms, and Article 28(9) says it must be in writing, which includes electronic form. Missing or incomplete terms breach the obligations of both parties, and Article 83(4) allows fines of up to 10 million euros or 2 percent of worldwide annual turnover for breaches of these obligations.
What is the difference between a DPA and an NDA?: An NDA protects confidential business information such as pricing, plans, or trade secrets, and its content is almost entirely up to the parties. A DPA governs personal data about identifiable people, and much of its content is dictated by law: GDPR Article 28(3) lists terms it must contain, including processing only on documented instructions, security measures, sub-processor rules, assistance with data subject rights, and deletion or return at the end. An NDA does not satisfy Article 28, even if it mentions personal data.
What is the difference between a DPA and a BAA?: Both are data protection contracts between a customer and a service provider, but under different laws. A DPA is required by the EU and UK GDPR and covers any personal data. A BAA (business associate agreement) is required by the US HIPAA rules and covers only protected health information handled by a business associate of a covered entity such as a healthcare provider or health plan. A vendor serving European healthcare customers and US hospitals may need to sign both.
Who drafts the DPA, the customer or the vendor?: Either can, and in practice it follows bargaining power. Most SaaS vendors publish a standard DPA and expect customers to sign it, while large customers often insist on their own processor terms. Legally, the controller is responsible for ensuring the contract meets Article 28, so a customer that signs a vendor's DPA still needs to check it. The European Commission also published standard contractual clauses for controller to processor contracts in Implementing Decision 2021/915, which either side can use.
Does a DPA cover international data transfers?: Not by itself. Article 28 covers the controller and processor relationship, while transfers of personal data outside the EU or UK need a separate transfer mechanism, such as an adequacy decision, the EU standard contractual clauses under Decision 2021/914, or the UK IDTA or UK Addendum. Most vendor DPAs incorporate the transfer mechanism as an annex, so reviewing the DPA means reviewing that annex too.
What does DPA mean legally?: In contract and privacy law, DPA almost always means data processing agreement: the legally binding contract GDPR Article 28 requires between a controller and a processor. The same letters are also used for a data protection authority (the regulator the GDPR calls a supervisory authority) and, in criminal law, for a deferred prosecution agreement. In a vendor contract or a procurement checklist, it means the data processing agreement.
What is a DPA in healthcare?: In European healthcare, a DPA is the same GDPR Article 28 contract, used whenever a hospital, clinic or health app shares patient data with a processor such as a cloud, records or telehealth vendor. Health data is a special category under Article 9 GDPR, so the security annex deserves extra scrutiny. In US healthcare, the equivalent contract for protected health information is a HIPAA business associate agreement (BAA), covered in the comparison table in this guide.

Bind is trusted by legal teams across Europe and the US