GDPR Data Processing Agreement (DPA): Article 28 Explained (2026)

A data processing agreement (DPA) is a binding contract that GDPR Article 28 requires any controller to enter into with every processor before that processor handles personal data on the controller's behalf. Without a compliant DPA, both parties face fines of up to EUR 20 million or four percent of global turnover under Article 83(4).

What Is a GDPR Data Processing Agreement?

A GDPR data processing agreement is the contract that Article 28(3) of Regulation (EU) 2016/679 requires a controller to put in place with every processor it engages to handle personal data. It sets out the subject-matter, duration, nature, and purpose of the processing, the type of personal data involved, the categories of data subjects, and the obligations and rights of the controller. The agreement must be in writing, including electronic form, as Article 28(9) specifies.

Article 28(1) requires a controller to use only processors that provide sufficient guarantees to implement appropriate technical and organisational measures. The DPA is the primary mechanism by which the controller secures and documents those guarantees, and it sits at the intersection of accountability and liability. Under Article 82, both controllers and processors face civil liability for damage caused by a GDPR infringement. The processor's liability is capped to situations where it has not complied with obligations specifically directed at processors or has acted outside the controller's lawful instructions. A well-drafted DPA defines those instructions precisely, which matters both for enforcement and for allocation of liability.

The EDPB's Guidelines 07/2020 on the concepts of controller and processor, adopted in final form on 7 September 2021, emphasise that the absence of a written DPA is itself a violation of Article 28, independent of whether any data subject has been harmed. Regulators have issued fines specifically for missing or inadequate processing agreements. For context on the broader GDPR framework, see What Is GDPR?.

Controller vs Processor: Why the Distinction Matters

Article 4(7) defines a controller as "the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data." Article 4(8) defines a processor as "a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller."

The controller decides the "why" and the "how" of processing: what data to collect, for what purpose, on what legal basis, and for how long. The processor operates within those parameters. It performs technical or organisational tasks on the data but does not independently set the purpose, retain data beyond the controller's instructions, or use the data for its own benefit.

The EDPB's Guidelines 07/2020 clarify that the designation is functional and factual, not contractual. Calling an entity a "processor" in a contract does not make it one if in practice it exercises independent judgment over the purposes or means of processing. An entity that drifts from processing-on-instructions into purpose-setting becomes a controller and assumes controller obligations regardless of how the parties labelled the relationship.

This distinction has three practical consequences. First, only the controller holds a lawful basis for processing under Article 6; the processor does not need a separate one as long as it operates within instructions. Second, the controller is primarily accountable to supervisory authorities for the substance of the processing. Third, audit, cooperation, and assistance obligations flow back to the controller through the DPA.

Common processor relationships include cloud storage providers hosting data on the controller's behalf; email service providers transmitting communications; payroll bureaus processing employee data under the employer's instructions; analytics platforms processing web-visitor data on the website operator's terms; and outsourced customer-support providers working from a defined script and database.

Not every third party that touches personal data is a processor. Joint controllers (Article 26), recipients who receive data under a legitimate disclosure, and entities processing data independently for their own purposes are not processors. A cloud-infrastructure provider that processes data only on documented customer instructions is a clear processor. A marketing analytics firm that aggregates data from multiple clients, derives its own insights, and sells those insights to third parties is, for that independent processing, a controller in its own right.

When Is a DPA Required?

A DPA is required whenever a processor processes personal data on behalf of a controller. Article 28(1) imposes the obligation on the controller without distinguishing by industry sector, organisation size, contract value, processing volume, or data sensitivity. A sole-trader photographer who outsources email newsletters to a marketing automation platform must have a DPA with that platform. The obligation arises before any processing begins; a controller that transfers data to a processor without a prior written DPA is in breach from the moment data moves.

Several contexts where DPAs are frequently overlooked but clearly required:

SaaS providers. When a business subscribes to a SaaS platform that processes the business's customer or employee data as part of delivering the service, the SaaS vendor is a processor and a DPA is mandatory. Most major vendors publish standard DPAs, but the controller remains responsible for verifying those documents satisfy Article 28(3) in full.

IT maintenance and support contractors. A contractor given temporary system access to perform maintenance on infrastructure containing personal data is processing that data on the controller's behalf, even if not expected to read or use it. Access itself constitutes processing under Article 4(2).

Analytics and advertising technology. Platforms that place tracking technologies on a controller's website and process visitor data according to the controller's configuration are acting as processors for those activities, even where the platform simultaneously processes data for its own advertising purposes in a separate controller capacity.

Outsourced HR and payroll. An external payroll bureau processes employee personal data strictly to fulfil the employer's payroll obligations; it does not determine the purpose of that processing.

Cloud infrastructure providers. Where a business runs its own applications on third-party cloud infrastructure, the cloud provider is processing personal data on the business's behalf. Major providers offer standard DPAs, but the controller cannot rely on vendor publication alone; active acceptance is required.

A DPA is not required when two organisations process personal data independently for their own separate purposes, each acting as a controller. A DPA is also not required for joint controllers, though Article 26 requires a separate arrangement between them.

The Eight Mandatory Clauses: Article 28(3) in Full

Article 28(3) specifies the minimum content of a DPA in eight lettered sub-clauses. Each is non-optional; a DPA that omits or substantively weakens any of these eight elements does not satisfy Article 28.

Beyond the eight mandatory clauses, Article 28(3) also requires the contract to specify the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data, the categories of data subjects, and the obligations and rights of the controller. These parameters define the outer boundary within which the processor lawfully operates.

Clause (a): Instructions Only

The documented-instructions requirement in Article 28(3)(a) is the foundational control mechanism of the processor relationship. "Documented" means written or otherwise recorded; verbal instructions are insufficient for any instruction that is material to the scope of processing.

The DPA itself sets the primary instructions (data categories, permitted processing operations, retention periods), and the service agreement supplements them with operational detail. Ad-hoc instructions outside the original scope must be documented. The processor's obligation to flag any instruction it believes violates the GDPR (set out in the final sentence of Article 28(3)) complements this clause: a processor that follows an unlawful instruction without raising it risks losing the liability shelter that instruction-compliance provides under Article 82(3).

Where the processor or its sub-processors operate infrastructure outside the EEA, the DPA must explicitly authorise those transfers and identify the transfer mechanism under GDPR Chapter V. See the GDPR International Data Transfers guide.

Clause (c): Article 32 Security

Article 28(3)(c) places the Article 32 obligations directly on the processor. Article 32(1) specifies what those security measures must address: pseudonymisation and encryption; the ability to ensure ongoing confidentiality, integrity, availability, and resilience of processing systems; the ability to restore availability and access to personal data in a timely manner after a physical or technical incident; and a process for regularly testing and evaluating the effectiveness of technical and organisational measures.

Appropriate measures must account for the state of the art, implementation costs, and the nature, scope, context, and purposes of processing, as well as the risk to the rights and freedoms of natural persons. What is appropriate for a processor handling anonymised analytics differs from what is required for health data or financial records. A DPA that does not specify security standards expected of the processor for the particular categories of data being processed falls short.

Clause (f): Assisting With Breach Notification and DPIAs

Article 28(3)(f) imposes a time-pressured cooperation obligation. Under Article 33(1), a controller must notify its supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours. A controller can only meet that deadline if its processor has systems in place to detect, document, and notify the controller promptly.

The DPA should specify the processor's obligation to notify the controller of any potential data breach within a defined period (many DPAs use 24 to 48 hours) and to provide the Article 33(3) information: the nature of the breach, categories and approximate number of data subjects affected, categories and approximate number of records concerned, likely consequences, and measures taken or proposed. A vague general reference to Article 33 is inadequate.

The DPIA assistance obligation is also practically important. Under Article 35, a controller must carry out a data protection impact assessment before processing likely to result in high risk to data subjects. Processors often hold the technical information needed to complete the risk assessment, and the DPA should specify the processor's cooperation obligation.

Clause (h): Audit Rights

Processors routinely propose to satisfy Article 28(3)(h) through third-party audit certifications (ISO 27001 or SOC 2 Type II) rather than allowing the controller direct access to systems and records. EDPB Guidelines 07/2020 confirm that third-party certifications can constitute evidence of compliance, but they cannot exclude the controller's right to conduct its own audit where it has specific compliance concerns. A DPA provision that entirely replaces the audit right with a certification reference does not satisfy Article 28(3)(h) and has been criticised by supervisory authorities.

Sub-Processors and the Flow-Down Obligation

A sub-processor is any third party that a processor engages to carry out specific processing activities on the controller's behalf. Article 28(2) requires the processor to obtain prior specific or general written authorisation from the controller before engaging any sub-processor.

Where the controller grants general authorisation, Article 28(2) requires the processor to inform the controller of any intended changes concerning the addition or replacement of sub-processors, giving the controller an opportunity to object. The DPA must build in a notification period sufficient for the controller to exercise this right; many DPAs set 30 days' advance notice.

Article 28(4) provides the flow-down rule: where a processor engages a sub-processor, it must impose on the sub-processor the same data protection obligations as those in the controller-processor contract. If the sub-processor fails to fulfil its obligations, the initial processor remains fully liable to the controller.

Every node in a processing chain must be bound by an Article 28-compliant agreement. Liability flows back fully to the processor, who must in turn ensure adequate contractual protections in downstream agreements with sub-processors.

Controllers managing complex vendor chains should map their processors and each processor's declared sub-processors as part of their records of processing activities (Article 30). Many processors publish sub-processor lists and commit to provide advance notification of changes.

The Commission's Article 28 Standard Contractual Clauses

The GDPR allows DPAs to be based, in whole or in part, on standard contractual clauses adopted by the Commission or by a supervisory authority (Article 28(6) and (7)).

Commission Implementing Decision (EU) 2021/914, published in Official Journal L 199/31 on 7 June 2021, adopted the SCCs for international data transfers. That decision contains four modules, including Module 2 (controller to processor) and Module 3 (processor to processor), governing Chapter V transfer obligations when processing involves a transfer outside the EEA. Those international transfer SCCs are distinct from, but compatible with, the Article 28 SCCs. For a full explanation, see the GDPR International Data Transfers guide.

Commission Implementing Decision (EU) 2021/915, also published on 4 June 2021, adopted standalone standard contractual clauses specifically for controller-processor agreements within the EU and EEA (the "Article 28 SCCs"). Parties who adopt them without modification can rely on the Commission's determination of adequacy for those clauses. They are structured to be modular and adaptable, with clearly marked optional provisions and appendices where the parties supply processing parameters (data categories, purposes, security measures, sub-processor lists).

Parties may add additional commercial terms alongside the Article 28 SCCs, provided those additions do not contradict the mandatory clauses or reduce protection for data subjects. Where the parties wish to incorporate both the Article 28 SCCs and the Chapter V transfer SCCs into a single agreement, the Commission's guidance confirms the two sets of clauses can be combined.

DPAs and International Data Transfers

Every time processing under a DPA involves a transfer of personal data outside the EEA, the DPA must address Chapter V compliance. Article 28(3)(a) already requires the DPA to cover any instruction to transfer data to a third country.

Where the entire processing relationship is within the EEA, the Article 28 SCCs cover the relationship fully. Where the processor operates infrastructure outside the EEA but the destination country holds an EU adequacy decision (for example, the UK, Japan, or a DPF-certified US organisation), the DPA must identify that adequacy decision as the transfer basis and confirm the processor and any sub-processors receiving data are covered by it. Where no adequacy decision applies, the DPA must incorporate the applicable Chapter V mechanism: for a controller-to-processor cross-border relationship, Module 2 of the 2021 international transfer SCCs, which also imposes a Transfer Impact Assessment under Clause 14.

A controller that executes an Article 28-compliant DPA with a US cloud provider but fails to separately incorporate Module 2 of the international transfer SCCs is partially compliant: the processing relationship is governed, but the transfer itself has no valid legal basis. The GDPR compliance checklist covers the steps required to address both layers.

Who Drafts the DPA?

The GDPR places the obligation to ensure a DPA is in place on the controller. In practice, large processors (SaaS vendors and cloud providers) typically produce the standard-form DPA because they transact with hundreds or thousands of controllers and cannot negotiate a bespoke contract with each one.

From the controller's perspective, this creates a due-diligence obligation rather than a drafting obligation. A controller that countersigns a processor's DPA without checking its content has not discharged its accountability obligations under Article 5(2), even if that DPA happens to be compliant. If the processor's standard DPA is deficient, the controller should negotiate amendments or seek a processor that provides a compliant agreement.

Controllers engaging smaller service providers who do not offer their own standard DPA must draft the agreement themselves or use the Commission's Article 28 SCCs as the base. The Article 28 SCCs are publicly available on the Commission's website and are free to use.

In a joint controller arrangement under Article 26, the obligations under Article 28 do not apply between the joint controllers. Article 26 requires a separate transparent arrangement governing their respective responsibilities, which operates under different rules from a DPA.

Consequences of Not Having a DPA

Failing to have a compliant DPA is an independent GDPR violation. Article 83(4) lists Article 28 as a provision whose breach is subject to administrative fines of up to EUR 10,000,000 or two percent of total worldwide annual turnover, whichever is higher. Where the absence of a DPA is symptomatic of broader accountability failures, supervisory authorities have also applied the higher Article 83(5) tier under Articles 5 and 25.

Supervisory authorities can also exercise corrective powers under Article 58(2): issuing warnings, reprimands, and compliance orders; temporarily or permanently limiting or banning processing; and ordering the suspension of data flows to a processor. A temporary processing ban may be operationally more damaging than a fine where the processor provides critical business infrastructure.

Civil liability under Article 82 is a separate risk. Where no DPA defined the processor's scope and obligations, the controller may struggle to establish that the processing was lawful. Enforcement decisions are public; a finding that a company was processing personal data through a service provider without any DPA signals systemic governance failures and tends to attract wider scrutiny.

Documented enforcement includes the Swedish Data Protection Authority (IMY) fining controllers for failing to have adequate processing agreements with vendors, and the Irish Data Protection Commission finding inadequate processor-controller contractual arrangements in major tech investigations.

Key Practical Steps for Controllers

Map processors. Identify every third party that processes personal data on the controller's behalf. The records of processing activities required under Article 30 are the natural vehicle for this exercise. A compliant written DPA must be in place before data is transferred to each identified processor.

Assess suitability. Article 28(1) requires due diligence on each processor's technical and organisational security measures, sub-processor arrangements, breach notification procedures, audit cooperation posture, and ability to assist with data-subject rights requests. Due diligence can include reviewing third-party audit certifications, completing vendor security questionnaires, and reviewing the processor's privacy documentation.

Execute a compliant DPA. Using the Commission's Article 28 SCCs is the most straightforward route to satisfying the mandatory clauses. Where the processing involves international transfers, Module 2 of the Commission's international transfer SCCs must also be incorporated or separately executed.

Manage sub-processor changes. Where the DPA provides for general sub-processor authorisation, establish a process for receiving and reviewing sub-processor change notifications and exercising the right to object where a proposed sub-processor raises compliance concerns.

Maintain DPAs. Processors update their services, add sub-processors, change data centres, and revise security measures. DPAs should be reviewed whenever a material change occurs in the processing activities covered.

For guidance on how the DPA fits into the wider GDPR compliance programme, see the GDPR compliance checklist.

Jurisdiction scope: This article addresses the data processing agreement requirement under GDPR Regulation (EU) 2016/679, which applies within the European Union and European Economic Area, including its application to processors and controllers established outside the EU/EEA who are subject to the GDPR's extraterritorial reach under Article 3. It does not address UK GDPR separately (which retains equivalent Article 28 requirements post-Brexit) or sector-specific processing contracts under Union institution data protection rules under Regulation (EU) 2018/1725.

Disclaimer: This article provides general legal information about GDPR Article 28 and data processing agreements as of June 2026. It does not constitute legal advice and should not be relied upon as such. The legal requirements described reflect the GDPR and official Commission and EDPB guidance as of the date of publication. Laws and guidance may change. You should consult a qualified lawyer licensed in your jurisdiction for advice specific to your organisation's circumstances.