Back to blog

GDPR Data Transfers Are the One Compliance Risk You Can Architect Away

The EU-US Data Privacy Framework survived its first court challenge but is now on appeal to the CJEU. Analytics that never transfers EU data to the US has nothing to lose either way.

Most GDPR risk is procedural — a notice you can rewrite, a retention window you can shorten, a consent flow you can fix. International data transfers are different. They depend on a legal instrument you do not control and cannot patch, and that instrument has been struck down twice in a decade. The only durable fix is architectural: never transfer the data in the first place.

The transfer mechanism keeps collapsing

GDPR Chapter V forbids sending personal data to a country without an adequate level of protection unless you have a valid transfer mechanism. For EU-to-US flows, that mechanism has a graveyard. The CJEU invalidated Safe Harbour in 2015 (Schrems I) and Privacy Shield in 2020 (Schrems II), both because US surveillance law gave EU citizens no real redress.

The current instrument is the EU-US Data Privacy Framework (DPF), adopted in 2023. On 3 September 2025 the General Court of the EU dismissed the first challenge to it, in Latombe v Commission (Case T-553/23), upholding the Commission's adequacy decision.

That is not the end of the story. Latombe filed an appeal to the Court of Justice on 31 October 2025, and noyb — Max Schrems' organisation — has signalled it is preparing a broader challenge to the DPF on the same surveillance grounds that sank the last two frameworks. The court that killed Safe Harbour and Privacy Shield will get another look.

Why this lands on analytics specifically

Analytics is the most common way a small EU site ends up making a US transfer without realising it. The browser sends an event; a US-headquartered analytics provider receives the visitor's IP address and behavioural data on US infrastructure. That is a transfer of personal data, and it inherits whatever legal status the DPF has on any given day.

Regulators already treated this as unlawful before the DPF existed. After noyb's coordinated complaints, the Austrian DSB ruled in 2022 that EU-to-US transfers via Google Analytics breached Chapter V, and DPAs in France, Italy, Denmark, Finland, Sweden, and Norway followed with the same reasoning. The IP address reaching US servers was enough.

If the CJEU invalidates the DPF, those rulings become the template again, overnight, for every tool still routing EU visitor data to the US.

Architecting the risk out

You cannot make the DPF more stable. You can build a data flow that has no Chapter V exposure to begin with. Two properties do it:

Process at the edge, in-region. Cloudflare's Data Localization Suite lets a Worker confine processing and logs to EU data centres, so the request never leaves the region it originated in. The decision about where data is handled becomes infrastructure configuration, not a legal instrument you hope survives appeal.

Never persist the identifying inputs. The raw IP and User-Agent that make a request "personal data" exist only in memory long enough to compute a daily visitor hash, then they are discarded:

visitor_hash = SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)

What gets stored is the hash, not the inputs. Because the salt rotates daily and is secret, the hash cannot be reversed to an individual or joined across days. There is no profile, and nothing identifying ever crosses a border because nothing identifying is ever retained.

You can verify the geography of the flow at the wire. A pageview beacon is a single request to a first-party endpoint you control:

POST /collect HTTP/2
Host: api.monoid.website
Content-Type: application/json

{"site_id":"...","path":"/pricing","referrer":"..."}

If api.monoid.website resolves to EU edge nodes and the Worker pins its storage to the EU, there is no US processor in the path, no adequacy decision to rely on, and no transfer to disclose. The country of the visitor still comes through — derived from the edge's own geolocation, not from shipping the IP to a third party.

The compliance posture this produces

A transfer you never make is a transfer you never have to defend. There is no DPF to cite in your records of processing, no standard contractual clauses to maintain, no transfer impact assessment to redo when the legal ground shifts, and no sub-processor in a third country to disclose under the transparency rules regulators are auditing in 2026.

Every other analytics compliance task is something you keep doing. Eliminating the transfer is something you do once, in the architecture, and then stop thinking about — regardless of how the CJEU rules on the appeal.

Sources

Comments

Loading comments…