If you’ve ever received a redline from an enterprise prospect’s legal team, you know the feeling: a wall of tracked changes, mostly in the DPA, with comments referencing provisions you’d never thought about. Most SaaS founders don’t read their own DPA until that moment. By then, you’re negotiating blind.
This post is a section-by-section walkthrough of what a DPA actually contains, what each provision does, and where the legitimate tensions between provider and customer sit. It won’t make you a privacy lawyer. It will make sure you’re never caught off guard in a procurement review.
What a DPA Is (and Isn’t)
A Data Processing Addendum is a contract that governs how you, as a SaaS provider, handle personal data on behalf of your customers. It supplements your Terms of Service and does not replace it. While your ToS governs the commercial relationship, your DPA governs the data relationship.
The legal hook is data protection law: GDPR requires a DPA whenever a controller (your customer) engages a processor (you) to handle personal data. US state privacy laws increasingly require the same. Even absent a specific legal mandate, enterprise buyers treat a well-structured DPA as a proxy for operational maturity.
The sections below follow the standard structure most enterprise buyers expect.
1. Definitions
Every DPA starts with definitions, and the definitions are doing real work. The ones that matter most:
Controller: the party that determines the purposes and means of processing personal data. Usually your customer.
Processor: the party that processes personal data on behalf of the controller. Usually you.
Processing: essentially anything done with data: collection, storage, use, disclosure, deletion. The definition is intentionally broad.
Personal data: any information relating to an identified or identifiable natural person. In a B2B context, this typically means your customer’s end users, employees, or contacts.
Sub-processor: a third party you engage to help you process the controller’s data. Your cloud provider, analytics tools, and AI APIs are almost certainly sub-processors.
The provider-friendly position here is precision: define personal data narrowly (scoped to data you actually receive), define processing to match what you actually do, and define sub-processor to cover only downstream processors, not independent controllers.
This is also why the controller/processor distinction matters beyond legal formality. Controllers bear the full weight of data protection compliance: they must establish a lawful basis for processing, respond to data subject rights requests, conduct data protection impact assessments, and face direct regulatory liability for violations. Processors have a narrower obligation: process only on instructions, maintain security, notify on breach. As a B2B SaaS provider, you’re processing your customer’s data to deliver a service they’ve defined. You don’t determine why the data exists or what business purpose it serves. You are, by design, a processor. Your DPA should make that unambiguous, because any ambiguity about your role can expose you to controller-level obligations you have no operational ability to fulfill along with regulatory liability that has nothing to do with your actual conduct.
2. Scope and Processing Instructions
This section establishes what data you’re processing, for what purpose, and under whose direction.
The standard structure includes a processing description (often in a schedule or annex) that specifies: the subject matter of processing, the duration, the nature and purpose, the type of personal data, and the categories of data subjects.
The key legal obligation: processors can only process personal data on documented instructions from the controller. In practice, this means your DPA should authorize the processing you actually do , such as providing the service, maintaining the platform, and complying with legal obligations, and exclude processing you don’t do, like using customer data to train your own models or building aggregate analytics products sold to third parties.
The provider-friendly position is broad instruction language that covers routine service delivery without requiring customer sign-off for every operational decision.
3. Security Measures
This section is where most startup DPAs go wrong. It either copies enterprise-grade commitments that don’t reflect reality, or it’s so vague it’s meaningless.
A well-structured security section commits to “appropriate technical and organizational measures” and references a schedule (usually Schedule B or Annex II) that lists those measures specifically. The measures should reflect your actual security posture: what your infrastructure provider handles, what you handle, and what you’ve implemented beyond defaults.
The provider-friendly position is describing measures at a level of abstraction that remains accurate as your stack evolves. “Encryption of personal data in transit and at rest using industry-standard protocols” is more durable than “AES-256 encryption managed by a dedicated security team.”
For more on why this section deserves its own attention, see DPA Security Measures: Don’t Promise What You Can’t Deliver.
4. Sub-processors
You almost certainly use sub-processors: AWS or GCP for infrastructure, Stripe for payments, an analytics tool, an email provider, possibly an AI API. Your DPA needs to address this.
The standard framework: you get general authorization to use sub-processors, with an obligation to notify the customer when you add new ones and a customer right to object. You’re also responsible for ensuring your sub-processors are bound by data protection obligations equivalent to those in your DPA. In practice, that means you need a DPA with every sub-processor you use, not just a terms of service click-through.
For major infrastructure and SaaS vendors, this is usually handled: AWS, GCP, Azure, Stripe, and most enterprise-grade tooling publish standard DPAs that you can execute or accept online. Before adding any vendor to your sub-processor list, you should confirm their DPA exists, covers the processing you’re engaging them for, and includes the security commitments and breach notification obligations your customer DPA requires of you. If you’ve promised your customers 48-hour breach notification, and your cloud provider’s DPA gives them 72 hours to notify you, you have a gap.
The more significant practical issue is the long tail. Founders routinely add tools, such as a new analytics platform, an AI API, or a customer support integration, without thinking through the sub-processor implications. Each one requires a DPA. Each one extends your liability chain. If that vendor suffers a breach involving your customer’s data, you’re on the hook to your customer as if the breach were your own, because you authorized that vendor’s access. The vendor’s DPA with you determines whether you have any contractual recourse against them. Many don’t offer meaningful recourse.
This is another downstream consequence of controller status worth naming explicitly. A controller using sub-processors must ensure the entire chain is contractually covered. As a processor, you share that obligation for the sub-processors you engage but your customer, as controller, bears ultimate accountability for the processing chain they’ve authorized. Clean processor status doesn’t eliminate your sub-processor obligations, but it does mean you’re not solely responsible for a data protection failure that originated with a vendor two levels removed from your customer relationship.
There are two authorization models in practice. General authorization (preferred by providers) lets you add sub-processors without pre-approval, subject to notice and objection rights. Specific authorization (preferred by enterprise customers) requires customer approval for each sub-processor. Most negotiated DPAs end up at general authorization with a reasonable objection window, typically 10 to 30 days.
The provider-friendly position is general authorization, a short objection period, and a clear process for handling objections that doesn’t give customers a unilateral right to terminate for any sub-processor change.
5. Data Subject Rights
When your customer’s end users exercise privacy rights such as access, deletion, correction, and portability, your customer typically has the legal obligation to respond. But fulfilling that obligation may require your cooperation.
This section establishes that you’ll assist the customer in responding to data subject requests, to the extent technically feasible and within your control. The provider-friendly position scopes this obligation to what you can actually do: exporting data from your platform, deleting specific records, correcting data you’ve stored. It doesn’t require you to build custom tooling on demand or respond to requests at unreasonable speed.
Practically, this means your platform should have the ability to export and delete customer data at a per-account level. If it doesn’t, that’s a gap that will surface in procurement.
6. Breach Notification
If you suffer a personal data breach affecting your customer’s data, you’re required to notify them. GDPR mandates notification “without undue delay” and generally within 72 hours of becoming aware. US state laws vary.
Your DPA should specify: what triggers notification (confirmed breach, or suspected breach too?), the timeframe, the minimum information to include, and your obligations to assist with the customer’s regulatory reporting.
The provider-friendly position sets a 48 to 72-hour notification window for confirmed breaches, limits early notification to what’s known at the time (with follow-up as investigation progresses), and scopes your assistance obligation to reasonable cooperation rather than taking over the customer’s regulatory response.
One provision founders routinely underestimate: end-customer notification obligations and who bears the cost. When a breach involves personal data your customer has collected from their own end users, your customer, as controller, is legally responsible for notifying those individuals. But enterprise DPAs are frequently drafted to push both the operational responsibility and the cost of that notification onto you as the processor. That means hiring a breach response firm, sending notification letters, standing up a call center, covering credit monitoring, and managing regulatory filings for a population of end users you have no direct relationship with and potentially no visibility into.
This is a significant and underappreciated financial exposure. A breach affecting a mid-market customer with 50,000 end users can generate notification costs alone in the hundreds of thousands of dollars, before any regulatory fines or litigation. It’s also a concrete illustration of why, as discussed in the Definitions section, you do not want to be characterized as a controller. A controller owns this entire obligation, including notification to data subjects, regulatory reporting, and breach response costs, as a matter of law, not contract negotiation. As a processor, these obligations belong to your customer. Your DPA should be explicit that end-customer notification is the controller’s responsibility, that your obligation is limited to notifying the customer promptly and providing reasonable assistance with their response, and that costs associated with notifying data subjects or engaging breach response vendors are the customer’s to bear unless the breach resulted directly from your negligence or wilful misconduct. If you’re agreeing to indemnify your customer for breach-related costs, make sure that indemnity has a cap tied to fees paid and excludes consequential damages, mirroring the same structure as your general liability framework.
7. Audit Rights
Enterprise customers want the right to audit your data protection practices. Left unconstrained, this provision is a nightmare: a customer could demand to send auditors into your office, inspect your systems, and interview your staff at their discretion.
The standard market position limits audits to: once per year, on reasonable notice (typically 30 days), during business hours, at the customer’s cost, and only after the customer has reviewed your existing certifications and reports (SOC 2, ISO 27001, penetration test summaries) and determined they’re insufficient.
The provider-friendly position goes further: audits conducted through questionnaire or review of third-party certifications as the default, with any physical or system access requiring advance notice, limited scope, and the customer bearing the cost. If you have SOC 2 Type 2, that report is your primary audit defense. The goal is to make it rare for a customer to have legitimate grounds to demand more.
8. Data Deletion and Return
When the relationship ends, what happens to the customer’s data? This section governs data retention post-termination and your obligation to return or delete personal data.
The standard approach: upon termination, you delete or return personal data within a defined period (typically 30 to 90 days), unless you’re legally required to retain it. You provide written confirmation of deletion on request.
The provider-friendly position includes a reasonable deletion period (90 days is common and gives customers time to initiate exports), limits return obligations to formats you can actually produce, and carves out anonymized aggregate data that doesn’t constitute personal data.
9. International Data Transfers
If your customer is in the EU or UK and you’re based in the US, you need a lawful mechanism to transfer personal data. The two main options are the EU-US Data Privacy Framework (DPF) and Standard Contractual Clauses (SCCs).
Most US SaaS companies incorporate SCCs into their DPA as a transfer mechanism, either as the primary mechanism or as a fallback if DPF certification lapses. SCCs are incorporated by reference (the EU Commission’s approved module text) with a brief annex specifying the parties, the data being transferred, and the security measures.
The provider-friendly position is a DPA that includes SCCs as a built-in annex, so customers don’t need to negotiate a separate transfer agreement, and that covers both controller-to-processor transfers (EU customer to US provider) and processor-to-processor transfers (you to your US-based sub-processors).
For a full breakdown, see International Data Transfers: SCCs, DPF, and What US SaaS Companies Need Now.
10. Governing Law
DPAs involving EU personal data should specify GDPR as the applicable data protection framework. For governing law and dispute resolution, the standard approach is to follow your master agreement (Terms of Service): same jurisdiction, same venue.
The one wrinkle: if your ToS says California law governs and a customer wants GDPR-governed processing terms, those aren’t in conflict. GDPR is a regulatory framework, not a contract law. Your DPA can be governed by California law while remaining GDPR-compliant.
Provider vs. Customer Positions: A Summary
| Section | Provider-Friendly | Customer-Friendly |
|---|---|---|
| Definitions | Narrow personal data scope | Broad personal data scope |
| Processing instructions | Broad service delivery authorization | Granular instruction requirements |
| Security measures | Principle-level commitments + schedule | Specific technical controls listed inline |
| Sub-processors | General authorization, short objection window | Specific authorization per sub-processor |
| Data subject rights | Commercially reasonable assistance | Strict SLAs, custom tooling obligations |
| Breach notification | 72 hours, confirmed breaches only | 48 hours, suspected breaches included |
| Audit rights | Certification review first; physical access scoped, on notice, at customer cost | Broad audit rights, annual physical inspection |
| Data deletion | 90-day deletion period post-termination | Immediate deletion on request |
| Transfers | SCCs built in as annex | Customer-negotiated SCC parameters |
The Negotiation Reality
Most enterprise DPA negotiations don’t start from scratch. Customers redline your DPA or ask you to sign theirs. Knowing your DPA’s baseline positions and where you’re willing to move is what separates a founder who closes the deal from one who’s still in legal review three months later.
The sections where you should hold firm: sub-processor authorization model, audit rights, and data deletion timelines. These have operational implications and represent your actual risk exposure.
The sections where movement is low-stakes: notification timeframes (48 vs. 72 hours is rarely material), governing law (if the customer is in the EU, accommodating EU governing law for the DPA is reasonable), and the description of security measures (if you can be more specific without overcommitting, do it).
No Boiler generates DPAs with provider-protective baseline positions across all of these sections, customized to your actual data practices based on your intake responses. You get a document that reflects what you actually do, not what a template assumes you do.
No Boiler provides self-service legal document generation and educational content. This material and our service is not a substitute for legal advice. Please have a qualified attorney review any documents before relying on them. No Boiler is not a law firm, and communications with us do not create an attorney-client relationship or carry any expectation of confidentiality. Use of our platform and content is governed by our Terms of Service and Privacy Policy.