Data Processing Agreement

No company handles personal data entirely on its own. An email vendor sends the mail, a support agency answers the tickets, a payment provider runs the charges. Handing over that work means handing over a list of people, and from that moment user data sits outside your own servers.

The gap only became visible after incidents. An account at the agency gets compromised, a hundred thousand email addresses leak, and the two companies look at each other. The company that outsourced says it only passed the data along. The company that received it says it only did what it was told. Open the contract and there's a single line about performing the services diligently — nothing about which fields were transferred, nothing about who has to raise the alarm. The users don't even know their data was at that vendor, or which company to complain to.

Regulation filled that gap with a contract requirement. When a data controller — the party that decided the purpose — hands processing to someone else, what is being handed over and what happens after an incident has to be written down. Responsibility toward the user stays with the party that outsourced. So this agreement is not a document that transfers accountability; it's the document that makes the accountability manageable.

Most of these agreements carry eight items. The order varies between templates, but the ones that cause trouble when missing are consistent.

1. Scope and purpose of the outsourced work. This bounds the job. An email vendor sends email; it does not market to your list on its own behalf.
2. The fields being transferred. Email address only, or name and phone number too. Anything not listed here can't be sent.
3. Retention and deletion. How long the receiving side keeps the data and how it destroys it. Line the retention period up with your own or the two sets of records drift apart.
4. Limits on sub-processing. The receiving side passing part of the work to yet another company — a support agency handing overnight coverage to someone else. Either they ask for approval in advance, or at minimum they publish the list.
5. Security measures. Store it encrypted, restrict access to named staff, keep access logs — the concrete standard the receiving side commits to.
6. Incident notification. The number of hours within which they must tell you after discovering a leak. Your own regulatory deadline runs separately and often starts at 72 hours from awareness, so a day lost waiting on the vendor is a day taken out of your own window.
7. Audit rights. Your right to check that any of this is actually happening, whether by requesting documentation or by inspecting on site.
8. What happens at termination. The data comes back or gets destroyed, with evidence that it was destroyed.

The party receiving the data usually writes it. A company sitting in the data processor seat can't review a different contract for every customer, so it publishes one standard version — that DPA link in the footer of a SaaS site. Large enterprise customers reverse this and arrive with their own template. Then the two documents go side by side and only the clauses that differ get negotiated. Liability caps and audit rights are where that negotiation usually settles, because both sides are trading the same thing: how much of an incident each one absorbs.

Three groups read it.

1. The customer's legal team. They look at sub-processing, the notification window, and the liability cap. The clause that blocks a deal usually comes from here.
2. Sales on the selling side. The document lands at the very end of a deal, which puts revenue behind it. Without a standard version, reviews add two weeks.
3. Whoever owns the product. The sub-processor list in the contract has to match the outside tools the product actually uses, and the person who can reconcile those two lists is rarely in legal. Only the person who added a tool knows what flows into it.

It also connects to the privacy policy, which has to disclose who you entrust data to. Sign with a new vendor and the list in that policy changes with it.

"Commercial terms are agreed, we're just waiting on the DPA. Do you have a standard one?"

Two weeks of schedule hinge on whether that document already exists.

"The error tracker we added needs to go on the sub-processor list."

The tools in use and the tools on paper have drifted apart.

"We can't hold a 24-hour notification window. Make it 72."

A refusal to sign a number the team can't actually meet.

Pagedeck lost three weeks to this document on its first enterprise deal. Sofia had finished negotiating terms when the customer's legal team asked for a DPA, and Pagedeck didn't have one. The deal sat still while Grace put one together from scratch, clause by clause, with the customer's template as the only reference.

They reversed the order afterward. The standard version now lives on the site and goes out during the proposal stage. That added one thing to maintain: the sub-processor list. When Theo connects a new error tracking tool, that tool sees user data, so it belongs on the list — and a change to the list has to be announced to existing customers. So adding an outside tool now runs as one bundle with a vendor assessment and a list update.

It's easy to file this under work that legal takes care of. It looks like a contract, the clause language is unfamiliar, and nothing about it seems to need product or engineering. But what goes wrong in these agreements is rarely the legal language — it's the facts. Which fields get transferred, which sub-vendors are in the chain, which country the servers sit in: only people who know the code and the infrastructure can answer those.

Left unchecked, what was signed and what actually runs drift apart. The contract names three sub-processors while six are in use, and that gap normally surfaces during a customer's security review or an incident investigation. At that point it isn't a missing line item. It's a breach of contract, and the customer who found it is the one deciding what happens next.