Master Data Processing Agreement: What It Covers and a Template (2026)

What is a master data processing agreement? A master data processing agreement (DPA) is a contract that governs how one organisation (the processor) handles personal data on behalf of another (the controller). It is called "master" when it sits above several services or engagements, so a single DPA covers every current and future processing the processor does for that controller, rather than signing a new one for each project. You need a DPA whenever a vendor touches personal data for you: a payroll provider, a cloud host, an email tool, an analytics service. Under the EU and UK General Data Protection Regulation, a written contract between controller and processor is mandatory, and it must contain specific terms. Many large buyers insist on their own "enterprise DPA" and attach it to the main services agreement. This article is general guidance, not legal advice. Data-protection law varies by jurisdiction and changes over time, so have a qualified professional review any DPA before you rely on it. Last verified October 2026. ## What a DPA must cover under GDPR Article 28 Under Article 28(3) of the EU GDPR (and the equivalent UK GDPR), the contract must set out the subject matter, duration, nature and purpose of the processing, the types of personal data, the categories of data subjects, and the controller's rights and obligations. It must then bind the processor to eight core commitments: 1. Documented instructions. Process only on the controller's recorded instructions.

2. Confidentiality. Ensure anyone handling the data is under a duty of confidence.
3. Security. Apply appropriate technical and organisational measures (Article 32).
4. Sub-processors. Engage another processor only with prior written authorisation, and flow the same obligations down to it.
5. Data subject rights. Help the controller respond to requests from individuals.
6. Compliance support. Assist with security, breach notification, impact assessments and prior consultation (Articles 32 to 36).
7. End of services. Delete or return the data at the controller's choice when the service ends.
8. Audits. Make available the information needed to show compliance and allow audits. A practitioner reading is that omitting any one of these eight points makes the DPA non-compliant, so templates should keep all of them. <!-- [VERIFY] exact statutory wording against EUR-Lex / legislation.gov.uk before relying on it --> ## Enterprise DPA vs vendor DPA - A vendor DPA is the processor's standard terms, drafted to protect the vendor. It tends to allow broad sub-processing, limited audit rights and the vendor's own security description.

• An enterprise DPA is the controller's own paper, drafted to protect the buyer. It tends to tighten sub-processor consent, strengthen audit and breach-notice timelines, and pin down data location and retention. Whoever's paper wins, the Article 28 content must be present. The negotiation is usually about audit, sub-processor approval, breach-notice timing, liability and international transfers, not about whether those clauses exist at all. ## Master data processing agreement template Copy the block below and fill the bracketed fields. This is a skeleton of the required terms, not a complete contract. ``` MASTER DATA PROCESSING AGREEMENT This DPA is entered into on [DATE] and forms part of the [Services Agreement] between: [CONTROLLER], [address] ("Controller") and [PROCESSOR], [address] ("Processor"). 1. DEFINITIONS Terms such as "personal data", "processing", "controller", "processor" and "data subject" have the meanings in [applicable data protection law]. 2. SCOPE AND ROLES (Annex 1) The subject matter, duration, nature and purpose of the processing, the types of personal data and categories of data subjects are set out in Annex 1. The Controller is controller; the Processor is processor. 3. PROCESSOR OBLIGATIONS The Processor will: (a) process only on the Controller's documented instructions; (b) ensure persons authorised to process are bound by confidentiality; (c) implement the security measures in Annex 2; (d) assist the Controller with data subject requests; (e) assist with security, breach notification, impact assessments and consultations. 4. SUB-PROCESSORS (Annex 3) The Processor may engage sub-processors only with the Controller's prior [specific / general] written authorisation, and will impose the same data protection obligations on each. Current sub-processors are listed in Annex 3. 5. PERSONAL DATA BREACH The Processor will notify the Controller without undue delay and within [N] hours of becoming aware of a personal data breach, with the information the Controller needs to meet its own notification duties. 6. INTERNATIONAL TRANSFERS Transfers outside [the UK/EEA] will rely on an approved transfer mechanism [e.g. Standard Contractual Clauses / UK Addendum / adequacy], described in Annex 4. 7. AUDIT The Processor will make available information to demonstrate compliance and allow audits by the Controller or its auditor, [on reasonable notice / no more than once a year except for cause]. 8. DELETION OR RETURN On the end of services, the Processor will, at the Controller's choice, delete or return all personal data and delete existing copies, unless law requires storage. 9. LIABILITY Liability under this DPA is subject to the limits in the [Services Agreement]. Annex 1: Details of processing Annex 2: Security measures Annex 3: Approved sub-processors Annex 4: Transfer mechanism Signed for Controller: ______ Signed for Processor: ______

- **Sub-processors (clause 4).** Decide between specific approval (you sign off each one) and general approval with a right to object. Enterprise buyers usually want notice of changes and a window to object.
- **Breach notice (clause 5).** Set a concrete timeline. Controllers often ask for 24 to 72 hours so they can meet their own regulator deadlines.
- **International transfers (clause 6).** Name the mechanism you actually rely on, such as Standard Contractual Clauses plus the UK Addendum, and keep it current as adequacy decisions change.
- **Deletion or return (clause 8).** Make the choice the controller's, and carve out only what law forces you to keep. ## Common mistakes to avoid - Signing a services agreement with no DPA at all, which is itself a breach where GDPR applies.
- Leaving Annex 1 blank, so the scope of processing is undefined.
- Vague sub-processor terms that let the processor add new vendors silently.
- No breach-notice timeline, so the controller cannot meet its own deadlines.
- An outdated transfer clause that still relies on a mechanism no longer valid. ## A note on jurisdiction What a DPA must contain varies by jurisdiction. The eight-point structure above comes from the EU and UK GDPR. Other regimes have their own rules: India's Digital Personal Data Protection Act, 2023 sets duties on data fiduciaries and processors, and US state laws such as the California Consumer Privacy Act (as amended by the CPRA) require specific contract terms with service providers. Privacy policies and DPAs often need to speak to several of these at once. The safe approach is to map each regime that applies to your data and make sure the DPA satisfies the strictest, rather than assume one template fits all. <!-- [VERIFY] current DPDP Act rules and state-law contract requirements as of 2026 --> ## Where a contract workspace helps A template gives you one compliant DPA; keeping a whole vendor base compliant is the harder part. You hold sub-processor lists, security annexes and transfer mechanisms current across many vendor DPAs, check an incoming DPA against your required terms before signing, and track breach-notice deadlines and audit rights everywhere. An AI workspace tuned to how your company processes data can draft a DPA, flow a change through its linked clauses, flag where a vendor's paper is missing an Article 28 point, and keep audit windows and renewal dates in view. [Adira](https://adiralaw.com) is one such workspace for data processing paperwork. The template is enough to start a compliant DPA on its own.