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

A data processing agreement, or DPA, is the contract that governs how a processor handles personal data on behalf of a controller. In Italy this contract is driven by the GDPR, which makes the agreement mandatory, and supplemented by the national Privacy Code and the oversight of the Italian data protection authority, the Garante. This guide explains the local law, the clauses the agreement must contain, and a template outline. It is general information, not legal advice. ## What law governs data processing in Italy? Italy applies the GDPR (Regulation (EU) 2016/679) directly, supplemented by national law: - The Italian Privacy Code (Legislative Decree No. 196 of 2003), as amended by Legislative Decree No. 101 of 2018 to align it with the GDPR. The Privacy Code fills gaps the GDPR leaves to member states, for example on certain processing and age of consent.

• The Garante per la protezione dei dati personali, Italy's supervisory authority, which enforces the rules, issues guidance and can impose fines. The GDPR does most of the work on controller and processor contracts, so the DPA must track the GDPR directly, with the Privacy Code checked for Italian-specific points. ## When is a DPA mandatory? Under Article 28 of the GDPR, whenever a processor processes personal data on behalf of a controller, the processing must be governed by a written contract or other legal act that binds the processor to the controller. This is not optional. Any arrangement where a vendor handles personal data for a customer, cloud, SaaS, payroll, analytics, support, needs a DPA. ## The mandatory clauses under Article 28 Article 28(3) lists the terms a DPA must contain. The processor must: - Process personal data only on documented instructions from the controller, including on international transfers.
• Ensure persons authorised to process are bound by confidentiality.
• Take all security measures required under Article 32.
• Respect the conditions for engaging a sub-processor, including prior authorisation and flow-down of equivalent obligations.
• Assist the controller to respond to data subject rights requests.
• Assist the controller with security, breach notification, impact assessments and prior consultation.
• At the controller's choice, delete or return the data at the end of the service and delete copies.
• Make available the information needed to demonstrate compliance and allow and contribute to audits. A DPA that omits any of these does not meet Article 28, so use the list as a checklist. ## International transfers If the processor or a sub-processor sends personal data outside the European Economic Area, the DPA must address a valid transfer mechanism under Chapter V of the GDPR, usually the European Commission's Standard Contractual Clauses, together with any transfer impact assessment. Italian supervisors, like others in Europe, scrutinise whether controllers can demonstrate accountability down the processing chain, including sub-processors, so transfer terms should be specific rather than generic. ## Key clauses a DPA should contain | Clause | Purpose | | --- | --- | | Roles and definitions | Identify controller and processor, define processing and personal data | | Subject matter and duration | Nature, purpose and length of processing | | Categories of data and subjects | What data and whose | | Documented instructions | Processing only on the controller's instructions | | Confidentiality | Bind authorised personnel | | Security measures | Article 32 technical and organisational measures | | Sub-processors | Authorisation and flow-down | | Data subject rights | Assistance to the controller | | Breach notification | Prompt notice to the controller | | International transfers | Transfer mechanism under Chapter V | | Audit | Information and audit rights | | Return or deletion | Choice of deletion or return at the end | | Liability | Allocation between the parties | ## A template outline you can adapt 1. Parties, roles and definitions

2. Subject matter, nature, purpose and duration
3. Categories of personal data and data subjects
4. Processing only on documented instructions
5. Confidentiality of personnel
6. Security measures under Article 32
7. Sub-processors and flow-down
8. Assistance with data subject rights
9. Assistance with breach, impact assessments and consultation
10. Personal data breach notification
11. International transfers and Standard Contractual Clauses
12. Audit and demonstration of compliance
13. Deletion or return of data
14. Liability, term and governing law ## Common mistakes to avoid - A DPA that does not cover every Article 28(3) requirement.

• Generic transfer language with no actual mechanism or impact assessment.
• No real sub-processor authorisation or flow-down of obligations.
• Security measures described so vaguely they cannot be audited.
• Ignoring Italian Privacy Code specifics for certain categories of data. ## Keeping data terms consistent across contracts Most organisations sign many DPAs, each with slightly different sub-processor lists, breach windows and transfer bases. Keeping them consistent, and knowing which version is the signed one, is the real operational burden, and it is the same work as every other contract: draft, review the risky terms, track the dates, keep versions straight. Teams increasingly do that in one connected workspace instead of scattered files. Adira is an AI contract workspace that drafts, reviews per-clause risk, and tracks obligations in one place. Adira is India-first today, and deeper non-India jurisdiction support, including Italy, is on its roadmap, so confirm GDPR and Italian Privacy Code specifics with local counsel. This article is general information and not legal advice.