DPA Template 2026: What Must Be Included, What Must Not (Art. 28 GDPR)

1. What is a DPA?

A Data Processing Agreement (DPA) is, under Art. 28(3) GDPR, a mandatory contract between the controller and the processor. It governs the processing of personal data on behalf of the controller.

"Processing by a processor shall be governed by a contract or other legal act..." — Art. 28(3) GDPR

The contract is the second stage, not the first. Art. 28(1) GDPR first obliges the controller to make a selection: it may only work with processors that provide sufficient guarantees of appropriate technical and organisational measures. Anyone who signs without having checked those guarantees beforehand formally satisfies paragraph 3 and misses paragraph 1. Practice recommendation: record the result of that check, with a date, in the processor inventory.

Before that comes clarification of roles. Three roles must be distinguished: controller (Art. 4 no. 7 GDPR), processor (Art. 4 no. 8 GDPR) and joint controllers (Art. 26 GDPR). Only the second constellation leads to a DPA — confusing processing on behalf of a controller with joint controllership is one of the most frequent documentation errors in practice. The distinguishing feature is the binding effect of instructions: processing on behalf of a controller exists only where the other party processes exclusively on your instructions and without a processing interest of its own (section 2). If that is not the case, the DPA is the wrong instrument — then either the other party is a controller in its own right (section 6) or joint controllership under Art. 26 GDPR applies.

And the DPA is not a ground for permitting processing: it governs how a third party processes on your behalf, not whether you may process at all. You need the legal basis under Art. 6(1) GDPR independently of it (section 8).

2. When is a DPA mandatory?

A DPA is mandatory as soon as three criteria come together:

1. an external body processes
2. personal data for you
3. on your instructions (no processing interest of its own)

Typical processor constellations:

• IT hosting (AWS, Azure, GCP, Hetzner)
• Cloud software (Microsoft 365, Salesforce, HubSpot)
• Newsletter tools (Mailchimp, Brevo, CleverReach)
• Payroll service providers (often, not always)
• IT maintenance providers with data access
• Backup providers
• SOC / external IT security

The providers and tools named in this list reflect the state of the first version of this article. What matters is not the name but the third criterion: being bound by instructions. Anyone who does not work on instructions but pursues a processing interest of its own is not a processor — in that case the other party is either a controller in its own right (section 6) or joint controllership under Art. 26 GDPR applies.

It should also be borne in mind that the processor bears obligations of its own which the DPA does not set aside — its own record under Art. 30(2) GDPR and, where applicable, its own data protection officer (section 8 and section 9).

3. 8 mandatory contents under Art. 28(3) GDPR

Art. 28(3) GDPR expressly sets out the minimum content of the contract: 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. Practice derives eight verifiable contractual building blocks from this:

Two points are regularly misread. The "14 days" in row 7 are a contractual supply deadline, not a statutory one: statutorily, Art. 12(3) GDPR applies to the controller — without undue delay and in any event within one month of receipt of the request, extendable by a further two months where necessary, taking into account the complexity and number of the requests, with the data subject to be informed of the extension within one month together with the reasons. Anyone who does not agree a shorter supply deadline in the DPA structurally cannot meet their own deadline. And row 3 is not a formality: data under Art. 9(1) GDPR — for example health data arising from cases of illness — is subject to a general prohibition on processing with narrow exceptions under Art. 9(2) GDPR.

Equally clear is what does not belong in the DPA: provisions for bodies that are controllers in their own right (section 6) — there the DPA is the wrong contract; the legal basis for the processing, which must exist independently under Art. 6(1) GDPR (section 8); and blanket assurances about technical and organisational measures, which precisely fail to make the guarantees under Art. 28(1) GDPR verifiable (row 8 of the table).

4. 6 typical DPA errors

Six errors keep appearing in DPAs submitted for review — what they have in common is that the contract formally exists but carries no meaning in an audit: because it does not fit the organisation's own processing operations, because annexes are missing, or because nobody can show which version applies. The corresponding check question against the contract text is given in section 7 in each case.

1. Generic 'model contract from the internet': does not cover the organisation's own processing operations — Art. 28(3) GDPR requires subject matter, duration, nature and purpose as well as types of data and categories of data subjects to be set out specifically for this processing relationship.
2. Sub-processor list missing: large providers such as Microsoft use a large number of sub-processors — all of them must be listed. Without an attached list, neither an objection procedure can be exercised nor the third country situation assessed. (Provider information: state of the first version of this article.)
3. Third country transfer without an SCC/DPF annex: mandatory for US tools (Mailchimp, Zoom, Salesforce). The same transfer, together with its safeguard, also belongs in the record of processing activities — for the controller under Art. 30(1) GDPR, for the processor under Art. 30(2)(c) GDPR. (Tool references: state of the first version.)
4. Right to audit missing or ineffective ('with 6 months' lead time') — an audit right that only takes effect after two quarters does not resolve an acute question of doubt.
5. Return of data after the end of the contract unregulated — without a provision, it is open on the termination date who deletes which copies within what period and how that is evidenced.
6. Version management: an old DPA version from 2018 still in use despite the new SCC 2021/914 — without a version date it cannot be shown to the supervisory authority which version applies.

5. Schrems II / DPF annex

For US processors or sub-processors in third countries, the DPA alone is not enough — a mandatory annex is required containing:

• Standard Contractual Clauses (SCC 2021/914) OR
• evidence of DPF certification (for DPF-certified US companies)
• Transfer Impact Assessment (TIA) — to be prepared per recipient, not per contract; the working basis is the sub-processor list from mandatory content 6
• Additional technical measures (encryption, pseudonymisation)

In practice this means: the assessment is carried out per recipient, not per contract. Evidence under the DPF variant applies in each case to the certified US company, which is why the sub-processor list from mandatory content 6 is the working basis for this annex. The legal basis for the DPF variant is Commission Implementing Decision (EU) 2023/1795 of 10 July 2023; it is in force. The action brought against it was dismissed by the General Court of the European Union in Case T-553/23 (Latombe) on 3 September 2025; the appeal C-703/25 P lodged on 31 October 2025 had not been decided as at 17 August 2026, and in addition the request for a preliminary ruling C-804/25 on the scope of the DPF is pending. The decision is linked in the sources section together with judgment T-553/23 and EDPB Binding Decision 1/2023.

The annex does not end in the contract folder: every third country transfer must be documented in the record of processing activities together with the corresponding safeguard. As a practice recommendation: file the TIA and the DPF evidence with the date of review and the reviewer in the processor inventory, so that nothing has to be researched again if the supervisory authority asks.

6. BayLDA: what is not a DPA

Not every external service provider with data access is a processor — anyone acting in their own processing interest or by virtue of their own professional duties is, in the cases in this table, a controller in their own right (in other constellations joint controllership under Art. 26 GDPR may come into consideration), and then the DPA is the wrong contract.

For the rows marked "controller in its own right" you do not conclude a DPA — instead, the body is listed as a category of recipient in the record of processing activities. A DPA concluded without justification is not merely superfluous: it describes the roles incorrectly and thereby contradicts what your record says about the same processing.

The BayLDA, as the Bavarian Data Protection Authority (Bayerisches Landesamt für Datenschutzaufsicht), is responsible for non-public bodies in Bavaria; in Germany, supervision of non-public bodies generally lies with the authorities competent under Land law (§ 40(1) BDSG). In Austria, the Austrian Data Protection Authority (Datenschutzbehörde) is the competent supervisory authority (§ 18(1) DSG). For processing on behalf of a controller as such there is no separate Austrian rule — what governs is Art. 28(1) and (3) GDPR, supplemented by the duty of data secrecy under § 6 DSG.

7. DPA checklist before signing

Eight check points decide whether a DPA submitted for review is ready for signature — each of them is answered directly against the contract text:

Practice recommendation on responsibilities: the department engaging the service provider requests the DPA and describes the subject matter and purpose; the data protection function checks points 1 to 7 against the contract text; authorised management gives approval; the result is documented with the date and the reviewer in the processor inventory. Without a named responsibility, point 8 of this list remains unevidenced in an audit.

1. All 8 mandatory contents included? — use section 3 as a counter-list, line by line; the provision on return and deletion after the end of the contract is additionally checked via point 6 of this list.
2. Sub-processor list available + objection procedure settled? — as an annexed list, not as a link to a website that can change without notification.
3. Annex on technical and organisational measures specific (not merely "appropriate measures")? — only specific measures make the guarantees under Art. 28(1) GDPR verifiable at all.
4. Third country annex (SCC/DPF) for US sub-processors? — same standard of review as in section 5.
5. Right to audit anchored contractually? — with exercisable lead time and a named scope of audit.
6. Return of data + deletion after the end of the contract settled? — record the format, the deadline and the evidence of deletion.
7. Version date + validity documented? — carry the version in the processor inventory so that the applicable version is established in an audit.
8. Signed by both sides (digital signature accepted)? — record in the processor inventory when and by whom it was signed.

8. What a DPA does not replace

A DPA does not make processing lawful — it only governs the conditions under which a third party processes on your behalf. Four obligations remain unaffected by it:

• Legal basis: any processing is lawful only if at least one of the six grounds of Art. 6(1) GDPR is met. For special categories, the prohibition of Art. 9(1) GDPR applies in addition and can only be overcome through the exceptions of Art. 9(2) GDPR.
• Record of processing activities: the controller keeps its record under Art. 30(1) GDPR, the processor keeps one of its own under Art. 30(2) GDPR with four mandatory items — name and contact details, categories of processing carried out on behalf of the controller, where applicable third country transfers with safeguards and, where possible, a general description of the measures under Art. 32(1) GDPR.
• Data protection impact assessment: where processing is likely to result in a high risk to the rights and freedoms of natural persons, the controller carries out a DPIA in advance (Art. 35(1) GDPR) — including where the processing technically takes place at the processor.
• Incident documentation: notification to the supervisory authority under Art. 33(1) GDPR is incumbent on the controller; under Art. 33(5) GDPR every personal data breach must be documented, including those not notified, together with the reasons for not notifying.

9. The DPA in Germany and Austria

The minimum content of the DPA is identical in both countries because Art. 28 GDPR applies directly — and for infringements of Art. 28 the same framework of Art. 83(4) GDPR applies in both countries. What differs is the national superstructure and the supplementary national criminal or administrative penalty provisions. The following overview gives, for each row, the source for precisely that statement.

10. The DPA in a supervisory audit: deadlines and cycles

In audit practice, the DPA is the second step: supervisory authorities regularly begin with the record of processing activities and then ask, for every external service provider named there, for the matching contract; the observed sequence is record of processing activities → DPA → technical and organisational measures → DPIA (practice observation, not a legal assertion).

From this follows the most important organisational requirement: your processor inventory must match the recipient entries in the record. Every processor named there needs a retrievable, dated DPA — and every DPA in the folder needs an entry in the record.

The following overview separates statutory deadlines from practice recommendations; the "Character" column applies in each case precisely to the row in which it appears.