Five questions to ask before signing a processor's DPA

Data Processing Agreements have a habit of getting rubber-stamped. They’re long, they’re formulaic, and they’re usually presented as non-negotiable by the vendor’s legal team. That’s exactly why they’re worth a proper look — the boilerplate is where the gaps hide.

Here are five questions I ask on every DPA review.

1. Does it actually name the processing?

Article 28(3) requires the DPA to set out the subject matter, duration, nature and purpose of the processing, the type of personal data, and the categories of data subjects. Vague, catch-all language (“any data provided by the Controller”) is unlikely to satisfy this — it should be specific enough that you could hand it to an auditor and they’d understand exactly what’s happening to the data.

2. Are sub-processors handled properly?

The agreement needs either specific or general written authorisation for sub-processing, and — if general authorisation is used — a mechanism for you to be notified of changes and object. Check whether that notification mechanism is realistic. A clause that technically exists but relies on you monitoring a static list buried in a portal isn’t much use in practice.

3. What happens on international transfer?

If the processor (or a sub-processor) is outside the UK, the DPA needs an appropriate transfer mechanism — typically the UK Addendum to the EU SCCs or an adequacy-based route. This is one of the most commonly missed elements, particularly with US-based SaaS vendors who default to their standard terms without checking UK-specific requirements.

4. Does it commit to appropriate security measures?

Article 32 obligations need to flow down into the DPA, not just exist in a separate security policy nobody can find. Ask for the specifics — encryption standards, access controls, breach detection — rather than accepting “industry standard security measures” as a substitute.

5. What’s the actual breach notification timeline?

You’re required to notify the ICO within 72 hours of becoming aware of a breach. If your processor’s DPA gives itself, say, five business days to tell you, the maths doesn’t work — you’d already be in breach of your own notification obligation before you even hear about the incident.

The pattern worth noticing

None of these are exotic requirements — they’re all explicitly listed in Article 28(3). The gaps usually aren’t intentional; they’re what happens when a DPA template gets copied and adapted without anyone checking it against the actual list. Which is, in fairness, exactly the kind of review that’s easy to outsource rather than do fifteen times a year yourself.