A data processing addendum (DPA) is a written contract between a business and a vendor that touches personal data — specifying what the vendor can do with it, how it must be secured, and who is liable if something goes wrong. If you handle California residents' data, accept EU personal data, or fall under HIPAA, you almost certainly need one. Here is how to know for sure, and what each law actually requires.
What a DPA actually does
Think of a DPA as the legal job description for any third party that processes data on your behalf. The vendor — whether a cloud database, email platform, or analytics tool — agrees in writing to process data only for your stated purposes, maintain appropriate security, cooperate with audits, and notify you of breaches.
Without a DPA, a regulator investigating a breach can argue that you had no contractual control over your vendor. That matters enormously when calculating fines and assessing liability.
CCPA/CPRA: the service-provider contract requirement
Under the California Consumer Privacy Act as amended by the California Privacy Rights Act (CPRA), a business can disclose personal information to a third party without triggering "sale" status — and the disclosure restrictions that come with it — only if that third party qualifies as a service provider. Cal. Civ. Code § 1798.100 et seq.
To qualify as a service provider under the CPRA, the vendor must have a written contract that:
- Prohibits the vendor from selling or sharing personal information received from you
- Bars the vendor from retaining, using, or disclosing personal information outside the specific services they are providing
- Requires the vendor to comply with applicable CPRA obligations
- Grants you the right to audit or take remediation steps
That written contract is, in effect, a DPA. Without it, a vendor that processes California residents' data is not a service provider under California law — it may be treated as a third party receiving a "sale," opening you to enforcement by the California Privacy Protection Agency (CPPA).
The CPRA also introduced a specific sub-service provider requirement: if your service provider engages another company to help process your customers' data, a comparable written contract must flow down to that sub-provider.
HIPAA and the BAA: a different instrument, same function
Covered entities under HIPAA — health plans, healthcare clearinghouses, and many healthcare providers — and their business associates face an analogous but distinct requirement: a Business Associate Agreement (BAA).
Under 45 C.F.R. § 164.504(e), a covered entity cannot disclose protected health information (PHI) to a business associate without a BAA. The required contract terms closely parallel a DPA: permitted uses, safeguard requirements, breach reporting timelines, and obligations at termination of the relationship.
If your SaaS product processes any PHI — even incidentally, even if you are not a healthcare company yourself — and you share that PHI with a cloud storage vendor, analytics processor, or subcontractor, you each need a BAA in place. Missing a BAA is a HIPAA violation independent of whether a breach ever occurs.
A single entity can be simultaneously a CPRA service provider and a HIPAA business associate; both agreements may be required for the same vendor relationship.
State laws that trigger DPA requirements: Virginia, Colorado, and Connecticut
Several states that enacted comprehensive privacy statutes following California's lead impose their own processor-agreement requirements.
Virginia — Under the Consumer Data Protection Act (Va. Code § 59.1-575 et seq.), controllers must enter a contract with processors that specifies the nature and purpose of processing, the type of data involved, and obligates the processor to delete or return data upon request. Virginia's law applies to businesses that control or process personal data of at least 100,000 Virginia residents annually, or 25,000 residents if the business derives over 50 percent of gross revenue from the sale of personal data.
Colorado — The Colorado Privacy Act (C.R.S. § 6-1-1301 et seq.) requires a binding contract between a controller and any processor. The contract must address the processor's obligations regarding confidentiality, security, sub-processors, assistance with consumer rights requests, and audits. Colorado's thresholds mirror Virginia's.
Connecticut — Connecticut's Data Privacy Act (Pub. Act No. 22-15, codified at Conn. Gen. Stat. § 42-515 et seq.) contains substantially the same processor-contract requirement, with thresholds of 100,000 consumers or 25,000 consumers plus 25 percent of gross revenue from data sales.
Each of these states can impose civil penalties for violations. Virginia, for example, sets a maximum penalty of $7,500 per intentional violation; Colorado and Connecticut allow similar enforcement by their attorneys general.
Note that none of these state laws require a separate addendum for every state — a single, well-drafted DPA can satisfy all three simultaneously if it addresses each law's required provisions.
Standard Contractual Clauses: when your vendor handles EU data
If your US business receives personal data from EU residents — even indirectly through a European customer or a SaaS user based in the EU — the General Data Protection Regulation (GDPR) applies to that transfer. GDPR does not permit personal data to flow from the EU to the United States without a valid transfer mechanism.
The mechanism most US companies rely on is Standard Contractual Clauses (SCCs), specifically the modular SCCs issued by the European Commission in June 2021. These are pre-approved contract terms that must be incorporated verbatim into the data transfer agreement. The relevant module depends on the relationship: controller-to-processor (Module 2) is the most common configuration when a US company receives EU personal data to provide services.
SCCs are incorporated into a DPA as an annex or exhibit. If you use a third-party processor — say, a US-based analytics firm — to handle data from your EU customers, both the transfer from EU to US and the transfer from you to the sub-processor must be covered by appropriate SCCs or an equivalent mechanism.
Failing to maintain a valid transfer mechanism is an independent GDPR violation, distinct from any underlying data breach. Fines under GDPR Article 83 can reach €20 million or 4 percent of global annual turnover, whichever is higher.
The practical trigger: a vendor sends you a DPA request
Many SaaS founders encounter a DPA for the first time when a corporate customer — particularly one based in Europe or operating in a regulated US sector — sends a contract request before agreeing to sign up. This is standard procurement due diligence, not a red flag.
When that happens, you are now the processor or service provider in that relationship. Your customer needs a DPA with you just as much as you need one with your own vendors. You will need to decide whether to sign their draft or provide your own.
If you are providing your own, it should at minimum address:
- The categories of personal data you process and the purposes for processing
- Your security measures and breach notification timeline (typically 72 hours to notify the controller, which matches GDPR Article 33)
- Sub-processor restrictions and notification obligations
- Data subject rights assistance — deleting, correcting, or porting data on request
- Audit rights for the controller
- Data return or deletion upon contract termination
- SCC addendum if EU personal data is involved
You can draft and execute a DPA without outside counsel for straightforward SaaS relationships. Forms-legal.com provides a data processing agreement template structured to cover the CCPA/CPRA service-provider contract requirements and GDPR SCC needs.
When you do not need a DPA
Not every vendor relationship requires a DPA. A vendor that merely acts as a conduit — a telecommunications carrier transmitting data without accessing content, or a postal courier — is not a "processor" under most privacy statutes.
Similarly, if a vendor processes data for its own purposes (a data broker that buys your customer list to resell), that vendor is a controller or third party, not a processor. A DPA would be legally inaccurate; what you need in that case is a data transfer agreement with appropriate use restrictions — or, under CPRA, a disclosure agreement if no opt-out mechanism is in place.
What happens without one
Regulators treat the absence of required processor contracts as a compliance gap that amplifies other violations. The FTC has cited inadequate data-sharing contracts in enforcement actions under Section 5 of the FTC Act (15 U.S.C. § 45). California's CPPA began formal rulemaking on enforcement priorities in 2025 and has publicly identified processor-contract compliance as an audit focus area.
The risk is not only regulatory. A vendor that lacks a DPA is also harder to hold contractually accountable if its data security fails. Without a breach-notification clause, you may receive no notice of an incident affecting your customers' data until a third party discovers it.
The checklist before your next vendor contract
Before signing any new SaaS, analytics, or cloud vendor agreement in 2026, run through these questions:
- Does the vendor access, store, or process personal data of your users or employees?
- Are any of those users California, Virginia, Colorado, or Connecticut residents?
- Is any of that data protected health information under HIPAA?
- Does any EU personal data flow to this vendor?
If you answer yes to any of these, execute a DPA before data transfer begins — not after.
Need the document itself? Download the free template →
This article is general information, not legal advice — see our accuracy & editorial policy. Confirm the cited law is current before relying on it.