I have spent thousands of hours as a privacy lawyer since the GDPR went into effect in May 2018 negotiating data protection agreements (DPA) for clients, many of whom are software vendors (either SaaS, on premises or somewhere in between). Although I typically think of them as a data processing addendum, I have also seen a DPA be positioned as a stand alone data privacy agreement or together with security terms as a data protection exhibit. This sometimes creates some confusion among everyone because they can have different implications even though they are closely related. I tend to care much more about what the terms of the contract are then the precise label that is given to it.

Before we get to the good stuff – which is how I think about and negotiate DPAs on behalf of my vendor clients, let’s cover the basics thanks to my favorite large language model of the day.

A Data Processing Addendum (DPA) is a contract—usually an addendum to a service agreement—that governs how a vendor (the processor) handles personal data on behalf of its customer (the controller). It is one of the core building blocks of modern privacy compliance, required under laws like the GDPR and strongly encouraged or implied under nearly all U.S. state privacy statutes.

What Is a Data Processing Addendum (DPA)?
A Data Processing Addendum (DPA) is a legally binding agreement that sets the rules for how a service provider may collect, use, store, transfer, or otherwise process personal data on behalf of a business. Whenever an organization shares personal information with a vendor—whether for cloud hosting, analytics, HR tools, marketing platforms, or software services—a DPA ensures that the vendor processes that data only as instructed and with appropriate safeguards.
DPAs are essential for demonstrating accountability, managing vendor risk, and complying with privacy laws in the U.S. and internationally.

Why DPAs Matter
A DPA protects both the business and the individuals whose data is being processed by:
– Ensuring the vendor uses the data only for authorized purposes
– Requiring security measures to protect the data
– Establishing clear responsibilities between controller and processor
– Providing audit rights, breach notification timelines, and sub‑processor controls
– Supporting compliance with laws such as:
– GDPR
– California Consumer Privacy Act (CCPA/CPRA)
– Colorado Privacy Act
– Virginia, Connecticut, Utah, and other state privacy laws
In short, a DPA is the contract that makes privacy compliance operational.

What a DPA Typically Includes
While the exact structure varies, most DPAs contain the following core elements:
1. Purpose and Scope of Processing
– What data is being processed
– Why it is being processed
– How long the processing will continue
2. Controller and Processor Obligations
– The controller’s instructions
– The processor’s duty to follow those instructions
– Restrictions on data use, retention, and disclosure
3. Security Requirements
– Technical and organizational measures (TOMs)
– Encryption, access controls, logging, and monitoring
– Incident response and breach notification timelines
4. Sub‑processor Management
– Whether the vendor may use subcontractors
– Approval requirements
– Flow‑down obligations
5. Data Subject Rights Support
Vendors must help the business respond to:
– Access requests
– Deletion requests
– Correction requests
– Opt‑out requests
6. International Data Transfers
If data leaves the UK, EU or some other countries, the DPA must address:
– Transfer mechanisms
– Cross‑border safeguards
7. Audit and Assessment Rights
The controller may:
– Request documentation
– Conduct audits
– Review compliance certifications
8. Return or Deletion of Data
At the end of the engagement, the vendor must:
– Return the data
– Delete it securely
– Certify deletion

When You Need a DPA
A DPA is required whenever a vendor processes personal data on your behalf, including:
– Cloud hosting providers
– SaaS platforms
– HR and payroll vendors
– Marketing and analytics tools
– Customer support platforms
– AI and machine‑learning service providers
If a vendor touches personal data—even incidentally—a DPA is almost always necessary.

Why DPAs Are Becoming More Important
With the rapid expansion of U.S. state privacy laws, DPAs are no longer a “GDPR‑only” requirement. Nearly every comprehensive state privacy law now requires:
– Processor contracts
– Specific mandatory clauses
– Clear allocation of responsibilities
This means DPAs are now a standard part of vendor onboarding and risk management for organizations of all sizes.

Here is what I regularly negotiate in a DPA:

So now that we have the perfunctory items out of the way, let’s talk about the things that I really care about in DPAs, what I sometimes negotiate, and where I have not seen a lot of negotiation.

IP Terms: I probably spend an unusually large amount of time thinking about confidential information definitions and customer data in data protection and security exhibits because they often contain intellectual property terms that can mess with the ownership or licensing terms in the underlying agreement. These definitions are written broadly by customers in order to bring everything under the sun within them, but I often find that they inadvertently could include the vendor information as well. The standard DPA built for regulatory compliance with privacy laws does not need to define either confidential information or customer data since the regulatory requirements are around personal data. However, I see a lot of data processing addendum go beyond the standard regulatory requirements.

Indemnification: I feel like I spend the most time here on whether the indemnification is limited to third-party claims or not, what the indemnification procedures are, and the grey areas where the indemnification for some reason is looking to go beyond a breach of the DPA that is not contributed to by the customer, into other areas such as any act or omission, or simple negligence. I always strike the very common proposal that the indemnification is uncapped.

Liability Cap: I basically never accept uncapped liability on either a DPA or the attached indemnification. So if you are negotiating on the customer side you had better make your plea to the business compelling as to why you need uncapped liability. Because I will tell you no.

Security Incidents and Breach Notifications: My changes in this area typically relate to operational concerns (ie, no it is not possible to do an “immediate” incident notification) or a broad incident reimbursement request. I typically extend incident notifications to 48 hours since the first 24 hours of incident response are usually needed for other things. I also always limit incident reimbursement to sending breach notifications required by applicable law and the associated costs. To me there are few compelling reasons to reimburse for ordinary compliance costs even if it relates to an incident.

CCPA Language: I find the regulatory requirements around certifications, monitoring and remediation rights vague and I am typically looking to modify or clarify them for my clients.

Audits: The reality here is that I do not care about this that much from a legal perspective. It is more of an operational question as to how much notice is needed, who pays, how in depth they can be, and is a third-party audit accepted in lieu of the customer’s own audit. My one concern here from the legal side is what happens when a customer finds deficiencies and wants to either (i) dictate changes/remediation; or (ii) terminate.

Security Terms: As long as the customer proposes something that is reasonable and my client can comply with it, I try not to spend too much time changing the technical terms in these. I usually do a review for things which in my experience vendors typically do not do or which customers do not typically ask for, and flag these to my clients for their technical, engineering or security team to review or discuss. The problem here is that sometimes security addendums either (i) use one-sided language in the hopes that the vendor will not edit it (for example, using “best practices” since I never want to be in a discussion about what this means); or (ii) throw everything possible in there as a requirement no matter how expensive it would be to implement. In general I probably spend a lot of time negotiating the vulnerability requirements in these since there is more risk then ordinary there.

Maybe negotiating:

I thought that the “maybe” category was important here because these are things that I would prefer to not be negotiating but seem to come up too much to put them in the below “not negotiating” category. These are the ones where there are a few things that I really care about and other than that they are fine with me.

Affiliates: In general I prefer that the DPA is between the contracting entity of the customer and the vendor. This can be handled with an intragroup DPA pretty easily and does not need to complicate the contractual relationship. If a customer really wants to give its affiliates rights under the DPA, such as a third-party beneficiary relationship, that is generally fine with me as long as long as it does not increase the liability of the vendor or expand the rights of the customer too much.

Subprocessors: In general I try to not negotiate these terms if they are reasonable. The biggest area of negotiation here is usually whether the contract requires express approval and what happens if the customer does not approve.

Government Requests: As long as this is something that allows my clients to comply with the law I typically accept it. So if it requires notice regardless of whether the law prohibits notice, I will have to add a carveout in there.

Not negotiating:

My DPA negotiation philosophy is to accept whatever I have authorization to accept unless the language is particularly vague. This means that we usually get to the heart of disagreements with customers pretty quickly in the negotiation. I do not tend to see a lot of the later disputes relating to redlines in any of the following areas:

Processing Restrictions: Over the years I have come to typically accept anything that is reasonably in line with GDPR here when it is proposed by customers.

Data Subject Rights: I have not seen a lot of controversy over these in DPAs. As long as an organization is giving the vendor enough time that it does not have to send on data subject requests over the weekend, these are usually fine.

Data Protection Impact Assessments: I do not usually make a lot of changes to this requirement. Nothing stands out in my mind as repetitive over the years.

Standard Contractual Clauses: The form is relatively standardized so the changes here are typically minor and either to the subprocessor provisions or the schedules. Most of the changes that I see here are usually stylistic or subprocessor specific, other than (i) the technical and organizational (ie, security/data protection) measures; and (ii) whether the limitations of liability of the agreement apply to the SCCs.