Data Processing Addendum Template and How to Draft One (2026)

What is a data processing addendum, and when do you need one? A data processing addendum (DPA) is a contract, usually attached to a main services agreement, that governs how one party processes personal data on behalf of the other. The party that decides why and how data is used is the controller (or, in India's law, the data fiduciary); the party that processes data on the controller's instructions is the processor. The DPA sets the rules: what data, for what purpose, for how long, with what security, who else may touch it, and what happens at the end. You need one whenever a supplier handles personal data for you, which is almost every modern vendor: a cloud host, a payroll provider, an email tool, a CRM, an analytics service. Under the EU and UK GDPR, a DPA is not optional. Article 28 of the GDPR requires a written contract with a defined set of terms whenever a processor processes personal data for a controller, and the same obligation flows down whenever a processor uses a sub-processor. <!-- [VERIFY: confirm current GDPR Article 28 text and latest SCC requirements before relying] --> Last verified October 2026. This article is general guidance, not legal advice. Data protection law varies by jurisdiction and changes often, so have a qualified professional review any DPA before you rely on it. ## Data processing addendum template Copy the block below and fill the bracketed fields. It is written to track the GDPR Article 28 requirements and to work as an addendum to a main agreement. ```

DATA PROCESSING ADDENDUM This Data Processing Addendum ("DPA") forms part of the [Agreement] dated [DATE] BETWEEN: [CONTROLLER NAME] ("Controller") AND [PROCESSOR NAME] ("Processor") 1. DEFINITIONS Terms such as "personal data", "processing", "controller", "processor", "data subject" and "sub-processor" have the meanings in the applicable data protection law. "Applicable Law" means [EU GDPR / UK GDPR / India's Digital Personal Data Protection Act, 2023 / other], as relevant. 2. SCOPE AND DETAILS OF PROCESSING (Annex 1) The Processor processes personal data only to provide the services. The subject matter, duration, nature and purpose of processing, the types of personal data and the categories of data subjects are set out in Annex 1. 3. PROCESSOR OBLIGATIONS The Processor will: (a) process personal data only on the Controller's documented instructions, including on international transfers, unless required by law (and will tell the Controller of such a legal requirement, where permitted); (b) ensure persons authorised to process the data are bound by confidentiality; (c) implement appropriate technical and organisational security measures (Annex 2); (d) respect the conditions in clause 4 for engaging sub-processors; (e) assist the Controller, by appropriate measures, to respond to data subject rights requests; (f) assist the Controller with security, breach notification, impact assessments and prior consultation with regulators; (g) at the Controller's choice, delete or return all personal data at the end of the services, and delete existing copies unless the law requires storage; (h) make available information needed to show compliance and allow and contribute to audits and inspections; (i) immediately tell the Controller if an instruction appears to infringe Applicable Law. 4. SUB-PROCESSORS The Processor will not engage a sub-processor without the Controller's [prior specific / general written] authorisation. Where general, the Processor will give advance notice of changes and a chance to object. The Processor imposes the same data protection obligations on each sub-processor and remains liable for its sub-processors. 5. PERSONAL DATA BREACH The Processor will notify the Controller without undue delay after becoming aware of a personal data breach, with the information the Controller needs to meet its own notification duties. 6. INTERNATIONAL TRANSFERS The Processor will not transfer personal data outside [permitted region] without an appropriate safeguard (such as Standard Contractual Clauses, an adequacy decision or equivalent) and the Controller's authorisation. 7. LIABILITY AND TERM This DPA runs for as long as the Processor processes personal data for the Controller. Liability is as set out in the [Agreement]. Annex 1: Details of processing (subject matter, duration, nature, purpose, data types, data subjects). Annex 2: Technical and organisational security measures. Annex 3: Approved sub-processors. Signed for the Controller: __________ Signed for the Processor: __________

- **Processor obligations (clause 3).** These track the mandatory Article 28(3) terms: process only on documented instructions, confidentiality, security, sub-processor conditions, help with data subject rights, help with breach and impact-assessment duties, delete or return data at the end, and allow audits. Do not water these down.
- **Sub-processors (clause 4).** Decide whether you require specific approval for each sub-processor or give general authorisation with notice and a right to object. Simply posting a list on a website without advance notice may not satisfy the law.
- **Breach notification (clause 5).** Require notice "without undue delay" so you can meet your own reporting deadlines. Your own deadline to a regulator may be short, so you need the processor to move fast.
- **International transfers (clause 6).** If data leaves its home region, require an appropriate safeguard such as Standard Contractual Clauses, and do not leave transfers unaddressed.
- **Security (Annex 2).** Attach a real description of technical and organisational measures (encryption, access controls, testing), not a one-line promise. ## Common mistakes to avoid - A blank or generic Annex 1, so the processing is never actually described.
- Weak sub-processor controls, or learning of new sub-processors only from a website.
- No clear breach-notification timing, leaving you unable to meet your own deadline.
- Ignoring international transfers when the vendor hosts or supports data abroad.
- A security annex that says "industry-standard" and nothing specific. ## A note on jurisdiction Data protection law varies by jurisdiction and is changing fast. Under the EU GDPR and UK GDPR, Article 28 makes a written DPA with specified terms mandatory, and cross-border transfers need a safeguard such as Standard Contractual Clauses. In India, the Digital Personal Data Protection Act, 2023 (DPDP Act) is being brought into force in phases, with the DPDP Rules, 2025 notified and most core obligations scheduled to take effect later; it uses the terms "data fiduciary" and "data processor", and the fiduciary stays accountable for processing done by its processors, so flow-down obligations in a DPA remain good practice. <!-- [VERIFY: confirm the exact DPDP commencement dates and processor-specific provisions against the official MeitY/Gazette text before relying] --> Last verified October 2026. The US has a patchwork of state laws (such as the CCPA/CPRA), and Singapore, Australia and others have their own regimes. The safe approach is to name the applicable law in the DPA, track the GDPR Article 28 structure as a strong baseline, and take local advice, saying "varies by jurisdiction" rather than assuming one rule fits all. ## Where a contract workspace helps A template gets you a sound DPA. The ongoing work is everything after: keeping DPA terms consistent across every vendor, checking each vendor's own DPA for weak sub-processor, breach or transfer terms before you sign, tracking which processors you use and where they send data, and keeping versions straight as laws change. Drafting a DPA tuned to your business, reading a vendor's own DPA and flagging weak sub-processor, breach or transfer terms in plain language, editing linked clauses so a change ripples through, and keeping obligations and review dates in view is the kind of job one AI workspace can hold in a single place, and [Adira](https://adiralaw.com) is one such tool. This template alone is enough to put a fair DPA in place; one connected place simply keeps drafting, review and tracking together instead of scattered.