For the last decade, the cloud industry has sold a convenient fiction to regulated enterprises: “If the data stays in your jurisdiction, you are sovereign.”
We are now seeing the collapse of that narrative.
As regulatory frameworks like DORA (Digital Operational Resilience Act), NIS2, GDPR and FINMA requirements tighten, the definition of sovereignty is shifting from location to control. It is no longer enough to ask, “Where is my data stored?” The critical question is: “Who controls it?”. You can delegate labor, but you can never delegate liability.
To achieve true digital sovereignty, an organization must master seven critical domains of control. It’s not a single problem to be solved but a holistic strategy to be implemented.
The Seven Pillars of Digital Sovereignty
You cannot govern an IT estate you don’t fully understand. True sovereignty requires a baseline of control across these key areas:
- Data Sovereignty: The physical and jurisdictional control of your data throughout its lifecycle, including the keys that protect it.
- Implementation Sovereignty: The ability to avoid vendor lock-in and maintain operational freedom through a technology-agnostic architecture.
- Operational Sovereignty: The capacity to maintain, operate, and recover your systems without reliance on external providers, especially during a crisis.
- Assurance Sovereignty: The power to independently and continuously audit and validate the integrity of your systems, providing immutable proof of compliance.
- Tooling Sovereignty: The ability to assemble a best-of-breed toolchain, avoiding monolithic, single-vendor stacks for both software and services.
- Executive Oversight: The ability to provide leadership with clear, business-relevant data on risk, cost, and compliance, enabling informed governance.
- Managed Services Flexibility: The ability to enforce universal policies across a hybrid landscape of on-premise, public cloud, and local managed service providers (MSPs) without sacrificing control.
Let’s explore how a modern control plane provides the technical foundation to master each of these domains.
1. Data Sovereignty: Beyond the Contractual Clause
A cloud contract may specify data residency in a certain country, but how do you technically control who can access it? How do you manage the keys that protect it? Can you guarantee that sensitive data is only accessed from within your jurisdiction, under policies you define?
True data sovereignty means owning the encryption keys and enforcing access policies that are independent of the provider. A sovereign control plane can act as a gatekeeper, integrating with your own Key Management System (KMS) to ensure that only trusted, jurisdictionally-compliant services can decrypt sensitive information. This moves beyond simply storing data in a specific location to having direct, technical authority over who can read it—a critical distinction for regulators.
2. Implementation Sovereignty: Decoupling Logic from Execution
Vendor lock-in is the silent enemy of sovereignty. When your operational knowledge is embedded in proprietary stacks, you lose the ability to choose. The key question becomes: Can you migrate critical applications to different cloud platforms if needed?
A technology-agnostic “Living Blueprint” of your estate provides the answer. This blueprint defines what your infrastructure should look like—the servers, the networks, their dependencies—independent of the tools that build it. The controller’s output engine then translates this blueprint into specific configurations for any tool you define, be it Terraform, Ansible, or Kubernetes manifests. If you decide to migrate from one cloud provider to another, you don’t re-architect your core model; you simply update the output template. This decouples architectural intent from the underlying technology, neutralizing vendor lock-in.
3. Operational Sovereignty: Owning the “Brain”
Your team relies on a provider’s SaaS management console to operate, patch, and recover your systems. But can you continue operating critical systems if those external cloud services become unavailable? A network outage, a geopolitical event, or a simple vendor decision can render your “local” infrastructure a zombie—un-patchable, un-scalable, and un-configurable.
This is why the control plane—the “brain” of your operations—must be self-hosted and ready to run in an air-gapped environment (disconnected from the public internet). The Rescile controller runs entirely within your boundary, as a single binary. During a disaster, even if the primary cloud provider’s management plane is down, your team can access the complete, up-to-date blueprint of your estate. From there, you can generate the necessary runbooks and IaC to fail over to a secondary site. Your ability to initiate recovery is never reliant on an external party’s management services.
4. Assurance Sovereignty: From Manual Audits to Immutable Proof
An auditor asks you to prove that every production database has a disaster recovery replica. This typically triggers a frantic, manual evidence hunt. The real question is: Do you have the ability to independently verify the security and integrity of your digital systems at any time?
This requires turning compliance from a periodic event into a continuous, automated process. By modeling your cloud regions, on-premise data centers, and data classifications as resources in a dependency graph, you can create declarative rules that enforce jurisdictional control. A rule can state: “Find every resource classified as ‘PII’ and ensure it is deployed in a region with the property jurisdiction: 'CH'. If not, enforce.” The controller audits the graph in real-time. Answering the auditor becomes an instant GraphQL query or a predefined output in formats like OSCAL, providing immutable proof.
5. Tooling Sovereignty: Escaping the Single-Vendor Stack
Large vendors sell an all-in-one dream: a single, integrated stack for infrastructure, operations, and security. While convenient, this creates the deepest form of lock-in, binding your operational logic to a proprietary ecosystem. A truly sovereign approach favors a composable architecture, assembling a best-of-breed toolchain from smaller, dedicated components—whether they are open-source projects or specialized commercial services.
This strategy hinges on a crucial question: Can you replace or take over maintenance of critical toolchain components if needed?
For an open-source tool, this could mean forking its code; for a commercial service, it means having the architectural freedom to replace it. A control plane that abstracts your architectural intent from the underlying tools is the key. It allows you to define your desired state in a universal model and then use output engines to drive any tool you choose—Terraform, Ansible, Crossplane, or a custom script. If a tool’s license changes or a vendor is acquired, you can swap it out for another without re-architecting your entire system. A controller built on open, human-readable formats like TOML and Git gives you this freedom, ensuring the path to sovereignty is not locked behind a proprietary gate.
6. Executive Oversight: Bridging Business and Technology
Leadership needs to understand risk and cost, but technical reports are often inscrutable. How do you ensure that digital sovereignty is explicitly part of your corporate or IT strategy, rather than a siloed technical concern?
The dependency graph must be more than a technical map; it must be an organizational one. By linking technical assets to business context, the graph allows for powerful, business-level queries. For instance, your entire vendor hierarchy can be modeled as part of the graph. A service isn’t just a technical node; it’s linked to its maintainer, which in turn is linked to a vendor that has its own subcontractors. This creates a clear, queryable chain of responsibility. When a regulator like FINMA asks for a complete list of all third- and fourth-party suppliers involved in a critical business function, you don’t hunt through spreadsheets. You run a single query against the graph and get an instant, auditable answer based on your supply chain model. This provides true leadership-level governance, aligning sovereignty goals with financial and operational KPIs and providing clear visibility into supply chain risk.
7. Managed Services: True Hybrid Flexibility
You want to use a mix of on-premise data centers, public clouds, and local managed service providers, but managing them in silos creates chaos. How do you restrict cloud deployments to specific regions or certified data centers universally?
A unified model of your entire hybrid world is the solution. It doesn’t differentiate between a virtual machine on-premise, an S3 bucket in AWS, or a service from a local managemed service provider. Each is simply a node in the graph. This “single pane of glass” allows you to define universal policies that span all environments. You gain ultimate flexibility without sacrificing centralized control.
True sovereignty means you—not your provider—control the “brain” of your infrastructure.
- You own the management system (the “control plane”) that runs your operations.
- You store the master data and rules in your own security boundary (e.g., your on-premise data center or a dedicated Virtual Private Cloud).
- You define the architectural and compliance logic—not your vendor.
By owning the control plane and the logic, you reduce the provider to a utility. You can swap providers—whether they are local or global—without losing your operational intelligence or compliance posture.
Recently, industry giants like IBM and HashiCorp made announcements that validate the exact philosophy Rescile was built upon.
IBM recently announced “IBM Sovereign Core”, a software foundation designed to give organizations complete operational authority. Their announcement hits the nail on the head:
“Digital sovereignty goes beyond data residency. It encompasses who operates and controls the technology environment… [and] under whose jurisdiction AI models run.” — IBM
Simultaneously, HashiCorp announced “Project Infragraph”, admitting that the current state of infrastructure management is plagued by “fragmented visibility.” They argue that to manage complexity and enable AI, you need a unified Resource Graph.
We agree with them entirely. These announcements act as massive market validation for what Rescile built with the controller. But there is one key difference: They are announcing a roadmap. We are already shipping a reality.
Don’t Wait for the Future. Build it.
IBM and HashiCorp have finally acknowledged what we’ve known for years: Sovereignty isn’t just about where your data lives—it’s about who controls your entire operational stack.
IBM’s Sovereign Core and HashiCorp’s Project Infragraph are steps in the right direction. But they’re still on the drawing board.
Rescile allows you already to decouple your governance from your infrastructure provider. Whether you use a public cloud, a local managed service provider, or your own data center, Rescile sits above them all as the Sovereign Intermediary—keeping your logic, your keys, and your compliance rules safely within your boundary. Because your logic is stored in open formats like Git and TOML, you retain ownership of your intellectual property—not the tool.
Sovereignty isn’t a feature you rent. It’s a capability you must own—before the next audit.
Compare Rescile Editions or Download the Community Edition to start building your sovereign graph today.
TL;DR: Why Data Residency Isn’t Enough
- ✅ Regulators care about control, not location (DORA, FINMA, NIS2). You cannot outsource liability.
- ✅ A self-hosted control plane is non-negotiable. SaaS management tools create a “kill switch” outside your control.
- ✅ True sovereignty requires mastering seven domains, from data and operations to technical and assurance controls.
- ✅ A living blueprint (or dependency graph) is essential to manage complexity, prove compliance, and automate operations.
- ✅ Sovereign AI requires a secure, self-hosted context to be useful without creating compliance risks.
- ✅ Rescile gives you the control plane, graph, and enforcement engine—today.