What Is a Data Processing Agreement (DPA) — and Why Your SaaS Needs One

At some point a deal you thought was done stops moving. The product fit was there, the pricing was agreed, and then their legal or security team sends back one line: "We'll need your DPA before we can sign." If you've never dealt with one, that sentence can feel like a wall. It isn't. A Data Processing Agreement is a standard, well-defined contract, and for most SaaS products it's a document you should already have ready to hand over rather than something you scramble to produce mid-deal.

This is the practical version, written for the founder or engineer who has to understand the thing rather than draft it from scratch. It covers what a DPA actually is, why GDPR requires one, what has to be inside it, the two directions you'll deal with it from (signing one and requesting one), and how to stop it from becoming a bottleneck in your sales cycle. None of it is legal advice, but all of it is the context that makes the legal advice quick and cheap.

What a DPA actually is

A Data Processing Agreement is a contract between two parties: the one that decides what happens to personal data, and the one that handles that data on the first party's behalf. In GDPR's language those are the data controller and the data processor. The DPA is the document that pins down, in writing, exactly what the processor is allowed to do with the data, what it must protect, and what happens when the relationship ends. You'll also see it called a Data Processing Addendum — AWS, Google, and Microsoft all use that name — but it's the same instrument.

That's the whole idea. It isn't a privacy policy (that's the promise you make to your users), and it isn't your terms of service (that's the commercial relationship). A DPA sits underneath both and governs one specific thing: how personal data moves between two companies when one is processing it for the other.

The reason it exists at all is accountability. GDPR makes the controller responsible for personal data across its entire lifecycle, including every company it hands that data to. Since a controller can't personally supervise how its vendors run their servers, the DPA is the mechanism that carries the obligations down the chain in writing. It turns "we trust our host to be careful" into "our host is contractually bound to specific, enforceable requirements."

Why GDPR makes it mandatory, not optional

The requirement isn't a best practice someone recommends. It's written into the regulation. Article 28 of the GDPR states that whenever a controller uses a processor, the processing must be governed by a contract that sets out the subject matter, duration, nature and purpose of the processing, the type of personal data, the categories of people it belongs to, and the obligations of both sides.

Read that plainly: if a company processes personal data on your behalf and there's no DPA, you (the controller) are not compliant. The gap isn't the processor's problem to fix on their own — the accountability lands on you. This is why the customer's legal team asks for yours before they sign. By buying your SaaS and feeding it their users' data, they're making you their processor, and their own compliance depends on having that contract in place with you.

The same logic runs in the other direction. Every third-party service you use to run your product — your hosting provider, your database, your email sender, your analytics — is your processor, and you need a DPA with each of them. Article 28 doesn't care about company size or deal value. A two-person startup handling EU personal data has the same baseline obligation as an enterprise.

The exception is narrow: if a service never touches personal data, or only handles data you've fully anonymised so no individual can be re-identified, there's no processing of personal data and no DPA to sign. That's a smaller set than people hope. Pseudonymised data — hashed emails, user IDs — still counts as personal data under GDPR, so it doesn't get you off the hook.

What happens if you skip it? Missing DPAs are a documentation failure regulators look for first, because they're trivial to check, and non-compliance with Article 28 falls under the higher tier of GDPR fines — up to €20 million or 4% of global annual turnover. For most small teams the fine is the distant risk; the immediate one is the deal that stalls when a buyer's security review asks for a document you don't have.

Controller or processor? For a SaaS, usually both

The single most common source of confusion is thinking you're only ever one of these. In practice a typical SaaS company wears both hats at once, and which one applies depends on whose data you're looking at.

For your customers' data — the records their users create inside your app — your customer is the controller and you are the processor. They decide why the data exists and what happens to it; you just operate the software that stores and processes it. In this relationship, you provide the DPA and they sign it.

For your own operational data — your customers' account details, your billing records, your marketing contacts — you are the controller. And every vendor you use to handle that data is your processor. In this relationship, you request and sign their DPAs.

So a healthy SaaS ends up with two stacks of paper: the DPA you hand to customers as their processor, and the DPAs you've collected from your own vendors as a controller. Getting the roles straight is what makes the rest of this manageable, because the duties, and who drafts the document, flip depending on which side you're on.

What has to be inside a DPA

You don't need to draft one from memory, but you should recognise the parts, because a DPA that's missing them isn't doing its job. Article 28(3) lays out the required content, and a solid agreement covers each of these:

• Scope and purpose — what personal data is processed, what categories of people it belongs to, and why. The processor may only act on the controller's documented instructions.
• Duration — how long the processing lasts, and what happens to the data at the end: return it or delete it, at the controller's choice.
• Confidentiality — everyone who touches the data is bound to keep it confidential.
• Security measures — the technical and organisational safeguards protecting the data, such as encryption, access control, and backups.
• Subprocessors — the rules for the processor using its own vendors, including your right to know who they are and to object.
• Assistance and audits — the processor must help the controller answer user-rights requests and demonstrate compliance, and allow audits.
• Breach notification — the processor must tell the controller about a data breach without undue delay so the controller can meet its own reporting deadlines.

Most reputable providers publish a standard DPA that already covers all of this. Your job is usually to read it, confirm it matches how you actually operate, and sign — not to write one clause by clause.

The subprocessor chain

Subprocessors deserve their own moment, because they're where a clean-looking compliance story springs a leak. A subprocessor is a processor's own processor: a vendor your vendor relies on. When you use a hosting platform that in turn runs on someone else's underlying cloud, that underlying cloud is your subprocessor, one step removed.

This matters for two reasons. First, the chain doesn't dilute your accountability. As the controller, you remain responsible for personal data no matter how many layers down it travels, so a subprocessor in a jurisdiction you didn't expect is still your problem. Second, it's a common way EU data ends up leaving the EU: your provider is European, but one of its subprocessors runs in the US, and now your data is subject to a transfer you never signed off on. And disclosure alone doesn't make that transfer lawful. Once personal data leaves the EU, GDPR's Chapter V kicks in and the transfer needs its own legal basis — an adequacy decision or Standard Contractual Clauses. The DPA's subprocessor clause tells you the transfer is happening; it's the transfer mechanism that makes it legal. Two separate boxes to tick, and it's easy to assume the first one covers the second.

A good DPA gives you visibility and a say here: a published list of subprocessors, advance notice before a new one is added, and the right to object. When you're evaluating a provider, the subprocessor list is one of the more revealing documents you can read — it tells you where your data really goes, not just where the marketing page says it's hosted. This is also why an EU-native stack, where the provider and its subprocessors are all inside the EU, is simpler to reason about than a global platform with an EU region bolted on.

Why the DPA shouldn't cost you a sales call

Here's the part that trips up smaller teams. On plenty of developer platforms the DPA technically exists, but it's gated: available only on an enterprise plan, or behind a "contact sales" form, or as a manual request that takes a week to fulfil. For a solo founder or a small team, that turns a routine legal necessity into a procurement obstacle. Worse, plenty of people ship without one simply because getting it was too much friction, which leaves them non-compliant without realising it.

That's the wrong default, and it's worth naming as a signal when you choose infrastructure. A DPA costs a provider essentially nothing to include — it's a standard document — and every customer processing EU personal data needs one. Gating it behind a sales tier doesn't reflect a real cost; it reflects a choice to treat compliance as an upsell. The better model is simple: the DPA is part of the account from day one, downloadable and signed without a conversation.

That's how Runsite handles it. A signed GDPR Data Processing Agreement is included on every plan — no upgrade, no negotiation, no sales call — and the whole stack runs in Frankfurt, Germany, so the subprocessor question has a short answer too. When a customer's security review asks for your DPA, you're forwarding a document you already have, not opening a two-week detour. If you want the wider picture of what that involves, our guide to EU hosting, data residency, and GDPR for developers covers the surrounding ground.

A DPA checklist for your SaaS, both directions

The whole topic gets lighter once you treat it as two short checklists rather than a legal ordeal.

As a processor (handing your DPA to customers): have a standard DPA ready before anyone asks. Publish it or keep it one click away, make sure it reflects how you actually process data, and keep your own subprocessor list current so you can answer follow-up questions without a fire drill.

As a controller (collecting DPAs from your vendors): when you add a service that will touch personal data, get its DPA signed as part of onboarding, not months later. Keep the signed copies somewhere you can find them during an audit or a customer review, and glance at each vendor's subprocessor list so you know where the data actually flows.

Do that and the request that once stalled a deal becomes a two-minute reply. The compliance was already in place; you just needed the paperwork to prove it.

The short version

A Data Processing Agreement is the contract that makes it legal for one company to process personal data on another's behalf. GDPR's Article 28 makes it mandatory whenever a controller uses a processor, which means your customers need one from you, and you need one from every vendor that touches personal data. A typical SaaS is a controller and a processor at the same time, so you'll deal with DPAs from both directions. Watch the subprocessor chain, because that's where accountability and data residency tend to slip. And treat a provider that hides its DPA behind a sales call as a warning sign: the document is standard, every customer needs it, and it should come with the account by default. Build on infrastructure that includes a GDPR DPA on every plan and the next time legal asks, the answer is already signed.