Data Processing Agreement (DPA) Template for GDPR Compliance (2025)

Quick Facts

What Is It? A Data Processing Agreement (DPA) is a legally binding contract between a data controller and data processor that governs how personal data is processed under GDPR Article 28.
Who Needs It? Any business that uses third-party service providers (processors) to handle personal data on their behalf (e.g., cloud hosting, CRM, email marketing, analytics, payroll). Required for GDPR, UK GDPR compliance.
Key Requirements Processing instructions, confidentiality, security measures, subprocessor management, data subject rights assistance, audit rights, data deletion/return, breach notification.
When Required? Mandatory under GDPR Article 28 whenever a processor handles personal data on behalf of a controller. Must be in place before processing begins.
Related Documents Privacy Policy, Cookie Policy, Standard Contractual Clauses (SCCs), UK IDTA, Master Service Agreement, Security Exhibit.
Compliance Frameworks GDPR (EU), UK GDPR, CCPA/CPRA (California - recommended but not required), LGPD (Brazil).

What This Template Includes

This comprehensive DPA template includes:

  • GDPR Article 28 compliance (all 8 mandatory requirements)
  • Processing instructions (purpose, duration, data types, data subjects)
  • Security measures (technical and organizational measures per Article 32)
  • Subprocessor management (authorization, notification, objection rights)
  • Data subject rights assistance (access, rectification, deletion, portability)
  • Breach notification (72-hour notification to controller)
  • Audit and inspection rights (controller's right to audit processor)
  • Data deletion and return (upon termination or request)
  • International data transfers (SCCs, UK IDTA, adequacy decisions)
  • Liability and indemnification (GDPR fines, third-party claims)
  • UK GDPR compliance (post-Brexit requirements)

This template is designed for SaaS companies, software vendors, cloud service providers, and any business acting as a data processor for its customers. Customize the bracketed sections to fit your specific relationship.

Data Processing Agreement Template

DATA PROCESSING AGREEMENT (DPA)

Effective Date: [DATE]

This Data Processing Agreement ("DPA") is entered into as of the Effective Date by and between:

[CONTROLLER LEGAL NAME] ("Controller" or "Customer") Address: [CONTROLLER ADDRESS] Contact: [CONTROLLER CONTACT EMAIL]

and

[PROCESSOR LEGAL NAME] ("Processor" or "Service Provider") Address: [PROCESSOR ADDRESS] Contact: [PROCESSOR CONTACT EMAIL]

(each a "Party" and collectively, the "Parties").

RECITALS

WHEREAS, Controller and Processor have entered into a [Master Service Agreement / Terms of Service / Software as a Service Agreement] dated [DATE] (the "Principal Agreement") pursuant to which Processor provides [DESCRIPTION OF SERVICES] (the "Services") to Controller;

WHEREAS, in the course of providing the Services, Processor processes Personal Data on behalf of Controller;

WHEREAS, the Parties wish to comply with the requirements of the General Data Protection Regulation (EU) 2016/679 ("GDPR"), the UK General Data Protection Regulation ("UK GDPR"), and other applicable Data Protection Laws;

WHEREAS, this DPA sets forth the terms and conditions under which Processor will process Personal Data on behalf of Controller in accordance with GDPR Article 28 and other applicable Data Protection Laws;

NOW, THEREFORE, in consideration of the mutual covenants and agreements contained herein, the Parties agree as follows:

1. DEFINITIONS

1.1 The following terms have the meanings set forth below:

(a) "Controller" means the entity that determines the purposes and means of processing Personal Data. In this DPA, Controller is [CONTROLLER NAME].

(b) "Processor" means the entity that processes Personal Data on behalf of the Controller. In this DPA, Processor is [PROCESSOR NAME].

(c) "Sub-processor" means any third-party processor engaged by the Processor to process Personal Data on behalf of the Controller.

(d) "Personal Data" means any information relating to an identified or identifiable natural person as defined in Article 4(1) of the GDPR and applicable Data Protection Laws.

(e) "Processing" means any operation or set of operations performed on Personal Data, such as collection, recording, organization, structuring, storage, adaptation, retrieval, consultation, use, disclosure, dissemination, erasure, or destruction, as defined in Article 4(2) of the GDPR.

(f) "Data Subject" means an identified or identifiable natural person to whom Personal Data relates.

(g) "Data Protection Laws" means all applicable laws and regulations relating to data protection and privacy, including but not limited to:

  • General Data Protection Regulation (EU) 2016/679 ("GDPR")
  • UK General Data Protection Regulation ("UK GDPR")
  • EU ePrivacy Directive (Directive 2002/58/EC)
  • California Consumer Privacy Act ("CCPA") and California Privacy Rights Act ("CPRA") (if applicable)
  • [OTHER APPLICABLE LAWS]

(h) "Supervisory Authority" means an independent public authority established by an EU Member State or the UK pursuant to the GDPR or UK GDPR.

(i) "Personal Data Breach" means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Personal Data transmitted, stored, or otherwise processed, as defined in Article 4(12) of the GDPR.

(j) "Standard Contractual Clauses" or "SCCs" means the standard contractual clauses for the transfer of Personal Data to third countries approved by the European Commission pursuant to GDPR Article 46(2)(c), as may be updated from time to time.

(k) "UK IDTA" means the UK International Data Transfer Agreement issued by the UK Information Commissioner's Office (ICO) pursuant to Section 119A of the UK Data Protection Act 2018.

(l) "Restricted Transfer" means a transfer of Personal Data from the European Economic Area ("EEA") or the United Kingdom ("UK") to a country that has not been recognized by the European Commission or UK government as providing an adequate level of data protection.

1.2 Capitalized terms not defined in this DPA have the meanings set forth in the Principal Agreement or the GDPR/UK GDPR.

2. SCOPE AND DURATION OF PROCESSING

2.1 Subject Matter and Duration

This DPA applies to the Processing of Personal Data by Processor on behalf of Controller in connection with the provision of the Services under the Principal Agreement.

Duration of Processing: The Processing will continue for the duration of the Principal Agreement, unless otherwise terminated in accordance with the terms of this DPA or the Principal Agreement.

2.2 Nature and Purpose of Processing

The Processor shall process Personal Data on behalf of the Controller for the following purposes:

  • [PURPOSE 1: e.g., "To provide cloud-based software services as described in the Principal Agreement"]
  • [PURPOSE 2: e.g., "To provide customer support and troubleshooting"]
  • [PURPOSE 3: e.g., "To monitor and improve the performance and security of the Services"]
  • [OTHER PURPOSES AS APPLICABLE]

2.3 Types of Personal Data

The Personal Data processed under this DPA may include, but is not limited to:

  • Contact Information: Name, email address, phone number, physical address
  • Account Information: Username, password (encrypted), account preferences
  • Professional Information: Job title, employer, department
  • Usage Data: IP address, browser type, device information, log data, cookies
  • Transaction Data: Payment information (if applicable), billing address, purchase history
  • [OTHER DATA TYPES AS APPLICABLE]

[IMPORTANT: SPECIFY THE EXACT TYPES OF PERSONAL DATA YOUR PROCESSOR HANDLES. BE AS SPECIFIC AS POSSIBLE.]

2.4 Categories of Data Subjects

The Data Subjects whose Personal Data may be processed include:

  • Customers: Individuals who are customers or users of the Controller's services
  • Employees: Employees or contractors of the Controller (if applicable)
  • Prospects: Individuals who have expressed interest in the Controller's services
  • [OTHER CATEGORIES AS APPLICABLE]

3. OBLIGATIONS OF THE PROCESSOR

3.1 Processing Instructions

(a) Processor shall process Personal Data only on documented instructions from the Controller, unless required to do so by EU, Member State, or UK law to which the Processor is subject. In such cases, the Processor shall inform the Controller of that legal requirement before processing, unless the law prohibits such information on important grounds of public interest.

(b) The initial instructions for Processing are set forth in this DPA and the Principal Agreement. Any additional or alternative instructions must be agreed upon in writing by both Parties.

(c) If Processor believes that any instruction from Controller violates the GDPR, UK GDPR, or other Data Protection Laws, Processor shall immediately inform Controller.

3.2 Confidentiality

(a) Processor shall ensure that all persons authorized to process Personal Data on behalf of Controller (including Processor's employees, contractors, and agents) have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.

(b) Processor shall maintain the confidentiality of all Personal Data and shall not disclose Personal Data to any third party except as permitted under this DPA or as required by law.

3.3 Security of Processing (Article 32 GDPR)

(a) Processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk of Processing, taking into account:

  • The state of the art
  • The costs of implementation
  • The nature, scope, context, and purposes of Processing
  • The risk of varying likelihood and severity for the rights and freedoms of natural persons

(b) Such measures shall include, as appropriate:

(i) Pseudonymization and encryption of Personal Data;

(ii) Ongoing confidentiality, integrity, availability, and resilience of processing systems and services;

(iii) Ability to restore availability and access to Personal Data in a timely manner in the event of a physical or technical incident;

(iv) Regular testing, assessment, and evaluation of the effectiveness of technical and organizational measures;

(v) Access controls (e.g., multi-factor authentication, role-based access control) to ensure that only authorized personnel can access Personal Data;

(vi) Data minimization (Processing only the minimum Personal Data necessary for the purposes);

(vii) Secure data deletion (ensuring Personal Data is securely deleted when no longer needed);

(viii) Incident response plan (procedures for detecting, reporting, and responding to Personal Data Breaches);

(ix) Physical security (securing data centers, servers, and backup facilities);

(x) Network security (firewalls, intrusion detection/prevention systems, secure transmission protocols).

(c) Security Certifications: [IF APPLICABLE: Processor maintains the following security certifications: SOC 2 Type II, ISO 27001, [OTHER CERTIFICATIONS]. Processor will provide evidence of such certifications upon reasonable request.]

(d) Processor shall conduct regular security assessments and audits to ensure the effectiveness of security measures and shall promptly remediate any identified vulnerabilities.

(e) Detailed Security Measures: A comprehensive description of Processor's technical and organizational security measures is set forth in Annex 2 (Security Measures) to this DPA.

3.4 Sub-processors

(a) General Authorization:

Controller provides [GENERAL / SPECIFIC] written authorization for Processor to engage Sub-processors.

[OPTION 1: GENERAL AUTHORIZATION] Controller provides general written authorization for Processor to engage Sub-processors, subject to the conditions set forth in this Section 3.4.

[OPTION 2: SPECIFIC AUTHORIZATION] Processor shall obtain Controller's prior specific written authorization before engaging any Sub-processor.

(b) Current Sub-processors:

Processor currently engages the Sub-processors listed in Annex 3 (Sub-processors) to this DPA.

(c) Notification and Objection:

[IF GENERAL AUTHORIZATION APPLIES:]

Processor shall inform Controller of any intended changes concerning the addition or replacement of Sub-processors at least [30/60/90] days in advance ("Notification Period").

Controller may object to the engagement of a new Sub-processor on reasonable grounds relating to data protection within [10/14/30] days of receiving notice ("Objection Period"). If Controller objects, the Parties shall work together in good faith to find a commercially reasonable solution. If no solution is found within [30] days, either Party may terminate the Principal Agreement with respect to the Services that require the use of the objected Sub-processor, without penalty.

(d) Sub-processor Agreements:

Where Processor engages a Sub-processor for carrying out specific Processing activities on behalf of Controller:

(i) Processor shall enter into a written agreement with the Sub-processor that imposes data protection obligations equivalent to those set forth in this DPA, including appropriate technical and organizational measures.

(ii) Processor shall ensure that the Sub-processor complies with the GDPR, UK GDPR, and other applicable Data Protection Laws.

(iii) Processor remains fully liable to Controller for the performance of the Sub-processor's obligations under the Sub-processor agreement and for any failure by the Sub-processor to fulfill its data protection obligations.

(e) Sub-processor Audits:

Controller has the right to audit Sub-processors (or appoint an independent auditor to audit Sub-processors) to verify compliance with the Sub-processor's data protection obligations, subject to the same terms as set forth in Section 3.8 (Audit and Inspection Rights).

3.5 Assistance with Data Subject Rights (Chapter III GDPR)

(a) Processor shall assist Controller in responding to requests from Data Subjects to exercise their rights under the GDPR, UK GDPR, or other Data Protection Laws, including:

(i) Right of access (Article 15 GDPR): Right to obtain confirmation and a copy of Personal Data being processed.

(ii) Right to rectification (Article 16 GDPR): Right to correct inaccurate or incomplete Personal Data.

(iii) Right to erasure ("right to be forgotten") (Article 17 GDPR): Right to request deletion of Personal Data.

(iv) Right to restriction of processing (Article 18 GDPR): Right to limit Processing of Personal Data.

(v) Right to data portability (Article 20 GDPR): Right to receive Personal Data in a structured, commonly used, machine-readable format.

(vi) Right to object (Article 21 GDPR): Right to object to Processing based on legitimate interests or for direct marketing purposes.

(vii) Rights related to automated decision-making and profiling (Article 22 GDPR).

(b) Processor shall provide reasonable assistance to Controller in responding to Data Subject requests within [10/14/30] days of receiving Controller's request for assistance, or within such shorter timeframe as may be required by Data Protection Laws.

(c) If Processor receives a Data Subject request directly, Processor shall promptly forward the request to Controller (within [2/5] business days) and shall not respond to the request without Controller's prior written authorization, unless required by law.

(d) Processor may charge Controller a reasonable fee for assistance with Data Subject requests if the requests are manifestly unfounded, excessive, or repetitive. [OPTIONAL: SPECIFY FEE STRUCTURE]

3.6 Assistance with Controller's Compliance Obligations

(a) Processor shall assist Controller in ensuring compliance with the obligations pursuant to:

(i) Article 32 GDPR (Security of Processing) – by implementing and maintaining appropriate technical and organizational measures as described in Section 3.3 and Annex 2.

(ii) Articles 33-34 GDPR (Personal Data Breach Notification) – by notifying Controller of Personal Data Breaches as described in Section 3.7.

(iii) Articles 35-36 GDPR (Data Protection Impact Assessment and Prior Consultation) – by providing information reasonably necessary for Controller to conduct a DPIA or consult with a Supervisory Authority, if required.

(b) Processor shall provide Controller with all information reasonably necessary to demonstrate compliance with the obligations set forth in this DPA and the GDPR/UK GDPR.

3.7 Personal Data Breach Notification

(a) Processor shall notify Controller without undue delay and, where feasible, within 72 hours of becoming aware of a Personal Data Breach.

(b) The notification shall include, to the extent available:

(i) A description of the nature of the Personal Data Breach, including the categories and approximate number of Data Subjects and Personal Data records affected;

(ii) The name and contact details of Processor's data protection officer or other contact point;

(iii) A description of the likely consequences of the Personal Data Breach;

(iv) A description of the measures taken or proposed to be taken by Processor to address the Personal Data Breach, including measures to mitigate its possible adverse effects.

(c) Processor shall provide reasonable assistance to Controller in:

(i) Notifying the Supervisory Authority of the Personal Data Breach (if required by Article 33 GDPR);

(ii) Notifying affected Data Subjects of the Personal Data Breach (if required by Article 34 GDPR);

(iii) Investigating, mitigating, and remediating the Personal Data Breach.

(d) Processor shall not notify any third party (including Data Subjects, Supervisory Authorities, or the media) of a Personal Data Breach without Controller's prior written consent, except as required by law.

(e) Processor shall document all Personal Data Breaches and maintain records for at least [3/5] years, or as required by Data Protection Laws.

3.8 Audit and Inspection Rights

(a) Processor shall allow Controller (or Controller's appointed independent auditor) to conduct audits and inspections to verify Processor's compliance with this DPA and applicable Data Protection Laws.

(b) Audit Frequency: Controller may conduct audits [once per year / upon reasonable notice], or more frequently if: (i) Required by a Supervisory Authority; (ii) A Personal Data Breach has occurred; or (iii) Controller has reasonable grounds to believe Processor is not complying with this DPA.

(c) Audit Notice: Controller shall provide Processor with at least [30/60] days' prior written notice of an audit, except in the case of a Personal Data Breach or Supervisory Authority request, in which case shorter notice (or no notice) may be provided.

(d) Audit Scope: Audits may include: (i) Review of Processor's technical and organizational security measures; (ii) Review of Processor's policies, procedures, and documentation related to data protection; (iii) Interviews with Processor's personnel; (iv) Inspection of Processor's facilities and systems (subject to reasonable security and confidentiality restrictions).

(e) Audit Reports: Processor may satisfy the audit requirement by providing Controller with a copy of a recent third-party audit report (e.g., SOC 2 Type II, ISO 27001 certification report) if such report adequately demonstrates compliance with this DPA.

(f) Audit Costs: Controller shall bear the costs of the audit, unless the audit reveals a material breach of this DPA by Processor, in which case Processor shall reimburse Controller for reasonable audit costs.

(g) Confidentiality: Controller and its auditors shall maintain the confidentiality of any information obtained during the audit and shall use such information solely for the purpose of verifying compliance with this DPA.

3.9 Deletion or Return of Personal Data

(a) Upon termination of the Principal Agreement or upon Controller's written request, Processor shall, at Controller's choice:

(i) Delete all Personal Data in Processor's possession or control; or

(ii) Return all Personal Data to Controller in a commonly used, machine-readable format.

(b) Deletion Timeframe: Processor shall delete or return Personal Data within [30/60/90] days of termination or request, unless otherwise agreed in writing.

(c) Secure Deletion: Processor shall delete Personal Data using secure methods (e.g., overwriting, degaussing, physical destruction of storage media) to ensure the data cannot be recovered.

(d) Retention Exceptions: Processor may retain Personal Data to the extent required by EU, Member State, or UK law, provided that Processor: (i) Informs Controller of the legal requirement to retain Personal Data; (ii) Continues to protect the confidentiality and security of the retained Personal Data; and (iii) Processes the retained Personal Data solely for the purpose required by law.

(e) Certification of Deletion: Upon Controller's request, Processor shall provide written certification that all Personal Data has been deleted or returned, and that no copies remain in Processor's systems (except as permitted under Section 3.9(d)).

(f) Backup Retention: Personal Data may remain in Processor's backup systems for up to [30/60/90] days after deletion, provided that such backup data is not accessible for normal operations and will be securely deleted in accordance with Processor's backup retention schedule.

4. INTERNATIONAL DATA TRANSFERS

4.1 Transfers Outside EEA/UK

If Processor (or its Sub-processors) processes Personal Data outside the European Economic Area ("EEA") or the United Kingdom ("UK"), the Parties shall implement appropriate safeguards to ensure compliance with Data Protection Laws, including:

(a) Adequacy Decisions:

If Personal Data is transferred to a country recognized by the European Commission (for GDPR) or the UK government (for UK GDPR) as providing an adequate level of data protection, no additional safeguards are required.

Current countries with adequacy decisions include (as of 2025):

  • EU Adequacy Decisions: Andorra, Argentina, Canada (commercial organizations), Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New Zealand, Republic of Korea, Switzerland, United Kingdom, Uruguay, United States (EU-U.S. Data Privacy Framework participants).
  • UK Adequacy Decisions: EEA countries, Switzerland, [others as designated].

(b) Standard Contractual Clauses (SCCs):

If Personal Data is transferred to a country without an adequacy decision, the Parties shall execute the Standard Contractual Clauses (SCCs) approved by the European Commission pursuant to GDPR Article 46(2)(c).

For transfers subject to GDPR: The Parties agree to be bound by the EU Standard Contractual Clauses set forth in Annex 4 (Standard Contractual Clauses - EU).

(c) UK International Data Transfer Agreement (UK IDTA):

If Personal Data is transferred outside the UK (and not covered by a UK adequacy decision), the Parties shall execute the UK International Data Transfer Agreement (UK IDTA) issued by the UK Information Commissioner's Office (ICO) pursuant to Section 119A of the UK Data Protection Act 2018.

For transfers subject to UK GDPR: The Parties agree to be bound by the UK IDTA set forth in Annex 5 (UK International Data Transfer Agreement).

(d) Transfer Impact Assessment (TIA):

Before transferring Personal Data to a third country without an adequacy decision, the Parties shall conduct a Transfer Impact Assessment (TIA) to assess whether the laws and practices of the destination country provide an adequate level of protection for the Personal Data, taking into account:

  • The nature of the Personal Data;
  • The purposes and duration of Processing;
  • The risks to Data Subjects;
  • The legal framework of the destination country (including government access to data, surveillance laws, etc.);
  • The supplementary measures (if any) implemented by Processor to ensure adequate protection.

4.2 U.S. Data Privacy Framework

[IF PROCESSOR IS CERTIFIED UNDER THE EU-U.S. DATA PRIVACY FRAMEWORK:]

Processor is certified under the EU-U.S. Data Privacy Framework (and/or UK Extension to the EU-U.S. Data Privacy Framework, and/or Swiss-U.S. Data Privacy Framework) and commits to processing Personal Data in accordance with the Principles of the applicable Framework(s).

Processor's certification can be verified at https://www.dataprivacyframework.gov/.

By virtue of Processor's certification, transfers of Personal Data from the EEA/UK/Switzerland to Processor in the United States are permitted under GDPR Article 45 (adequacy decision).

4.3 Ongoing Monitoring

Processor shall continuously monitor the legal and factual circumstances surrounding international data transfers and shall immediately notify Controller if:

  • Processor is no longer able to comply with the SCCs, UK IDTA, or other transfer mechanisms;
  • Processor receives a request from a government authority or court to disclose Personal Data (subject to legal restrictions on such notification);
  • There are changes to the laws or practices of the destination country that may affect the adequacy of protection for Personal Data.

5. LIABILITY AND INDEMNIFICATION

5.1 Liability Under GDPR

Each Party shall be liable for damage caused by its Processing of Personal Data to the extent such Processing is in violation of the GDPR, UK GDPR, or this DPA, in accordance with Articles 82-83 of the GDPR.

5.2 Indemnification by Processor

Processor shall indemnify, defend, and hold harmless Controller from and against any and all losses, damages, liabilities, costs, and expenses (including reasonable attorneys' fees) arising out of or relating to:

(a) Processor's breach of this DPA or applicable Data Protection Laws;

(b) Processor's failure to implement appropriate technical and organizational security measures;

(c) Any Personal Data Breach caused by Processor's negligence or willful misconduct;

(d) Third-party claims (including Data Subject claims and Supervisory Authority fines or penalties) arising from Processor's non-compliance with this DPA or Data Protection Laws.

5.3 Limitation of Liability

[IMPORTANT: CONSULT LEGAL COUNSEL ON LIABILITY CAPS. GDPR DOES NOT ALLOW PROCESSORS TO LIMIT LIABILITY FOR DATA PROTECTION VIOLATIONS. HOWEVER, THE PRINCIPAL AGREEMENT MAY INCLUDE GENERAL LIMITATIONS OF LIABILITY THAT APPLY TO OTHER CLAIMS.]

Notwithstanding any limitation of liability in the Principal Agreement, Processor's liability for violations of this DPA or Data Protection Laws shall not be limited or excluded, except to the extent such limitation or exclusion is expressly permitted by applicable law.

6. TERM AND TERMINATION

6.1 Term

This DPA shall commence on the Effective Date and shall remain in effect for the duration of the Principal Agreement, unless earlier terminated in accordance with this Section 6.

6.2 Termination

(a) Either Party may terminate this DPA if the other Party materially breaches this DPA and fails to cure such breach within [30] days of receiving written notice.

(b) Controller may terminate this DPA (and the Principal Agreement) immediately if: (i) Processor is unable to comply with this DPA or Data Protection Laws; (ii) Processor suffers a significant Personal Data Breach that compromises the security or confidentiality of Personal Data; (iii) A Supervisory Authority orders Controller to cease using Processor's services due to non-compliance.

(c) Upon termination of this DPA or the Principal Agreement, Processor shall delete or return Personal Data as described in Section 3.9.

6.3 Survival

The following provisions shall survive termination of this DPA: Sections 3.2 (Confidentiality), 3.9 (Deletion or Return of Personal Data), 5 (Liability and Indemnification), 6.3 (Survival), and 7 (General Provisions).

7. GENERAL PROVISIONS

7.1 Relationship to Principal Agreement

This DPA is incorporated into and forms part of the Principal Agreement. In the event of a conflict between this DPA and the Principal Agreement with respect to data protection matters, this DPA shall prevail.

7.2 Amendments

This DPA may only be amended by a written agreement signed by both Parties, except that Processor may amend Annex 2 (Security Measures) and Annex 3 (Sub-processors) in accordance with the notification and objection procedures set forth in Sections 3.3 and 3.4, respectively.

7.3 Severability

If any provision of this DPA is held to be invalid, illegal, or unenforceable, the remaining provisions shall remain in full force and effect. The Parties shall negotiate in good faith to replace any invalid provision with a valid provision that achieves, to the extent possible, the original intent.

7.4 Governing Law

[OPTION 1: EU MEMBER STATE LAW] This DPA shall be governed by and construed in accordance with the laws of [EU MEMBER STATE], without regard to its conflict of laws principles.

[OPTION 2: UK LAW] This DPA shall be governed by and construed in accordance with the laws of England and Wales, without regard to its conflict of laws principles.

[OPTION 3: U.S. STATE LAW - IF ADEQUACY MECHANISM APPLIES] This DPA shall be governed by and construed in accordance with the laws of the State of [STATE], without regard to its conflict of laws principles, except that data protection obligations shall be governed by the GDPR and UK GDPR as applicable.

7.5 Jurisdiction

Any dispute arising out of or relating to this DPA shall be subject to the exclusive jurisdiction of the courts of [JURISDICTION], except that Data Subjects shall retain the right to bring claims in the courts of the EU Member State or UK country where they have their habitual residence, in accordance with Article 79 of the GDPR.

7.6 Order of Precedence

In the event of a conflict between: (a) This DPA and the Principal Agreement: This DPA prevails with respect to data protection matters. (b) This DPA and the Standard Contractual Clauses (Annex 4) or UK IDTA (Annex 5): The SCCs/UK IDTA prevail. (c) The Principal Agreement and the Standard Contractual Clauses (Annex 4) or UK IDTA (Annex 5): The SCCs/UK IDTA prevail.

7.7 Entire Agreement

This DPA, together with the Principal Agreement and all annexes, constitutes the entire agreement between the Parties with respect to the subject matter hereof and supersedes all prior or contemporaneous agreements, understandings, or representations, whether written or oral.

7.8 Notices

All notices under this DPA shall be in writing and delivered to the addresses set forth in the preamble, or to such other address as a Party may designate by written notice.

7.9 Language

This DPA is executed in [ENGLISH / OTHER LANGUAGE]. If this DPA is translated into another language, the [ENGLISH] version shall prevail in the event of a conflict.

7.10 Counterparts

This DPA may be executed in counterparts, each of which shall be deemed an original and all of which together shall constitute one and the same instrument. Electronic signatures shall have the same force and effect as original signatures.

SIGNATURE

IN WITNESS WHEREOF, the Parties have executed this Data Processing Agreement as of the Effective Date.

CONTROLLER:

[CONTROLLER LEGAL NAME]

By: ___ Name: [NAME] Title: [TITLE] Date: [DATE]

PROCESSOR:

[PROCESSOR LEGAL NAME]

By: ___ Name: [NAME] Title: [TITLE] Date: [DATE]

ANNEX 1: DETAILS OF PROCESSING

A. LIST OF PARTIES

Controller:

  • Name: [CONTROLLER LEGAL NAME]
  • Address: [CONTROLLER ADDRESS]
  • Contact Person: [NAME, TITLE]
  • Email: [EMAIL]
  • Phone: [PHONE]

Processor:

  • Name: [PROCESSOR LEGAL NAME]
  • Address: [PROCESSOR ADDRESS]
  • Contact Person: [NAME, TITLE]
  • Email: [EMAIL]
  • Phone: [PHONE]

B. DESCRIPTION OF PROCESSING

Nature of Processing: [e.g., "Processor will store, retrieve, and process Personal Data in connection with providing cloud-based software services to Controller."]

Purpose of Processing: [e.g., "To enable Controller to use Processor's SaaS platform for customer relationship management, including storing customer contact information, tracking interactions, and generating reports."]

Duration of Processing: [e.g., "For the term of the Principal Agreement, plus 30 days for data deletion/return."]

C. TYPES OF PERSONAL DATA

[List all types of Personal Data, e.g.:]

  • Name
  • Email address
  • Phone number
  • Physical address
  • Job title and employer
  • IP address
  • Device information
  • Usage data (login times, pages viewed, etc.)
  • [OTHER DATA TYPES]

D. CATEGORIES OF DATA SUBJECTS

[List all categories of Data Subjects, e.g.:]

  • Controller's customers
  • Controller's employees
  • Controller's prospects (potential customers)
  • [OTHER CATEGORIES]

E. SPECIAL CATEGORIES OF DATA (IF APPLICABLE)

[Special categories include racial/ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, biometric data, health data, sex life, or sexual orientation (Article 9 GDPR)]

[IF NO SPECIAL CATEGORIES:] This DPA does not authorize Processor to process special categories of Personal Data as defined in Article 9 of the GDPR.

[IF SPECIAL CATEGORIES ARE PROCESSED:] Processor is authorized to process the following special categories of Personal Data:

  • [LIST SPECIAL CATEGORIES, e.g., "Health data for the purpose of providing telehealth services"]

F. PROCESSING LOCATIONS

Primary Processing Locations: [List countries/regions where Personal Data will be processed, e.g.:]

  • United States (AWS us-east-1, us-west-2)
  • European Union (AWS eu-west-1)
  • [OTHER LOCATIONS]

Backup/Disaster Recovery Locations: [List countries/regions where backups are stored, e.g.:]

  • United States (AWS us-east-1)
  • [OTHER LOCATIONS]

ANNEX 2: TECHNICAL AND ORGANIZATIONAL SECURITY MEASURES

Processor implements the following technical and organizational measures to protect Personal Data:

A. ORGANIZATIONAL MEASURES

1. Information Security Policies and Procedures

  • Written information security policy reviewed and updated annually
  • Data protection and privacy policies
  • Incident response and breach notification procedures
  • Vendor management and third-party security assessment procedures

2. Personnel Security

  • Background checks for employees with access to Personal Data (where permitted by law)
  • Confidentiality agreements signed by all employees and contractors
  • Regular security awareness training for all personnel
  • Role-based access controls (RBAC) limiting access to Personal Data based on job function

3. Data Protection Officer (DPO) / Privacy Contact

  • [IF REQUIRED BY GDPR ARTICLE 37: Name and contact details of DPO]
  • Privacy point of contact: [EMAIL]

4. Security Certifications and Audits [List certifications, e.g.:]

  • SOC 2 Type II (annual audit)
  • ISO 27001:2013 certified
  • PCI DSS Level [1/2/3/4] (if applicable)
  • [OTHER CERTIFICATIONS]

B. TECHNICAL MEASURES

1. Access Controls

  • Multi-factor authentication (MFA) required for all user accounts
  • Role-based access control (RBAC) limiting access based on principle of least privilege
  • Unique user credentials for all personnel (no shared accounts)
  • Automatic session timeout after [15/30] minutes of inactivity
  • Regular access reviews (at least quarterly) to remove unnecessary access

2. Encryption

Encryption in Transit:

  • TLS 1.2 or higher for all data transmitted over public networks
  • HTTPS enforced for all web traffic
  • VPN or other secure channels for internal data transfers

Encryption at Rest:

  • AES-256 encryption for all Personal Data stored in databases
  • Full-disk encryption for all servers, workstations, and mobile devices
  • Encrypted backups using industry-standard encryption algorithms

3. Network Security

  • Firewalls protecting all network perimeters
  • Intrusion detection and prevention systems (IDS/IPS)
  • Network segmentation to isolate systems processing Personal Data
  • Secure network architecture (DMZ, private subnets, etc.)
  • Regular vulnerability scanning and penetration testing

4. System Security

  • Antivirus and anti-malware software on all endpoints
  • Security patches and updates applied within [30] days of release (or sooner for critical vulnerabilities)
  • Hardened server configurations following CIS benchmarks or equivalent standards
  • Secure development practices (secure coding standards, code reviews, static/dynamic analysis)

5. Data Minimization and Pseudonymization

  • Personal Data is pseudonymized where feasible (e.g., using tokenization, hashing)
  • Only minimum necessary Personal Data is collected and processed
  • Automated deletion of Personal Data when no longer needed

6. Logging and Monitoring

  • Centralized logging of all access to Personal Data
  • Security information and event management (SIEM) system monitoring for anomalies
  • Logs retained for at least [12] months
  • Regular log reviews to detect unauthorized access or suspicious activity

7. Backup and Disaster Recovery

  • Automated daily backups of all Personal Data
  • Encrypted backups stored in geographically separate locations
  • Regular backup restoration testing (at least annually)
  • Disaster recovery plan with RTO [X hours] and RPO [Y hours]
  • Business continuity plan tested at least annually

8. Incident Response

  • Documented incident response plan
  • 24/7 security operations center (SOC) or equivalent monitoring
  • Breach notification procedures compliant with GDPR Articles 33-34
  • Post-incident reviews and remediation

9. Physical Security

  • Data centers certified to [ISO 27001 / SOC 2 / other standards]
  • 24/7 physical security (guards, surveillance cameras, access control)
  • Biometric or badge-based access control for server rooms
  • Secure disposal of hardware (degaussing, shredding, certified destruction)

10. Application Security

  • Secure authentication and authorization mechanisms
  • Protection against OWASP Top 10 vulnerabilities
  • Regular security testing (penetration testing, vulnerability scanning)
  • Secure API design (authentication, rate limiting, input validation)

C. DATA BREACH RESPONSE

In the event of a Personal Data Breach, Processor will:

  1. Contain and investigate the breach within [24] hours of detection
  2. Notify Controller within [72] hours of becoming aware of the breach
  3. Provide detailed incident report including:
    • Nature and scope of the breach
    • Data Subjects and data records affected
    • Likely consequences
    • Measures taken to mitigate the breach
  4. Cooperate with Controller in notifying Supervisory Authorities and Data Subjects (if required)
  5. Conduct post-incident review and implement corrective actions

D. REGULAR TESTING AND REVIEW

Processor conducts the following regular testing and assessments:

  • Annual SOC 2 Type II audit (or equivalent)
  • Quarterly vulnerability scans
  • Annual penetration testing
  • Annual disaster recovery testing
  • Quarterly access reviews
  • Annual review and update of security policies

ANNEX 3: LIST OF SUB-PROCESSORS

Processor currently engages the following Sub-processors:

Sub-processor Name Service Provided Processing Location Data Processed
[e.g., Amazon Web Services (AWS)] [Cloud hosting and infrastructure] [United States, EU] [All Personal Data types]
[e.g., Stripe, Inc.] [Payment processing] [United States] [Payment information, billing address]
[e.g., SendGrid, Inc.] [Email delivery service] [United States] [Email addresses, names]
[e.g., Intercom, Inc.] [Customer support chat] [United States] [Names, email addresses, usage data]
[ADD ALL SUB-PROCESSORS] [Service] [Location] [Data types]

Sub-processor Change Notification:

Processor shall notify Controller of any changes to this list at least [30] days in advance by:

  • Posting updates to [PROCESSOR WEBSITE URL/subprocessors]
  • Sending email notification to [CONTROLLER EMAIL]
  • [OTHER NOTIFICATION METHOD]

Controller may subscribe to automatic notifications of Sub-processor changes at: [NOTIFICATION SUBSCRIPTION URL]

Objection Process:

If Controller objects to a new Sub-processor, Controller shall notify Processor in writing within [14] days of receiving the change notification. The Parties shall work together in good faith to resolve the objection within [30] days. If no resolution is reached, Controller may terminate the Principal Agreement with respect to the Services requiring the objected Sub-processor.

ANNEX 4: STANDARD CONTRACTUAL CLAUSES (EU) - MODULE TWO (CONTROLLER-TO-PROCESSOR)

[INSERT THE EU STANDARD CONTRACTUAL CLAUSES APPROVED BY THE EUROPEAN COMMISSION PURSUANT TO COMMISSION IMPLEMENTING DECISION (EU) 2021/914 OF 4 JUNE 2021]

Note: The full text of the EU Standard Contractual Clauses (Module Two: Controller-to-Processor) can be found at: https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj

Key Provisions:

  • Module: Module Two (Controller to Processor)
  • Docking Clause (Clause 7): [APPLICABLE / NOT APPLICABLE]
  • Applicable Law (Clause 17): [EU MEMBER STATE LAW, e.g., "Law of Ireland"]
  • Choice of Forum (Clause 18): [EU MEMBER STATE JURISDICTION, e.g., "Courts of Ireland"]
  • Technical and Organizational Measures (Annex II): See Annex 2 of this DPA
  • List of Sub-processors (Annex III): See Annex 3 of this DPA

[IMPORTANT: THE FULL SCCs MUST BE ATTACHED TO THIS DPA. CONSULT LEGAL COUNSEL TO ENSURE PROPER IMPLEMENTATION.]

ANNEX 5: UK INTERNATIONAL DATA TRANSFER AGREEMENT (UK IDTA)

[INSERT THE UK INTERNATIONAL DATA TRANSFER AGREEMENT (UK IDTA) ISSUED BY THE UK INFORMATION COMMISSIONER'S OFFICE PURSUANT TO SECTION 119A OF THE UK DATA PROTECTION ACT 2018]

Note: The UK IDTA template can be found at: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/international-data-transfer-agreement-and-guidance/

Key Information for UK IDTA:

  • Start Date: [DATE]
  • The Parties: Exporter (Controller) and Importer (Processor) as identified in this DPA
  • Table 1: Parties and Key Details: See Annex 1 of this DPA
  • Table 2: Selected SCCs, Modules and Selected Clauses: Module 2 (Controller to Processor)
  • Table 3: Appendix Information: See Annexes 1, 2, and 3 of this DPA
  • Table 4: Ending this Addendum: As specified in the UK IDTA

[IMPORTANT: THE FULL UK IDTA MUST BE ATTACHED TO THIS DPA. CONSULT LEGAL COUNSEL TO ENSURE PROPER IMPLEMENTATION.]

ANNEX 6: DATA PROTECTION IMPACT ASSESSMENT (DPIA) ASSISTANCE

[OPTIONAL ANNEX - INCLUDE IF CONTROLLER REQUIRES PROCESSOR ASSISTANCE WITH DPIA]

If Controller is required to conduct a Data Protection Impact Assessment (DPIA) pursuant to Article 35 of the GDPR, Processor shall provide the following assistance:

A. Information to be Provided by Processor:

  1. Description of Processing Operations:

    • Nature, scope, context, and purposes of Processing
    • Categories of Personal Data and Data Subjects
    • Processing locations and Sub-processors involved

  2. Assessment of Necessity and Proportionality:

    • Why the Processing is necessary for Controller's purposes
    • Why the Processing is proportionate to those purposes

  3. Assessment of Risks to Data Subjects:

    • Risks arising from the Processing (e.g., data breach, unauthorized access, discrimination)
    • Likelihood and severity of risks
    • Measures to mitigate risks

  4. Security Measures:

    • Technical and organizational measures implemented by Processor (see Annex 2)
    • Certifications and audit reports demonstrating compliance

  5. Compliance Measures:

    • How Processor ensures compliance with GDPR and this DPA
    • Data protection policies and procedures
    • Training provided to personnel

B. Timeframe for Assistance:

Processor shall provide the requested information within [30] days of receiving Controller's written request, or within such shorter timeframe as may be required by law or the Supervisory Authority.

C. Fees for Assistance:

Processor's assistance with the DPA shall be provided [AT NO ADDITIONAL COST / SUBJECT TO PROCESSOR'S THEN-CURRENT PROFESSIONAL SERVICES RATES].

END OF DPA TEMPLATE

Download

Download DPA Template (Markdown) Download DPA Template (Word) Download DPA Template (PDF)

(Download buttons to be implemented by your development team.)

Customization Checklist

Use this checklist to customize the DPA template for your business:

  • [ ] Replace all bracketed placeholders (e.g., [CONTROLLER NAME], [PROCESSOR NAME], [DATE]) with your actual information.
  • [ ] Complete Annex 1 with specific details about the Processing (data types, data subjects, purposes, locations).
  • [ ] Complete Annex 2 with your actual security measures (be as specific as possible).
  • [ ] Complete Annex 3 with a comprehensive list of all Sub-processors (including cloud providers, payment processors, email services, analytics tools, etc.).
  • [ ] Attach the full EU Standard Contractual Clauses (Annex 4) if you transfer data outside the EEA.
  • [ ] Attach the full UK IDTA (Annex 5) if you transfer data outside the UK.
  • [ ] Specify authorization model for Sub-processors (general vs. specific authorization) in Section 3.4(a).
  • [ ] Specify notification period for Sub-processor changes (30/60/90 days) in Section 3.4(c).
  • [ ] Specify objection period for Sub-processor changes (10/14/30 days) in Section 3.4(c).
  • [ ] Specify breach notification timeframe (72 hours recommended) in Section 3.7(a).
  • [ ] Specify audit frequency (annually recommended) in Section 3.8(b).
  • [ ] Specify data deletion timeframe upon termination (30/60/90 days) in Section 3.9(b).
  • [ ] Choose governing law (EU Member State, UK, or U.S. state with adequate mechanism) in Section 7.4.
  • [ ] Review liability provisions with legal counsel (Section 5).
  • [ ] Ensure consistency between this DPA and your Master Service Agreement or Terms of Service.
  • [ ] Have both parties sign the DPA (electronic signatures are acceptable).

Key Provisions Explained

1. Processing Instructions (Section 3.1)

What it means: The processor can only process personal data according to the controller's documented instructions. The processor cannot process data for its own purposes or use data in ways not authorized by the controller.

Why it's important: This is a core requirement of GDPR Article 28. It ensures the controller maintains control over how their customers' personal data is used.

Example: If you use a cloud hosting provider (processor), they can only store and retrieve your data as instructed. They cannot analyze your customer data for their own marketing purposes or share it with third parties without your authorization.

2. Confidentiality (Section 3.2)

What it means: All employees, contractors, and agents of the processor who have access to personal data must sign confidentiality agreements or be under a statutory obligation of confidentiality.

Why it's important: Protects personal data from unauthorized disclosure by processor personnel.

Example: All employees of your SaaS vendor who might access your customer data must sign NDAs and be trained on data protection obligations.

3. Security Measures (Section 3.3 + Annex 2)

What it means: The processor must implement appropriate technical and organizational measures to protect personal data, including encryption, access controls, logging, backup, incident response, etc.

Why it's important: GDPR Article 32 requires both controllers and processors to implement security measures appropriate to the risk. Failure to do so can result in significant fines (up to €10 million or 2% of global turnover).

Example: Your cloud provider must encrypt data at rest and in transit, use multi-factor authentication, conduct regular security audits, and have an incident response plan.

4. Sub-processors (Section 3.4 + Annex 3)

What it means: The processor cannot engage sub-processors (e.g., subcontractors) without the controller's authorization. The controller must be notified of any new sub-processors and given the opportunity to object.

Why it's important: Ensures the controller knows who has access to their customers' personal data and can assess the risks.

Example: If your SaaS vendor wants to use a new email delivery service (sub-processor), they must notify you 30 days in advance. If you object (e.g., because the sub-processor has poor security), the vendor must find an alternative or allow you to terminate the agreement.

5. Data Subject Rights Assistance (Section 3.5)

What it means: The processor must assist the controller in responding to data subject requests (access, deletion, rectification, portability, objection, etc.).

Why it's important: Controllers are ultimately responsible for responding to data subject requests under GDPR Chapter III, but they rely on processors to provide the data or perform the requested actions.

Example: If one of your customers requests deletion of their data under GDPR Article 17, your SaaS vendor must delete the customer's data from their systems within a reasonable timeframe (e.g., 14 days).

6. Breach Notification (Section 3.7)

What it means: The processor must notify the controller of any personal data breach within 72 hours (or as soon as feasible).

Why it's important: GDPR Article 33 requires controllers to notify supervisory authorities of breaches within 72 hours. Controllers cannot meet this deadline if processors delay notification.

Example: If your cloud provider suffers a breach that exposes your customer data, they must notify you within 72 hours so you can notify the relevant data protection authority and affected customers.

7. Audit Rights (Section 3.8)

What it means: The controller (or an independent auditor) has the right to audit the processor to verify compliance with the DPA and data protection laws.

Why it's important: GDPR Article 28(3)(h) requires processors to make available all information necessary to demonstrate compliance and allow audits.

Example: You can conduct an annual audit of your SaaS vendor (or review their SOC 2 Type II report) to verify they are implementing the security measures promised in the DPA.

8. Data Deletion/Return (Section 3.9)

What it means: Upon termination of the agreement or upon request, the processor must delete or return all personal data and certify that it has been deleted.

Why it's important: Ensures personal data is not retained longer than necessary and cannot be accessed after the relationship ends.

Example: When you stop using a SaaS platform, the vendor must delete all your customer data within 30 days (or return it to you in a portable format) and provide written certification that the data has been deleted.

9. Standard Contractual Clauses (Annex 4) and UK IDTA (Annex 5)

What it means: If the processor (or sub-processor) processes personal data outside the EEA or UK, the parties must implement additional safeguards, such as Standard Contractual Clauses (SCCs) or the UK International Data Transfer Agreement (UK IDTA).

Why it's important: GDPR Chapter V restricts transfers of personal data to countries outside the EEA unless adequate safeguards are in place. The European Commission's adequacy decisions and SCCs are the primary mechanisms for lawful transfers.

Example: If you (EEA-based controller) use a U.S.-based SaaS provider (processor) that is not certified under the EU-U.S. Data Privacy Framework, you must execute the EU Standard Contractual Clauses (Module 2: Controller to Processor) to ensure the transfer is lawful.

Common Mistakes to Avoid

1. Not Executing a DPA at All

Mistake: Using third-party service providers (processors) without a signed DPA.

Why it's a problem: GDPR Article 28(3) requires a written contract between the controller and processor. Failure to have a DPA in place is a violation of GDPR and can result in fines.

How to fix: Execute a DPA with every third-party vendor that processes personal data on your behalf (cloud providers, CRM platforms, email marketing tools, analytics providers, payment processors, etc.).

2. Using a Generic DPA That Doesn't Specify Processing Details

Mistake: Using a template DPA without completing Annex 1 (details of processing), Annex 2 (security measures), or Annex 3 (sub-processors).

Why it's a problem: A DPA must contain specific details about the processing activities, data types, security measures, and sub-processors. A generic DPA does not meet GDPR requirements.

How to fix: Complete all annexes with specific, detailed information about your processing relationship.

3. Not Listing All Sub-processors

Mistake: Failing to list all sub-processors in Annex 3, or not updating Annex 3 when new sub-processors are added.

Why it's a problem: GDPR Article 28(2) requires processors to obtain authorization before engaging sub-processors. Controllers must know who has access to their customers' personal data.

How to fix: Maintain a comprehensive, up-to-date list of all sub-processors, including cloud hosting providers, CDNs, payment processors, email delivery services, analytics tools, customer support platforms, etc.

4. Not Implementing Standard Contractual Clauses for International Transfers

Mistake: Transferring personal data to processors outside the EEA/UK without executing Standard Contractual Clauses (SCCs) or the UK IDTA.

Why it's a problem: Violates GDPR Chapter V (international transfers). Transfers without adequate safeguards can result in supervisory authority enforcement actions, including orders to suspend the transfer.

How to fix: If you transfer data to a processor in a country without an adequacy decision, execute the EU Standard Contractual Clauses (Annex 4) and/or UK IDTA (Annex 5). Conduct a Transfer Impact Assessment (TIA) to ensure the transfer is lawful.

5. Not Specifying Breach Notification Timeframe

Mistake: Not including a specific timeframe for the processor to notify the controller of a personal data breach.

Why it's a problem: GDPR Article 33 requires controllers to notify supervisory authorities within 72 hours of becoming aware of a breach. If the processor delays notification, the controller cannot meet this deadline.

How to fix: Specify that the processor must notify the controller within 72 hours of becoming aware of a breach (Section 3.7(a)).

6. Not Conducting Audits or Reviewing Security Certifications

Mistake: Signing a DPA but never auditing the processor or reviewing their security certifications (SOC 2, ISO 27001, etc.).

Why it's a problem: GDPR Article 28(3)(h) gives controllers the right to audit processors. If you don't exercise this right, you have no way to verify the processor is actually implementing the promised security measures.

How to fix: Conduct annual audits (or review the processor's SOC 2 Type II reports) to verify compliance. Include audit rights in Section 3.8 of the DPA.

7. Not Requiring Data Deletion Upon Termination

Mistake: Not including a clause requiring the processor to delete or return personal data upon termination.

Why it's a problem: GDPR Article 28(3)(g) requires processors to delete or return personal data at the controller's choice upon termination. If data is not deleted, the processor continues to process it unlawfully.

How to fix: Include a data deletion/return clause (Section 3.9) and specify a reasonable timeframe (e.g., 30 days after termination).

8. Not Updating the DPA When Processing Activities Change

Mistake: Signing a DPA and never updating it, even though the processing activities have changed (e.g., new data types, new sub-processors, new processing locations).

Why it's a problem: The DPA must accurately reflect the current processing activities. An outdated DPA does not comply with GDPR.

How to fix: Review and update the DPA at least annually, or whenever there are significant changes to the processing activities. Update Annex 1 (processing details), Annex 2 (security measures), and Annex 3 (sub-processors) as needed.

9. Not Obtaining Sub-processor Authorization

Mistake: The processor engages new sub-processors without notifying the controller or obtaining authorization.

Why it's a problem: Violates GDPR Article 28(2) and Section 3.4 of the DPA. Controllers have the right to object to new sub-processors on data protection grounds.

How to fix: Implement a sub-processor notification process (e.g., email notification 30 days in advance, or maintain a public list of sub-processors on your website). Allow controllers to object within the objection period.

10. Not Addressing International Transfers in the DPA

Mistake: Not including provisions for international data transfers, or not executing SCCs/UK IDTA when required.

Why it's a problem: Violates GDPR Chapter V. Transfers to countries without adequacy decisions require additional safeguards (SCCs, UK IDTA, Binding Corporate Rules, etc.).

How to fix: Include Section 4 (International Data Transfers) in the DPA. If you transfer data outside the EEA/UK, execute the EU Standard Contractual Clauses (Annex 4) and/or UK IDTA (Annex 5).

When to Use This Template

You should use this DPA template if:

  • You are a data controller (e.g., a SaaS company) and you use third-party service providers (processors) to handle customer data on your behalf.
  • You are a data processor (e.g., a cloud hosting provider, CRM platform, email marketing tool) and your customers (controllers) require a DPA to comply with GDPR.
  • You process personal data of individuals in the EU or UK and are subject to GDPR or UK GDPR.
  • You need to comply with GDPR Article 28 requirements for controller-processor agreements.

Common controller-processor relationships that require a DPA:

  • SaaS company (controller) using AWS, Google Cloud, or Azure for cloud hosting (processor)
  • E-commerce company (controller) using Stripe or PayPal for payment processing (processor)
  • Marketing agency (controller) using HubSpot, Salesforce, or Mailchimp for CRM/email marketing (processor)
  • Employer (controller) using Gusto, ADP, or Rippling for payroll processing (processor)
  • Healthcare provider (controller) using telehealth platforms or EHR systems (processor)

FAQs

What is the difference between a controller and a processor?

Answer:

  • Data Controller: The entity that determines the purposes and means of processing personal data. In other words, the controller decides why and how personal data is processed.

    • Example: A SaaS company that collects customer information to provide software services is a controller.

  • Data Processor: The entity that processes personal data on behalf of the controller according to the controller's instructions.

    • Example: A cloud hosting provider (AWS, Google Cloud, Azure) that stores customer data for a SaaS company is a processor.

Key distinction: Controllers make decisions about data processing; processors act on the controller's instructions.

Do I need a DPA if I'm using a well-known cloud provider like AWS or Google Cloud?

Answer: Yes. GDPR Article 28(3) requires a written contract between the controller and processor, regardless of how well-known or reputable the processor is.

Most major cloud providers (AWS, Google Cloud, Azure, etc.) offer standard DPAs that customers can sign electronically. Check your provider's website for their DPA.

What is the difference between a DPA and Standard Contractual Clauses (SCCs)?

Answer:

  • DPA: A contract between a controller and processor that governs how the processor will process personal data (processing instructions, security measures, sub-processors, breach notification, etc.). Required by GDPR Article 28 for all controller-processor relationships.

  • Standard Contractual Clauses (SCCs): A specific set of contractual clauses approved by the European Commission for international data transfers from the EEA to countries without adequacy decisions. Required by GDPR Article 46 for restricted transfers (transfers to countries outside the EEA without adequacy decisions).

Relationship: The DPA governs the controller-processor relationship. The SCCs (which are incorporated into the DPA as Annex 4) govern international transfers. If the processor is located in the EEA, you only need a DPA. If the processor is located outside the EEA (e.g., in the U.S.), you need both a DPA and SCCs (unless the processor is covered by an adequacy decision, such as the EU-U.S. Data Privacy Framework).

Do I need a DPA for CCPA/CPRA compliance (California)?

Answer: The CCPA and CPRA do not explicitly require a written contract between a business and service provider (the CCPA/CPRA equivalents of controller and processor). However, the CCPA does require businesses to include certain provisions in their contracts with service providers, such as:

  • Service provider can only use personal information for the specific purposes stated in the contract.
  • Service provider cannot sell, retain, or disclose personal information for any purpose other than performing the services.

Best practice: Even if not strictly required by CCPA, using a DPA (or DPA-like contract) for your service provider relationships is a good practice to ensure data protection compliance. Many California businesses use GDPR-compliant DPAs to cover both GDPR and CCPA obligations.

Can I use the same DPA for multiple service providers?

Answer: No. Each DPA must be specific to the controller-processor relationship. You need a separate DPA for each processor (e.g., one DPA with AWS for cloud hosting, another DPA with Stripe for payment processing, another DPA with SendGrid for email delivery, etc.).

However, if you are a processor providing services to multiple controllers, you can use the same DPA template for all your customers, as long as you customize the annexes (Annex 1, 2, 3) for each customer relationship.

What happens if a processor violates the DPA?

Answer:

  • GDPR Liability (Article 82): Both controllers and processors can be held liable for damages caused by unlawful processing. If a processor breaches the DPA, the controller may sue the processor for damages.

  • Supervisory Authority Fines (Article 83): Supervisory authorities can fine processors up to €10 million or 2% of global turnover (whichever is higher) for violating GDPR obligations (e.g., failing to implement adequate security measures, engaging unauthorized sub-processors, etc.).

  • Termination: The controller can terminate the DPA (and the underlying service agreement) if the processor materially breaches the DPA (Section 6.2(a)).

  • Indemnification: The processor may be required to indemnify the controller for losses, damages, and fines arising from the processor's breach (Section 5.2).

Do I need to conduct a Transfer Impact Assessment (TIA) for international data transfers?

Answer: Yes, if you transfer personal data to a country without an adequacy decision using Standard Contractual Clauses (SCCs) or the UK IDTA.

The European Data Protection Board (EDPB) issued guidance (Recommendations 01/2020) requiring controllers and processors to conduct a Transfer Impact Assessment before transferring data using SCCs. The TIA assesses whether the laws and practices of the destination country provide adequate protection for the personal data, taking into account:

  • The nature of the personal data
  • The risks to data subjects
  • The legal framework of the destination country (including government surveillance laws, data access requests, etc.)
  • Supplementary measures (if any) to ensure adequate protection

Example: If you transfer data from the EU to the U.S. using SCCs, you must conduct a TIA to assess whether U.S. surveillance laws (e.g., FISA Section 702, Executive Order 12333) pose a risk to the personal data, and whether you need to implement supplementary measures (e.g., additional encryption, data minimization, etc.).

What is the EU-U.S. Data Privacy Framework, and do I still need SCCs if my processor is certified?

Answer: The EU-U.S. Data Privacy Framework is an adequacy decision adopted by the European Commission in July 2023 that allows transfers of personal data from the EEA to U.S. companies certified under the Framework.

If your processor is certified under the EU-U.S. Data Privacy Framework:

  • You do not need Standard Contractual Clauses (SCCs) for transfers from the EEA to the U.S. The adequacy decision serves as the legal basis for the transfer.
  • You can verify a company's certification at https://www.dataprivacyframework.gov/.

If your processor is not certified:

  • You must use Standard Contractual Clauses (SCCs) or another transfer mechanism (e.g., Binding Corporate Rules) for transfers to the U.S.

Note: The UK has adopted a separate UK Extension to the EU-U.S. Data Privacy Framework for transfers from the UK to U.S. companies. Switzerland has adopted the Swiss-U.S. Data Privacy Framework.

How often should I review and update the DPA?

Answer: You should review and update the DPA:

  • At least annually to ensure it reflects current processing activities and complies with any changes to data protection laws.
  • Whenever processing activities change significantly, such as:
    • New data types are processed
    • New sub-processors are engaged
    • Processing locations change
    • Security measures are updated
    • The processor's business model changes (e.g., the processor starts using AI to analyze customer data)

Best practice: Schedule an annual DPA review with your legal team and processors to ensure all information (especially Annexes 1, 2, and 3) is up to date.

Can I negotiate changes to a processor's standard DPA?

Answer: It depends. Large, established processors (AWS, Google Cloud, Salesforce, etc.) typically offer standard DPAs that are non-negotiable. These DPAs are designed to comply with GDPR and are generally acceptable.

For smaller or custom service providers, you may be able to negotiate certain provisions, such as:

  • Breach notification timeframe (e.g., require 72 hours instead of "without undue delay")
  • Audit rights (e.g., expand audit scope, reduce notice period)
  • Liability caps (e.g., remove liability limitations for data protection violations)
  • Sub-processor approval (e.g., require specific authorization instead of general authorization)

Best practice: Have your legal team review the processor's standard DPA. Negotiate if necessary, but be prepared for large processors to refuse changes.

Do I need a DPA for processors located in the EEA/UK?

Answer: Yes. GDPR Article 28(3) requires a written contract between the controller and processor, regardless of where the processor is located. Even if the processor is in the EEA or UK, you still need a DPA.

However, if the processor is in the EEA or UK, you do not need Standard Contractual Clauses (SCCs) or the UK IDTA, since the transfer is within the EEA/UK.

What should I do if a processor refuses to sign a DPA?

Answer: If a processor refuses to sign a DPA, you have two options:

  1. Find a different processor that will sign a DPA. GDPR Article 28(1) requires controllers to "use only processors providing sufficient guarantees" to implement appropriate technical and organizational measures. A processor that refuses to sign a DPA is not providing sufficient guarantees.

  2. Negotiate with the processor to understand their concerns. Some processors may have legitimate reasons for not signing your specific DPA template (e.g., they have their own standard DPA). In this case, review their DPA to ensure it complies with GDPR Article 28 requirements.

Important: Using a processor without a DPA is a violation of GDPR and can result in fines and enforcement actions by supervisory authorities.

Next Steps

  1. Identify all processors that handle personal data on your behalf (cloud hosting, CRM, email marketing, analytics, payment processing, etc.).
  2. Customize this DPA template for each processor relationship, completing Annexes 1, 2, and 3 with specific details.
  3. Execute Standard Contractual Clauses (Annex 4) if you transfer data to processors outside the EEA.
  4. Execute the UK IDTA (Annex 5) if you transfer data to processors outside the UK.
  5. Conduct Transfer Impact Assessments (TIAs) for international transfers to countries without adequacy decisions.
  6. Have both parties sign the DPA (electronic signatures are acceptable).
  7. Review and update the DPA annually, or whenever processing activities change significantly.
  8. Maintain records of all DPAs and keep them accessible for supervisory authority audits.
  9. Consult legal counsel to ensure the DPA complies with GDPR, UK GDPR, and other applicable data protection laws.

Need help negotiating DPAs with vendors or ensuring GDPR compliance? Contact Promise Legal for personalized guidance.

Related Resources:

This button allows you to scroll to the top or access additional options. Alt + A will toggle accessibility mode.