This Data Processing Agreement (the "DPA") is entered into on {Effective Date} (the "Effective Date") by and between:
Controller: {Controller Name}, with a principal place of business at {Controller Address} (the "Controller").
Processor: {Processor Name}, with a principal place of business at {Processor Address} (the "Processor").
Each, a "Party" and collectively, the "Parties."
This DPA supplements the agreement between the Parties for the provision of services (the "Service Agreement") and governs the Processor's Processing of Personal Data on behalf of the Controller. In the event of a conflict between this DPA and the Service Agreement on matters relating to Personal Data, this DPA prevails.
In consideration of the Parties' obligations under this DPA and the Service Agreement, the Parties agree as follows.
1. Definitions
For purposes of this DPA, the following terms have the meanings given:
- "Controller" means the natural or legal person that, alone or jointly with others, determines the purposes and means of the Processing of Personal Data. In this DPA, the Controller is the Party so identified above.
- "Data Protection Laws" means the EU General Data Protection Regulation (Regulation (EU) 2016/679, "GDPR") and any EU member-state laws implementing or supplementing it, together with any other data protection law that applies to the Processing under this DPA.
- "Data Protection Laws" means the UK General Data Protection Regulation ("UK GDPR") and the UK Data Protection Act 2018, together with any other data protection law that applies to the Processing under this DPA.
- "Data Protection Laws" means the California Consumer Privacy Act as amended by the California Privacy Rights Act ("CCPA/CPRA") and other US state privacy laws that apply to the Processing, together with any other data protection law that applies under this DPA.
- "Data Subject" means the identified or identifiable natural person to whom the Personal Data relates.
- "Personal Data" means any information relating to a Data Subject as defined under Data Protection Laws, including any data processed by the Processor on the Controller's behalf in the course of providing the Service.
- "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 Processed by the Processor.
- "Processor" means the natural or legal person that Processes Personal Data on behalf of the Controller. In this DPA, the Processor is the Party so identified above.
- "Processing" (and "Process") means any operation or set of operations performed on Personal Data, including collection, recording, organization, structuring, storage, adaptation, retrieval, consultation, use, disclosure, transmission, dissemination, restriction, erasure, or destruction.
- "Service" means the services provided by the Processor to the Controller under the Service Agreement.
- "Sub-Processor" means any third party engaged by the Processor (or by a Sub-Processor) to Process Personal Data on behalf of the Controller.
- "Standard Contractual Clauses" or "SCCs" means the standard contractual clauses for the transfer of Personal Data to processors established in third countries, adopted by the European Commission, as updated from time to time.
Terms used in this DPA but not defined here have the meanings given in the applicable Data Protection Laws.
About this section
What's in this section
The Controller/Processor split defined here decides who answers to the regulator and who carries the liability. Mislabel the roles and every obligation downstream attaches to the wrong party.
Why this section is here
Every clause that follows is written in terms of 'Personal Data,' 'Processing,' and the two roles. If those anchors drift from their statutory meaning, the obligations built on them turn arguable at the worst possible time: mid-incident or mid-audit.
Common mistake
Defining terms differently from how they appear in the GDPR, UK GDPR, or applicable law. The DPA should adopt the statutory definitions or explicitly reference them, not redefine them.
2. Scope, Roles, and Processing Instructions
Roles. In relation to Personal Data Processed under this DPA, the Controller is the data controller and the Processor is the data processor.
Under the CCPA (as amended by the CPRA) and analogous US state laws, the Controller is the "business" and the Processor is the "service provider."
Subject matter, nature, and purpose. The subject matter of the Processing is {Subject Matter}. The nature of the Processing is {Nature of Processing}. The purpose of the Processing is {Purpose of Processing}. The duration of the Processing is {Duration of Processing}.
Categories of Personal Data and Data Subjects. The categories of Personal Data Processed under this DPA are {Categories of Personal Data}. The categories of Data Subjects are {Categories of Data Subjects}.
Documented instructions. The Processor shall Process Personal Data only on the documented instructions of the Controller, including with regard to transfers of Personal Data to a third country, unless required to do otherwise by applicable law. The Service Agreement, this DPA, and any subsequent written instructions provided by the Controller to the Processor constitute the documented instructions for purposes of this Section. The Processor shall notify the Controller of any legal requirement that, in the Processor's view, conflicts with the Controller's instructions before complying with that requirement, unless that law prohibits such notification on important grounds of public interest. The Processor shall also promptly inform the Controller if, in the Processor's opinion, an instruction infringes applicable Data Protection Laws, unless prohibited from doing so by applicable law.
About this section
What's in this section
The 'only on documented instructions' rule is what keeps a Processor a Processor. The moment it starts deciding its own purposes for the data, it becomes a Controller in the regulator's eyes and inherits the full liability that comes with that.
Why this section is here
GDPR won't accept a handshake that the Processor will 'only do what it's told'; Article 28(3) makes the Parties write the instructions down as specific particulars. That written scope is what a regulator checks to see whether the Controller really defined the boundary or just assumed one.
Common mistake
Leaving processing details vague. 'Such personal data as the Controller may provide' is not sufficient; regulators expect specific categories and purposes.
What GDPR Article 28 requires →3. Processor's General Obligations
Security measures. The Processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk of the Processing, as required by applicable Data Protection Laws. Examples of measures the Processor may maintain, as applicable to the Service, include encryption of Personal Data in transit and at rest, role-based access controls, multi-factor authentication for administrative access, security awareness training for personnel, vendor due diligence, and documented incident response procedures.
Confidentiality of personnel. The Processor shall ensure that all personnel authorized to Process Personal Data are bound by appropriate obligations of confidentiality, whether contractual or statutory, and have received training on their obligations under Data Protection Laws and this DPA.
Restricted access. The Processor shall restrict access to Personal Data to personnel who require access to perform the Service and only to the extent reasonably necessary for the Processing's purpose.
Updates to legal landscape. The Processor shall notify the Controller of any change in applicable Data Protection Laws that materially affects the Processor's ability to perform the Service in compliance with this DPA.
About this section
What's in this section
This is the clause the Controller leans on to show its own regulator that it vetted an adequate Processor. The more concrete the duties, the more the Controller can demonstrate; a vague version protects no one.
Why this section is here
A security promise is only worth what you can enforce. Spelling the duties out as specifics is what turns 'we take security seriously' into something the Controller can hold the Processor to when an incident exposes whether the words were real.
Common mistake
Promising 'industry-standard security' without specifying what the Processor actually does. Regulators and customers expect concrete measures (encryption, access controls, vendor due diligence, incident response procedures).
4. Sub-Processors
General authorization. The Controller authorizes the Processor to engage Sub-Processors to assist in providing the Service, subject to the terms of this Section. A current list of Sub-Processors is maintained by the Processor and made available to the Controller upon request.
Notification and right to object. The Processor shall provide the Controller with at least twenty (20) days' prior written notice before engaging a new Sub-Processor. The Controller may object to the addition of a new Sub-Processor on reasonable grounds related to data protection, in which case the Parties will work in good faith to resolve the objection. If the objection cannot be resolved, the Controller may terminate the affected portion of the Service Agreement on written notice.
Flow-down obligations. The Processor shall impose on each Sub-Processor data protection obligations that are at least as protective as those imposed on the Processor under this DPA, and shall remain fully liable to the Controller for the performance of each Sub-Processor's obligations.
Current Sub-Processors. (Replace with your actual sub-processor list, or maintain the list separately and reference its location here.)
As of the Effective Date, the Processor engages the following Sub-Processors:
- (Sub-Processor name): (service provided, location of processing)
- (Sub-Processor name): (service provided, location of processing)
- (Sub-Processor name): (service provided, location of processing)
About this section
What's in this section
No modern Processor runs without sub-processors: the cloud host, the email API, the support tool all touch the data. This clause is where the Controller decides how much say it keeps over that hidden second layer of vendors.
Why this section is here
If a sub-processor leaks data, GDPR treats it as the Processor's own failure (Art. 28(4)) and the Controller's failure for permitting it. This clause is what pushes protective terms all the way down the chain instead of stopping at the first vendor.
Common mistake
Granting blanket sub-processor authorization without a notification mechanism. The Controller needs a reasonable opportunity to object to new sub-processors that change the risk profile.
5. Assistance to the Controller
Data Subject rights. Taking into account the nature of the Processing, the Processor shall assist the Controller, by appropriate technical and organizational measures, in responding to requests from Data Subjects to exercise their rights under Data Protection Laws, including rights of access, rectification, erasure, restriction, portability, and objection. If the Processor receives a direct request from a Data Subject relating to Personal Data Processed under this DPA, the Processor shall promptly notify the Controller and shall not respond except on the Controller's documented instructions or as required by applicable law.
DPIAs and prior consultation. The Processor shall provide reasonable assistance to the Controller in conducting data protection impact assessments and in any prior consultation with supervisory authorities, where required by applicable Data Protection Laws, taking into account the nature of the Processing and the information available to the Processor.
Scope of assistance. The Processor shall provide reasonable assistance under this Section without charge for routine requests. For requests that materially exceed routine assistance, the Processor may charge reasonable fees agreed in advance, provided that the Processor shall not refuse assistance solely on the basis of cost where the Controller has a legal obligation to respond.
About this section
What's in this section
Data subjects send their access and deletion requests to whoever holds the data, which is usually the Processor, even though the legal duty to answer sits with the Controller. This clause is the bridge that lets the Controller fulfil a request it can't physically perform on its own.
Why this section is here
The duty runs wider than data subject requests: Articles 28(3)(e) and (f) also pull the Processor into the Controller's impact assessments and regulator consultations, because only the Processor knows how the processing actually works under the hood.
Common mistake
Treating assistance as optional or chargeable without limits. Reasonable assistance must be available; what 'reasonable' means in cost and time should be defined upfront.
6. Personal Data Breach Notification
Notification to Controller. The Processor shall notify the Controller without undue delay, and in any event within {Breach Notification Timeline} of becoming aware of a Personal Data Breach affecting Personal Data Processed under this DPA.
Information provided. The Processor's notification shall include, to the extent known and reasonably available at the time of notification: (a) a description of the nature of the Personal Data Breach, including the categories and approximate number of Data Subjects and Personal Data records concerned; (b) the likely consequences of the Personal Data Breach; (c) the measures taken or proposed to address the Personal Data Breach and mitigate its possible adverse effects; and (d) the name and contact details of the Processor's data protection officer or other contact point.
Updates. Where the full information is not available at the time of notification, the Processor shall provide updates as additional information becomes available and shall cooperate with the Controller in the Controller's investigation and response.
Controller's obligations. The Controller is responsible for notifying supervisory authorities and Data Subjects as required by Data Protection Laws. The Processor shall provide reasonable assistance to the Controller in meeting these obligations.
About this section
What's in this section
The Controller's 72-hour clock to the regulator effectively starts when the Processor discovers a breach, not when the Controller hears about it. Every hour the Processor takes to report is an hour off the Controller's own deadline, which is why this timeline is the most negotiated number in the DPA.
Why this section is here
Speed is only half of it; the Processor's notice also has to carry enough detail (what data, whose, how much) for the Controller to brief the regulator and the affected users. A fast but empty 'we had an incident' message doesn't discharge the obligation.
Common mistake
Letting the Processor decide whether a breach is 'serious enough' to report. That judgment is the Controller's to make; the Processor's job is to surface every incident promptly and let the Controller assess severity.
7. International Transfers
General principle. Personal Data shall not be transferred outside the European Economic Area (an "International Transfer") unless an appropriate safeguard under the GDPR applies.
Adequacy. Where the European Commission has recognized the destination country as providing an adequate level of protection, the transfer is permitted without additional safeguards.
Standard Contractual Clauses. Where no adequacy decision applies, the Parties incorporate by reference the Standard Contractual Clauses (Module 2: Controller to Processor, or Module 3: Processor to Processor, as applicable) approved by European Commission Implementing Decision (EU) 2021/914 as the safeguard for International Transfers from the EEA. (When relying on the SCCs for an actual transfer, attach or reference the populated annexes at deployment: (1) parties and transfer description, (2) technical and organizational measures, and (3) sub-processors. Current text: https://eur-lex.europa.eu/eli/dec_impl/2021/914.)
Transfer Impact Assessment. Consistent with the Schrems II framework, the Parties acknowledge that the SCCs alone may not suffice where the destination country's legal regime materially affects protection, and shall cooperate on a Transfer Impact Assessment and any supplementary measures (such as encryption) needed to ensure an essentially equivalent level of protection.
Copies on request. The Controller may request a copy of the relevant SCCs or other transfer safeguards by contacting the Processor at {Processor Contact}.
General principle. Personal Data shall not be transferred outside the United Kingdom (an "International Transfer") unless an appropriate safeguard under the UK GDPR applies.
Adequacy. Where the UK Government has made adequacy regulations for the destination country, the transfer is permitted without additional safeguards.
UK transfer mechanism. Where no adequacy regulations apply, the Parties incorporate by reference the UK International Data Transfer Agreement (IDTA), or the UK Addendum to the EU SCCs where the EU SCCs are also used, as the safeguard for International Transfers from the United Kingdom, and shall complete the IDTA tables or Addendum at deployment.
Transfer risk assessment. The Parties shall cooperate on a transfer risk assessment and any supplementary measures needed to ensure transferred Personal Data receives protection essentially equivalent to that under the UK GDPR.
Copies on request. The Controller may request a copy of the relevant transfer safeguards by contacting the Processor at {Processor Contact}.
Location of Processing. The Processor Processes Personal Data in the United States and in other locations where it or its Sub-Processors operate. US law does not generally restrict cross-border transfers of Personal Data.
Foreign-law data. Where the Processor receives Personal Data subject to the laws of the European Economic Area, the United Kingdom, or Switzerland, the international-transfer safeguards those laws require (such as the EU Standard Contractual Clauses or the UK IDTA) apply to that data, and the Parties will put them in place before the transfer.
Copies on request. The Controller may request a copy of any applicable transfer safeguards by contacting the Processor at {Processor Contact}.
About this section
What's in this section
Most SaaS triggers this clause without realizing it: the moment data lands on a US-hosted server or a US support agent opens a ticket, a cross-border transfer has happened and needs a lawful basis.
Why this section is here
Under Chapter V a transfer with no valid mechanism isn't a paperwork gap; the transfer itself is unlawful, and every day of processing that follows compounds it. The clause is what gives the data a lawful route out of the EEA in the first place.
Common mistake
Naming a transfer mechanism the Parties don't actually use. If the DPA says BCRs apply but the Processor doesn't have approved BCRs, the transfer is unlawful regardless of the contract text.
UK transfers and the IDTA →8. Audit Rights and Compliance
Information on request. The Processor shall make available to the Controller all information reasonably necessary to demonstrate the Processor's compliance with this DPA and Data Protection Laws.
Third-party audit reports. The Controller's audit rights under this Section are primarily satisfied by the Processor's third-party audit reports (such as SOC 2 Type II, ISO 27001, or equivalent independent assessments). The Processor shall provide such reports to the Controller upon written request, subject to reasonable confidentiality obligations.
On-site audits. The Controller (or an independent auditor mandated by the Controller and reasonably acceptable to the Processor) may conduct an on-site audit of the Processor's compliance with this DPA where (a) the Processor's third-party audit reports do not adequately address a documented compliance concern raised by the Controller, (b) on-site audit is required by a Data Protection Law or supervisory authority to which the Controller is subject, or (c) following a Personal Data Breach affecting the Controller's Personal Data. On-site audits are subject to at least thirty (30) days' prior written notice (except in the case of (c)), reasonable confidentiality obligations, and shall not unreasonably interfere with the Processor's business operations or the privacy of other customers' data.
Cooperation. The Processor shall cooperate in good faith with the Controller's audits and shall remedy any non-compliance identified by the audit within a reasonable time.
About this section
What's in this section
On paper the Controller holds a sweeping right to inspect; granting that literally to every customer would grind a Processor's operations to a halt. This clause is where that tension gets settled, and it's rarely settled the same way twice.
Why this section is here
A Controller can't take the Processor's compliance on faith; it has to be able to check. This clause is the verification mechanism, the line between a Controller that can show diligence and one that merely hoped its vendor was telling the truth.
Common mistake
Either granting unlimited audit rights (impractical for a Processor with many customers) or denying audits entirely (non-compliant). The standard compromise is third-party reports plus limited on-site rights triggered by specific cause.
9. Return or Deletion of Personal Data
On termination. Upon termination or expiry of the Service Agreement, or at the Controller's earlier written request, the Processor shall, at the Controller's election: (a) return all Personal Data to the Controller in a structured, commonly used, and machine-readable format; or (b) delete all Personal Data, except where retention is required by applicable law. Personal Data residing in backup systems shall be securely isolated from further Processing and deleted in accordance with the Processor's normal backup retention cycle, unless earlier deletion is technically feasible.
Legal retention. Where the Processor is required by applicable law to retain Personal Data after termination (for example, for tax, accounting, anti-money-laundering, or litigation-hold purposes), the Processor shall continue to apply the protections of this DPA to the retained data for as long as it is retained and shall delete it when the legal retention requirement ends.
Certification. Upon completion of return or deletion, the Processor shall provide written certification to the Controller that the Personal Data has been returned or deleted in accordance with this Section.
About this section
What's in this section
The clause that proves the relationship actually ended. Without it, data lingers in the Processor's systems and backups long after the contract is over, and live data with no governing agreement is exposure for both Parties at once.
Why this section is here
This is the Controller's off-boarding lever: it decides whether the data comes back or is destroyed, and gets it in a usable form. Skip it and the Controller loses control of its own data at the exact moment it's walking away.
Common mistake
Failing to address legal retention obligations. Tax records, AML logs, and similar regulatory data must be retained even after termination; the DPA should acknowledge this exception.
10. Liability and Indemnity
Limitation of liability. Each Party's liability arising out of or in connection with this DPA is subject to the limitations of liability set out in the Service Agreement, including any aggregate cap, exclusions of liability, and limitations on types of damages, except to the extent that such limitations are prohibited by applicable Data Protection Laws.
Liability cap. Without prejudice to the foregoing, each Party's aggregate liability under this DPA shall not exceed the fees paid or payable by the Controller to the Processor under the Service Agreement during the twelve (12) months preceding the event giving rise to the claim.
Indemnification. The Processor shall indemnify the Controller against any losses, damages, fines, or expenses (including reasonable legal fees) incurred by the Controller as a direct result of (a) the Processor's willful misconduct or gross negligence in performing this DPA, or (b) the Processor's failure to comply with the Processor-specific obligations under Data Protection Laws. For ordinary breaches of this DPA, the limitations of liability set out in the Service Agreement apply.
Mutual indemnification. The Controller shall indemnify the Processor against any losses, damages, fines, or expenses (including reasonable legal fees) incurred by the Processor as a result of the Controller's material breach of this DPA, the Controller's willful misconduct, or the Controller's failure to provide lawful and complete instructions for the Processing.
Statutory liability preserved. Nothing in this Section affects the direct liability of either Party to Data Subjects, supervisory authorities, or other third parties under Data Protection Laws.
About this section
What's in this section
Under GDPR Article 82 a data subject can pursue either Party for the full amount and let that Party chase the other for its share. This clause decides who ultimately pays, which is why it's the most heavily negotiated provision in the document.
Why this section is here
A cap here can't limit what a data subject recovers from either Party; liability to the individual under GDPR can't be contracted away. What it does limit is what the Parties can claim back from each other, which is the only piece actually within their control.
Common mistake
Negotiating liability without considering the underlying Service Agreement's liability cap. Inconsistent caps between the DPA and the main contract create interpretive disputes.
11. Term and Termination
Term. This DPA takes effect on the Effective Date and remains in force for so long as the Processor Processes Personal Data on behalf of the Controller under the Service Agreement.
Termination for material breach. Either Party may terminate this DPA (and, at its election, the affected portion of the Service Agreement) on thirty (30) days' written notice for a material breach by the other Party that is not cured within the notice period.
Termination for unauthorized processing. The Controller may terminate this DPA and the affected portion of the Service Agreement immediately on written notice if the Processor engages in Processing that is materially inconsistent with this DPA or applicable Data Protection Laws and the Processor fails to cure within ten (10) business days of written notice.
Survival. Sections 9 (Return or Deletion), 10 (Liability and Indemnity), and 12 (Governing Law) survive termination or expiry of this DPA.
About this section
What's in this section
Without independent termination rights, a Controller that catches its Processor mishandling data has only one exit: breach the commercial contract and absorb the fallout. This clause gives it a clean way to walk when data protection specifically breaks down.
Why this section is here
Data-protection duties outlive the commercial deal; they run until the data is returned or deleted. This clause keeps the DPA in force exactly as long as the Processor still holds Personal Data, so obligations don't lapse while the data is still live.
Common mistake
Forgetting to address what happens to Personal Data on termination (covered in Section 9) or how the DPA interacts with the Service Agreement's termination provisions.
12. Governing Law, Jurisdiction, and Miscellaneous
Governing law. This DPA is governed by and construed in accordance with the laws of {Governing Law}, without giving effect to any conflict-of-laws principles. The Parties consent to the exclusive jurisdiction and venue of the courts located in {Jurisdiction} for any dispute arising out of or relating to this DPA.
Order of precedence. In the event of a conflict between this DPA and the Service Agreement on matters relating to the Processing of Personal Data, this DPA prevails. In all other respects, the terms of the Service Agreement remain in effect.
Entire agreement. This DPA, together with the Service Agreement, constitutes the entire agreement between the Parties with respect to the subject matter and supersedes all prior agreements, representations, or understandings, whether oral or written, on the same subject.
Amendment. Any amendment to this DPA must be in writing and signed (or accepted via clickwrap) by both Parties.
Severability. If any provision of this DPA is held invalid or unenforceable, the remaining provisions shall continue in full force and effect.
No partnership. Nothing in this DPA creates a partnership, joint venture, agency, fiduciary, or employment relationship between the Parties. Neither Party has authority to bind the other.
Counterparts. This DPA may be executed in counterparts, each of which is deemed an original and all of which together constitute one and the same instrument. Counterparts may be executed electronically; an electronic signature has the same legal effect as a handwritten signature.
Notices. Notices required under this DPA shall be sent to the Controller at {Controller Contact} and to the Processor at {Processor Contact}, or to such other contact as either Party may designate in writing. The DPO's contact (if applicable) is {DPO Contact}.
U.S. State Privacy Provisions
Where the Processing of Personal Data under this DPA includes data of residents of California or another US state with a comprehensive privacy law, the Processor acts as a "service provider," "processor," or analogous role under the applicable state law and the following provisions apply:
(a) The Processor shall not sell or share Personal Data (as those terms are defined under CCPA/CPRA and analogous state laws) under any circumstances;
(b) The Processor shall not retain, use, or disclose Personal Data for any purpose other than the specific purposes set out in this DPA, including any commercial purpose other than performing the Service or otherwise as permitted under applicable state law;
(c) The Processor shall not combine Personal Data received from the Controller with Personal Data received from or on behalf of any other person, except as permitted under applicable state law;
(d) The Processor shall comply with any obligations applicable to a service provider, processor, or contractor under applicable state law, including providing the same level of privacy protection as required of the Controller;
(e) The Processor shall notify the Controller if it determines that it can no longer meet its obligations under applicable state law, and the Controller shall have the right to take reasonable and appropriate steps to stop and remediate unauthorized use of Personal Data; and
(f) The Processor certifies that it understands the restrictions in this Section and will comply with them, as required of a service provider or contractor under the CCPA (as amended by the CPRA) and its implementing regulations.
About this section
What's in this section
The sleeper clause here is order of precedence. When the DPA and the commercial agreement disagree on a data-protection point, this decides which wins; leave it silent and the weaker commercial term can quietly override the protections you drafted.
Why this section is here
The governing law picked here sets the rules of interpretation for every other clause. A mature data-protection jurisdiction gives both sides predictable answers; an unfamiliar one means litigating questions no local court has settled.
Common mistake
Picking a governing law unrelated to the Parties' actual data flows. Where Personal Data is processed across multiple jurisdictions, choose a law connected to one of those jurisdictions.
Acceptance
(This acceptance clause assumes the Processor's platform actually captures Controller identity or account, timestamp, network address, the DPA version presented, the affirmative acceptance action, and a copy of the exact accepted terms. Verify your implementation captures these elements before relying on this clause. For ClickTerm-powered acceptance flows, this happens automatically.)
The Controller agrees to the terms of this DPA by clicking "I Agree" (or taking a substantially similar affirmative acceptance action) at the time this DPA is presented in the onboarding or access flow.
By accepting this DPA, the individual confirms that they have authority to bind the Controller as the relevant signatory under applicable law and that the Controller's acceptance is made knowingly and voluntarily.
The acceptance is captured and timestamped by the Processor, and the record of acceptance, including the version of this DPA presented, the time of acceptance, the network address of the device used, and the identity of the accepting individual, constitutes evidence of the Controller's agreement to be bound by this DPA.
Signatures
The Parties have executed this DPA as of the Effective Date.
Controller: {Controller Name}
By: _______________________________ Name: _____________________________ Title: _____________________________ Date: _____________________________
Processor: {Processor Name}
By: _______________________________ Name: _____________________________ Title: _____________________________ Date: _____________________________
About this section
What's in this section
For self-service SaaS, this is how you put one standardized DPA in front of every business customer and bind them all without a signature page or a per-deal negotiation for each one.
Why this section is here
Electronic acceptance is legally equivalent to a wet signature for commercial DPAs, so binding force isn't the question; evidence is. Under the GDPR's accountability principle (Art. 5(2)), the Controller must be able to demonstrate it bound the Processor, and a clean acceptance record is that proof.
Common mistake
Accepting a DPA without checking that the person clicking can actually bind the Controller. A junior employee's click does not commit their company; capture evidence of the accepter's authority, not just their identity.
Why e-signatures are binding →