GDPR Data Processing Agreement Clauses Requirements Clause by Clause: A Practical Guide

Under GDPR Article 28, a controller may use a processor only through a binding contract. That contract is the data processing agreement (DPA). The regulation does not prescribe a single template; it prescribes outcomes. This guide explains GDPR data processing agreement clauses requirements clause by clause, so you can map each mandatory term to your service, supply chain, and audit evidence.

Why Article 28 Makes the DPA a Legal Control

Article 28(1) requires the controller to use only processors that provide sufficient guarantees to implement appropriate technical and organisational measures. Article 28(3) then states that processing by a processor must be governed by a contract or other legal act under Union or Member State law. The contract must be in writing, including in electronic form, and must bind the processor to the controller. A DPA is therefore not a commercial nicety. It is the instrument that keeps processing lawful when a third party handles personal data on your behalf.

The controller remains accountable to data subjects and supervisory authorities. A DPA does not transfer that accountability. It allocates operational duties and creates evidence that Article 28 has been respected. For related drafting context, see GDPR Data Processing Agreement Clauses: A Practical Guide.

The Mandatory Clause-by-Clause Checklist Under Article 28(3)

The GDPR data processing agreement clauses requirements clause by clause checklist below follows the eight lettered items in Article 28(3). Each item should be visible in the contract, not merely implied by a policy or a security page.

The Eight Lettered Obligations

(a) Documented instructions. The processor must process personal data only on documented instructions from the controller. This includes transfers to a third country or an international organisation, unless required by Union or Member State law. If law requires processing, the processor must inform the controller before processing unless prohibited by law.

(b) Confidentiality. Persons authorised to process personal data must be committed to confidentiality or be under an appropriate statutory obligation of confidentiality. This covers employees, contractors, and temporary staff.

(c) Article 32 security. The processor must take all measures required under Article 32 of the GDPR. Those measures are risk-based and include encryption, pseudonymisation, resilience, and regular testing.

(d) Sub-processor conditions. The processor must respect the conditions in Article 28(2) and Article 28(4) for engaging another processor. In practice, this means prior written authorisation, notice of changes, and flow-down of equivalent obligations.

(e) Data subject rights assistance. The processor must assist the controller in responding to data subject requests under Chapter III. That includes access, rectification, erasure, restriction, portability, and objection requests.

(f) Compliance assistance. The processor must help the controller meet Articles 32 to 36. This covers security, personal data breach notification, data protection impact assessments, and prior consultation with the supervisory authority.

(g) Deletion or return. At the end of the provision of services, the processor must delete or return all personal data and delete existing copies unless Union or Member State law requires storage. Backups, archives, and disaster recovery systems need explicit treatment.

(h) Audit and information rights. The processor must make available all information necessary to demonstrate compliance and allow for and contribute to audits, including inspections, by the controller or another auditor mandated by the controller.

Article 28(3) also requires the processor to immediately inform the controller if, in its opinion, an instruction infringes the GDPR or other Union or Member State data protection provisions. That notification duty should have a named contact and a defined channel.

Sub-processors, International Transfers, and Liability

Sub-processor clauses are a frequent source of gaps. Article 28(2) prohibits engaging another processor without prior specific or general written authorisation from the controller. If authorisation is general, the processor must inform the controller of intended changes and give the controller the opportunity to object. Article 28(4) requires the same data protection obligations to be imposed on the sub-processor by contract. If the sub-processor fails, the initial processor remains fully liable to the controller.

International transfers need separate attention. A DPA should identify transfer mechanisms such as an adequacy decision, Standard Contractual Clauses, or Binding Corporate Rules. It should also record any transfer impact assessment and supplementary measures. The DPA is not a substitute for a valid Chapter V transfer tool.

Liability terms should reflect Article 82 and the risk allocation in the supply chain. A processor that determines the purposes and means of processing may be treated as a controller under Article 28(10). Drafters should avoid language that accidentally gives the processor discretion over why or how data is processed.

Operationalising the DPA: Security, Audits, and Breach Response

A signed DPA is only the start. The GDPR data processing agreement clauses requirements clause by clause obligations must be reflected in daily operations. Security schedules should name the Article 32 measures, the owner, and the review cycle. Breach clauses should state how the processor will notify the controller without undue delay after becoming aware, what information it will provide, and how the controller will meet its Article 33 and Article 34 duties.

Audit clauses work best when they define scope, frequency, notice periods, confidentiality, and cost. Unlimited audit rights can be impractical, but a clause that offers only a generic statement of cooperation may not satisfy Article 28(3)(h). A practical approach is a tiered model: annual reports, questionnaires, remote checks, and on-site inspections when risk justifies them.

Documentation discipline matters. If you already maintain management-system records, apply the same control logic described in The ISO 9001 documentation requirements guide: A Practical O to DPA version control, approvals, and evidence retention. If your organisation also places products on the EU market, keep privacy records aligned with the technical documentation practices in EU CE Marking Technical File: A Practical Guide.

Common Pitfalls and a Practical Review Workflow

Generic templates often fail because they do not match the actual processing. Watch for missing sub-processor lists, no change-notification process, vague breach timelines, deletion clauses that ignore backups, and transfer clauses that name a mechanism without evidence. Also check that the DPA covers the controller's documented instructions, not just the processor's standard service description.

Use the GDPR data processing agreement clauses requirements clause by clause review as a repeatable workflow:

1. Map the data flow and confirm controller and processor roles.
2. Check Article 28(3)(a) to (h) against the contract text.
3. Attach annexes for processing details, security measures, sub-processors, and transfers.
4. Test breach, rights-request, and audit procedures with a tabletop exercise.
5. Version the DPA and review it when services, vendors, or laws change.

That workflow turns a legal document into an operational control. It also gives supervisory authorities a clear trail from obligation to evidence.