Almost every business hands personal data to someone else to do a job – a cloud host, a payroll bureau, an email platform, a marketing agency. The moment that happens, the GDPR expects a specific contract to be in place: a data processing agreement. It is one of the most commonly overlooked compliance documents, and one of the easiest for a supervisory authority to check. This article explains when you need a DPA and what belongs in it.
Why the DPA matters
Under the GDPR, the business that decides why and how personal data is processed is the controller, and any outside party that processes that data on the controller’s behalf is a processor. Article 28 requires that this relationship be governed by a written contract. Without one, both parties are exposed: the controller has failed a clear legal obligation, and the arrangement lacks the safeguards that protect the individuals whose data is involved.
When do you actually need one?
You need a DPA whenever another organisation processes personal data on your instructions rather than for its own purposes. Using a cloud provider to store customer records, an external payroll firm to run salaries, or a support tool that handles user data all trigger the requirement. You do not need a DPA with a party that is a controller in its own right – for example, an authority you are legally required to report to, or a professional adviser exercising independent judgement.
Controller, processor or joint controllers?
Getting the roles right is the first step, because it determines which contract you need. If two organisations jointly decide the purposes and means of processing, they are joint controllers and need a different kind of arrangement. Misclassifying a relationship is a common error that leads to the wrong contract being signed.
What a compliant DPA must contain
Article 28 sets out mandatory content. The agreement must state the subject matter, duration, nature and purpose of the processing, the types of personal data and categories of individuals involved. It must bind the processor to act only on the controller’s documented instructions, to keep the data confidential, and to apply appropriate security measures. It must address the use of sub-processors, assistance with data subject rights, breach notification, and what happens to the data when the contract ends – return or deletion. It must also give the controller a right to audit or inspect.
Sub-processors: the clause people forget
Most modern suppliers rely on their own suppliers – a SaaS tool built on a third-party cloud, for instance. The DPA must set out whether the processor may engage sub-processors, and how the controller is informed of and can object to changes. This chain of accountability is frequently where responsibility becomes unclear, so it is worth reading the sub-processor terms rather than assuming them.
International transfers
If the processor or a sub-processor handles data outside the EEA, the agreement needs to address the transfer safeguards the GDPR requires, such as standard contractual clauses. This is one of the more technical areas and one where a generic template often falls short of the specific transfer taking place.
Practical example: onboarding a new SaaS tool
A company adopting a new customer-support platform should, before going live, confirm the supplier is a processor, obtain its DPA, check the list of sub-processors and where they are located, verify the security commitments, and confirm what happens to the data if the company later switches tools. Doing this at onboarding is far easier than reconstructing it during an incident or an audit.
Common mistakes companies make
Businesses often assume the supplier’s standard terms already cover data processing when they do not, sign a DPA without checking the sub-processor and transfer clauses, keep no record of which suppliers process which data, and never revisit agreements as tools change. Another frequent error is treating the DPA as a formality to be filed and forgotten rather than a live description of a real data flow.
Recommended actions
Map which suppliers process personal data on your behalf, make sure each has a signed DPA meeting the Article 28 requirements, pay particular attention to sub-processors and international transfers, and review the arrangements whenever you add or change a supplier. Keep the list current so you can answer a regulator’s question without a scramble.
Frequently asked questions
Is a DPA the same as a privacy policy?
No. A privacy policy tells individuals how you use their data. A DPA is a contract between a controller and a processor governing how the processor handles data on the controller’s behalf. They serve different purposes and neither replaces the other.
Who is responsible if the processor causes a breach?
Both parties can bear responsibility depending on the circumstances. The controller remains accountable for choosing an adequate processor and giving clear instructions, while the processor is responsible for its own obligations under the GDPR and the agreement.
Can we use the supplier’s standard DPA?
Often yes, but you should read it against your actual processing rather than sign it unread. Standard terms vary in quality, and the sub-processor and transfer clauses in particular deserve a careful look.
Conclusion
A data processing agreement turns an informal reliance on suppliers into a documented, accountable relationship that the GDPR requires and regulators expect. The businesses that stay compliant are the ones that know exactly who processes their data and have the right contract in place for each. Lawgent helps companies map their data flows, put compliant DPAs in place and keep them current as their tools evolve. Contact us to review your supplier agreements before a regulator does.
