All posts

ComplianceApril 10, 2026·8 min read

GDPR DPA addenda: the founder's checklist

If your vendor processes any personal data of EU residents on your behalf, GDPR Article 28 requires a written agreement governing how. That agreement is the Data Processing Addendum (DPA), and most vendor templates have at least one corner that needs sharpening.

Here's the eight-point checklist we run on every DPA we review. None of this is novel; it's all directly from Article 28 and Schedule terms in the EDPB-recommended SCCs. But the templates skip steps, and the skips matter.

1. Subject matter and duration

Article 28(3) requires the DPA to describe the subject matter, duration, nature, and purpose of the processing. Many templates wave this off with "as set out in the Services Agreement." That's fine for subject matter; not fine for duration, which should specify retention.

What to look for: explicit retention period or "for the duration of the Services Agreement plus 30 days for purge."

2. Categories of data subjects and personal data

The DPA should enumerate which categories of data subjects (your employees, your customers, your end-users) and which categories of personal data (contact details, identifiers, financial data, special category data under Article 9) are being processed.

Red flag: "all personal data provided by Customer." Not specific enough.

3. Sub-processor list and notification

Article 28(2) requires the processor to obtain prior authorization for new sub-processors, with the customer having the right to object. Many templates default to "30-day blanket consent" — which functionally removes your veto.

What to look for: sub-processor list available at a stable URL, 30-day prior notification of additions, and a customer right to terminate the relevant services if you object.

4. Transfer mechanism for data leaving the EEA

Post-Schrems II, transfers to non-adequate countries (the US, most notably) require Standard Contractual Clauses (the 2021 SCCs, Module 2 for processor-to-processor) and a Transfer Impact Assessment. The DPA should reference both.

Red flag: an old DPA template that still references the 2010 Controller SCCs or relies on the invalidated Privacy Shield.

5. Confidentiality of staff

Article 28(3)(b) requires that "persons authorized to process the personal data have committed themselves to confidentiality."

What to look for: explicit language that the processor's personnel are under confidentiality obligations.

6. Security measures (Article 32)

Article 32 requires "appropriate technical and organizational measures." The DPA should attach (or reference by URL) a security schedule listing encryption, access controls, breach detection, and the rest.

Red flag: vague language like "industry-standard security measures." Get specifics.

7. Breach notification

Article 33(2) requires the processor to notify the controller "without undue delay" of a personal-data breach. "Without undue delay" is fuzzy enough to permit a week; you want 24 hours.

What to look for: explicit 24-hour or 48-hour notification window, plus a commitment to provide the information you'll need to satisfy your Article 33(3) notification to the supervisory authority.

8. Audit rights

Article 28(3)(h) gives the controller the right to "audits, including inspections" of the processor. Many DPAs replace audit rights with "the processor will provide a SOC 2 report on request." That's a useful proxy but not a replacement.

What to look for: SOC 2 report on request, plus the right to a direct audit no more than once per year, with reasonable notice and non-disruptive scope. The right matters even if you never exercise it.

How CheckMyDoc handles this

DPAs are part of the standard Compliance check on every Launch and Scale review. We surface the eight items above as separate findings, severity- coded, with the citing section and the standard market language to push back to. If the DPA is missing entirely from a vendor MSA, that's flagged as a high-severity finding on its own.

A disclaimer

This is a checklist for self-review, not a substitute for a privacy lawyer. GDPR is a moving target — supervisory authority guidance shifts, court decisions reshape transfer mechanisms, and your specific risk profile depends on the data you're processing. Treat this as a starting point, then take the live ones to counsel.