If you’re a B2B SaaS founder and you’ve started selling to mid-market or enterprise customers, you’ve probably received this request: “Can you send us your DPA?”
If you had one ready, you sent a link and the deal kept moving. If you didn’t, you scrambled to figure out what a DPA is, what it should say, and how to get one in place before the deal stalled. Or worse, the customer sent you their DPA, and you spent weeks negotiating a document drafted entirely in their favor.
A Data Processing Addendum is one of the four core documents in your customer contracting stack. It’s the document founders understand least, enterprise customers ask for most, and the absence of which creates more deal friction than almost any other compliance gap. This post covers what a DPA is, why it exists, how it connects to your other documents, and why having one ready before anyone asks for it is one of the highest-leverage things you can do for your sales motion.
What a DPA Actually Is
A DPA is a contract between you (the data processor) and your customer (the data controller) that governs how you handle their data. It defines the scope of data processing, your security obligations, breach notification timelines, subprocessor management, data subject rights procedures, audit rights, data deletion requirements, and international transfer mechanisms.
The DPA sits alongside your Terms of Service as a separate agreement, not inside it. Your Terms of Service govern the commercial relationship: what service you provide, how billing works, what your liability exposure looks like. Your DPA governs the data processing relationship: what data you process, how you protect it, what happens when something goes wrong with the data specifically.
These are two different sets of obligations serving two different purposes. One doesn’t replace the other. A Terms of Service without a DPA leaves your data handling commitments unaddressed. A DPA without Terms of Service leaves your commercial framework undefined.
Why It Exists
The DPA exists because data protection laws require it.
Under GDPR (Article 28), a controller must have a binding contract with any processor that handles personal data on its behalf. That contract must include specific provisions about the nature and purpose of processing, the types of personal data involved, the categories of data subjects, and the obligations and rights of both parties. Without this contract, neither you nor your customer can demonstrate compliance with GDPR’s processor requirements.
Under the CCPA/CPRA, the equivalent mechanism is the service provider contract. As covered in the earlier post on the CCPA service provider framework, qualifying as a service provider (rather than a third party) requires specific contractual language that limits how you use the personal information you receive. That language typically lives in the DPA.
Beyond regulatory requirements, enterprise procurement teams treat the DPA as a primary evaluation document. When a prospect’s security or legal team reviews your vendor application, they’re checking whether you have a DPA, whether it covers the obligations they expect, and whether the commitments match their requirements. A ready-made DPA that addresses these concerns accelerates the review. A missing DPA stalls it.
What If You Don’t Have EU or UK Customers
A common assumption: “We’re US-only, so we don’t need a DPA. That’s a GDPR thing.”
This is wrong for several reasons. First, the CCPA’s service provider framework requires contractual language governing how you process personal information on behalf of your customers. If you serve California-based customers (or customers with California-based end users), that contractual language needs to exist somewhere. The DPA is where it lives.
Second, US enterprise procurement teams require DPAs regardless of whether GDPR applies. Data processing agreements have become a standard part of the vendor approval process for any company handling customer data. The request “send us your DPA” comes from US procurement teams just as often as from European ones.
Third, even if your customer base is entirely domestic today, that changes. Your first international customer, your first customer with a London or Berlin office, your first customer whose end users are scattered across the EU. When that happens, you need a DPA that satisfies GDPR requirements. Having one in place before that moment means you’re ready. Not having one means you’re retrofitting your legal stack under deal pressure.
The practical takeaway: a DPA is not just a GDPR compliance document. It’s a standard component of your customer contracting stack that addresses data processing obligations under multiple frameworks and satisfies procurement requirements regardless of where your customers are located.
What a DPA Is Not
Clearing up common misconceptions helps founders understand where the DPA fits in their document stack.
A DPA is not your privacy policy. Your privacy policy is a public-facing disclosure document that tells the world what data you collect and how you use it. Your DPA is a contractual agreement between you and a specific customer governing how you handle their data. The privacy policy discloses. The DPA commits. These documents need to be consistent with each other, but they serve fundamentally different purposes.
A DPA is not a security questionnaire. Security questionnaires (SIG, CAIQ, custom vendor assessments) ask about your security practices in a question-and-answer format. Your DPA’s security schedule (Schedule B) documents the security measures you commit to implementing. The questionnaire describes your posture at a point in time. The DPA creates a contractual obligation to maintain that posture.
A DPA is not an NDA. Confidentiality obligations in your Terms of Service or a standalone NDA protect proprietary business information. A DPA governs personal data processing under data protection law. The legal frameworks, obligations, and remedies are different.
A DPA is not optional if you process customer data. If your SaaS product handles personal data on behalf of customers (and it almost certainly does), data protection laws require a processing agreement. Having no DPA doesn’t mean you have no obligations. It means you have obligations you haven’t documented, which is worse.
The Dual Role: GDPR Processor and CCPA Service Provider
As covered in the privacy policy pillar, B2B SaaS companies are typically both a processor and a controller. Your DPA governs your processor role: the handling of customer data on behalf of your customers.
Your DPA needs to satisfy both GDPR and CCPA requirements if you serve customers in both jurisdictions. Under GDPR, you’re a “processor” and your DPA must meet Article 28 requirements. Under CCPA, you’re a “service provider” and your DPA must include the contractual language that qualifies you for that classification (purpose limitation, no secondary use, certification of compliance).
These frameworks overlap significantly but aren’t identical. A DPA drafted solely for GDPR compliance may not include the CCPA-specific provisions needed to qualify as a service provider. A DPA drafted solely for CCPA may not address all Article 28 requirements. The best practice is a single DPA that addresses both, with jurisdiction-specific annexes where needed.
What Your DPA Should Cover
At a high level, a B2B SaaS DPA addresses the following areas. Each is covered in more detail in the subsequent posts in this pillar.
Definitions. Establish the precise meaning of key terms: controller, processor, personal data, processing, data subject, subprocessor, and any jurisdiction-specific terms (business, service provider, consumer under CCPA).
Scope and instructions. Define what data you process, for what purposes, and on whose instructions. The processing should be limited to what’s necessary to provide the service as described in your Terms of Service and Order Form.
Security measures. Document the technical and organizational security measures you implement to protect customer data. This is typically structured as a separate schedule (Schedule B) that can be updated independently from the main DPA. The security measures you commit to must be ones you actually have in place. Overpromising in Schedule B creates liability exposure and audit findings.
Subprocessor management. List the third-party services that process customer data on your behalf, define the process for adding or changing subprocessors (notification timeline, customer objection rights), and commit to imposing equivalent data protection obligations on your subprocessors.
Data subject rights. Commit to assisting your customer in responding to data subject rights requests (access, deletion, correction, portability). This means your platform needs the technical capability to fulfill these requests when your customer passes them through.
Breach notification. Define the timeline and process for notifying your customer of a data breach. Under GDPR, the controller has 72 hours to notify the supervisory authority, which means your notification to the controller needs to happen fast enough for them to meet that deadline. Your DPA should specify the processor-to-controller notification timeline explicitly. Make it achievable.
Audit rights. Grant the customer the right to audit your compliance with the DPA, either directly or through a third-party auditor. In practice, most B2B SaaS companies satisfy this by providing their SOC 2 report or equivalent certification, with on-site audits reserved for specific circumstances.
Data deletion and return. Define what happens to customer data when the processing relationship ends: the export window, the deletion timeline, and whether the customer can request certification of destruction.
International transfers. If data moves across borders (from the EU/UK to the US, for example), specify the transfer mechanism: EU-US Data Privacy Framework, Standard Contractual Clauses, or both. The implementation details of transfer mechanisms in the DPA are covered in post 4.5 in this pillar.
Governing law. Specify which jurisdiction’s law governs the DPA. This may differ from the governing law in your Terms of Service, particularly if the DPA includes GDPR-specific provisions that reference EU member state law.
Why Having a DPA Ready Accelerates Sales
The DPA is where most enterprise deals stall. Not because the document is inherently complex, but because most companies don’t have one ready.
When a prospect’s procurement or security team requests your DPA and you don’t have one, several things happen. The deal pauses while you draft or source a DPA. The customer’s timeline slips. If the customer loses patience, they send you their DPA, which is drafted to protect them and may include commitments you can’t or shouldn’t accept. You spend weeks negotiating a document you could have had ready in advance.
When you have a DPA ready, the dynamic changes entirely. The request comes in, you send a link. The procurement team reviews a document that anticipates their requirements. The review becomes a confirmation exercise rather than a negotiation. The deal keeps moving.
This is the same “bring your own paper” principle from the first post in this series. If you don’t have a DPA ready, you end up on the customer’s paper. Their DPA will include security commitments calibrated to their enterprise vendor requirements (not your actual capabilities), breach notification timelines that may be more aggressive than you can meet, audit provisions that give them broad access rights, and liability exposure that may not be bounded by your Terms of Service limitation of liability.
Every one of those provisions is a negotiation point. Every negotiation point adds time. And every week the deal sits in legal review is a week you’re not generating revenue from that customer.
The DPA and Your Document Stack
Your DPA doesn’t operate in isolation. It’s one component of an integrated document stack that needs to be internally consistent.
Your Terms of Service should incorporate the DPA by reference. The DPA’s security commitments should align with what your SOC 2 report describes. Your DPA’s data sharing and subprocessor provisions should be consistent with your privacy policy’s third-party disclosures. Your DPA’s liability provisions should reference (and be subject to) the limitation of liability in your Terms of Service. If you’ve followed the confidentiality drafting guidance from the Terms of Service pillar, customer data should be governed by the DPA, not the confidentiality section.
When these documents work together, they tell a consistent story to procurement teams, auditors, and (if it ever comes to it) opposing counsel. When they contradict each other, every inconsistency is a potential liability.
The subsequent posts in this pillar go deeper into each component of the DPA: the section-by-section anatomy (4.2), security measures and Schedule B (4.3), subprocessor management (4.4), and the implementation of international transfer mechanisms (4.5).
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.
This is the first post in the DPA pillar. Next up: DPA Anatomy: What Each Section Means and Why It Matters. Related: The B2B SaaS Legal Stack: What You Actually Need · The CCPA Service Provider Framework · GDPR as a B2B SaaS Company Without EU Operations.