A Data Processing Agreement is one of the most common — and most misunderstood — elements of GDPR. Most organisations know they “should have one”. But far fewer understand when it is actually required, what it must contain, and how it differs from simply accepting a vendor’s terms of service.
The starting point is a question every controller needs to answer: when you share personal data with an external party, who determines the purpose and means of the processing? If the answer is you — the external party is acting on your instructions — then you need a Data Processing Agreement. If they determine the purpose themselves, they are a separate controller, and a DPA is not required.
Getting this distinction wrong creates real compliance risk. A DPA signed where none is needed is a minor inefficiency. The absence of a DPA where one is required is a breach of Article 28 GDPR.
Controller vs processor — the key distinction
Before deciding whether a DPA is needed, the relationship between the parties must be correctly classified.
A data controller determines the purposes and means of processing personal data. The controller bears full responsibility for lawful processing and must be able to demonstrate compliance.
A data processor processes personal data on behalf of the controller — acting only on the controller’s documented instructions, and not determining the purpose of processing independently.
The practical test: does the external party decide why the data is being processed, or only how to carry out the processing task you have given them?
A payroll software provider that processes employee salary data strictly according to your instructions is a processor. A law firm that receives client data to provide independent legal advice is a separate controller — it determines its own purposes and means of processing. The same logic applies to an accountant acting as an independent professional versus a bookkeeping service that processes your data in a system you control.
A misclassification — treating an independent controller as a processor, or vice versa — leads to incorrect compliance measures on both sides.
When a DPA is required
A Data Processing Agreement is required whenever a controller transfers personal data to a processor — an external party that processes data on its behalf. In practice, this covers a wide range of everyday business relationships.
Hosting and cloud infrastructure — the provider stores data on servers it manages. The controller determines what data is stored and why; the provider carries out the technical processing.
CRM and SaaS platforms — Salesforce, HubSpot, Pipedrive and similar tools process customer data on the controller’s behalf. A DPA is required regardless of where the vendor is based.
Email marketing platforms — Mailchimp, Klaviyo and similar services process subscriber data on the controller’s instructions. One of the most commonly missing DPAs in practice.
Payroll and HR software — processes employee personal data on the employer’s behalf, including sensitive financial information.
Accounting and bookkeeping services — where the accountant is processing your data in your system or to your instructions, rather than acting as an independent professional.
IT support and managed services — where the provider has access to systems containing personal data, even if that access is incidental to their main service.
Marketing and advertising agencies — where the agency processes customer or prospect data on the controller’s behalf to run campaigns.
When a DPA is not required
Not every external transfer of personal data requires a DPA. The agreement is not needed when:
The third party is an independent controller — it determines its own purposes and means of processing. Examples: a bank processing payments under its own legal obligations, a postal service handling deliveries, a supervisory authority, a court.
The parties are joint controllers — where two or more organisations jointly determine the purposes and means of processing. This relationship requires a joint controller arrangement under Article 26 GDPR rather than a DPA.
The transfer is to a recipient acting in a professional capacity under their own obligations — such as an independent lawyer or auditor acting under professional secrecy rules.
What a DPA must contain — Article 28 GDPR requirements
Article 28 GDPR specifies the mandatory elements of a data processing agreement. The agreement must set out:
Subject matter and duration — what personal data is covered and for how long the processor will have access to it.
Nature and purpose of processing — what type of processing is being carried out and for what purpose.
Type of personal data and categories of data subjects — what categories of data are involved (contact data, financial data, health data) and whose data is being processed (customers, employees, applicants).
Obligations and rights of the controller — including the right to audit and inspect the processor’s compliance.
The agreement must also oblige the processor to:
- process personal data only on documented instructions from the controller,
- ensure that authorised persons are subject to confidentiality obligations,
- implement appropriate technical and organisational security measures,
- assist the controller in responding to data subject requests,
- delete or return all personal data at the end of the contract,
- make available all information necessary to demonstrate compliance,
- inform the controller before engaging any sub-processors.
Sub-processors — further transfers down the chain
A processor may engage sub-processors — other organisations that carry out specific processing activities on behalf of the processor. This requires the controller’s prior authorisation.
Authorisation may be general (the controller agrees to sub-processors being used, with the right to be informed of any changes) or specific (the controller approves named sub-processors). Most large SaaS vendors operate under general authorisation, publishing a list of current sub-processors on their website.
Controllers should review sub-processor lists — particularly where sub-processors are located outside the EEA, as international transfers require additional safeguards.
DPA in practice — common mistakes
Missing DPAs with SaaS providers. Clicking “I accept the terms of service” is not a DPA. Many SaaS providers offer a separate DPA on request, or include it as part of their data protection addendum. Controllers need to actively seek and sign these.
No register of processors. A controller may have dozens of processors — different software tools, agencies, service providers. Without a central register, it is impossible to verify whether DPAs are in place, current and covering the right data.
DPA signed but not updated. A DPA drafted at the time of initial engagement may no longer reflect the current scope of processing. Changes in the service, new sub-processors or new data categories may require the DPA to be updated.
Processor acting as controller. Where a processor starts making its own decisions about how to use the data — for example, using it for its own analytics or marketing — the relationship has shifted. The DPA no longer covers that processing, and the processor may have become an unauthorised controller.
Managing DPAs in iGDPR
iGDPR includes a dedicated processor management module that allows you to maintain a central register of all data processing agreements, link each agreement to the relevant processing activities in your record of processing activities, track the validity and scope of each DPA, and manage sub-processor information. The system flags missing or expiring agreements and allows you to store signed copies — so your processor register is always audit-ready.
Summary
A Data Processing Agreement is required whenever personal data is shared with an external party that processes it on your behalf and under your instructions. Its absence is a breach of Article 28 GDPR. Its presence, however, is not enough — the agreement must cover all mandatory elements, reflect the actual scope of processing, and be kept current as the relationship evolves.
Key principles:
- a DPA is required for every processor relationship, not just large or “official” vendors,
- the controller–processor distinction must be correctly identified before signing,
- the agreement must contain all elements specified in Article 28 GDPR,
- sub-processors require the controller’s prior authorisation,
- a central register of processors and DPAs supports accountability and audit readiness.
Frequently asked questions about data processing agreements
Only those that process personal data on your behalf — which includes most cloud-based tools. Providers that only sell you a licence but have no access to your data do not require a DPA. Where in doubt, check whether the provider has access to personal data you have input into their system.
Not unless the terms of service contain all the elements required by Article 28 GDPR. Many larger providers offer a separate Data Processing Addendum (DPA) alongside their standard terms — this is what you need to sign or accept.
Processing personal data through a processor without a DPA is a breach of Article 28 GDPR and can result in an administrative fine from the supervisory authority. It also means the controller has no contractual basis for holding the processor to GDPR obligations.
No — sub-processors require the controller’s prior authorisation. The DPA should specify whether authorisation is general or specific, and what notice the processor must give before engaging new sub-processors.
It can be part of the main service agreement, provided all required elements are included. Electronic acceptance of a DPA addendum is generally sufficient — physical signatures are not required.
Engaging a processor who refuses to sign a DPA puts the controller in breach of GDPR. If a vendor cannot or will not provide a compliant DPA, the controller should consider whether the relationship can continue.
Manage your data processing agreements and processor register in one system
iGDPR lets you maintain a central register of all processors and DPAs, link each agreement to the relevant processing activities, track validity and flag missing agreements — all connected to your record of processing activities. See how it works in practice.
START FREE TRIAL
