Skip to main content
GeraCompliance/Guides/Data Processing Agreement
GDPR

GDPR Data Processing Agreement (DPA): What It Must Contain

Last updated June 2026 · 8 min read

Quick Answer

A Data Processing Agreement (DPA) is the Article 28 GDPR contract you must put in place whenever a vendor processes personal data on your behalf — your cloud host, email tool, CRM, payroll provider, and so on. It must bind the processor to act only on your documented instructions, keep data secure, manage sub-processors, assist with data subject requests and breaches, and delete or return data at the end. Without a compliant DPA, both controller and processor are exposed to enforcement.

Why a DPA Is Not Optional

Article 28 GDPR is blunt: where processing is carried out on behalf of a controller, it must be governed by a contract. This is not a best-practice nicety — it is a legal requirement, and operating without one is itself a breach, independent of whether any data is ever mishandled. Every business uses processors, often dozens of them, so DPAs are one of the most common GDPR obligations and one of the most commonly neglected.

Controller, Processor — Get the Roles Right First

Before you can paper a relationship, you must classify it. A controller decides why and how personal data is processed. A processor acts only on the controller's instructions. You are the controller of your own customer and staff data; a SaaS vendor handling that data for you is your processor. The wrinkle is that the same organisation can wear both hats: your analytics provider is your processor for your visitors' data, but a controller for its own account-administration data. Two independent controllers sharing data for their own purposes do not need an Article 28 DPA — they need a different analysis. Misclassifying the relationship leads to the wrong contract entirely.

The Mandatory Article 28 Clauses

A compliant DPA must bind the processor to all of the following:

  • Documented instructions only. Process personal data solely on the controller's documented instructions, including for international transfers.
  • Confidentiality. Ensure everyone authorised to process the data is bound by confidentiality.
  • Security. Implement appropriate technical and organisational measures under Article 32.
  • Sub-processors. Engage sub-processors only with authorisation and flow down equivalent obligations.
  • Data subject rights. Assist the controller in responding to access, erasure, and other data subject requests.
  • Security and breach assistance. Help the controller meet its Article 32–36 duties, including breach notification and DPIAs.
  • Deletion or return. At the end of the engagement, delete or return all personal data at the controller's choice.
  • Audit and information. Make available the information needed to demonstrate compliance and allow audits or inspections.

Handling Sub-Processors

Almost no processor works alone — your CRM uses a cloud host, which uses a CDN, and so on. Article 28 lets a processor use sub-processors only with the controller's prior written authorisation (specific or general), and the processor must impose the same data protection obligations on each sub-processor by contract. Critically, the original processor stays fully liable to you if a sub-processor fails. Strong DPAs publish a current sub-processor list and give you advance notice and a right to object before new ones are added.

Don't Forget International Transfers

A DPA documents the relationship, but it is not, by itself, a lawful basis for sending personal data outside the EU or UK. If your processor or any sub-processor stores or accesses data internationally, you also need a transfer mechanism — most often the EU Standard Contractual Clauses, plus the UK International Data Transfer Addendum or IDTA for UK data, supported by a transfer risk assessment. See our GDPR vs UK GDPR guide for the post-Brexit transfer differences.

A Practical Approach for Businesses

Build a vendor register listing every processor that touches personal data, note whether a DPA is in place, and chase the gaps. Most large vendors offer a standard DPA you can accept; for smaller suppliers, send your own. Review the sub-processor lists annually. This work pairs naturally with the data inventory in our GDPR for small business guide.

GeraCompliance provides a ready-to-use, Article 28-complete DPA template along with the rest of the GDPR document set. For a full programme delivered fast, the GDPR sprint produces your DPAs and supporting documents in days.

Frequently Asked Questions

What is a Data Processing Agreement (DPA) under GDPR?

A Data Processing Agreement is a legally binding contract required by Article 28 GDPR whenever a controller engages a processor to handle personal data on its behalf. It sets out the subject matter, duration, nature and purpose of the processing, the types of data and categories of data subjects, and the rights and obligations of both parties — ensuring the processor only acts on the controller's documented instructions.

When do you need a DPA?

You need a DPA whenever one organisation (the processor) processes personal data on behalf of another (the controller). Common examples include using a cloud host, an email marketing platform, a payroll provider, a CRM, an analytics tool, or an outsourced support service. If a vendor only sees personal data as an independent controller, a DPA in the Article 28 sense is not required, but the relationship still needs to be analysed.

What clauses must a GDPR DPA contain?

Article 28(3) requires the processor to: process only on documented instructions; ensure persons authorised to process are under confidentiality; implement Article 32 security measures; respect conditions for engaging sub-processors; assist the controller with data subject requests; assist with security, breach notification, and DPIAs; delete or return data at the end of the contract; and make available information to demonstrate compliance and allow audits.

What is the difference between a controller and a processor?

A controller determines the purposes and means of processing personal data — the "why" and "how". A processor processes personal data only on behalf of, and on the instructions of, the controller. A company is usually a controller for its own customer and employee data, and acts as a processor when it handles another organisation's data as a service. The same company can be a controller for some processing and a processor for other processing.

Do sub-processors need to be covered in a DPA?

Yes. A processor may only engage a sub-processor with the controller's prior specific or general written authorisation, and must impose the same data protection obligations on the sub-processor by contract. If the sub-processor fails, the original processor remains fully liable to the controller. Good DPAs include a sub-processor list and a mechanism for notifying and objecting to changes.

Does a DPA cover international data transfers?

A DPA should address transfers, but the transfer mechanism itself is separate. If the processor or a sub-processor moves personal data outside the EU/UK, you also need a valid transfer tool — typically Standard Contractual Clauses (and the UK Addendum/IDTA for UK data), plus a transfer risk assessment. The DPA documents the arrangement; the SCCs provide the lawful transfer basis.

Get an Article 28-ready DPA

Use our free DPA template, or let the GDPR sprint deliver your full vendor-contract set in days.

Related Guides & Tools