What a Data Processing Agreement Should Say Before You Sign It

A vendor sends over a data processing agreement as a PDF, twelve pages long, with a note saying it is their standard terms and that everybody signs it. Someone forwards it to you with the subject line “fine?”. It is not fine yet. But you can find out whether it is in about twenty minutes, because only six clauses in the whole document decide anything.

The rest is definitions, cross-references and a schedule that restates the definitions in a different font. The six that carry weight are sub-processors, location, retention, deletion, breach notification and audit rights. Read those first, in that order, and you will know what the agreement actually gives you and what it quietly withholds.

None of this is legal advice, and the final version of anything you sign should be read by a lawyer. But the person best placed to spot the real problems in a data processing agreement is usually whoever knows where the data goes, and that is rarely the lawyer. If you have already done the work a technical discovery produces, you already hold most of the facts you need to test the vendor’s wording against.

Why the data processing agreement is the document that matters

A vendor contract has a commercial half and a data half. People read the commercial half closely, because price, term and notice period are legible and everyone has an opinion about money. The data half sets out what happens to records about your customers while they sit on somebody else’s infrastructure, and it usually gets a glance and a signature.

Article 28 of the General Data Protection Regulation is the text to keep open while you read. It requires that a processor acts only on documented instructions, and that the arrangement is set out in a binding written contract. That contract is the DPA. It is not a courtesy attachment. It is the instrument that makes the relationship lawful in the first place, which is why a vague one is a problem rather than a preference.

Two words do all the work. The controller decides why and how personal data is processed. The processor processes it on the controller’s behalf and may not invent new purposes for it. Most disputes start with a vendor behaving like a controller while holding a processor’s contract: using your records to train a model, to build a benchmark, or to produce an insight they then sell back to you.

So read the purpose clause with that distinction in hand. If the agreement grants the vendor any right to use your data for “product improvement”, “aggregated analytics” or “research”, that is a controller activity wearing processor clothing, and it belongs in a separate, named, opt-in paragraph or nowhere. Our own data processing page exists for the same reason: the list of who touches what should be publishable without embarrassment.

Sub-processors: the clause most agreements under-write

A sub-processor is anyone your vendor hands the data to in order to do their job. The hosting provider. The email delivery service. The error tracker that receives a stack trace with a customer identifier in it. The support desk. The overnight team on another continent that answers tickets while your office is closed. This clause decides how far your data travels, and it is routinely the thinnest part of the document.

What a usable sub-processor clause says

• A current list you can read without asking. A published page or a dated appendix, not “available on request”. A list you have to request is a list that goes stale between requests.
• Notice before a new one is appointed. Notice given after the change has happened is not notice. It is a changelog.
• A right to object that ends in something. An objection right whose only outcome is the vendor saying no is decoration. It has to end in a workaround or in exit without penalty.
• Flow-down obligations. The sub-processor is bound to terms at least as strict as the vendor’s, and the vendor stays liable to you for their failures.
• A named purpose for each entry. “Infrastructure” is not a purpose. “Object storage for uploaded files, Frankfurt” is a purpose, and it tells you where to look when something goes wrong.

What to push back on

Blanket consent is the pattern to refuse. Wording that has you agreeing in advance to any sub-processor the vendor may ever appoint, with notice deemed given by updating a web page you are expected to monitor, converts a control into a formality. Ask instead for notification by email to a named role on your side. Vendors who process data for a living already have that switch built; the ones who resist usually have not thought about it.

The same reasoning applies inside your own product. Every integration you add is a sub-processor decision made by an engineer at speed, which is why automations and integrations deserve a register of their own. And it applies to code you did not write running on pages you own, which we have covered separately in how you secure a website you did not build. The third-party script problem and the sub-processor problem are the same problem at two different layers.

Where the data physically sits, and who can read it

There are two questions here, and vendors habitually answer only the first. Where is the data stored, and where is it accessed from? A record can live in an EU region for its entire life and still be read every night by a support engineer sitting somewhere else. Under the regulation, that access is a transfer, and it needs the same treatment as a copy.

Ask for both answers in writing, per environment. Production, backups, logs and the support tooling are four different places, and they are frequently in four different jurisdictions with four different answers. Backups are the ones people forget. A database pinned to one region with snapshots replicated to another is a transfer nobody wrote down, and it will surface during an incident rather than during procurement.

Retention and deletion are two different promises

They read like one clause and they are two. Retention governs how long the vendor keeps data while the contract is alive. Deletion governs what happens once it ends. Agreements are often precise about the first and vague about the second, and that combination is the common one because the second only ever costs the vendor money.

The three things to insist on

Insist on three things. A deadline expressed in days rather than “promptly”. A sentence covering backups, because deleting from live systems quickly while backups roll off over a longer window is a perfectly legitimate answer once it is written down and unacceptable when it is left implied. And written confirmation of deletion on request, which costs the vendor almost nothing and gives you something to put in a file.

Watch the phrase “except where required by law”. It is legitimate. Tax rules and litigation holds are real, and no vendor can contract out of them. It becomes a problem when it stands unqualified, because unqualified it can be read to cover anything the vendor later decides it would rather keep. Ask for the exception to name a category and a period. Vendors who have thought about retention can do this in one line.

Your own house counts too. A vendor deleting on schedule does nothing for you if your team keeps CSV exports on a shared drive indefinitely, or if a reporting tool holds a mirror of the same records under a different name. This is the same discipline that decides whether you can migrate ten years of pages without losing the archive: knowing what you hold, where it sits, and why it is still there.

Breach notification: the trigger, the clock and the contents

Three moving parts, and negotiations usually argue about only one of them. The clock gets all the attention. The trigger decides when the clock starts, and it is worth more.

“Upon confirmation of a breach” can absorb an entire internal investigation before anyone owes you a word. “Upon becoming aware of a security incident affecting controller data” starts the count far earlier and covers the ambiguous cases, which are most cases in the first day. Changing that phrase is worth more to you than shaving hours off the notification window.

The clock should be a number of hours, stated as a number. “Without undue delay” on its own is not a number. You need an early figure because your own obligation as controller begins when you become aware, and you cannot report what nobody has told you. A vendor whose notice period runs longer than your own reporting duty has handed you a deadline you cannot meet.

The contents matter as much as the timing. A message saying “we experienced a security incident” helps nobody. Specify what a notice must contain: which categories of data, the approximate scope, what is known and what is not yet known, what has been contained, and a named contact who can take a follow-up question. Then decide separately what you will tell your own customers, which is a writing problem before it is a technical one, and which we have written about in what to say while you still do not know.

It is also worth remembering how ordinary most incidents are. Credential stuffing against a login form, an abandoned plugin, an automated scan that finds an exposed endpoint: none of it is targeted, and all of it is constant. If that surprises you, stopping abuse without blocking buyers covers the everyday version of the problem, which is the version your vendor is far more likely to notify you about.

Audit rights you would actually use

This is where standard contracts and reality diverge most. Almost every DPA grants a right to audit. Almost no small controller ever exercises it, and most vendors would be genuinely disrupted if even a fraction of their customers tried. So the clause sits there, unexercised and therefore untested, doing no work at all.

The tiered version that works

The practical version is tiered. First tier: the vendor supplies its current third-party report on request, under confidentiality, without a negotiation each time. Second tier: a written security questionnaire once a year, answered by a named person who can be held to the answers. Third tier: a remote or on-site audit with reasonable notice, at your cost, available when there has been a breach or a material change. Three tiers you would use beat one tier you never will.

What comes back at the first tier is a report, and reports vary enormously. A finding with no severity, no affected asset and no recommended fix is an observation, not a finding. Tooling that resolves raw findings into severities, priorities and reviewable reports, such as Prooflin, exists because the gap between “we ran a scan” and “here is what to do about it” is where most security reporting quietly dies.

Our parent company has written directly about both halves of that: how to read an audit you were sold and the anatomy of a finding. Both are useful before you accept a vendor’s report as evidence of anything.

A clause you would never exercise is not a protection. It is a sentence that makes both sides feel better about signing.

What is genuinely standard, and what only looks it

Some clauses track the regulation closely and arguing about them burns goodwill you will want later, when you are asking for something that matters. Others look boilerplate and are not. This is the split we work to.

The security annex is the row that gets missed. An annex the vendor may amend at its own discretion is a description of today rather than a commitment for the term. Ask for a single sentence preventing a material reduction of the stated measures while the contract runs. It is a small ask and it converts a brochure into an obligation.

How to read one in twenty minutes

Here is the sequence we use. It is deliberately not the order the document is written in, because the order the document is written in is designed to be read from the front and abandoned around page four.

1. Confirm the roles. You are the controller, the vendor is the processor, for every category of data you care about. If the vendor claims controller status anywhere, stop and read that passage twice.
2. Read the sub-processor annex before the body. The list tells you more about the real architecture than the security section ever will.
3. Search the document for “transfer”. Then ask about access separately, because the transfer clause will describe storage and stop there.
4. Find the deletion deadline. If there is no number attached to it, that is your first redline, and it is usually accepted without argument.
5. Find the breach trigger, not the breach clock. Read what the vendor must know, and how certain they must be, before anything starts counting.
6. Check whether the security annex can move. A unilateral amendment right turns every control listed in it into a statement of current intent.
7. Read the liability cap last, against everything above it. A cap set at a small fraction of the annual fee makes every obligation you just negotiated advisory.

Where we would start, and where we would not bother

The decision rule is short. Negotiate the clauses you would need on your worst day, and accept the rest without ceremony. The worst day is a breach at a sub-processor you did not know existed, in a country you did not expect, discovered by somebody outside your organisation. Every clause worth an argument sits on that path. Everything else is drafting.

The honest concession: proportionality is real, and this whole exercise is overkill for some suppliers. A scheduling widget that never touches a customer record does not need a tiered audit right. A tool that holds your entire contact database does. Spend the effort where the data is rather than spreading it evenly across a supplier list, because effort spread evenly is effort nobody notices missing.

One more thing that gets skipped. Diary the review. A DPA is signed once and then governs a relationship that changes constantly: new features, new regions, new sub-processors, a support model that moved. Re-read the sub-processor list once a year against what the vendor publishes now. That single habit catches more drift than any clause you could have negotiated at the start.

And if the vendor in question runs part of your site rather than sitting off to one side of it, the same questions belong in the maintenance arrangement, where access is continuous rather than occasional. If you have an agreement in front of you and want a second read on the stack it describes, tell us what you are being asked to sign.