DPA notes — what a data processing agreement needs

I do not draft DPAs. Not from scratch, not from memory, not by adapting something I found. Where I am processing personal data on a client's behalf, I start from a standard model — the client's own DPA, an industry-standard controller-to-processor template, or the European Commission's standard contractual clauses where they apply — and I have it reviewed by a qualified professional before I sign it.

This file is a checklist for reading a DPA someone hands me, and for knowing when to ask a lawyer. It is not legal advice and it contains no legal text on purpose. Nothing here is a substitute for a review.

When a DPA is needed

• The client is the controller, I am the processor, and I touch personal data on their behalf → a written agreement is required under GDPR Art. 28 before any data moves.
• Tier 1, fully aggregated, no personal data ever leaves their environment → often not required, but I confirm that rather than assume it. "Aggregated" has to mean genuinely non-identifying, not just "no name column."
• If I am unsure whether something counts as personal data, I assume it does and get the agreement in place. It is cheaper than the alternative.

Clauses an EU controller-to-processor DPA needs

Read for these. A missing one is a question for the lawyer, not something I fill in myself.

• ☐Subject matter, duration, nature and purpose of the processing
• ☐Categories of personal data and categories of data subjects
• ☐Documented instructions — I process only on the controller's written instructions, including on international transfers
• ☐Confidentiality — anyone processing the data is bound to confidentiality
• ☐Security measures — the technical and organisational measures, usually an annex; this is where my baseline runbook gets attached
• ☐Sub-processors — whether general or specific authorisation applies, the notice period for changes, and flow-down of the same obligations
• ☐Assistance to the controller — with data subject rights requests
• ☐Assistance with breach notification, DPIAs and prior consultation
• ☐Breach notification to the controller without undue delay — with the actual hours written in, matching what my incident plan promises
• ☐Deletion or return at the end of the engagement, and what happens to copies
• ☐Audit and information rights — what the controller can ask for and how
• ☐International transfers — the mechanism if data goes outside the EEA, and the transfer risk assessment if one is required
• ☐Liability, indemnity and insurance — commercial, and the part I am most likely to get wrong alone
• ☐Governing law and jurisdiction
• ☐Annexes actually filled in — an unfilled annex is a common and serious gap

Things I check against my own operation

The paperwork has to match what I actually do, or it is worse than useless:

• ☐The breach notification window in the DPA matches templates/incident-plan.md
• ☐The sub-processor list matches templates/gdpr-art30-register.csv
• ☐The security annex matches baseline-runbook.md and I can evidence every claim in it
• ☐The deletion clause matches what templates/handover.md actually does, including backups
• ☐The stated data locations match the data-flow diagram
• ☐I can genuinely meet the audit and assistance obligations as a one-person consultancy

Red flags — stop and get advice

• The client hands me a controller-to-controller agreement for what is clearly processing on their behalf, or the roles are left vague.
• I am asked to sign terms committing me to a certification I do not hold.
• Obligations I cannot physically meet — 24/7 response, on-site audit at short notice, uncapped liability.
• Transfers outside the EEA with no mechanism named.
• Pressure to start processing "while legal catches up." The answer is no; the data waits.

My Art. 30 obligation

As a processor I keep my own record of processing activities — templates/gdpr-art30-register.csv. It is separate from the client's record and it is my responsibility, not theirs.