In short
A data processing agreement is a contract between a controller, who decides why personal data is processed, and a processor, who handles it on the controller's instructions. You need one with every supplier processing personal data for you — hosting, analytics, email, support, payments — and clients will need one with you when you process data on their behalf. Most major providers publish one as part of their terms.
Controller and processor
The distinction determines who is responsible for what.
A controller decides why and how personal data is processed. If you run a website and collect enquiries, you are the controller of that data.
A processor handles personal data on the controller's instructions and for their purposes. Your hosting provider, your email platform, your analytics tool are processors.
A DPA is the contract between them, setting out what the processor may do.
The categories are about decision-making, not access. A supplier who could technically read the data but has no say in why it exists is a processor. And an agency deciding to run analytics for its own purposes on a client's site becomes a controller for that, not a processor — which surprises people.
When you need one
As a controller, with every processor: hosting, analytics, email delivery, marketing platform, CRM, support tool, error tracking, payment processing, cloud storage, and any freelancer or agency handling personal data.
As a processor, with every client whose data you handle. If you build and maintain sites, you are a processor for your clients' data, and they need an agreement with you.
That second direction catches agencies out. A client's compliance team will eventually ask, and having one ready is better than drafting under time pressure — it is also a straightforward thing to include in your standard client contract.
What it must cover
A DPA typically sets out:
Subject matter and duration of the processing.
Nature and purpose — what is being done and why.
Types of personal data and categories of people affected.
The controller's obligations and rights.
That the processor acts only on documented instructions, which is the core of it.
Confidentiality commitments from anyone with access.
Security measures appropriate to the risk.
Sub-processor rules — whether they may engage others, and whether you are told or asked.
Assistance with data subject requests, since a controller receiving an access request may need the processor's help to fulfil it.
Breach notification, and how quickly.
What happens at the end — deletion or return of data.
Audit rights, usually satisfied by providing certifications rather than allowing site visits.
Most providers already have one
For major services, a DPA exists as part of their terms and you accept it when you sign up, or activate it in account settings.
So the practical task is usually confirming rather than negotiating: find each provider's DPA, check it covers what you need, and keep a record that it is in place. That record is what you produce when a client asks, and assembling it later is harder than doing it as you go.
Smaller suppliers and freelancers may not have one, in which case you provide it.
What to check before relying on one
Sub-processors. Who else touches the data? Most providers publish a list. Check whether you are notified of changes and whether you can object — this matters more than it sounds, because your data goes wherever their sub-processors are.
Where data is processed. Frequently not where you assumed. If it leaves the EU, check the transfer safeguard.
Breach notification timing. Some commit to a specific period; some say only "without undue delay," which is less useful when you have your own notification obligations.
Deletion at termination. What happens to your data when you leave, and how long it persists in their backups.
Security specifics, or at least a certification you can point to.
Where it does not apply
Some relationships are not controller-processor.
Joint controllers, where two organisations decide purposes together. Different arrangement, different requirements.
Independent controllers, where you pass data to someone who decides their own purposes — an accountant, or a payment provider that determines its own processing for fraud prevention. That is a transfer between controllers, not a processing arrangement.
Getting the classification wrong means having the wrong document, so it is worth thinking about rather than defaulting to a DPA for every supplier relationship.
A practical routine
List every supplier touching personal data. For each, locate the DPA and record where it is and what it covers. Note the sub-processors and processing locations. Have your own processor DPA ready for clients. Review the list annually and whenever you add a supplier — the same trigger that should prompt a privacy policy review.
That is an afternoon and it is the documentation a client's compliance review will ask for.
General information rather than legal advice. For significant contracts or regulated data, have a lawyer review the terms.
If a client has sent you a compliance questionnaire and you are not sure how to answer it, book a call.
Common questions
What is a data processing agreement?
A contract between a controller, who decides why and how personal data is processed, and a processor, who handles it on the controller's instructions. It sets out what the processor may do, security measures, sub-processor rules, breach notification, and what happens to data at the end.
Who needs a DPA?
Anyone using suppliers that process personal data on their behalf — hosting, analytics, email, CRM, support, payments, cloud storage, and freelancers. Agencies also need one in the other direction, since they act as a processor for their clients' data and clients will eventually ask.
Do I need to negotiate a DPA with every supplier?
Usually not. Major providers publish one as part of their terms, accepted at signup or activated in account settings, so the task is confirming rather than negotiating. Keep a record of where each one is, since that is what you produce when a client's compliance team asks.
What should I check in a supplier's DPA?
Who their sub-processors are and whether you are notified of changes, where data is actually processed and what safeguard applies if it leaves the EU, how quickly they commit to notifying you of a breach, what happens to your data at termination, and what security measures or certifications they provide.
Is every supplier relationship a controller-processor one?
No. Joint controllers decide purposes together and need a different arrangement, and passing data to someone who determines their own purposes — an accountant, for example — is a transfer between controllers rather than processing. Using the wrong document means having the wrong protections.
