Free Word download • Edit online • Save & share with Drive • Export to PDF
A Data Protection Agreement (DPA) is a legally binding contract between a data controller — the organization that determines why and how personal data is processed — and a data processor — the vendor, platform, or service provider that handles that personal data solely on the controller's instructions. It establishes the permitted scope of processing, the security standards the processor must maintain, how sub-processors are governed, what happens when a data breach occurs, and how personal data is handled when the relationship ends. Unlike a general confidentiality agreement, a DPA specifically addresses personal data belonging to identifiable individuals — customers, employees, website visitors — and is required by GDPR Article 28 and equivalent privacy laws in the UK, Canada, and a growing number of US states before any data transfer to a processor takes place.
Operating without a signed DPA is not a compliance gap that can be remedied after the fact — processing personal data without one is a direct violation under GDPR, exposing the controller to fines of up to €10 million or 2% of global annual turnover, whichever is higher. Beyond regulatory penalties, the absence of a DPA leaves you with no contractual basis to compel a vendor to notify you of a breach, delete your data at contract end, or restrict sub-processor onboarding. Enterprise customers and regulated industry buyers routinely require a signed DPA before they will onboard a new vendor — making execution a commercial prerequisite as well as a legal one. Every payroll platform, CRM tool, cloud host, email marketing service, and analytics provider your business uses almost certainly processes personal data on your behalf; each one needs a DPA. This template gives you a structured, compliance-ready starting point that covers all ten mandatory GDPR Article 28 elements, works across US state privacy law frameworks, and can be adapted for UK and EU cross-border transfer mechanisms — saving you the cost of drafting from scratch for every new vendor relationship.
| If your situation is… | Use this template |
|---|---|
| Vendor processes personal data strictly on your instructions with no independent purpose | Data Processing Agreement (Controller to Processor) |
| Two businesses jointly determine the purposes of processing the same personal data | Joint Controller Agreement |
| Transferring personal data from the EU or UK to a third country without an adequacy decision | Standard Contractual Clauses (SCCs) Addendum |
| US health data shared with a vendor under HIPAA requirements | Business Associate Agreement (BAA) |
| Employee personal data shared with a parent or affiliated company | Intra-Group Data Transfer Agreement |
| Consumer data rights and opt-out procedures required under CCPA or state privacy laws | Privacy Policy |
| General confidentiality covering non-personal business information shared with a vendor | Non-Disclosure Agreement |
Why it matters: GDPR Article 28 requires a binding agreement to be in place before processing begins. Processing personal data without a DPA is a direct violation that can result in regulatory fines up to €10M or 2% of global annual turnover.
Fix: Make DPA execution a hard gate in your vendor onboarding checklist — no data flows to a new processor until the signed DPA is on file.
Why it matters: A DPA without a completed data-processing schedule is unenforceable and fails to satisfy the mandatory content requirements of GDPR Article 28(3). Regulators routinely cite missing schedules in enforcement actions.
Fix: Treat Schedule 1 as mandatory — list every category of personal data, every data subject category, the specific processing purpose, and the maximum retention period before execution.
Why it matters: Undefined security standards cannot be audited or enforced. If a breach occurs and the DPA contains only vague security language, the processor bears no clear contractual obligation and the controller has no basis for a claim.
Fix: Attach a specific security schedule listing concrete controls — AES-256 encryption, multi-factor authentication, annual penetration testing — or reference an attached SOC 2 or ISO 27001 report.
Why it matters: Without notification obligations, processors can add new sub-processors — including in high-risk jurisdictions — without the controller's knowledge, creating undisclosed cross-border transfers and supply-chain liability.
Fix: Require written notice at least 30 days before adding any new sub-processor, and give the controller a documented right to object within that window.
Why it matters: The 72-hour GDPR deadline runs from the controller to the supervisory authority. If the processor also has 72 hours to notify the controller, the controller has zero buffer to investigate before its own regulatory deadline expires.
Fix: Set the processor's notification obligation at 24 to 48 hours, giving the controller sufficient time to assess the incident and decide whether and how to notify the regulator.
Why it matters: Without an express deletion clause, processors retain personal data indefinitely after the relationship ends — violating the data minimization and storage limitation principles under GDPR and most modern privacy laws.
Fix: Include a clause requiring the processor to return or securely delete all personal data within 30 days of termination and to provide written certification of deletion.
In plain language: Establishes the meaning of key terms — personal data, processing, controller, processor, sub-processor — and identifies exactly which data flows and processing activities the agreement governs.
In this Agreement, 'Personal Data', 'Controller', 'Processor', 'Processing', and 'Data Subject' have the meanings given in [APPLICABLE LAW / GDPR Article 4]. This Agreement applies to all Processing of Personal Data carried out by [PROCESSOR NAME] on behalf of [CONTROLLER NAME] as described in Schedule 1.
Common mistake: Leaving the scope vague by not attaching a Schedule 1 that lists the specific categories of data, data subjects, and processing operations. Without it, the agreement is unenforceable in practice and fails GDPR Article 28(3) requirements.
In plain language: States that the processor may only process personal data on the documented, written instructions of the controller and must alert the controller if an instruction would breach applicable law.
Processor shall Process Personal Data only on the documented instructions of Controller as set out in Schedule 1 or as otherwise agreed in writing. Processor shall immediately inform Controller if, in its opinion, an instruction infringes [GDPR / APPLICABLE LAW].
Common mistake: Allowing the processor to process data for its own business purposes, product improvement, or marketing under a carve-out in the instructions clause. This converts the processor into a joint controller and invalidates the DPA structure.
In plain language: Requires the processor to ensure that only authorized personnel with a need to know can access personal data, and that those individuals are bound by confidentiality.
Processor shall ensure that persons authorized to Process the Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality, and that access is limited to those who need it to perform the services.
Common mistake: Failing to require written confidentiality commitments from individual employees or contractors. Verbal undertakings are difficult to demonstrate during a regulatory audit or after a breach.
In plain language: Requires the processor to implement appropriate technical and organizational measures to protect personal data against unauthorized access, loss, or destruction — proportionate to the risk.
Processor shall implement and maintain the technical and organizational security measures set out in Schedule 2, including at minimum: [encryption at rest and in transit / access controls / regular penetration testing / incident response procedures].
Common mistake: Describing security measures in vague terms like 'industry-standard security' without specifying concrete controls. Vague language provides no baseline to assess compliance and is routinely rejected by enterprise procurement teams.
In plain language: Defines whether the processor may engage sub-processors, what approval process is required, and that the processor remains fully liable for the sub-processor's compliance.
Processor shall not engage any sub-processor without Controller's prior specific or general written authorization. Where general authorization is granted, Processor shall maintain a list of approved sub-processors (Schedule 3) and notify Controller of any changes at least [30] days in advance, giving Controller the opportunity to object.
Common mistake: Granting blanket sub-processor authorization with no notification requirement. Controllers lose visibility into their data supply chain and cannot exercise meaningful oversight — a direct GDPR violation.
In plain language: Obligates the processor to assist the controller in responding to data subject requests — access, deletion, portability, correction — within the timeframes required by law.
Processor shall, taking into account the nature of the Processing, assist Controller by appropriate technical and organizational measures to fulfill Controller's obligations to respond to requests for exercising Data Subject rights under [APPLICABLE LAW], within [5] business days of receiving a request.
Common mistake: Omitting a concrete response timeline. Without one, processors delay or deprioritize data subject requests, causing controllers to breach their statutory deadlines — typically 30 days under GDPR and most US state privacy laws.
In plain language: Requires the processor to notify the controller of any personal data breach within a defined timeframe — typically 24 to 72 hours — including the nature, scope, and preliminary remediation steps.
Processor shall notify Controller of any Personal Data Breach without undue delay and in any event within [48] hours of becoming aware, providing at minimum: the nature of the breach, categories and approximate number of data subjects affected, likely consequences, and measures taken or proposed.
Common mistake: Setting a 72-hour breach notification window that mirrors the GDPR supervisory-authority deadline. The processor's notice to the controller must come early enough for the controller to investigate and still meet its own regulatory reporting obligation — 24 to 48 hours is the appropriate processor standard.
In plain language: Governs any transfer of personal data outside the EEA, UK, or other restricted jurisdiction — specifying the lawful transfer mechanism used, such as Standard Contractual Clauses or adequacy decisions.
Processor shall not transfer Personal Data to any country outside [EEA / UK] without Controller's prior written consent and implementation of an appropriate safeguard, including but not limited to: (a) an adequacy decision; (b) Standard Contractual Clauses in the form approved by [European Commission / ICO]; or (c) binding corporate rules.
Common mistake: Referencing Standard Contractual Clauses without specifying which version or module applies. The EU replaced the 2010 SCCs with new modular SCCs in 2021 — using the old version does not provide a valid transfer mechanism.
In plain language: Grants the controller the right to audit the processor's compliance with the DPA, either directly or through a third-party auditor, on reasonable notice.
Processor shall make available to Controller all information necessary to demonstrate compliance with this Agreement and shall allow for and contribute to audits, including inspections, conducted by Controller or a third-party auditor mandated by Controller, on [30] days' prior written notice.
Common mistake: Allowing audits only on 60 or 90 days' notice with no provision for urgent access following a breach or regulatory inquiry. In a post-incident scenario, 90-day notice renders the audit right meaningless.
In plain language: States what happens to personal data when the agreement ends — the processor must return all data to the controller or securely delete it, and certify that deletion has occurred.
Upon termination or expiry of this Agreement, Processor shall, at Controller's election, return all Personal Data to Controller or securely delete all copies, within [30] days of termination, and certify in writing that deletion has been completed, unless applicable law requires continued storage.
Common mistake: No deletion certification requirement. Processors retain data indefinitely 'just in case' without a formal obligation to delete — exposing the controller to ongoing liability under data minimization principles.
Confirm which party determines the purpose of processing (controller) and which party acts only on instructions (processor). Insert the full legal entity names, registered addresses, and contact details for both parties.
💡 If both parties independently determine why data is processed — not just how — they are joint controllers, not controller and processor. A DPA is the wrong instrument in that case; use a joint controller agreement instead.
List the specific categories of personal data (e.g., names, email addresses, payment data), the categories of data subjects (e.g., customers, employees), the purpose of processing, and the retention period. This schedule is the operational core of the agreement.
💡 Be as specific as possible. 'Customer data' is not a category — 'customer name, email address, purchase history, and IP address' is. Regulators and enterprise procurement teams reject vague schedules.
List the technical and organizational security controls the processor has in place: encryption standards, access control policies, penetration testing frequency, backup procedures, and incident response contacts.
💡 Request the processor's most recent SOC 2 Type II report or ISO 27001 certificate and attach it as an exhibit to Schedule 2 rather than redrafting controls from scratch.
Choose between specific authorization (you approve each sub-processor individually) or general authorization (processor maintains a list and gives advance notice of changes). Insert the notice period — 30 days is standard — and attach the current sub-processor list as Schedule 3.
💡 General authorization with a 30-day objection window is the commercially standard approach. Specific authorization is appropriate only for high-risk or highly sensitive data.
Enter the number of hours within which the processor must notify the controller of a personal data breach. Insert 24 or 48 hours — not 72 — to give the controller time to investigate before the regulatory clock runs.
💡 Include the notification contact details — a named privacy officer or a dedicated security-incident email — directly in the clause, not just in a side letter.
If the processor is located outside the EEA, UK, or another restricted jurisdiction, select the appropriate transfer mechanism — EU SCCs (2021 modular version), UK International Data Transfer Agreement (IDTA), or adequacy decision — and attach the relevant addendum.
💡 For US-based processors handling EU or UK data, the EU–US Data Privacy Framework provides adequacy for certified companies. Verify certification at dataprivacyframework.gov before relying on it.
Specify the governing law and jurisdiction for disputes. Both parties must sign before any personal data is transferred. Add the effective date and confirm that signatures are captured in writing or via a compliant electronic signature platform.
💡 A DPA signed after data has already been transferred does not retroactively cure the unlawful processing period — execute it before onboarding the vendor or activating the service.
A data protection agreement (DPA) is a legally binding contract between a data controller — the business that decides why personal data is processed — and a data processor — a vendor or service provider that handles that data on the controller's behalf. It defines the permitted processing activities, security requirements, sub-processor rules, breach notification timelines, and what happens to the data when the relationship ends. GDPR Article 28 and equivalent laws in the UK, Canada, and several US states require a written DPA before any processing begins.
A DPA is typically required whenever a business shares personal data with a third-party vendor that processes it on the business's instructions — including cloud hosting providers, payroll platforms, CRM tools, email marketing services, HR software, analytics platforms, and IT managed-service providers. Under GDPR, the obligation applies to any controller established in the EU or processing data of EU residents, regardless of where the processor is located. Many US state privacy laws — including California, Virginia, and Colorado — impose similar requirements.
A privacy policy is a public-facing notice to individuals — customers, users, or employees — explaining how a business collects, uses, and shares their personal data. A DPA is a private, binding contract between two businesses governing how a processor handles personal data on the controller's instructions. A privacy policy does not substitute for a DPA, and a DPA does not replace the obligation to publish a privacy policy. Both are required for GDPR compliance.
Yes. GDPR Article 28 requires a binding DPA to be in place before processing begins. Processing personal data without an executed DPA is a direct violation that can result in fines up to €10 million or 2% of global annual turnover, whichever is higher. In practice, enterprise customers and regulated industries require a signed DPA as a precondition to onboarding a new vendor, making execution a commercial necessity as well as a legal one.
GDPR Article 28(3) requires a DPA to cover: the subject matter, duration, nature, and purpose of the processing; the type of personal data and categories of data subjects; the controller's obligations and rights; the processor's obligation to act only on documented instructions; confidentiality commitments; appropriate security measures; sub-processor rules; assistance with data subject rights; assistance with security and breach notification obligations; deletion or return of data at contract end; and audit cooperation. A DPA missing any of these elements does not satisfy the GDPR requirement.
It can, provided it covers all the mandatory elements of GDPR Article 28(3) and the specific processing details — data categories, purposes, retention periods — reflect what actually happens. In practice, many vendor DPAs use generic language that does not accurately describe the processing or contains overly broad data-use rights that convert the processor into a joint controller. Always review a vendor's standard DPA against your actual data flows before signing, and negotiate changes where the standard terms do not reflect the true processing relationship.
A sub-processor is a third party engaged by the processor to perform specific processing activities on behalf of the controller — for example, a cloud infrastructure provider used by a SaaS platform. Under GDPR, the controller must authorize the use of sub-processors, either specifically (approving each one) or generally (approving a list with advance notice of changes). The processor remains fully liable for the sub-processor's compliance with the DPA, and the DPA must impose the same data protection obligations on the sub-processor as those imposed on the processor.
When a processor is located outside the EEA or UK, the DPA must specify the lawful transfer mechanism — typically EU Standard Contractual Clauses (2021 modular version), the UK International Data Transfer Agreement (IDTA), an adequacy decision, or binding corporate rules. For US-based processors handling EU personal data, certification under the EU–US Data Privacy Framework provides an adequacy basis for transfers. The DPA should attach the applicable transfer instrument as an addendum, specifying which module and which party is the data exporter and importer.
Yes, if they use any third-party tool or service that processes personal data on their behalf. Common examples include payroll software, email marketing platforms, CRM systems, cloud file storage, and accounting tools. The obligation applies regardless of company size under GDPR and most modern privacy laws. Many small businesses satisfy this through the vendor's standard DPA — available in the vendor's privacy or legal documentation — but the agreement must still be executed before personal data is shared.
An NDA protects confidential business information — trade secrets, financial data, product plans — from unauthorized disclosure between two parties. A DPA specifically governs the lawful handling of personal data belonging to third-party individuals such as customers or employees. An NDA does not satisfy GDPR or privacy law requirements for data processor relationships. Where both confidential business information and personal data are shared, both documents are typically required.
A privacy policy is a public-facing notice informing individuals how a business collects and uses their personal data. A DPA is a private contractual instrument between two businesses governing how a processor handles personal data on the controller's behalf. A privacy policy is directed at data subjects; a DPA is directed at the processor. GDPR requires both — the privacy policy does not replace the DPA obligation.
A Business Associate Agreement (BAA) is a US-specific HIPAA instrument governing how healthcare service providers handle protected health information (PHI) on behalf of a covered entity. A DPA is a broader instrument under GDPR and modern privacy laws covering all personal data, not just health data, and applies globally. US healthcare companies processing EU patient data may require both a HIPAA BAA and a GDPR-compliant DPA with the same vendor.
A data sharing agreement governs situations where two organizations share personal data for their own independent purposes — both acting as data controllers — such as two businesses co-marketing to a shared audience. A DPA covers the narrower relationship where one party processes data strictly on the other's instructions. The distinction is legally significant: controller-to-controller sharing requires a data sharing agreement, not a DPA.
SaaS vendors operate simultaneously as data processors for customers and data controllers for their own user data, requiring a clearly delineated DPA that covers sub-processor chains including cloud infrastructure and analytics providers.
Healthcare organizations processing patient data outside the US must pair the DPA with HIPAA Business Associate Agreement obligations, and the security schedule must address clinical-data-specific controls such as audit logging and role-based access to patient records.
Financial institutions face layered data protection obligations under sector-specific regulations — PCI DSS, GLBA, and MiFID II — meaning the DPA security schedule must reference compliance with these frameworks in addition to general privacy law requirements.
Retail and e-commerce businesses share customer behavioral data, purchase history, and payment information with analytics tools, advertising networks, and fulfilment partners — each requiring a separate DPA that addresses consent-based processing and cookie data under ePrivacy rules.
Law firms, accountancies, and consultancies frequently process client personal data using third-party practice management or document platforms, making DPAs essential for maintaining client confidentiality obligations alongside regulatory data protection requirements.
HR functions share sensitive employee data — payroll details, health information, background check results — with multiple processors, requiring DPAs that explicitly address special-category data processing obligations and the heightened security measures they require.
The US has no single federal data protection law equivalent to GDPR, but a growing number of state privacy laws — California (CPRA), Virginia (VCDPA), Colorado (CPA), Connecticut, and others — impose data processing agreement requirements on businesses above certain thresholds. HIPAA requires a Business Associate Agreement for healthcare data. US companies processing personal data of EU or UK residents must comply with GDPR and UK GDPR regardless of where the company is located, typically requiring Standard Contractual Clauses for data transfers.
Canada's federal private-sector privacy law (PIPEDA, succeeded by Bill C-27 / CPPA when enacted) requires organizations to use contractual or other means to ensure comparable privacy protection when transferring personal data to third-party processors. Quebec's Law 25 (in force since 2023) imposes explicit written contract requirements for data transfers to processors and requires a privacy impact assessment for cross-border transfers. Organizations subject to Quebec Law 25 should ensure their DPAs include the mandatory elements specified under that regime.
The UK GDPR (retained post-Brexit) imposes requirements substantively identical to EU GDPR Article 28, requiring a binding written DPA for all controller-processor relationships. The UK Information Commissioner's Office (ICO) has published its own International Data Transfer Agreement (IDTA) as the approved mechanism for transfers from the UK to third countries — EU SCCs are no longer sufficient on their own for UK data transfers. The UK–US data bridge provides an adequacy mechanism for transfers to certified US organizations.
GDPR Article 28 is the primary legal basis for DPA requirements in the EU, mandating a written contract covering all ten specified elements before processing begins. The European Commission issued new modular Standard Contractual Clauses in June 2021, replacing the 2010 SCCs — the new Module 2 (controller to processor) should be incorporated or attached for transfers outside the EEA. GDPR fines for DPA violations can reach €10 million or 2% of global annual turnover under Article 83(4). Member states including France (CNIL) and Germany (multiple DPAs) have issued additional national guidance on DPA content.
| Path | Best for | Cost | Time |
|---|---|---|---|
| Use the template | Small and mid-size businesses using standard SaaS tools and cloud platforms where the vendor provides a template DPA for completion | Free | 30–60 minutes |
| Template + legal review | Businesses processing special-category data, handling cross-border EU or UK transfers, or negotiating DPAs with enterprise customers | $400–$900 | 2–5 days |
| Custom drafted | SaaS vendors building a scalable DPA program for enterprise sales, healthcare or financial services companies with sector-specific regulatory requirements, or cross-border data infrastructure agreements | $1,500–$5,000+ | 1–3 weeks |
This document is one of 3,000+ business & legal templates included in Business in a Box.
Access over 3,000+ business and legal templates for any business task, project or initiative.
Customize your ready-made business document template and save it in the cloud.
Share your files and folders with your team. Create a space of seamless collaboration.
"Fantastic value! I'm not sure how I'd do without it. It's worth its weight in gold and paid back for itself many times."
"I have been using Business in a Box for years. It has been the most useful source of templates I have encountered. I recommend it to anyone."
"It has been a life saver so many times I have lost count. Business in a Box has saved me so much time and as you know, time is money."
Stop downloading documents. Start operating with clarity. Business in a Box gives you the Business Operating System used by over 250,000 companies worldwide to structure, run, and grow their business.
Start free · No credit card required
