How to Write a GDPR Data Processing Agreement (2026): The Complete Guide

A Data Processing Agreement is the contract that makes it lawful for a processor to touch personal data on a controller’s behalf. GDPR Article 28(3) says it plainly: processing by a processor shall be governed by a contract or other legal act that binds the processor to the controller. No contract, no lawful processing — and liability flows straight back up the chain.

The DPA does three distinct jobs at once, and understanding them separately is what makes the drafting sensible. First, it documents the roles: who decides the purposes and means (controller), who carries out the processing under instructions (processor). That classification is not cosmetic; it determines which obligations attach to which party under the GDPR and who is on the hook when something goes wrong. Second, it allocates the eight specific duties that Article 28(3) pins on the processor: documented instructions, confidentiality, security, sub-processor controls, data-subject-rights assistance, compliance assistance, deletion or return, and audit. Skip one and the contract fails on its face. Third, it operationalises the rest of the GDPR for this specific relationship: what data, what purposes, what security measures, what sub-processors, what breach-notification timeline, whether data leaves the EEA and under what transfer mechanism.

Most DPAs fail not on the structural bones — almost every template on the internet has the eight clauses in some form — but on the operational layer: the Annex I description of processing is vague, the Annex II security measures are aspirational, the Annex III sub-processor list is empty or stale, the transfer mechanism is unspecified, the TIA has not been done. A DPA that passes the eight-clause structural test and fails the operational test is the kind of document that looks compliant on a shelf and disintegrates in a supervisory-authority audit.

The 2026 context matters here too. Supervisory authorities across the EEA have moved from structural review (“do you have a DPA?”) to substantive review (“does your Annex II match what your infrastructure actually does?”). Audit requests now routinely ask for the Annex III sub-processor list, the TIA, the sub-processor-notification log, and evidence of the deletion workflow at end of processing. A DPA drafted to survive that level of scrutiny looks different from one drafted for a signature page. This guide is about the former.

Before you draft anything, decide what relationship you are papering. The three live options under GDPR are controller-to-processor (Article 28), joint controllers (Article 26), and controller-to-controller (no processor relationship; the parties transact at arm’s length as independent controllers). The obligations, the contract structure, and the liability flows are different for each.

Controller-to-processor is the default for most vendor relationships. The controller decides why and how data is processed; the processor executes those decisions on instructions. Cloud hosting, email delivery, CRM, payroll, customer support, analytics that the customer configures — these are almost always processor relationships. The defining test is whether the vendor has its own purposes for the data (independent of the customer’s) or merely executes the customer’s. A hosting provider that stores your data because you told it to is a processor. A hosting provider that then analyses your data to improve its own product without your specific authorisation has tipped into being a controller for that second purpose — and that is a different contract.

Joint controllers appear when two organisations jointly determine the purposes and means of processing. The classic example is a co-branded loyalty programme where both partners decide what data to collect and how to use it; a shared research programme where both institutions define the study parameters; a platform-plus-publisher arrangement where both jointly shape how user data flows. Joint controllers are governed by Article 26, not Article 28, and the contract is a Joint Controller Arrangement rather than a DPA. The essential-content summary of that arrangement has to be made available to data subjects, and — this is the trap — data subjects can exercise rights against either joint controller regardless of the internal allocation.

Getting the classification wrong is the single most common DPA drafting mistake. A joint-controller relationship papered as a controller-processor DPA is legally defective and exposes both sides to residual liability. An independent-controller relationship papered as a DPA over-binds the receiving party and can create purpose-limitation problems if the receiving party has legitimate independent uses of the data. The practical test: if both parties make substantive decisions about the data — not just how to implement the other’s decisions — you are probably joint controllers. If you are unsure, err toward the classification that imposes more obligations, because the remedy for under-documenting is worse than the remedy for over-documenting.

Article 28(3) gives you a list of eight things the processor contract must contain. Each is worth understanding individually because the drafting traps are different for each.

(a) Documented instructions. The processor processes only on the controller’s documented instructions, including for transfers to third countries. The Main Agreement plus the DPA plus the controller’s written instructions from time to time are the complete instructions — that phrasing is important, because it closes the loop on what counts. The processor must also inform the controller if it is legally required to process beyond the instructions (unless that notification is itself prohibited, which is rare). The drafting trap: processors that reserve a right to process for their own “legitimate business purposes” without defining those purposes have stepped out of processor status, into controller status, for that processing — and the contract is misclassified.

(b) Confidentiality. Personnel authorised to process the data must be under a confidentiality obligation, statutory or contractual. For most companies this is an existing employment term and the contract can cross-reference. For contractors and sub-processors it often needs explicit language.

(c) Article 32 security. The processor implements appropriate technical and organisational measures — the ones listed in Annex II. The statute does not prescribe specific measures; it requires they be appropriate to the risk. The drafting trap: aspirational Annex II content. If you list ISO 27001 certification and you have not been audited, you have misrepresented a material term. If you list encryption at rest and you have not actually enabled it on the systems in scope, same problem. Annex II should be a factual description of what the processor actually does, not what it plans to do.

(d) Sub-processors. The processor engages sub-processors only with the controller’s prior authorisation — general or specific — and flows the same data-protection obligations through to the sub-processor by written contract. The processor remains fully liable to the controller for the sub-processor’s performance. Section 5 of this guide covers the general-vs-specific choice in detail.

(e) Data-subject-rights assistance. Taking into account the nature of the processing, the processor assists the controller in responding to Chapter III rights requests: access, rectification, erasure, portability, restriction, objection, automated decision-making. The obligation is to provide assistance, not to be a substitute for the controller. EDPB Guidelines 07/2020 frame this as reasonable cooperation. The drafting question is who pays for the assistance; Section 9 of this guide covers it.

(f) Compliance assistance. The processor assists the controller in complying with Articles 32 to 36: security, breach notification, DPIAs, prior consultation. Again, “taking into account the nature of the processing and the information available to the processor.” The operational layer here is the breach-notification chain discussed in Section 8.

(g) Deletion or return. At the end of processing, at the controller’s choice, the processor returns or deletes all personal data and any existing copies, unless EU or Member State law requires storage. The drafting trap: backup copies. Most production infrastructure retains data in rolling backups for 30 to 90 days; that retention is usually unavoidable at the technical level. The market-standard solution is to acknowledge backup retention explicitly and confirm that backup copies remain subject to the confidentiality and security obligations until they are overwritten in the ordinary course. A clause that promises instant deletion of all backups is either untrue or describes infrastructure you do not have.

(h) Audit rights. The processor makes available to the controller all information necessary to demonstrate compliance and allows for audits, including inspections, conducted by the controller or a mandated auditor. Section 10 covers how this is actually operationalised — usually some combination of third-party reports, questionnaires, and on-site rights.

When personal data leaves the EEA for a country without an adequacy decision, Article 46 requires a transfer mechanism. In practice, for the vast majority of EU exporters, that means the Standard Contractual Clauses — Commission Implementing Decision (EU) 2021/914 of 4 June 2021. The 2021 SCCs replaced the older 2010 versions, and they are structured as a modular toolkit, not a single template.

Module 1 is Controller-to-Controller. Module 2 is Controller-to-Processor, the most common. Module 3 is Processor-to-Processor — the one you use when you are a processor sub-contracting data outside the EEA to a further sub-processor. Module 4 is Processor-to-Controller, less common and for specific scenarios where the processor sends data back to a controller outside the EEA.

The practical implication: the module you incorporate depends on your role and the downstream role, not on the deal size or the industry. If you are a European customer signing with a US SaaS vendor that does not hold EU-US DPF certification, and the vendor will process your data in the US, you need Module 2. If that vendor in turn uses a sub-processor in a third country that is not EEA-adequate and not covered by the DPF, the vendor needs Module 3 with that sub-processor. The modules are not substitutable — Module 2 clauses are written for a controller-processor relationship, and using them for a processor-sub-processor relationship misrepresents the parties’ obligations.

The SCCs must be used in their entirety. You can add supplementary provisions, but you cannot omit or modify the core clauses. The Annex I (parties, description of processing, competent supervisory authority), Annex II (technical and organisational measures), and Annex III (sub-processors, for Module 2 and 3) have to be completed as part of the incorporation. The DPA generator treats these as dual-purpose: the same Annex I, II, and III that the DPA builds serve as the SCC annexes where SCCs are incorporated.

Three elections in the SCCs you have to make. Clause 7 (docking) controls whether additional entities can accede to the SCCs later; most commercial DPAs leave it in as applicable because it makes adding affiliates painless. Clause 17 specifies governing law; for EU exports this is typically the law of the exporter’s EU Member State, commonly Ireland for pan-EU operations. Clause 18 specifies forum; typically the same jurisdiction. The competent supervisory authority in Annex I.C is either the exporter’s lead supervisory authority under Article 56 or the authority of the Member State whose law governs the transfer.

An incorporation-by-reference clause in the DPA — “the SCCs are hereby incorporated and form an integral part of this DPA” — is how most commercial drafting handles the mechanics. That avoids a physical attachment while making the SCCs operative. A conflict-order clause confirms that if the DPA and the SCCs conflict, the SCCs prevail — this is required by Clause 5 of the SCCs themselves and should be expressly mirrored in the DPA.

Brexit produced a parallel UK GDPR regime with the Information Commissioner’s Office as the supervisory authority. For restricted transfers from the UK to a country without UK adequacy, the ICO issued two alternative instruments in March 2022: the International Data Transfer Agreement (IDTA) and the UK Addendum to the EU SCCs. Either works; neither is required; the choice is operational.

The IDTA is a standalone instrument — a full contract for UK-only restricted transfers. It replaces the old pre-Brexit SCCs for UK flows. Use it when your data flows are UK-only and you have no EU exposure to co-ordinate with.

The UK Addendum is the more common choice for multinationals. It is a short document (four tables) that sits on top of the EU SCCs 2021/914 and adapts them for UK law — substituting UK GDPR references, designating the ICO as competent supervisory authority, and resolving the jurisdictional differences. For any organisation already operating under the EU SCCs, the Addendum avoids maintaining two separate clauseworks. The drafting is mechanical: you incorporate the EU SCCs by reference, incorporate the UK Addendum on top of those, and identify which Tables (1 = Parties, 2 = the EU SCCs as adopted, 3 = annex information, 4 = termination on ICO changes) each party completes.

As of April 2026, the UK maintains an adequacy decision covering transfers to the EEA (so EEA-to-UK and UK-to-EEA flows are adequacy-based, no SCCs or IDTA needed) and the UK Extension to the EU-US Data Privacy Framework (which permits UK data to flow to DPF-certified US organisations that have also extended their certification to UK data). Those are the only UK adequacy flows of practical importance; for everything else the IDTA or Addendum is required.

The UK equivalent of the Schrems II TIA is the Transfer Risk Assessment (TRA), with ICO guidance published in 2022 and updated since. The TRA asks structurally similar questions to the TIA but has its own template and should be completed to UK standards when the UK is the exporter. A common shortcut for multinationals is to complete a single combined TIA/TRA document covering both regimes — legal under both as long as it meets both sets of content requirements.

On 16 July 2020, the CJEU issued its decision in Case C-311/18 — Data Protection Commissioner v. Facebook Ireland Limited and Maximillian Schrems, universally called Schrems II. The court invalidated the EU-US Privacy Shield (the predecessor to the current DPF) and upheld the SCCs, but subject to a condition: exporters relying on the SCCs must verify, on a case-by-case basis, whether the destination country’s law and practice provide an essentially equivalent level of protection to that guaranteed within the EEA, and must implement supplementary measures if not.

That verification is the Transfer Impact Assessment. The authoritative guidance is EDPB Recommendations 01/2020 (adopted June 2021), which lays out a six-step methodology: know your transfer, identify the transfer tool, assess the law and practice of the destination country, identify and adopt supplementary measures, formalise procedural steps, re-evaluate at appropriate intervals. The output is a documented TIA that accompanies the transfer and sits in the controller’s GDPR accountability file.

Four supplementary measures categories are now standard. Technical measures are the strongest: end-to-end encryption with keys controlled by the exporter, pseudonymisation of direct identifiers prior to transfer, and split processing where no single jurisdiction holds complete data. Contractual measures include notification of government access requests where legally permitted, transparency reporting, and express commitments to challenge unlawful requests. Organisational measures include strict internal access policies, data minimisation, and documented purpose limitation. The fourth category, “alternative measures” in the EDPB language, captures whatever else fits the specific transfer.

The EU-US Data Privacy Framework, adopted on 10 July 2023 by the European Commission, provides an adequacy basis for transfers to US organisations that have self-certified under the framework. In practical effect, this removes the Schrems II TIA requirement for transfers to DPF-certified recipients for the categories covered by the certification. As of April 2026, the DPF remains in force — it survived its first legal challenge in September 2024 when the EU General Court dismissed the case brought by French MEP Philippe Latombe, though Latombe’s appeal to the CJEU was filed in October 2025 and remains pending. The October 2024 first periodic review by the European Commission concluded that the DPF continues to ensure an adequate level of protection.

Two practical implications for 2026 DPA drafting. First, DPF certification meaningfully simplifies transfers: if your US vendor is DPF-certified for the data categories in scope, the transfer can rely on the DPF adequacy without SCCs or a TIA. But the DPF is structurally fragile — it rests on US Executive Order 14086, which a future administration could revoke, and on the CJEU’s resolution of the Latombe appeal. Best-practice drafting in 2026 treats the DPF as primary and the SCCs as fallback in the same agreement, so that lapsed or invalidated certification does not leave the transfer exposed. Second, for transfers to non-DPF-certified recipients or for data categories outside the certification scope, the full Schrems II TIA regime applies — there is no general exception for “low-risk” or “small-volume” transfers.

Article 28(2) and 28(3)(d) give the controller two authorisation models for sub-processors. Specific authorisation requires the processor to get the controller’s written consent for each individual sub-processor before engaging that sub-processor. General authorisation lets the controller authorise sub-processors generally, with the processor obliged to notify the controller of additions or replacements and give the controller an opportunity to object.

In practice, every commercial SaaS DPA uses general authorisation. Specific authorisation is operationally impossible when the vendor relies on dozens of infrastructure sub-processors (AWS, Cloudflare, Stripe, SendGrid, Intercom, Datadog, the list is long), each of which might rotate its own sub-processors. Specific authorisation survives in managed-services and regulated-industry contexts (healthcare, financial services, defence) where the customer has a legitimate interest in per-sub-processor review.

The general-authorisation workflow has three operational pieces. First, a current sub-processor list is published — typically on the vendor’s website — and identified in Annex III as of the effective date. Second, a notification commitment: the vendor notifies the customer (by email, by subscribing them to a notification feed, or by updating the published list) a defined number of days (14 minimum, 30 or 45 market-standard) before a new sub-processor commences processing. Third, an objection right: the customer can object on reasonable data-protection grounds within the notice period, and the vendor must either withdraw the proposed sub-processor, propose an alternative, or allow the customer to terminate the affected service without penalty.

Two drafting traps appear here. The first is the silent objection: contracts that say the customer “may object” without specifying the consequence of objection. That phrase is empty; it has to be paired with a specific remedy. The second is the back-to-back obligation. Article 28(4) requires the processor to impose the same data-protection obligations on the sub-processor as the processor has to the controller. In practice that means flowing through the SCCs (Module 3 for EEA exports to a sub-processor outside the EEA) or equivalent contractual language. The processor remains fully liable to the controller for the sub-processor’s performance — Clause 9(c) of the SCCs puts this in so many words. A sub-processor contract that caps the sub-processor’s liability at something well below the potential GDPR exposure is, from the controller’s perspective, a red flag that the chain-of-responsibility is broken.

The Annex III list itself — who is on it, what purposes they serve, where they process — is increasingly part of audit practice. Supervisory authorities ask for it; customers ask for it as part of vendor diligence. An Annex III that says “various cloud infrastructure providers” is not compliant; an Annex III that names AWS for hosting in EU-West-1, Cloudflare for DDoS protection globally, and Stripe for payment processing in the US is. Keep it current — the list is a live document.

The eight Article 28(3) clauses are structural. The annexes are operational. A DPA that has the eight clauses but an empty or vague set of annexes is the kind of document that fails a supervisory-authority audit in an afternoon. This section is about doing the annexes with enough specificity to survive one.

Annex I — Description of Processing. Three sub-parts: the parties (names, addresses, roles, contacts, DPO or privacy contact), the description of processing (categories of data subjects, categories of personal data, subject matter, nature, purpose, frequency of transfer, duration), and the competent supervisory authority for SCC purposes. The trap is generality. “Personal data processed as part of the Services” is not a description; it is a placeholder. A compliant Annex I names specific categories: contact identifiers (name, email, phone), account and authentication data, customer content, usage telemetry, device identifiers, payment data. It names specific data-subject categories: customers of the controller, end users, employees, prospects. It describes the processing with verbs: hosting, storing, transmitting, accessing, backing up, deleting. The rule of thumb: if someone reading only Annex I could not tell what you do and for whom, the annex is too vague.

Annex II — Technical and Organisational Measures. The Article 32 measures actually implemented. Encryption in transit and at rest, access controls, MFA, logging, incident response, backups with tested restore, personnel training, BCP/DRP. The drafting trap is aspiration. Listing ISO 27001 when you have not been certified, listing SOC 2 when your report is expired, listing pseudonymisation when you do not pseudonymise — these are misrepresentations. Annex II should be factual. If you want to commit to something you do not yet do, do it or leave it out; do not describe future intent as current state. The market-standard closing paragraph of Annex II reserves the right to replace any measure with a functionally equivalent or more stringent measure; this gives operational flexibility without degrading the commitment.

Annex III — Authorised Sub-processors. The list as of the effective date, with purpose and location. As discussed above, this should be real. An Annex III pointing to a public URL where the live list is maintained is market-standard and audit-friendly; the DPA captures the list at the effective date, and the URL keeps it current. The notification-and-objection workflow lives in the DPA body, not the annex.

Annex IV — TIA Summary (where transfers are in scope). Not required by GDPR but market practice is converging on including a TIA summary table in the DPA or as an attachment. The summary captures destination country, transfer tool relied upon, nature-of-data sensitivity assessment, surveillance-law exposure, historical government-access disclosure, supplementary measures, and conclusion. The full TIA sits in the controller’s accountability file; the summary table is the version regulators are likely to see first.

Article 28(3)(h) gives the controller the right to audit the processor, including through on-site inspections. In practice this is one of the most negotiated clauses in any DPA, because the vendor’s operational cost of on-site audits across its customer base is enormous. The market has converged on four models.

Third-party report model (vendor-favourable). The vendor provides its current SOC 2 Type II or ISO/IEC 27001 report on request; that, plus written responses to questionnaires, ordinarily satisfies the Article 28(3)(h) obligation. This works when the vendor has a current, reputable attestation covering the services in scope. Most enterprise SaaS vendors operate on this model.

Questionnaire model (lightweight). The vendor responds to the controller’s reasonable security and data-protection questionnaire once per year. Common for smaller vendors without a SOC 2.

On-site rights model (controller-favourable). The controller can conduct on-site audits on 30 to 60 days’ notice, once per year (more often in the event of a breach or supervisory-authority direction), during business hours, subject to confidentiality. Heavy for vendors — expect pushback.

Combined model (balanced, market-standard). Third-party reports and questionnaires as the default, with on-site rights available on notice. This is what most enterprise SaaS DPAs actually say. It satisfies the controller’s Article 28(3)(h) right while minimising operational friction.

Three drafting details matter regardless of model. First, costs: on-site audit costs are typically borne by the controller, except that the vendor bears the cost of remediating material non-compliance the audit identifies. Second, frequency and scope: most clauses pin audits to once per year (more often after a breach), during business hours, with minimum disruption. Third, auditor confidentiality: the controller’s auditor, if external, signs an NDA before accessing vendor premises or documentation; most DPAs make this explicit.

The EDPB has not directly ruled that any particular model satisfies Article 28(3)(h), but the 2020 Guidelines and a growing body of DPA enforcement decisions suggest that a well-implemented combined model, with genuine questionnaire responses and genuine third-party reports, is adequate for most processing. On-site-only models are rarely enforced and operationally impractical; questionnaire-only models work for low-risk processing but are thin for sensitive data.

Article 28(3)(e) requires the processor to assist the controller with data-subject-rights (DSR) requests. Article 28(3)(f) requires assistance with Articles 32 to 36 obligations — including breach notification, DPIAs, and prior consultation. Neither subsection says the assistance is free, and market practice is genuinely split.

The controller-favourable position is that assistance is part of what the controller is paying for under the Main Agreement, and the DPA should confirm free assistance. The vendor-favourable position is that DSR fulfilment imposes real operational cost — especially for complex configurations, historical data, or high-volume requests — and reasonable reimbursement is appropriate. EDPB Guidelines 07/2020 frame the obligation as one of reasonable cooperation “taking into account the nature of the processing and the information available to the processor.”

Three cost models appear in commercial DPAs. Free assistance for all requests is unusual outside enterprise-tier SaaS and customer relationships with substantial commercial value to the vendor. Limited-free plus costs for bespoke is the most common middle ground: reasonable-volume standard requests free, engineering-heavy custom requests at documented cost following notice. Cost reimbursement for all assistance is common for smaller vendors and for managed-services providers whose configurations make DSR fulfilment operationally heavy.

What is not acceptable — and supervisory authorities have been clear about this — is a fee structure that effectively prevents the controller from meeting its regulatory deadlines. A clause that charges $500 per DSR response from a vendor with thousands of EU end-user accounts is a constructive denial of the Article 28(3)(e) obligation. The scorecard in the generator flags fee structures that look like constructive denials; real-world DPAs with this pattern are regulatory risk.

Breach notification is the other half of this section and carries its own timing. Article 33(1) requires the controller to notify the supervisory authority within 72 hours of becoming aware of a breach. Article 33(2) requires the processor to notify the controller “without undue delay.” That phrase is deliberately unspecific in the statute, and DPAs have to pin it down. Market-standard drafting is 24 to 48 hours, measured from the processor’s awareness. 72 hours is permissive and leaves the controller no margin to meet its own Article 33(1) deadline. 24 hours is aggressive but increasingly common in enterprise DPAs and reflects the operational realities of modern incident response.

The notification content matters too. Article 33(3) specifies what a controller’s notification to the supervisory authority must contain: nature of the breach, categories and approximate numbers of data subjects and records affected, DPO or contact point, likely consequences, measures taken or proposed. The processor’s notification to the controller should contain the same information, to the extent known at the time, so the controller can meet its Article 33(3) obligation. Phased notification — initial notification within 24 hours with updates as information becomes available — is expressly permitted by Article 33(4) and is the operationally realistic structure.

Article 28(3)(g) requires the processor, at the controller’s choice, to delete or return all personal data at the end of processing, along with existing copies, unless EU or Member State law requires storage. The drafting is short; the operational reality is not.

The straightforward part: at the end of the Main Agreement, the controller picks delete or return; the processor executes. If the controller picks return, the data goes back in a commonly used, machine-readable format (CSV, JSON, the vendor’s native export). If the controller picks delete, the processor deletes from production systems and confirms in writing.

The operational reality is that production infrastructure retains data in rolling backups for 30 to 90 days by default, and in many cases longer for regulatory or continuity reasons. Deleting individual records from encrypted rolling backups is technically infeasible for most architectures — backups are snapshots of the whole system. The market-standard solution is to acknowledge this explicitly: the processor deletes the data from production, and any backup copies are retained for the ordinary backup retention period, during which they remain subject to the same confidentiality and security obligations, and are then overwritten in the ordinary course.

This is not a loophole; it is honesty. A clause that promises instantaneous, complete deletion of all backup copies is either a technical misrepresentation or a promise the vendor cannot operationally keep. Supervisory authorities have been pragmatic about this: backup retention subject to secure technical handling and ordinary-course expiry does not violate Article 28(3)(g). What they are less pragmatic about is processors that cannot evidence the deletion workflow at all — undocumented deletion processes are a red flag in audits.

The “unless EU or Member State law requires storage” exception is important and narrow. It covers, for example, financial-records retention under Member State tax law (often 6 to 10 years), employment-record retention, and certain sector-specific obligations. It does not cover the processor’s general business preference to retain data for analytics or improvement. Processor retention under this exception should be (a) identified in Annex I, (b) limited to what the law actually requires, (c) subject to the continuing security obligations, and (d) deleted once the legal retention period expires.

If your DPA template has not been updated since 2023, four categories of change are worth knowing.

DPF status after Latombe and the CJEU appeal. The EU-US Data Privacy Framework, adopted July 2023, survived its first legal challenge when the EU General Court dismissed the Latombe case in September 2024. French MEP Philippe Latombe filed an appeal to the CJEU in October 2025, which remains pending as of early 2026. The European Commission’s first periodic review (October 2024) concluded the DPF continues to ensure adequate protection. Over 2,800 US organisations now hold active DPF certification. For DPA drafting, this means: DPF certification provides a real and currently operative transfer basis, but the DPF is structurally fragile — it rests on US Executive Order 14086, which a future administration can revoke, and on the pending CJEU appeal. Best-practice 2026 drafting treats the DPF as primary and the SCCs as fallback in the same agreement, so that lapse or invalidation does not strand the transfer.

EU AI Act intersection (Article 10 and Article 50). The EU AI Act, in force from August 2024 with staggered application dates, intersects with GDPR at two points relevant to DPAs. Article 10 governs training and testing data for high-risk AI systems, including quality and bias-detection obligations; controllers whose processors train AI systems on controller data have new diligence obligations. Article 50 requires transparency obligations for certain AI systems (watermarking of synthetic content, disclosure of AI interaction, emotion-recognition notices) that may interact with the processor’s role. DPAs in 2026 should identify whether the processing involves AI training or AI-system provision, and — if so — allocate the AI-Act responsibilities between controller and processor. The generator surfaces this via an optional AI-processing flag.

Sub-processor lists as audit evidence. Across EEA supervisory authorities, enforcement decisions in 2024 and 2025 increasingly reference the Annex III sub-processor list as audit evidence. Failing to maintain a current Annex III is now a documented audit finding in multiple jurisdictions. The operational implication: an Annex III pointing to a URL where the list is kept current, with a documented notification log, is increasingly expected.

US state-privacy-law interaction. California’s CPRA and the fifteen-plus subsequent state privacy laws (Virginia, Colorado, Connecticut, Utah, Texas, Florida, Oregon, Montana, Tennessee, Iowa, Delaware, New Jersey, New Hampshire, Kentucky, Indiana, Minnesota, Maryland, and others, depending on effective date) have adopted the service-provider contract model that is functionally similar to the GDPR’s Article 28. A DPA drafted to GDPR standards and extended with the US state-privacy-law service-provider terms is now the market-standard structure for global SaaS vendors. The marginal cost of adding the US terms is low; the marginal benefit in audit posture is substantial.

The theory above is useful if you draft DPAs once or twice a year. This section is the operational workflow — what to actually do when procurement sends you a new vendor DPA on Monday morning and wants sign-off by Friday.

Step 1 (5 minutes): Classify the relationship. Controller-to-processor (most common, Article 28 DPA), joint controllers (Article 26 arrangement, different contract), or independent controllers (controller-to-controller, minimal contract unless transfers in scope). Getting this wrong wastes all the following steps. If you are unsure, default to the classification imposing more obligations.

Step 2 (10 minutes): Fill in the parties and Annex I. Legal entity names, addresses, contacts, DPO email. Categories of data subjects, categories of personal data, subject matter, nature, purpose, duration. Specific, not generic — if you cannot describe what you actually process, you cannot defend it in an audit.

Step 3 (5 minutes): Annex II — TOMs. Factual description of what the processor actually implements. Encryption in transit and at rest, access controls, MFA, logging, backups, incident response, training, BCP/DRP. Anything you list, you commit to; anything you commit to, you should actually do.

Step 4 (10 minutes): Sub-processor model. General or specific authorisation. If general, the notification period (30 days common, 45 days enterprise), objection remedy, and Annex III list. If specific, the consent workflow and the list. Back-to-back contractual flow-down via SCC Module 3 where third-country.

Step 5 (10 minutes): Transfer mechanism. If no third-country transfer, skip this step. If yes, identify the regime (EU GDPR, UK GDPR, Swiss FADP), the transfer mechanism (DPF certification if applicable, plus SCC fallback; SCC Module 2 or 3; UK Addendum), and complete the TIA scaffold (destination country, surveillance-law exposure, historical government access, supplementary measures, conclusion).

Step 6 (5 minutes): Audit, DSR, breach, deletion. Audit model (combined is market-standard), DSR cost model (limited-free is balanced), breach notification timing (24-48 hours market-standard), deletion-or-return at end (either-at-controller’s-choice is default, with backup-retention realism).

Step 7 (5 minutes): Liability, governing law, boilerplate. Liability cap (enhanced 2x for DPA claims is balanced; uncapped-for-fines is controller-favourable; Main-Agreement cap is vendor-favourable). Governing law (follow the Main Agreement, except SCC Clause 17 prevails for the SCCs). Order-of-precedence clause (SCCs > DPA > Main Agreement).

Step 8 (5 minutes): Run the scorecard. The generator produces a live compliance scorecard that flags missing Article 28(3) sub-clauses, missing SCCs when third-country transfer is flagged, missing TIA, vague processing descriptions, inadequate TOM coverage, notification periods shorter than 14 days, and breach hours longer than 72. Target 100%; below 90% indicates structural issues.

Step 9 (5 minutes): Export and close. Download as PDF for signature, HTML or Markdown for version control, JSON for re-opening the same config later. Save the JSON alongside the executed agreement so the next renewal starts from a known baseline.

Total elapsed time: under an hour for a complete DPA, with annexes, tailored to the specific regime, transfer scenario, and commercial context. The generator shortcuts every step; without it, the same work is a half-day with a template library and careful reading. The discipline to save configurations and reuse them is what turns the hour into fifteen minutes once you have three or four well-tuned templates for your common scenarios.

One piece of advice the workflow does not capture: for any DPA covering sensitive categories, high volumes, or complex international flows, have a data-protection lawyer review the draft before signing. The generator produces a defensible baseline; a lawyer adds context-specific judgment about whether the baseline is enough for your particular situation. The compound cost of a bad DPA, measured in supervisory-authority fines under Article 83 and in lost customer trust after a breach, is orders of magnitude higher than the cost of a two-hour review.