This is the second of two articles on a sovereignty paradox. The first, Control Isn’t Sovereignty?, argued that delegating to systems with broader resilience can produce more outcome sovereignty than direct ownership. This one is about the harder question underneath.
Most sovereignty design follows the same logic. To protect operations against grid failures: Install generators on site. Stock diesel reserves to keep them running through an extended outage. Arrange supply contracts with fuel suppliers for resupply during a crisis.
The architecture covers each layer of the problem.
In April 2025, this design met the exact scenario it was built for. The Iberian peninsula went dark. Spain, Portugal, and parts of southern France lost power for hours in some regions and days in others – the largest blackout in European history. Generators kicked in. Operations kept running.
And then the diesel started to run low. Trucks headed to fuel stations to refill. The pumps that move fuel from underground tanks to delivery trucks need electricity to run, and the grid was still down. And many fuel stations had no backup power. The diesel was there, sitting in the tanks. The pumps couldn’t move it.
The generators were the backup for the grid. The diesel reserves were the backup for the generators. Nothing was backing up the fuel stations.
Sovereignty runs deeper than one layer.
This is a resilience problem before it’s a sovereignty one — whether the system holds when a layer underneath it gives way.
Every system has a next layer.
The fuel station problem is not specific to Iberia, and not specific to power. It is the general shape of how resilience designs fail.
Multi-cloud strategies illustrate the same pattern. An enterprise deploys across AWS, Azure, and Google to avoid single-vendor dependency. But the fail-over systems, the orchestration logic, and the routing decisions that switch traffic between clouds often live in tooling that itself depends on one of those clouds. When AWS US-East-1 had a major outage in 2024, many supposedly multi-cloud architectures discovered that their fail-over system depended on US-East-1 too. The redundancy was real at one layer and absent at the next.
Backup recovery shows it again. Enterprises maintain offline backups against ransomware. The backups survive an attack. But the recovery procedures depend on Active Directory, DNS, and identity providers – the same systems that ransomware tends to disable. The backup is intact. The path to restore it is not.
Software supply chains show it at extreme depth. The 2021 Log4j vulnerability affected nearly every Java enterprise application in the world because everyone depended on the same logging library, four or five dependency layers below their own code. Most security teams discovered the dependency only when they had to patch it.
Resilience is recursive. Whatever protects you depends on something. That something has its own dependencies. And those have theirs. Every architecture holds only as deep as the layer beneath it holds.
This isn’t an argument against delegation.
The previous article in this series argued that in many cases delegation can produce more outcome sovereignty than direct ownership. The Iberian case showed it. The argument still holds.
What the fuel station problem adds is the next move. The deep dependencies usually don’t show. If the grid drops for twenty minutes, the generator covers it and power stays sovereign. If a single region of a cloud provider has problems but the rest of the world’s network keeps working, failover succeeds and operations stay sovereign. If data is corrupted but identity and DNS still work, the backup restores and the business stays sovereign. The architecture handles the conditions it sees most of the time, and most of the time it’s right.
The depth problem only surfaces in the extreme cases. A short outage tests the first layer. An extended outage tests the second. A regional crisis tests the third. Most architectures are built for the first layer. Some are built for the second. Few are built for the third.
The question isn’t whether deep dependencies exist. They always do. The questions are different. First, have you mapped your architecture’s dependencies down to their actual depth, or only to the conditions you usually encounter? Second, when do these deeper levers move? And third, if they move, does that do something to your business that you want to avoid?
Some depth doesn’t need to be designed for. A meteor strike, a global undersea cable severance, a multi-day continental power failure – though these are real, they are so rare that for most businesses they’re not worth the cost of mitigation. Some deep levers matter and are worth mitigating. Think of a 48-hour grid failure where your infrastructure is damaged not only during the outage but also long afterwards – servers that always run and never need to be restarted, going down together, taking a week to be back up and running even though the grid is long restored. That’s a scenario to design for.
Where this leaves us
When designing your sovereignty, your dependency research needs to go deep. Don’t stop at the top layer you see. Make it a practice: for every resilience layer you put in to mitigate a top-layer dependency, research the levers and dependencies of that mitigation itself. The generator you installed to mitigate a grid failure has its own dependencies. Find them. The cloud failover you built to mitigate a regional outage has its own dependencies. Find those too. Keep going until you reach the layer where the remaining risks don’t matter to your business.
Designing sovereignty isn’t about eliminating dependencies. It’s about knowing which ones exist, when they would move, and which of those moves you can afford to let happen.
Real sovereignty isn’t a property of your own architecture. It’s a property of how clearly you’ve seen what sits underneath it.
This argument was first developed for an internal masterclass held on April 16, 2026, where it was presented as part of a broader exploration of how organizations should think about whether their sovereignty design actually holds when the conditions they’re protecting against arrive. The published version reflects subsequent conversations and refinements. A companion piece, Control Isn’t Sovereignty?, makes the first move in this paired argument.
Originally published on LinkedIn