If you run a SaaS company that handles customer data, you need a Data Processing Agreement. Not eventually. Not when your next enterprise customer asks for one. Right now, before your next customer signs up and before your next renewal conversation.
In 2026, DPAs are no longer just a GDPR requirement for companies doing business in Europe. Twenty US states now have comprehensive privacy laws that require processor agreements, and enterprise buyers have made DPAs a standard contract requirement regardless of geography. If you do not have a DPA, you are losing deals and accumulating legal liability at the same time.
This article explains what a DPA is, when you need one, what it must contain, and why the template you downloaded last year probably does not protect you.
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 behalf of the controller). In most SaaS relationships, your customer is the controller and you are the processor.
The DPA specifies the scope, purpose, and duration of data processing. It defines what types of personal data you will handle, what you are permitted to do with it, what security measures you maintain, how you handle data subject rights requests, and how you notify the controller of data breaches. It is a contract specifically about data, not about the commercial relationship.
A DPA is distinct from your main SaaS agreement. Your SaaS agreement covers the commercial relationship: pricing, service levels, IP ownership, and liability. Your DPA covers the data relationship. Both are necessary. Many SaaS companies try to address data processing in their main agreement or their privacy policy, but neither of those documents satisfies the legal requirements for a DPA.
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' end users is located in the EU or UK, GDPR's DPA requirements apply to your relationship with that customer. For most SaaS companies serving global markets, this means GDPR applies to essentially all customer relationships.
But GDPR is no longer the only law that requires data processing agreements. As of 2026, twenty US states have enacted comprehensive privacy laws, including California (CPRA), Virginia (VCDPA), Colorado, Connecticut, Texas, and others. Each of these laws requires controllers to enter into contracts with processors that contain specific provisions. The required provisions overlap substantially with GDPR Article 28 requirements but are not identical.
Beyond legal requirements, DPAs have become a practical sales prerequisite. Enterprise and mid-market buyers include DPA review as a standard part of vendor due diligence. Procurement teams and security officers increasingly will not sign off on a new SaaS vendor without a completed DPA. If you cannot produce a DPA on short notice, you are losing deals to competitors who can.
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, which means it does not satisfy your customers' GDPR obligations and exposes both you and your customers to regulatory risk.
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 models on it, or share it with third parties without the controller's written authorization. This seems obvious, but many SaaS companies have terms that broadly license customer data for product improvement purposes, which conflicts with this requirement.
You must impose confidentiality obligations on every person who has access to the personal data. This includes your employees, contractors, and any subprocessors. The DPA should specify that authorized personnel are bound by confidentiality as a condition of their access.
The DPA must describe the technical and organizational security measures you implement to protect the data. This is not a generic security statement. It needs to describe actual measures: encryption standards, access controls, network security, incident detection capabilities, and employee security training.
You must include provisions for subprocessor management, data subject rights assistance, breach notification, audit rights for the controller, and instructions for deletion or return of data at the end of the processing relationship. Each of these is a substantive legal obligation, not boilerplate.
US State Privacy Law DPA Requirements
US state privacy laws do not use identical language, but they converge on similar requirements for processor agreements. Understanding the common requirements allows you to draft a DPA that covers the most important states without needing a separate agreement for each jurisdiction.
The contract must specify the nature and purpose of the processing, the type of personal data involved, and the duration of the processing. This mirrors GDPR's requirements but is now a US law obligation as well. Many companies have GDPR-compliant DPAs but fail to meet this requirement because their DPA was drafted before US state laws passed and was never updated.
Several states, including California under the CPRA, require processors to agree not to sell or share personal data they process on behalf of a controller, not to use that data for their own commercial purposes, and to cooperate with the controller's compliance obligations. These provisions need to be explicit in the DPA, not implied.
The practical effect is that you need a DPA that works across multiple state laws simultaneously. Drafting to the strictest requirements (GDPR plus California CPRA) generally satisfies most other US state requirements, but a privacy policy lawyer familiar with the current state law landscape can confirm compliance for the states where your customers are concentrated.
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 for your customers' personal data: you handle it on their behalf, according to their instructions, for purposes they define. Your customers are controllers.
But this distinction is not always clean. If you use customer data to improve your own product, generate aggregate analytics that you sell or use for your own business purposes, or make independent decisions about how personal data is processed, you may be acting as a controller for some processing activities. Controllers have significantly more compliance obligations than processors.
Your DPA must accurately reflect which role you play for each processing activity. If you are a processor for hosting customer content but a controller for your own analytics, you need a DPA that clearly separates these roles and limits your processor obligations to the data you process on the customer's behalf. Getting this distinction wrong creates legal exposure under GDPR and US state laws.
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, your customer support platform, your email delivery service, your analytics tools — each of these is a subprocessor if it has access to personal data from your customers.
Under GDPR, you must obtain the controller's authorization before engaging a subprocessor. You can do this through specific authorization (naming each subprocessor) or general authorization (publishing a list of subprocessors and notifying customers of changes). Most enterprise customers require specific authorization and will push back on broad general authorization provisions.
You are responsible for your subprocessors' compliance. If your cloud provider suffers a data breach, you are the one your customers will hold responsible under the DPA. This means you need DPAs with each of your subprocessors that impose equivalent data protection obligations. A chain of DPAs from controller to processor to subprocessor is required for full legal compliance.
Many SaaS companies fail to realize how long their subprocessor chain is. Audit every third-party service that touches customer data and ensure each one has a DPA in place. This audit often reveals surprising results: customer support tools, live chat platforms, error monitoring services, and marketing analytics tools frequently have access to personal data that companies did not consciously grant them.
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 to the controller "without undue delay" so the controller can meet its 72-hour notification obligation to supervisory authorities. In practice, this means your DPA should commit to notifying the controller within 24-48 hours of discovering a breach.
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 have taken or propose to take to address the breach. Your incident response plan needs to be designed to gather this information quickly so you can meet the notification timeline.
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 most demanding timeline (24-48 hours) to ensure compliance across all applicable laws. Your incident response procedures need to be aligned with this commitment.
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 that may not accurately describe what you actually do with customer data. A DPA that says you "use industry-standard encryption" when you do not, or that you "maintain SOC 2 Type II certification" when you have not completed the audit, creates contractual liability the moment a customer discovers the discrepancy.
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 the DPA's subprocessor disclosure requirement. Customers who conduct security reviews will find the discrepancy, and regulators who investigate breaches will as well.
Many SaaS companies also mishandle the data deletion clause. Your DPA likely says you will delete customer data upon contract termination. But if your backup retention policy keeps data for 90 days after termination, your practice contradicts your contract. Either align your retention policy with your DPA or update your DPA to accurately describe your retention and deletion practices.
Finally, many DPAs fail to address the limitation of liability for data processing specifically. Your main SaaS agreement likely caps your liability at one year of fees. But a data breach affecting thousands of customers could generate regulatory fines and customer claims that far exceed that cap. Ensure your liability provisions address data breaches specifically and that you have appropriate cyber liability insurance to cover exposure above the contractual cap.
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 mapping identifies every category of personal data you process, every subprocessor that touches it, and every transfer mechanism you use. The DPA is then drafted to match reality, not a generic template.
Your lawyer will also negotiate DPAs with enterprise customers who send their own versions. Enterprise DPAs are often heavily one-sided in the customer's favor, with liability provisions, audit rights, and notification timelines that go well beyond what you can operationally support. A technology lawyer can identify which provisions are acceptable and which need to be negotiated, and can push back effectively without jeopardizing the commercial relationship.
As US state privacy laws continue to multiply, your DPA needs to evolve. A lawyer who tracks new state laws can update your DPA as new requirements come into effect, so you are not scrambling to update your agreements every time a new state law passes.
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. A privacy policy is a public-facing document that tells users how you handle their data. Terms of service govern the commercial relationship between your company and your customers. All three serve different purposes and none can substitute for the others.
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 processor agreements. If your customers are based in California, Virginia, Colorado, Connecticut, Texas, or any of the other states with comprehensive privacy laws, those laws require you to have a DPA-equivalent agreement in place. The requirements are slightly different from GDPR but the substance is similar.
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 use different terminology and have some different requirements. A well-drafted DPA can satisfy both by addressing the requirements of each law explicitly. Many SaaS companies use a single DPA with state law addenda that address jurisdiction-specific requirements. A privacy lawyer can draft a DPA structure that works across all applicable laws.
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 notification obligations, your liability, or your responsibilities in responding to the breach. Your customer cannot meet their own regulatory notification obligations without information from you. Regulators investigating the breach will find the absence of a DPA as evidence of inadequate data governance. Your customer will likely have breach of contract claims in addition to any statutory claims. The absence of a DPA amplifies every other consequence of a breach.
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 you cannot operationally support, such as notification timelines of 12 hours, unlimited audit rights, or liability provisions that exceed your insurance coverage. Have a technology lawyer review the customer's DPA and prepare a redline that accepts reasonable provisions while pushing back on operationally unworkable ones. Most enterprise customers expect negotiation and will accept reasonable modifications.
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, your liability exposure, and your relationship with every customer whose data you process. Getting it right requires understanding your actual data practices, not copying a template.
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 subprocessors, your security measures, and the specific laws that apply to your customers. Contact TOS Lawyer to get a DPA that protects your business and satisfies your customers' compliance requirements.