What Is a Data Processing Agreement? GDPR Article 28 Explained

If you run a website, SaaS product, or e-commerce store that handles personal data from the EU, you’ve likely encountered the term Data Processing Agreement — or DPA. It often shows up when you sign up for a service like Stripe, Mailchimp, or Google Analytics: “Please accept our DPA.”

But what exactly is a DPA, when do you need one, and what happens if you don’t have it? This guide breaks down GDPR Article 28 in plain language and shows you how to create a compliant DPA for free.

What Is a Data Processing Agreement (DPA)?

A Data Processing Agreement is a legally binding contract between a data controller and a data processor that governs how personal data is handled on the controller’s behalf.

Under GDPR Article 28(3), whenever a controller engages a processor to handle personal data — whether that’s hosting user data, sending emails, or running analytics — the relationship must be governed by a written agreement. That agreement is the DPA.

In practical terms, a DPA answers:

• What data is being processed, and for what purpose?
• How must the processor handle it (security, retention, sub-processors)?
• What happens if there’s a breach, and who notifies whom?
• When must data be deleted or returned?

Without a DPA, the processing relationship is non-compliant with GDPR — even if both parties act in good faith. The agreement itself is the compliance artifact.

Not to be confused with: A privacy policy (which faces your users) or a Data Processing Addendum (often the same as a DPA but attached as an addendum to a master service agreement). For most small businesses, “DPA” and “DPA addendum” are interchangeable.

Controller vs Processor: Who Is Who?

Understanding the two roles is essential — your obligations under a DPA depend entirely on which one you are.

Data Controller

The controller determines why and how personal data is processed. You are a controller if you decide:

• What personal data to collect (e.g., email addresses, names, payment details)
• Why you collect it (e.g., to deliver a newsletter, fulfill orders, provide a SaaS service)
• How long to keep it and who to share it with

Examples: A SaaS company storing user profiles, an e-commerce store handling customer orders, a blog owner collecting newsletter subscribers.

Data Processor

The processor handles personal data on behalf of the controller, following the controller’s instructions. A processor does not decide the purpose — it executes it.

Examples: Mailchimp sending your newsletters, Stripe processing your payments, AWS hosting your database, Google Analytics analyzing your traffic.

You Can Be Both

Many businesses are simultaneously a controller (for their own users’ data) and a processor (for their customers’ end-user data). A B2B SaaS that stores its customers’ client data is a classic dual-role example. In that case you need:

• A privacy policy for data you control (facing your users) — see our SaaS privacy policy guide
• A DPA for data you process on behalf of your customers (facing your business clients)

The controller-processor distinction maps directly to GDPR Articles 24–28, and getting it wrong is one of the most common compliance mistakes.

When Do You Need a DPA?

You need a DPA whenever you (controller) share personal data with a third party who processes it on your behalf — or when you (processor) handle personal data for a client.

Common scenarios that require a DPA:

Scenario	Controller	Processor	DPA Needed?
You use Mailchimp to send newsletters	You	Mailchimp	✅ Yes
You use Stripe for payments	You	Stripe	✅ Yes
You host on AWS / Vercel / Cloudflare	You	Hosting provider	✅ Yes
You use Google Analytics	You	Google	✅ Yes
A client hires your SaaS to manage their users’ data	Client	You	✅ Yes
You share data with a joint controller (co-deciding purpose)	Both	—	Different agreement*

* Joint controllers need a transparent arrangement under Article 26, not a standard Article 28 DPA.

You also need a DPA if you Sub-process: If your processor uses sub-processors (e.g., your email provider uses a cloud host), the DPA must address sub-processing — who the sub-processors are, how changes are notified, and your right to object.

Even if your vendor says “we’re GDPR compliant” on their marketing page, that claim is not a substitute for a signed DPA. Compliance is demonstrated through the agreement, not asserted on a homepage.

What a DPA Must Include: GDPR Article 28 Mandatory Clauses

GDPR Article 28(3) is prescriptive — a valid DPA must contain each of the following. An agreement missing any of these is incomplete.

1. Subject Matter, Duration, Nature, and Purpose

Define exactly what the processing covers:

• Subject matter — what service the processing relates to (e.g., “email delivery for newsletter subscribers”)
• Duration — how long processing lasts (e.g., term of the service agreement plus a deletion window)
• Nature and purpose — what operations are performed (collection, storage, transmission, analysis) and why

2. Types of Personal Data and Categories of Data Subjects

Specify:

• Data types — email addresses, names, IP addresses, payment tokens, etc.
• Data subject categories — subscribers, customers, end users, employees

Vague references like “personal data as provided by the controller” are technically allowed but weak — specificity helps both parties during audits.

3. Controller’s Instructions

The processor must only act on documented instructions from the controller. The DPA should state:

• Processing occurs solely per the controller’s instructions (including those in the service agreement)
• The processor must inform the controller immediately if an instruction violates GDPR

4. Confidentiality Obligations

Anyone authorized to process the data must be under a confidentiality obligation — contractual or statutory. This covers the processor’s employees and contractors with access to personal data.

5. Security Measures (Article 32)

The DPA must reference appropriate technical and organizational measures (TOMs), such as:

• Encryption at rest and in transit
• Access controls and authentication
• Pseudonymization where appropriate
• Regular security testing and evaluation
• Incident detection and response capability

A generic “we take security seriously” is insufficient. Name the measures or reference an annexure that does.

6. Sub-Processor Rules

The processor must:

• Not engage sub-processors without prior authorization (general or specific, as agreed)
• Inform the controller of any intended sub-processor changes, giving the controller a chance to object
• Flow down the same data protection obligations to each sub-processor by contract

7. Data Subject Rights Assistance

The processor must assist the controller in fulfilling data subject requests — access, rectification, erasure, restriction, portability, and objection — taking into account the nature of the processing and the information available to the processor.

8. Breach Notification Support

In a personal data breach, the processor must:

• Notify the controller without undue delay after becoming aware of the breach
• Provide information the controller needs to meet its own 72-hour notification duty to the supervisory authority (Article 33) and, where required, to data subjects (Article 34)

The DPA should define the notification channel and the minimum information the notice must contain.

9. Data Protection Impact Assessment (DPIA) and Consultation Assistance

The processor must assist the controller with DPIAs and prior consultations with supervisory authorities (Articles 35–36) where the processing is likely to result in high risk.

10. Deletion or Return of Data

At the end of the service, the processor must — at the controller’s choice — delete or return all personal data and delete existing copies, unless EU or Member State law requires retention.

11. Audit and Inspection Rights

The processor must make available all information necessary to demonstrate compliance and allow for and contribute to audits and inspections by the controller or an auditor mandated by the controller. This is often the most negotiated clause.

What Happens If You Don’t Have a DPA?

Operating without a required DPA has concrete consequences:

• Regulatory exposure. Supervisory authorities can treat the absence of a DPA as a standalone GDPR violation. Fines under Article 83(4) can reach €10 million or 2% of global annual turnover (whichever is higher) for Article 28 infringements. Even if no breach occurs, an audit that finds missing DPAs can trigger enforcement.
• Processor liability. Under GDPR, processors have direct obligations. Without a DPA, the boundary between controller and processor instructions blurs, and a processor that goes beyond its mandate may be treated as a controller — inheriting broader liability.
• Breach fallout. Without clear breach notification timelines and responsibilities, a real incident becomes chaotic: delayed notifications, incomplete reports to authorities, and extended regulatory scrutiny.
• Commercial risk. Enterprise customers, especially in the EU, routinely require a DPA before signing. No DPA can mean no deal. Many procurement checklists treat a missing DPA as a hard blocker.
• Data subject claims. If a data subject exercises a right (e.g., erasure) and the processor doesn’t cooperate because no DPA defines the workflow, the controller remains liable for the failure.

In short, a DPA is not paperwork for its own sake — it is the contract that allocates risk, defines cooperation, and proves compliance.

How to Generate a Free DPA in Minutes

Drafting a DPA from scratch or hiring a lawyer for a bespoke agreement can cost hundreds to thousands of euros. For most startups, creators, and small businesses, that’s disproportionate — especially when the required clauses are standardized by Article 28 itself.

Our free DPA generator creates a complete, Article 28–aligned Data Processing Agreement tailored to your setup:

1. Enter your details and your counterparty’s — company names, addresses, and roles (controller / processor).
2. Describe the processing — subject matter, duration, data types, and data subject categories. We guide you through each mandatory field so nothing is missed.
3. Review the generated DPA — all 11 mandatory clause groups are included with clear, editable language covering instructions, confidentiality, security, sub-processors, breach notification, DPIA support, deletion/return, and audit rights.
4. Export and sign — download as a legal-grade DOCX or PDF (Times New Roman, letterhead-ready) or as HTML/Markdown. The document is ready to attach to your service agreement or send for countersignature.

Like our privacy policy tools, the DPA generator is free forever, no signup, and entirely client-side — your inputs never leave your browser. Need a privacy policy to pair with it? Generate a privacy policy, cookie policy, or terms and conditions next.

GDPR compliance doesn’t have to be expensive or intimidating. The right agreement, generated correctly, covers you in minutes rather than months.

Generate your free Data Processing Agreement →

Related reading: Privacy Policy for SaaS Products · GDPR vs CCPA: Key Differences · Why Your Website Needs a Privacy Policy