Every European product team eventually runs into the same legal email: “Has procurement signed the data processing agreement with this analytics vendor yet?” The answer matters more than people realize. A weak DPA isn’t just a compliance risk — it’s a future migration project, a future stakeholder fight, and sometimes a future fine.
I’ve reviewed maybe sixty DPAs across analytics, attribution, and tag management vendors. The good ones look almost identical. The bad ones get creative in places you don’t want creativity. This checklist captures what I look for in every review, in the order I check it.
Why a DPA Is Non-Negotiable Under GDPR
Article 28 of the GDPR is unambiguous: when you let a third party process personal data on your behalf, you need a written contract that spells out exactly what they can do with it. Analytics vendors are processors. Tag managers are processors. Anything that touches a user identifier, an IP address, or a behavioral signal qualifies.
“We don’t collect personal data” is almost never a defensible answer. IP addresses are personal data under the GDPR. Hashed user IDs are personal data when combined with other signals. Even cookieless analytics often falls in scope because the fingerprinting logic produces a quasi-identifier. If you process user behavior in any way, you need a DPA.
The 12-Point Checklist
Here’s what I check, in order, before signing or renewing a DPA with any analytics vendor:
1. Named Sub-Processors with Locations
The vendor must list every sub-processor by name, the country of processing, and the purpose. “Cloud infrastructure providers” is not a list. If you can’t tell whether the vendor uses AWS in Frankfurt or in Ohio, you can’t make a transfer impact assessment, and you’ll fail any audit.
2. Standard Contractual Clauses for Non-EEA Transfers
If any data leaves the EEA — including to the US, UK, or APAC datacenters — the DPA must include the 2021 EU Standard Contractual Clauses, with the right modules selected. Module 2 (controller to processor) is the most common. Older 2010 SCCs are not acceptable anymore.
3. Transfer Impact Assessment Cooperation
Schrems II requires you to assess whether the destination country’s surveillance laws might compromise the data. The vendor doesn’t do the assessment for you, but they must commit to providing the information you need: legal jurisdiction, government access requests received, encryption posture. Vague language here means the vendor will stonewall when you actually ask.
4. Data Categories and Purpose Limitation
The DPA must list the categories of personal data being processed (identifiers, behavior, device data) and the exact purposes (analytics, attribution, A/B testing). Anything outside that list requires a new DPA amendment. This protects you when the vendor announces a “new AI feature” that quietly starts processing your data for model training.
5. Retention Period
How long does the vendor keep the raw data? Reasonable answers range from 14 months to 26 months for analytics. Anything beyond 26 months without a stated business reason is a red flag. The DPA must commit the vendor to deletion at the end of the retention window, not just “anonymization.”
6. Deletion on Termination
When you terminate the contract, what happens to the data? The DPA should specify a deletion timeline (typically 30 to 90 days), the format of the deletion certificate, and whether backups are included. “Data may persist in backups” is acceptable only if accompanied by a deletion-on-restoration commitment.
7. Breach Notification Window
You have 72 hours to notify your supervisory authority of a personal data breach. That clock starts when you become aware. Your vendor must therefore tell you within a window short enough to meet that obligation. I push for 24 hours. Anything over 48 hours is unacceptable for an analytics processor.
8. Audit Rights
The DPA must give you the right to audit. In practice, this usually means accepting a recent SOC 2 Type II or ISO 27001 report instead of an on-site audit. That’s fine — but the right itself must be in the contract. Vendors who want to remove or restrict it are signaling they have something to hide.
9. Personnel Confidentiality
The vendor must confirm that anyone with access to your data is bound by confidentiality obligations and has been trained on data protection. This is boilerplate in any decent DPA, but I’ve seen it missing in early-stage analytics startups. If it’s missing, ask for it added.
10. Security Measures Schedule
An annex listing the technical and organizational measures (TOMs): encryption at rest, encryption in transit, access controls, key rotation, vulnerability management. Vague language (“industry-standard security”) is a fail. You want specifics — “AES-256 at rest, TLS 1.2+ in transit, quarterly access reviews.”
11. Sub-Processor Change Notice
When the vendor adds a new sub-processor, they must notify you in advance — typically 30 days — and let you object. If you can’t object, the sub-processor list is decorative. I’ve had clients reject DPAs with one-day notice clauses, because that’s not enough time to do an impact assessment.
12. Liability and Indemnification
If the vendor’s processing causes a fine or a customer complaint, who pays? The DPA must cap and allocate liability fairly. Most vendors push for total exemption or a one-month-fees cap. That’s not acceptable for a tool processing your entire user base. Push back, and document the negotiation.
Common Red Flags I Reject Outright
- “Anonymized data” carve-outs that let the vendor use your data freely as long as it’s “anonymized” by their own definition.
- Unilateral right to change the DPA terms with email notice.
- Sub-processor list maintained on a webpage that the vendor can update silently.
- No named contact for data protection inquiries.
- Deletion timelines longer than 90 days post-termination.
The first time a client asked me to review a DPA, I missed two of these. The vendor changed sub-processors three months later, and we found out only when a customer asked us during a sales call. Now I keep this list taped above my desk.
How to Run a DPA Review
I treat the review as a 60-minute exercise. The steps:
- Read the DPA end-to-end, marking every clause that maps to a checklist item.
- For each checklist item that’s missing or weak, draft a redline.
- Send redlines to the vendor’s legal contact, not just to your account manager.
- Track the negotiation in your vendor management system, not in email.
- Re-review annually or whenever the vendor changes sub-processors.
Most analytics vendors will accept reasonable redlines. The ones who refuse are usually the ones who’ll cause you problems later.
FAQ
Do I need a separate DPA for every analytics vendor?
Yes. Every processor needs its own contract. You cannot rely on the master service agreement to cover GDPR processor obligations. Most vendors publish a standard DPA you can sign as an addendum. Always check whether the published version is current.
What’s the difference between a DPA and Standard Contractual Clauses?
The DPA covers Article 28 processor obligations within the EEA. SCCs are what you add when data crosses borders to a country without an adequacy decision. They are layered: a US-based vendor needs both a DPA and the SCCs as an annex.
Can I use a DPA template I find online?
For internal reference, yes. As a substitute for the vendor’s own DPA, no. Each processor relationship has different sub-processor lists, retention periods, and security postures. A template won’t cover the specifics you need to assess.
How often should I re-review existing DPAs?
Annually at minimum. More often if the vendor announces a new product, changes ownership, or adds a sub-processor. Set a reminder in your vendor management system. The vendor will not remind you.
Conclusion
A DPA review is one of those tasks that feels bureaucratic until you actually need the contract to protect you. The twelve points above take an hour to walk through. They’ve saved me — and clients — from a handful of awkward situations and at least two near-misses with regulators. Run the checklist before you sign anything.