Free DPA Generator

A Data Processing Agreement (DPA), also called a Data Processing Addendum, is a contract between a controller (the organization that decides why and how personal data is processed) and a processor (the organization that processes personal data on the controller's behalf). Under GDPR Article 28(3), the contract is legally required whenever a controller engages a processor — there is no de minimis exception. If you use any third-party vendor that handles personal data relating to EU, UK, or Swiss individuals (cloud hosting, email delivery, analytics, CRM, payroll, customer support, marketing automation), you must have a DPA in place. The DPA is also required under Brazil's LGPD Article 39, the Australian Privacy Act's APP 8 chain-of-responsibility rules for overseas disclosures, and — in practical commercial effect — by every major US state privacy law including California's CPRA (which requires a service-provider contract) and the fifteen-plus other state privacy statutes that have adopted the CPRA service-provider model. A DPA is distinct from, and sits alongside, the main commercial contract or terms of service.

GDPR Article 28(3) requires every processor contract to contain eight specific clauses, and each one is non-negotiable. (1) The processor may process personal data only on documented instructions from the controller, including for international transfers, unless EU or Member State law requires otherwise (in which case the processor must inform the controller before processing, unless prohibited). (2) Personnel authorised to process the personal data must be under a confidentiality obligation. (3) The processor must implement the Article 32 security measures. (4) The processor may only engage a sub-processor with the controller's prior specific or general written authorisation, and must impose the same data-protection obligations on that sub-processor by contract. (5) The processor must assist the controller in responding to data-subject-rights requests under Chapter III (access, rectification, erasure, portability, restriction, objection, automated decision-making). (6) The processor must assist the controller in complying with Articles 32 to 36 (security, breach notification, data-protection impact assessments, prior consultation). (7) At the end of the processing, the processor must, at the controller's choice, return or delete all personal data (subject to legal retention requirements). (8) The processor must make available to the controller all information necessary to demonstrate compliance with Article 28 and allow for audits, including inspections, by the controller or a mandated auditor. The generator's compliance scorecard flags any of these that are missing or inadequately drafted.

The Standard Contractual Clauses (SCCs) are pre-approved contractual templates issued by the European Commission that provide a lawful basis for transferring personal data outside the European Economic Area to a country without an adequacy decision. The current SCCs are set out in Commission Implementing Decision (EU) 2021/914 of 4 June 2021 and are divided into four modules covering different transfer scenarios. Module 1 covers Controller-to-Controller transfers. Module 2 covers Controller-to-Processor transfers — this is the one most SaaS customers need when their European data flows to a US-based vendor not certified under the EU-US Data Privacy Framework. Module 3 covers Processor-to-Processor transfers — this is what a processor uses when sub-processing data to a further sub-processor located outside the EEA. Module 4 covers Processor-to-Controller transfers, which is less common. The SCCs must be signed and can operate as a complete DPA in their own right, with the relevant Annex I (processing description), Annex II (technical and organisational measures), and Annex III (sub-processors) completed. The generator auto-injects Module 2 or Module 3 when the template involves a third-country transfer and produces the annexes from your inputs. The SCCs must be used in their entirety — you cannot omit individual clauses — though you may add supplementary provisions that do not contradict them.

The Transfer Impact Assessment (TIA) is a documented analysis required by the Court of Justice of the European Union's July 2020 Schrems II decision (Case C-311/18) whenever a controller or processor transfers personal data outside the EEA in reliance on the SCCs or another Article 46 transfer mechanism. The TIA must evaluate the law and practice of the destination country, identify any risks of government access that would undermine the SCC protections, and assess whether supplementary measures (typically end-to-end encryption controlled by the data exporter, pseudonymisation, or contractual and organisational safeguards) are necessary and sufficient. If the TIA concludes that the destination country's laws do not provide essentially equivalent protection and no adequate supplementary measures are available, the transfer cannot lawfully proceed. For transfers to the United States, organisations transferring to a DPF-certified recipient do not need to perform a TIA for the categories covered by the certification, but they still need one for transfers to non-certified recipients (for example, a sub-processor outside the DPF scope). 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 Latombe case, though an appeal to the CJEU was filed in October 2025 and remains pending. The EDPB's Recommendations 01/2020 remain the authoritative guidance. The generator produces a TIA scaffold — a set of structured questions covering surveillance law exposure, historical government requests, supplementary measures, and data-type sensitivity — which you complete and attach to the DPA.

GDPR Article 28(2) and 28(3)(d) give the controller two choices for authorising sub-processors. Specific authorisation means the processor must obtain the controller's written consent for each individual sub-processor before engaging that sub-processor. This gives the controller maximum control but is operationally impractical for most modern SaaS vendors who rely on dozens of sub-processors. General authorisation means the controller authorises the processor to engage sub-processors generally, but the processor must inform the controller of any intended addition or replacement of sub-processors, giving the controller the opportunity to object. Essentially every commercial SaaS DPA uses general authorisation with a notification-and-objection workflow: the processor publishes a list of sub-processors and commits to posting updates (commonly 30 days) before onboarding a new one; if the controller objects on reasonable data-protection grounds, either the processor withdraws the proposed sub-processor or the controller may terminate the affected service. Two details often missed in drafting: the processor must impose the same Article 28 obligations on the sub-processor by written contract (flowing through Module 3 or equivalent language), and the processor remains fully liable to the controller for the sub-processor's performance. The generator surfaces both choices and builds the notification workflow, objection period, and sub-processor list in Annex III.

GDPR Article 28(3)(e) and (f) require the processor to assist the controller with data-subject rights requests and with compliance obligations under Articles 32 to 36 (security, breach notification, DPIAs). The statute does not say this assistance must be free, and market practice is split. EDPB Guidelines 07/2020 clarify that the obligation is one of reasonable cooperation taking into account the nature of the processing and the information available to the processor — the processor is not a substitute for the controller's own compliance function. In commercial DPAs, three models appear: free assistance for limited-volume requests (common for enterprise SaaS), reimbursement of documented costs (common for smaller vendors), and paid assistance at stated hourly or per-request rates (common for managed-services providers whose configurations make DSR fulfilment operationally heavy). What is not acceptable is a clause that denies the processor's assistance obligation entirely or that pegs fees so high as to effectively prevent the controller from meeting its regulatory deadlines. The generator lets you pick among these models and flags fee structures that look like a constructive denial of the obligation. On breach assistance specifically, the processor must notify the controller ‘without undue delay’ under Article 33(2) — market-standard drafting pins this at 24 to 48 hours, measured from the processor's awareness.

After Brexit, the UK GDPR operates as a parallel regime to the EU GDPR, with the Information Commissioner's Office (ICO) as the supervisory authority. For restricted transfers from the UK to a country without UK adequacy, you need either the International Data Transfer Agreement (IDTA) or the UK Addendum to the EU SCCs, both issued by the ICO in March 2022. The IDTA is a standalone contract that replaces the old pre-Brexit SCCs for UK-only transfers. The UK Addendum is a short document that sits on top of the EU SCCs 2021/914 and adapts them for UK law — this is the common choice for multinational organisations already using the EU SCCs because it avoids maintaining two separate clauseworks. As of April 2026, the UK maintains an adequacy decision for transfers to the EEA and for transfers under the UK Extension to the EU-US Data Privacy Framework (which lets UK data flow to DPF-certified US organisations that have also extended their certification to UK data). For transfers outside those adequacy flows, the IDTA or Addendum must be signed, and a UK TRA (Transfer Risk Assessment) — the UK equivalent of a TIA — must be documented. The generator auto-injects the UK Addendum when UK GDPR is selected and a third-country transfer is flagged, and includes a UK TRA scaffold.

Joint controllers are two or more organisations that jointly determine the purposes and means of processing — for example, a co-branded marketing partnership where both parties decide what data to collect and how to use it, or a shared research programme. Joint controllers are governed by GDPR Article 26, not Article 28, and the agreement is a Joint Controller Arrangement rather than a DPA. The distinction matters because the obligations flow differently. Under Article 28, the processor follows the controller's instructions; under Article 26, both parties are independently subject to GDPR obligations and the arrangement must transparently allocate responsibility for each right and obligation — particularly responding to data-subject requests and providing the Article 13/14 information. Data subjects may assert their rights against either joint controller regardless of the internal allocation. Getting the classification right is the single most common DPA drafting mistake: a true joint-controller relationship papered as a controller-processor DPA is legally defective and creates residual liability for both sides. The generator includes a Joint Controller Arrangement template that follows the Article 26 structure, allocates responsibilities for each GDPR duty, and produces the essential-content summary that Article 26(2) requires to be made available to data subjects.