What Is a DPA? Data Processing Agreements Explained

Updated: September 2026

A Data Processing Agreement (DPA) is a written contract between a data controller and a data processor. Article 28 of the GDPR requires one whenever one organisation processes personal data on behalf of another.

If your company uses a cloud host, an email marketing platform, a payroll provider, or a CRM, each supplier processes your personal data. You need a DPA in place with each one.

This guide covers what a DPA is, who needs one, the eight clauses Article 28 makes mandatory, and what to check before you sign.

Key Takeaways

• A Data Processing Agreement is legally required under GDPR Article 28 whenever a controller hands personal data to a processor. It has to be in writing, including in electronic form.

• Article 28(3) sets out specific content the contract must cover, including documented instructions, confidentiality, security measures, sub-processor rules, deletion or return of data, and audit rights. A supplier contract that skips these is not a compliant DPA.

• Missing or inadequate DPAs carry fines of up to €10 million or 2% of global annual turnover. In 2022, the French regulator fined software company Dedalus Biologie €1.5 million, partly for failing to have Article 28-compliant contracts with its clients.

What Is a Data Processing Agreement?

A Data Processing Agreement (DPA) is a legally binding contract between a controller and a processor that governs how the processor handles personal data on the controller’s behalf.

It sets out the scope of the processing, the purpose, and what the processor can and cannot do with the data. GDPR requires it to be in writing, which includes electronic form.

You will also see it called a data processing addendum, a data protection agreement, or an Article 28 agreement. Most suppliers attach it to their main service contract as a separate schedule rather than negotiating it line by line.

Who Is the Controller and Who Is the Processor?

The controller decides why and how personal data is processed. The processor handles that data on the controller’s instructions and does not decide the purpose itself.

Getting the roles right matters, because the DPA obligations flow from them.

Role	Decides	Typical example
Controller	Why the data is collected and how it is used	A retailer collecting customer addresses to fulfil orders
Processor	Nothing about purpose; acts on instructions	The cloud provider storing those addresses
Joint controllers	Purpose and means decided together	Two companies running a shared marketing campaign

One warning from Article 28(10): if a processor starts deciding the purposes and means of processing on its own, it is treated as a controller for that processing and takes on full controller liability.

When Do You Need a DPA?

You need a DPA any time personal data leaves your organisation for a third party to process on your behalf. In practice, that covers most of the software your business runs on:

• Cloud storage and hosting providers

• Email and marketing platforms

• CRM and helpdesk software

• Payroll and HR systems

• Website analytics tools

• Outsourced IT support, accountants, and recruiters

Two situations do not need one. If you share data with another organisation that decides its own purposes, that is a controller-to-controller relationship, which needs a different kind of agreement. And if data never leaves your organisation, Article 28 does not apply.

What Must a DPA Include Under Article 28?

Article 28(3) sets a floor. Anything below it is not a valid DPA, regardless of what the supplier calls the document.

What details must the contract describe?

Every DPA has to set out:

• The subject matter and duration of the processing

• The nature and purpose of the processing

• The type of personal data involved

• The categories of data subjects

• The obligations and rights of the controller

What eight commitments must the processor make?

The contract also has to bind the processor to each of the following:

1. Process only on documented instructions. The processor acts on the controller’s written instructions, including for any transfer of data outside the EU. If a law forces the processor to act otherwise, it has to tell the controller first, unless that law prohibits it on public interest grounds.

2. Keep staff under confidentiality. Anyone authorised to touch the data must be bound by confidentiality, either contractually or by statute.

3. Apply Article 32 security measures. The processor takes the technical and organisational security steps required by Article 32, such as encryption, access controls, and resilience testing.

4. Follow the rules on sub-processors. No sub-processor without the controller’s prior written authorisation, either specific or general. Where the authorisation is general, the processor must tell the controller about any new or replacement sub-processor and give it a chance to object.

5. Assist with data subject rights. The processor helps the controller respond to access, erasure, rectification, and other rights requests, using appropriate technical and organisational measures.

6. Assist with security and breach obligations. The processor helps the controller meet its duties under Articles 32 to 36, covering security, breach notification, data protection impact assessments, and prior consultation with the regulator.

7. Delete or return the data at the end. When the service ends, the processor deletes or returns all personal data at the controller’s choice, and deletes existing copies, unless law requires it to keep them.

8. Allow audits and provide evidence. The processor makes available whatever information the controller needs to demonstrate Article 28 compliance, and allows for audits and inspections by the controller or an auditor it appoints.

Article 28 adds one more duty on top of the eight: if the processor believes an instruction from the controller breaches the GDPR, it must say so immediately.

Do Processors Need a DPA With Their Sub-Processors?

Yes. Article 28(4) requires the processor to impose the same data protection obligations on any sub-processor it engages through its own contract.

The key point is liability. If the sub-processor fails to meet those obligations, the original processor stays fully liable to the controller for that failure. Responsibility travels down the chain without leaving the parties above it.

For a controller, this means asking any supplier two questions: who are your sub-processors, and can I see the terms you have with them?

What Happens If You Don’t Have a DPA?

Breaching Article 28 sits in the GDPR’s lower fine tier under Article 83(4): up to €10 million or 2% of global annual turnover, whichever is higher. The absence of a written agreement is a breach in itself, whether or not anyone was harmed.

Regulators do enforce this. In April 2022, France’s CNIL fined Dedalus Biologie €1.5 million, citing breaches of Articles 28(3), 29, and 32 after a breach exposed the health data of around 500,000 people. Its contracts with laboratory clients did not contain the obligations Article 28 requires.

That decision carried a warning for suppliers. Dedalus argued the duty to put a DPA in place sat with its clients as controllers. The CNIL disagreed and held the processor responsible. Both sides of the relationship carry the obligation.

Beyond the fine, a controller remains accountable for a breach that happens at its processor. Choosing suppliers that can actually meet Article 32 standards is part of the controller’s own compliance position.

What Should You Check Before Signing a DPA?

Most DPAs arrive as a supplier template. A few clauses are worth reading closely before you accept it.

Scope of processing. Check that the processor is not permitted to use your data for its own purposes, such as product improvement or model training. The scope of the DPA should not be wider than the lawful basis you have for the data in the first place.

Security commitments. Look for specific measures rather than a general promise to keep data safe. Look for encryption at rest and in transit, access controls, and independent certifications like ISO 27001.

Breach notification timing. Article 33 gives you 72 hours to notify your regulator. A DPA that lets the processor take “reasonable” time to tell you leaves you exposed. Ask for a defined window, ideally 24 to 48 hours.

Sub-processor list and objection rights. You should be able to see the current list and receive notice of changes with a real opportunity to object.

Deletion and return. Confirm what happens at termination, how long deletion takes, and whether backups are included.

International transfers. If the processor moves data outside the EU or UK, check which mechanism covers it, usually Standard Contractual Clauses plus a transfer risk assessment.

Audit rights. Some suppliers replace audits with an annual certification report. That can be acceptable, but you should know which you are getting.

How Is a DPA Different From an NDA or SCCs?

These three documents get confused, and they do different jobs.

Document	What it does	When you need it
DPA	Governs how a processor handles personal data for a controller	Any controller-to-processor relationship under GDPR
NDA	Protects confidential business information from disclosure	Commercial discussions, regardless of personal data
SCCs	Provides a legal safeguard for transfers outside the EU or UK	When personal data leaves the EEA to a country without an adequacy decision

They often sit together. A supplier relationship involving an overseas cloud provider can need all three. For a closer comparison of the first two, see our guide on NDA vs DPA.

Does the EU Digital Omnibus Change DPA Requirements?

No. The European Commission published its Digital Omnibus proposal on 19 November 2025, proposing targeted GDPR amendments covering areas such as the definition of personal data, breach notification timing, DPIA lists, and cookie rules.

Article 28 is not among the articles it proposes to change, and the package is still a proposal working through the European Parliament and Council. Current DPA obligations apply in full.

Conclusion

A DPA records who is responsible for what when personal data passes between two organisations. The GDPR makes it mandatory, sets out exactly what it must contain, and lets regulators fine either party for getting it wrong.

The practical work usually comes down to knowing which suppliers process personal data for you, and whether the agreements already in place actually meet the Article 28 standard. For most companies, that starts with a supplier inventory.

If you need help reviewing your processor contracts or building that inventory, our data protection consultants can help.

Frequently Asked Questions

Is a DPA legally required under GDPR?

Yes. Article 28(3) requires a written contract between the controller and processor whenever personal data is processed on the controller’s behalf. Electronic form counts as writing.

Who is responsible for putting the DPA in place, the controller or the processor?

Both. The European Data Protection Board’s guidance says both parties are responsible for making sure a contract exists, and regulators can fine either one. 

Do I need a DPA with Google, AWS, or Microsoft?

Yes. When you store or process personal data in a third-party cloud service, that provider is your processor. The major providers publish standard DPAs that you accept as part of their terms, so the work is checking the terms rather than negotiating a document from scratch.

What is the difference between a DPA and a data sharing agreement?

A DPA governs a controller-to-processor relationship, where one party acts on the other’s instructions. A data sharing agreement covers controller-to-controller arrangements, where each party decides its own purposes for the data.

What are the penalties for not having a DPA?

Up to €10 million or 2% of global annual turnover, whichever is higher, under Article 83(4). The actual amount depends on the factors listed in Article 83(2), including the gravity and duration of the infringement, the number of people affected, and the degree of cooperation with the regulator. In the Dedalus case, the CNIL imposed €1.5 million.

Disclaimer: This blog post is for informational purposes only. It does not offer legal advice or opinions. This article is not a guide for resolving legal issues or managing litigation on your own. It should not be considered a replacement for professional legal counsel and does not provide legal advice for any specific situation or employer.