Reading a data processing agreement for the three terms that matter.

A DPA is long, and most of it is boilerplate that will never be litigated. Three terms carry almost all of the risk. Read those closely and skim the rest.

The Brooklyn Bridge tower and its radiating suspension cables, seen from below.

WestBridge Counsel · June 2026 · Note

A data processing agreement is the contract that sits underneath a vendor relationship and says what the vendor may do with the personal data you hand it. Buyers tend to either sign it unread or get lost in its length. Both are mistakes. Most of a DPA is recital and required language that will look the same across every vendor you use. The risk concentrates in three places. Read those with care; move quickly through the rest.

1. Scope and purpose: what the processor may actually do

The first term that matters defines what the vendor is permitted to do with your data, and it is where the most consequential drafting hides. You are looking for a clean statement that the processor acts only on your documented instructions and only to provide the service. Then you are looking for the exceptions that quietly widen that grant: rights to use the data for "service improvement," for "analytics," or, increasingly, to train models. Those phrases can convert a narrow processing arrangement into a broad license over your customers' data. If a vendor wants those rights, that is a negotiation to have on purpose, not a clause to absorb by accident.

2. Subprocessors: who else gets the data

The second term is the chain behind the vendor. Almost every modern vendor relies on others to deliver its service, and your data flows to them. The questions that matter are whether the vendor must impose the same obligations on those subprocessors, whether you get notice before a new one is added, and whether you can object. A right to be notified with no right to object is close to no right at all. This term decides how far your data travels and whether your protections travel with it.

3. Security, breach, and audit: who bears it when something goes wrong

The third term is what happens on a bad day. Look for a security standard that is specific rather than a promise to use "reasonable" measures, a breach-notification obligation with a defined and short timeline, and a meaningful way to verify compliance, whether a true audit right or a credible substitute. Then read this term against the liability provisions in the main agreement, because a strong breach obligation is worth little if a low cap or a broad exclusion sits over it. The two have to be read together; vendors count on you reading them apart.

Worth a glance, rarely the fight

A few other provisions deserve attention without usually deserving a battle. International-transfer mechanics, including standard contractual clauses where data crosses borders, matter when your footprint is global. Deletion or return of data on termination matters when you leave. Cooperation with data-subject requests matters when your own users exercise their rights. Read them; flag the ones that do not fit your situation; spend your negotiating capital on the first three.

The short version

A DPA allocates risk between you and a vendor over the data your customers trusted you with. Read it for that, not for completeness. What may they do with the data, who else touches it, and who carries the loss when it leaks. Get those three right and the rest is housekeeping.

Work with us

Have a vendor's DPA in front of you?

Start a conversation