Data processing agreements (Article 28): when you need one with clients and suppliers

A data processing agreement (DPA) is the contract you need whenever another business handles personal data on your behalf: the studio that maintains your website, the freelancer who manages your CRM, the tool that sends your newsletter. Article 28 of the GDPR makes it compulsory and lists what it must say. The UK GDPR keeps the same rule.

Small teams sit on both sides of it. You are the client of a dozen tools that process your customers’ data, and you may also be the supplier who handles data for your own clients. When I build an automation for a client, like the internal app I made for one of them, I need access to their mailbox, for example. That is exactly the kind of access a DPA is meant to frame.

For the wider picture, see my complete guide to GDPR.

Controller or processor? The two roles, with examples

The controller decides why and how personal data is processed (Article 4(7)). The processor processes it on the controller’s behalf (Article 4(8)). What counts is who decides, not who holds the data or who is bigger: a one-person studio can be the processor of a large company, and Google is the processor of a two-person shop that runs on Google Workspace.

A cold emailing provider that also finds the leads makes choices a processor normally leaves to its client, so write down who chooses the sources, who informs prospects and who handles objections (my cold email GDPR checklist covers those duties). And a processor that uses your data for its own purposes becomes a controller for that processing (Article 28(10)).

Distance changes nothing. A developer in Casablanca who maintains a French shop’s customer database is its processor. And a business in London, Toronto or New York that falls under the GDPR because it sells into the EU (the two tests are explained here) needs Article 28 terms with its own processors.

When you need a data processing agreement, and when you don’t

You need one in two situations:

1. As a client, with every supplier that processes personal data for you, whatever its size and whether you pay for it or not. Article 28(1) also asks you to use only processors that offer sufficient guarantees, and the DPA is where those guarantees are written down.
2. As a supplier, whenever you handle a client’s personal data, even if all you have is a login. Merely consulting data counts as processing under Article 4(2).

You don’t need one when the other party decides for itself what it does with the data, as your bank does with a payment: you are then two separate controllers.

Joint controllers: a different arrangement

When two businesses decide together why and how data is processed, they are joint controllers (Article 26): two firms that co-host a webinar and design its sign-up form together, for example. Instead of a DPA, they sign an arrangement that says who informs people and who answers their requests, and they make its essence available to them. People can still exercise their rights against either firm.

What a data processing agreement must contain

Article 28 of the GDPR sets the minimum. The contract must be in writing, and electronic form counts (Article 28(9)), so terms accepted online and a signed PDF both work. It must describe the processing: its subject matter and duration, its nature and purpose, the types of personal data, the categories of people concerned, and the controller’s obligations and rights. Then the processor commits to eight things:

1. Act only on your documented instructions, including on transfers outside the EU.
2. Confidentiality: everyone who handles the data is bound by it.
3. Security: the measures Article 32 requires, from encryption to the ability to restore data after an incident.
4. Sub-processors only with your authorisation and under the same obligations.
5. Help with people’s rights, such as access and erasure requests.
6. Help with your other duties: security, breach notification and impact assessments (Articles 32 to 36).
7. Delete or return the data at the end, as you choose, and delete copies unless the law requires keeping them.
8. Audits: give you the information that proves compliance, and allow audits, including inspections.

The processor must also tell you at once if it thinks one of your instructions breaks data protection law. In the UK, the ICO (formally the Information Commission since 30 September 2026) lists the same terms in its guidance on contracts.

Sub-processors: the chain behind your supplier

Your suppliers have suppliers: your CRM runs on a cloud host, your newsletter tool on a delivery service. Under Article 28(2), a processor needs your prior written authorisation before bringing in another processor. That authorisation can be specific, case by case, or general, in which case the processor must tell you about changes in advance so that you can object. Article 28(4) passes the same obligations down the chain, and your processor stays fully liable to you for the ones below it.

Large providers usually rely on general authorisation: they publish a list of sub-processors, and some let you subscribe to notices of changes. Keep a simple list of your own processors, with a link to each one’s DPA and sub-processor page. It feeds your record of processing (Article 30) and your privacy policy, and it answers the client who asks who touches its data.

Free templates: the EU model clauses and the CNIL guide

You don’t need to pay for a template. On 4 June 2021, the European Commission adopted standard contractual clauses between controllers and processors (Implementing Decision (EU) 2021/915). They meet the requirements of Article 28(3) and (4) and can be used between any controller and its processor. You keep their wording as it is, pick one of the two sub-processor options in Clause 7.7 (specific or general authorisation) and fill in the annexes: the parties, the description of the processing, the security measures and the list of sub-processors.

Don’t confuse them with the clauses adopted the same day for transfers outside the EU (Decision 2021/914), which my guide to US tools and the Data Privacy Framework covers.

In France, the CNIL’s guide for processors (September 2017 edition) includes an example of clauses to adapt to each service. For a contract under the UK GDPR alone, the EU clauses refer to EU law, so adapt the references or work from the ICO’s list.

Model clauses cover data protection only: price, liability caps and intellectual property stay in your main contract.

Getting your suppliers’ DPAs: Google, Microsoft and the rest

With big providers, you don’t negotiate: you accept. Menu names and plans below are those at the time of writing (October 2026).

• Google Workspace uses its Cloud Data Processing Addendum. A super administrator reviews and accepts it in the Admin console under Account > Account settings > Legal and compliance (Security and Privacy Additional Terms). Google’s help page says this is only needed if your agreement does not already include it, and changes nothing if it does, so accept it when in doubt.
• Microsoft 365: the Products and Services Data Protection Addendum is incorporated by reference into Microsoft’s Product Terms, so there is nothing to sign. Download a copy from aka.ms/dpa for your records.
• Other tools: look for “DPA”, “data processing addendum” or “data processing agreement” on the legal, privacy or trust page. Many build it into their terms; others are signed through a form, as OpenAI’s is for ChatGPT Business, ChatGPT Enterprise and its API.

Personal plans are the gap. OpenAI offers no DPA for its Free, Go, Plus or Pro plans, and Google’s processing terms come with Google Workspace, not with a personal Gmail account. If a tool has no DPA, keep client data out of it. Save a dated PDF of every DPA you accept: terms change, and you want the version that applied.

When a client sends you their DPA

If you work for larger clients, the DPA often arrives with the contract, sometimes with a security questionnaire. Read it as the supplier, because you are the one making promises. Check five points:

1. The description matches what you really do. When I need a client’s mailbox for an automation, the annex should name the mailbox, the purpose and how long access lasts.
2. Breach notification: the GDPR asks processors to warn the controller without undue delay (Article 33(2)). Some DPAs set a fixed number of hours: accept only a deadline you can keep, weekends included. The controller then has its own 72 hours to notify the regulator.
3. Sub-processors: list your own tools in the annex (hosting, email, file sharing) so that you comply from day one.
4. Audits: the right to audit is mandatory, but you can propose reasonable conditions, such as notice and documents first.
5. Liability and indemnities go beyond Article 28: check that the DPA does not lift the liability cap set in your main contract.

At the end of the contract, return or delete the data as agreed, within the deadline you set together (see my guide to GDPR retention periods). Then remove your access: the mailbox, the CRM login, the API keys.

Your checklist, and when to call a lawyer

1. List every supplier that touches personal data for you, with its role.
2. For each processor, save the DPA, the sub-processor list and the transfer mechanism if data leaves the EU or the UK.
3. Move client data off tools that offer no DPA.
4. If you handle data for clients, prepare your own DPA from the Commission’s clauses, annexes filled in, before a client asks.
5. As a processor, keep a record of the processing you carry out for clients (Article 30(2)).
6. Review the list once a year and whenever you add a tool.

This guide is general information, not legal advice. For most small teams, the Commission’s clauses and the providers’ standard DPAs are enough, without a lawyer. A lawyer or a DPO is worth paying for when you process health or other sensitive data, when a client’s DPA includes unlimited liability or indemnities, when you act as joint controllers, or when a supplier outside Europe offers no transfer mechanism you can rely on.