Data processing agreement: what it is and which of your tools need one

A data processing agreement is the contract the GDPR asks for between you and any company that handles personal data on your behalf: your email platform, your host, your analytics tool. Article 28 lists what it has to say. For most website tools you don’t draft anything. The vendor publishes its DPA and you accept it in the terms or with a setting. The real work is knowing which tools those are, and making sure your privacy policy names them.

This guide covers what a DPA is, when you need one and what goes in it, then the tools on a typical small site and where each vendor keeps its terms. There’s a build order, a prompt you can hand an assistant, and a check you can run on your phone. If you’re here because a client just emailed asking for your DPA, skip to the template section.

What is a data processing agreement, or DPA agreement?

Two roles first. The controller is whoever decides why and how personal data gets used. The GDPR’s wording is the one who determines the purposes and means of the processing of personal data (Article 4(7)). On your website, that’s you. You decided to collect newsletter sign-ups and what to send.

The processor is the company doing the work for you: ‘processor’ means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller. Your email platform sends the newsletter for you. Your host stores the form entries for you. The ICO’s page on when a contract is needed has a small-business example: A marketing company sends promotional vouchers to a hairdresser’s customers on the hairdresser’s behalf. The marketing company is a processor for the hairdresser.

The data processing agreement is the contract between the two. You’ll also see it called a data processing addendum, data processing terms or a data processing amendment. Google says “terms”, Shopify says “addendum”, Stripe and HubSpot say “agreement”. Same job each time: it ties the processor to your instructions.

When is a data processing agreement required?

Whenever a processor handles personal data for you. Article 28(3) says Processing by a processor shall be governed by a contract or other legal act that binds the processor to the controller (GDPR Article 28). The UK GDPR says the same. Paragraph 9 adds that it shall be in writing, including in electronic form, so terms you accept online count. Article 28 has no exception for small companies.

People mostly go wrong in the other direction. A company that uses the data for its own purposes is a controller in its own right for that part, and the GDPR says a processor that starts deciding purposes and means shall be considered to be a controller in respect of that processing (Article 28(10)). Plenty of vendors are both, and their own terms say where the line runs:

• Stripe’s DPA lists purposes where it’s your processor, and others, fraud monitoring and its own legal duties among them, where it has the sole and exclusive authority to determine the purposes and means of Processing Personal Data it receives from or through User (Stripe DPA).
• HubSpot is a processor for your customer data. Its controller-to-controller terms apply solely to the extent that Customer uses our enrichment products or the HubSpot Tracking Code with Intent data sharing enabled (HubSpot DPA).
• Google keeps a public list. Google Analytics and Google Tag Manager are under its Data Processing Terms. Most of Google Ads, and AdSense, are under its controller-controller terms (Google’s service list).

I don’t decide who’s what. Go by the vendor’s description, and where it’s unclear, the EDPB’s guidelines on controller and processor. Where a vendor is a controller, there’s no DPA for that part. It still receives your visitors’ data, so your privacy policy still covers it.

In the US, the nearest thing is the CCPA’s service provider contract. California’s Civil Code defines a service provider as one handling personal information for a business pursuant to a written contract that stops it selling or sharing that information or using it outside the contract’s purposes (Cal. Civ. Code 1798.140(ag)). Shopify’s DPA, for one, has a separate appendix for when it acts as a service provider under US laws. The CCPA compliance guide has the rest.

What GDPR Article 28 says a DPA must contain

First, the contract describes the processing: subject matter and duration, nature and purpose, the type of personal data, whose data it is, and your obligations and rights. Then the processor commits to eight things, points (a) to (h):

Point	What the processor commits to
(a)	Uses the data only on your documented instructions, including about sending it abroad, unless a law says otherwise
(b)	Everyone handling the data is bound to confidentiality
(c)	Takes the security measures Article 32 asks for
(d)	Brings in other processors only on the conditions in paragraphs 2 and 4
(e)	Helps you answer people using their rights, such as access or deletion
(f)	Helps with security, breach notifications and impact assessments (Articles 32 to 36)
(g)	Deletes the data or hands it back at the end, your choice
(h)	Gives you what you need to show it complies, and allows audits and inspections

It also has to tell you straight away if it thinks an instruction of yours goes against the rules. The ICO’s page on what needs to be included in the contract goes point by point, with one practical line worth knowing: An instruction can be documented by using any written form, including email.

On sub-processors, your processor needs your prior written authorisation, specific or general, before it brings one in. With a general one it tells you about changes so you can object. The sub-processor takes on the same obligations and your processor stays fully liable for it (Article 28(4) GDPR). The ICO notes the word itself is shorthand: this is not a term taken from the UK GDPR itself. Shopify’s version is typical. It keeps a list, gives you a way to get notice of changes, and lets you object (Shopify DPA).

Point (c) leads to Article 32. What that means on a website is in the guide to security headers.

Point (a) covers data sent abroad, so the DPA usually carries the transfer safeguard too. Stripe’s says User transfers Personal Data to Stripe, LLC in the United States and attaches a data transfers addendum. The Commission’s transfer clauses for processors already include Article 28, and its questions and answers say so: Companies therefore do not need to sign a separate contract to comply with Article 28 of the GDPR. The UK is different. The ICO says The EU SCCs are not valid on their own for restricted transfers under the UK GDPR. You add its IDTA or its Addendum. The Handbook article on international data transfers has more.

Which of your website tools need one

Here’s a typical small site. “Typically sees” is what that kind of tool usually gets from your visitors. For the legal role, read the vendor’s own terms.

Tool	Typically sees	Where the DPA usually lives
Host or shop platform	Form entries, orders, server logs with IP addresses	In the main terms. Shopify’s Data Processing Addendum is incorporated into its Terms of Service
Analytics	IP addresses, device details, pages viewed, cookie identifiers	Google’s Ads Data Processing Terms cover Analytics and Tag Manager
Email marketing	Names, email addresses, opens and clicks	The provider’s legal pages, linked as “DPA” or “data processing terms”
Forms	Whatever the form asks	The form service’s legal pages, or your host’s if the form posts to your own server
Live chat	Names, emails, messages, IP addresses	The chat vendor’s legal pages
Payments	Names, card details, billing addresses, device data	Stripe’s Data Processing Agreement, part of its agreement
CRM	Contact details, notes, often tracking data	HubSpot’s Data Processing Agreement, part of its Customer Terms
Scheduling	Names, emails, appointment times	The booking tool’s legal pages
Error tracking	IP addresses, browser details, sometimes what a visitor typed	The vendor’s legal or security pages
Embeds: maps, video, fonts	IP addresses, sometimes cookies	The provider’s terms, which may not make it your processor at all

That last row is the one I can’t settle for you. Embed providers word their terms differently, and some say little about their role.

Acceptance usually works one of three ways.

1. It’s built into the terms. Shopify, Stripe and HubSpot fold the DPA into the main contract, so it applies from sign-up. The EDPB says DPAs inside standard terms aren’t a problem in themselves (paragraphs 108 and 110).
2. It’s a setting. Google Analytics’ help page says businesses established in the EEA, the UK or Switzerland already have the terms incorporated. Everyone else accepts them in Admin, under Account settings, Account details, Data Processing Amendment, and Amendments for new accounts are automatically accepted.
3. It’s a click or a signature. Google’s terms take effect on the date on which Customer clicked to accept or the parties otherwise agreed to these Data Processing Terms. HubSpot’s DPA page offers a signed copy on request.

Take-it-or-leave-it terms are fine. The EDPB uses that exact case, a cloud service whose terms are provided to the customer on a “take it or leave it basis”, and still calls the customer the controller and the provider the processor. Then it adds a line for small businesses: the imbalance in the contractual power of a small data controller with respect to big service providers should not be considered as a justification for accepting terms that fall short. So read what you accept. If a vendor changes its DPA, The mere publication of these modifications on the processor’s website is not compliant with Article 28. That’s paragraph 110 of the EDPB guidelines. Save a dated copy of each DPA when you accept it.

How to build your list: a build order and a prompt

1. List every outside domain your site loads. The cookie check guide shows how: developer tools, Network tab, reload, and note every domain that isn’t yours. Do the homepage, a form page and the checkout.
2. Add what the browser doesn’t show: where form entries go, your email platform, your CRM, your host.
3. Mark which ones get personal data. Nearly every request carries the visitor’s IP address, so most will. The personal data examples guide covers what counts.
4. Write down processor or controller for each, as the vendor describes itself, for the way you use it.
5. Find the DPA. Accept it where it’s a setting, and save a dated copy.
6. Note where the data goes: which country, and which safeguard the DPA names.
7. Update your privacy policy. Article 13 asks for the recipients or categories of recipients of the personal data, if any, and for any transfer abroad with its safeguard (Article 13). The privacy policy example shows the section.
8. Do it all again whenever you add a tool.

An assistant can draft steps 1 to 6. Paste your domain list into this:

Here is a list of the third-party domains my website loads, and the services my forms and checkout send data to:

[paste the list here]

For each one:
1. Name the company behind it.
2. Say what personal data it is likely to receive from my visitors.
3. Say whether the company describes itself as a processor or a controller for this use. Quote its own documentation and give the URL.
4. Give the URL of its data processing agreement or data processing terms, and say how it is accepted: part of the terms of service, a setting in the account, or a separate signature.
5. Say where it stores or sends the data, if its documentation says so, and which transfer safeguard it names.

Answer in a table with one row per company. Mark anything you are not sure of as "unsure". Don't guess, and don't fill a gap with a general statement.

Then check its work, because legal pages move and assistants quote old versions. Open every URL and find the quote. If it isn’t there, the row stays “unsure”.

Data processing agreement template: when you need to draft one

You need a DPA template when you’re the processor: an agency running clients’ sites, a developer hosting a booking system, a small SaaS. If you only use other people’s tools, you accept theirs.

Start from the official texts:

• The European Commission’s standard contractual clauses between controllers and processors, adopted on 4 June 2021 under Article 28(7), with a Word version you can fill in. They’re voluntary: There is no obligation to use SCCs.
• The ICO’s page on what needs to be included in the contract, for the UK GDPR. It also points to the Danish data protection authority’s clauses, approved by the EDPB, and says a contract using them unchanged should comply with Article 28.
• The transfer clauses above, if client data leaves the EU or the UK with you.

Fill in the annexes honestly, sub-processors included. The ICO’s guidance for controllers using a processor says clients may ask for documents such as your privacy policy and information security policy, so have them ready. And get a lawyer to read the final version before you send it.

Common mistakes on real sites

These are the gaps I see most on small sites.

The policy names three services and the site loads twelve. Analytics, payments and the email platform are usually listed. The chat widget, the map, the booking embed and the error tracker usually aren’t.

A DPA covers one product while the site uses another. Google’s terms apply only to the services they were agreed for. HubSpot’s split turns on which features you switch on, so one setting can move a tool to different terms without anyone touching the privacy policy.

A form sends data to a tool nobody listed. A contact form plugin posting to its own servers, a quote form feeding a CRM, a footer newsletter box run by a second email platform.

Data goes abroad and the policy names no safeguard. The vendor’s DPA has one, but the policy says only “we may transfer data outside the EEA”. Article 13(1)(f) asks for the safeguard and how to get a copy.

Check your own site with a phone

1. Open your privacy policy on your phone. Write down every company it names, and every category, like “analytics providers”.
2. Clear the stored data for your site. On an iPhone it’s Settings, Safari, Advanced, Website Data.
3. Load your homepage, a form page, and the checkout or booking page. Accept the banner so everything loads. Consent is a different check.
4. Go back to Website Data. Every domain that isn’t yours belongs to a company. Look up any you don’t recognise.
5. Look at the pages. A chat bubble, a map, a video, a payment button and a “powered by” line under a form are all companies.
6. Send yourself a test through each form and note who the confirmation comes from.
7. Put the two lists side by side. Every company missing from the policy needs a line, and if it’s a processor, a DPA.
8. Find the transfers section. Does it name a safeguard for each company keeping data outside the EU or the UK?

Website Data only shows companies that stored something, so the laptop Network tab from the cookie check guide catches more.

Peeky reads the public pages of your site for the same gaps. For EU-04 and UK-06, he lists the outside companies your pages contact and compares them with the companies your privacy policy names. For EU-06, he looks for visitor data leaving for servers outside Europe, and whether the policy says how it’s protected.

Questions people ask

What is a DPA agreement?

A DPA, or data processing agreement, is the contract between a business and a company that handles personal data on its behalf, such as an email platform or a host. Article 28 of the GDPR requires it and lists what it must say: follow your instructions, keep the data confidential and secure, use sub-processors only with your authorisation, help with people's rights, delete or return the data at the end, and allow audits.

Is a data processing agreement required for every tool?

Only for tools that handle personal data on your behalf. The ICO says that every time a controller uses a processor there must be a written contract. Where a vendor uses data for its own purposes, it's a controller for that part, and its own terms usually say so. It still belongs in your privacy policy as a recipient.

What's the difference between a data processing agreement and a data processing addendum?

Nothing that matters. Vendors pick the name. Shopify calls its document a Data Processing Addendum, Stripe a Data Processing Agreement and Google its Data Processing Terms. "Addendum" usually signals that it's attached to the main terms of service. Whatever it's called, it has to cover the points in Article 28(3) of the GDPR.

Do I need to sign Google's data processing terms?

For Google Analytics, usually not by hand. Google's help page says businesses established in the EEA, the UK or Switzerland already have the terms incorporated. Others accept them in Admin, under Account settings, and new accounts accept them automatically. Most of Google Ads sits under Google's controller-controller terms instead, so it's a recipient rather than your processor.

Who signs the DPA, the controller or the processor?

Both are bound by it. The ICO says the controller and processor must be party to the contract. With most website tools nobody signs paper: the vendor drafts it and you accept it with the terms or a setting. When you draft one yourself, the EDPB recommends signatures so it's easy to show the contract is in force.