If you run a SaaS company that handles customer data, you need a Data Processing Agreement. Not eventually. Not when you start selling to enterprise clients. Now. A DPA defines what you can and cannot do with the data your customers entrust to you, and it determines who is liable when something goes wrong.
In 2026, DPAs are no longer just a GDPR requirement for companies doing business in Europe. Twenty US states now have comprehensive privacy laws, and most of them require written agreements between businesses that share personal data. Your mid-market and enterprise prospects already expect a DPA before they sign your contract. If you do not have one, you lose the deal. If you have the wrong one, you take on liability you never intended.
This article explains what a DPA is, when you need one, what it must contain, and why the template you downloaded last year is probably creating more problems than it solves.
1. What a Data Processing Agreement Actually Is
A Data Processing Agreement is a legally binding contract between a data controller (the company that decides why and how personal data is processed) and a data processor (the company that processes personal data on the controller’s behalf). If you are a SaaS company, you are almost always the processor. Your customer is the controller.
The DPA specifies the scope, purpose, and duration of data processing. It defines what types of personal data you will handle, whose data it is (your customer’s end users, employees, or clients), and what you are permitted to do with that data. It also establishes security requirements, breach notification timelines, and what happens to the data when the contract ends.
A DPA is distinct from your main SaaS agreement. Your SaaS agreement covers the commercial relationship: pricing, service levels, intellectual property, and liability. Your DPA covers the data relationship: how personal data flows, who is responsible for protecting it, and what happens if it is compromised. Most SaaS companies attach the DPA as an addendum to their main agreement, but the DPA must be a standalone, enforceable document.
2. When You Need a DPA
Under GDPR, you need a DPA any time you process personal data on behalf of an EU or UK data subject. That means if even one of your customers has European users whose data passes through your platform, GDPR Article 28 requires a DPA.
But GDPR is no longer the only law that requires data processing agreements. As of 2026, twenty US states have enacted comprehensive privacy laws, and most of them require written contracts between controllers and processors. California, Colorado, Connecticut, Virginia, Texas, Oregon, Montana, and a dozen other states all mandate some form of data processing contract. The specific requirements vary by state, but the core obligation is the same: if you process personal data on someone else’s behalf, you need a written agreement that defines your obligations.
Beyond legal requirements, DPAs have become a practical sales prerequisite. Enterprise and mid-market buyers include DPA review in their procurement process. Their legal teams will redline your DPA before their business team signs your contract. If you do not have a DPA, or if your DPA is clearly a generic template, you signal that you have not thought seriously about data protection. That can kill deals with exactly the customers you want most.
3. Mandatory Clauses Under GDPR Article 28
GDPR Article 28 lists specific provisions that every DPA must include. Missing any of these makes your DPA non-compliant, regardless of how thorough the rest of the document is.
The DPA must state that you process personal data only on documented instructions from the controller. You cannot use the data for your own purposes, train your own models on it, or analyze it for insights you sell separately. If your SaaS product does any of these things, the DPA must disclose it and obtain the controller’s specific consent.
You must impose confidentiality obligations on every person who has access to the personal data. This includes your employees, contractors, and anyone else who touches customer data. The DPA must state that these individuals are bound by confidentiality agreements or statutory obligations.
The DPA must describe the technical and organizational security measures you implement to protect the data. This is not a place for vague promises. Regulators expect specifics: encryption standards, access controls, logging and monitoring, incident response procedures, and regular security testing. Your security measures should match or exceed what a reasonable company in your industry would implement given the sensitivity of the data.
You must include provisions for subprocessor management, data subject rights assistance, breach notification, audit rights, and data deletion or return upon contract termination. Each of these is covered in more detail below.
4. US State Privacy Law DPA Requirements
US state privacy laws do not use identical language, but they converge on similar requirements for processor agreements. Most state laws require the following provisions in any contract between a controller and processor.
The contract must specify the nature and purpose of the processing, the type of personal data involved, and the duration of the processing. The processor must agree to follow the controller’s instructions and not process data for any other purpose. The processor must delete or return personal data at the controller’s request or upon termination of the agreement.
Several states, including California under the CPRA, require processors to agree not to sell or share personal data they receive from controllers. This seems obvious, but many SaaS companies inadvertently violate this requirement by using customer data for product analytics, benchmarking, or training machine learning models. If your DPA does not explicitly address these activities, you may be breaching your contractual obligations without realizing it.
The practical effect is that you need a DPA that works across multiple state laws simultaneously. Drafting to the strictest standard (currently a combination of GDPR and CPRA requirements) will generally satisfy all applicable laws, but each new state law introduces the possibility of a unique requirement that your existing DPA does not cover.
5. Controller vs. Processor: Understanding Your Role
Your role in the data processing relationship determines your legal obligations. As a SaaS company, you are typically a processor: you handle personal data according to your customer’s instructions. Your customer is the controller: they decide what data to collect, why, and how.
But this distinction is not always clean. If you use customer data to improve your own product, generate aggregate analytics, or train AI models, you may be acting as a controller for those activities. That changes your legal obligations and your liability exposure significantly. A controller faces direct regulatory enforcement and data subject claims. A processor’s liability is generally limited to its own failures to follow instructions and implement security measures.
Your DPA must accurately reflect which role you play for each processing activity. If you are a processor for hosting customer data but a controller for product analytics, the DPA should say so clearly. Misclassifying your role does not reduce your liability. It just means your DPA is inaccurate, which creates additional legal exposure.
6. Subprocessor Chains and Your Responsibility
Almost every SaaS company uses subprocessors: third-party services that process personal data on your behalf. Your cloud hosting provider, email delivery service, payment processor, analytics platform, and customer support tools are all subprocessors if they have access to your customers’ personal data.
Under GDPR, you must obtain the controller’s authorization before engaging a subprocessor. You can do this through specific prior authorization (naming each subprocessor and getting approval) or general authorization (maintaining a list and giving the controller the right to object when you add new subprocessors). Most SaaS companies use general authorization, which requires maintaining an up-to-date list of subprocessors and notifying customers before adding new ones.
You are responsible for your subprocessors’ compliance. If your cloud provider suffers a data breach, you are the one your customer holds accountable under the DPA. Your DPA with your customer must include the subprocessor provisions, and your contracts with your subprocessors must impose equivalent data protection obligations. This creates a chain of accountability that regulators enforce aggressively.
Many SaaS companies fail to realize how long their subprocessor chain is. Audit every third-party service that touches customer data. Map the data flows. Then make sure your DPA’s subprocessor list is complete and your downstream contracts include the required protections.
7. Breach Notification and Incident Response
Your DPA must specify how quickly you will notify the controller if you discover a personal data breach. GDPR requires notification “without undue delay” after becoming aware of a breach affecting personal data. Most DPAs translate this to a specific hour count, typically 24 to 72 hours.
The notification must include the nature of the breach, the categories and approximate number of data subjects affected, the likely consequences, and the measures you are taking to address the breach. Vague notifications like “we experienced a security incident” do not satisfy the requirement.
US state privacy laws add their own notification timelines, which vary from 30 to 72 hours depending on the state. Your DPA should commit to the shortest timeline that applies to your customer base, so you are covered regardless of which state law governs a particular incident.
8. Common DPA Mistakes That Create Liability
The most common mistake is using a DPA template without modifying it to match your actual data practices. Templates use generic language about processing activities, security measures, and subprocessors. If your DPA says you implement “industry-standard encryption” but you actually use outdated TLS versions, the DPA itself becomes evidence of your failure to meet your own commitments.
Another frequent mistake is failing to list all subprocessors. If your DPA names five subprocessors but you actually use fifteen, you are in breach of your DPA every time a customer’s data passes through an undisclosed subprocessor. This is not a technicality. Enterprise customers audit subprocessor lists, and discovering undisclosed subprocessors is grounds for contract termination.
Many SaaS companies also mishandle the data deletion clause. Your DPA likely says you will delete customer data upon contract termination. But do you actually have the technical ability to do that across all systems, backups, logs, and subprocessors? If your DPA promises deletion within 30 days but your backup retention policy keeps data for 90 days, you have a compliance gap.
Finally, many DPAs fail to address the limitation of liability for data processing specifically. Your main SaaS agreement may cap liability at the fees paid in the prior 12 months, but your DPA may have its own liability provisions, or it may be silent on the issue. If the DPA does not address liability, the controller may argue that the cap in your SaaS agreement does not apply to data processing claims. Get this right in the drafting stage.
9. What a Technology Lawyer Handles That Templates Cannot
A technology lawyer who works with SaaS companies will map your actual data flows before drafting a single clause. That means identifying every type of personal data you process, every system it touches, every subprocessor in the chain, and every jurisdiction whose laws apply. The DPA is then built around your real operations, not a hypothetical business.
Your lawyer will also negotiate DPAs with enterprise customers who send their own versions. Enterprise DPAs are often heavily weighted in favor of the controller, with unlimited liability, unreasonable audit rights, and breach notification timelines that are operationally impossible. A lawyer who understands SaaS economics can negotiate terms that protect your interests while satisfying the customer’s compliance requirements.
As US state privacy laws continue to multiply, your DPA needs to evolve. A lawyer who tracks new state laws can update your DPA proactively, before a new law takes effect, rather than leaving you to discover gaps after a customer or regulator points them out.
Frequently Asked Questions
Is a DPA the same as a terms of service or a privacy policy?
No. A DPA is a business-to-business agreement between a data controller and a data processor. Your terms of service govern the relationship between your company and your end users. Your privacy policy tells end users how you handle their data. Your DPA tells your business customers how you handle the data they entrust to you. All three documents serve different purposes and are required by different legal frameworks. A SaaS company typically needs all three.
Do I need a DPA if all my customers are in the United States?
Yes, in most cases. Twenty US states now have privacy laws that require written contracts between controllers and processors. If your customers or their end users are located in any of those states, you need a DPA. Even if you operate in a state without a privacy law, your customers in regulated states will require a DPA as part of their own compliance obligations. Practically speaking, every SaaS company serving US business customers needs a DPA in 2026.
Can I use the same DPA for GDPR and US state privacy law compliance?
You can, but it requires careful drafting. GDPR and US state laws have overlapping but not identical requirements. A DPA drafted to the strictest standard across both frameworks can work as a single document, but it must explicitly address the requirements unique to each framework. Many SaaS companies use a single DPA with annexes or schedules that address jurisdiction-specific requirements. A generic template drafted solely for GDPR will not satisfy US state law requirements without modification.
What happens if I do not have a DPA and there is a data breach?
Without a DPA, you have no contractual framework defining your responsibilities, notification timelines, or liability limits. Your customer can pursue claims under general contract law, negligence, and applicable privacy statutes. Regulators in both the EU and US can impose penalties for processing personal data without a required agreement in place. The absence of a DPA also signals to regulators that your data protection program is deficient, which can increase the severity of any enforcement action.
How do I handle DPA requests from enterprise customers who send their own version?
Review the customer’s DPA carefully before signing. Enterprise DPAs often include provisions that are unreasonable for a SaaS company, such as unlimited liability for data processing claims, the right to conduct on-site audits at any time, or breach notification within an operationally impossible timeframe. You should negotiate these terms just as you would negotiate the commercial terms of the deal. Starting with your own DPA and marking up the customer’s version against it gives you a clear view of where the gaps are.
Get a DPA Built for Your SaaS Business
A Data Processing Agreement is not a box to check. It is a binding contract that defines your data handling obligations, shapes your liability exposure, and directly affects your ability to close enterprise deals. A poorly drafted DPA can cost you more than not having one at all.
Hansen Tong and the team at TOS Lawyer draft and negotiate DPAs specifically for SaaS companies. That means agreements built around your actual data flows, your real subprocessor chain, and the privacy laws that apply to your customer base. Whether you need a DPA from scratch or need to overhaul a template that is not working, contact TOS Lawyer to get a DPA that protects your business and closes deals.