Data processing agreements: what a DPA must contain

A data processing agreement (DPA) is the contract that lets a vendor handle personal data on your behalf without becoming a free agent with it. GDPR spells out what it must say. The CCPA has its own list. If the data crosses borders, transfer clauses get attached. Here's what each part has to cover and where the real negotiation happens.

Most DPAs are vendor templates. That's fine, because the legal minimum is fairly standardized, but templates differ a lot in the details that matter when something goes wrong: breach notice timing, audit rights, sub-processor changes and liability. This page goes through the mandatory content first, then the points worth negotiating, then a review checklist. It's general information, not legal advice.

When you need a DPA

Under GDPR, whenever a processor handles personal data on behalf of a controller. A processor acts on your instructions and for your purposes: cloud hosting, email delivery, a CRM, payroll, a support desk, a privacy tool. If the vendor decides its own purposes for the data (an ad network building profiles, for example), it's a controller in its own right, and a controller-to-controller agreement fits instead.

Article 28(9) requires the contract to be in writing, which includes electronic form. A click-through DPA incorporated into the terms counts. Processors also need DPAs with their own sub-processors, carrying the same obligations down the chain.

Under the CCPA, the equivalent is the contract that makes a vendor a service provider or contractor. Without it, handing over personal information can count as a "sale" or "sharing", with all the opt-out obligations that follow. Most other US state privacy laws (Virginia, Colorado, Connecticut, Texas, Oregon and others) also require a written controller-processor contract with listed terms. Those lists largely overlap with GDPR's.

GDPR Article 28(3), clause by clause

Article 28(3) requires the contract to describe the processing and then commit the processor to eight specific obligations. A DPA missing any of them doesn't meet the article.

The description of processing

The contract must set out the subject matter and duration, the nature and purpose of the processing, the types of personal data, the categories of data subjects, and the controller's obligations and rights. In practice this is an annex. It's often the weakest part of a template, with "customer data as uploaded by customer" doing a lot of work. For high-risk processing, ask for specifics that match your data map and ROPA.

The closing sentence of Article 28(3) adds one more duty: the processor must immediately inform the controller if it thinks an instruction infringes GDPR or other EU or member-state data protection law.

The Commission has published optional standard contractual clauses for controller-processor agreements under Article 28(7) (Implementing Decision (EU) 2021/915). Few vendors use them as their DPA. They are, however, a useful benchmark for what complete wording looks like.

CCPA service provider and contractor terms

The CCPA statute (Civil Code §1798.100(d) and the definitions of "service provider" and "contractor" in §1798.140) and the regulations at 11 CCR §7051 require the contract to:

1. Prohibit selling or sharing the personal information.
2. Identify the specific business purposes for processing. The regulations say these can't be described generically, for example by referring to the entire agreement.
3. Prohibit retaining, using or disclosing the information for any purpose other than those business purposes, including any other commercial purpose.
4. Prohibit using it outside the direct business relationship, including combining it with data from other sources or the vendor's own consumer interactions, except as the regulations allow.
5. Require compliance with the CCPA and the same level of privacy protection the business must provide (including help with consumer requests and reasonable security).
6. Give the business the right to take reasonable steps to make sure the vendor uses the data consistently with the business's obligations, such as manual reviews, automated scans, and regular assessments or audits (at least once every 12 months, as one example in the regulations).
7. Require the vendor to notify the business if it can no longer meet its obligations.
8. Give the business the right, on notice, to take reasonable steps to stop and remediate unauthorized use.
9. Require the vendor to help the business honor consumer requests, or have the business tell the vendor which requests to act on.

A contractor (someone the business makes personal information available to, rather than one who processes it on the business's behalf) must also certify that it understands and will comply with the restrictions. Subcontracting needs a contract with the same terms (§7051(b)).

A good DPA handles GDPR and CCPA in one document, with a US state addendum or a section that maps the terms above. If the vendor's DPA only covers GDPR, ask for the CCPA terms before signing.

International transfers

If the processor (or a sub-processor) is outside the EEA, or support staff access data from outside it, the transfer needs a legal basis under GDPR Chapter V. The DPA is where the transfer mechanism is attached.

Where the EU-US Data Privacy Framework stands

The Commission adopted its adequacy decision for the EU-US Data Privacy Framework (DPF) on 10 July 2023. It covers US organizations that self-certify with the Department of Commerce and appear on the DPF list. There are parallel extensions for the UK (the "UK-US data bridge") and Switzerland.

On 3 September 2025, the EU General Court dismissed the challenge in Latombe v Commission (Case T-553/23) and upheld the adequacy decision. The applicant appealed to the Court of Justice (Case C-703/25 P). At the time of writing, no judgment on the appeal has been reported; check the case page for its current status. The DPF is valid and usable until a court rules otherwise. Its two predecessors, Safe Harbor and Privacy Shield, were both struck down by the Court of Justice, however, so many organizations put SCCs in place as a fallback. If a US vendor relies on the DPF, check it's on the DPF list with the right scope (HR or non-HR data), and ask whether its DPA includes SCCs that would apply if the DPF fell.

Negotiation points

The mandatory clauses are rarely where disputes happen. These are:

• Breach notification timing. GDPR requires the processor to notify the controller "without undue delay" (Article 33(2)), and the controller has 72 hours to notify the regulator. Ask for a specific number of hours, a definition of what triggers notice (a confirmed breach versus a suspected one), and the minimum content of the first notice.
• Audit rights. Vendors offer SOC 2 or ISO reports and questionnaire answers. Controllers want on-site audits. A common middle ground: reports first, with an on-site or remote audit allowed after a breach, a regulator request, or when the reports don't answer a specific concern, at reasonable notice and frequency.
• Sub-processor changes. How much notice (30 days is common), how you're notified (email subscription, not just a web page that changes), what happens if you object, and whether you can terminate without penalty. Covered in detail in Sub-processor lists.
• Liability. Whether data protection breaches fall under the general liability cap, a higher "super cap", or are uncapped. This is a commercial point and often the hardest one.
• Government access requests. A commitment to challenge overbroad requests, notify you where legally allowed, and publish a transparency report.
• Assistance costs. Whether help with DSRs, DPIAs and audits is included or billed.
• Deletion and return. Format of the export, how long you have to retrieve data, and how long backups persist.
• Data location. Whether the hosting region is a contractual commitment or just a current practice.
• Vendor's own use of data. Product improvement, analytics and AI model training. These are separate purposes, and under the CCPA they need to fit the regulation's limited exceptions. Read these clauses closely.
• Order of precedence. If the DPA and the main agreement conflict, the DPA should win on data protection matters. If SCCs are attached, they win over both.

DPA review checklist

Use this when a vendor DPA lands on your desk. The buyer's checklist covers the wider vendor evaluation.

1. Roles. Is the vendor correctly described as processor / service provider? Any processing where it acts as a controller is called out separately.
2. Processing annex. Subject matter, duration, nature, purpose, data types and data subject categories are filled in and accurate.
3. All eight Article 28(3) obligations (a)-(h) are present, plus the duty to flag infringing instructions.
4. Security annex describes real measures, and you've compared it with the vendor's assurance report.
5. Sub-processors. A list is linked, with a notice mechanism you can subscribe to, a notice period and an objection right.
6. Breach notice. A specific timeframe and minimum content.
7. Data subject request support through product features, with a timeline for forwarding requests sent to the vendor.
8. Audit. Reports available, plus an audit right that can be used in practice.
9. Deletion and return at the end, with a timeline, backups addressed, and certification on request.
10. CCPA terms. The §7051 items are present, with specific business purposes and no sale or sharing.
11. Transfers. The right mechanism (adequacy/DPF, SCCs with the right modules, UK IDTA or Addendum), annexes completed, and a transfer impact assessment on file.
12. Vendor's own use (analytics, product improvement, AI training) is limited and acceptable to you.
13. Liability and precedence clauses checked by counsel.
14. Filed and tracked. The signed DPA is linked from your vendor inventory and ROPA, with a review date.

Common questions

Need this built?

If you would rather have this implemented than read about it, tell us about your project and we will reply with questions or a rough plan.