DPA Playbook: Clause-by-Clause Positions for Data Processing Agreements

Five clauses decide whether a data processing agreement (DPA) has teeth: breach notice, subprocessors, security, transfers, and how the DPA sits under the liability cap. The rest is mostly boilerplate you can move fast on. This is a negotiation playbook for that one contract type, the terms that govern how a vendor handles personal data on your behalf.

For each key clause it gives a preferred position, an acceptable range, a fallback ladder, a walk-away line, and the trigger for escalating to privacy counsel. It flags whether each position is a controller (customer) or processor (vendor) one, because DPAs cut both ways and you will sit on different sides of the table depending on the deal. This is general information, not legal advice, and it is not a substitute for privacy counsel on high-risk or large-scale processing.

TL;DR

• Breach notice with no time bound is the top deal-breaker. "Without undue delay" alone is soft. Push for a defined outer limit, ideally 48 to 72 hours from confirmed discovery.
• Blanket subprocessor rights with no notice let the vendor hand your data to anyone. Demand a list, advance notice of changes, and a right to object.
• A DPA carved out of all liability is a trap. If the master agreement (MSA) cap and exclusions swallow data breach, the DPA is decorative.
• Transfers with no valid mechanism (Standard Contractual Clauses or another recognized basis) are a compliance and reputational risk. Do not accept "we will figure it out later."
• Audit rights limited to a self-serve report only are not real audit rights. Report-based review is fine as the default; keep an on-site step for cause.
• On US deals, get the CCPA/CPRA service provider language right. No sale, no share, no use outside your instructions, or the vendor is not a service provider and your exemption breaks.

How to use this playbook

Read the DPA once end to end, then run each clause through the same four questions: what you want, what you can live with, the ladder down, and where you walk. Note your role first. Controllers (the customer deciding why and how data is processed) push for control and accountability; processors (the vendor acting on instructions) push for scope limits and predictable obligations.

The model is deliberately boring: preferred, acceptable range, fallback, walk-away, escalation trigger. Boring is what lets a reviewer move fast and stay consistent across dozens of vendor papers. If you run reviews at volume, Vaquill AI can enforce these playbook positions automatically on a first-pass redline, so the human hours go to the genuine exceptions.

For the narrative walkthrough see the DPA review field guide; this page is the positions. This playbook lives in the contract playbooks hub alongside the master services agreement playbook.

Calibrate to the data, not the template

The same DPA does not deserve the same fight on every deal. Tier your effort by what the vendor actually touches. A marketing tool that sees only business contact names is low risk; a payroll, health, biometric, or child-facing vendor is not.

For low-risk business data, the acceptable range is usually enough: 72-hour breach notice, general subprocessor authorization with objection, and reports-only audit. Do not burn a week red-lining a Calendly-style tool. For sensitive data (HR, health, financial, biometric, geolocation, anything about minors), move up to the preferred column across the board and pull in privacy counsel early.

The clauses that actually consume redline time are subprocessors, breach notice, and the liability interaction. Vendors will almost always resist on-site audit and an uncapped data-breach carve-out; those are the predictable fights. In-house teams tend to over-negotiate the roles recital and under-negotiate the liability cap, which is backwards.

Here is what usually gives and what does not. Vendors concede a 72-hour breach window, a general subprocessor authorization with objection, and SOC 2 report access without much fuss. They rarely concede on-site audit outside a for-cause trigger, and they almost never accept an uncapped data-breach liability. The realistic trade is to give up the on-site audit for a firm breach window and a data-breach super-cap. Spend your leverage there, not on wording nobody enforces.

Playbook at a glance

Roles and characterization

Side: matters most to the controller (customer), who does not want to inherit joint liability.

• Preferred position. The DPA states plainly who is the controller and who is the processor, and confirms the processor acts only on the controller's behalf. Under US state laws, mirror this with the "service provider" or "processor" label the statute uses.
• Acceptable range. A processor that also acts as an independent controller for narrow, disclosed purposes (billing or fraud prevention) is fine if those purposes are listed and separated from your data.
• Fallback ladder. First, name the roles per activity in a schedule. If the vendor resists, list its independent-controller activities and confine them. Last resort, accept dual roles only where each has its own defined obligations.
• Walk-away. Language that makes you a joint controller for everything by default, or leaves roles undefined so liability defaults to shared. Joint control brings shared accountability to data subjects and regulators.
• Escalation trigger. Any hint of joint controllership, or processing the vendor wants for its own product development or model training.

Scope, nature, and documented instructions

Side: controller wants tight instructions; processor wants a clear, closed scope.

• Preferred position. The DPA describes the subject matter, duration, nature, and purpose of processing, the categories of data and data subjects, and states the processor may process personal data only on the controller's documented instructions. This tracks the structure the GDPR requires for processor terms under Article 28.
• Acceptable range. A short instructions schedule that can be updated in writing, plus processing where required by law with prior notice to you (unless notice is legally barred).
• Fallback ladder. First, an itemized instructions schedule. If the vendor wants flexibility, allow updates by written notice. Last resort, a general instruction to process "as necessary to provide the services" with a ban on any other purpose.
• Walk-away. The vendor reserves the right to process your data for its own purposes without a lawful basis you approved, or to train its models on your data with no opt-out.
• Escalation trigger. Any secondary-use, analytics, or model-training language, and any processing of special-category or children's data.

The model-training clause is the one to read twice on any AI vendor. Watch for "service improvement," which is often the polite phrase for training on your data. De-identification is not a free pass, since re-identifiable data can still be personal data, so pin down the standard used. Preferred is no training on your data at all; acceptable is training only on aggregated, truly anonymized data with a clear opt-out; walk away from a use-your-data-to-improve-our-product grant with no way to say no.

Subprocessors

Side: controller wants control; processor wants operational freedom.

• Preferred position. Prior specific written authorization: the DPA lists current subprocessors, and the processor gets your approval before adding new ones.
• Acceptable range. General authorization with notice and objection: advance notice (10 to 30 days), a right to object on reasonable data-protection grounds, and an exit right if the objection is not resolved.
• Fallback ladder. First, a named list plus prior approval. If the vendor needs speed, general authorization with a real notice window and objection right. Last resort, notice via a subscribable page, but only with a right to object and terminate. Either way, the processor must flow down equivalent terms to every subprocessor and stay liable for their failures.
• Walk-away. A blanket right to appoint subprocessors with no notice, no list, and no objection right, or no flow-down of obligations. Your data then moves to unknown parties on unknown terms.
• Escalation trigger. No subprocessor list at all, notice periods under 10 days, or a refusal to remain liable for subprocessor acts.

A workable general-authorization fallback reads like this:

Controller authorizes Processor to engage the Subprocessors listed at [URL].
Processor shall give Controller at least 30 days' notice before adding or
replacing a Subprocessor. Controller may object on reasonable data-protection
grounds; if the parties cannot resolve the objection, Controller may terminate
the affected services. Processor remains liable for its Subprocessors' acts.

On the processor side, this is a reasonable place to land: general authorization keeps operations moving, and a real objection right plus termination gives the customer control without a per-vendor approval bottleneck.

Security measures

Side: controller wants specifics; processor wants a defensible, bounded commitment.

• Preferred position. A security schedule listing concrete technical and organizational measures: encryption of data in transit and at rest, role-based access control, logging, and a named certification such as SOC 2 Type II or ISO 27001. This is the kind of measure the GDPR points to for security of processing under Article 32.
• Acceptable range. A commitment to maintain measures appropriate to the risk, plus a named certification the vendor holds and keeps current, with a right to see the report.
• Fallback ladder. First, an itemized measures schedule. If the vendor prefers to reference its security policy, require it be attached with a no-material-degradation commitment. Last resort, "measures appropriate to the risk" plus a current certification and report you can review.
• Walk-away. "Industry standard security" or "commercially reasonable measures" with nothing named, no encryption, and no certification. Undefined security is unmeasurable and unenforceable.
• Escalation trigger. No encryption of data at rest, no access controls described, or a certification that has lapsed.

Data subject rights assistance

Side: controller carries the legal duty; processor provides the plumbing.

• Preferred position. The processor assists the controller in responding to data subject requests (access, deletion, correction, portability, objection) promptly, at no extra charge, using appropriate technical and organizational measures.
• Acceptable range. Assistance within a defined window (five to ten business days), with reasonable cost-recovery only for high-volume or unusually complex requests.
• Fallback ladder. First, free, prompt assistance. If the vendor wants cost recovery, cap it and tie it to genuinely excessive volume. Last resort, self-service tooling that lets you fulfill requests yourself, plus a backstop of manual help.
• Walk-away. The processor refuses to help, or prices per-request assistance so high you cannot meet statutory deadlines. That leaves you unable to comply.
• Escalation trigger. No mechanism for deletion or access at all, or fees that would make routine compliance impractical.

Personal data breach notification

Side: controller needs speed; processor wants a realistic trigger.

• Preferred position. The processor notifies you without undue delay and no later than 48 hours after it becomes aware of a personal data breach, with follow-up as facts develop. Tie the clock to awareness, not to the vendor's own internal conclusion that an incident is "confirmed" or reportable, or it can run out the string while it deliberates. The controller usually reports to the regulator, and under the GDPR that authority notice is generally due within 72 hours, so your processor needs to move faster than your own deadline.
• Acceptable range. Notice without undue delay and no later than 72 hours after the processor becomes aware, plus cooperation on investigation and on any required data subject notices.
• Fallback ladder. First, a 48-hour outer limit. If the vendor pushes, 72 hours. Last resort, "without undue delay" only if paired with a defined maximum measured from discovery, not from the vendor's own conclusion that a report is required.
• Walk-away. "Without undue delay" with no hour figure, notice only "as required by applicable law," or a clock that starts when the vendor decides the breach is reportable. Each lets the vendor sit on a breach.
• Escalation trigger. Any breach clause with no numeric deadline, or one that ties notice to the vendor's discretion rather than to discovery.

Sample fallback wording that fixes a soft clause:

Processor shall notify Controller of any Personal Data Breach without undue
delay and in any event within 72 hours after Processor becomes aware of it,
and shall provide the information Controller reasonably needs to meet its own
notification obligations, supplementing that notice as further facts emerge.

Audit rights

Side: controller wants verification; processor wants to avoid disruptive on-site visits.

• Preferred position. The controller may verify compliance through the processor's current audit reports and certifications, and may conduct or commission an on-site audit for cause or after a breach, on reasonable notice.
• Acceptable range. Report-based review as the default (SOC 2 or ISO reports on request), plus a once-a-year or for-cause on-site right with cost allocation for excessive requests.
• Fallback ladder. First, reports plus for-cause on-site. If the vendor resists on-site, keep it for post-breach and regulator-driven situations only. Last resort, reports plus a written questionnaire the vendor must complete, with a cooperation duty.
• Walk-away. Audit limited to a self-serve report page with no cooperation duty, no on-site step even after a breach, and no obligation to answer questions. That is a brochure, not an audit right.
• Escalation trigger. No cooperation obligation, no path to verify after a breach, or reports gated behind fees.

International transfers

Side: both sides carry risk; the controller carries the regulator-facing exposure.

• Preferred position. The DPA names a valid transfer mechanism for any personal data leaving its origin jurisdiction, such as the Standard Contractual Clauses (SCCs) for EU or UK data, or an approved equivalent, and identifies where data is stored and processed.
• Acceptable range. Data residency in named regions plus the SCCs or another recognized mechanism incorporated by reference, with a commitment to update it if the legal basis changes.
• Fallback ladder. First, SCCs (or the relevant equivalent) attached and completed. If the vendor references them, require the annexes be filled in. Last resort, a commitment to put a valid mechanism in place before any regulated transfer, with your right to pause transfers until it is.
• Walk-away. Cross-border transfers with no mechanism named, or a promise to "comply with applicable law" with nothing concrete behind it. Unmechanized transfers of regulated data are a live compliance gap.
• Escalation trigger. Any transfer of EU, UK, or other regulated data, unfilled SCC annexes, or storage in a jurisdiction you did not expect.

Return and deletion at termination

Side: controller wants clean exit; processor wants a workable retention carve-out.

• Preferred position. On termination, the processor returns or deletes all personal data at the controller's choice, deletes existing copies, and certifies deletion in writing within a defined period.
• Acceptable range. Return or deletion within 30 to 90 days, with a narrow carve-out for backups on a defined rotation and data the vendor must keep by law, all still protected by the DPA until deleted.
• Fallback ladder. First, choice of return or deletion plus certification. If the vendor needs backup retention, cap the window and require deletion at the end of the cycle. Last resort, deletion on a fixed schedule with the DPA's obligations surviving until the last copy is gone.
• Walk-away. The vendor keeps your data indefinitely, has no deletion duty, or will not certify. Data you cannot get back or confirm destroyed is an open-ended liability.
• Escalation trigger. No deletion obligation, no certification, or a backup carve-out with no end date.

Liability and interaction with the MSA cap

Side: controller wants breach exposure to bite; processor wants a predictable ceiling.

• Preferred position. Data breach and privacy violations are carved out of the general liability cap, or given a separate higher super-cap, and are excluded from the "no indirect damages" waiver to the extent of statutory fines and third-party claims.
• Acceptable range. A dedicated data-incident super-cap (a multiple of fees, or a fixed figure) that sits above the general cap, with regulatory fines and data subject claims inside it.
• Fallback ladder. First, a full carve-out for data breach. If the vendor refuses, a super-cap several times the general cap. Last resort, ensure the DPA is not swept under a low general cap combined with a broad exclusion of the exact damages a breach causes.
• Walk-away. The DPA is fully inside a low general cap and the exclusions waive the indirect and consequential damages a data breach actually produces. That leaves the cap on paper and the exposure on you.
• Escalation trigger. Any attempt to fold data breach into a one-times-fees cap, or to exclude regulatory fines and notification costs. Read this clause together with the limitation of liability and confidentiality clauses, since they interlock.

In practice, a full carve-out is realistic on high-value or high-risk deals where you have leverage; on a low-value SaaS subscription it is often performative and the vendor will not sign it. The middle ground that actually settles is a super-cap: commonly 2x to 5x the annual fees, or a fixed cyber figure, sitting above the general cap and covering fines and notification costs. If you cannot get either, at minimum keep data breach out of the "no indirect or consequential damages" waiver, since those are the damages a breach produces.

US state law: CCPA/CPRA service provider terms

Side: controller (business) needs the vendor to qualify as a service provider; processor wants to accept those limits cleanly.

A quick note on state variation before the positions. California uses the "service provider" and "contractor" labels and the no-sale, no-share framing under the CCPA as amended by the CPRA. The newer comprehensive laws (Colorado, Connecticut, Virginia, and Texas among them) use "controller" and "processor" and require a written contract with a defined set of processor duties: process only on instructions, confidentiality, security, subprocessor terms, deletion, and cooperation on assessments. The duties rhyme across states, so a single well-drafted DPA can satisfy most of them, but the California sale/share language is the piece you cannot skip.

• Preferred position. The DPA states the vendor is a "service provider" (or "processor" or "contractor" as the relevant state uses), and includes the required restrictions: no selling or sharing the personal information, no retaining, using, or disclosing it outside the direct business relationship or your written instructions, and no combining it with other sources except as permitted.
• Acceptable range. The full service provider restrictions plus a certification that the vendor understands and will comply, and a right for you to take reasonable steps to stop and remediate unauthorized use.
• Fallback ladder. First, the complete statutory service provider language. If the vendor's paper is thin, add the missing restrictions by addendum. Last resort, secure the no-sale, no-share, and purpose-limitation terms, which are what keep the exemption intact.
• Walk-away. The vendor rejects the service provider restrictions or reserves a right to use your data for its own purposes. Without those terms the disclosure can count as a sale or share, and your exemption breaks.
• Escalation trigger. Any right to monetize, share for cross-context advertising, or use your data for the vendor's own analytics or product development.

The verdict

A DPA is only as strong as its weakest of five clauses: breach notice, subprocessors, security, transfers, and liability. Get a defined breach window, a controlled subprocessor process, named security measures, a valid transfer mechanism, and a liability structure where data breach actually bites. Fix those and the rest is cleanup.

Know your role before you read a word. Controllers push for control and accountability; processors push for closed scope and predictable duties. The positions above give you a consistent line to hold and a clear ladder down, so you spend your negotiation capital on the clauses that decide whether a breach is recoverable or ruinous.

FAQ

What is a DPA playbook? It is a reviewer's guide to one contract type, the data processing agreement, that sets a preferred position, an acceptable range, a fallback ladder, and a walk-away line for each key clause. It lets an in-house team review vendor DPAs quickly and consistently, and it flags whether each position is a controller or processor one, since you argue different things depending on your side.

Are DPAs required in the US? There is no single federal DPA mandate, but state privacy laws effectively require the terms. California's CCPA and CPRA require specific service provider or contractor terms for a disclosure to avoid counting as a sale or share, and other state laws impose similar processor requirements. Deals that touch EU or UK data also pull in the GDPR's processor terms.

How fast must a processor report a data breach? The baseline standard is "without undue delay," which on its own is soft. Push for a defined outer limit measured from confirmed discovery, ideally 48 hours and no more than 72. The controller often must notify the regulator within 72 hours under the GDPR, so the processor has to move faster than the controller's own deadline.

Should you allow subprocessors? Usually yes, because vendors rely on infrastructure and tooling. The control is process: get a current list, advance notice of changes, a right to object, and flow-down of equivalent terms with the processor staying liable. Refuse blanket appointment rights with no notice, list, or objection.

What security terms should a DPA require? Concrete measures, not adjectives. Look for encryption of data in transit and at rest, role-based access control, logging, and a named certification such as SOC 2 Type II or ISO 27001 that the vendor keeps current. "Industry standard security" with nothing named is unenforceable.

How does a DPA interact with the MSA liability cap? That interaction decides whether the DPA has teeth. If data breach is folded under a low general cap and the exclusions waive the damages a breach causes, the DPA is decorative. Push to carve data breach out of the cap, or give it a higher super-cap, and keep regulatory fines and third-party claims inside it.

Can AI review a DPA against a playbook? Yes. A tool that holds your standard positions can flag deviations on a first pass, mark the walk-away clauses, and draft fallback language, so a reviewer starts from a redline instead of a blank page. Vaquill AI applies playbook positions this way, with a human deciding the genuine exceptions. Treat the output as a first draft, not a signature.

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.