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

A data processing agreement (DPA, in Swedish personuppgiftsbiträdesavtal) is the contract a controller signs with any supplier that processes personal data on its behalf. In Sweden the DPA is not optional. It is required directly by Article 28(3) of the EU General Data Protection Regulation (GDPR), which applies in Sweden as directly binding law, supplemented by the Swedish Data Protection Act (Dataskyddslag, SFS 2018:218). If you use a payroll bureau, a cloud host, a CRM, an email tool or any vendor that touches personal data about your staff, customers or users, you need a DPA in place before the processing starts. This page explains what the agreement must say, the clauses Swedish and EU law require, and how the Swedish regulator reads them. It is general information, not legal advice. ## Do you need a DPA in Sweden, and who signs it? Yes, whenever one party (the processor) processes personal data on the documented instructions of another (the controller). Typical examples: a SaaS vendor hosting your customer records, an accounting firm running payroll, a marketing agency sending email on your behalf. The controller decides why and how data is processed; the processor only acts on instructions. Two points specific to the Swedish and EU setup: - The DPA sits on top of the GDPR, it does not replace it. The GDPR applies in full across the EU, so a Swedish DPA is essentially an Article 28 contract written for a Swedish controller. The Swedish Data Protection Act (2018:218) adds national rules (for example on certain identifiers and sensitive-sector processing) but does not change the core Article 28 requirements.

• The supervisory authority is IMY. Sweden's data protection regulator is the Integritetsskyddsmyndigheten (IMY, the Swedish Authority for Privacy Protection). IMY supervises both controllers and processors established in Sweden and can order access to documentation, including the DPA and the security measures behind it. ## What the law requires a DPA to contain Article 28(3) GDPR sets out the mandatory content. A DPA used in Sweden must, as a minimum, be in writing (electronic form counts) and cover all of the following: 1. Subject matter, duration, nature and purpose of the processing.

2. Type of personal data and categories of data subjects.
3. Processing only on documented instructions from the controller, including on international transfers, unless EU or Swedish law requires otherwise.
4. Confidentiality commitments from everyone authorised to process the data.
5. Security of processing under Article 32 (appropriate technical and organisational measures).
6. Sub-processors: no engagement without prior authorisation, and flow-down of the same obligations by contract.
7. Assistance to the controller with data subject rights requests (access, erasure, portability and the rest).
8. Assistance with breach notification, data protection impact assessments and prior consultation.
9. Deletion or return of the data at the end of the service, and deletion of copies.
10. Audit and information: the processor makes available everything needed to show compliance and allows audits or inspections. If any of these is missing, the agreement is not a valid Article 28 contract, and both parties are exposed. ## Key clauses, and what to watch in each | Clause | What good looks like | Common weak spot | |---|---|---| | Scope and instructions | A precise description of data, purposes and documented instructions | Vague "as instructed from time to time" with no written trail | | Security (Art. 32) | Named measures: encryption in transit and at rest, access control, logging | A bare promise of "appropriate measures" with no detail | | Sub-processors | A list plus a right to object to new ones within a set notice period | Blanket consent with no notice and no objection right | | International transfers | Standard Contractual Clauses or another Article 46 safeguard for non-EEA transfers | Silence on where data actually sits | | Breach notification | A fixed, short deadline for the processor to notify the controller | "Without undue delay" with no hours or days | | Assistance with rights | Clear process and realistic timelines for access and erasure requests | Costs and timelines left open | | End of term | Return or deletion, with a certificate on request | No wording on backups and copies | | Liability and indemnity | Allocation that matches each party's role and risk | One-sided caps that a Swedish court may test for reasonableness | ## Swedish and EU points that change the drafting - International transfers. Sweden is in the EEA, so transfers inside the EEA are free. Transfers to a third country (for example a US sub-processor without an adequacy route) need a transfer tool such as the EU Standard Contractual Clauses plus a transfer impact assessment. Name the sub-processor locations in the DPA so the controller can assess this.

• Language. There is no legal requirement that a DPA be in Swedish. English-language DPAs are common and enforceable, but IMY correspondence and any Swedish court proceedings will be in Swedish, so keep an accurate understanding of the terms on both sides.
• Sensitive and regulated data. The Swedish Data Protection Act and sector statutes (for example the Patient Data Act in healthcare) add rules for certain data. If the processing touches health, employment or public-sector data, check whether a sector law overrides the general position.
• Unreasonable terms. General Swedish contract law, including section 36 of the Contracts Act (Avtalslagen, SFS 1915:218), lets a court adjust a term that is unreasonable. A heavily one-sided liability cap in a DPA can be challenged on that basis. ## A short DPA outline you can adapt 1. Parties and roles (controller, processor).

2. Definitions, aligned to GDPR terms.
3. Subject matter, duration, nature and purpose (often an annex).
4. Categories of data and data subjects (annex).
5. Processor obligations and the documented-instructions rule.
6. Confidentiality.
7. Security measures (Article 32), set out in an annex.
8. Sub-processors: list, authorisation and flow-down.
9. International transfers and the chosen safeguard.
10. Assistance: data subject rights, breach notification, DPIAs.
11. Audit and inspection rights.
12. Return or deletion at end of term.
13. Liability, term and termination, governing law (Swedish law, Swedish courts or arbitration).
14. Annexes: processing details, security measures, approved sub-processors. Always tailor the annexes. A generic DPA with empty annexes is the most common reason one fails a review. ## Common mistakes - Signing a supplier's standard DPA without checking the sub-processor list and transfer locations.

• Leaving breach notification at "without undue delay" with no concrete deadline for the processor.
• Forgetting the annexes that describe the actual data and security measures.
• Treating the DPA as the only document, when the main service agreement still needs to be consistent with it.
• Ignoring that a controller stays responsible to IMY and data subjects even after delegating to a processor. ## Keeping every DPA consistent in one place Most teams do not have one DPA. They have dozens, each with a different sub-processor list, a different breach deadline and a different review date, scattered across inboxes and drives. The work of drafting a DPA from a house template, checking each clause against Article 28, tracking which vendors have signed and when each agreement renews is exactly the work an AI contract workspace can hold in one place: draft from your own standard, flag clauses that drift from it, keep a live timeline of versions and signatures, and surface renewal and review dates as alerts. If that sounds useful, Adira is built around that single-workspace idea. Deeper non-India jurisdiction coverage is on its roadmap; India is the deepest today. This article is general information about Swedish and EU data protection practice and is not legal advice. For a specific agreement, confirm the current statutes and take qualified Swedish advice.