DPA Review Field Guide for In-House Counsel

The same three phrases lose privacy negotiations every week. "Without undue delay" for breach notification, with no defined hours. "SOC 2 Type II available upon request" as the only audit right. "Liability shall be subject to the limitations set forth in the Agreement" with no carve-out for security incidents.

In-house counsel sign those terms because the head of sales pinged Slack with "vendor sent a DPA, can you take a quick look." That "quick look" is the most expensive 15 minutes of legal work you do all quarter, and this DPA review checklist, part of how teams put legal AI for in-house counsel to work, is what replaces it.

The DPA template in circulation in 2026 is not the DPA template of 2020. The post-Schrems II SCC update in 2021, the DPF in 2023, and 19 US state privacy laws now on the books have rewritten what a defensible processor contract looks like.

Most vendor templates have not caught up, or have caught up only on the surface, retaining 2020-era liability and audit posture under a 2026 transfer-mechanism gloss.

Four of the 15 items in this checklist actually move risk: controller/processor classification (item 15), transfer mechanism (item 6), breach notification timeline (item 5), and liability cap carve-out for data breach (item 8). The other eleven are real but lower-leverage. If you only have 30 minutes with a DPA, fight those four and accept template language on the rest.

The Data Processing Addendum is a 14-page contract that points at four regulatory regimes, drags in two transfer mechanisms, and carries the only liability that matters when the breach notice hits your CEO's inbox at 11:47 p.m. on a Sunday.

There is no quick look. Only the look you do now, or the look outside counsel does later at $1,100 an hour after a regulator opens a file.

How to review a DPA in one pass: confirm whether you are the controller or processor, check that the cross-border transfer mechanism is named (DPF or the correct SCC module), nail down the breach notification timeline in defined hours, and carve data breach out of the general liability cap. Then run the full 15-point list below for the rest. Those four items move more risk than the other eleven combined.

DPA Review Field Guide for In-House Counsel

TL;DR

Part of our in-house counsel guide series.

  • A DPA review checklist for in-house counsel runs 15 items: sub-processor disclosure, approval rights, data residency, audit rights, breach notification timeline, cross-border transfer mechanism, deletion on termination, liability cap carve-out, encryption, tenant isolation, personnel controls, insurance, DPO designation, SCCs by reference, and controller/processor classification.
  • The four items vendors will actually push back on are sub-processor approval (most want notice-only), breach notification timeline (most want "without undue delay" rather than 72 hours), audit rights (most want SOC 2 attestation only), and the liability cap carve-out for data breach (most want their main cap to apply).
  • Post-Schrems II (Case C-311/18), the EU-US Data Privacy Framework (effective July 10, 2023) is a valid transfer mechanism for vendors self-certified with the US Department of Commerce. SCCs (Commission Implementing Decision 2021/914) are the standard backup. For sensitive data flows, run a transfer impact assessment regardless of which mechanism the contract names. If the vendor offers neither, walk.
  • Real negotiating leverage lives in one place: are you the controller or the processor under the deal? Get that wrong and the rest of the document points the wrong direction.
Quick check

What breach notification timeline does this guide set as the default a DPA should require from the vendor?

Why DPAs are a sinkhole

GDPR Article 28 made a written processor contract mandatory in the EU; California, Virginia, Colorado, Connecticut, Texas, and a dozen more states followed.

Every SaaS vendor ships a DPA template. None are identical. Each quietly re-allocates risk in three or four places.

The vendor stack got bigger. A 200-person company in 2018 had maybe 40 SaaS tools. The 200-person company in 2026 has 140, half procured by a marketing manager with a corporate card.

The breach economics got worse. IBM's 2024 Cost of a Data Breach Report put the average US breach at $9.36 million, healthcare at $9.77 million globally. The DPA decides whether you eat that number or the vendor does.

The 15-point DPA review checklist

The 15 clauses to confirm in any vendor's data processing agreement before signing.

The DPA review checklist at a glance

Here is the whole checklist in one table, with the default position and which items are worth a fight. Skim this, then read the detail on the four that matter.

#ItemDefault positionFight for it?
1Sub-processor disclosurePublic, dated, contractual listMedium
2Data residencyWritten commitment, change noticeMedium
3Sub-processor approvalRight-to-object, 30 days, terminate on objectionYes
4Audit rightsThird-party right on cause + SOC 2Yes
5Breach notification48 hours from becoming awareYes
6Transfer mechanismDPF or correct SCC module namedYes
7Deletion or returnController's choice, 30 days, certifyMedium
8Liability cap carve-outBreach carved out, 3x to 10x or fixed floorYes
9EncryptionAES-256 at rest, TLS 1.3 in transitLow
10Tenant isolationNamed isolation model, change noticeLow
11Personnel controlsLeast-privilege, MFA, trainingLow
12InsuranceStand-alone cyber, scaled to dataMedium
13DPO designationNamed contact, working emailLow
14SCCs by referenceCorrect module, annexes filledMedium
15Controller vs processorConfirmed in writing before signingYes

The GDPR Article 28 terms a DPA must contain

Before you negotiate posture, confirm the contract has the mandatory subjects. GDPR Article 28(3) requires the processor contract to set out the subject matter, duration, nature, and purpose of processing, the type of personal data, and the categories of data subjects. It then requires the processor to:

  • process only on the controller's documented instructions, including on transfers (Art 28(3)(a))
  • ensure persons processing the data are under a duty of confidentiality (Art 28(3)(b))
  • take all security measures required by Article 32 (Art 28(3)(c))
  • respect the conditions for engaging sub-processors in Article 28(2) and 28(4) (Art 28(3)(d))
  • help the controller answer data subject rights requests (Art 28(3)(e))
  • help the controller meet its Article 32 to 36 duties, including breach notification and DPIAs (Art 28(3)(f))
  • delete or return the data at the end of the service (Art 28(3)(g))
  • make available the information needed to show compliance, and allow audits (Art 28(3)(h))

A DPA missing any of these is not Article 28 compliant, which is itself a breach exposed to fines up to EUR 10 million or 2 percent of global turnover under the lower tier (GDPR Article 28, EUR-Lex). If a vendor template drops a subject, that is a redline before you argue about caps.

The CCPA service-provider terms most templates miss

If California residents' data is in scope, a GDPR-shaped DPA is not automatically enough. The CCPA, as amended by the CPRA, requires the contract to bind a "service provider" or "contractor" to specific terms (California Civil Code 1798.140 and the CPPA regulations). Confirm the DPA:

  • limits the vendor to the specific business purpose, and bars retaining, using, or disclosing the data for any other purpose
  • prohibits selling or sharing the personal information
  • prohibits combining the data with personal information from other sources, outside the permitted exceptions
  • requires the same level of privacy protection the CCPA requires of the business
  • grants the business the right to take reasonable steps to stop and remediate unauthorized use
  • requires the vendor to notify the business if it can no longer meet its CCPA obligations

Most vendor DPAs bury these in a US-states schedule, and some pre-2023 templates never added the CPRA-specific "same level of protection" and combination-ban language. Read the schedule, do not assume it tracks the statute.

The 15-point checklist

Run every DPA against these in order. Each has a default position. Deviate only with a reason you could explain to your audit committee.

1. Sub-processor disclosure

The vendor must publish a current list of sub-processors. Not "available on request," not "in our trust portal after NDA." A URL, public, dated, updated.

If you can't see who is touching the data before you sign, you cannot do downstream due diligence, map transfer mechanisms, or answer a regulator's first question.

Default: public sub-processor list as a contractual obligation, refreshed on cadence.

2. Data residency commitment

Where the data sits at rest. US-only, EU-only, both with regional pinning, or "globally distributed."

The column most procurement teams skip, and the one most likely to trigger a customer escalation 18 months later, when a healthcare customer realizes their PHI sat on a Frankfurt node for 90 days.

Default: written residency commitment matching the vendor's marketing claims, with change notice rights.

3. Sub-processor approval mechanism

First fight. Two postures: "right to object" (vendor notifies, customer has N days to object, objection lets you terminate the affected service) and "prior written consent" (vendor cannot onboard without express written sign-off).

Vendors want right-to-object. Healthcare and fintech customers want prior consent. The recurring vendor counter: "we cannot operate with 1,400 customers each holding a veto on our infrastructure."

The concession, when you push back, is a tiered structure: prior consent for sub-processors with access to unencrypted personal data or processing outside named regions, right-to-object for everyone else. That tiered structure is the deal to write.

Default: right-to-object with 30 days' advance notice, plus a termination-without-penalty right if you object and the vendor proceeds anyway. Prior consent only for vendors touching crown-jewel data.

4. Audit rights

Second fight. Three rungs. Vendor wants the bottom: annual SOC 2 Type II on request. Middle: third-party-audit right, independent firm at your cost, once a year, reasonable notice. Top: on-site audit by customer or designee.

Where I concede: the on-site rung, for any pure SaaS vendor with a clean SOC 2. Where I hold firm: the third-party right for any vendor touching regulated data, framed as "exercisable on a material security incident or regulator demand."

That framing flips it from a control problem to a contingency, which most vendor counsel signs within one redline cycle.

5. Breach notification timeline

Third fight, cleanest regulatory anchor. GDPR Article 33 obligates the controller to notify the supervisory authority within 72 hours of becoming aware of a breach. If you are the controller and your vendor is the processor, you cannot meet that clock if the vendor's obligation is "without undue delay" with no defined hours.

The standard vendor redline I see: cross out "48 hours" and write back "no later than 72 hours from confirmation of a Security Incident." Two problems with that. "Confirmation" gives the vendor unilateral control of when the clock starts. "72 hours" is your own clock under Article 33, with no buffer to assess and notify.

Default: vendor notifies you within 48 hours of becoming aware (not confirming), with the GDPR Article 33(3) information set provided as it becomes available. California's Civil Code §1798.82 requires notice to affected consumers "in the most expedient time possible," which courts have read aggressively.

6. Cross-border transfer mechanism

If any data leaves the EU, the contract must name the mechanism. Post-Schrems II (Case C-311/18, CJEU July 16, 2020), Privacy Shield was invalidated. The acceptable list for EU-to-US transfers:

  • EU-US Data Privacy Framework, effective July 10, 2023, for vendors self-certified with the US Department of Commerce. Check the active certification list directly. DPF is valid on its own; for sensitive flows, run a transfer impact assessment regardless.
  • Standard Contractual Clauses under Commission Implementing Decision (EU) 2021/914, with the correct module (Module 1 C-to-C, Module 2 C-to-P, Module 3 P-to-P, Module 4 P-to-C). Module selection is where most templates are wrong.
  • Binding Corporate Rules, which only the largest vendors have.

A vendor that won't name a mechanism, or hand-waves with "we comply with applicable law," has not done the work.

7. Data deletion or return on termination

GDPR Article 28(3)(g) requires the processor to delete or return all personal data at the end of the service, at the controller's choice.

The trap is the carve-out: "except as required to comply with applicable law" stretched to mean analytics retention, and "except for back-up media deleted in accordance with our standard retention schedule" without a defined outside date.

Default: deletion or return at controller's election within 30 days of termination, backup deletion within 90 days, written certification on request.

8. Liability cap carve-out for data breach

Fourth fight, and where most in-house counsel leave the most money on the table. The vendor's MSA usually caps liability at 12 months of fees. The DPA, if you don't push, inherits that cap.

A vendor you pay $80,000 a year is then contractually exposed for $80,000 if they lose your customer database. Not a serious number.

The standard vendor move: refuse uncapped on the cover page, offer a 2x super-cap in the DPA, and tell you "no one in our category does better." For vendors selling into healthcare or financial services, that line is wrong.

Default: data breach liability uncapped or at a meaningful multiple (3x to 10x annual fees, or a fixed floor of $1M to $10M depending on sensitivity), with DPA breaches carved out from the general limitation. Treat 2x as the floor, not the ceiling.

9. Encryption at rest and in transit

AES-256 at rest, TLS 1.3 in transit. So standardized in 2026 that pushback signals a problem.

Require the standard, not an implementation, and require notice on downgrade. Key management is the harder sub-question: customer-managed for sensitive deployments, vendor-managed for everything else.

10. Tenant isolation guarantees

For multi-tenant SaaS, get a written representation about how customer data is logically separated. "Logical isolation" with no further detail is meaningless.

Ask for specifics: database-per-tenant, schema-per-tenant, or row-level isolation with tenant ID filtering. The contract should commit to one so a future architectural change requires customer notice, not silent re-platforming.

11. Personnel access controls and training

The vendor's personnel are the largest attack surface you do not control.

Default: least-privilege, MFA on production, background checks for personnel touching customer data, annual privacy and security training with documented completion. Verizon's 2024 DBIR put the human element in 68% of breaches.

12. Insurance requirements

Cyber liability: $5M minimum for a small vendor, $10M to $25M for regulated data, $50M-plus at enterprise scale. Plus tech E&O and general liability at standard amounts. COI required, 30 days' cancellation notice, refreshed annually.

Where I hold firm: stand-alone cyber. Vendors often try to roll cyber into general liability under one number, and a GL tower does not pay on a breach.

13. Data Protection Officer designation

Under GDPR Article 37, certain controllers and processors must designate a DPO. The DPA should name the vendor's DPO (or equivalent privacy contact) with a working email, and require notice of changes. If none is designated, ask why.

14. SCCs pulled by reference, with correct module

If the deal involves EU transfers, SCCs go in as an annex or by reference. The most common drafting error: referencing "the Standard Contractual Clauses" without specifying Module 2 (C-to-P) or Module 3 (P-to-P). Confirm the importer and exporter annexes are filled out with real information, not "see Order Form."

15. Controller versus processor classification

The foundation everything else rests on. Is your company the controller (you determine purposes and means) or the processor (you process on behalf of another controller)? For a customer using a SaaS tool, you are almost always the controller. Re-sale arrangements, embedded analytics, AI-training data flows, and platform-of-platforms situations can flip this.

Get it wrong and the entire DPA points at the wrong obligations. Ask the vendor in writing how they classify the relationship, and confirm their answer matches yours before signing.

The AI-training carve-out almost no 2020 template has

The DPA section everyone added in 2024 and 2025, and a lot of templates still lack, is a clean prohibition on the vendor using customer personal data to train, fine-tune, or evaluate AI models.

Vendors who built AI into their product after 2023 frequently treat customer data as a training input by default, with an opt-out tucked into a sub-clause. The right contractual position is the inverse: opt-in, in writing, per use case, with deletion rights on revocation.

Sub-processor language interacts with this too. If your vendor's sub-processor list includes an LLM provider, ask whether prompts and outputs traverse that sub-processor with personal data attached, and whether the LLM provider has zero-retention enabled on the API tier the vendor uses.

The contractual answer should be "yes, zero-retention, no training on customer inputs," in writing. Anything weaker than that is a hole you will read about in a breach notice later.

A worked example: one redline pass

Here is what the four high-leverage items look like on a real-shaped DPA from a mid-market SaaS vendor you pay $80,000 a year, holding customer PII including some EU data.

Classification. The DPA says "the parties acknowledge that, for the purposes of the Data Protection Laws, Customer is the Processor and Vendor is the Sub-Processor." Wrong direction for a standard SaaS purchase. You determine purposes and means, so you are the controller and the vendor is the processor. Redline: swap the roles, and add a line confirming the vendor processes only on your documented instructions.

Transfer mechanism. The clause reads "Vendor will ensure an appropriate transfer mechanism is in place as required by applicable law." That names nothing. Redline: "For transfers of EU personal data to the United States, the parties incorporate the Standard Contractual Clauses (Module 2, Controller to Processor) per Commission Implementing Decision (EU) 2021/914, with Annexes I to III completed; where Vendor is self-certified under the EU-US Data Privacy Framework, the DPF applies."

Breach timeline. The vendor wrote "Vendor shall notify Customer without undue delay following confirmation of a Security Incident." Two problems: no defined hours, and "confirmation" hands the vendor the start of the clock. Redline: "within 48 hours of becoming aware of a Security Incident," plus the Article 33(3) information set as it becomes available.

Liability. Section 9 says "each party's total liability shall be subject to the limitations in the Agreement," which is the 12-month-fees cap, so $80,000 for losing your database. Redline: carve Security Incident liability out of the general cap, set it at the greater of 5x annual fees or $2 million.

That is four edits. They are the difference between a defensible contract and a number your CEO reads in a breach notice.

Red flags

Three patterns reliably indicate a vendor you do not want.

A vendor that refuses any audit right beyond "you can review our SOC 2 once a year." Either something to hide or a contracts process so brittle the first regulator letter will break it.

Vague sub-processor language: "Vendor may engage sub-processors from time to time." No list, no notice mechanism, no objection right. 2018 boilerplate. If they will not update it on request, they treat privacy as marketing copy.

Indemnity carve-outs that exclude data breach. The MSA promises broad indemnification for IP infringement and third-party claims, then the DPA quietly carves out "any claim arising from a Security Incident." Read those carve-outs carefully. Most common vendor-side move, most expensive one you miss.

Cross-jurisdictional considerations

The contract has to satisfy whichever regulator might show up.

GDPR is the strictest baseline: Article 28 for processor obligations, Article 32 for security, Article 33 for breach notification, Article 37 for DPO. If your DPA satisfies GDPR, it satisfies most US state laws on substance.

CCPA, as amended by CPRA, lives in California Civil Code §1798.100 et seq. It uses "service provider" and "contractor" rather than "processor," but the functional obligations rhyme. The CCPA-specific moves: limits on using personal information outside the business purpose, and consumer-rights flowdown.

PIPEDA in Canada and Quebec's Law 25 add notification and consent requirements that differ from the US-state pattern. LGPD in Brazil, modeled on GDPR, adds local data-subject rights.

Draft your in-house DPA template to GDPR-baseline, with US-state, Canada, and Brazil schedules layered on. Vendor review then becomes a delta exercise, not a fresh read.

The 2026 negotiation reality

Sub-processor approval has converged on right-to-object with 30 days' notice. Prior consent is still achievable for the largest customers and the most sensitive data, but no longer the default ask.

Breach notification has converged on 48 to 72 hours, with sophisticated vendors writing the full GDPR Article 33(3) disclosure set into the contract. "Without undue delay" with no defined hours is a tell that incident response is not mature.

Audit rights have converged on SOC 2 Type II plus a written-questions right plus a third-party audit right exercisable on cause. Pure SOC-2-only is a 2020 position that has not aged well.

DPF and 2021/914 SCCs have settled the EU transfer question for most deployments, with a transfer impact assessment layered on for sensitive flows. The open question is whether DPF survives a Schrems III challenge.

The framework is operative, regulators treat it as valid, and most counsel sign on it while keeping SCCs as a belt-and-suspenders fallback. Refusing to sign anything until the next CJEU decision is not defensible.

Liability carve-outs are where variance remains. Bottom of the market: main-cap parity. Top: uncapped breach liability or a 10x super-cap. Most enterprise deals land at 2x to 5x. Push for the top of that band on any vendor holding regulated data.

The DPA review is not glamorous work. It is the work that determines whether your company is on the right side of a breach notice 18 months from now. Build the template, run the checklist, stop calling it a quick look.

FAQ

How do you review a DPA?

Work top down. Confirm whether you are the controller or the processor, because that sets every other obligation. Check the four high-leverage items (transfer mechanism, breach timeline in defined hours, sub-processor approval, and a liability carve-out for data breach), then run the full 15-point checklist for the remaining clauses. Treat anything that deviates from your default as a redline you can justify to your audit committee.

What must a GDPR-compliant DPA include?

GDPR Article 28(3) requires the subject matter, duration, nature, and purpose of processing, the data types, and the categories of data subjects, plus eight processor duties: documented instructions, confidentiality, Article 32 security, sub-processor conditions, help with data subject rights, help with breach and DPIA duties, deletion or return, and audit access. A DPA missing any of these is not Article 28 compliant.

What is the difference between a DPA and SCCs?

A DPA is the processor contract required by GDPR Article 28 for any vendor handling personal data on your behalf. Standard Contractual Clauses are a separate transfer mechanism, under Commission Implementing Decision (EU) 2021/914, that you add when personal data leaves the EU to a country without an adequacy decision. You can need both: the DPA governs the processing, the SCCs (or the Data Privacy Framework) legalize the cross-border transfer.

Does the CCPA require a data processing agreement?

The CCPA, as amended by the CPRA, requires a written contract binding any "service provider" or "contractor" to specific terms: a limited business purpose, a bar on selling or sharing, a ban on combining data outside permitted exceptions, the same level of privacy protection the CCPA requires, and the right to remediate misuse. It uses different labels than GDPR, but a vendor handling California residents' data needs a compliant contract.

What breach notification timeline should a DPA require?

Push for the vendor to notify you within 48 hours of becoming aware of a breach, not "without undue delay" and not from "confirmation." You as the controller have only 72 hours under GDPR Article 33 to notify the supervisory authority, so a 48-hour vendor obligation leaves a buffer to assess and report. Tie notice to "becoming aware" so the vendor cannot delay the clock by withholding confirmation.

What are the biggest red flags in a vendor DPA?

A refusal of any audit right beyond an annual SOC 2 review, vague sub-processor language with no list or objection right, and indemnity or liability carve-outs that exclude data breach. Each signals either something to hide or an immature contracts process. A flat refusal to sign a compliant DPA at all is the clearest red flag of the three.

Should a DPA carve data breach out of the liability cap?

Yes, for any vendor touching regulated or sensitive data. The default vendor position inherits the main 12-month-fees cap, which can leave a vendor exposed for a trivial sum after losing your entire database. Negotiate breach liability uncapped or at a meaningful multiple (3x to 10x annual fees, or a fixed floor), carved out from the general limitation. Treat 2x as the floor, not the ceiling.

Are data processing agreements required in the US?

There is no single federal law that names a "DPA," but in practice yes for most vendors handling personal data. The CCPA as amended by the CPRA requires a written service-provider or contractor contract with set terms, the newer state privacy laws (Virginia, Colorado, and others) require processor contracts, and sector rules require their own versions: HIPAA business associate agreements for health data, GLBA service-provider terms for financial data. If a vendor processes covered or regulated data on your behalf, you need a compliant data-processing contract.

Who needs to sign a data processing agreement?

Both parties: your company as the controller or business, and the vendor as the processor or service provider, signed before the vendor starts processing personal data. Sub-processors the vendor uses do not sign your DPA, but the vendor must bind them to equivalent terms through its own contracts, and list them so you keep an objection right.

Make it a repeatable check

For related operational playbooks, see the DPA negotiation playbook, which legal AI vendors offer signed DPAs, and the in-house contract review playbook. For more on running this checklist as structured field extraction across a stack of vendor DPAs, see /features/document-matrix.

Running the 15-point checklist as a delta exercise against a GDPR-baseline template is the kind of work Vaquill AI is built for, with contract review and compliance checks flagging the sub-processor, breach-timeline, and liability-carve-out clauses that miss the mark.

Want to turn DPA review into a repeatable delta check? Start a free Vaquill AI trial, or see the DPA review feature.

Legal AI that reads your documents and knows the law.
Ask a legal question, review a contract, or search thousands of your files. Every answer shows where it came from. 7-day free trial, no card.
24 min read

New legal AI guides, weekly.

Arshita Anand

Arshita Anand

Co-Founder & CEO · Attorney

Arshita leads product and strategy at Vaquill, building the legal AI suite that solo, small-firm, and in-house US lawyers use to run a matter end to end.