What Is a Data Processing Agreement (DPA)? A Plain-Language Guide

If you use any SaaS tool that handles personal data on your behalf, you need a Data Processing Agreement. This is not optional. Under GDPR Article 28, any relationship between a data controller (you) and a data processor (your software vendor) must be governed by a binding contract that covers specific data protection requirements.

Most marketing, sales, and customer service tools process personal data: email addresses, names, behavioral tracking, purchase history, support conversations. Every one of those vendor relationships requires a DPA.

What a DPA Actually Is

A Data Processing Agreement (sometimes called a Data Processing Addendum or DPA) is a legally binding contract between two parties:

Data Controller: Your business. You determine why and how personal data is processed. When you collect email addresses for a newsletter, you are the controller.
Data Processor: Your vendor. They process personal data on your behalf, following your instructions. When Mailchimp sends your newsletter, Mailchimp is the processor.

The DPA defines the rules of this relationship: what data is processed, why, how it is protected, where it goes, and what happens when things go wrong.

What GDPR Requires in a DPA

GDPR Article 28(3) specifies what a DPA must include. Here are the key elements in plain language:

Subject Matter and Duration

The DPA must describe what personal data is being processed and for how long. For an email marketing platform, this might be: "subscriber email addresses, names, and engagement data, processed for the duration of the service agreement."

Nature and Purpose of Processing

Why is the data being processed? For a CRM, this would include contact management, pipeline tracking, email communication, and reporting. The purpose must be specific, not vague.

Types of Personal Data

The DPA lists the categories of data involved: names, email addresses, IP addresses, behavioral data, purchase history, etc. This matters because it defines the scope of the processor's obligations.

Categories of Data Subjects

Who are the people whose data is being processed? Typically: your customers, leads, website visitors, newsletter subscribers, or employees.

Obligations and Rights of the Controller

Your responsibilities as the controller, including: providing lawful instructions to the processor, ensuring you have a legal basis for processing, and responding to data subject requests.

Processor Obligations

This is the core of the DPA. The processor must:

Process data only on your instructions and not use it for their own purposes
Ensure confidentiality by requiring staff to sign confidentiality agreements or be under statutory obligations
Implement appropriate security measures (encryption, access controls, incident response)
Not engage sub-processors without your authorization (either specific or general prior written authorization)
Assist with data subject requests (access, deletion, portability)
Delete or return data at the end of the contract
Allow and contribute to audits so you can verify compliance
Notify you of data breaches without undue delay

Sub-Processors

Most SaaS vendors use other companies to deliver their service: cloud hosting providers, CDN services, payment processors, analytics tools. Each of these is a sub-processor.

The DPA must specify whether the processor can engage sub-processors and under what conditions. Most vendors publish a sub-processor list that you should review. If a sub-processor is located outside the EU, additional transfer safeguards are required.

International Data Transfers

If your data leaves the EU/EEA, the DPA must specify the legal mechanism for the transfer: an adequacy decision, Standard Contractual Clauses (SCCs), or Binding Corporate Rules (BCRs).

This is where things get complicated with US vendors. A DPA with Mailchimp or HubSpot will reference the Data Privacy Framework or SCCs for EU-US transfers. European vendors processing data within the EU do not need these transfer mechanisms.

Where to Find Your Vendors' DPAs

Most SaaS companies publish their DPA in one of these locations:

Account settings: Some platforms (HubSpot, Mailchimp) let you review and accept the DPA directly in your account
Legal or trust page: Look for links labeled "DPA," "Data Processing Agreement," "GDPR," or "Privacy" in the website footer
On request: Some vendors require you to email their legal or privacy team to receive the DPA

If a vendor does not offer a DPA at all, that is a serious red flag. Under GDPR, you cannot use a processor without one.

What to Look For When Reviewing a DPA

Not all DPAs are created equal. Here is a practical checklist:

Data Location

Does the DPA specify where data is processed? Look for explicit statements about EU-only processing versus global or US processing. A DPA that says "data may be processed in any country where we have facilities" is weaker than one that guarantees EU-only processing.

Sub-Processor List

Is there a published list of sub-processors? Can you be notified when new sub-processors are added? Some DPAs give you the right to object to new sub-processors. Others only require notification.

Transfer Mechanisms

If data leaves the EU, which mechanism is used? The Data Privacy Framework, SCCs, or both? Remember that the DPF has been challenged and its predecessors were invalidated. SCCs require a Transfer Impact Assessment.

Breach Notification Timeline

GDPR requires processors to notify controllers "without undue delay." Some DPAs specify a timeframe (e.g., 72 hours). Others leave it vague. A specific timeframe is better.

Audit Rights

Can you audit the processor's compliance? Most DPAs include this right in principle, but the practical details vary. Some vendors offer third-party audit reports (SOC 2, ISO 27001) as an alternative to on-site audits.

Data Deletion

What happens to your data when the contract ends? The DPA should specify whether data is deleted or returned, and within what timeframe. Look for automatic deletion clauses versus "upon request" language.

DPA vs. Privacy Policy

These are different documents:

A Privacy Policy is a public document telling end users how a company handles their data. It is written for consumers.
A DPA is a contract between two businesses (controller and processor) governing data processing on behalf of the controller. It is written for business-to-business relationships.

You need both. Your own privacy policy tells your customers what you do with their data. Your DPA with each vendor ensures those vendors handle your customers' data according to GDPR requirements.

European Vendors Simplify DPA Compliance

When your vendor is a European company processing data within the EU, the DPA is simpler:

No international transfer clauses needed because data stays within EU jurisdiction
No Transfer Impact Assessment required (TIAs are only needed for transfers outside the EU)
No dependency on the Data Privacy Framework or SCCs
No CLOUD Act exposure because the company is not subject to US law

This is one of the practical advantages of choosing European marketing tools. The DPA review process is straightforward, and the compliance risk is structurally lower.

Browse European tools by category: CRM, Email Marketing, Marketing Automation, Web Analytics, or explore the full tool directory.

FAQ

Do I need a DPA with every SaaS tool I use?

If the tool processes personal data on your behalf, yes. This includes email marketing platforms, CRM systems, analytics tools, chat widgets, survey tools, and any other service that handles your customers' or users' personal data. Tools that only process anonymized or aggregated data (with no way to identify individuals) may not require a DPA, but this is rare.

What happens if I do not have a DPA with a processor?

You are in violation of GDPR Article 28. This can result in fines of up to EUR 10 million or 2% of annual global turnover (whichever is higher) under Article 83(4). Beyond fines, it also means you have no contractual protection if the processor mishandles your data.

Can a processor refuse to provide a DPA?

They can, but you should not use them if they do. A processor that refuses to provide a DPA either does not understand GDPR obligations or is unwilling to commit to them. Neither is acceptable for handling your customers' personal data.

Is a US vendor's DPA valid under GDPR?

Yes, a DPA with a US vendor can be valid if it includes appropriate transfer mechanisms (DPF participation, SCCs with TIA, or BCRs). However, the DPA does not override US law. The CLOUD Act still applies to the vendor regardless of what the DPA states. A DPA with a European vendor under EU jurisdiction provides stronger structural protection.