The data processing addendum, decoded.
A DPA governs how a software vendor handles personal data on your behalf, and the vendor's standard version is written to protect the vendor. This note sets out the nine clauses a buyer-grade DPA must contain, the standards to hold each to, and how the addendum binds to the master agreement.
A data processing addendum is a risk-allocation document, not a click-through annex. A buyer-grade DPA fixes a breach notice at 72 hours from discovery, names and gates every sub-processor, binds cross-border transfers to standard contractual clauses, and carves data-breach liability out of the general cap. Every one of those defaults is negotiable — and a vendor's willingness to move on them reads how seriously it takes the data it is about to hold.
01 Key findings
The standard DPA is drafted to protect the vendor. It offers a vague breach obligation, an open-ended right to add sub-processors, and an audit clause limited to self-certification. Each default shifts risk onto the customer, and each is movable.
The controller carries primary liability, so the DPA is the customer's lever. The customer is usually the data controller and the vendor the processor; the DPA is the instrument that pushes defined obligations and liability back onto the party that actually holds the data.
Breach notice and the liability carve-out are the two clauses vendors fight hardest. "Without undue delay" preserves room to miss the customer's own 72-hour regulatory deadline; breach liability left inside the general cap can leave the customer absorbing a multi-million incident under a cap set for ordinary disputes.
Sub-processors and transfers are where control silently leaks. A named list with a genuine right to object, plus standard contractual clauses for any transfer to a non-adequate jurisdiction, converts an open-ended data-sharing right into a controlled one.
AI services break the traditional template. Model training, prompt and output retention, and IP ownership all need explicit terms a legacy DPA never contemplated.
02 The nine-clause checklist
A buyer-protective DPA covers nine areas, and the standard to hold each to is specific — not "reasonable," but named and testable. Use this as the pre-signature checklist; each row corrects a common vendor default.
| Clause | Buyer standard | Common vendor default |
|---|---|---|
| Scope & instructions | Processing limited to documented purposes only | Broad, self-defined processing rights |
| Breach notification | Notice within 72 hours of discovery, no materiality filter | "Without undue delay," clock at confirmation |
| Sub-processors | Named list, prior notice of additions, right to object | Open-ended additions, notice on a web page |
| Audit rights | On-site audit or a recognised third-party report | Self-certification only |
| Location & transfer | Named regions, SCCs for cross-border transfers | Silent on where data sits |
| Security measures | Specified technical and organisational controls | Vague "reasonable" security |
| Return & deletion | Certified deletion within a fixed window at termination | Indefinite retention, no certification |
| Assistance | Support for data-subject requests and impact assessments | No committed cooperation |
| Liability | Data-breach liability carved out of the general cap | Breach liability inside the ordinary cap |
03 Controller vs processor
Under modern data-protection law the customer is usually the data controller — deciding why and how personal data is processed — and the vendor is the processor, acting on the controller's documented instructions. The DPA is the instrument that records those instructions and binds the processor to them.
The distinction matters because the controller carries primary legal liability to data subjects and regulators. The DPA is therefore the customer's mechanism for pushing defined obligations and liability back onto the vendor that actually holds the data. A DPA that leaves the roles vague leaves the customer exposed.
04 The 72-hour breach standard
The breach-notification clause is the one that gets tested in a crisis, and the difference between a fixed window and a vague one is measured in regulatory exposure. Major data-protection regimes require the controller to notify regulators within 72 hours of becoming aware of a breach. If the processor's obligation is looser, the customer can breach its own deadline through no fault of its own — simply because the vendor took a week to report.
The DPA must pass the regulatory clock through to the processor: notice within 72 hours of the vendor's discovery, with enough detail for the customer to assess and report. Watch for two dilutions.
A materiality filter lets the vendor decide a breach is too minor to report — but the customer, not the vendor, should make that call. A clock that starts at "confirmation" rather than "discovery" lets the vendor extend the timeline by slow-walking its internal investigation. Both belong to the same category of risk-shifting terms covered in our contract red flags guide.
05 Sub-processors & cross-border transfers
Where personal data crosses a border, the DPA must name a lawful transfer mechanism, because most regimes prohibit sending personal data to a jurisdiction without adequate protection unless a recognised safeguard is in place. The standard safeguards are standard contractual clauses (SCCs), an adequacy determination for the destination country, or an approved certification framework. The practical requirement is two-fold: name the regions where data is stored and processed, and incorporate SCCs for any transfer to a non-adequate jurisdiction, with the vendor committing to the supplementary measures those clauses require.
The default DPA reserves the right to add sub-processors at will, with notice buried in a web page the customer never checks. Require a named sub-processor list in the DPA itself, written notice of any addition, and a genuine right to object that pauses onboarding of the new sub-processor while the objection is resolved. This single change converts an open-ended data-sharing right into a controlled one — and surfaces exactly which fourth parties touch your data before they start touching it.
06 DPAs in the AI era
AI vendors raise data questions a traditional DPA was not written for: whether customer data is used to train models, whether prompts and outputs are retained, and who owns the generated content. A DPA for an AI service must add explicit terms — that customer data will not be used for model training without consent, that inputs and outputs are not retained beyond the service need, and that the customer retains rights in its data and the outputs.
These issues sit at the intersection of data protection and intellectual property, and for AI services processing often happens across multiple regions, so the transfer terms above intersect directly with data residency. They are covered in depth in our guides to AI data residency and IP rights and AI audit rights.
07 Review framework
Four questions frame every DPA review. Weight them to the sensitivity of the data before deciding how hard to push — and whether to sign at all.
Data sensitivity
Highly sensitive or regulated personal data raises the stakes on every clause and lowers the threshold for walking away. Routine, low-sensitivity data tolerates more compromise.
Breach & liability exposure
Confirm the 72-hour window from discovery and that data-breach liability is carved out of the general cap. These are the two terms vendors resist hardest and the two that decide incident cost.
Data flow & sub-processors
Know where the data sits, which fourth parties touch it, and that any cross-border transfer carries SCCs. A named list with a right to object keeps the flow controlled.
Enforceability & survival
An audit right must permit an on-site inspection or a recognised third-party report. Return, deletion, and liability terms must survive termination, or they protect nothing after the service ends.
08 Our recommendation
For low-sensitivity data, hold the vendor to the checklist but accept reasonable compromise. Prioritise the fixed breach window and the sub-processor right to object; treat the rest as negotiable clean-up.
Where the data is sensitive, insist on all nine standards, force the liability carve-out, and name every region and sub-processor. A vendor that refuses is telling you how it will behave in an incident.
Beyond the nine clauses, bar training on your data without consent, cap prompt and output retention, and confirm you own the outputs. Verify residency across every region the model touches.
09 Binding, survival & when to walk
A DPA is only as strong as its link to the master agreement and its survival terms. The addendum should be incorporated by reference, take precedence over the master agreement on data matters, and survive termination so that return-and-deletion and liability obligations continue to bind after the service ends. A DPA that expires with the service leaves the customer with no recourse for data the vendor still holds during wind-down.
Most negotiations end in a workable compromise, but a small number of vendor positions justify walking away: a refusal of any fixed breach window, an unrestricted right to add sub-processors, or a decline to carve data-breach liability out of a low general cap. For sensitive data, an unacceptable DPA is a reason to choose a different vendor — the regulatory and reputational exposure of a mishandled breach dwarfs the convenience of the preferred product.
Make the DPA a buyer protection
Our vendor negotiation practice runs the nine-clause checklist on every data-bearing agreement, alongside the commercial terms.
The Licensing Edge
Weekly vendor and licensing intelligence for enterprise IT leaders. 3,000+ subscribers.