# Sovereignty Is Not a Region Dropdown There's a dropdown in every cloud console that radiates more false comfort per pixel than any other UI element in software. Region: eu-central-1. Frankfurt. Select it, deploy, and a whole compliance narrative writes itself: the data is in Germany, Germany is in the EU, therefore we're covered. Meetings end early on the strength of that dropdown. Here's the claim this post defends: where your data sits and who can be compelled to hand it over are two different questions, the dropdown answers only the first, and an expanding genre of sovereignty marketing depends on you not noticing the difference. ## Jurisdiction follows the company In 2018, the United States passed the CLOUD Act, and its core provision is worth reading in the original because no summary improves on it:
...regardless of whether such communication, record, or other information is located within or outside of the United States.
18 U.S.C. 2713, added by the CLOUD Act, 2018. Congressional Research Service overview
The obligation attaches to the provider, wherever the provider's US legal entity can reach: data within its "possession, custody, or control" is in scope, Frankfurt datacenter or not. Whether an EU subsidiary of a US parent falls outside that reach is precisely the disputed question, and the honest answer is that it hasn't been cleanly resolved; corporate structure, not server placement, is where the argument happens. Your bytes sleep in Germany. The subpoena lands in Washington. To be precise about what the law is and isn't: it establishes legal process, with warrants, review, and a mechanism for providers to challenge conflicts with foreign law. It's not a secret free-for-all, and describing it as one is its own kind of washing. But the process runs through US courts, applying US standards, to data your German neighbors assumed was governed by German ones. ## Two legal systems, one server The collision isn't theoretical; it has a case name. On July 16, 2020, the EU's top court decided [Schrems II](https://www.europarl.europa.eu/RegData/etudes/ATAG/2020/652073/EPRS_ATA(2020)652073_EN.pdf), striking down the Privacy Shield transfer framework because US surveillance law didn't offer EU citizens protection the court considered essentially equivalent to EU law. A successor adequacy framework has since arrived, and few people in Brussels would bet on it being the last word, given that its predecessor's predecessor died the same way. Notice what that whole line of cases is about. Not datacenter locations. Legal orders: which country's authorities can reach the data, under which safeguards, reviewable by whose courts. The entire dispute would look identical if every byte involved had spent its life in Frankfurt, because the question was always jurisdiction over the companies holding the keys. | The region dropdown controls | It does not control | |------------------------------|---------------------| | Latency to your users | Which governments can compel disclosure | | Where data rests physically | Where the operator is legally answerable | | Which local failure domain you're in | Who employs the people with admin access | | A data-residency checkbox | Whether encryption keys leave the jurisdiction | ## How to spot sovereignty-washing "Sovereign" is becoming a product adjective, and some of what it decorates is genuine engineering while some is a region with a flag sticker. The test is a short list of questions that marketing pages tend not to answer. Who owns the operating entity, all the way up? Which courts can bind that owner? Who holds the encryption keys, and can the operator's parent be compelled to use them? And the question that gets skipped most: if the answers change, how fast can you leave? Key custody deserves its own line, because it's where the washing gets technical. Hold-your-own-key arrangements genuinely narrow what an operator can be compelled to produce, but only if the operator truly can't reach the keys; a key management service run by the same corporate family is a promise, not a boundary. Ask where the key material physically lives and who can rotate it. The answer sorts real designs from brochures quickly. That last question on the list matters most because exit is the sovereignty mechanism you control unilaterally. Every other protection on the list is something a vendor or a legislature grants you and can amend. The ability to take your workloads and data elsewhere on short notice is the one that doesn't require anyone's permission, which is why we treat portability as a sovereignty feature and not a procurement nicety. It's the same argument we made about [multi-cloud](/multi-cloud/multi-cloud-overrated-portability-isnt), pointed at a different threat. ## The steelman: residency isn't nothing The dropdown's defenders have real points. Data residency solves genuine problems: latency, local failure domains, and a handful of sector rules that literally require data to remain in-country. Residency also narrows practical exposure, since data that never leaves a jurisdiction at rest is harder to sweep up incidentally. And for a lot of businesses, a pragmatic read is fine; not everyone's threat model includes foreign legal process, and pretending otherwise is its own theater. Conceded, all of it. Residency is a floor. The error is selling the floor as the house: compliance narratives built on the dropdown quietly assume location implies jurisdiction, and both the CLOUD Act's text and a decade of transfer-framework litigation say it doesn't. A law can say so in one sentence. Marketing needs you to not read that sentence. We're a European company, and I'd love to tell you that alone settles something. It doesn't; jurisdiction applies to us the same way, which is rather the point. What we can do is build so the exit door stays open, and describe the legal terrain plainly instead of decorating it. So, about your own stack: do you know, today, whose courts can reach it? Not where it runs. Who can reach it. --- Related: [Multi-Cloud Is Overrated. Portability Isn't.](/multi-cloud/multi-cloud-overrated-portability-isnt), the operational half of this argument. More about what we're building at [light-cloud.com](https://light-cloud.com).