What Is a Data Processing Agreement (DPA)? GDPR Requirements Explained

If your website collects any personal data from EU residents, and that data touches a third-party service, you need a Data Processing Agreement. Not a nice-to-have. Not optional compliance theater. An actual legal requirement under Article 28 of the GDPR, with fines of up to 4% of global annual turnover if you skip it.

The problem is that most founders and product teams either don't know this requirement exists or assume it's been handled somewhere in the vendor's terms of service. It usually hasn't. A vendor's standard ToS is not a DPA. And clicking "accept" on a cookie banner during vendor onboarding is definitely not a DPA.

This guide explains exactly what a Data Processing Agreement is, when you need one, what it legally must include under GDPR, and how to figure out which of your current vendor relationships require one right now.

What Is a Data Processing Agreement?

A Data Processing Agreement (DPA) is a legally binding contract between two parties: a data controller and a data processor. The controller is the business that decides why and how personal data is collected and used. The processor is a third-party service that handles that data on the controller's behalf.

When you collect email addresses on your website and send them to Mailchimp to run your newsletter, you are the controller. Mailchimp is the processor. The DPA is the contract that says: here is what data we're sharing, here is the only purpose it can be used for, and here are the security measures you must maintain to protect it.

GDPR Article 28 makes this mandatory. It's not a recommendation or a best practice. Any time a controller uses a processor to handle personal data, a DPA must be in place before processing begins. Processing data without a DPA in place is a GDPR violation, full stop.

When Do You Need a DPA?

You need a DPA any time you share EU personal data with a third-party service that processes it on your behalf. The easiest way to think about it: if a vendor receives, stores, or does anything with personal data that belongs to your users, and they're doing it to provide a service to you, that's a processor relationship and a DPA is required.

Here are the most common scenarios where businesses need DPAs but often don't have them:

• Email marketing platforms: Mailchimp, Klaviyo, ConvertKit, ActiveCampaign. They store your subscribers' email addresses and personal data.
• Analytics tools: Google Analytics, Mixpanel, Amplitude. They receive IP addresses and behavioral data from your visitors.
• CRM systems: HubSpot, Salesforce, Pipedrive. They store customer contact information and interaction history.
• Customer support tools: Intercom, Zendesk, Freshdesk. They process customer names, emails, and support ticket contents.
• Cloud hosting and storage: AWS, Google Cloud, Azure. They store all data on your platform including anything personal.
• Payment processors: Stripe, PayPal, Braintree. They handle payment and billing information.
• Error monitoring: Sentry, Datadog, Bugsnag. They may capture stack traces containing personal data.
• Video hosting: Wistia, Vimeo Business. If you upload customer-facing content with personal identifiers.

Most major vendors actually have their DPAs available for download in their legal documentation or compliance sections. Google, Mailchimp, Stripe, AWS, Intercom, and others all have standard DPAs. The typical process is: navigate to the vendor's privacy or legal page, find the DPA, sign it (sometimes via a click-through, sometimes it requires a signature), and keep a copy on file.

Controller, Processor, and Joint Controller: What's the Difference?

GDPR draws a sharp line between these three roles and the legal obligations are very different depending on which role applies.

The joint controller scenario is the one that catches businesses off guard most often. Facebook Pixel is the classic example. When you install the Facebook Pixel, Facebook isn't just processing data on your behalf. They're also using that data for their own advertising purposes. That makes Facebook a joint controller for some of that data, not just a processor, and a DPA alone doesn't cover the relationship properly.

For a broader look at all the compliance documents your site should have in place, the complete GDPR guide covers the full picture.

What a GDPR-Compliant DPA Must Include

Article 28(3) of GDPR specifies exactly what a DPA must contain. This isn't a suggestion; these are mandatory elements without which the agreement is not compliant. Here's what the law requires:

Subject matter and duration. What personal data is being processed, and for how long. The DPA should specify both the contract term and what happens to data at the end (deletion, return to controller, etc.).

Nature and purpose of processing. What is the processor actually doing with the data? Running email campaigns? Hosting files? Processing payments? The purpose must be documented specifically.

Type of data and data subjects. What categories of personal data are involved (names, emails, IP addresses, payment data, health data) and who the data subjects are (your customers, your employees, website visitors).

Processing only on documented instructions. The processor commits to only process data according to what the controller has instructed, in writing. They cannot use the data for their own purposes.

Confidentiality obligations. Everyone at the processor who has access to the personal data must be bound by confidentiality, either by a legal obligation or a contractual agreement.

Security measures. The processor must implement appropriate technical and organizational measures to protect the data. GDPR doesn't specify exactly what these must be, but they should be appropriate to the risk level of the data being processed.

Sub-processor restrictions. The processor cannot bring in additional sub-processors without either the controller's prior specific consent or prior general authorization with notice of changes. If general authorization is given, the processor must inform the controller of any sub-processor changes and give the controller time to object.

Assistance with data subject rights. The processor must help the controller respond to requests from individuals exercising their GDPR rights: access, erasure, portability, restriction, and objection. If your user asks you to delete all their data, you need your processors to be able to help you do that.

Assistance with controller's compliance obligations. The processor must help with security notifications, data protection impact assessments, and other compliance activities where the processor's involvement is necessary.

Deletion or return at contract end. When the processing relationship ends, the processor must delete or return all personal data, at the controller's choice. No keeping copies.

Audit rights. The processor must allow the controller to conduct audits or inspections, and must provide all information necessary to demonstrate compliance with Article 28.

DPA vs Privacy Policy: Two Completely Different Documents

These two documents are frequently confused but they do entirely different things for entirely different audiences.

A privacy policy is a public document for your users. It tells people what data you collect about them, why you collect it, who you share it with, and what their rights are. It's required by GDPR, the CCPA, and most other privacy laws. It lives on your website and anyone can read it.

A Data Processing Agreement is a private contract between you and your vendor. Your users will never see it. It's not a disclosure to anyone; it's a binding agreement that governs what your vendor can do with data you've shared with them. It's signed by both parties and kept on file as evidence of compliance.

Both are required. One doesn't substitute for the other. Your privacy policy should mention what categories of third-party processors you use. Your DPAs govern the actual relationships with each of those processors.

You also need a GDPR-specific privacy policy that discloses your legal bases for processing, your retention periods, and your data subject rights procedures. That's separate from a standard privacy policy and separate from any DPAs.

How to Actually Get Your DPAs in Order

The practical steps are more straightforward than most people expect. Here's how to approach it:

Step 1: Make a list of every third-party tool that receives personal data. Go through your tech stack: email, analytics, CRM, support, hosting, payments, marketing, monitoring. If it touches personal data, write it down.

Step 2: Check whether each vendor has a standard DPA available. Most major vendors do. For Google services, it's in Google's privacy documentation. For AWS, it's their Data Processing Addendum. For Mailchimp, it's in their legal center. Search "[vendor name] data processing agreement" or "[vendor name] DPA."

Step 3: Sign or accept the DPA for each vendor. Some require a formal signature. Many major vendors have moved to click-through DPAs where accepting it through an online form is legally valid. Keep a record of when you accepted and what version of the DPA was in effect.

Step 4: For smaller vendors without a standard DPA, generate one and have them sign it. This is where a DPA generator comes in. You create the agreement based on the specifics of the relationship, and the vendor signs it. The FreeTOS DPA generator walks you through this process and produces a GDPR Article 28 compliant agreement.

Step 5: Maintain a record of all processing activities. GDPR Article 30 requires controllers to maintain a Record of Processing Activities (RoPA) that documents all data processing operations. Your list of processors and DPAs becomes part of this record.

What Are the Consequences of Not Having a DPA?

GDPR enforcement has moved well past the "big fines only go to Facebook" era. Smaller companies and SMBs get fined too, and missing DPAs is a documented enforcement area.

The maximum penalty for violating Article 28 (the DPA requirement) is up to €10 million or 2% of global annual turnover, whichever is higher. In practice, fines are calculated based on severity, the nature of the data, how long the violation existed, and whether the company was cooperative during the investigation.

Beyond fines, enforcement actions typically require you to remediate the violation immediately, which means scrambling to get DPAs signed with every vendor while under regulatory scrutiny. That's significantly worse than just doing it properly to begin with.

Data breaches are the other major trigger. If you suffer a breach and can't demonstrate you had proper DPAs with your processors, your liability exposure increases substantially because you can't show you took appropriate measures to protect the data.

Frequently Asked Questions