Sovereignty - or the illusion of control

27 October 2025 sovereignty resilience governance

From sovereignty theatre to real resilience

Digital sovereignty is having a moment. Many European public sector organisations plan to reduce their dependence on American hyperscalers. The new mantra: "If it's not EU, it won't do."

I've been working on these questions for years, and I welcome the increased attention. Geopolitical tensions are real. Regulatory concerns are valid. The instinct to reduce critical dependencies is sound.

Let me be clear about my position: reducing dependence on American technology for critical national infrastructure is sound strategy. The US government's extraterritorial legal reach is real and unique. For defense systems, critical utilities, sensitive government data - yes, this matters.

What frustrates me is HOW we're having this conversation. We're making expensive, symbolic moves while missing the systematic thinking that would actually deliver resilience.

So we are in danger of addressing the visible, politically-charged dependencies while missing the operational ones that are just as critical.

Let me show you what I mean.

The Rolls-Royce problem

Most organisations treat IT suppliers like... suppliers. Procurement negotiates every last cent out of their margin. Contracts specify penalties for downtime. Service levels are lawyered to death.

Then 3am Saturday happens. Your provider is down. You need someone in the trenches, working shoulder to shoulder with your team RIGHT NOW.

Suddenly you remember: you paid for overbooked Ryanair, but you are expecting Rolls-Royce service… You want a partner - but Procurement and Legal have created a transactional relationship with a supplier instead.

Worse: you might have created adversarial incentives. That penalty clause for downtime? It just gave your supplier a reason to hide problems when they were still smaller, and try fixing them quietly rather than calling you immediately.

The contract doesn't pick up the phone at 3am - so it's going to be a looong night of escalation calls.

Fear is a poor adviser

Let's map some of the actual fears driving sovereignty discussions:

These are real concerns. But here's what's interesting: they apply to ALL your dependencies, not just the American ones.

Your local IT shop can:

"If it ain't Dutch, it ain't much" (or "If it's not EU, it won't do") is asking the right question with the wrong scope.

This isn't an argument against sovereignty measures. It's an argument for thinking them through systematically. So let's start with the basics: what are we actually worried about?

The Government access question

One of the most frequently cited concerns: what happens when a government orders your provider to hand over your data or shut down your service?

This is real. The US CLOUD Act allows American law enforcement to compel US-based companies to produce data regardless of where it's stored. Other countries have similar mechanisms. It's a legitimate - yet nuanced - concern that deserves more than "just don't use American providers."1

But here's where it gets interesting:

European providers face the same pressures - just from different governments. Your German cloud provider can be compelled by German authorities. Your French backup service can receive orders from French intelligence services. GDPR doesn't exempt law enforcement requests.

The question isn't "which government can access my data?" It's "which governments can access my data, under what circumstances, and what's my plan when it happens?"

This is why the hold-your-own-key discussion matters. It's one of the few technical controls that can limit government access regardless of which government is asking. But as we saw earlier, it comes with serious trade-offs.

What you should actually be asking:

The uncomfortable reality: If you're doing business in multiple jurisdictions, SOME government will have potential legal access to SOME of your data. The question is whether you've consciously designed which government has access to what, or whether you're just hoping nobody asks.

And this brings us back to the bigger picture. If government data access is your concern, you need to think systematically about ALL the ways governments can access or influence your operations.

The Hold-Your-Own-Key paradox

Here's a popular 'solution': hold your own encryption keys. Your cloud provider can't access your data, so neither can governments pressuring them.

Problem solved?

Not quite:

You achieved sovereignty by making yourself less secure and less operational. Congratulations?

Who's missing from your sovereignty assessment?

Here's a quick test: your organisation's 'digital sovereignty plan' probably mentions American hyperscalers dozens of times. How many times does it mention your DNS provider? Your certificate authority?

Let's talk about the players you're NOT scrutinising:

Your DNS provider: When Dyn went down in 2016, half the internet went with it.2 Where does your DNS live? Who controls your domain registrar? A DDoS on your DNS provider is just as effective as a government order to your cloud provider.

Your Certificate Authorities: Your entire HTTPS security depends on a chain of trust involving Certificate Authorities (CAs). How many of those are American? How many are actually managed by organisations you've never heard of? What happens when one gets compromised or receives a legal order?

Your "local" IT shop: That "European" managed services provider you migrated to? Check their stack:

Your software supply chain: You migrated your infrastructure to a European cloud. Great. But:

Your backup strategy: You've achieved sovereignty by hosting everything in Amsterdam. Where are your backups? If they're also in Amsterdam, what happens when the Schiphol fiber ring gets cut? If they're in another EU country, congratulations - you just created a cross-border data flow that might trigger the same regulations you were worried about.

The Real Question

It's not "Are we dependent on American tech?"

It's "Do we have a systematic approach to understanding ALL our critical dependencies - and have we consciously designed trade-offs for each one?"

Right now, most organisations are performing sovereignty theatre: they're addressing the visible, politically-charged dependencies while ignoring the operational ones that are just as critical.

Building real partnerships (not just contracts)

Once you've identified all your dependencies - the visible and hidden ones - you need to think about the relationship itself. This is where many sovereignty initiatives stumble: they focus on WHERE the provider is located, not HOW the relationship actually works.

Ask yourself these questions for each critical dependency:

Are they critical for YOUR business? If they go down, can you function? For how long? This determines how much you should invest in the relationship.

Are YOU critical for THEIR business? If you're 2% of their revenue, expect 2% of their attention during a crisis. If you're 40% of their revenue, you have leverage - but also risk if they become over-reliant on you and can't survive without your business.

This asymmetry matters. Your "sovereign" European provider might be heavily dependent on your government contract. What happens if budget cuts force you to reduce spending? Do they have other revenue streams, or will they struggle to maintain the infrastructure you need?

Do they have the skills to meet your security requirements? This is especially important when migrating to smaller European providers. The hyperscalers can hire top security talent globally. Your regional provider might struggle to compete for that talent.

Questions to ask:

If the answer is "they're learning" - that's fine, IF you're prepared to help them build that capability. Which brings me to:

Should you be investing in THEIR capabilities? If this provider is critical to your operations, their security IS your security. Some organisations are taking the approach of:

This sounds expensive - but compare it to the cost of having them compromised.

Are you paying them enough to do security properly? Remember the Rolls-Royce problem? If you've negotiated every cent out of their margin, where do you think they'll cut corners?

Security costs money:

If you want "sovereign" security that actually works, you need to pay for it. The lowest bid often delivers exactly what you paid for.

Do you understand mutual dependencies? It's not just "what happens if they fail?" but "what happens if WE fail and it impacts THEM?"

Example: Your provider hosts your critical infrastructure. You get breached through a different vector (phishing, anyone?). Now malware is running in their infrastructure. Did you architect things so this doesn't become THEIR problem too? Or did you just share the risk without sharing the information?

Questions to map:

The Partnership Test

Here's a simple test of whether you have a partnership or just a contract:

Call your provider's emergency contact. Not during a real emergency - just call. Do you get:

Real partners have real people who know your systems. Suppliers have SLAs.

This applies to ALL providers, not just "sovereign" ones. The flag on the data centre matters far less than the quality of the relationship and the mutual understanding of dependencies.

From Paper to Practice: Testing your dependencies

So you've identified your dependencies. You've made conscious trade-offs. You've signed better contracts with better incentives.

Now what?

The contract still doesn't pick up the phone at 3am.

This is where most organisations stop. They've done the strategic thinking, filled out the spreadsheets, and moved on. But they're still operating in "Safety-I" mode: assuming that if you design it right, it'll work right.

Why does this matter? Because organisations are complex systems. In complex systems, behaviour emerges from interactions between components - you can't predict the whole by analysing the parts. A small change can cascade unexpectedly. This is why the "design it right and it'll work right" approach fails.

You need to actively test whether your carefully designed trade-offs actually hold up under pressure.

Test your Hold-Your-Own-Key setup

You've implemented hold-your-own-key to maintain data sovereignty. Great. Now:

Test your "European alternative"

You've migrated to a European cloud provider for sovereignty. Now test it:

Test your operational reality

The biggest gap isn't technical - it's operational:

The 3am Saturday Test

The staffing test

Joint security exercises

This is where the rubber meets the road. Don't just test YOUR side - test the RELATIONSHIP:

Red/Purple team exercises

Chaos Engineering for dependencies

Netflix's chaos monkey3 randomly breaks their infrastructure to make sure they can handle it. You should do the same for dependencies:

Game days

Borrow from the DevOps playbook: run regular "game days" where you deliberately stress-test your dependencies:

The feedback loop

Here's the crucial part: treat every test as a learning opportunity, not a pass/fail exam.

After each test:

This is "Safety-II" thinking: you're not trying to prevent all failures. You're building the organisational muscle memory to handle failures gracefully.

Apply this same "design trade-offs + test reality" approach to ALL your dependencies.

The Uncomfortable Truth

Real resilience means accepting that sovereignty isn't binary. It's a spectrum of conscious trade-offs that you ACTIVELY TEST.

The organisations that will survive aren't the ones with perfect sovereignty. They're the ones who:

Your immune system doesn't work by avoiding all germs. It works by learning to handle them in controlled doses.

From theatre to reality

The sovereignty discussions happening right now are asking the RIGHT questions. European organisations SHOULD reduce critical dependencies on American technology. But right now, we're getting theatre-quality answers to strategic-quality questions.

Real sovereignty isn't about which flag is on your data center. Instead, we should aim for real autonomy and real resilience, which means:

The good news? The sovereignty theatre has gotten organisations thinking about dependencies. Now let's finish the job properly.

Start small:

Because when your European provider goes down at 3am on Saturday, you won't be asking "Are we sovereign?"

You'll be asking: "Can we recover gracefully?"

And that's the only question that matters.

1. NCSC-NL published on this: How the CLOUD Act works in data storage in Europe 2. DDoS attacks on Dyn 3. Netflix Chaos Monkey and Security Chaos Engineering by Kelly Shortridge

← Back to archive