What Is the Data Privacy Framework (DPF)?
The EU-US Data Privacy Framework (DPF) is an adequacy-based transfer mechanism that lets personal data be sent to certified US recipients without a separate transfer impact assessment. That differs from SCC, which requires its own assessment. Which mechanism applies depends on the vendor path – and DPF's durability is currently being challenged in court.
When personal data is headed to a US AI provider, the transfer needs a lawful basis. The EU-US Data Privacy Framework – DPF – is one of two common such bases. Understanding what DPF is, and where it differs from Standard Contractual Clauses, determines how much analysis work falls on you.
What DPF Is
The Data Privacy Framework is an adequacy decision from the European Commission. It means the EU has determined that US recipients certified under the framework offer a level of protection essentially equivalent to the EU’s own. Transfers to such a certified recipient therefore require no separate transfer impact assessment – the adequacy decision carries the basis.
That’s the central difference from Standard Contractual Clauses (SCC). With SCC, you have to carry out a Transfer Impact Assessment yourself and add technical safeguards. With DPF, the burden of proof shifts to the certification: if the recipient is on the list, the transfer basis is in place.
A common misconception is that DPF thereby settles the entire question of US data access. It doesn’t. DPF gives the transfer a lawful basis under GDPR, but that doesn’t change the fact that a US recipient still falls under US legislation such as the CLOUD Act. The adequacy decision says the level of protection has been judged sufficient at the system level – it isn’t a promise that an individual government request can never reach the data. DPF and the question of government access are therefore two separate layers that both need managing, not just one.
The Mechanism Differs by Vendor Path
Here’s where it gets practically important. Which mechanism applies depends on which provider and which path you choose.
Some providers, Microsoft and OpenAI for example, are active DPF participants – their transfers can rest on the adequacy decision. A direct path to a different provider, like Anthropic, may instead rely on SCC plus your own transfer impact assessment (TIA). The same type of service can therefore have a different transfer mechanism depending on how you buy it.
A concrete scenario: a company assumes “US AI = DPF” and documents the transfer accordingly. During the review, it turns out the specific vendor path they chose rests on SCC, not DPF – and the TIA is missing. The lesson is that you need to know exactly which mechanism your path uses, not assume a generic one.
Durability Is Being Tested in Court
DPF is the third in a line of mechanisms for EU-US transfers. The two predecessors, Safe Harbor and Privacy Shield, were both struck down by the EU Court of Justice. DPF’s durability is now being tested again, in what’s known as the Latombe case at the EU Court of Justice, among other proceedings.
That doesn’t mean DPF is invalid today – it applies. But the history calls for caution. Building an architecture that fully assumes DPF will last forever means repeating a mistake that’s already been made twice.
Checkpoints for the Buyer
When you review an AI contract that invokes DPF, there are a few things to check off:
- Current certification. Is the provider actually on the official DPF list right now, for the right type of data? Check it – don’t rely on marketing copy.
- The right mechanism for your path. Does your specific path rest on DPF or on SCC? The assumption “US AI = DPF” doesn’t hold; it depends on the provider and the purchase path.
- Fallback mechanism in the contract. Is SCC available as a fallback in case DPF falls? That’s the most common and wisest safeguard.
- An architecture that tolerates a shift. Is the solution built so you can switch transfer basis without redoing everything?
Build for a Mechanism Shift
The practical lesson: build so a change in transfer mechanism doesn’t tear down the whole solution. Have a fallback mechanism in the contract – usually SCC – and an architecture where you can shift basis without redoing everything.
And since the participant list changes: always check the provider’s current DPF status on the official list before signing a contract. A certification that was valid last quarter may have changed.
If you’d like to see how DPF connects to SCC, residency, and government access across a full AI project, there’s more on our AI page. Need help figuring out which transfer mechanism your setup actually rests on? Get in touch.
Frequently asked questions
What's the difference between DPF and SCC?
DPF is an adequacy decision: the EU has determined that certified US recipients offer sufficient protection, so the transfer requires no separate analysis. SCC are contract clauses that you supplement yourself with a transfer impact assessment (TIA) and supplementary measures. DPF shifts the burden of proof from you to the certification – SCC places it on you.
Are all US AI providers part of DPF?
No. Participation differs by provider and contract path. Some providers are active DPF participants, while other paths instead rest on SCC plus your own transfer impact assessment. The transfer mechanism can therefore differ depending on whether you buy direct or through a cloud platform – check which one actually applies.
How do I know if a provider is DPF-certified?
Certified organizations are listed in the official DPF list, maintained by the US Department of Commerce. Check current participation status there before signing a contract – a certification may have changed or lapsed. A provider having been listed before is no guarantee it's listed today.
Is the Data Privacy Framework legally secure in the long run?
It's being challenged in court. DPF's durability is under review at the EU Court of Justice (the Latombe case), the same way earlier mechanisms were struck down. The wise approach is to build the architecture so a change in transfer mechanism doesn't tear down the whole solution, rather than assuming DPF will last forever.
What happens if DPF is struck down?
Then transfers have to rest on a different basis, in practice usually SCC plus your own transfer impact assessment. It's happened before: both Safe Harbor and Privacy Shield fell. That's why contracts should have a fallback mechanism, and the architecture should be built so a shift can happen without redoing everything.