Data processing agreement for SaaS: a 2026 guide

If you run a SaaS that handles customer data — and almost every SaaS does, even when it feels like it doesn't — you're moving other people's personal data through other people's infrastructure every day. Your analytics tool. Your email provider. Your CRM. Your video testimonial platform. Each of them is, in GDPR language, a data processor handling data you're responsible for.

The document that defines what each of them can and can't do with that data is called a Data Processing Agreement, or DPA. Under GDPR it's a legal requirement whenever you share personal data with a processor. Outside the EU, it's a best practice that enterprise buyers increasingly expect. And if you've ever been asked for your own DPA during a security review, you already know: the quality of that document can make or break a deal.

This post is about DPAs from the buyer side — how to read one, what it should contain, and which red flags should end a vendor consideration.

What a DPA actually contains

A DPA is not a free-form document. It's structured around a required set of topics. The details vary; the structure doesn't.

Purpose and scope. What data is being processed, for what reason, for how long. Vague language here is the first red flag. A good DPA spells out categories of data (email addresses, IP addresses, payment details, video recordings) and maps each to a specific processing purpose.

Roles. Clearly identifies who is the data controller (usually you, the SaaS buyer, since you decide what gets processed) and who is the data processor (the vendor). In edge cases the parties may be joint controllers — the DPA should spell that out too.

Duration. The period the processor has rights to the data, and what happens at the end — return, delete, or archive.

Sub-processor list. Which third parties the processor uses to deliver the service — CDN, hosting, email vendor, support tool. This is critical, and covered in detail below.

Security measures. Concrete technical and organizational measures the processor commits to: encryption at rest, encryption in transit, access controls, incident response, employee training.

Data subject rights handling. How the processor will help you honor requests when your users exercise GDPR rights — right to access, right to erasure, right to data portability.

Data location. Where the data physically lives and where it's processed. EU-only, US-only, multiple jurisdictions. This matters because different jurisdictions carry different legal regimes.

International transfer safeguards. If the data leaves the EU, what mechanisms protect it — Standard Contractual Clauses, adequacy decisions, binding corporate rules.

Notification obligations. How quickly the processor must notify you of a data breach (72 hours is the GDPR threshold), what information they'll share, what support they'll provide during incident response.

Why your SaaS needs one from every processor

Three reasons, in descending order of how painful the consequences are.

Regulatory exposure. Under GDPR and equivalent frameworks (UK GDPR, CCPA/CPRA, LGPD), having a valid DPA with every processor is a legal obligation for the data controller. Missing one doesn't just expose the vendor. It exposes you.

Breach cascade. If your processor gets breached and you don't have a contractually-defined notification pathway, you find out late, you scramble to communicate with users, and regulators will notice the procedural gap.

Sales friction. Enterprise buyers — and increasingly mid-market — will ask for your vendor stack and their DPAs during procurement. If your answer is "we don't have one on file for that vendor," the deal gets stuck in legal review for weeks. DPAs aren't only a compliance asset. They're a sales asset.

How to evaluate a vendor's DPA

A practical checklist when a SaaS sends you their DPA for review.

• Is it up-to-date? Look for recent revision dates and references to current frameworks. A DPA citing only GDPR with no mention of Schrems II, current Standard Contractual Clauses, or UK GDPR is old.
• Is the sub-processor list specific and current? "We use third parties" is useless. You want named vendors, the purpose each is used for, and the jurisdiction each operates in.
• Is the data location explicit? "Data is processed in accordance with applicable law" is a non-answer. You want a concrete statement — EU region, US region, specific cloud provider, specific jurisdiction.
• Are the security commitments concrete? "Industry-standard security measures" is marketing copy. "Encryption at rest using AES-256, TLS 1.2 or higher in transit, role-based access control, SOC 2 Type II certification" is a DPA.
• Is the notification timeline specified? 72 hours after awareness of a breach is the GDPR standard. A DPA saying "reasonable time" is insufficient.
• Is there a clear process for data subject requests? When one of your users asks to be forgotten, how does the vendor support you in executing that, and how long does it take them?
• Is liability capped reasonably? Very low caps — "three months of fees paid" — are red flags, especially for processors holding sensitive data. Industry standard for most processors is 12 months or higher.

If three or more come back weak, negotiate the gaps before signing — or pick a different vendor.

Sub-processors and the chain of responsibility

This is where most founders get caught off guard.

When you share data with a SaaS vendor, they usually share it onward — with their cloud provider, their CDN, their email vendor, their support tool. Each is a sub-processor. Under GDPR, your DPA with the primary vendor makes you liable, at least indirectly, for the behavior of their sub-processor chain.

What to look for:

A public sub-processor list. Vendors who take this seriously publish the list at a stable URL and notify you when it changes. Vendors who don't make you ask.

Sub-processor change notifications. The DPA should require the vendor to notify you when a new sub-processor is added, and give you a window to object before the change takes effect.

Flow-down obligations. The DPA should require the vendor to bind their sub-processors to the same obligations. Otherwise the chain leaks at the second link.

For a specific case study on how sub-processors affect video-testimonial hosting and consent handling, see the GDPR and video testimonials guide.

Common red flags in SaaS DPAs

Fast-track disqualifiers when reviewing a new vendor's DPA:

• "We may use third-party service providers" with no list. You cannot do due diligence on a ghost.
• "Data is stored in multiple regions worldwide" with no specificity. You can't guarantee EU data residency to your own customers.
• "We comply with applicable law" as the entire security section. Fine as a backstop, useless as a commitment.
• Liability cap of three months of fees or less. Industry standard is 12 months or more for processors handling sensitive data.
• No data-retention clause. When you cancel, how long do they keep your data? If the DPA doesn't say, assume forever.
• No breach-notification SLA. If the commitment is "within reasonable time," assume weeks.
• No defined path for data subject requests. If the DPA doesn't describe how the vendor helps you honor erasure requests, you're on your own when a user asks.

When you're the processor, not the controller

Brief flip-side note. If your SaaS processes data on behalf of your own business customers — meaning your customers are the controllers and you're the processor — they'll ask you for your DPA. Be ready.

Your DPA should cover everything above from the processor's side: your security commitments, your sub-processor list, your data location, your notification SLAs, your support for data subject requests. Publish it at a stable URL. Make it easy for prospects to find during procurement. Update it whenever your sub-processor list changes.

Your DPA is often the first legal document an enterprise buyer reads about your company. Treat it accordingly.

Closing thought

A DPA is not a formality. It's the operational contract for the most sensitive thing you pass to a vendor — your customers' data. Treat it like any other high-trust contract: read it, question the vague parts, walk away when the answers don't hold up.

If video or other sensitive content is part of your stack, read the GDPR and video testimonials guide for a sector-specific breakdown of how DPAs, sub-processors, and consent interact.