Schrems II and Data Transfers: Why an EU-Only Stack Is the Stable Answer

If you sell software into Europe, "Schrems II" turns up in places you didn't invite it. It's a line in a Data Processing Agreement, a checkbox in a vendor security review, the reason a prospect's lawyer asks where your database lives. Two words, usually left unexplained, quietly deciding whether a deal moves forward. Most of what's written about it is either lawyer-grade or fear-grade, and neither helps you make a hosting decision.

So here's the plain-terms version: what the ruling actually said, why it wasn't a one-off, and why it ends up being a question about where you host rather than what you sign. None of this is legal advice. It's the context that makes the term stop being a scary phrase in a contract and start being a decision you can reason about.

Who Max Schrems is, and what got struck down

Max Schrems is an Austrian privacy lawyer who, as a student in 2011, asked Facebook for a copy of the data it held on him and got back a stack of pages that made him wonder what US law actually allowed once European data landed there. That question became a decade of litigation. His first case reached the Court of Justice of the European Union in 2015 and took down Safe Harbor, the agreement that had let companies move personal data across the Atlantic since 2000. The framework that replaced it, Privacy Shield, is the one his second case was aimed at.

That second case, formally C-311/18 and known everywhere as Schrems II, was decided in July 2020. The Court ruled that Privacy Shield did not give European data the protection GDPR requires once it reaches the United States, and struck it down with immediate effect. It left Standard Contractual Clauses standing as a transfer tool, but added a condition that changed what using them involves: you can't just sign them and assume the data is protected. That single caveat is what turned a court ruling into a workload for thousands of companies, and we'll get to it.

Read down that table and the shape of the thing is hard to miss. Two arrangements built to legalise the same transfer, both invalidated by the same court within five years of each other, each replaced by something structurally similar. This isn't a story about one bad framework getting fixed. It's a pattern, and understanding why it repeats tells you more than any single ruling does.

Why the bridges keep collapsing

The reason is a conflict that no framework has resolved, because it isn't a paperwork problem. GDPR says personal data leaving the EU has to keep a level of protection that is "essentially equivalent" to what it had inside the Union. US surveillance law, in the Court's assessment, doesn't clear that bar. Programmes authorised under Section 702 of FISA and Executive Order 12333 give US intelligence agencies access to data held by US providers, and a European whose data gets swept up has no meaningful way to challenge it in a US court. As long as those two facts sit side by side, any bridge built over the gap is standing on ground the Court has already called unstable.

The US CLOUD Act sharpens the point. It lets US authorities compel a US-based provider to produce data it controls no matter which country the servers are in. So a US company's European data centre doesn't fully settle the question, because the obligation follows the company, not the hardware. This is the part worth saying clearly, because it's where the fear-grade writing takes over: none of this is about US companies behaving badly or wanting to hand your data over. It's a straightforward clash between one legal system's guarantees and another's powers, and it's structural, which is exactly why patching the contract on top never quite holds.

What Schrems II asked of everyone else

The headline was that Privacy Shield died, but the part that reached into everyday engineering was quieter. By keeping Standard Contractual Clauses alive only on the condition that they actually deliver equivalent protection, the Court made SCCs necessary but no longer sufficient. Signing the clauses stopped being the end of the task and became the start of it: you now have to check whether the law in the destination country would undercut what you just signed, and do something about it if it would.

That check has a name, a Transfer Impact Assessment, and the follow-on work has guidance behind it in the European Data Protection Board's Recommendations 01/2020 on supplementary measures. We walked through where these obligations come from in where to store EU user data; the point here is the ongoing cost of them. Every transfer of EU personal data to the US now carries a recurring chore list:

• Map which data actually leaves the EU, and to whom, including subprocessors your provider uses further down the chain.
• Assess whether US law would compromise the protection your SCCs promise, and write that assessment down.
• Add supplementary measures where it would — extra encryption, pseudonymisation, contractual and technical controls — and confirm they're enough.
• Keep the whole thing current, because the assessment expires the moment the legal ground shifts, which it does.

For a small team, that's real time spent on lawyers and documentation rather than product, and it doesn't buy certainty. It buys a defensible position that has to be re-defended whenever the framework underneath it moves again.

The 2023 Data Privacy Framework, and why it isn't case closed

In July 2023 the European Commission adopted a new adequacy decision, the EU-US Data Privacy Framework, which restored a cleaner route for transfers to the US. It's genuine relief: if the US organisation you're sending data to has self-certified under the framework, you can rely on that instead of running the full SCC-plus-assessment gauntlet. For a lot of companies, the day-to-day friction eased considerably.

The catch is history. This is the third arrangement of its kind, built to bridge the same gap the last two couldn't hold. Schrems and his organisation noyb said publicly they consider it flawed on the same grounds as Privacy Shield and signalled they'd challenge it, a case people already call "Schrems III" before it has a number. As of writing the framework is valid and usable, and it may well survive. But relying on it means betting that this bridge outlasts the next court case, on a route where the previous two didn't. That's a fine bet to make with eyes open. It's a bad one to make by accident.

The durable answer: don't have a transfer

Step back from the frameworks and the assessments and the acronyms, and notice that all of them exist to solve one problem: European data went somewhere GDPR doesn't reach cleanly. If the data never leaves, the problem never starts. There's no transfer to justify, no impact assessment to write, no framework to monitor, and no exposure to whatever the next ruling decides. The most stable answer to the transfer question turns out to be not having a transfer at all.

This is where residency stops being a nice-to-have and becomes the low-drama engineering choice. It's also worth being honest about its limits, the same way EU vs US hosting is: keeping data in the EU removes the hardest and least stable part of compliance, but it isn't compliance by itself. You still need a lawful basis for processing, a way to handle data-subject requests, real security, and a Data Processing Agreement. Residency takes the Schrems question off the table. It doesn't take the rest of GDPR off the table. The wider picture of what "hosting in Europe" involves is laid out in the EU hosting guide.

What this means for your stack

In practice, sidestepping the transfer question means keeping every copy of the data on one side of the border, which is easier when the platform is built that way rather than configured into it after the fact. That's the setup Runsite runs on. Web Services keep your app containers, environment variables, build artifacts, and logs in a Frankfurt, Germany region, with no replication to non-EU regions and no fallback to overseas infrastructure. Put managed PostgreSQL and S3-compatible object storage next to them and the database, its backups, and your files sit in the same region rather than scattered across two continents.

The quiet advantage there is what's missing. There's no second region on another continent for data to replicate into, so there's no transfer to assess, no supplementary measures to bolt on, and nothing that a future Schrems ruling can reach. A signed GDPR Data Processing Agreement comes with every plan, so the contractual side is answered up front rather than negotiated as an enterprise add-on. The Schrems question doesn't get a better answer here; it just never gets asked.

The short version

Schrems II struck down Privacy Shield in 2020, the second EU-US data bridge to fall in five years, because European data in the US can't get the protection GDPR demands while US surveillance law works the way it does. That conflict is structural, which is why the 2023 Data Privacy Framework, the third bridge, is already being challenged. Relying on any transfer framework means betting it survives the next case. Keeping EU data in the EU means there's no transfer to bet on: no assessment, no framework to watch, nothing for the next ruling to touch. It isn't the whole of compliance, but it's the one part you can settle permanently. If your users and your obligations are both in Europe, the simplest way to answer the Schrems question is to make sure it never comes up. Keep the whole stack in an EU region and it won't.