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

A Data Processing Agreement (DPA) in Finland is the contract that must exist whenever one business (the controller) has another (the processor) handle personal data on its behalf. It is not optional: under the GDPR a controller may use only a processor bound by a written contract that meets Article 28. This guide covers the law that applies in Finland, the clauses the DPA must contain, a skeleton, and the mistakes to avoid. This is general information, not legal advice. Confirm the detail with a qualified Finnish data protection lawyer before you rely on a DPA. ## When you need a DPA in Finland You need one in every controller-to-processor relationship: a SaaS vendor hosting customer data, a payroll bureau, a cloud provider, a marketing agency running your lists. If the supplier only touches personal data as an incidental by-product and does not process it for you, the analysis differs, but the safe default is to put a DPA in place. ## The law that applies in Finland ### The GDPR (Regulation 2016/679) The General Data Protection Regulation applies directly in Finland. Article 28 lists the terms every DPA must contain, and Article 28(3) sets out the specific obligations the processor must accept. These are the core of the document. ### The Data Protection Act (1050/2018) Finland's national Data Protection Act (Tietosuojalaki, 1050/2018) supplements the GDPR. It has applied since 1 January 2019 and replaced the old Personal Data Act (523/1999). It sets national detail, for example on the processing of personal identity codes and the age of consent, and names the supervisory authority. ### The supervisory authority and employee data The Office of the Data Protection Ombudsman (Tietosuojavaltuutetun toimisto) is the national supervisory authority. Where employee personal data is processed, the Act on the Protection of Privacy in Working Life (759/2004) adds separate rules that a workplace DPA should respect. ## Key clauses to include (the Article 28 checklist) - Subject matter and duration. What is processed and for how long.

• Nature and purpose. Why the processor handles the data.
• Type of personal data and categories of data subject. Set out in a schedule.
• Documented instructions. The processor acts only on the controller's written instructions, including on international transfers.
• Confidentiality. Everyone authorised to process data is under a duty of confidence.
• Security. Technical and organisational measures appropriate to the risk (Article 32), listed in a schedule.
• Sub-processors. No sub-processor without prior authorisation, and the same obligations flow down by contract.
• Data subject rights. The processor assists the controller in answering access, erasure, and other requests.
• Breach notification. The processor notifies the controller without undue delay after becoming aware of a breach.
• Deletion or return. At the end of the service, data is deleted or returned at the controller's choice.
• Audits and information. The processor makes available the information needed to show compliance and allows audits.
• International transfers. If data leaves the EEA, name the transfer tool, usually the EU Standard Contractual Clauses, plus any supplementary measures. ## A usable DPA skeleton 1. Parties and definitions (align with GDPR terms)

2. Subject matter, duration, nature, and purpose
3. Processing only on documented instructions
4. Confidentiality undertakings
5. Security measures (reference Schedule)
6. Sub-processing and the authorisation process
7. Assistance with data subject rights
8. Assistance with security, breach, and impact assessments
9. Personal data breach notification
10. Deletion or return of data on termination
11. Audit and information rights
12. International transfers and the transfer mechanism
13. Liability and allocation between the parties
14. Schedules: processing details, security measures, approved sub-processors ## Common mistakes to avoid - Relying on a confidentiality clause alone. An NDA does not meet Article 28. A standalone or embedded DPA is required.

• Blank schedules. The processing details, security measures, and sub-processor list are the substance. Leaving them empty makes the DPA unenforceable in practice.
• Ignoring transfers. If the processor or its sub-processors sit outside the EEA, name a valid transfer tool. Silence is a gap.
• No breach timeline discipline. The processor must notify without undue delay. Vague wording slows the controller's own 72-hour clock to the authority.
• Forgetting Finnish specifics. Personal identity codes and employee monitoring carry extra national rules that a generic EU template may miss. ## One workspace for your Finnish data contracts A DPA is never a single document: it links to a main services contract, a security schedule, and a sub-processor list that changes over time. Keeping the DPA, its schedules, and the renewal and audit dates together, rather than scattered across email, is what keeps you able to prove compliance. Adira is an AI legal workspace built for that: draft, review, and track linked contracts in one place, with each clause modelled so a change flows through consistently. Adira is deepest in Indian law today, and wider jurisdiction depth, including the Nordics, is on its roadmap, so treat non-India output as a draft for local counsel to confirm. Get the Article 28 terms and the Finnish specifics right first, fill the schedules properly, and keep the trail in one place.