What Is a Data Processing Agreement (DPA)?

You're closing your first enterprise deal. Everything's going well. The prospect loves your product. Legal is reviewing the contract.

Then you get the email: "We'll need a Data Processing Agreement before we can sign."

You freeze. "A what?"

Welcome to B2B SaaS compliance. If you process customer data on behalf of other businesses—especially European ones—you need a DPA.

What a DPA Actually Is

A Data Processing Agreement (DPA) is a legally binding contract between you and your customer that defines how you handle their users' personal data.

Under GDPR Article 28, if you process personal data on behalf of another business, you must have a written DPA. Without one, both parties can face significant fines.

Think of it as a promise: "Here's exactly how we'll protect your users' data, what we'll do with it, and what happens if something goes wrong."

Controller vs. Processor: The Critical Distinction

Before you can understand DPAs, you need to understand two GDPR roles:

Data Controller
The business that decides what personal data to collect and why. They determine the purpose and means of processing.

Example: An online store that collects customer names, emails, and addresses to fulfill orders is the data controller.

Data Processor
A service provider that processes personal data on behalf of the controller, following the controller's instructions.

Example: A SaaS email platform that sends marketing emails for that online store is the data processor.

Who Needs a DPA?

You need a DPA if your business is:

SaaS Platforms

• CRM systems (you store customer contact data)
• Email marketing tools (you send emails to your customer's subscribers)
• Analytics platforms (you track user behavior for your customers)
• Project management tools (you store team and client information)
• Helpdesk software (you manage support tickets containing user data)

Agencies and Service Providers

• Marketing agencies managing client email lists
• Web development agencies with access to client databases
• Virtual assistants handling customer inquiries
• Data analytics firms processing customer data

Cloud Service Providers

• Hosting companies storing customer databases
• Backup services retaining client data
• Storage platforms with user-uploaded files

If you're B2C and only process data for your own purposes, you typically don't need a DPA—just a strong Privacy Policy. But if you're B2B, DPAs become essential as you scale.

When Customers Will Ask

Most founders first encounter DPA requests when they:

Land Their First Enterprise Customer
Large companies have compliance teams that require DPAs before signing contracts. No DPA, no deal.

Serve EU-Based Customers
GDPR-aware businesses will ask for a DPA to stay compliant. Even US companies with EU employees will request one.

Go Through Security Reviews
Compliance audits often flag missing DPAs. Security questionnaires will ask: "Do you have a DPA available?"

Integrate with Large Platforms
Shopify, Salesforce, HubSpot, and similar platforms often require DPAs from integration partners.

Pursue SOC 2 or ISO 27001 Certification
Auditors will expect DPAs with all your vendors—and your customers will expect one from you.

What a DPA Must Cover

A compliant DPA includes these key sections:

Subject Matter and Duration

Defines what the agreement covers and how long it lasts (usually tied to your main service agreement).

Nature and Purpose of Processing

Clearly describes what you're processing the data for.

Example: "Processor will process personal data solely to provide email marketing services to Controller."

Types of Personal Data

Lists the categories of data you'll process:

• Contact information (names, emails, phone numbers)
• Account credentials (usernames, hashed passwords)
• Usage data (IP addresses, session logs)
• Payment information (credit card tokens, billing addresses)
• User-generated content (messages, files, documents)

Categories of Data Subjects

Who the data belongs to:

• Customers of the Controller
• Employees of the Controller
• Website visitors
• Newsletter subscribers

Processor Obligations

Your responsibilities as the processor:

• Only process data according to documented instructions from the Controller
• Ensure employees who handle data are bound by confidentiality
• Implement appropriate security measures (encryption, access controls)
• Only engage sub-processors with prior written consent
• Assist the Controller with data subject requests (access, deletion, portability)
• Notify the Controller of any data breaches within 72 hours
• Delete or return all data when the agreement ends

Security Measures

Specific technical and organizational safeguards you have in place:

• Encryption (data at rest and in transit)
• Access controls (role-based permissions, 2FA)
• Regular security audits and penetration testing
• Employee training on data protection
• Incident response procedures

Don't just say "appropriate security measures." Be specific about what you actually do.

Sub-Processors

Third-party tools and vendors you use to deliver your service.

Common sub-processors for SaaS companies:

• Cloud hosting (AWS, Google Cloud, Azure)
• Payment processing (Stripe, PayPal)
• Email delivery (SendGrid, Mailgun)
• Analytics (Google Analytics, Mixpanel)
• Customer support (Intercom, Zendesk)

You must maintain a public list of all sub-processors and notify customers before adding new ones, giving them the right to object.

Data Subject Rights

Your role in helping the Controller fulfill user requests for:

• Access to their data
• Correction of inaccurate data
• Deletion (right to be forgotten)
• Data portability (export in machine-readable format)
• Restriction of processing
• Objection to processing

You don't have to handle these requests yourself, but you must provide your customer with the tools or data to respond.

Data Breach Notification

What happens if there's a security incident:

• You must notify the Controller within 72 hours of discovering a breach
• Provide details about what data was affected
• Explain what measures you're taking to address it
• Cooperate with the Controller's investigation

Data Retention and Deletion

What happens to data after the contract ends:

• How long you can retain data
• When and how you'll delete or return data
• Exceptions for legal or backup retention

Audits and Inspections

The Controller's right to verify your compliance:

• Provide information demonstrating compliance
• Allow audits (at reasonable intervals)
• Provide access to relevant documentation

Most companies satisfy this with SOC 2 reports or third-party security certifications rather than allowing direct audits.

Standard Contractual Clauses (SCCs)

If you transfer data outside the European Economic Area (EEA), you need additional protections called Standard Contractual Clauses.

Common scenarios requiring SCCs:

• Your servers are in the US but you serve EU customers
• You use sub-processors based outside the EU (AWS US, for example)
• Your support team is based in a non-EU country

The European Commission provides pre-approved SCC templates. You can't just write your own. You must use the official templates.

Many SaaS companies append SCCs to their DPA as a separate module that activates when customers enable "EU data residency" options.

How to Prepare Your DPA

Step 1: Document Your Sub-Processors

Create a public list of every third-party service you use that touches customer data. Update this regularly.

Step 2: Map Your Data Flows

Understand what data you collect, where it's stored, who has access, and how long you retain it.

Step 3: Review Your Security Measures

Document your actual security practices. Don't promise things you don't do.

Step 4: Use a Template or Hire a Lawyer

Start with a standard DPA template (many are publicly available from companies like AWS, Stripe, or Google). Customize it for your business.

For high-stakes contracts, have a lawyer review it. Getting it wrong can cost you the deal—or worse, expose you to liability.

Step 5: Make It Easily Accessible

Host your DPA on your website (e.g., yoursite.com/legal/dpa). Make it available for download. Include it in your sales materials.

Step 6: Train Your Team

Your sales team should know what a DPA is and be able to provide it when asked. Don't let DPA requests slow down deals.

Common Mistakes to Avoid

Waiting Until a Customer Asks
Have your DPA ready before you need it. Enterprise deals move fast, and "we need two weeks to prepare that" kills momentum.

Copying Someone Else's DPA Without Customization
Your DPA must reflect your actual practices. If you promise encryption at rest but don't do it, you're liable.

Forgetting to Update Your Sub-Processor List
Every time you add a new tool (analytics, CRM, support), update your sub-processor list and notify customers.

Not Having a Process for Data Subject Requests
Your DPA promises you'll help customers respond to user requests. Have a process in place before you need it.

Ignoring International Data Transfers
If you're US-based and serve EU customers, you likely need SCCs. Don't skip this.

DPA vs. Other Legal Documents

How a DPA fits with your other legal documents:

Privacy Policy: Explains how you handle data you collect for your own purposes
DPA: Explains how you handle customer data you process on their behalf

Terms of Service: Governs the use of your product
DPA: Governs how you protect customer data while they use your product

Service Level Agreement (SLA): Promises about uptime and performance
DPA: Promises about data security and compliance

You need all of these if you're a B2B SaaS company serving enterprise customers.

When You Can Skip a DPA

You don't need a DPA if:

• You're purely B2C and only process data for your own purposes
• You don't handle any customer data on behalf of others
• You only provide software that runs entirely on the customer's infrastructure (they control all data)

But if there's any doubt, prepare a DPA. It's better to have one and not need it than to lose a deal because you don't have one ready.

The Bottom Line

A DPA isn't just a legal formality. It's a competitive advantage.

Having a well-prepared DPA signals that you're a professional, compliant, trustworthy vendor. Enterprise customers notice.

Don't wait until you need one. Prepare your DPA now, make it publicly available, and update it as your business evolves.

Your future enterprise deals will thank you.