What a Data Processing Agreement Has to Cover

A data processing agreement governs what one party may do with personal data on another's behalf. It is often treated as a schedule to be accepted unread, which is a poor allocation of attention: it is the document that determines who bears the cost when something goes wrong with personal data.

Settle the roles first

Nothing else in the document is coherent until you know whether each party is acting as a controller, a processor, or a joint controller for the processing in question. This is determined by who decides the purposes and means of the processing — not by which party has more bargaining power, and not by what the agreement asserts. A characterisation that does not match the facts will not survive scrutiny.

Describe the processing specifically

The schedule describing the processing is the part most often filled with generic text, and it is what makes the rest enforceable. It should state:

• Subject matter and duration of the processing.

• Nature and purpose — what is actually done with the data and why.

• Categories of personal data, including any special categories.

• Categories of data subjects.

• Where the processing and storage physically happen.

If the processing description could be pasted into any other contract unchanged, it isn't describing your processing.

The operative obligations

• Process only on documented instructions, and flag instructions that appear unlawful.

• Confidentiality obligations binding on personnel with access.

• Appropriate technical and organisational security measures, described rather than merely asserted.

• Sub-processor controls: authorisation, notice of changes, a meaningful right to object, and flow-down of equivalent terms.

• Assistance with data subject rights requests, within a workable timeframe.

• Breach notification to the controller without undue delay, with a defined channel and content.

• Assistance with impact assessments and regulator engagement.

• Deletion or return at the end of the relationship, with any retention carve-out stated.

• Audit and information rights that are exercisable in practice.

Deal with international transfers explicitly

If data will move across borders, the agreement needs to say on what legal basis, and the mechanism has to be one that is currently valid for the jurisdictions involved. This is the fastest-moving area of data protection law and the one where inherited template text is most likely to be out of date. Where a transfer risk assessment is required, note who performs it.

Make the security schedule real

'Industry standard security measures' is unenforceable and tells a regulator nothing. List the measures: encryption in transit and at rest, access control and review, logging, backup and recovery objectives, personnel screening, secure development, incident response. Where the processor holds a recognised certification, reference it and its scope — but do not let a certification substitute for the list.

Negotiate the notification timeline you can actually meet

Controllers frequently demand breach notification within a very short window, and processors frequently accept it without checking whether their own detection and triage can deliver. An undeliverable commitment converts a security incident into a contractual breach as well. Agree a period that reflects reality, and define what the initial notification must contain versus what can follow.

Data protection law differs substantially between jurisdictions and changes frequently, particularly on transfers. This is an orientation to the structure, not legal advice; have the agreement itself reviewed by counsel qualified in the applicable regimes.