Digital sovereignty and the public cloud in Belgium: how do the pieces fit together?

What is digital sovereignty?

Let's first take a quick step back together. Context, clarity and nuance matter in this discussion around digital autonomy.

Digital sovereignty is the ability of a country or a business to stay in control of its own digital future. It covers a lot more than just where data physically sits (data residency).

In 2026, we define digital sovereignty around three pillars:

• Data sovereignty: the guarantee that data is subject to the laws and regulations of the jurisdiction where it's located. That means control over who can access data and under what conditions, without foreign legislation, such as the US CLOUD Act, being able to intervene.
• Operational sovereignty: the ability to manage and control your cloud and infrastructure independently, from running updates to managing infrastructure and encryption keys, ideally with staff based within your own jurisdiction.
• Technological sovereignty: the freedom to choose and switch technology without being locked into a single vendor, backed by a real exit strategy. Open-source standards and cloud-native technology are a key part of that. Think of choosing Kubernetes as the foundation on top of your cloud services.

Why does digital sovereignty remain a hot topic?

Ongoing geopolitical tension between the United States and the European Union makes it difficult to reach agreements on managing, processing and exchanging sensitive data. A data privacy framework matters, because many European businesses are hugely dependent on American cloud providers

What happens if the worst-case scenario becomes reality and European law shuts American cloud enterprises out? What if AWS, Azure and Google's cloud services become legally off-limits in Europe? Or the other way around: what if the US government claims access to data belonging to European businesses? How far does the CLOUD Act really reach in practice, given that it allows the US government to demand access to data under certain conditions? Recent events show that there have already been real cases of data being leaked, or access being cut off.

What are AWS, Azure and GCP actually doing?

How are the three big cloud players, Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP), navigating this uncertainty?

Their strategy is clear: reassure European customers with dedicated "sovereign" offerings, without cannibalizing their global model. But how does that translate into concrete steps for the digital sovereignty of Belgian businesses?

AWS: European Sovereign Cloud

AWS is betting heavily on the AWS European Sovereign Cloud (Germany, Brandenburg), fully operational since January 2026. It's a separate, independent cloud infrastructure, physically, operationally and logically separated from AWS's existing regions.

• aws.eu — An independent cloud for Europe
  AWS describes the European Sovereign Cloud as a standalone offering built entirely within the EU, designed to help customers meet strict digital sovereignty requirements through dedicated technical, operational and legal safeguards.

The core promise: all customer data, including metadata, stays within the EU and is managed exclusively by EU-based, EU-vetted staff.

Critics still point to the American parent company. Because AWS US remains part of the contracting structure, the reach of US law stays a point of concern.

Azure: Cloud for Sovereignty

Microsoft continues to build out its Microsoft Cloud for Sovereignty, in effect since early 2026. This isn't a separate cloud, but an extensive set of policies, guardrails and tools layered on top of the existing Azure cloud. It lets customers configure a "Sovereign Landing Zone" that meets strict compliance requirements.

Azure pairs data residency guarantees with advanced encryption and confidential computing, keeping data encrypted even while it's in use.

In December 2025, Microsoft also launched ABC (Azure Belgium Central), a brand-new region for the Belgian market.

The latest Microsoft updates on digital sovereignty, straight from the source:

• Microsoft completes landmark EU Data Boundary
• The ABC of Azure Belgium Central
• Microsoft opens its first cloud region in Belgium

GCP: Data Boundary and Dedicated

Google also expanded its sovereignty options in 2025. With Google Cloud Data Boundary, customers can strictly define the geographic boundaries for where their data is stored and processed.

• Google has had its data center in Mons (Bergen) up and running since 2010 — datacenters.google/locations/belgium. Worth noting: at the time, this was Google's first data center outside the US.

Google also offers Google Cloud Dedicated, an air-gapped or hybrid solution delivered together with local partners (such as T-Systems in Germany, and together with Proximus in Luxembourg) to meet the strictest local sovereignty requirements from governments.

Could the answer lie in Europe after all?

Now, over to Europe: could the key to our digital autonomy actually lie closer to home? Especially in combination with open source. We joined the Eurostack initiative as a co-supporter back in October 2025.

SUSE has, since last year, positioned itself firmly as a European champion of the open, sovereign cloud. With the recent signing of the EuroStack letter, SUSE, together with other European tech companies, is pushing for a stronger focus on sovereign European digital infrastructure.

For Belgian organizations, SUSE's portfolio, think Rancher for Kubernetes management and NeuVector for container security, offers concrete tools to avoid vendor lock-in. For SUSE, real sovereignty starts with the freedom to choose where and how you run your applications, independent of the underlying cloud provider. That opens the door to combining it with other players.

European players

Several European players are active today too. Here's an overview of a few worth keeping an eye on.

Cloud native as a stepping stone to digital sovereignty

Cloud native is a strategic enabler for digital sovereignty, by building applications and infrastructure on open-source standards such as Kubernetes and containers.

A cloud-native architecture makes applications, data and systems inherently portable. A container running on AWS today can run on Azure, a local Belgian cloud provider, or an on-premise cluster tomorrow, with minimal changes.

This breaks the classic vendor lock-in that comes from relying on proprietary services from the hyperscalers. Organizations that standardize their infrastructure on Kubernetes create an abstraction layer that gives them the flexibility to move workloads to whichever cloud best fits their sovereignty requirements at any given time.

The Cloud Native Landscape and Cloud Native Trail Map give you an overview and a roadmap to get started.

➡️ Choose a Cloud Native-first design for your IT today, regardless of whether you're on public cloud, private cloud or on-prem. It's an investment now, but it buys you more room to move later.

Digital sovereignty and NIS2: how does that connect?

The NIS2 directive, in force under Belgian law since late 2024, draws a direct line between cybersecurity and sovereignty. NIS2 requires organizations in essential and important sectors (energy, transport, healthcare, but also digital service providers) to take strict risk management measures and report incidents.

The connection to digital sovereignty runs two ways:

1. Control over the supply chain: NIS2 requires organizations to assess the security of their entire supply chain, including their cloud providers. That forces a critical look at security practices and the legal jurisdiction of the provider.
2. Data governance and risk management: the directive requires a thorough understanding of where critical data sits and who has access to it. That ties directly into the principles of data and operational sovereignty. Choosing a sovereign cloud solution can help demonstrate that adequate measures are in place to limit risk.

How do you piece it all together now?

That covers the theory and the latest developments. One question remains: what should you and your business actually do with this? We see four possible levels, ranging from full trust in the American three to complete decoupling.

Level 1: EU regions from the big American players

• You choose a region in the EU with a public cloud provider, which keeps your data "pinned" there.
• Not all services, and not always the newest ones, are available in every EU region. That said, this has become much less of an issue over time.
• One thing to watch: because the parent companies remain American, some legal experts still don't consider this fully "sovereign."

Level 2: Sovereign clouds from the big American players

• You set up an environment in a dedicated, EU-operated region.
• Here too, not every service is immediately or fully available, but data still stays "pinned" to the region you choose.
• The region is operationally run by European staff and companies.
• One thing to watch: legal experts still consider these European regions subject to the CLOUD Act, which can require providers to disable services or share data in certain cases, following notification.

Level 3: European and Belgian cloud solutions

• You work with a European or Belgian cloud player.
• Not all the services and capabilities the big three offer are available here.
• Redundancy, SLAs and capacity aren't (yet) on par with the big players.

Level 4: On-premise solutions

Managed

• On-premise using tools from a public cloud provider combined with co-location (for example, AWS Outposts).
• On-premise using tools from a private cloud or infrastructure provider (for example, VMware Tanzu, Red Hat OpenShift, Oracle, SAP Kyma, …).

Self-served

On-premise using open tools from a provider (for example, SUSE and Rancher RKE2).

Take the first step

Wherever your starting point is, and whatever your plans look like, we have the knowledge and experience to guide you toward the right solution. Whether we write the strategic plan together with you, or help you bring your own plan to life: let's get in touch.

But let one piece of advice be crystal clear: choose Cloud Native solutions built on containers and Kubernetes today, without hesitation. They give you freedom of choice down the line, and that's what all of us are after in a changing world.

If you'd rather map things out yourself first, this checklist can help.

Disclaimer: given how fast this topic evolves, it's worth continuing to check current, reliable sources as well.

🗒️ Free resource 1

Checklist for security and digital sovereignty

Balancing innovation, security and sovereignty takes a deliberate approach. Use this checklist as a guide for your strategy:

• Data classification
  • Identify and classify your data. Which data is strategic, sensitive, or subject to specific regulation?
  • Determine the residency, sovereignty and compliance requirements for each data category.
• Provider evaluation
  • Analyze your cloud provider's sovereignty offering. Go beyond the marketing and read the fine print on data access, metadata and operational management.
  • Evaluate the risks from foreign legislation (e.g. the CLOUD Act). Does the provider offer solid contractual and technical guarantees?
• Technical measures
  • Implement a zero-trust architecture: trust nothing, verify everything.
  • Make full use of encryption: at rest, in transit and, where possible, in use (confidential computing).
  • Manage your own encryption keys (Bring Your Own Key/Hold Your Own Key) and ideally store them outside the cloud provider's infrastructure.
• Exit strategy and open standards
  
  • Build your applications on open standards (e.g. Kubernetes) to guarantee portability.
  • Avoid deep integration with proprietary PaaS services that make migration complex and costly.
  • Document and test your exit strategy: can you actually move your data and applications within an acceptable timeframe?
• NIS2 compliance
  • Map your supply chain. Do you know which (sub)processors your cloud provider relies on?
  • Have a robust incident response plan that accounts for NIS2's reporting obligations.

🗒️ Free resource 2

Below is a table you can use to conduct your own analysis of another public, private, or on-premises infrastructure. We also used this table to analyze other providers based on our requirements.