The Three Dimensions of Sovereignty - Data, Operational, and Technical

Data Sovereignty: Where Data Lives, Who Can Reach It, and Under Which Law

Data sovereignty is usually where the discussion starts. It concerns the location of data storage and processing, and who ultimately gains access. For European organizations, this often involves EU data residency, GDPR compliance, and clarity on whether personal or sensitive data leaves a specific legal jurisdiction. It also includes encryption, customer-managed keys, and control over data access pathways. For regulated workloads, trust, compliance, and contractual obligations depend on both the data’s location and the organization’s ability to verify who has read, unlocked, or disclosed it.

Physical location is only one part of the issue. The more complex questions involve jurisdiction and control: which legal entity delivers the service? Which legal system has the authority to compel that entity? Who has access to the data, metadata, support systems, and management plane? Who manages the keys, and can the customer prevent provider access when necessary?

The US CLOUD Act is often raised in this context. It would be an overstatement to suggest that US authorities can casually browse European cloud environments. The law does, however, create an obligation for covered providers to preserve or disclose data within their possession, custody or control, regardless of whether that data is located inside or outside the United States. For boards, the important phrase is "possession, custody or control." Location matters, but it is only one part of the test.

This is why the sovereign cloud initiatives from hyperscalers matter. AWS, Microsoft and Google are all responding to the same European concern: customers want the scale and innovation of hyperscale cloud, but with stronger guarantees around where data is stored, who can operate the environment, who can access support systems, where encryption keys are controlled and how much dependency remains on global infrastructure.

The approaches differ. AWS positions its European Sovereign Cloud as a separate cloud in the EU, with European governance, EU-based operations and technical separation from existing AWS Regions. Microsoft frames sovereignty as a set of capabilities across public cloud, private cloud and partner-operated clouds, including data residency, local access oversight, external key management in managed HSM, confidential computing and hybrid or disconnected options. Google offers a spectrum that includes data boundary controls in public cloud, dedicated sovereign offerings with local partners, and Google Distributed Cloud in connected or air-gapped modes.

These are meaningful developments. They can reduce non-European operational access, improve evidence for regulators, strengthen key control, support local operations, and create better options for sensitive workloads. They also show that the hyperscalers recognize sovereignty as a board-level buying criterion, not a niche compliance feature.

Careful assessment remains essential. A sovereign cloud offering from a US-headquartered provider can only be described as "outside the grip of the United States" if the specific legal, contractual and technical model supports that conclusion. The stronger and more defensible statement is that these offerings can reduce exposure and improve control, while the remaining legal and operational risks must be validated on a workload-by-workload basis.

The practical conclusion is therefore more nuanced. European boards should ask: which legal entity contracts with us? Which law applies? Where are data, metadata, logs, and backups stored? Who can access the management plane? Who operates support? Who controls the encryption keys? What happens if a government order is issued? What contractual commitments are enforceable? What evidence can we show regulators and customers?

A common misconception is that data stored in Europe is automatically safe. In reality, data sovereignty covers more than location. It is about legal authority, access paths, operational control, encryption, metadata, support processes, and evidence.

Data sovereignty is visible because it maps directly to regulation, customer concern, and public perception. But visibility should not be mistaken for completeness. A data residency commitment without clarity on access, control and jurisdiction can create confidence without substance.

Operational Sovereignty: Who Can Run, Change, or Interrupt the Service

Operational sovereignty is about day-to-day control. It asks a practical question: if something important happens, who has the authority, access, and ability to act?

That means looking beyond the system’s hosting location. Who can approve and implement changes? Who can access production environments? Who can create or remove administrator accounts? Who can view logs during an incident? Who can restore backups? Who can restart services, modify configurations, or disconnect integrations? If the primary vendor is unavailable, who can keep the service running?

These operational details determine whether the organization maintains control under pressure. A platform might appear compliant on paper, but if only an external vendor can recover it, investigate incidents, or perform critical configuration changes, then operational sovereignty is restricted.

This is why the assumption "on-premises equals control" is too simple. An on-premises environment can still depend on a vendor for firmware, licenses, identity services, managed security, remote support, or scarce internal skills. If the organization owns the hardware but relies on a single supplier to operate or recover the service, control is weaker than it appears.

The reverse is also true. A hyperscaler environment can still offer meaningful control when organizations implement strong identity governance, define support boundaries, enable customer-controlled access, maintain detailed logs, test recovery procedures, and establish solid contractual agreements. Complete independence may not be required for every workload. The required level of control depends on the risk and business criticality involved.

For low-risk internal applications, simple support agreements and recovery plans might suffice. For critical systems such as payment platforms, healthcare services, or public-sector applications, stricter access controls, tested exit strategies, auditor-ready documentation, and operational continuity in case of provider changes become essential.

Regulation is heading in this direction. NIS2 expands cybersecurity risk management and reporting requirements to additional critical sectors. DORA, especially for financial institutions, explicitly covers operational resilience, including ICT risk management, incident handling, resilience testing, and third-party risk. These regulations ask organizations to understand, govern, and manage external dependencies.

This is important because operational sovereignty transforms abstract risk into business continuity. The key question is whether the organization can maintain service operations, demonstrate control, and make decisions under pressure.

Technical Sovereignty: How Much Freedom You Have to Change Direction

Technical sovereignty is about portability, interoperability, and avoiding irreversible lock-in. It asks whether the organization can move, replace, integrate, or redesign without incurring prohibitive costs.

This dimension is closely related to architecture, but it also has a significant business impact. Lock-in to specific technologies can weaken bargaining power, reduce strategic options, and increase the cost of future change.

Technical sovereignty depends on data formats, API options, proprietary platform services, automation tools, identity management, deployment strategies, and skills. The greater an organization’s reliance on provider-specific services, the more benefits it may gain in speed and innovation. At the same time, future migration becomes more difficult.

A common misconception is that open-source equals sovereignty. Open source can reduce certain dependencies, particularly when standards, community maturity, and portability are strong. But it still requires support, security updates, lifecycle oversight, integration, and skills. A poorly managed open-source system can introduce new dependencies.

Technical sovereignty defines the degree of freedom an organization has to adapt its direction over time. Whether a workload is sufficiently sovereign depends on how technical flexibility, operational control, and data governance come together in the organization’s specific context.

The Trade-off Matrix

The relative importance of the three dimensions differs by organization and workload.

For public sector organizations, all three aspects are often important. Data can be sensitive, operations may be politically and socially vital, and technical dependency might become a strategic issue since public services need to stay manageable over time.

In healthcare and financial services, data and operational sovereignty are particularly important. Patient records, banking information, payments, and regulated reports need legal clarity, auditability, and robustness.

For many private sector digital companies, technical sovereignty could be their top priority. They often focus on speed, bargaining power, cost management, and avoiding dependence on a single platform model.

Even within a single organization, the required sovereignty stance varies depending on the workload. A public website, an HR system, a customer analytics platform, a payment environment, and a national identity service each require a different level of control.

The Realistic Constraints

The three dimensions can move in different directions. Improving one can create pressure on another.

Stronger data sovereignty may require stricter residency, key control, and legal safeguards. That can limit the choice of cloud services, reduce automation options, or complicate operations.

Greater operational sovereignty may mean more local control, stricter access processes, and tested recovery outside the main provider model. That increases assurance, but also requires more people, governance, monitoring, and duplicated capabilities.

More technical sovereignty may reduce lock-in through open standards and portability. But avoiding provider-specific services can slow delivery, increase integration work, and limit access to innovation that creates real business value.

This is the trade-off: sovereignty choices can reduce risk, but they can also introduce cost, complexity, and slower execution. The right decision is the option that fits the workload’s risk, business criticality, and dependency profile.

Finding the Right Balance

Rather than asking whether the organization is sovereign, leadership should ask: which dimensions of sovereignty matter for this workload, and what level of dependency are we willing to accept?

This is a practical aspect of governance. Sovereignty becomes valuable when it helps leadership determine where control is essential, where dependence is acceptable, where vendors need to offer more assurance, and where extra complexity is not warranted.

The next step is to visualize dependencies. Many organizations struggle to answer the questions this model prompts with confidence. They may have assumptions, architecture diagrams, contracts, and partial inventories, but often lack a validated understanding of where critical dependencies actually sit.

Sovereignty discussions usually stall because organizations struggle to clearly see their dependencies. That lack of visibility makes decision-making harder. The next blog will explore this gap and show why visibility is the essential foundation for decisions that boards, technology leaders, and risk teams can all support.