What is a "Global DPA," and does it actually cover every regime?
A "Global DPA" is a vendor's claim that one data processing addendum covers GDPR and every other privacy regime that applies to your data, in a single document. That claim often doesn't hold up. A contract can use GDPR's vocabulary correctly, controller, processor, data subject rights, DPIA, and still fail to do what GDPR's Article 28 actually requires, the way a product can carry an "organic" label nobody has checked against the ingredients. We call this GDPR-washing: language that reads right without holding up.
The EU side is a fixed checklist. The US side is a patchwork. Those are two different kinds of documents pretending to be one.
| EU (GDPR Article 28) | US (state statutes) | |
|---|---|---|
| Legal structure | A single prescriptive article; a required element that's missing makes the DPA deficient as a matter of law | No single federal statute; state laws (CCPA/CPRA, VCDPA, CPA, CTDPA, others) share a common core but differ on wording and thresholds |
| Classification test | Controller and processor roles turn on who determines purposes and means of processing | CCPA turns on a specific label: classification as a "service provider" or "contractor" rather than as a recipient of a "sale" or "share" |
| Transfer mechanism | Standard Contractual Clauses required for transfers to a country GDPR treats as a third country | No domestic equivalent to SCCs; only relevant if the US vendor pushes data onward to a GDPR third country |
| Additional layer | Member states add rules on top of GDPR (e.g., German works council involvement, AGB-Recht liability limits) | No equivalent state-on-state layering; obligations come directly from the applicable state statute |
What does the EU side actually require under GDPR Article 28?
GDPR's Article 28(3) is prescriptive. A processor agreement must cover each of the following. If a required element is missing, the DPA is deficient as a matter of law, there's no judgment call.
01Subject matter, duration, nature, and purpose of processing
The contract has to actually describe the processing, not just reference it in general terms.
02Categories of data and data subjects
What kinds of personal data, and whose, the processor is handling.
03Processing only on the controller's instructions
The processor can't determine its own purposes for the data, that's what separates a processor from a controller.
04Confidentiality
Personnel authorized to process the data must be under a confidentiality obligation.
05Security measures under Article 32
Technical and organizational measures appropriate to the risk, not a generic security promise.
06Sub-processor authorization
General or specific authorization, with a right to object, not mere notice.
07Assistance with data subject rights, breach notification, and DPIAs
The processor has to help the controller meet its own obligations in each of these three areas.
08Deletion or return of data at termination
The processor's copy of the data doesn't just linger once the contract ends.
09Audit rights
The controller (or a mandated third party) has to be able to actually verify compliance.
Does GDPR compliance mean the DPA is done?
No. GDPR is only a floor. Member states layer national rules on top of it. Employee data in Germany, for instance, often needs works council involvement independent of anything the DPA says, and German standard-terms law (AGB-Recht) restricts what a liability clause can validly do regardless of what GDPR itself requires. A DPA that's "GDPR compliant" in the abstract can still fail once you check it against the specific member state your data actually touches.
What governs a DPA when the vendor is US-based?
The US has no equivalent single article. Obligations come from state statutes, CCPA/CPRA, VCDPA, CPA, CTDPA, and others, that share a common core: process only as instructed, secure the data, delete on request, no independent use by the processor. But the statutes differ on wording and thresholds.
CCPA in particular turns on a specific label: the vendor has to qualify as a "service provider" or "contractor," rather than as a recipient of a "sale" or "share." Miss that language and the classification, and the exposure that comes with it, can shift.
Does a US vendor need Standard Contractual Clauses?
Only in one specific situation. There's no domestic US equivalent to SCCs. They matter for a US vendor only if that vendor is pushing your data onward to a jurisdiction GDPR treats as a third country. A purely domestic US vendor relationship, with no onward international transfer, doesn't trigger this requirement.
Where does "GDPR-washing" actually show up in real contracts?
Most templates start as US SaaS boilerplate with GDPR language stapled on. Three clauses are worth checking first, because they tend to predict how the rest of the document holds up.
Check your DPA's language. Pick a clause type below and we'll show you the common defect, no email required.
What's the real question to ask when comparing vendors?
The real question is narrower than that: does the EU-facing language track GDPR Article 28(3) in substance rather than only in the label it uses; is there a valid transfer mechanism actually attached rather than merely referenced; and does the US-facing language correctly classify the vendor's role under the statute that governs your data. A single well-drafted document can clear all three. Plenty of "Global DPAs" clear none of them, because the underlying draft was built to the more permissive standard and left that way.
What should you do about this?
We run this exact review for clients before it surfaces in due diligence or a breach, checking vendor DPAs against both regimes and flagging what's missing before it's relied on. If you want a vendor contract checked, or want a DPA built to hold up on both sides from the start, reach out to General Legal.
Quick answers
- Does a "Global DPA" automatically satisfy both GDPR and US state law?
- No. It often uses the right vocabulary without meeting the substantive requirements of either regime.
- What makes an EU DPA deficient under GDPR Article 28?
- Missing any of the required elements, subject matter, security measures, sub-processor authorization, audit rights, and more, makes the DPA deficient as a matter of law.
- Does GDPR compliance cover every EU member state requirement?
- No. Member states layer additional rules on top, such as German works council involvement and AGB-Recht liability restrictions.
- What's the key classification test under CCPA?
- Whether the vendor is a "service provider" or "contractor," rather than a recipient of a "sale" or "share."
- Does a US-only vendor need Standard Contractual Clauses?
- Only if that vendor pushes the data onward to a country GDPR treats as a third country.
- Your Sub-Processor List Is Probably Wrong [Explained]Ask most startups for a sub-processor list, get a vendor list instead—that gap is where GDPR exposure quietly sits.
- A GDPR-Compliant Vendor Doesn't Automatically Mean Your Data Transfer Is LegalYour vendor says they're GDPR compliant. That doesn't mean your data transfer to the US is legal—those are two separate question