Data Processing Agreement in Denmark: Template, Key Clauses and Local Law (2026)

What a data processing agreement in Denmark is A data processing agreement (DPA) in Denmark is the written contract between a controller (the business that decides why and how personal data is processed) and a processor (the supplier that processes that data on the controller's instructions). A DPA is not optional paperwork. Under Article 28 of the GDPR, whenever a processor handles personal data for a controller, a written contract with a defined set of terms is mandatory, and this applies in Denmark as it does across the EU. Denmark adds national rules on top of the GDPR through its own Data Protection Act, and the Danish Data Protection Agency (Datatilsynet) supervises and enforces both. This page explains the law and the clauses. It is general information, not legal advice. ## The law that governs it in Denmark - The GDPR. Regulation (EU) 2016/679 applies directly in Denmark. Article 28(3) lists the terms a DPA must contain. Article 28(1) says a controller may only use processors that give sufficient guarantees of appropriate technical and organisational measures.

• The Danish Data Protection Act. The Act on supplementary provisions to the GDPR (Act No. 502 of 23 May 2018, Databeskyttelsesloven) supplements the Regulation with national rules, for example on processing national identity numbers and on video surveillance. The two must be read together.
• The regulator. Datatilsynet is the supervisory authority in Denmark. It issues guidance, handles complaints, and can impose fines. It publishes a standard set of data processing clauses that many Danish businesses use as a base.
• International transfers. Where data leaves the European Economic Area, the GDPR transfer rules apply, usually the European Commission's Standard Contractual Clauses plus a transfer risk assessment. ## Key clauses to include ### The mandatory Article 28 terms
• Subject matter, duration, nature, and purpose of the processing.
• The types of personal data and categories of data subjects.
• Processing only on the controller's documented instructions.
• A duty of confidentiality on everyone who processes the data.
• Appropriate technical and organisational security measures (Article 32).
• Rules on engaging sub-processors, including prior authorisation and flow-down terms.
• Help with data subject requests and with the controller's own GDPR duties.
• Deletion or return of the data at the end of the service.
• Information and audit rights so the controller can check compliance. ### The practical additions
• Breach notification: how fast the processor tells the controller, so the controller can meet its own 72-hour notification duty.
• A list of approved sub-processors and how changes are notified.
• International transfer terms and the chosen transfer mechanism.
• Liability and indemnity allocation between controller and processor. ## A simple clause skeleton 1. Definitions aligned with GDPR terms.

2. Subject matter, duration, nature, and purpose (often an annex).
3. Types of data and categories of data subjects (an annex).
4. Processing on documented instructions only.
5. Confidentiality of personnel.
6. Security measures under Article 32 (an annex).
7. Sub-processors: authorisation and flow-down.
8. Assistance with data subject rights and controller duties.
9. Personal data breach notification.
10. International transfers and the transfer mechanism.
11. Deletion or return of data on termination.
12. Audit and information rights.
13. Liability and governing law (Danish law). ## Common mistakes to avoid - Treating a DPA as a formality and copying a template without filling in the annexes on data types, purposes, and security measures.

• Vague sub-processor terms, so the controller loses visibility of who actually touches the data.
• No breach notification timeline, which puts the controller's own 72-hour duty at risk.
• Ignoring international transfers when the processor or its sub-processors sit outside the European Economic Area.
• Leaving deletion or return undefined, so data lingers after the service ends. ## Managing Danish data processing terms in one workspace A DPA is rarely signed once and forgotten. Sub-processor lists change, security annexes get updated, and the same terms have to stay consistent across every supplier and customer. That is far easier when drafting, review, and tracking sit in one place rather than scattered across email threads. Adira is an AI legal workspace where you can draft a DPA, see each clause flagged as favourable, neutral, or unfavourable to you, edit clauses in plain English, and track review dates across your whole contract portfolio. Adira is deepest on Indian law today, and Denmark-specific and EU data-protection depth is on the roadmap, so pair it with Danish counsel and your data protection officer for the local detail.