Data Processing Agreement Template
Hand-drafted data processing agreement template for 2026 — GDPR Article 28 compliant, covers controller-processor relationship, sub-processors, security measures, breach notification and international transfers (SCCs & UK IDTA). Suitable for UK, EU and global engagements. Download today as PDF, Word or Google Docs.
Download Template See what’s inside →Quick answer. A data processing agreement template (DPA) is the contract required under GDPR Article 28 whenever a controller engages a processor to handle personal data. It defines the controller-processor relationship, sets the processor's obligations on security and breach notification, and authorises sub-processors. The template below covers all eight Article 28(3) mandatory clauses plus international transfer mechanisms (UK IDTA and EU SCCs). Download as PDF, Word or Google Docs.
What is a Data Processing Agreement?
A Data Processing Agreement (DPA) is a written contract required under Article 28 of the UK GDPR and the EU GDPR whenever a controller (the organisation that decides why and how personal data is processed) engages a processor (a third party that processes personal data on the controller's behalf) to handle that data. The DPA sets out the subject matter and duration of the processing, its nature and purpose, the type of personal data, the categories of data subjects, and the rights and obligations of each party. It is the legal instrument that turns a commercial vendor relationship into a compliant data protection relationship.
Almost every modern business is both a controller and a processor for different sets of data. A SaaS founder is the controller for their employees' HR records, but a processor for the personal data their customers upload into the product. A marketing agency is a processor for client lists and a controller for its own staff data. A DPA captures these roles correctly, prevents one party from being held responsible for the other party's mistakes, and gives data subjects a clear chain of accountability if something goes wrong. Without a DPA in place, a controller is in breach of Article 28 from the moment the processor starts handling personal data, regardless of how good the underlying service is.
Key Components of a Data Processing Agreement
- Subject matter and duration - what processing happens, and for how long
- Nature and purpose - the activities involved and the business reason for them
- Type of personal data - the categories of personal data processed
- Categories of data subjects - who the data relates to (customers, staff, end users)
- Controller instructions - documented written instructions the processor must follow
- Processor obligations - confidentiality, security, assistance, sub-processor controls
- International transfer mechanisms - SCCs, IDTA, or adequacy where relevant
- Audit rights - the controller's right to audit or receive third-party assurance
- Breach notification - timelines and processes for reporting personal data breaches
- Return or deletion - what happens to the data at the end of the services
Types of DPAs and Processing Relationships
Not every data-sharing arrangement is a controller-processor relationship, and the wrong characterisation can produce a contract that fails compliance review. The first job of any DPA is to correctly identify the role each party plays. The table below summarises the three relationships most commonly mistaken for one another.
| Relationship | Who decides purposes and means? | Contract type required | Typical examples |
|---|---|---|---|
| Controller to Processor | Controller decides; processor follows documented instructions | Article 28 DPA | SaaS hosting, payroll bureau, analytics platform, email sender |
| Joint Controllers | Both parties jointly determine purposes and means | Article 26 joint controller arrangement | Co-marketing partners, joint research projects, co-branded products |
| Controller to Controller | Each party determines purposes and means independently | Data sharing agreement (not a DPA) | Selling a customer list, due diligence disclosures, regulatory reporting |
| Processor to Sub-Processor | Processor passes controller instructions down | Article 28(4) flow-down DPA | SaaS vendor using AWS, payroll bureau using a print-and-post supplier |
Common Controller-Processor Scenarios
- Cloud hosting and infrastructure: AWS, Google Cloud, Microsoft Azure, hosting providers
- SaaS and productivity tools: CRM, email marketing, helpdesk, project management platforms
- Analytics and tracking: Google Analytics, Mixpanel, Hotjar, session replay tools
- Payment and billing: Stripe, PayPal, billing and invoicing platforms
- HR and payroll: Payroll bureaux, applicant tracking systems, benefits administrators
- Communications: Twilio, Telnyx, transactional email providers, SMS platforms
- Customer support: Zendesk, Intercom, AI chatbot vendors, outsourced helpdesks
Joint Controller Scenarios
- Co-marketing campaigns: Two brands jointly running a lead-generation programme
- Joint research: Universities and corporates collaborating on data-driven research
- White-label arrangements: Where both parties materially shape what data is collected
- Embedded third-party services: Embedded social plugins, advertising integrations
- Industry consortia: Shared platforms run by multiple member organisations
Sub-Processor Examples
- Hosting under a SaaS: A SaaS vendor using a hyperscaler such as AWS, GCP, or Azure
- Email delivery: SaaS platforms using SendGrid, Mailgun, or Postmark for transactional email
- Customer support outsourcing: A processor contracting an outsourced support team
- AI and language models: A processor calling an LLM API such as Claude or OpenAI
- Payment processing: A SaaS using a card processor for subscription billing
When You Definitely Need a DPA
- Any cloud or SaaS vendor that touches personal data on your behalf
- Any outsourced function where personal data leaves your direct control
- Any analytics or tracking provider processing user behaviour or identifiers
- Any AI vendor being sent personal data as part of prompts, training, or inference
- Any consultant or contractor with persistent access to personal data systems
- Any new vendor onboarding, before personal data is shared, not after
What's Inside the Data Processing Agreement Template
The template is structured the way a privacy lawyer would structure it for you, with twelve standard clauses organised into four logical groups, plus two annexes. Each clause has placeholder text you can edit and standard fallback wording where you need a sensible default. Every Article 28(3) mandatory item is covered.
1. Parties & Roles
- Controller identification
- Processor identification
- Effective date & term
- Definitions (GDPR Article 4)
2. Processing Details (Annex 1)
- Subject matter & duration
- Nature & purpose
- Type of personal data
- Categories of data subjects
3. Processor Obligations
- Documented instructions only
- Confidentiality of staff
- Security measures (Annex 2)
- Sub-processor authorisation
- Data subject rights assistance
- Breach notification
4. Audit, Transfers & End-of-Term
- Audit rights
- International transfers (SCCs / IDTA)
- Data return or deletion
- Liability allocation
- Governing law
All twelve clauses plus the two annexes are editable. The processing details (Annex 1) and security measures (Annex 2) are the two main customisations you'll make for each engagement — the core obligations stay the same.
Essential Data Processing Agreement Components
Subject Matter, Duration, Nature, and Purpose
- Subject matter: A short description of the services that involve processing
- Duration: The contractual term during which processing is permitted
- Nature of processing: The activities involved (storage, transmission, retrieval, deletion)
- Purpose of processing: The business reason the controller is engaging the processor
- Type of personal data: Identifiers, contact data, financial data, behavioural data, special category data
- Categories of data subjects: Customers, prospects, employees, applicants, end users, suppliers
Controller Instructions and Processor Obligations
- Documented instructions: The processor only processes on the controller's documented instructions
- Lawful processing: The processor flags any instruction that appears to breach data protection law
- Confidentiality: All personnel with access are bound by confidentiality duties
- Personnel training: Staff are trained on data protection and security obligations
- Assistance with rights: The processor helps the controller respond to data subject requests
- Assistance with obligations: Help with DPIAs, prior consultation, and security obligations
Sub-Processor Authorisation and Flow-Down
- Authorisation type: Specific prior authorisation, or general authorisation with notice
- Notification of changes: The processor notifies the controller of new sub-processors before engagement
- Right to object: The controller can object to a new sub-processor on reasonable grounds
- Sub-processor list: A maintained, current list available to the controller on request
- Flow-down obligations: Sub-processors are bound by the same obligations the processor accepts
- Continuing liability: The processor remains fully liable to the controller for sub-processor failures
Security Measures (Article 32)
- Encryption: Encryption of personal data in transit and at rest where appropriate
- Pseudonymisation: Where it reduces risk to data subjects without breaking the use case
- Confidentiality, integrity, availability, resilience: Of processing systems and services
- Restoration: Ability to restore availability and access after a physical or technical incident
- Testing and evaluation: Regular testing and review of the effectiveness of measures
- Access controls: Role-based access, least privilege, multi-factor authentication
- Logging and monitoring: Audit logs of access and processing activities
Breach Notification and Incident Response
- Without undue delay: The processor notifies the controller without undue delay on becoming aware
- Defined timeline: Practical SLAs such as 24 or 48 hours from awareness
- Required information: Nature of the breach, categories and approximate numbers, likely consequences, measures taken
- Cooperation: The processor cooperates with regulator notifications and data subject communications
- Remediation: Steps to contain, mitigate, and prevent recurrence of the breach
- Documentation: A complete written record of the breach, response, and lessons learned
Audit Rights and Third-Party Assurance
- Audit on reasonable notice: Right to audit the processor's compliance with the DPA
- Third-party assurance: Acceptance of SOC 2, ISO 27001, or equivalent independent reports
- Information requests: The processor provides all information needed to demonstrate compliance
- Inspection rights: Reasonable on-site inspection where remote review is insufficient
- Frequency limits: Reasonable cadence so audits do not become operationally disruptive
- Cost allocation: Who bears reasonable audit costs in normal and exceptional circumstances
International Data Transfers
- Adequacy decisions: Reliance on UK or EU adequacy decisions where available
- Standard Contractual Clauses: EU SCCs (2021 modules) where transfers leave the EEA
- UK International Data Transfer Agreement: The IDTA where transfers leave the UK
- UK Addendum: The UK Addendum to the EU SCCs for parallel UK and EU coverage
- Transfer risk assessment: A documented assessment of the destination country's risks
- Supplementary measures: Encryption, pseudonymisation, or contractual measures where needed
End of Term: Return or Deletion
- Controller's choice: The controller chooses return or deletion at the end of services
- Defined timeline: A specific period after termination within which return or deletion happens
- Backup data: Reasonable timeline for purging data from backups
- Certification: The processor certifies in writing that deletion has been completed
- Statutory retention exceptions: Limited carve-outs where law requires longer retention
- Format of returned data: A useful, machine-readable, commonly used format
Common Data Processing Agreement Pitfalls
- Mislabelling a controller-controller relationship as controller-processor
- Vague processing descriptions that do not satisfy Article 28(3)
- Open-ended general sub-processor authorisation with no objection mechanism
- Breach notification clauses with no defined timeline or required information
- International transfers with no SCCs, IDTA, or transfer risk assessment attached
- "We will delete data on request" rather than a defined return-or-delete timeline
- Liability caps that swallow data protection liability and indemnities
- Missing flow-down obligations to sub-processors
Controller, Processor, and Sub-Processor: How the Roles Connect
The DPA exists because GDPR puts different obligations on each role in the data-processing chain. The chart below shows how the roles connect: who instructs whom, who holds the data, and who is accountable for what.
The chart shows three things every founder using this template needs to internalise: (1) the controller and processor have different obligations — you can't pretend you're "just a processor" if you're really making the decisions; (2) the processor must impose the same data protection obligations on every sub-processor by contract under GDPR Article 28(4); and (3) the processor remains liable to the controller for the sub-processor's mistakes — you can't push that risk down the chain.
How to Fill Out a Data Processing Agreement: Step-by-Step Guide
Establish: Who is the controller, who is the processor, and what processing happens.
- Confirm whether each party is a controller, processor, or joint controller
- Describe the subject matter and duration of the processing in plain English
- Set out the nature and purpose of the processing
- List the categories of personal data processed
- List the categories of data subjects affected
Define: The instructions the processor must follow and the duties they accept.
- Record the controller's documented processing instructions
- Bind the processor's personnel to confidentiality
- Require assistance with data subject requests, DPIAs, and prior consultation
- State the processor's obligation to flag instructions that may breach the law
- Confirm assistance with the controller's Article 32 security obligations
Control: The chain of accountability where data flows further downstream.
- Choose specific prior authorisation or general authorisation with notice
- Require advance notification of new or replacement sub-processors
- Reserve a reasonable right to object to new sub-processors
- Require flow-down obligations equivalent to those in this DPA
- Confirm the processor's continuing liability for sub-processor acts and omissions
Document: The technical and organisational measures and how incidents are handled.
- Attach a schedule of technical and organisational measures aligned to Article 32
- Set a clear breach notification SLA (24 or 48 hours from awareness is typical)
- Specify the information the processor must include in a breach notification
- Provide audit rights, including acceptance of independent third-party reports
- Agree reasonable cadence and cost allocation for audits
Choose: The right transfer mechanism for the destinations involved.
- Identify all countries where personal data will be processed
- Rely on UK or EU adequacy decisions where they apply
- Attach the EU SCCs and the UK Addendum for parallel UK and EU transfers
- Use the UK IDTA for transfers leaving the UK to non-adequate countries
- Document a transfer risk assessment and any supplementary measures
Close out: What happens to the data when the services finish.
- Give the controller a clear choice between return and deletion
- Set defined timelines for both live data and backup purges
- Require written certification of deletion
- Carve out only the statutory retention exceptions that genuinely apply
- Specify the format and method for returned data
Data Protection Law and Compliance Considerations
Data processing agreements sit at the intersection of contract law and data protection law. Article 28 of the UK GDPR and the EU GDPR both require specific clauses, and supervisory authorities (including the ICO in the UK and the EU national regulators) have published guidance on how DPAs should be drafted. Sector-specific obligations apply on top — for example NHS Data Security and Protection Toolkit requirements in healthcare, FCA requirements in financial services, and PCI-DSS for cardholder data. Where personal data leaves the UK or EEA, transfer mechanisms must be in place before the transfer begins. Professional legal advice from data protection counsel is essential for any high-risk processing or any contract that will be heavily relied upon.
Sub-Processors, Security, and Breach Notification
Sub-Processor Management
- Sub-processor inventory: A current, accurate list maintained by the processor
- Risk-based review: Higher-risk sub-processors reviewed more frequently
- Onboarding due diligence: Security questionnaires, certifications, references
- Contract flow-down: Article 28-equivalent obligations applied to every sub-processor
- Change management: Notification, objection windows, and replacement procedures
- Termination cascade: Plans for replacing or removing problem sub-processors
Technical and Organisational Measures (Article 32)
- Identity and access: SSO, MFA, role-based access controls, least privilege
- Encryption: TLS 1.2+ in transit, AES-256 at rest, managed key rotation
- Network controls: Segmentation, firewalls, intrusion detection and prevention
- Endpoint security: Hardening standards, anti-malware, mobile device management
- Vulnerability management: Patching SLAs, vulnerability scanning, penetration testing
- Logging and monitoring: Centralised logs, anomaly detection, security operations
- Backup and recovery: Regular backups, tested restoration, defined RTO and RPO
- Personnel security: Background checks, training, leaver processes
- Physical security: Data centre certifications, controlled office access
- Secure development: SSDLC, code review, static and dynamic analysis
Breach Notification Workflow
- Detection: Monitoring, alerting, and triage that surface incidents quickly
- Initial assessment: Severity, scope, categories of data, categories of subjects
- Processor-to-controller notification: Within the agreed SLA from awareness
- Controller-to-regulator notification: Within 72 hours where required by Article 33
- Data subject notification: Where high risk to rights and freedoms under Article 34
- Containment and remediation: Stopping the breach and reducing harm
- Forensics: Root cause analysis and supporting evidence
- Lessons learned: Process and control changes to prevent recurrence
- Documentation: A complete record retained for the regulatory limitation period
Assistance With Data Subject Rights
- Access requests: Producing copies of personal data on request
- Rectification: Correcting inaccurate or incomplete personal data
- Erasure: Deleting personal data where the right to be forgotten applies
- Restriction: Suspending processing in defined circumstances
- Portability: Exporting personal data in a structured, commonly used format
- Objection: Stopping processing where the data subject objects on legitimate grounds
- Automated decisions: Human review of solely automated decisions
Records of Processing Activities
- Article 30(1) records: Maintained by the controller for their processing activities
- Article 30(2) records: Maintained by the processor for processing on behalf of others
- Cooperation: The processor provides the controller with information needed for their records
- Regulator requests: Both parties cooperate with supervisory authority requests
- Format and accessibility: Records in writing, including electronic form, kept current
- Scope: Categories of subjects, data, recipients, transfers, retention, security measures
Practical Tips for Strong Security Schedules
- Reference recognised standards (ISO 27001, SOC 2, NIST CSF) instead of reinventing controls
- Be specific about encryption (algorithms, key management, rotation cadence)
- Use named SLAs for breach notification, patching, and access reviews
- Avoid vague language such as "industry-standard" without a definition
- Update measures annually as the threat landscape changes
- Map measures to the actual personal data risk, not a generic checklist
Data Processing Agreement — Frequently Asked Questions
The controller is the organisation that decides why personal data is processed and how. The processor processes the personal data on the controller's behalf and only on the controller's documented instructions. A SaaS customer is normally the controller; the SaaS vendor is normally the processor. Where two parties jointly determine the purposes and means of processing, they are joint controllers and an Article 26 arrangement applies instead of a DPA.
You need a DPA with every vendor that processes personal data on your behalf. That includes cloud providers, SaaS tools, analytics platforms, payroll bureaux, customer support outsourcers, AI providers receiving personal data in prompts, and any consultant with persistent access to systems containing personal data. You do not need a DPA where the vendor only processes pseudonymised, anonymised, or non-personal data, or where the vendor is acting as an independent controller (in which case a data sharing agreement is the right contract).
Article 33 of the UK GDPR and EU GDPR requires controllers to notify the supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it. Processors must notify the controller without undue delay so that the controller can meet that 72-hour deadline. In practice this means processors agree to a faster internal SLA in their DPAs, often 24 or 48 hours from awareness, with a defined list of information the notification must contain.
You need a transfer mechanism whenever personal data leaves the UK or EEA to a country without an adequacy decision. From the EEA you use the EU Standard Contractual Clauses (the 2021 modular versions). From the UK you use either the UK International Data Transfer Agreement (IDTA) or the UK Addendum to the EU SCCs. Adequacy decisions cover transfers to the UK from the EU, the EU from the UK, and a small list of other countries. A transfer risk assessment must accompany the SCCs or IDTA, evaluating whether the destination country's laws undermine the contractual safeguards.
You can, but read it carefully. Most large SaaS vendors offer a take-it-or-leave-it standard DPA that satisfies Article 28(3) on its face. Common gotchas include: vague processing descriptions; broad general sub-processor authorisation with weak objection rights; breach notification timelines tied to "confirmed" rather than "suspected" breaches; international transfer terms that omit the UK Addendum; deletion timelines measured in years; and liability caps that effectively swallow data protection indemnities. If a standard DPA fails on any of these, push back or accept that you are taking the risk.
Under Article 28(4), the processor remains fully liable to the controller for sub-processor acts and omissions. Data subjects can also bring claims directly against either party under Article 82. The processor's DPA with its sub-processors must flow down equivalent obligations. In commercial terms, the controller usually negotiates either an uncapped data protection liability or a higher cap for breach of data protection obligations, sitting outside the general liability cap.
A transfer risk assessment (TRA) is a written assessment of whether the laws and practices of the destination country allow the contractual safeguards in the SCCs or IDTA to be effective. Following Schrems II, the TRA is required whenever you rely on the SCCs or IDTA. It looks at government access laws, redress mechanisms, the nature of the data, the purposes of processing, and any technical or contractual supplementary measures (such as encryption with keys held in the source country). The ICO and EU regulators have published TRA templates that are a good starting point.
Keep the DPA, all schedules, and the records of processing for at least the regulatory limitation period (commonly six years from the end of the contract under English law) and longer where sector rules require it. Retention is necessary to demonstrate Article 5(2) accountability if a regulator investigates a historic incident. Deletion of the personal data itself follows the DPA's own end-of-term clauses; deletion of the contract record is governed by your normal contract retention policy.
Risk Management and Legal Considerations
Regulatory and Enforcement Risks
- Administrative fines: Up to £17.5 million or 4% of global annual turnover under UK GDPR
- EU GDPR fines: Up to €20 million or 4% of global annual turnover
- Enforcement notices: Orders to bring processing into compliance or stop entirely
- Public censure: ICO and EU regulator decisions are published and create reputational damage
- Sector-specific penalties: Additional regulator action under FCA, MHRA, NHS DSPT, and others
- Class actions and group claims: Representative actions for data protection breaches
Operational and Contractual Risks
- Breach response cost: Forensics, legal, regulator response, customer notification
- Indemnity exposure: Indemnification of customers for processor failures
- Liability cap erosion: Data protection claims that escape standard liability caps
- Insurance gaps: Cyber and tech E&O policies with carve-outs for data protection fines
- Customer churn: Loss of B2B customers after a serious breach or DPA failure
- Procurement blocks: Failed vendor risk assessments preventing future deals
Information Security Risks
- Unauthorised access: Insider threats, credential theft, account takeover
- Ransomware and extortion: Encrypted systems, exfiltration-based extortion
- Supply chain attacks: Compromise via third-party software or sub-processors
- Misconfiguration: Open S3 buckets, exposed databases, leaked secrets
- Phishing and social engineering: Targeting employees with system access
- Endpoint compromise: Malware on devices with access to personal data
International Transfer Risks
- Inadequate transfer mechanism: No SCCs, IDTA, or adequacy where required
- Government access: Foreign laws compelling disclosure of personal data
- Sub-processor sprawl: Onward transfers to additional countries without controls
- Adequacy decision changes: Withdrawal or partial limitation of adequacy
- Court rulings: Schrems-style rulings invalidating existing transfer mechanisms
- Sanctions and export controls: Restrictions on transferring data to certain jurisdictions
AI and Emerging Technology Risks
- Personal data in prompts: Sending personal data to LLM and AI APIs without a DPA
- Training data use: Personal data being used to train third-party models
- Automated decision-making: Article 22 obligations for solely automated decisions
- Profiling: Higher-risk profiling requiring DPIAs and transparency
- Bias and accuracy: Article 5(1)(d) accuracy obligations for AI-generated outputs
- Explainability: Right to meaningful information about automated logic
Risk Mitigation Strategies
- Vendor risk management: Pre-onboarding due diligence and tiered vendor reviews
- Standardised DPA templates: A house DPA used across all new vendors
- Negotiation playbooks: Documented fallback positions for common pushbacks
- Continuous monitoring: Periodic re-assessment of material vendors
- Incident response readiness: Rehearsed breach playbooks involving processors
- Cyber insurance: Coverage for breach response, defence costs, and regulator action
Critical Data Protection Risk Principles
- Sign the DPA before any personal data starts flowing, not after
- Treat the schedules (data, transfers, security) as the operative parts
- Re-paper material vendors when transfer law changes (e.g. new SCCs, IDTA updates)
- Keep an audit trail of TRAs, sub-processor approvals, and breach notifications
- Train procurement and engineering on what triggers the need for a DPA
- Map vendors to data categories so high-risk processing gets escalated treatment
International Data Transfers and Cross-Border Considerations
Adequacy Decisions
- UK adequacy regulations: Countries the UK government has formally recognised as adequate
- EU adequacy decisions: Countries the European Commission has formally recognised as adequate
- UK to EEA: Currently covered by EU adequacy decision in favour of the UK and vice versa
- EU-US Data Privacy Framework: Adequacy for certified US recipients
- UK Extension to the DPF: Equivalent route for UK transfers to certified US recipients
- Other adequate countries: Includes Andorra, Argentina, Canada (commercial), Israel, Japan, New Zealand, South Korea, Switzerland, Uruguay
Standard Contractual Clauses (EU SCCs 2021)
- Module 1: Controller to controller
- Module 2: Controller to processor
- Module 3: Processor to processor (sub-processor)
- Module 4: Processor to controller
- Docking clause: Adding new parties without re-papering the entire SCCs
- Annexes: Required schedules for parties, processing description, technical and organisational measures
UK International Data Transfer Agreement and Addendum
- UK IDTA: Standalone UK transfer mechanism for transfers leaving the UK
- UK Addendum to the EU SCCs: Allows the EU SCCs to be used for UK transfers in parallel
- Choice of mechanism: Most multinational organisations use the SCCs plus UK Addendum for parallel coverage
- Approved versions: Use the current ICO-approved versions; older versions become invalid over time
- Tabular structure: The IDTA uses tables that must be completed accurately, not skipped
- Signature and dating: Both parties must execute the agreement before transfers begin
Transfer Risk Assessment
- Destination law assessment: Government access laws, surveillance, redress mechanisms
- Practical access experience: How often the importer is asked for data in practice
- Nature and sensitivity of data: Special category data requires stricter assessment
- Purposes of processing: What the data is being used for at the destination
- Importer profile: Whether the importer is a likely target of government requests
- Supplementary measures: Encryption, pseudonymisation, contractual measures, organisational measures
Supplementary Measures
- Strong encryption in transit and at rest: Reducing the value of intercepted data
- Customer-managed keys: Where keys remain in the source country
- End-to-end encryption: Where the importer cannot access plaintext
- Pseudonymisation and tokenisation: Reducing identifiability at the destination
- Restrictive access policies: Tight controls on who at the importer can see the data
- Transparency reports: The importer publishes statistics on government data requests
- Government request notification: The importer challenges or notifies on requests where lawful
Multi-Jurisdiction Considerations
- EU GDPR vs UK GDPR: Substantially aligned but diverging on adequacy and onward transfers
- US state privacy laws: CCPA, CPRA, VCDPA, CTDPA, UCPA, and others
- Other regimes: Brazil LGPD, Canada PIPEDA, Australia Privacy Act, Singapore PDPA
- Sector-specific regimes: US HIPAA for health, GLBA for financial services, COPPA for children
- Localisation requirements: China, Russia, India, and others with data residency rules
- One-stop-shop: The EU one-stop-shop applies to lead authority disputes for controllers
International Transfer Best Practice
- Map every personal data flow to the actual countries where data is processed and stored
- Pick the right transfer mechanism for the source jurisdiction (UK, EEA, or both)
- Run a documented TRA before transfers begin and refresh it on material change
- Build supplementary measures into the architecture, not just the contract
- Re-paper transfer mechanisms when ICO or EDPB guidance changes
- Maintain a transfer register so audits and customer questionnaires can be answered quickly
UK vs EU vs US Privacy Law Context
"GDPR" is shorthand for several closely-related but distinct legal regimes. Knowing which one applies to your engagement matters because it changes the citations in the DPA and the international transfer mechanism you need.
European Union (EU GDPR)
The original EU General Data Protection Regulation (Regulation 2016/679) applies across all EU member states from 25 May 2018. Article 28 sets out the controller-processor obligations and Article 28(3) lists the eight mandatory clauses every DPA must contain. The lead supervisory authority depends on the controller's main establishment.
United Kingdom (UK GDPR + DPA 2018)
Post-Brexit, the UK retained the GDPR framework as the UK GDPR, supplemented by the Data Protection Act 2018. Substantively the obligations are nearly identical to the EU GDPR — including Article 28's mandatory DPA clauses — but the supervisory authority is the Information Commissioner's Office (ICO) rather than an EU authority. The ICO's guidance on contracts and data sharing is the authoritative source for UK DPA drafting.
For UK-to-non-UK transfers, the UK uses its own International Data Transfer Agreement (IDTA) or the UK Addendum to the EU SCCs.
United States (CCPA / CPRA + sectoral laws)
The US has no federal equivalent to GDPR. Privacy law operates at state level and through sector-specific federal laws (HIPAA for health, GLBA for financial, COPPA for children, etc.). The most influential state regime is California's California Consumer Privacy Act (CCPA), expanded by the California Privacy Rights Act (CPRA). The CCPA uses the term "service provider" rather than "processor", and a comparable contract is required under CCPA Section 1798.140(ag).
Other states with comprehensive privacy laws include Virginia (VCDPA), Colorado (CPA), Connecticut (CTDPA), and Texas (TDPSA). Each has its own variant of the controller-processor (or controller-service provider) contract requirement.
Practical drafting
For most UK-headquartered SaaS founders, a UK GDPR-compliant DPA also satisfies EU GDPR for EU customers (the obligations are nearly identical), and can be adapted with a CCPA addendum for US customers. The template below is drafted in UK/EU GDPR style with provisions that can be adapted for US state-level requirements.
DPA Implementation and Best Practices
Pre-Contract Preparation
- Use a house DPA template: A single, version-controlled template adapted by tier
- Tier vendors by risk: Low, medium, high based on data volume and sensitivity
- Pre-approved positions: Negotiation playbook with fallback positions for common pushbacks
- Vendor due diligence: Security questionnaire, certifications, references, financial checks
- Data inventory: Knowing what personal data the vendor will actually touch
- Stakeholder alignment: Procurement, legal, security, and DPO aligned before negotiation
Negotiation and Execution
- Lead with your DPA: Send your template first rather than accepting the vendor's
- Pick your battles: Liability, breach notification, sub-processors, transfers are non-negotiable
- Schedules matter most: The schedules describe the actual processing and security
- Match the order form: DPA, MSA, and order form must point at the same scope
- Execute before data flows: Live data must not move before the DPA is signed
- Storage and retrieval: Signed DPA stored where procurement and DPO can find it
Onboarding and Operations
- Onboarding playbook: Provisioning, access reviews, monitoring set up before go-live
- Sub-processor list ingestion: Tracking who the processor uses and where
- Periodic reviews: Annual or risk-based review of material vendors
- Audit and assurance: Accepting and tracking SOC 2, ISO 27001, and equivalent reports
- Breach simulation: Tabletop exercises that include the processor's response
- Vendor risk dashboards: A single view of vendors, data, transfers, and assurance status
Change Management
- Sub-processor changes: Tracked, assessed, and either accepted or objected to in time
- Transfer law changes: SCCs, IDTA, and adequacy updates trigger re-papering
- Service changes: New features that change the processing trigger DPA updates
- Acquisitions and reorganisations: Vendor M&A changes who the controller is contracting with
- Regulator guidance: ICO, EDPB, and national regulator updates inform DPA refreshes
- Internal scope changes: Expansion of internal use cases triggers a fresh DPIA and DPA review
End-of-Term and Exit
- Exit planning: Documented plans for return or deletion at the end of the contract
- Migration support: Reasonable cooperation in moving to a new vendor
- Deletion certificates: Written confirmation of deletion received and retained
- Backup purges: Reasonable timeline for purging from backups, then certificate
- Lessons learned: Capture what worked and what did not for future vendors
- Record retention: The DPA, schedules, and audit evidence kept for the limitation period
Continuous Improvement
- Template refresh cadence: Annual review of the house DPA template
- Negotiation feedback loop: Common pushbacks captured into the playbook
- Regulator engagement: Tracking ICO and EDPB enforcement decisions
- Industry benchmarking: Comparing terms against peer companies
- Staff training: Refresher training for procurement, sales, and engineering teams
- Tooling investment: Vendor risk management, contract lifecycle management, transfer registers
Indicators of a Mature DPA Programme
- A single house DPA template with documented variations by risk tier
- Personal data does not start flowing until the DPA is signed
- An accurate, current sub-processor and transfer register
- Documented transfer risk assessments for every material non-adequate transfer
- Tabletop-tested breach response that includes processors and sub-processors
- Periodic re-assessment driving renegotiation, replacement, or termination
What founders say about this template
Feedback from founders, DPOs and procurement teams who have used the data processing agreement template on real vendor relationships.
Scroll →
Used this for our procurement DPA across twelve UK SaaS vendors. The Article 28(3) coverage is exact, and the sub-processor authorisation mechanics are the cleanest I've seen for B2B SaaS.
Adopted this as our customer-facing DPA for our SaaS product. Two enterprise customers' privacy counsel reviewed it and signed without amendments. The IDTA addendum being pre-built saved a meaningful chunk of negotiation time.
Solid Article 28 coverage and the Annex 1/Annex 2 split is exactly how the regulators want to see it. Wish there was a CCPA service-provider addendum out of the box, but adapting one wasn't hard.
As a small fintech, this is the level of DPA we needed without paying for an enterprise privacy lawyer. The breach notification timing is sensible (24 hours), and the audit rights are properly scoped.
Plain-English drafting alongside the formal language is the standout feature. My non-legal colleagues in procurement could actually understand it, which made the vendor onboarding process meaningfully faster.
UK-orientated DPA that handles both UK GDPR and EU GDPR cleanly. The transfer mechanism hooks (IDTA + UK Addendum to EU SCCs) are exactly what our outside counsel said we needed post-Schrems II.
Related Legal Templates
DPAs rarely sit on their own — they slot into a wider stack of vendor and customer contracts. Here are the templates founders typically pair with this one.
Scroll →
Privacy Policy
The public-facing privacy notice required by GDPR Articles 13 and 14. Sets out how you collect and use personal data, lawful bases, retention, and data subject rights.
View privacy policy template →Terms of Service
The customer-facing terms governing use of your product or service. Often referenced alongside the DPA when the customer is also the data controller.
View terms of service template →Confidentiality Agreement (NDA)
Covers confidential information shared during a vendor relationship. Sits alongside the DPA — the DPA covers personal data; the NDA covers everything else confidential.
View NDA template →Master Service Agreement
The umbrella contract for B2B services. The DPA is typically attached as a schedule or addendum to the MSA, kicking in whenever personal data is processed.
View MSA template →Service Agreement
Single-engagement services contract. The DPA attaches to it whenever the services involve processing personal data on the customer's behalf.
View service agreement template →Software License Agreement
Licensing contract for software products. SaaS engagements typically need a DPA alongside the licence whenever the software processes customer personal data.
View software licence template →Employment Agreement
Sets confidentiality obligations on staff who will handle personal data — one of the GDPR Article 28(3)(b) requirements that the processor must satisfy internally.
View employment agreement template →Statement of Work
Project-specific scope document. Annex 1 of the DPA (processing details) often mirrors what's in the SOW, so the two documents should align.
View SOW template →Download the Data Processing Agreement Template
Our comprehensive Data Processing Agreement template includes all the essential provisions you need to satisfy Article 28 of the UK GDPR and EU GDPR. The template is professionally drafted with current ICO and EDPB guidance in mind, and is ready to adapt for controller-processor and processor-sub-processor relationships across SaaS, professional services, marketing, HR, and other common scenarios.
What's Included in Our Template:
- Article 28 framework: Every clause required by Article 28(3) of the UK GDPR and EU GDPR
- Schedules: Processing description, sub-processor list, technical and organisational measures, transfer details
- Sub-processor controls: Specific or general authorisation paths with notification and objection mechanics
- Breach notification: Defined SLA from awareness with the required content of the notification
- International transfers: Hooks for the EU SCCs, UK IDTA, UK Addendum, and transfer risk assessment
- End-of-term: Defined return-or-delete options with certification requirements
Template Features
- Aligned to UK GDPR, EU GDPR, and current ICO and EDPB guidance
- Suitable for SaaS vendors, professional services, marketing partners, and outsourced functions
- Plain-English drafting alongside the legally required language
- Schedules that operationalise the contract rather than restating it
- Updates tracked against major regulatory changes
- Compatible with EU SCCs (2021 modules), UK IDTA, and the UK Addendum
Important Legal Disclaimer
This template is provided for informational purposes only and does not constitute legal advice. Data processing agreements involve the UK GDPR, EU GDPR, the Data Protection Act 2018, sector-specific regulations, and ongoing regulator guidance from the ICO and EU national supervisory authorities. While our templates are professionally prepared, every controller-processor relationship is unique and may require specific provisions for your jurisdictions, sectors, and risk profile. We strongly recommend consulting qualified data protection counsel and your Data Protection Officer (where appointed) before relying on any template, particularly for high-risk processing, special category data, or international transfers to non-adequate countries.