DPA agreement for privacy teams: template & checklist
Alex Shi
A data processing agreement (DPA) is a legally binding contract required under GDPR Article 28 whenever a processor handles personal data on behalf of a controller. Without one in place before processing begins, the processing is unlawful: full stop. The immediate action: require a signed DPA before any vendor or service provider touches EU personal data, and verify that the contract covers all eight provisions listed in Article 28(3). The annotated template in Section 7 gives you copy-ready clause language for each one.
Table of Contents
- What a data processing agreement actually is (and how it differs from an NDA or MSA)
- When does your organization actually need a DPA?
- The eight core clauses required by GDPR Article 28(3)
- What your Annex II (technical and organizational measures) needs to include
- How to manage sub-processors: authorization models and objection procedures
- An annotated DPA template you can copy and adapt
- Negotiation priorities and common pitfalls
- Key Takeaways
- Why most DPA failures are process failures, not legal ones
- How Formable helps you draft, negotiate, and store compliant DPAs
- Authoritative sources for further reading
- FAQ
What a data processing agreement actually is (and how it differs from an NDA or MSA)
A DPA defines the relationship between two parties: the data controller (the organization that determines why and how personal data is processed) and the data processor (the vendor or service provider that processes data on the controller's behalf, following the controller's instructions). Getting this classification right matters because it determines who bears which legal obligations under GDPR.
The legal trigger is Article 28(3): processing by a processor must be governed by a binding contract that sets out the subject matter, duration, nature, and purpose of the processing, along with the type of personal data and categories of data subjects involved. A DPA that omits any of these elements is legally deficient, regardless of how well-drafted the rest of it is.
Professionals often confuse DPAs with NDAs or MSAs. They serve different purposes and are not interchangeable.
| Contract | Primary purpose | Legal basis | When you need it |
|---|---|---|---|
| DPA | Governs processing, security, and lifecycle of personal data | GDPR Article 28 | Before any processor handles EU personal data |
| NDA | Protects confidential business information from disclosure | Contract law | When sharing proprietary or sensitive business information |
| MSA | Sets commercial terms for an ongoing service relationship | Contract law | When establishing a long-term vendor or client relationship |
A DPA is not an NDA. An NDA keeps business secrets private; a DPA governs what a processor can do with personal data, how it must protect that data, and what happens when the relationship ends. In practice, you often need both: the MSA sets the commercial terms, the NDA protects confidential information exchanged during the engagement, and the DPA governs the personal data processing. For a deeper look at how NDAs fit alongside DPAs in your contract stack, see Formable's guide on unilateral vs. mutual NDAs.
Quick distinctions to keep in mind:
- A DPA is required by law when EU personal data is involved; an NDA is a commercial choice.
- A DPA travels with the data; an MSA governs the service relationship broadly.
- Signing an NDA does not satisfy GDPR's DPA requirement, even if it includes a data confidentiality clause.
- A DPA must be updated when processing activities change; an MSA amendment is not a substitute.
When does your organization actually need a DPA?
Three conditions together trigger the DPA requirement. First, an external party processes personal data on your instructions rather than for its own purposes. Second, the data subjects are located in the EEA, UK, or Switzerland. Third, the processing is on your behalf: the vendor is acting as your processor, not as an independent controller making its own decisions about the data.
If all three apply, a signed DPA must exist before processing starts. Timing is not negotiable. Failure to formalize a DPA exposes organizations to regulatory fines and reputational damage, and supervisory authorities have cited missing DPAs as a standalone violation in enforcement actions.
For U.S.-based organizations, the most common triggers include:
- Cloud hosting and infrastructure providers processing EU customer data on your servers
- HR and payroll vendors handling employee data for EEA-based staff
- Analytics and marketing platforms processing behavioral data from EU website visitors
- Customer support tools where agents access EU customer records
- Subcontractors who receive EU personal data as part of a project delivery
SaaS click-through DPAs are common and can be legally valid, but they require the same Article 28(3) review as a negotiated agreement. Many SaaS vendors publish their DPA in their legal documentation hub; your procurement checklist should confirm it covers all eight mandatory elements before you accept it.
Procurement and IT checklist:
- Identify whether the vendor processes EU personal data on your behalf or as an independent controller.
- Confirm the DPA is signed (or click-through accepted) before any data transfer or system access.
- Store the executed DPA alongside the MSA and any annexes in a central contract repository.
- Assign a DPA owner (legal, privacy, or compliance) and a review trigger (contract renewal, change in processing scope, or sub-processor update).
- Track DPA version history so you can demonstrate which version was in force at any given time.
The eight core clauses required by GDPR Article 28(3)
Article 28(3) specifies exactly what a DPA must contain. Missing any one of these elements makes the contract legally deficient, regardless of its commercial terms. Here is each element, what it means in plain language, a red-flag phrase to avoid, and a tight example clause.
1. Processing only on documented instructions The processor must act solely on the controller's written instructions. If the processor needs to process data for any other purpose, it must notify the controller first. Red flag: "Processor may use data to improve its services." Example clause: "Processor shall process Personal Data only on documented instructions from Controller, including with regard to transfers of Personal Data to a third country, unless required to do so by applicable law."
2. Confidentiality obligations Everyone with access to the personal data must be bound by confidentiality, either by contract or statutory obligation. Red flag: "Processor will take reasonable steps to limit access." Example clause: "Processor shall ensure that persons authorized to process Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality."
3. Security measures (Article 32) The processor must implement technical and organizational measures appropriate to the risk. This is the foundation for Annex II (see Section 5). Red flag: "Processor will maintain industry-standard security." Example clause: "Processor shall implement and maintain the technical and organizational measures set out in Annex II, which satisfy the requirements of Article 32 GDPR."
4. Sub-processor controls The processor cannot engage a sub-processor without prior specific or general written authorization from the controller. Sub-processors must be bound by equivalent data protection obligations. Red flag: "Processor may engage sub-processors at its discretion." Example clause: "Processor shall not engage a sub-processor without prior written authorization from Controller. Where general authorization is given, Processor shall notify Controller of any intended changes and allow Controller a reasonable objection period."
5. Assistance with data subject rights The processor must help the controller respond to requests from data subjects exercising their rights (access, erasure, portability, etc.). Red flag: "Processor will cooperate with data subject requests where feasible." Example clause: "Processor shall, taking into account the nature of the processing, assist Controller by appropriate technical and organizational measures in fulfilling its obligation to respond to requests for exercising data subject rights."
6. Compliance assistance (breach notification and DPIAs) The processor must assist with breach notifications, DPIAs, and prior consultations. Costs and scope of this assistance should be contractually defined to avoid disputes. Red flag: "Processor will notify Controller of breaches when practicable." Example clause: "Processor shall notify Controller without undue delay, and in any event within 48 hours of becoming aware of a Personal Data Breach, providing the minimum information set out in Schedule [X]."
7. Deletion or return of data At the end of the service, the processor must delete or return all personal data and delete existing copies, unless retention is required by law. Red flag: "Processor will delete data within a reasonable time after contract end." Example clause: "Upon termination of the Agreement, Processor shall, at Controller's election, delete or return all Personal Data and delete existing copies within 30 days, unless applicable law requires retention of the Personal Data."
8. Audit and inspection rights The controller must be able to audit the processor's compliance, either directly or through a third-party auditor. Red flag: "Controller may request information about Processor's security practices." Example clause: "Processor shall make available to Controller all information necessary to demonstrate compliance with this Agreement and allow for and contribute to audits and inspections conducted by Controller or a mandated auditor, subject to reasonable notice and confidentiality obligations."
What your Annex II (technical and organizational measures) needs to include
Annex II is where the security commitments in Article 32 become concrete. Regulators expect specific, demonstrable controls rather than vague boilerplate. A clause that says "we use industry-standard encryption" tells an auditor nothing. A clause that names AES-256 encryption at rest, TLS 1.2+ in transit, and references a dated SOC 2 Type II report gives them something to verify.
Pro Tip: Include verifiable artifacts in Annex II: the encryption standard (e.g., AES-256), the MFA rollout date, the most recent penetration test date, and the SOC 2 report period. Auditors look for date-stamped evidence, not aspirational language.
| TOM category | What to state in the DPA | Evidence an auditor will seek |
|---|---|---|
| Access controls | Role-based access, least-privilege principle, MFA for privileged accounts | MFA configuration screenshots, access review logs |
| Encryption | AES-256 at rest, TLS 1.2+ in transit | Encryption policy, certificate inventory |
| Monitoring and logging | Audit logs retained for [X] days, SIEM alerts for anomalous access | Log retention policy, SIEM dashboard sample |
| Backup and restore | Daily encrypted backups, restore tested quarterly | Backup schedule, most recent restore test record |
| Personnel and training | Annual security awareness training, background checks for data handlers | Training completion records, HR policy |
| Incident response | Documented IR plan, tabletop exercises conducted annually | IR plan version date, exercise after-action report |
| BCP and DRP | Recovery time objective (RTO) and recovery point objective (RPO) defined | BCP document, last test date and outcome |
Annex II should be reviewed at least annually and updated whenever the processor makes a material change to its security architecture. Tie the review obligation to the DPA itself so it does not get lost in a general vendor review cycle.
How to manage sub-processors: authorization models and objection procedures
Sub-processor management is one of the most operationally complex parts of a DPA. Two authorization models are in common use, and the right choice depends on how dynamic the processor's supply chain is.
Model 1: Specific authorization. The controller approves each sub-processor by name before engagement. This gives the controller maximum visibility but creates friction for processors with large or frequently changing vendor lists. It works well for high-risk processing or when the controller has strong data minimization requirements.
Model 2: General authorization with notification and objection window. The processor maintains a public list of approved sub-processors and notifies the controller of any intended changes. The controller has a defined window (typically 10–30 days) to object. If no objection is raised, the change proceeds. A live sub-processor list plus a clear objection window is market standard and audit-friendly.
Sample clause for Model 2: "Processor shall maintain a publicly accessible list of sub-processors at [URL]. Processor shall notify Controller at least [14] days in advance of any intended addition or replacement of a sub-processor. Controller may object in writing within [14] days of notification on reasonable data protection grounds. Where Controller objects and the parties cannot resolve the dispute, Controller may terminate the relevant services on [30] days' written notice."
What controllers should insist on, regardless of the model:
- The purpose, location, and security posture of each sub-processor must be documented.
- Flow-down obligations: sub-processors must be bound by data protection terms at least as protective as those in the DPA.
- Back-to-back terms: the processor remains fully liable to the controller for the acts and omissions of its sub-processors.
Red flags in sub-processor clauses:
- No notification requirement for new sub-processors
- Unlimited discretion to add sub-processors without controller approval
- No flow-down obligation to downstream sub-processors
- Objection window shorter than 10 days or no objection right at all
- Sub-processor list not publicly accessible or not kept current
An annotated DPA template you can copy and adapt
A modular DPA structure keeps the agreement organized and makes it easier to update individual components without renegotiating the whole contract. Here is the recommended structure, with annotation notes on each module.
Preamble and recitals Identify the parties, their roles (controller and processor), and the legal basis for the agreement. Reference the main services agreement (MSA or order form) that this DPA supplements. Annotation: Confirm that the controller and processor roles are correctly assigned. Misclassifying a joint controller as a processor is a common error that invalidates the DPA's legal effect.
Definitions Define "Personal Data," "Processing," "Data Subject," "Sub-processor," "Personal Data Breach," and "Supervisory Authority" by reference to GDPR Article 4. Annotation: Use GDPR's own definitions verbatim. Custom definitions that narrow the scope of "personal data" are a red flag in vendor templates.
Scope and processing description (Annex I) Annex I should capture: subject matter, duration, nature and purpose of processing, type of personal data, and categories of data subjects. This is the factual foundation of the DPA. Annotation: Be specific. "Customer data" is not sufficient. Name the data types (name, email, payment card data, health information) and the processing activities (storage, analysis, transmission).
Article 28(3) core clauses Include all eight mandatory elements as described in Section 4. Do not consolidate them into a single "compliance" clause: each element should be separately addressable.
Technical and organizational measures (Annex II) Populate using the TOM table in Section 5. Reference specific standards, tools, and report dates rather than generic commitments.
Sub-processor annex (Annex III) List all approved sub-processors with their name, location, and processing activity. For Model 2 authorization, include the URL of the live sub-processor list.
Standard Contractual Clauses and transfer annex (Annex IV) When data transfers outside the EEA are involved, incorporate the applicable SCC module. For controller-to-processor transfers, Module 2 is the standard choice. Complete Annex I, II, and III of the SCCs as required. Place the Transfer Impact Assessment (TIA) summary in Annex IV.
Pro Tip: Never edit the core approved SCC text. All negotiable commercial details belong in the annexes. Modifying the SCC clauses themselves voids their safe-harbor effect and exposes both parties to transfer compliance risk.
Termination and end-of-service obligations State the deletion or return timeline and the format for confirming completion. Reference the backup retention caveat (see Section 8 for realistic timelines).
Liability and indemnity Processors typically seek to cap their liability at the fees paid under the MSA. Controllers should push for carve-outs for breaches caused by the processor's negligence or willful misconduct, and for third-party claims arising from the processor's failure to comply with the DPA.
Signature blocks Both parties must sign. For click-through DPAs, the acceptance timestamp and user identity should be captured and stored as part of the contract record. Formable's audit trail captures these events as immutable, timestamped records.
Negotiation priorities and common pitfalls
Many vendor DPAs are legally valid if they include the Article 28(3) items. The real negotiation is about specificity, risk allocation, and operational workability. Here is where to focus your effort.
Must-have compliance items (non-negotiable):
- All eight Article 28(3) elements present and substantive (not boilerplate)
- Specific TOMs in Annex II with verifiable artifacts, not aspirational language
- Sub-processor notification and objection right with a defined window
- Breach notification timeline of 48–72 hours with a minimum information set
- Deletion or return obligation with a defined timeline and confirmation mechanism
- Audit rights that include the right to request third-party certifications (SOC 2, ISO 27001)
Negotiable commercial items:
- Whether audit rights are exercised via certificate or on-site inspection (certificates are standard; on-site is reserved for high-risk processing)
- The length of the sub-processor objection window (10–30 days is the market range)
- Cost allocation for assistance with data subject rights requests and DPIAs
- The liability cap and carve-outs
- Deletion timelines in light of backup retention constraints
Tactical playbook:
- Push for evidence, not promises. Request the most recent SOC 2 Type II report, penetration test summary, and ISO 27001 certificate as part of DPA execution, not as a future deliverable.
- Frame cost-of-assistance language carefully. Processors must assist with breach notifications and DPIAs, but the DPA should specify what "assistance" includes and whether it is included in the service fee or billed separately.
- Accept vendor-hosted live sub-processor lists for Model 2 authorization, but require a direct notification mechanism (email to a named privacy contact) rather than relying on the controller to monitor the list.
- On deletion timelines: instantaneous deletion across distributed backups is often impractical. A compliant DPA should use "commercially reasonable" secure deletion timelines and document backup expiration policies. A 30-day active deletion plus a 90-day backup expiration window is a defensible and realistic standard.
Pro Tip: When a vendor insists on a 90-day or longer deletion window, ask them to document their backup rotation schedule and include it as an exhibit. That documentation becomes your evidence of compliance if a data subject later challenges the deletion.
Formable's collaborative redlining tool lets both parties mark up DPA terms in real time, so negotiation cycles that typically span weeks can close in days. For teams that want to start from a pre-built structure rather than a blank document, Formable's contract creator includes DPA templates with clause libraries aligned to Article 28(3).
Key Takeaways
A compliant DPA must be signed before processing begins and must include all eight elements specified in GDPR Article 28(3); missing any one element makes the contract legally deficient.
| Point | Details |
|---|---|
| Sign before processing starts | A DPA must be executed before any processor handles EU personal data; retroactive signing does not cure the violation. |
| Verify all eight Article 28(3) clauses | Check for documented instructions, confidentiality, security, sub-processor controls, data subject rights assistance, compliance assistance, deletion/return, and audit rights. |
| Require specific TOMs evidence | Annex II must name verifiable controls (AES-256, MFA, SOC 2 report date); vague boilerplate fails regulatory scrutiny. |
| Set a sub-processor objection process | Require a public sub-processor list, a 10–30 day objection window, and flow-down obligations to downstream vendors. |
| Retain DPAs and annexes centrally | Store the executed DPA, all annexes, and version history in a central repository; include SCCs and TIA summaries when transfers outside the EEA are involved. |
| Formable for DPA workflows | Formable's contract creator, redlining tool, and AI review engine help teams draft, negotiate, and store compliant DPAs with missing-clause detection built in. |
Why most DPA failures are process failures, not legal ones
The legal requirements for a data processing agreement are clear. Article 28(3) lists exactly what must be in the contract. The SCCs tell you precisely how to handle cross-border transfers. Regulators have published detailed guidance. And yet, organizations still get cited for missing DPAs, deficient TOMs, and sub-processor clauses that offer no real protection.
The failure is almost never a lack of legal knowledge. It is a process failure: the DPA was never requested during vendor onboarding, the TOMs annex was copied from a previous contract without review, or the sub-processor list was accepted without checking whether flow-down obligations existed. Privacy leads and legal counsel know what a good DPA looks like. The gap is between knowing and doing, consistently, across every vendor relationship.
There is also a tendency to treat DPA negotiation as a one-time event. A DPA signed at contract inception can become dangerously stale. Processing activities change. Sub-processors are added. Security architectures evolve. A DPA that accurately described the processing in 2022 may be materially inaccurate today. Building a review trigger into the contract itself, tied to renewal or material change, is the single most underused compliance control in this space.
One more thing worth saying plainly: vendor DPAs are not automatically bad. Many are well-drafted and cover the Article 28(3) requirements adequately. The question is not whether to use a vendor template, but whether you have actually read it against the checklist in Section 4 before accepting it. A click-through DPA accepted without review is a liability, not a compliance record.
How Formable helps you draft, negotiate, and store compliant DPAs
Closing a DPA that is both legally compliant and commercially acceptable takes more than a good template. It takes a workflow that catches missing clauses before signing, keeps both parties aligned during negotiation, and stores the final record where it can be retrieved at audit time.
Formable is built for exactly that workflow. Start from a DPA template with clause libraries aligned to Article 28(3), then use Formable's AI contract review engine to flag missing elements and risk language before the document goes to the other side. When the vendor sends back their own template, Formable's contract review catches gaps automatically. Collaborative redlining keeps both parties in the same document, and e-signing with a full audit trail closes the loop with an immutable, timestamped record. Annexes are versioned and stored alongside the executed agreement, so your compliance record is complete from day one. Start from the annotated template and close your next DPA faster.
Authoritative sources for further reading
These primary sources should be stored alongside your DPA record for audit readiness.
- GDPR Article 28 full text: the primary legal basis for all DPA requirements; reference for every mandatory clause.
- European Commission Standard Contractual Clauses guidance: official SCC text, module selection guidance, and annex completion instructions.
- EU Data Protection Reform overview: context on the GDPR framework and its ongoing application.
- Data Privacy Framework participant search: verify whether a U.S. vendor is certified under the EU-U.S. Data Privacy Framework before relying on it as a transfer mechanism.
- NDA vs. DPA: legal architecture of confidentiality and compliance: useful reference for explaining the distinction to non-legal stakeholders.
- GDPR and backups: handling deletion requests: practical guidance on deletion timelines and backup retention language.
- For a checklist-driven approach to keeping your contract documentation audit-ready, the technical SEO checklist for B2B websites from TheWebTeam.co illustrates the same discipline applied to documentation hygiene that privacy teams should apply to DPA record-keeping.
FAQ
Is a DPA a legal document?
Yes. A data processing agreement is a legally binding contract required by GDPR Article 28 whenever a processor handles personal data on a controller's behalf. Processing without one in place is unlawful under EU data protection law.
Is a DPA the same as an NDA?
No. An NDA protects confidential business information from disclosure, while a DPA governs the processing, security, and lifecycle of personal data under privacy law. You often need both, but one does not substitute for the other.
What is a DPA contract?
A DPA contract is the agreement between a data controller and a data processor that sets out the terms under which personal data is processed, including the mandatory eight elements specified in GDPR Article 28(3): documented instructions, confidentiality, security measures, sub-processor controls, data subject rights assistance, compliance assistance, deletion or return obligations, and audit rights.
Should a DPA be signed before processing starts?
Yes, always. GDPR Article 28 requires the processing to be governed by a binding contract before it begins. Retroactive signing does not cure the violation, and supervisory authorities have cited the absence of a pre-processing DPA as a standalone infringement.
Can you use a vendor's standard DPA template?
A vendor's standard DPA can be legally sufficient if it includes all eight Article 28(3) elements. Review it against the checklist in this guide before accepting it. Key areas to scrutinize are TOM specificity in Annex II, the sub-processor objection window, and the breach notification timeline. Formable's AI contract review engine can flag missing clauses automatically when you upload a vendor template for review.
