Showing Posts From

Sovereignty

Digital sovereignty is not where your cloud runs

Organizations often talk about digital sovereignty as if it is a geographical problem. As if moving workloads from one region to another, or choosing a “European cloud”, somehow resolves it by default. That framing is comfortable. It is also misleading. Because digital sovereignty is not defined by where your cloud runs. It is defined by what you depend on, who controls those dependencies, and how quickly that control can shift without you noticing. And in most modern architectures, those answers are far less reassuring than organizations assume. The illusion of location-based control One of the most persistent misunderstandings in cloud strategy is the idea that data residency equals sovereignty. If data is stored in a specific country or region, the thinking goes, it must be under that jurisdiction’s control. Therefore, the organization is sovereign. But sovereignty is not a storage property. It is an operational condition. Modern cloud environments separate storage, compute, identity, observability, orchestration, and security into distributed services. Even if data is physically stored within a defined region, the control plane often is not. Identity providers, logging systems, container orchestration, key management services, and telemetry pipelines may all cross borders by design. And each of those layers introduces external dependency. So what looks like sovereignty at the infrastructure layer can still be deep dependency at the control layer. The real dependency map is not obvious Most organizations can tell you where their workloads run. Far fewer can explain:Who controls their identity system Where authentication and authorization decisions are evaluated Which external APIs are critical to deployment pipelines How secrets are managed and rotated What happens if a major cloud control plane becomes unavailableThese are not edge cases. They are core architectural facts. Yet they are often treated as implementation details rather than strategic dependencies. The result is a mismatch between perceived autonomy and actual control. A system may look sovereign on a slide deck while being tightly coupled to a small number of global providers in practice. Sovereignty is not binary Another common mistake is treating digital sovereignty as a yes-or-no state. Either you are sovereign, or you are not. Reality is more nuanced. Sovereignty exists on a spectrum of control across multiple dimensions:Data sovereignty: Where data is stored and under which legal regimes it falls Operational sovereignty: Who can change, deploy, or interrupt systems Technical sovereignty: How replaceable core components are Economic sovereignty: How easily costs can be influenced externally Vendor sovereignty: How dependent you are on specific providers or ecosystemsAn organization can be strong in one dimension and weak in another. For example, you might host data locally while remaining fully dependent on a single global identity provider. Or you might have multi-cloud infrastructure but still rely on one provider’s proprietary orchestration layer. Calling this “sovereign” or “not sovereign” misses the point entirely. The real question is: where are you constrained without realizing it? Cloud convenience is a design trade-off Cloud platforms are powerful because they reduce complexity. Managed services remove the need to operate infrastructure at scale. APIs abstract away operational burden. Integrated tooling accelerates delivery. But every abstraction is also a dependency. When you adopt a managed database, you gain operational simplicity. You also accept a specific backup model, a specific failover mechanism, and a specific pricing structure. When you adopt a managed identity provider, you gain security and standardization. You also accept that authentication is no longer fully under your control. These are not flaws. They are trade-offs. The problem arises when organizations treat these trade-offs as reversible defaults rather than strategic commitments. The hidden concentration of control Over time, cloud adoption tends to concentrate control rather than distribute it. Even in multi-cloud environments, the same patterns emerge: One provider becomes the primary identity source One ecosystem dominates observability One pipeline tool becomes the standard deployment mechanism One set of APIs defines infrastructure behavior This is not accidental. It is the natural outcome of efficiency seeking. But concentration introduces fragility. Not necessarily technical fragility in the form of outages, but strategic fragility: reduced negotiating power, limited exit options, and increasing difficulty to redesign systems without significant disruption. The more optimized a system becomes around a single ecosystem, the less sovereign it tends to be. The uncomfortable question: what can you actually replace? A practical way to evaluate sovereignty is not to ask where systems run, but what would happen if key components disappeared. Not hypothetically in a disaster scenario, but structurally:If your identity provider changes terms or access, how fast can you switch? If your primary cloud provider increases costs significantly, what breaks first? If a critical managed service is discontinued, do you have an exit path or just a migration project? If external connectivity is restricted, which parts of your architecture stop functioning immediately?These questions are uncomfortable because they expose design assumptions that are usually left unchallenged. Most organizations discover that their “sovereign” architecture contains far fewer independent components than expected. Sovereignty requires intentional friction True digital sovereignty is not achieved by avoiding cloud platforms. It is achieved by designing for optionality, even when it introduces friction. That can include:Avoiding unnecessary proprietary abstractions in core systems Designing data portability as a requirement, not a future task Separating identity from infrastructure providers Maintaining documented, tested exit strategies for critical services Ensuring that no single provider becomes a structural bottleneckNone of these decisions are purely technical. They are architectural governance choices. And they often conflict with short-term efficiency goals. Which is why they are frequently postponed. Leadership, not infrastructure, defines sovereignty At its core, digital sovereignty is not a cloud architecture problem. It is a leadership problem. Because the hardest part is not building systems that are portable or independent. The hardest part is deciding when dependency is acceptable and when it is not. Every organization will rely on external platforms. The question is not whether dependency exists, but whether it is understood, measured, and intentionally managed. Without that clarity, sovereignty becomes a narrative rather than a capability. Closing thought Digital sovereignty is not where your cloud runs. It is whether you could still operate if your assumptions about that cloud stopped being true. And in most modern architectures, that question is less theoretical than it seems.