Data processing agreements: when you need one

You need a data processing agreement (DPA) whenever one business processes personal data on behalf of another under the GDPR or UK GDPR. If you use an email platform, payroll provider, CRM, cloud host or outsourced support team that handles personal data for you, you need a DPA with each of them. If you’re the supplier handling your clients’ customer data, your clients need one with you. Several US state privacy laws, California’s included, require similar contracts with service providers and processors.

For most small businesses, the DPA already exists. Big software vendors publish one and fold it into their terms. The work is in finding it, checking it, and knowing what to do when a client sends you theirs.

Controllers and processors, in plain terms

The controller decides why and how personal data is used. The processor handles it on the controller’s behalf and on its instructions. A subprocessor is a supplier the processor uses, such as the cloud host behind a software product.

Take Hannah, who runs a physiotherapy clinic in Dublin. She decides to collect patient names, contact details and appointment notes, so she’s the controller. The booking software that stores that data for her is her processor. The booking company runs on a large cloud platform, which is a subprocessor.

Diagram of a data chain: a physio clinic as controller decides why and how data is used, booking software as processor acts only on the clinic’s instructions, and a cloud host as subprocessor is bound by the same obligations; a DPA links the clinic and the software, and subprocessor terms link the software and the host — Each link in the chain needs its own contract, and the obligations should flow all the way down.

Not every supplier is a processor. Your accountant or lawyer usually decides how to use the data to meet their own professional duties, which makes them a controller in their own right. The same goes for a bank handling payments. You don’t need a DPA with them, although your privacy notice should still mention that you share data with them.

What the GDPR says a DPA must include

The GDPR sets out what a controller-processor contract has to cover. In short, the processor must:

process the data only on the controller’s documented instructions
make sure its staff are bound by confidentiality
keep the data secure with appropriate technical and organizational measures
use subprocessors only with the controller’s authorization, and pass the same obligations down to them
help the controller respond when people exercise their rights
help the controller with security, breach notifications and impact assessments
delete or return the data when the service ends
provide the information needed to show compliance, and allow audits

The contract also has to describe the processing: its subject matter and duration, its nature and purpose, the types of personal data and the categories of people involved. That description usually sits in an annex, and it’s the part most often left blank or copied from someone else’s template.

Checklist of eight terms a GDPR processor contract must cover: acting only on instructions, staff confidentiality, security measures, approved subprocessors, help with rights requests, help with breaches and assessments, deletion or return at the end, and showing compliance including audits, plus a description of the processing — The eight required terms, plus the description of processing that people tend to skip.

The clauses worth negotiating

The required terms are fairly standard. The commercial terms around them are where DPAs really differ.

Breach notification timing

Controllers have 72 hours to notify the regulator, so they want processors to tell them fast. “Without undue delay” is the standard processor wording. A client demanding notice within 24 hours of any suspected incident, including ones that turn out to be nothing, can be hard for a small supplier to meet. Something like 48 hours after confirming a breach is a common middle ground.

Audit rights

Controllers are entitled to check compliance, but unlimited on-site audit rights are a real burden for a small processor. Offering certifications or a completed security questionnaire first, with on-site audits limited to once a year on reasonable notice, is a fair position.

Liability and indemnities

Clients often ask for uncapped indemnities for data breaches. If you’re the supplier, compare this with the limitation of liability in your main contract, and make sure the DPA doesn’t quietly override it. A separate, higher cap for data protection claims is a common compromise. Check what your cyber insurance actually covers before you agree to a number.

Subprocessors

Most processors use a general authorization: they list their current subprocessors and give notice of changes, and the controller can object. Check the notice period and what happens if you do object. Often the only remedy is ending the service.

International transfers

If data leaves the EU or UK, the DPA should include or reference the standard contractual clauses or another valid transfer mechanism, such as the EU-US Data Privacy Framework for certified US companies.

When a client sends you their DPA

If you run a small agency or software business, sooner or later a bigger client will send you a 15-page DPA and ask for a signature by Friday. Don’t sign it just because it’s labeled “standard.” Check that it describes what you actually do, since some client templates assume you host sensitive data when you only ever see a contact list. Look for clauses that pull in the client’s own security policy by reference, which can commit you to controls you’ve never read. And watch for wording that makes you responsible for the client’s own compliance failures.

Pushing back is normal. Many clients will accept your own DPA if it covers the required terms, or agree to a short list of edits. Keep a copy of the signed version with the main contract, because DPA obligations often continue for as long as you hold the data, even after the services end. A survival clause usually spells out which ones.

US state privacy laws

US laws use different labels. California’s law talks about “service providers” and “contractors” and requires written contracts that, among other things, stop them selling or sharing the data or using it outside the business relationship. Virginia, Colorado, Connecticut and many other states with comprehensive privacy laws require controller-processor contracts with terms that look a lot like the GDPR list. Whether these laws apply to you depends on thresholds such as revenue or the number of state residents whose data you handle, so check each state where you do business.

A quick checklist

List every supplier that touches personal data for you and mark each one as a processor or not.
For each processor, find their DPA (usually linked in their terms or trust center) and save a dated copy.
Check that the description of processing matches what you actually use them for.
Check the subprocessor list, the breach notification timing and the transfer mechanism.
If you’re a supplier, prepare your own standard DPA so you’re not negotiating from scratch with every client.

Next steps

Start with your three biggest suppliers by data volume, which for most businesses means email marketing, CRM and payroll, and confirm each has a DPA in place. If a client has sent you their DPA, read the liability, audit and breach clauses first, since that’s where the cost sits. You can upload a DPA to LegalWolf to check it against the GDPR list and flag terms that clash with your main agreement.

This article is general information, not legal or tax advice. Laws differ between countries and states and change over time, so check the rules that apply to you or speak to a qualified professional.