What Is a Data Processing Agreement and When Does Your Business Need One?
Your business collects personal data. You share it with a payment processor, a cloud hosting provider, an email marketing tool, or an analytics platform. Each of those handoffs creates a legal relationship that your privacy policy does not cover on its own. That gap is where a data processing agreement comes in, and for many businesses operating under GDPR, CCPA, or CPRA, that gap carries real legal liability.
A data processing agreement is not optional paperwork. It is a binding contract between your company and any third party that processes personal data on your behalf. Without one, you are exposed to regulatory fines, breach liability, and loss of your customers’ trust. With a poorly drafted one, you are exposed to the same risks.
This guide explains what a data processing agreement must include, when your business is legally required to have one, and what a specialist technology lawyer reviews before you sign anything that touches your users’ data.
1. What a Data Processing Agreement Actually Is
A data processing agreement, commonly called a DPA, is a contract between a data controller and a data processor. The data controller is your business, the entity that decides what personal data is collected and why. The data processor is any third party that handles that data on your instructions.
Examples of data processors your business almost certainly uses: cloud storage providers like AWS or Google Cloud, email platforms like Mailchimp, CRM tools like Salesforce, payment gateways, analytics services, customer support software, and any SaaS tool your team uses to handle customer records.
The DPA sets out exactly what data each processor can access, what they are permitted to do with it, how they must protect it, and what happens if something goes wrong. Without a DPA in place, there is no documented chain of accountability for personal data that leaves your direct control.
2. When Is a Data Processing Agreement Legally Required?
Under the European Union’s General Data Protection Regulation (GDPR), a DPA is mandatory any time a data controller engages a data processor. Article 28 of the GDPR specifies that processing by a processor must be governed by a contract setting out the subject matter, duration, nature, and purpose of the processing, the type of personal data, and the obligations and rights of the controller.
If your business serves users in the European Union or EEA, even from a US base, GDPR applies. That means every data-sharing arrangement you have with a third-party processor requires a compliant DPA. No exceptions based on company size or revenue.
Under the California Consumer Privacy Act (CCPA) and its amendment, the California Privacy Rights Act (CPRA), businesses are required to enter into contracts with service providers that restrict how they use personal information. While the CPRA’s contract requirements differ in structure from GDPR’s Article 28, the practical outcome is similar: a written agreement is required when you share personal data with a service provider for business purposes. You can review our detailed breakdown of CCPA and CPRA requirements for 2026 for more on the California-specific obligations.
Beyond GDPR and California, state privacy laws in Virginia, Colorado, Connecticut, Texas, and other US states have introduced similar contractual requirements. If your business serves customers in multiple states, the assumption should be that a DPA is required, not that one might be optional.
3. What a Data Processing Agreement Must Include
A compliant DPA is not a one-page form. These are the core provisions a data processing agreement must address to meet GDPR Article 28 requirements and align with US state privacy law obligations.
Subject Matter, Duration, and Purpose
The DPA must specify what personal data is being processed, why it is being processed, and for how long the processing arrangement lasts. Vague language here creates compliance gaps. Defining the processing purpose also limits what the processor can do with the data, which is critical protection for your business and your users.
Processing Instructions
The processor must only process personal data on your documented instructions. The DPA must state this explicitly and include a clause requiring the processor to notify you if any instruction violates applicable law. This creates a legally binding record that the processor cannot repurpose your users’ data for their own ends.
Confidentiality Obligations
All personnel with access to the personal data must be bound by confidentiality obligations. The DPA must confirm this is in place at the processor level, not just assumed.
Security Measures
The processor must implement appropriate technical and organizational security measures. The DPA should specify the security standard or at minimum reference a recognized framework such as ISO 27001 or SOC 2. Vague references to “reasonable security” do not satisfy regulatory requirements and do not protect you if a breach occurs.
Subprocessor Rules
Your processor will almost certainly use subprocessors. Cloud vendors use their own tools; SaaS platforms use third-party payment or analytics services. The DPA must require that the processor gets your authorization before engaging subprocessors and must impose the same data protection obligations on those subprocessors. This chain of accountability matters during a data breach investigation.
Data Subject Rights Assistance
When your users exercise their rights under GDPR or CCPA, such as requesting access to their data or asking for deletion, your processors must assist you in fulfilling those requests. The DPA must obligate processors to cooperate with these rights requests and do so within the timeframes applicable law requires.
Breach Notification
The processor must notify you without undue delay if they become aware of a personal data breach. GDPR requires controllers to notify supervisory authorities within 72 hours of becoming aware of a breach. Without a DPA that obligates your processor to notify you promptly, you cannot meet that deadline.
Return or Deletion of Data
When the processing relationship ends, the DPA must require the processor to either return or delete all personal data, at your choice. This prevents your users’ data from sitting indefinitely in a third-party system after you have stopped using that vendor.
Audit Rights
The DPA must give you the right to audit the processor’s compliance with the agreement. In practice, this often takes the form of review rights over third-party audit reports such as SOC 2 Type II reports, rather than on-site inspections. But the right must exist in writing.
4. What Happens Without a Data Processing Agreement
Operating without required DPAs puts your business at risk in three specific ways.
First, regulatory fines. GDPR fines for failing to maintain compliant data processing agreements can reach 10 million euros or 2% of global annual revenue, whichever is higher, under Article 83(4). For US businesses processing EU personal data, those fines apply regardless of where your company is based.
Second, breach liability. If a third-party processor suffers a breach and you have no DPA in place, you have no documented chain of accountability and limited contractual recourse. Without a DPA that obligates the processor to notify you promptly, you may miss regulatory reporting deadlines and face penalties on top of the breach itself.
Third, your privacy policy becomes unenforceable in a critical area. Privacy policies tell users what data you collect and why. A DPA governs what actually happens to that data once you pass it to a third party. If your practice does not match your privacy policy because a processor is doing something your DPA does not restrict, you have a compliance problem that your privacy policy cannot fix. Our privacy policy legal services page explains how attorney-drafted frameworks address the full data lifecycle, not just the user-facing disclosure.
5. Standard Contractual Clauses for International Data Transfers
If your business transfers personal data from the EU to the US, a DPA alone may not be sufficient. The EU-US Data Privacy Framework (DPF), adopted in 2023 as a replacement for the invalidated Privacy Shield, provides a transfer mechanism for certified US companies. For companies that are not DPF-certified or that transfer data to countries without an EU adequacy decision, Standard Contractual Clauses (SCCs) must be incorporated into the data transfer arrangement.
SCCs are pre-approved contract clauses published by the European Commission. They are incorporated into your DPA or executed as a separate addendum. Using outdated or incorrect SCCs creates the same compliance gap as having no transfer mechanism at all. If your SaaS platform serves EU users and relies on US-based cloud infrastructure, this is a legal area that requires direct attention, not an afterthought.
6. DPAs vs. Your Privacy Policy: Why Both Are Required
A privacy policy is an external-facing disclosure document. It tells your users what data you collect, why, and what their rights are. A DPA is an internal-facing legal agreement between your business and a third-party vendor. These documents serve different legal purposes and cover different legal obligations.
Your privacy policy cannot substitute for a DPA. Your DPA cannot substitute for a privacy policy. Both are legally required, and both need to be accurate, current, and consistent with each other. When they conflict, that inconsistency becomes evidence in regulatory investigations and litigation. The legal checklist for US SaaS startups covers how DPAs fit into a complete legal foundation alongside your ToS, privacy policy, and service agreements.
7. How a Technology Lawyer Reviews Your DPAs
Standard DPAs provided by third-party vendors are written to protect the vendor, not your business. Cloud providers, SaaS tools, and payment processors have legal teams whose job is to draft agreements that limit the vendor’s liability while giving your business as little recourse as possible in the event of a breach.
A technology lawyer reviews a proposed DPA against your applicable regulatory obligations, your existing privacy policy, your business’s actual data flows, and the jurisdiction-specific requirements that apply to your users. Where the vendor’s standard DPA falls short, the attorney negotiates specific amendments or requires a custom addendum. Where required DPA provisions are missing, the attorney ensures they are added before you sign.
This review matters most when you are onboarding enterprise clients who conduct security and legal due diligence, when your business expands into EU markets, when you are facing a privacy audit or regulatory inquiry, and when you are evaluating new vendors who will process sensitive user data.
Frequently Asked Questions
Does my US business need a data processing agreement if we don’t serve EU customers?
Possibly. US state privacy laws, including California’s CPRA, Virginia’s VCDPA, and Colorado’s CPA, require contracts with service providers that restrict how they process personal information. Even without EU exposure, your business likely needs written data processing contracts with vendors that handle customer data on your behalf.
Can I use a template data processing agreement from the internet?
A template DPA may satisfy basic form requirements but is unlikely to reflect your specific data flows, applicable regulatory obligations, or the terms your vendor has proposed. Generic templates often miss jurisdiction-specific requirements such as CPRA’s “service provider” contract elements or GDPR’s SCCs for cross-border transfers. An attorney-reviewed DPA addresses your actual situation.
Who is responsible if a vendor causes a data breach and there is no DPA?
Under GDPR, both the controller (your business) and the processor can be held liable. Without a DPA, you have no contractual basis for requiring the vendor to cooperate with breach response, notify you promptly, or cover associated costs. Your business bears the regulatory and reputational consequences with limited recourse against the vendor.
How often should a data processing agreement be reviewed?
DPAs should be reviewed whenever your data processing activities change, when a vendor updates their own data handling practices, when new privacy laws apply to your business, or when you renew a vendor contract. At minimum, a full review every 12 to 18 months is a reasonable baseline for active SaaS businesses.
Do we need separate DPAs with every vendor, or can one document cover multiple vendors?
A DPA is a bilateral agreement between your business and each specific vendor. Each processing relationship requires its own agreement because the subject matter, duration, data types, and security obligations differ per vendor. Some businesses use a standard DPA template they present to new vendors, but each executed DPA is vendor-specific.
What is the difference between a data processing agreement and a data sharing agreement?
A DPA governs a processor that handles data on your instructions. A data sharing agreement governs a situation where two controllers share data for their own purposes, neither one acting on the other’s instructions. The legal obligations and contract terms differ significantly. If you are sharing data with a partner for joint marketing purposes, for example, you likely need a data sharing agreement, not a DPA.
Conclusion
Every business that uses third-party tools to process personal data needs data processing agreements. GDPR makes them mandatory for EU data flows, and US state privacy laws have added similar requirements that now reach most online businesses serving American consumers. Operating without properly drafted DPAs creates regulatory exposure, limits your recourse when vendors cause breaches, and creates inconsistencies between your privacy policy and your actual data practices.
If your business has not reviewed the data processing agreements with your vendors, or if you are relying on the standard form contracts vendors provide without legal review, that review is overdue. Contact Hansen Tong at TOSLawyer.com to have your data processing agreements reviewed by a technology lawyer who understands both the regulatory requirements and the vendor contracts that fall short of them.