GDPR Data Processing Agreement (DPA): Guide + Template

What a DPA is

A Data Processing Agreement (DPA) is the contract that must exist whenever a controller uses a processor to handle personal data on its behalf. Required by Article 28, it sets out what the processor may and must do with the data, and it is mandatory — using a processor without one is itself a breach of GDPR.

If you use cloud hosting, SaaS tools, payroll bureaus, email platforms or analytics providers, you almost certainly need DPAs in place with each of them.

Why it is legally required

Article 28 says processing by a processor must be governed by a written contract that binds the processor to the controller and sets out specific terms. The point is to ensure that data handed to a third party is still protected to the GDPR standard, with responsibilities clearly allocated.

Because it is a legal requirement, the absence of a DPA is one of the easiest compliance gaps for a regulator to identify — and one of the easiest to fix.

The mandatory contents

A DPA must set out the subject matter and duration of the processing, its nature and purpose, the types of personal data and categories of data subjects, and the obligations and rights of the controller. These details frame exactly what the processor is engaged to do.

Vague, boilerplate descriptions are a common weakness — the specifics matter, because they define the limits of what the processor may lawfully do.

Process only on documented instructions

The cornerstone obligation is that the processor will process personal data only on the controller’s documented instructions. The processor cannot use the data for its own purposes; if it does, it becomes a controller for that use and takes on far greater responsibility.

This single clause is what keeps the processor in its lane and the controller in charge of the data.

Confidentiality and security

The DPA must require the processor to ensure that people authorised to process the data are under a duty of confidentiality, and to implement appropriate security measures in line with Article 32 — encryption, access controls and the rest, proportionate to the risk.

These obligations extend the controller’s own security expectations into the processor’s environment.

Sub-processor rules

A processor must not engage another processor (a sub-processor) without the controller’s authorisation, and must flow the same data protection obligations down to any sub-processor it uses. The DPA sets out how this authorisation works — specific or general, with notice of changes.

Because most modern services rely on sub-processors (cloud infrastructure, support tools), this is one of the most practically important parts of the agreement.

Assisting the controller

The DPA must require the processor to assist the controller in meeting its own obligations: helping respond to data subject rights requests, supporting security and breach-notification duties, and assisting with DPIAs and prior consultations where relevant.

This is what makes the processor a genuine partner in compliance rather than a passive recipient of data.

Breach notification

Crucially, the processor must notify the controller of a personal data breach without undue delay. This is what allows the controller to meet its own 72-hour deadline to the regulator, so the timing expectation should be explicit and tight.

A slow processor notification can blow the controller’s deadline, so this clause deserves careful attention.

Return or deletion at the end

At the end of the engagement, the processor must delete or return all the personal data, and delete existing copies, unless law requires retention. The DPA should specify which option applies and how it will be evidenced.

This prevents data lingering with former vendors — a frequently overlooked source of risk.

Audits and demonstrating compliance

The processor must make available the information needed to demonstrate compliance with Article 28 and allow for, and contribute to, audits and inspections by the controller or an appointed auditor. In practice this is often satisfied through certifications and audit reports.

This gives the controller a right to verify, rather than simply trust, that the processor is doing what it agreed to.

Who provides the DPA?

Either party can provide the DPA, but in practice large processors (cloud and SaaS providers) usually offer their own standard DPA, which controllers accept or negotiate. The European Commission and some authorities have also published standard contractual clauses for controller-processor relationships that can be used as a ready-made template.

Whoever drafts it, the controller is responsible for ensuring the DPA meets Article 28 — so review vendor DPAs rather than signing blindly.

DPA vs controller-to-controller agreement

Be careful to use the right contract. A DPA governs a controller-processor relationship. Where you share data with another organisation that uses it for its own purposes, that is a controller-to-controller transfer needing a different agreement, not a DPA.

Using the wrong type of contract misallocates responsibilities, so confirm the relationship before papering it.

Getting DPAs in place

Practically: inventory every vendor that processes personal data for you, check whether a compliant DPA exists, and put one in place where it doesn’t. Review vendor-provided DPAs against Article 28, and keep copies as part of your records. Make a DPA a standard step in onboarding any new processor.

This turns DPAs from a scramble into a routine part of procurement.

How ISpectra helps

Putting compliant DPAs in place with every processor is a foundational, and frequently incomplete, part of GDPR compliance. ISpectra Technologies helps organisations inventory their processors, review and negotiate vendor DPAs against Article 28, provide template agreements, and build DPA checks into onboarding.

If you are unsure whether your vendor contracts meet the requirement, a short review will tell you where the gaps are.

In one paragraph

A Data Processing Agreement is the mandatory Article 28 contract between a controller and a processor. It must describe the processing and require the processor to: act only on documented instructions; ensure confidentiality and Article 32 security; use sub-processors only with authorisation; assist with rights, security, breaches and DPIAs; notify breaches without undue delay; delete or return data at the end; and support audits. Either party can provide it — large vendors usually offer their own — but the controller must ensure it meets Article 28. Inventory every processor, put a compliant DPA in place with each, and make it a standard step when onboarding new vendors.

A practical onboarding habit

The organisations that handle DPAs well treat them as part of vendor onboarding, not a separate legal chore. The moment a new tool is being considered — before any real data flows into it — someone checks: does this vendor process personal data on our behalf? If yes, is there a DPA, does it meet Article 28, and what sub-processors and transfers does it involve? Making this a checkbox in procurement stops gaps appearing in the first place.

It also pays to keep a simple register of your processors alongside their DPAs, the data they handle, and where that data is hosted. This register feeds your Record of Processing Activities, supports your transfer assessments, and means that when a regulator, customer or auditor asks “who are your sub-processors and how is the data protected?”, you can answer in minutes rather than scrambling through inboxes. A little discipline at onboarding saves a great deal of effort later, and turns DPAs from a recurring fire drill into a quiet, well-documented routine.