The Adequacy Carousel: Why Your EU Data Strategy Shouldn't Depend on the Next US Privacy Framework

Three dates the EU privacy world is watching:

• ▸3 September 2025 — the General Court of the European Union upholds the EU-US Data Privacy Framework.
• ▸31 October 2025 — the framework is appealed to the Court of Justice.
• ▸Sometime in 2026 — the CJEU rules.

Even Max Schrems, whose organisation noyb filed the appeal, has publicly said he expects it to fail on standing grounds — dismissed before the merits are reached. That doesn't end the cycle. Schrems' broader position is that the only durable answer in 2026 is data localisation, and the legal history backs him up.

If your stack depends on the answer the CJEU lands on, this post is for you.

A short legal timeline

To understand why we're here a fourth time, the timeline matters:

• ▸2000–2015 — Safe Harbor. The original framework letting US companies receive EU personal data. The CJEU strikes it down in Schrems I (2015) after Edward Snowden's disclosures show what FISA §702 actually does.
• ▸2016–2020 — Privacy Shield. The replacement. Same idea, fresh paint. Struck down in Schrems II (2020) on essentially the same grounds: EU privacy law and US surveillance law remain in genuine tension, and a self-certification framework can't bridge it.
• ▸2023 — Data Privacy Framework (DPF). The third attempt, adopted by the European Commission in July 2023. Most US-incorporated SaaS providers — Vercel, Supabase, Stripe, Datadog, OpenAI, GitHub — now point at the DPF as their legal basis for receiving EU personal data.
• ▸3 September 2025 — Latombe v. Commission (T-553/23). The General Court upholds the DPF: at the time of adoption, the US offered "adequate" protection.
• ▸31 October 2025. noyb files an appeal to the CJEU.
• ▸2026. The CJEU rules. Schrems himself has said the appeal will probably fall on standing grounds — but the underlying tension is unchanged, and recent structural changes to US oversight bodies (the Privacy and Civil Liberties Oversight Board, the Federal Trade Commission) are already raising fresh questions about whether the redress mechanisms the DPF relies on still function.

Three frameworks in twenty-five years. Two struck down. One contested. The cycle has been about three to five years long since 2000, and the gap between cycles is not getting longer.

What's at stake if the DPF falls

Your stack does not go offline. The DPF is a paperwork instrument, not a packet filter. But every US-incorporated vendor in your processing record needs new contractual scaffolding within weeks — and the speed of that scaffolding is the part the executive summaries leave out.

In 2020, when Schrems II invalidated Privacy Shield overnight, tens of thousands of EU companies spent the next eighteen months rebuilding their transfer paperwork: signing Standard Contractual Clauses with each vendor, performing Transfer Impact Assessments per processing activity, mapping where their end-users' data physically routes through which subprocessor in which country, and either accepting the residual risk or migrating workloads. Some did it fast. Many didn't, and quietly carried unresolved transfer risk for the next two years.

If the DPF is struck, the same exercise repeats. If the DPF is upheld but the political ground under it keeps shifting, the exercise still repeats — just on a slower clock.

The thing that makes any of this not your problem is if the question of cross-Atlantic transfer doesn't apply to your stack in the first place.

A four-level test for any vendor

When you next evaluate a backend or a cloud, ordered easiest to hardest:

L1 — Data residency. The bytes physically sit in an EU data centre. This is the minimum, and it's what most "we have an EU region" stories deliver. It addresses latency for EU users and a narrow, surface-level reading of GDPR Art. 44 (cross-border transfers).

L2 — Legal jurisdiction. The entity that controls the bytes is established in the EU and answers to EU courts first. This is the level the entire DPF debate is fundamentally about. If your provider is EU-jurisdiction, the adequacy carousel is not your problem — there is no transatlantic transfer to argue about.

L3 — Ownership. The provider's parent company and capital structure sit in the EU. This guards against an M&A event or a board decision elsewhere flipping the answer overnight. A vendor that's L2 today but acquired by a non-EU buyer next year is back at L1 the day the deal closes.

L4 — Operational independence. The provider's support staff, sub-processors, backup pipelines, log analytics and payment partners all stay in the EU too. This is the level where most "sovereign cloud" claims fall over: a support engineer in California opens a customer ticket attachment, a backup silently replicates to us-east-1, an observability vendor ingests log lines containing end-user emails. None of that is hostile — it's just operational drift. But it's what an EU regulator looks at when they look hard.

What each level actually protects

Each level builds on the last. Earning L1 is not a failure; it's the right level for some workloads. The point of the test is to make the choice deliberate.

Apply the test to a typical "EU stack"

A common modern EU-region stack, rated honestly:

This is not a hit piece. It's the maths. Most of the modern developer toolkit is L1 — and that's a deliberate choice you can make if the trade-offs are worth it. The point is to know.

Where Eurobase sits

We built the platform to clear all four levels by default:

• ▸L1: yes. Compute, database, storage, and email all run on Scaleway in France (DC-PAR1 / DC-PAR2).
• ▸L2: yes. Eurobase is a French entity. (Currently in registration; SIRET will publish on the imprint page on incorporation.)
• ▸L3: yes. EU-owned cap-table by design; structure published on incorporation.
• ▸L4: substantially. All sub-processors are EU-based by default — Scaleway in France, GatewayAPI in Denmark, Mollie in the Netherlands when paid plans launch. Google and GitHub OAuth are opt-in per project, off by default, and any active sub-processor surfaces in your live compliance report so you always know your data map.

Want to verify any of this? The compliance report inside any Eurobase project lists every active sub-processor, its jurisdiction, its certifications, and the data categories it sees. It's generated from the same database the platform uses to run — not a static page that drifts from reality.

The take-away

The four-level test is vendor-agnostic. Print it, take it to your CTO, your CISO, and your legal counsel. Whichever provider you end up picking, ask them where they sit on each level. They should be able to answer in two sentences. If they need a paragraph, that's information too.

Adequacy frameworks come and go. Where your vendor is established does not.

If you'd like a backend that's L4 by default, sign up free.