Free Word download • Edit online • Save & share with Drive • Export to PDF
A Data Processing Agreement (DPA) is a legally binding contract between a data controller — the organization that determines the purpose and means of processing personal data — and a data processor — the vendor, platform, or service provider that handles that personal data on the controller's behalf. The DPA defines the processor's obligations: to act only on the controller's documented instructions, maintain appropriate security measures, manage sub-processors, assist with data subject rights requests, notify the controller of breaches within a defined window, and delete or return all personal data when the relationship ends. Under GDPR Article 28, a written DPA is not optional — it is a mandatory prerequisite to any processor engagement involving EU or UK personal data, and functionally equivalent requirements now apply under California's CCPA/CPRA, Quebec's Law 25, and a growing roster of US state privacy laws.
Unlike a general confidentiality agreement or master services contract, a DPA is specifically structured around data protection law and must reflect the actual categories of data being processed, the specific technical and organizational security measures in place, and the chain of accountability from controller through processor to any downstream sub-processors. This free Word download gives you a compliance-ready template you can edit online, adapt to your specific processing activities, and export as PDF for execution — covering every clause required under GDPR Article 28(3) and compatible with the major data protection frameworks in North America and the UK.
Operating without a signed DPA creates simultaneous regulatory and commercial exposure. Regulators treat the absence of a DPA as evidence of unlawful processing — the gap period before you execute the agreement carries the same fine exposure as a breach itself, up to 2% of global annual turnover under GDPR. Enterprise customers conducting vendor due diligence will stall or cancel procurement if you cannot produce a signed DPA on request; it has become a standard checkbox in B2B security questionnaires alongside SOC 2 reports and ISO 27001 certificates. Without a DPA, you also have no enforceable contractual right to require your processor to notify you of a data breach within the window you need to meet your own 72-hour supervisory authority reporting obligation — leaving you legally exposed for a processor's failure. A clearly drafted DPA specifying deletion obligations with certification requirements protects you from residual liability after a vendor relationship ends, when former processors may retain copies of your customers' data indefinitely without a contractual obligation to purge. This template gives you a structured, jurisdiction-aware starting point that closes all of these gaps — ready to customize, negotiate, and execute before personal data moves.
| If your situation is… | Use this template |
|---|---|
| Processing EU/EEA personal data under GDPR | GDPR Data Processing Agreement |
| Transferring personal data outside the EU to a third country | Standard Contractual Clauses (SCCs) |
| California consumer data regulated under CCPA/CPRA | CCPA Data Processing Addendum |
| Two controllers jointly determining processing purposes | Joint Controller Agreement |
| Sharing personal data between two organizations for a specific purpose | Data Sharing Agreement |
| Engaging a sub-processor downstream of the main processor | Sub-Processor Agreement |
| Comprehensive privacy program documentation including DPA | Privacy Policy Template |
Why it matters: GDPR Article 28 requires the DPA to be in place before processing begins. Retroactive execution exposes both parties to regulatory findings of unlawful processing covering the gap period — fines up to 2% of global annual turnover apply.
Fix: Make DPA execution a hard gate in vendor onboarding. No access to personal data systems should be provisioned until the signed DPA is filed.
Why it matters: A DPA that references 'industry-standard security' without specifying controls fails GDPR Article 28(3)(c) and provides no enforceable baseline if a breach occurs — regulators will treat the omission as evidence of inadequate due diligence.
Fix: Enumerate specific controls in Annex 2 — encryption standard, access control model, audit log retention period, and penetration testing frequency — and require the processor to notify you of material changes to these controls.
Why it matters: Allowing sub-processors without a notice period prevents controllers from exercising their GDPR Article 28(2) right to object, creating a compliance gap and potential liability for downstream breaches by undisclosed sub-processors.
Fix: Include a clause requiring at least 30 days' written notice of any new sub-processor and granting the controller a documented objection right, with a defined process for resolving disputes.
Why it matters: If the processor has 72 hours to notify the controller, and the controller has 72 hours to notify the supervisory authority, any processor delay — even by hours — puts the controller in breach of its own regulatory deadline.
Fix: Set the processor's notification deadline at 24–48 hours, require a preliminary notice even if full details are unknown, and include a list of the minimum information required in that first notification.
Why it matters: Without written confirmation of deletion, controllers cannot demonstrate to regulators that they fulfilled their data minimization and storage limitation obligations after a vendor relationship ends — a common finding in post-termination audits.
Fix: Require the processor to deliver written certification of deletion within 30 days of termination, specifying the deletion method and confirming that all copies — including backups — have been purged or scheduled for purge.
Why it matters: Several EU supervisory authorities and enterprise procurement teams reject DPAs that limit the controller's audit right to reviewing third-party certifications. This model also fails to address scenarios where the certification scope does not cover the specific processing activities in the DPA.
Fix: Preserve a direct audit right exercisable on reasonable notice (30 days is standard), even if you also accept SOC 2 or ISO 27001 reports as a primary compliance mechanism.
In plain language: Sets out the precise meaning of controller, processor, personal data, and processing as used in the agreement, and identifies the subject matter, duration, nature, and purpose of the processing.
In this Agreement, 'Personal Data', 'Controller', 'Processor', and 'Processing' have the meanings given in [APPLICABLE REGULATION]. The Processor shall process Personal Data only as described in Annex 1 (Subject Matter, Duration, Nature, Purpose, and Data Categories) on behalf of the Controller.
Common mistake: Copying GDPR definitions without updating them to reflect the applicable regulation in the governing jurisdiction — leaving the DPA ambiguous for US-state-law or Canadian-law processing.
In plain language: Establishes that the processor may only process personal data on documented instructions from the controller — and must alert the controller if it believes an instruction would violate applicable law.
Processor shall process Personal Data only on documented instructions from Controller, including with regard to transfers, unless required to do so by applicable law. Processor shall immediately inform Controller if, in its opinion, an instruction infringes applicable data protection law.
Common mistake: Allowing the processor to process data for its own purposes or analytics without a separate lawful basis — this transforms the processor into a controller and voids the DPA's legal structure.
In plain language: Requires the processor to ensure that all personnel authorized to process personal data are bound by a confidentiality obligation, whether contractual or statutory.
Processor shall ensure that persons authorized to process Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.
Common mistake: Omitting confidentiality obligations for contractor or temporary staff who access personal data — creating a gap that regulators treat as a failure of organizational security measures.
In plain language: Specifies the security controls the processor must maintain to protect personal data, calibrated to the risk of the processing — encryption, access controls, pseudonymization, backup, and incident response procedures.
Processor shall implement and maintain the technical and organizational measures set out in Annex 2, including at minimum: [encryption in transit and at rest using AES-256], [role-based access controls], [annual penetration testing], and [a documented incident response plan].
Common mistake: Referencing TOMs only in a vague annex placeholder without specifying actual controls — regulators and enterprise customers will reject a DPA that says 'appropriate security' without enumerated measures.
In plain language: Sets the conditions under which the processor may engage sub-processors — general or specific written authorization — and requires the processor to flow down equivalent DPA obligations to each sub-processor.
Processor shall not engage any sub-processor without prior [specific / general] written authorization from Controller. Where general authorization is granted, Processor shall notify Controller of any intended sub-processor changes, giving Controller the opportunity to object. Processor shall impose equivalent data protection obligations on each sub-processor.
Common mistake: Granting general authorization for sub-processors without a notification and objection mechanism — this prevents the controller from maintaining actual oversight of the sub-processing chain.
In plain language: Obligates the processor to assist the controller in responding to data subjects exercising their rights — access, rectification, erasure, restriction, portability, and objection — within the controller's legal deadlines.
Processor shall, taking into account the nature of the processing, assist Controller by implementing appropriate technical and organizational measures to fulfill Controller's obligation to respond to requests for exercising data subjects' rights under [APPLICABLE REGULATION] within [30] days of receipt.
Common mistake: Setting no timeframe for the processor's assistance obligation — if the controller faces a 30-day regulatory deadline, a processor that takes 25 days to acknowledge a request causes a breach of the controller's statutory obligation.
In plain language: Requires the processor to notify the controller of a personal data breach without undue delay — and within a specified maximum period — and to provide the information needed for the controller to fulfill its own regulatory notification obligations.
Processor shall notify Controller of a Personal Data Breach without undue delay and, where feasible, not later than [48] hours after becoming aware of it. The notification shall include the information specified in Annex 3, to the extent available at the time of notification.
Common mistake: Setting the notification window at 72 hours or longer — GDPR requires controllers to notify supervisory authorities within 72 hours, so a 72-hour processor notice window leaves the controller zero time to assess the incident before its own deadline runs.
In plain language: Requires the processor to return or securely delete all personal data after the service relationship ends, and to certify deletion in writing to the controller.
Upon termination or expiry of this Agreement, Processor shall, at Controller's election, delete or return all Personal Data to Controller and delete existing copies, unless applicable law requires storage. Processor shall certify such deletion in writing within [30] days of the date of termination.
Common mistake: No deletion certification requirement — without it, controllers have no audit trail confirming that former processors actually purged the data, creating residual regulatory exposure.
In plain language: Grants the controller — or its designated auditor — the right to conduct audits or inspections of the processor's processing activities to verify compliance, and requires the processor to cooperate fully.
Processor shall make available to Controller all information necessary to demonstrate compliance with its obligations and shall allow for and contribute to audits, including inspections, conducted by Controller or an auditor mandated by Controller, on [30] days' prior written notice.
Common mistake: Granting only a right to review third-party audit reports (e.g., SOC 2) without preserving a direct audit right — some regulators and enterprise customers require the ability to conduct their own inspections and will reject a DPA that replaces this with a certification-only model.
In plain language: Specifies which jurisdiction's law governs the DPA, where disputes are resolved, and how liability is allocated between controller and processor for data protection failures.
This Agreement is governed by the laws of [JURISDICTION]. Each party's liability under this Agreement shall be subject to the limitations and exclusions set out in the Master Services Agreement between the parties, except to the extent that applicable data protection law renders such limitations unenforceable.
Common mistake: Choosing a governing law that conflicts with where the data subjects are located or where the processor operates — several regulators assert jurisdiction regardless of the chosen law, making an inconsistent choice legally untested and commercially risky.
Enter the full registered legal entity names of both parties — not trade names or brand names. Confirm which party determines the purpose of processing (controller) and which acts only on instructions (processor).
💡 If both parties independently determine processing purposes for any part of the data, you need a Joint Controller Agreement for that portion, not a DPA.
Specify the subject matter, duration, nature, and purpose of the processing, along with the categories of personal data (e.g., names, email addresses, payment card data) and categories of data subjects (e.g., end customers, employees).
💡 Be specific — 'customer data' is too vague to satisfy a regulatory audit. List the actual data fields your processor handles.
State the permissible processing activities and any geographic restrictions explicitly. Include a clause requiring the processor to flag any instruction it believes would breach applicable law.
💡 Attach your data flows diagram as a schedule — it clarifies the instruction scope and serves as evidence during regulatory inquiries.
List specific security controls: encryption standard (e.g., AES-256 in transit and at rest), access control model, backup frequency, penetration testing cadence, and incident response plan reference.
💡 Request the processor's most recent SOC 2 Type II or ISO 27001 certificate and cross-reference its scope against the TOMs you list — gaps between the certificate and the DPA Annex are a common audit finding.
Decide between specific authorization (naming each sub-processor) and general authorization (allowing new sub-processors with notice and objection rights). Require the processor to impose equivalent obligations on each sub-processor.
💡 Ask the processor for its current sub-processor list before signing — surprises in the first notification after execution erode trust and slow the objection process.
Set the processor's notification deadline at 48 hours or less to give yourself buffer before your own 72-hour GDPR supervisory authority reporting deadline. Specify what information must be included in the notification.
💡 Require a preliminary notification within 24 hours even if full details are unavailable — regulators accept staged notifications and penalize silence.
Choose whether the controller wants data returned or deleted on termination, set the processor's deadline for completing this (30 days is standard), and require written certification of deletion.
💡 Include a data retention schedule in the annex — processors often retain backups beyond the standard deletion period; the schedule forces them to commit to a specific purge date.
Both authorized signatories must execute the DPA before the processor handles any personal data. File the signed DPA alongside the Master Services Agreement and update it whenever processing activities change materially.
💡 Set a calendar reminder to review the DPA annually — regulatory changes, new data categories, and processor infrastructure changes can all trigger an amendment obligation.
A data processing agreement (DPA) is a legally binding contract between a data controller and a data processor that governs how personal data is handled on the controller's behalf. It sets out the processor's obligations — to act only on instructions, maintain security, notify the controller of breaches, and delete data on termination — and preserves the controller's rights to audit and enforce compliance. Under GDPR Article 28, a written DPA is mandatory whenever a controller engages a processor; similar requirements apply under CCPA, PIPEDA, and other data protection frameworks.
You need a DPA any time a vendor or service provider processes personal data on your behalf rather than for its own purposes. Common triggers include engaging a SaaS CRM, payroll processor, cloud hosting provider, email marketing platform, analytics tool, or background-check service that handles your customers' or employees' personal data. The DPA must be executed before any personal data is transferred — retroactive execution does not cure the gap period under GDPR.
A data controller is the entity that determines why and how personal data is processed — typically your business. A data processor is a third party that handles personal data strictly on the controller's documented instructions, without independently determining the purpose or means of processing. The distinction matters because controllers and processors carry different legal obligations and liabilities under GDPR, CCPA, and comparable laws. If a vendor uses your data for its own analytics or advertising, it may be acting as a controller for that purpose — which requires a different legal basis than a DPA.
Yes. GDPR Article 28 explicitly requires a binding written contract between every controller and processor covering the processor's obligations. Processing without a DPA in place is itself a violation of GDPR and can result in regulatory fines, even if no data breach has occurred. The contract must cover subject matter and duration, nature and purpose of processing, data categories, data subject categories, and the controller's rights and processor's obligations as specified in Article 28(3).
Yes. A DPA must be executed as a binding agreement between the controller and processor — both parties must sign, and the signing authority on each side must have the authorization to bind their respective organizations. Many SaaS vendors present DPAs as online click-through agreements; these are generally valid under GDPR where a clear acceptance mechanism exists, but a countersigned document is preferable for enterprise relationships and regulatory evidence.
A sub-processor is a third party that the processor engages to carry out specific processing activities on the controller's personal data — for example, a cloud hosting provider used by a SaaS vendor. Under GDPR Article 28(2), the processor must obtain either specific or general written authorization from the controller before engaging a sub-processor. The DPA should require the processor to notify the controller of new sub-processors with sufficient advance notice (typically 30 days) to allow the controller to object, and to impose equivalent DPA obligations on every sub-processor it engages.
At minimum, the DPA's technical and organizational measures (TOMs) annex should cover encryption in transit and at rest (standard: AES-256), role-based access controls with multi-factor authentication, regular vulnerability assessments and penetration testing, a documented incident response plan, backup and recovery procedures, and employee security training requirements. Vague references to "industry-standard security" without enumerated controls fail GDPR Article 28(3)(c) and provide no enforceable baseline in the event of a breach.
Under GDPR, controllers must notify their supervisory authority within 72 hours of becoming aware of a breach. To give controllers adequate time to assess and report, the processor's DPA notification obligation should be set at 24–48 hours. A 72-hour processor deadline is a common drafting mistake — any delay by the processor puts the controller in breach of its own regulatory obligation. Require a preliminary notification even when full details are not yet available, and specify the minimum information that must be included.
On termination or expiry of the DPA, the processor must — at the controller's election — either return all personal data in a portable format or securely delete it, and must delete all existing copies including backups within an agreed period (typically 30 days), unless applicable law requires continued storage. The processor should provide written certification of deletion, specifying the method used and confirming that all copies have been purged. Without this certification, controllers have no audit trail to demonstrate compliance with data minimization and storage limitation obligations.
An NDA protects confidential business information shared between parties in a commercial relationship — it covers trade secrets, pricing, and strategy, not the legal obligations around processing personal data. A DPA is specifically required by data protection law whenever personal data is processed by a third party on a controller's behalf. Both documents often exist alongside each other, but they serve distinct legal functions.
A privacy policy is a public-facing disclosure to data subjects explaining what personal data you collect, why, and how you use it. A DPA is a binding contract between two businesses — the controller and processor — governing the processor's obligations. Both are required under GDPR but address entirely different relationships: the privacy policy faces outward to individuals; the DPA faces inward to vendors.
A Master Service Agreement (MSA) governs the overall commercial relationship — scope of services, fees, IP, warranties, and liability. A DPA is a data-specific addendum that operates alongside the MSA, addressing obligations required by data protection law. The DPA typically incorporates the MSA's liability caps but carves out uncapped liability for certain data protection breaches as required by regulation.
A data sharing agreement governs the transfer of personal data between two controllers — for example, two organizations sharing customer data for a joint research project. A DPA governs processing by a processor acting strictly on the controller's instructions. If both parties independently determine the purpose of processing, a joint controller agreement or data sharing agreement is needed, not a DPA.
SaaS vendors serve as processors for enterprise controller-customers and must provide a GDPR-compliant DPA as a standard commercial deliverable before closing mid-market and enterprise deals.
Healthcare processors handling protected health information must layer HIPAA Business Associate Agreement obligations on top of GDPR or CCPA DPA requirements, creating a dual-compliance framework with overlapping but non-identical security and breach notification rules.
Financial processors handling payment card data, account information, or credit data face DPA obligations alongside PCI DSS requirements and sector-specific regulatory expectations from the FCA, CFPB, or equivalent authorities.
Payroll processors, background-check providers, and benefits platforms handle sensitive employee personal data — including special category data such as health and financial information — making a robust DPA with explicit special-category processing provisions essential.
The US lacks a single federal data processing law, but CCPA/CPRA (California), VCDPA (Virginia), CPA (Colorado), and a growing number of state privacy laws require written data processing contracts with service providers. HIPAA mandates a Business Associate Agreement for processors handling protected health information — a BAA is a distinct instrument from a GDPR-style DPA and has specific statutory content requirements. Controllers operating in multiple US states should confirm which state privacy laws apply to their processing activities and whether the DPA template satisfies each.
Canada's PIPEDA and the newer Bill C-27 (Consumer Privacy Protection Act, pending enactment) require organizations to use contractual means to protect personal information disclosed to service providers. Quebec's Law 25 (Bill 64), in force since September 2023, imposes GDPR-comparable obligations including written data processing contracts, mandatory privacy impact assessments, and breach notification requirements. Processors handling Quebec residents' data must comply with Law 25 regardless of their location.
The UK GDPR — retained as domestic law post-Brexit under the Data Protection Act 2018 — mirrors GDPR Article 28 DPA requirements. Controllers in the UK must also ensure that transfers of personal data to processors outside the UK comply with UK adequacy regulations or use UK-specific International Data Transfer Agreements (IDTAs) rather than EU Standard Contractual Clauses. The ICO has published a DPA template and guidance that UK-based controllers may use as a compliance baseline.
GDPR Article 28 is the primary source of DPA obligations across all EU member states. The European Data Protection Board (EDPB) has issued guidance on Article 28 requirements, and the European Commission's 2021 Standard Contractual Clauses must be used for any transfer of personal data to processors in third countries lacking an adequacy decision. Member state supervisory authorities — including the CNIL (France), BfDI (Germany), and Garante (Italy) — publish national DPA guidance that may impose additional specificity requirements beyond the GDPR minimum.
| Path | Best for | Cost | Time |
|---|---|---|---|
| Use the template | Small businesses and startups executing standard DPAs with SaaS vendors or service providers for routine processing activities | Free | 30–60 minutes per DPA |
| Template + legal review | Mid-market companies onboarding processors handling sensitive or special-category data, cross-border data transfers, or material volumes of EU/UK personal data | $500–$1,500 for a privacy lawyer review | 2–5 days |
| Custom drafted | Enterprise processors serving as DPA counterparties in regulated sectors (healthcare, financial services), multi-jurisdiction processing chains, or organizations subject to active regulatory scrutiny | $2,500–$8,000+ | 2–4 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
