What is a data processing agreement (DPA) and when do I need one?
By SuLe · Updated 11 June 2026
A data processing agreement is the contract UK GDPR Article 28 requires whenever a processor handles personal data on your behalf — your host, analytics tool, email platform or any subprocessor. It is mandatory, not optional, and it must contain a set of specific terms. If a supplier touches your users' data, you need a DPA with them.
Key facts
- UK GDPR Article 28 requires a written DPA whenever a processor handles personal data for you.
- It is mandatory and must contain specific terms — scope, duration, security, subprocessors, deletion and audit rights.
- Your startup is usually the controller; your suppliers are usually the processors.
- Controller-to-controller data sharing needs a data sharing arrangement instead, not a DPA.
- Most major processors publish a standard DPA you can accept — but you still need one in place.
What is a DPA and why is it mandatory?
A data processing agreement is the contract that governs a processor handling personal data for you. UK GDPR Article 28 makes it a legal requirement — you cannot lawfully hand personal data to a processor without one.
A processor is any supplier that processes personal data on your instructions rather than for its own purposes: your cloud host, your analytics provider, your transactional email service. When they process your users' data, Article 28 applies.
The DPA is not paperwork for its own sake. It binds the processor to act only on your instructions, keep the data secure, and help you meet your own obligations — so the chain of responsibility does not break at your supplier.
When exactly do I need one?
Whenever a processor handles personal data for you — which, for a typical startup, is most of your stack. Hosting, databases, analytics, email, customer support tools and payment processors commonly all qualify.
You do not need a DPA with a supplier that never touches personal data — a design contractor working only on mock-ups, say. The trigger is personal data being processed on your behalf, not the mere existence of a supplier relationship.
The other boundary is controller-to-controller. Where you share data with an organisation that decides its own purposes — not acting on your instructions — that is a data sharing arrangement, governed differently, not an Article 28 DPA.
What must a compliant DPA contain?
Article 28 prescribes the core terms, so a compliant DPA is not free-form. It must set out the subject matter and duration, the nature and purpose of the processing, the type of personal data and categories of data subject, and your obligations and rights as controller.
It must also bind the processor to specific commitments: process only on your documented instructions; ensure confidentiality; keep the data secure; engage subprocessors only with authorisation and on equivalent terms; assist with data subject rights and breaches; and delete or return the data at the end.
Finally it must give you audit and information rights, so you can verify compliance. A DPA missing these elements is not Article 28-compliant, however official it looks.
| Element | What it covers | Why it matters |
|---|---|---|
| Scope & duration | Subject matter, length, purpose | Defines the permitted processing |
| Data & subjects | Types of data and people | Bounds what the processor may touch |
| Security | Appropriate technical measures | Meets the Article 28 security duty |
| Subprocessors | Authorisation and flow-down terms | Keeps the chain compliant |
| Rights & breach help | Assisting with DSARs and breaches | Lets you meet your own duties |
| Deletion / return | End-of-contract data handling | Prevents orphaned personal data |
Who drafts it — me or my supplier?
Usually whoever is the larger or more standardised party. Big processors — cloud, email and analytics providers — publish their own DPA that you accept as part of onboarding, and relying on a reputable provider's standard DPA is normally fine.
When your startup is the processor for a customer, the roles flip: you may offer your DPA to them, often attached to your SaaS terms as a schedule. Enterprise customers will frequently present their own instead.
What matters is not authorship but existence: a signed, Article 28-compliant agreement covering the relationship. Keep a simple register of which DPAs are in place with which processors, so nothing slips through.
Worked example
Hannah runs Bloomdesk, a customer-support SaaS. Her stack includes a cloud host, a transactional email provider, an analytics tool and a helpdesk integration — all of which process her customers' end-user data.
Each of those is a processor, so Hannah accepts each provider's standard Article 28 DPA and logs them in a short register. Her design agency, which only builds marketing pages and never touches user data, needs no DPA.
When a mid-market client signs, Bloomdesk is now their processor, so Hannah attaches her own DPA to the SaaS terms. The client's procurement team reviews it, tweaks the subprocessor list, and signs — the chain from client to Bloomdesk to its subprocessors stays intact end to end.
Where founders go wrong
Assuming reputable tools make the DPA unnecessary.
A trustworthy provider still requires a signed Article 28 agreement — trust is not compliance.Confusing controller-to-controller sharing with processing.
Sharing with an organisation that sets its own purposes needs a data sharing arrangement, not a DPA.Ignoring subprocessors.
Your processor's subprocessors must be covered by flow-down terms, or the chain breaks below you.Keeping no register.
Without a list of who processes what under which DPA, gaps go unnoticed until due diligence finds them.
Related questions
Is a data processing agreement legally required?
Yes. UK GDPR Article 28 requires a written contract with mandatory terms whenever a processor handles personal data on your behalf — there is no discretion about it. Using a hosting provider, analytics tool or email service without a DPA in place is a compliance gap, even though most reputable suppliers offer one as standard.
What is the difference between a controller and a processor?
A controller decides why and how personal data is processed; a processor acts on the controller's instructions. Your startup is usually the controller, and your suppliers — host, analytics, email — are your processors. The distinction matters because Article 28 governs controller-to-processor relationships, while controller-to-controller sharing needs a different arrangement.
Do I need a DPA with every supplier?
You need one with every supplier that processes personal data for you as a processor. A supplier that never touches personal data does not need one. Where two organisations each decide their own purposes — controller to controller — you need a data sharing arrangement instead, not an Article 28 DPA.
Who provides the DPA — me or the supplier?
Either. Large processors like cloud and email providers publish their own DPA that you accept, and that is usually fine to rely on. When you are the processor for a customer, you may present your DPA to them. What matters is that a compliant Article 28 agreement exists and is signed, not who drafted it. [More: What should B2B SaaS terms of service include?]
The DPA is one of the most-missed pieces of startup compliance precisely because it feels like admin — until a customer's security review or an investor's data-room request asks for the whole set. A SuLe solicitor can check your processor contracts and give you a DPA to offer your own customers. Book a free compliance check call and close the gaps in your data chain.
Keep reading: What does UK GDPR require from an early-stage startup? · What should B2B SaaS terms of service include? · What is a master services agreement (MSA)? · Can I transfer user data outside the UK? · What happens if my startup has a data breach? · Can I use OpenAI or Anthropic APIs and stay UK GDPR compliant?
Primary sources: ICO — For organisations · GOV.UK — Data protection
