The Practical Guide to Data Processing Agreements
A Plain-English Primer for Reviewing and Negotiating DPAs with Confidence
How to Use This Guide
If you:
- Work in product, sales, operations, procurement, security, or finance
- Occasionally get handed a DPA to "review"
- Don't live in privacy law every day
- Want to avoid signing something risky
This guide is for you.
You don't need to become a privacy lawyer. You just need to:
- Understand what a DPA is doing.
- Recognize common obligations.
- Spot risky clauses.
- Know when to escalate.
1. What Is a Data Processing Agreement?
A Data Processing Agreement (DPA) is a contract that governs how one company processes personal data on behalf of another.
More formally:
- A controller decides why and how personal data is used.
- A processor processes that data on the controller's behalf.
A DPA exists to:
- Allocate responsibilities.
- Ensure compliance with privacy laws (GDPR, CCPA, etc.).
- Define security obligations.
- Clarify liability if something goes wrong.
When Does a DPA Show Up?
- You provide SaaS to customers.
- You host customer data.
- You process payroll for another company.
- You manage marketing campaigns.
- You provide cloud infrastructure.
If you touch personal data on behalf of someone else, a DPA is likely required.
2. Core Roles and Definitions
Controller
The company that decides what data to collect, why, and how it will be used.
Processor
The company that processes data for the controller. Example: A SaaS analytics provider processing customer usage data.
Sub-Processor
A third party hired by the processor. Examples: AWS hosting, Stripe payments, Zendesk support.
Personal Data
Any information relating to an identifiable person — name, email, IP address, device ID, employee ID.
Special Category Data (Sensitive Data)
Data with heightened protection: health information, biometric data, racial/ethnic origin, religious beliefs.
These definitions are foundational. Most DPA disputes stem from confusion about roles.
3. When Do You Actually Need a DPA?
You likely need a DPA if:
- You store or access customer end-user data.
- You process employee data for another company.
- You use third-party cloud services in your solution.
- You're operating in the EU, UK, or serve EU/UK customers.
Quick Self-Test
- Do we determine the purpose of the data? → You're probably a controller.
- Do we just process it according to customer instructions? → You're likely a processor.
Sometimes you're both (for different data types). That's common.
4. The Anatomy of a DPA
Most DPAs follow a predictable structure:
- Definitions
- Scope of processing
- Roles and responsibilities
- Processor obligations
- Security measures
- Sub-processors
- Data subject rights assistance
- Breach notification
- International transfers
- Audit rights
- Liability and indemnification
- Term and termination
- Data return or deletion
Once you understand this structure, DPAs become much less intimidating.
5. Processor Obligations: The Core Commitments
If you're the processor, this is your main responsibility section.
1. Process Only on Instructions
You must follow documented instructions from the controller. Risk area: if instructions are vague, disputes can arise.
2. Confidentiality
Your personnel must be bound by confidentiality. This is standard and non-controversial.
3. Implement 'Appropriate' Security Measures
Encryption, access controls, MFA, logging, incident response, vendor risk management.
4. Assist with Data Subject Requests
Controllers must respond to access, deletion, and correction requests. Processors must assist when technically feasible.
5. Breach Notification
You must notify the controller 'without undue delay.' Be careful with aggressive deadlines — a 24-hour obligation can be operationally risky.
6. Delete or Return Data at Termination
You must return or delete data, and possibly certify deletion. Always check how backups are handled.
6. Controller Obligations
Controllers have obligations too:
- Provide lawful basis for processing.
- Ensure data subjects are informed.
- Respond to data subject requests.
7. Security Schedules (TOMs)
Most DPAs include a security appendix covering:
- Access management controls
- Physical security
- Encryption standards
- Disaster recovery & business continuity
- Penetration testing
- Certifications (SOC 2, ISO 27001)
Key Risk Insight
Too vague → Hard to prove compliance. Too specific → Locked into tools or methods.
Balanced language includes: risk-based approach, industry standards, flexibility for evolution.
8. Sub-Processors
One of the most negotiated sections.
General vs Specific Authorization
- General → You can add sub-processors with notice.
- Specific → Controller must approve each one (operationally difficult for SaaS).
Objection Rights
Watch for automatic termination rights and unrealistic timelines.
Liability
Processors remain fully liable for sub-processors' actions. This is standard.
9. International Data Transfers
If data crosses borders (e.g., EU → US), additional safeguards apply:
- Standard Contractual Clauses (SCCs)
- UK Addendum
- EU–U.S. Data Privacy Framework
Confirm: What mechanism is being used?
10. Breach Notification
This section can create serious operational pressure. Typical components: definition of breach, timeline, required content of notice, ongoing cooperation.
Example of risky language:
"Processor shall notify Controller within 24 hours of becoming aware of any suspected breach."
"Suspected" can create chaos. More balanced language refers to confirmed incidents.
11. Audit Rights
Controllers often request audit rights including on-site, annual, third-party audits, and security questionnaires.
Best practice for processors:
- Allow audit via third-party reports (e.g., SOC 2).
- Limit frequency (e.g., once per year).
- Require reasonable notice.
- Allocate costs appropriately.
Unlimited audit rights are a red flag.
12. Liability & Indemnification
This is where financial exposure lives. Watch for:
- Unlimited liability for data protection breaches.
- Indemnity for regulatory fines.
- Liability outside the MSA cap.
Always confirm:
- Does the DPA follow the MSA liability cap?
- Or does it carve out privacy from limitations?
13. Termination and Data Deletion
At contract end: data must be returned or deleted, backups may be retained for limited periods, and deletion certification may be required.
Watch for:
- Unrealistic deletion timelines.
- Conflicts with legal retention requirements.
14. Common Negotiation Pressure Points
Most frequently negotiated clauses:
- Audit rights
- Breach notification timing
- Liability caps
- Indemnification
- Sub-processor objection rights
- Security commitments
Large enterprises often push for unlimited liability, aggressive breach timelines, and broad audit rights. Startups often concede too quickly. Understand your leverage.
15. Common Red Flags
- • Unlimited liability.
- • Indemnification for all regulatory fines.
- • 24-hour breach notice regardless of confirmation.
- • Open-ended audit rights.
- • Strict liability standards.
- • "Processor shall comply with all laws globally."
- • Undefined "state-of-the-art" obligations.
If you see two or more of these, escalate internally.
16. How to Review a DPA in 30 Minutes
A practical workflow:
- Confirm Roles — Are you clearly designated as processor?
- Check Scope — Does the processing description match reality?
- Review Liability — Is liability capped? Is privacy carved out?
- Review Breach Timeline — Is it realistic?
- Review Audit Rights — Are they limited and structured?
- Review Sub-Processor Section — Is authorization general? Is objection manageable?
- Review Security Appendix — Is it aligned with actual practice?
- Confirm Termination Mechanics — Can you operationally comply?
If anything feels disproportionate, escalate.
17. DPA vs Data Sharing Agreement vs BAA
| Agreement Type | When Used | Key Focus |
|---|---|---|
| DPA | Controller → Processor | Processing on instructions |
| Data Sharing Agreement | Controller ↔ Controller | Shared control |
| BAA (HIPAA) | Healthcare context | PHI handling |
18. Frequently Asked Questions
Can we refuse a customer's DPA?
Yes. Many vendors require customers to use the vendor's template instead.
Do we need separate DPAs per country?
Often no — global addenda can cover multiple regions.
Does a DPA replace a privacy policy?
No. A DPA governs B2B processing. A privacy policy addresses individuals.
What happens if there's no DPA?
Regulatory non-compliance risk. Also potential contractual disputes.
19. Glossary (Plain English)
- Processing
- Any operation performed on data.
- DPIA
- Risk assessment for high-risk processing.
- TOMs
- Technical and organizational measures.
- SCCs
- EU-approved transfer clauses.
- Supervisory Authority
- Data protection regulator.
20. Final Practical Takeaways
You don't need to be a privacy expert to review a DPA. You need to:
- Understand roles.
- Recognize core obligations.
- Identify disproportionate risk.
- Escalate intelligently.
A good DPA is balanced — it protects both parties and reflects operational reality.
When reviewing, always ask:
- Can we operationally comply?
- Is the risk proportional to the contract value?
- Does this align with our security posture?
- Does liability follow our MSA?