Digital sovereignty: location, access and operations held apart

What digital sovereignty means in IT infrastructure

Digital sovereignty is the ability to decide about your own data, systems and architecture without needing a third party to agree. The term is often debated as a matter of principle. Technically it is not. It breaks down into three levels that can be examined separately, and that in practice regularly come apart.

Level 1: location

Where the data physically sits, where the systems run, which paths the network takes. This level is the easiest one to answer, which is why it is so often quoted as a stand-in for the whole question.

Level 2: access and law

Who can legally access the data, under which law, on what grounds, and whether you would find out. What decides this level is not geography but the legal form and seat of the provider and of its parent company.

Level 3: operations and architecture

Who operates the platform, who holds administrative access, and whether you could replace a core component without a provider having to agree. This is the level on which sovereignty is won or lost over the years.

Two related terms come up in the same discussions. Data sovereignty means control over the data itself: who may process it, copy it, analyse it. Data residency is narrower still and describes only where a data set is held. Both are subsets of digital sovereignty, which also covers the platform and its operation. Anyone who talks about data alone overlooks that an application can stand still even when the data itself is untouched.

Data residency is not data sovereignty

The most important distinction in the whole topic sits in two terms that are used almost interchangeably in procurement documents. Data residency answers the question about the storage location. Data sovereignty answers the question about legal authority. Treating them as the same leaves a gap in a legal review that cannot be closed at short notice.

The reason is the US CLOUD Act of 2018. It allows US authorities, under certain conditions, to access data held by US companies, regardless of whether the server stands in Frankfurt, Dublin or Virginia. What matters is not where the disk sits but who has control over it. A German or Irish data centre operated by a US group therefore answers the residency question in full and the sovereignty question not at all.

The same dividing line runs through data protection law. With the Schrems II ruling of 16 July 2020, the Court of Justice of the European Union invalidated the EU-US Privacy Shield and required organisations relying on standard contractual clauses to assess the legal situation in the recipient country case by case. Since 2023 an adequacy decision of the European Commission has again supported transfers to certified companies in the United States. That is a political foundation, not a technical one. It can change, and when it does the assessment of your architecture changes with it, without you having done anything.

What follows in practice is one simple test question. Not: is our data in the EU? But: which law applies to the company that controls our data, and what happens if that law changes.

What hyperscalers are and what their sovereign cloud offerings solve

Hyperscalers are the few globally active cloud providers that offer compute, storage and services at a scale that can be expanded almost at will: Amazon Web Services, Microsoft Azure and Google Cloud. The term describes size first of all. It becomes interesting because a particular operating model comes with that size: a great many proprietary services, deeply integrated, addressed through provider-specific interfaces.

That is exactly where the tie develops. A single virtual machine is portable. An application hanging off a dozen provider-specific services is not. The deeper the integration, the more expensive the way out, and the smaller your room for negotiation at the next change of terms. This is not an accusation against the providers, it is the predictable consequence of an architectural decision.

The large providers have responded to the sovereignty debate. Since January 2026 AWS has been running the European Sovereign Cloud, a physically and logically separated infrastructure based in Brandenburg, with an investment of more than 7.8 billion euros. Offerings of this kind are meant seriously and they do solve something: the residency question, and in part the question of who staffs operations. They do not automatically solve the question of legal authority over the parent company, nor the question of how portable the services in use are. Anyone assessing such an offering should address both points deliberately instead of assuming they are included.

That the market is moving is measurable. According to a Gartner forecast, European sovereign cloud investment in infrastructure rises from 6.7 billion USD in 2025 to 23.1 billion USD in 2027, a tripling in two years.

Free whitepaper · 8 pages

Digital Sovereignty

By Andreas Hankel, CTO onehundred. Download in exchange for your e-mail address, no sales call.

Get the whitepaper

NIS2 moves sovereignty from intent to evidence

Until the end of 2025 sovereignty was, for most organisations, a strategic preference. The EU NIS2 directive changed that, and each member state transposes it into national law with its own act and its own timetable. Germany is the clearest example to date: the implementation act has been in force since 6 December 2025, with no transition period. The group of supervised organisations grows there from about 4,500 to around 29,500. The registration deadline passed on 6 March 2026 and the grace period granted by the BSI, the German federal office for information security, ended on 31 July 2026. Both dates have gone.

The decisive difference from earlier rulebooks lies not in how demanding the requirements are but in their form. What is required is not statements of intent but documented technical measures: access control, patch management, tested recovery. Anyone who has run sovereignty as an architectural preference now has to be able to evidence it.

The sanctions match. Fines reach up to 10 million euros or 2 per cent of global annual turnover. An organisation that has not implemented the measures is not in a transition phase since the grace period ended, it is in a state that can be sanctioned.

One point is particularly relevant for the sovereignty question, and it is the point that reaches organisations outside the EU as well. Service providers are part of the supply chain. Your cloud provider and your operator are therefore part of your own duty to provide evidence, and if you supply customers in the EU, their duty reaches you through the same route. An architecture whose operation you cannot make a statement about becomes a problem at this point, even when everything runs technically. The details are in the article on NIS2.

What ISO 27001, BSI C5 and a C5 attestation actually say

In tenders and provider comparisons, certificates are readily used as a substitute for a sovereignty assessment. That does not work, because they answer a different question.

ISO 27001

The standard certifies a management system for information security: there are defined processes, named owners and regular audits. It says nothing about where the data sits and nothing about legal authority. It also matters who exactly is certified. A data centre can hold the certificate while the provider operating inside it does not. At onehundred that is precisely the case: the data centres in use are ISO 27001 certified, the company itself works to ISO 27001 and BSI compliant processes but is not certified in its own right. Ask every provider about this distinction directly.

BSI C5

The Cloud Computing Compliance Criteria Catalogue published by the BSI describes minimum requirements for cloud services and is the usual reference point in the German market. It is not a certificate but a catalogue of criteria. The audit is performed by an auditor and the result is a C5 attestation. The distinction here is important. A type 1 attestation confirms that the measures were appropriately designed at a given date. A type 2 attestation confirms in addition that they were effective over a period of time. For judging an operation, only the second case carries weight.

The C5 catalogue also covers the surrounding environment, including jurisdiction and access by investigating authorities. Those statements are the point at which an attestation touches the sovereignty question at all. Read them, instead of checking only whether an attestation exists.

The European market: initiatives, stacks and providers

Anyone looking for a sovereign alternative runs into three very different things that are often named in the same breath. Keeping them apart saves misunderstandings.

Gaia-X

A European initiative for a federated data infrastructure. Gaia-X does not operate a cloud itself. It develops rules, standards and criteria against which providers can be measured. The value lies in comparability, not in a product you can book.

Sovereign Cloud Stack

An open source project that defines and maintains a standardised, fully open cloud stack, built on established components such as OpenStack and Kubernetes. The aim is that several operators offer the same platform and that workloads can move between them. It is relevant as a counter-model to proprietary platforms, not as a provider.

Delos Cloud

A subsidiary of SAP that provides Microsoft technology under German operational responsibility for the public sector. The model addresses location and operating staff. Whether it answers the question of technological independence depends on how tightly your own applications are bound to the platform underneath. For a public authority that is a different calculation than for a product company.

Alongside these sit the classic European cloud providers and the managed service providers that build and operate a private cloud in European data centres. Here the label matters less than the concrete answer to three questions: which standards does the platform run on, who holds administrative access, and how would your systems get back out if it came to that.

How sovereignty is implemented technically

The three levels from the first section have a technical counterpart that can be described as three layers. They are the checklist for any target architecture.

Infrastructure

Public cloud, private cloud, edge, your own data centre, bare metal, network. The goal on this layer is to avoid a single point of dependency: no one provider whose outage or change of terms hits the entire estate. Hybrid is not an interim state here, it is the permanent target architecture for most organisations.

Platform

Virtualisation, containers and orchestration, storage and databases. What matters is that this layer rests on open standards: Kubernetes to CNCF standard, open virtualisation such as KVM or Proxmox, databases without proprietary extensions. This layer determines whether an application can move at all. It is also the groundwork for running AI workloads on your own infrastructure later, because the portability required for that is the same portability.

Operations

Managed operations, cost control, security along a risk management approach, automation and governance. This is where the evidence that NIS2 requires accumulates, and where it is decided whether the architecture on paper matches reality. Configuration as code is not a stylistic choice on this layer, it is the precondition for being able to evidence and reproduce a state at all.

A practical yardstick for all three layers is exit capability: how long it would take and what it would cost to replace a core component. That question can be worked through on paper and brings more clarity in a few days than a debate of principle about providers.

Sovereignty erodes in operations, not in the project

Building a sovereign architecture is a bounded project. Keeping it sovereign is a standing task: patches, access rights, changes of supplier, new workloads. The typical mistakes therefore do not happen at the start but in the two years that follow.

• The exception that stays. A service runs with another provider for the time being, because it had to be quick. The words for the time being appear in no operations manual, and the exception is never unwound.
• The access nobody withdrew. An external provider held administrative access for the migration. After the project nobody removed it, because nobody owned the question.
• Last year’s architecture picture. After about two years the documented target architecture typically no longer matches the actual state. In an audit that difference is exactly the problem.
• The criticality assessment nobody updates. Which workloads are business critical changes. If the assessment is more than twelve months old, it protects the wrong systems.
• Divided responsibility. Where build and operations sit with different parties, responsibility shifts at every handover, and with it the question of who holds access when it matters.
• The recovery that was never tested. A backup that has never been restored is an assumption. NIS2 requires evidence at exactly this point.

All six have the same root cause: sovereignty was treated as a project outcome rather than as an operational property that somebody is named responsible for.

How to establish where you stand and turn it into a plan

The way in is not a decision of principle but a stocktake. Four steps are enough for a picture you can rely on.

1. Answer the three levels separately. For your five most important systems: where the data sits, which law applies to the provider, who holds administrative access. Three columns, five rows. The gaps become visible on their own.
2. Quantify exit capability per core component. Effort and duration of a switch, estimated, but written down. A component without an estimate is a component whose risk nobody knows.
3. Check the state of your evidence. Access control, configuration state, tested recovery: does the documentation exist, and is it current. These are the same questions a NIS2 audit asks.
4. Set an order of work. Not everything at once, but staggered by business criticality: less critical systems first, core systems later with more test coverage.

Out of those four steps comes a roadmap that sets priorities instead of describing a target state. Anyone who would rather not walk that road alone can hand it over: that is exactly what our sovereign cloud offering contains, from establishing where you stand through stepwise migration to operations with evidence documented as you go. If your focus is on backup, recovery and the technical NIS2 measures, NIS2 resilience is the better way in.

A closing word on expectations: sovereignty cannot be bought, only built and kept. The movement is the same in all three theses. From the location question to the legal question. From intent to evidence. From the project to operations.