What is a DPA and why is my enterprise customer demanding one?

What a DPA actually is

A DPA is a contract — usually an addendum bolted onto your main services agreement — that sets out the rules for handling personal data that belongs to your customer or their users. It says what you may do with that data, what safeguards you'll apply, who else can touch it, and what happens when the relationship ends.

It exists because of a specific legal requirement. Under GDPR Article 28(3), whenever one organisation processes personal data on behalf of another, that processing "shall be governed by a contract" that binds the processor and sets out a defined list of terms. Your customer isn't being difficult: without a signed DPA, they are in breach of the GDPR the moment they send you personal data. That's why it shows up as a hard gate in enterprise procurement.

The same requirement appears, with local wording, well beyond the EU — UK GDPR Article 28, and processor-contract obligations in laws such as Brazil's LGPD and several U.S. state privacy laws. If you sell to enterprises anywhere, you will be asked for one.

Controller vs processor: which one are you?

Everything in a DPA flows from a single distinction the GDPR draws:

• The controller decides why and how personal data is processed. In a SaaS deal, that's usually your customer — it's their data, their users, their purposes.
• The processor handles the data on the controller's instructions. That's usually you, the vendor.

So in the typical arrangement, your customer is the controller and you are the processor. The DPA is the controller telling the processor, in writing, exactly how the data must be handled. That's why the obligations run mostly one direction: they land on you.

The line isn't always clean. For data about your own business contacts, your billing records, or your marketing lists, you are the controller. And where you engage another vendor to help deliver the service, that vendor becomes your sub-processor — more on that below. Getting these roles right is the foundation; a DPA that mislabels who's who creates problems everywhere else.

What's actually negotiable (and what isn't)

Most of a DPA is not up for debate, because it restates the statute. Pushing back on the Article 28(3)(a)–(h) obligations mostly signals you haven't read them. What genuinely gets negotiated is a shorter list:

If you offer a standard DPA that already tracks Article 28, most enterprise customers will accept it with edits only to the negotiable column. That's the fast path.

The required processor obligations: Article 28(3)(a)–(h)

This is the heart of the DPA. Article 28(3) says the contract must, in particular, stipulate that the processor:

1. (a) Documented instructions. Processes the personal data only on the controller's documented instructions, including for any transfer to a third country — unless required to act otherwise by EU or Member State law.
2. (b) Confidentiality. Ensures that people authorised to process the data are bound by confidentiality (by contract or statutory duty).
3. (c) Security. Takes all security measures required under Article 32 — appropriate technical and organisational measures to protect the data.
4. (d) Sub-processors. Respects the conditions in Article 28(2) and (4) before engaging another processor (the sub-processor rules, below).
5. (e) Assist with data-subject requests. Helps the controller respond to requests from individuals exercising their rights (access, deletion, portability, etc.), by appropriate technical and organisational measures, so far as possible.
6. (f) Assist with compliance. Helps the controller meet its obligations under Articles 32–36 — security, breach notification, data protection impact assessments, and prior consultation — taking into account the nature of processing and the information available.
7. (g) Delete or return. At the controller's choice, deletes or returns all the personal data at the end of the services, and deletes existing copies, unless law requires storage.
8. (h) Demonstrate compliance and allow audits. Makes available all information needed to show compliance with Article 28, and allows for and contributes to audits and inspections by the controller or its mandated auditor.

When your customer's questionnaire or DPA asks about breach notification timelines, DSAR support, encryption, or deletion-on-termination, they are checking these eight items. A good DPA maps to them one-for-one.

Sub-processor clauses: Article 28(2) and 28(4)

A sub-processor is any third party you bring in to help process the customer's data — your hosting provider, email-delivery vendor, or analytics tool. The GDPR governs this in two places:

Article 28(2) — authorisation. You can't engage a sub-processor without the controller's prior authorisation, which can be specific (named up front) or general. Where general authorisation is used — the practical default in SaaS — you must "inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object."

Article 28(4) — flow-down and liability. When you engage a sub-processor, you must impose on it, by contract, "the same data protection obligations as set out" in your DPA with the controller. And critically: where the sub-processor fails, you remain fully liable to the controller for its performance. You can't outsource the risk, only the work.

In practice this means you maintain a published sub-processor list, flow your DPA terms down to each vendor, and notify customers before adding or replacing one.

The prior-notice objection pattern for new sub-processors

Article 28(2) requires the opportunity to object but sets no fixed notice period — the number comes from your DPA, not the statute. The market has settled on a short advance-notice window, commonly framed as around 14 to 30 days, during which the customer may object to a new sub-processor on reasonable data-protection grounds. If they object and you can't accommodate it, the customer typically gets a right to terminate the affected part of the service.

The mechanics of getting this right — when the obligation triggers, what the notice must contain, and a ready-to-send email — are covered in detail in our sub-processor change notification template. If you're being asked for a DPA, you'll need that notification process too; the two go together.

What to do when a customer demands one

1. Confirm your role. In almost all SaaS deals you're the processor and they're the controller. Get this right before you touch the terms.
2. Offer your own standard DPA if you have one. A DPA that already tracks Article 28(3)(a)–(h) is the fastest route through legal review — see our own DPA for the shape of one.
3. Know your sub-processors. Have a current list and a notification process ready before you sign, because 28(4) makes them your responsibility.
4. Negotiate only the negotiable column. Liability, audit mechanics, notice period, transfer mechanism. Leave the statutory obligations alone.
5. Don't over-commit. Never agree to a breach-notification timeline or audit cadence you can't actually meet — the DPA is enforceable.

How Privacy Automated helps

Privacy Automated keeps the pieces a DPA depends on in one place: your controller/processor determinations, your live sub-processor list, and the notification workflow for adding a new one. When a customer asks for a DPA or sends a questionnaire, you're answering from a maintained record rather than reconstructing it under deadline. See the product tour for how it fits together.