DPA Negotiation Playbook (2026)

What a DPA is and when you need one A data processing agreement (DPA) is the contract that governs how a processor handles personal data on behalf of a controller. Under the EU and UK GDPR, Article 28 requires a written contract whenever a controller uses a processor, and it sets out a list of terms that contract must contain. In practice you negotiate a DPA whenever you buy or sell a service that touches personal data, from a payroll provider to a cloud platform. This playbook covers the terms that matter, the usual positions, and sensible fallbacks. It is general guidance, not legal advice, and it focuses on the GDPR and UK GDPR framework. Where you process data under another regime (for example US state privacy laws), verify the local requirements before relying on this. Have a qualified professional review a material DPA. ## The mandatory Article 28 terms Article 28(3) requires the contract to bind the processor on a defined set of points. These are not optional, so the negotiation is about how they are worded, not whether they appear. - Processing only on documented instructions from the controller.

• Confidentiality commitments from everyone authorised to process the data.
• Security measures appropriate to the risk (Article 32).
• Sub-processor rules (see below).
• Assistance to the controller with data subject rights requests.
• Assistance with security, breach notification and data protection impact assessments.
• Deletion or return of the data at the end of the service.
• Audit and information rights, so the controller can verify compliance. The DPA must also record the subject matter, duration, nature and purpose of the processing, the types of personal data and categories of data subject. Get this schedule right, because it defines the scope of everything else. ## Term by term positions and fallbacks Scope and instructions. Controllers want processing strictly limited to their written instructions and the stated purpose. Processors want room to process as needed to provide the service and to meet their own legal duties. Fallback: tie instructions to the service description and allow processing required by law, with notice to the controller unless the law forbids it. Sub-processors. Controllers prefer prior specific consent for each new sub-processor. Processors want general authorisation with a right to change. The common landing: general authorisation, a published list, advance notice of changes (often 30 days), and a right for the controller to object on reasonable data protection grounds. The processor must flow down equivalent Article 28 obligations to each sub-processor and stays liable for them. Security. Controllers push for specific, listed measures. Processors prefer a commitment to measures appropriate to the risk with a right to update them. Fallback: an agreed baseline in a schedule, with a no material reduction commitment so the processor cannot weaken protection during the term. Breach notification. Controllers want notice without undue delay and often ask for a fixed clock, for example 24 to 72 hours. Processors resist a short fixed clock and a duty to assess whether the breach is notifiable. Fallback: notice without undue delay and in any event within a set number of hours of the processor becoming aware, with agreed information to follow as it is confirmed. Audit rights. Controllers want to audit on site. Processors, especially large ones, offer third party certifications and reports instead, with on site audits only on reasonable notice and at the controller's cost. Fallback: certifications and reports first, with a right to a focused audit after a breach or on regulator request. Liability and indemnity. This usually sits in the main agreement, not the DPA. Watch for a DPA that quietly caps or excludes data protection liability, or an uncapped indemnity. Align the DPA liability position with the master agreement and make sure regulatory fines and data claims are addressed consistently. International transfers. Where data leaves the EEA or UK, add the appropriate transfer mechanism, usually the Standard Contractual Clauses (and the UK Addendum or IDTA for UK data), with a transfer impact assessment where required. The Article 28 clauses and the transfer clauses are separate instruments, so include both. Deletion and return. Agree what happens to the data at the end: return, deletion, or both, within a set period, with a certificate of deletion on request and a carve out for copies the processor must keep by law. ## Preparation and common traps Before you negotiate, map the processing: what data, whose, why, where, and which sub-processors. Decide your non negotiables (often security baseline, breach notice and sub-processor control for controllers; audit scope and liability for processors). Common traps: a DPA that contradicts the main agreement, a missing transfer mechanism, an audit clause that is unworkable, a breach clock no one can meet, and a sub-processor list that is already out of date on day one. ## One workspace for draft, review, track and govern A DPA is highly standardised on its face, and the fights are always in the detail: sub-processors, audit scope, the breach clock and transfers. The deeper problem is that this work is usually split across a drafting tool, a review tool, a spreadsheet of dates, and email threads, so nothing stays connected and knowledge lives in people's heads. A single AI workspace tuned to your company takes a different approach. You draft, understand, edit, track and govern every contract in one place, where each document is modelled as a structured clause tree rather than flat text, so the system can show per clause risk, flag where a draft departs from your standard positions, let you edit a clause in plain language, and keep a live timeline of what changed and when. Because it learns from your own documents and preferred terms, the output sounds like your company rather than a generic template. Adira is built around that idea. A single-pane view of upcoming obligations and overall legal health is on its roadmap. The point is not another tool to check, it is to make the judgement on this page a repeatable company standard instead of something each person re-derives on every deal.