In August 2024, a single category of cross-border data transfer cost Uber 290 million euros. The Dutch Data Protection Authority found the company had moved European drivers’ personal data to servers in the United States without adequate safeguards, one of the largest transfer-related penalties in GDPR history (EDPB). A cross-border data transfer under GDPR is any movement of personal data from the European Economic Area to a recipient in a country outside it, and GDPR treats every such transfer as prohibited by default unless a specific legal condition is satisfied. Uber was not hacked. It simply moved data the way most multinationals do, and that is precisely the point regulated industries keep missing.
TL;DR
- Under GDPR, a cross-border data transfer is any personal data leaving the EEA, or becoming accessible from outside it. It is banned by default; the burden is on you to justify it.
- Since the Schrems II ruling, picking a transfer mechanism is the beginning of compliance, not the end. You must also prove the destination actually protects the data.
- The mechanisms, adequacy decisions, Standard Contractual Clauses, Binding Corporate Rules, and narrow Article 49 derogations, each carry a different burden and a different fragility.
- The EU-US Data Privacy Framework is valid in 2026 but has survived one court challenge, faces an appeal, and rests on US oversight that is itself under pressure. Two predecessors were struck down.
- Encryption and privacy-enhancing technologies that keep data unreadable in the destination are the one safeguard a court cannot annul, which is why they anchor any transfer strategy meant to outlast the next ruling.
When Does GDPR Treat a Data Flow as a Cross-Border Transfer?
GDPR treats a data flow as a cross-border transfer whenever personal data originating in the European Economic Area is sent to, stored in, or simply made accessible from a country outside it. That last clause catches organizations off guard: a US support engineer viewing an EU customer database from a laptop in Texas is a cross-border data transfer, even though nothing was formally exported. Chapter V of GDPR governs all of it, and its default position is restrictive, permitting a transfer only where the data keeps essentially equivalent protection after it leaves (Article 44).
That default matters more than the mechanics. A GDPR cross-border data transfer is not lawful until you can point to a specific basis for it, either an adequacy decision, appropriate safeguards, or a narrow derogation. The stakes make the topic a board-level one: Article 83 places transfer violations in the top penalty tier, up to 20 million euros or 4 percent of total worldwide annual turnover, whichever is higher. The Uber fine was not an outlier; it was the rule being enforced.
Rule of thumb:
If a person or system outside the EEA can read, receive, or reach EU personal data, a cross-border transfer has occurred, whether or not anyone “sent” a file. Remote access, cloud storage, support tickets, and analytics pipelines all count. Map the access, not just the exports.
Why Isn’t Choosing a Transfer Mechanism Enough to Stay Compliant?
Choosing a transfer mechanism is no longer enough because the mechanism only proves the paperwork, not the protection. This is the shift most compliance programs have not absorbed. In 2020 the Court of Justice of the European Union struck down the EU-US Privacy Shield in the Schrems II ruling, finding that US surveillance law gave authorities disproportionate access to Europeans’ data with insufficient redress (European Parliament). Crucially, the same ruling kept Standard Contractual Clauses valid but attached a condition to them: the exporter must assess, case by case, whether the destination country’s laws actually let the safeguards work, and add supplementary measures where they do not.
That assessment now has a name, the transfer impact assessment, and it is where diligence lives. It forces a question a contract cannot answer: can the recipient, or any authority with power over the recipient, get at the data despite the clauses on paper? If the answer is yes, the mechanism alone leaves the transfer unlawful. Regulators are enforcing exactly this gap. Uber had a corporate relationship with its US parent, but the Dutch authority found the safeguards inadequate for what the data was exposed to, and the 290 million euro fine followed. The mechanism was never the finish line.
The trap:
A signed set of Standard Contractual Clauses feels like completion. Legally, since Schrems II, it is a starting document that obligates you to prove the destination is safe and to fix it if it is not. Treating the signature as the end of the exercise is the single most common, and most expensive, cross-border compliance mistake.
Which GDPR Transfer Mechanism Should You Rely On?
The right GDPR transfer mechanism depends on where the data is going and how often. The three families, adequacy, appropriate safeguards, and derogations, trade convenience against burden, and most organizations end up using more than one across their data flows.
| Mechanism | What it is | Best for | Key limitation |
| Adequacy decision | Commission ruling that a country’s regime is essentially equivalent | Transfers to listed countries (UK, Switzerland, Japan, South Korea, and others) | Limited country list; can be reviewed or revoked |
| Standard Contractual Clauses (SCCs) | Pre-approved contract terms binding importer and exporter (Article 46) | Most commercial transfers to non-adequate countries | Since Schrems II, require a transfer impact assessment and often supplementary measures |
| Binding Corporate Rules (BCRs) | Internal rules approved by a supervisory authority for intra-group transfers | Large multinationals moving data within the group | Slow and expensive to get approved; still subject to the Schrems II test |
| EU-US Data Privacy Framework | Adequacy decision specific to certified US organizations | Transfers to self-certified US companies | Legally contested; depends on evolving US oversight |
| Article 49 derogations | Narrow exceptions such as explicit consent or contractual necessity (Article 49) | Occasional, non-repetitive transfers | Not a basis for systematic or large-scale transfers |
For most regulated organizations, SCCs do the heavy lifting, because adequacy covers only a short list of countries and BCRs can take years to approve. Article 49 derogations are a trap when overused; they are built for the occasional transfer, not the daily data pipeline. Whichever you choose, baseline data compliance now hinges on the assessment that sits on top of the mechanism, not the mechanism alone.
Can You Still Trust the EU-US Data Privacy Framework in 2026?
You can rely on the EU-US Data Privacy Framework in 2026, but you should not build a permanent strategy on it. Adopted as an adequacy decision in July 2023, it replaced the invalidated Privacy Shield and now underpins transfers for more than 2,800 certified US organizations (European Commission). For transfers to a certified recipient, it is a clean, usable legal basis today.
The durability is the problem. The framework survived its first challenge when the EU General Court dismissed the Latombe case in September 2025, but that decision has been appealed to the Court of Justice, the same court that annulled the two previous transatlantic frameworks (IAPP). The ground beneath it is shifting too: in June 2026 the US Supreme Court held in Trump v. Slaughter that the President may remove Federal Trade Commission members at will, weakening the independence of an agency that the framework’s oversight structure depends on (Congress.gov). A transfer basis that has been reinvented twice in a decade is a convenience to use, not a foundation to pour.
What Does Cross-Border Compliance Look Like in Healthcare, Finance, and Government?
Across regulated sectors, cross-border compliance means pairing a legal mechanism with technical controls strong enough to satisfy the Schrems II standard, because these are the transfers regulators watch most closely. The mechanism is shared; the sensitivity of the payload is what raises the bar, and it raises it differently in each sector.
Healthcare carries the heaviest sensitivity, because health data is a special category under GDPR with heightened protection. Multinational clinical trials and cross-border research cannot function without moving data, yet a single mishandled patient-record transfer carries regulatory and ethical weight at once. This is why multi-institution healthcare AI collaboration increasingly analyzes data across borders without the raw records ever leaving their country of origin.
Financial services move data across borders constantly, for fraud detection, group risk reporting, and regulatory filings, while sitting under regimes that pull in different directions. Uber’s fine is the cautionary tale: routine operational transfers to a US parent, done without adequate safeguards, became a nine-figure liability. Institutions increasingly adopt secure financial analytics that combine signals across jurisdictions without exposing the underlying customer data to the receiving entity.
Government faces a sovereignty dimension no contract can resolve. Agencies must sometimes share data with allied partners while respecting classification limits and citizen privacy that cannot be delegated abroad. The requirement is cross-domain collaboration that produces shared insight without shared raw access, keeping the data under national control even as its results cross a border.
Which Technical Safeguards Actually Satisfy Regulators?
The technical safeguards that satisfy regulators are the ones the European Data Protection Board identified after Schrems II as able to stop access by destination-country authorities, chiefly strong encryption and effective pseudonymization. The logic is precise: if neither the importer nor any authority with power over the importer can read the data, the destination’s surveillance laws stop being relevant to the transfer. The safeguard travels with the data rather than depending on the recipient’s legal environment.
The detail that disqualifies most setups is key control. Encryption only counts as an effective supplementary measure when the keys stay under the exporter’s control inside the EEA and the importer cannot decrypt, which rules out the typical cloud arrangement where the provider holds the keys. Beyond encryption, data anonymization and data de-identification can take data out of GDPR’s scope entirely when done irreversibly, and differential privacy limits what any transferred dataset reveals about an individual. Treating AI data security and transfer compliance as one problem, rather than two, is what separates a defensible transfer from a documented hope.
How Do Privacy-Enhancing Technologies Turn Compliance Into Collaboration?
Privacy-enhancing technologies turn cross-border compliance from a defensive exercise into a collaborative one by letting organizations use data across jurisdictions without the raw personal data ever being readable to the receiving party. Privacy-enhancing technologies invert the usual transfer problem: instead of moving readable data and then arguing it is protected, they ensure it is never readable in the destination, which is the most direct way to satisfy the Schrems II supplementary-measures test.
Three approaches do most of the work. Fully Homomorphic Encryption lets a party abroad compute on encrypted EU data and return results without decrypting it, so no plaintext personal data ever crosses the border. Federated learning trains shared models while records stay in their home jurisdiction, moving only model updates. Secure multi-party computation lets institutions in different countries compute a joint result, a cross-border fraud signal or a multinational research finding, without any party revealing its inputs. With confidential computing added in, these form the practical layer of secure AI collaboration that regulators increasingly expect to see documented.
The practical payoff is a different kind of guarantee. A Standard Contractual Clause is a promise about the recipient’s behavior and a transfer impact assessment is a prediction about a foreign legal system; both can be overturned, as the history of transatlantic frameworks keeps showing. Keeping data encrypted through computation itself, the approach Duality Technologies builds on, means the receiving side is cryptographically unable to read it, so the transfer no longer depends on how a court reads US surveillance law. It depends on mathematics, which does not change when a government does.
Bottom line for exporters:
Legal mechanisms manage the risk that a transfer is challenged. Technical safeguards remove the reason to challenge it. The first depends on a foreign legal system staying favorable; the second does not depend on anything a court can change. Build on the second, and the mechanism becomes a formality rather than a fault line.
What Should Regulated Teams Do Before the Next Framework Falls?
The transatlantic transfer landscape has been rebuilt twice in ten years, and the appeal now before the Court of Justice means it could move again. Teams that treat the current framework as permanent will spend the next decade re-papering their transfers every time a court rules. The alternative is to prepare for volatility rather than bet against it.
That means three things in practice. Map every place EU personal data is accessible from outside the EEA, including the remote-access and analytics paths that never look like transfers. Keep a valid mechanism in place, but stop treating it as sufficient. And make protection travel with the data, so that when the legal basis wobbles, the compliance does not, because the receiving side never held readable data in the first place. The organizations that will still be compliant after the next ruling are the ones building on the layer no court can revoke.
