A Data Processing Agreement (DPA) is the contract that governs how a vendor handles personal data on your behalf. Under UK GDPR and EU GDPR, you must have one in place with any vendor that processes personal data for you. There’s no exception for small contracts, free trials, or pilot deployments.
Most DPAs you’ll see are templates. The vendor’s template, the customer’s template, or the IAPP’s template — all roughly similar. The work is in knowing what to look for.
The vocabulary, briefly
Controller vs. processor
The controller decides why and how personal data is processed. The processorprocesses data on the controller’s instructions. In a typical SaaS arrangement, the customer is the controller (they decide what data to upload, who to share it with) and the vendor is the processor (they store and process the data per the customer’s choices).
Some arrangements involve joint controllers (both parties decide on processing purposes). Joint control is rarer than vendors think; double-check before signing a DPA that designates joint control.
Sub-processor
A sub-processor is a third party your processor hires to help process data — AWS, Stripe, a transcription API, a customer-support tool. Under GDPR, the controller has the right to know who the sub-processors are and to object to additions.
Standard Contractual Clauses (SCCs)
SCCs are the EU’s legal mechanism for transferring personal data outside the EEA to a country without an adequacy decision. They come in modules (controller-to-processor, processor-to-processor, etc.) and must be incorporated into the DPA. The UK has its own version, the International Data Transfer Addendum (IDTA), which is similar.
The four red flags
1. Vague sub-processor list
Open the DPA and find Annex I (or the equivalent — sometimes called “Approved Sub-processors”). It should be a list with names, services, and locations.
- If the list is empty or just says “TBD,” that’s a red flag.
- If the list says “Vendor’s affiliates and standard cloud providers,” that’s a red flag — you can’t consent to a list you can’t see.
- If the list is on the vendor’s website behind a generic “current sub-processors” URL, that’s acceptable, but ask for the URL to be linked in the DPA so it’s contractually binding.
You also want a notice + objection mechanism: at least 30 days’ notice before a new sub-processor is added, with a right to terminate the underlying contract for objections that aren’t resolved.
2. Insufficient breach notification
GDPR requires the processor to notify the controller of a personal data breach “without undue delay.” The DPA should specify what that means in practice.
Acceptable: notification within 24 hours of becoming aware of a breach. Some DPAs say 72 hours; that’s the GDPR deadline for the controller to notify the regulator, which means a 72-hour processor notification gives the controller zero time to act.
Look for: notification within 24 hours, including (i) nature of the breach, (ii) affected data subjects, (iii) likely consequences, (iv) measures taken or proposed.
3. Audit rights that don’t mean anything
GDPR gives controllers the right to audit processors. Vendors hate this for obvious reasons (auditors are expensive and disruptive). The compromise most DPAs use: controllers can rely on third-party audit reports (SOC 2, ISO 27001) instead of running their own audit.
That’s acceptable, with two caveats:
- The controller should retain the right to audit directly — at the controller’s cost, with reasonable notice — if the third-party reports are insufficient or inadequate.
- The third-party report must be made available on request, refreshed annually, and cover the actual services you’re using (not a different product line).
4. International transfer mechanism missing or weak
If the processor or any sub-processor is outside the EEA / UK, the DPA must include a valid transfer mechanism. The default in 2026 is SCCs (for EU-origin data) and the IDTA (for UK-origin data), with the relevant modules selected and Annexes completed.
Watch for:
- DPAs that reference SCCs but don’t actually attach or incorporate them. Without the actual text and Annexes, the SCCs aren’t in force.
- DPAs relying on outdated mechanisms (the old EU-US Privacy Shield, the 2010 SCCs). These are no longer valid.
- DPAs that ignore international transfers entirely, despite obvious cross-border processing (e.g., a US vendor with no transfer language).
The minimum acceptable DPA
At minimum, your DPA should cover:
- Roles (who is controller, who is processor) and the categories of personal data and data subjects.
- Purpose, nature, and duration of processing.
- Processor’s confidentiality obligation (employees and agents bound by confidentiality).
- Security measures (encryption, access controls, incident response).
- Sub-processor list, notice, and objection mechanism.
- Data subject rights assistance (the processor must help the controller respond to access, deletion, rectification requests).
- Breach notification timeframe and content.
- Audit rights (direct + third-party report).
- International transfer mechanism (SCCs / IDTA), where applicable.
- Return or deletion of data on termination.
- Liability allocation (usually subject to the underlying contract’s liability cap).
If you remember one thing
DPAs are templates because the law is templated. The risk isn’t in the obvious clauses; it’s in what’s missing. Run through the four red flags. If all four are clean, sign the DPA and move on.
For a clause-by-clause negotiation reference, see our DPA playbook with sample positions for each provision.