Sovereign Cloud Strategy Is Not A Yes/No Question

Sovereign cloud has moved from buzzword to board-level concern. The EU is tightening its Cloud Sovereignty Framework, the Data Act is coming into force, and initiatives like Gaia-X, national “cloud de confiance” programmes and sector data spaces are maturing.

At the same time, hyperscalers are launching their own sovereign offers: AWS European Sovereign Cloud operated only by EU entities, Google’s extended “sovereign cloud” options in partnership with players like Thales, and similar moves from others.

In that context, many organisations ask a deceptively simple question:

“Should we go for a fully sovereign cloud, or should we optimise for best of breed and not care where the data sits?”

As CTO, CIO or CDO, I would never answer this with a binary yes/no. It is the wrong question. Sovereign cloud is not a product to tick on a procurement list. It is a strategy that must be designed, case by case, for a given industry, a given company and a given portfolio of data and workloads.

This article explains why there is no universal answer, why “just use two clouds” is usually not the solution, and how I would structure a real decision process at C-level.

1. Sovereign cloud is three questions, not one

A lot of confusion comes from mixing three different ideas:

1. Data residency Where is the data stored and processed physically.
2. Data sovereignty Which jurisdiction actually has legal control over the data.
3. Operational sovereignty Who operates, administers and supports the service in practice.

Any sovereign strategy that does not clearly separate these three dimensions will lead to bad decisions.

2. The false comfort of “let’s just use multiple clouds”

The “obvious” answer some teams jump to is:

“We will put sensitive data on a local sovereign cloud and keep everything else on a global hyperscaler. Best of both worlds.”

On paper, that sounds reasonable. In practice, a real multi-cloud strategy is one of the hardest things to execute at scale:

• You double or triple all resources (It's not linear)
• You lose economies of scale on tooling, licenses, landing zones and platform teams.
• You create complex data integration paths between clouds and sometime annihilate the original sovereign goal without knowing it.
• You risk ending up with the worst of both worlds.

This does not mean multi-cloud is always wrong. It means it must be a deliberate design decision with clear scope and guardrails, not a reflex.

3. The only honest answer: “it depends” – but with structure

Saying “it depends” is not enough. The role of CTO, CIO or CDO is to turn that into a structured strategy that a board can understand and own.

For a sovereign cloud decision, I would always work along at least four axes:

1. Industry and regulatory pressure
2. Data criticality and sensitivity
3. Jurisdictional and dependency risk
4. Business model and innovation needs

The output is not “yes sovereign / no sovereign”. It is a map of where sovereignty is non-negotiable, where it is desirable, and where global best of breed remains the rational choice.

4. Three realistic patterns instead of a binary choice

Pattern 1: Sovereign-first for critical data, integrated with global cloud

Examples include:

• EU-only sovereign regions from global providers.
• European sovereign providers aligned with EU initiatives.

Everything else can remain on standard global regions.

Key condition: treat this as one enterprise platform with unified identity, governance and security. and accept all tradeoffs and remember them in futur discussions.

Pattern 2: Global-first with strong sovereignty controls

Here, a hyperscaler is the primary platform, but you apply strong sovereignty controls:

• Regional data boundaries.
• Encryption with customer-controlled keys.
• Confidential computing.
• Contractual and regulatory compliance alignment.

Pattern 3: Sector data spaces and European ecosystems

In some industries, the real question is not “which cloud provider” but “which ecosystem” you must join.

Examples include sector data spaces like Catena-X or healthcare data spaces aligned with EU programmes.

In those cases, sovereignty is about federation, standards and data-sharing rules.

5. Additional concern: can global providers truly separate sovereignty?

A central question remains: when international cloud providers claim they will operate sovereign environments fully independent from their native market, how realistic is that promise?

The operational separation can be feasible: EU-only staff, isolated regions, contractual and legal firewalls. But the real friction lies in the code itself.

Global cloud platforms are built on globally shared codebases, engineering pipelines and service architectures. Rewriting all cloud services natively for each sovereign market would require:

• Duplicating entire engineering teams.
• Maintaining parallel codebases.
• Rebuilding foundational services from scratch.
• Slowing down global innovation cycles.

In practice, most hyperscalers centralise their builders, and sovereign variants still rely on large parts of the global codebase. This is not necessarily a problem, but it is a reality that executives must understand when assessing technical and legal sovereignty claims.

This concern reinforces why sovereignty is never a binary choice and why a realistic strategy must look beyond marketing labels.

6. Why I will never give a one-line answer as CTO / CIO / CDO

If a board asks:

“Are we going sovereign or not?”

my honest answer is:

“We will define where we must be sovereign, where we should be, and where it is not worth the trade-off.”

There are several reasons.

5.1 The trade-offs are too big to hide

Going strict on sovereignty can mean:

• Slower access to the latest AI capabilities.
• Smaller partner ecosystem.
• Higher costs.

Optimizing for global innovation can mean:

• Higher exposure to extraterritorial access.
• Concentration risk.
• Regulatory friction.

5.2 Multi-cloud as an excuse hides complexity and risk

Multiple clouds can become unmanageable without:

• A clear control plane.
• Defined data movement rules.
• Clear team ownership.

7. How I would run a sovereign cloud strategy decision

Step 1: Align the C-suite

Clarify business priorities, regulatory landscape, and strategic constraints.

Step 2: Classify data and workloads

For each domain, assess sensitivity, regulatory obligations, performance and interoperability needs. It has to be done, end-to-end (tedious task should I remind?)

Step 3: Design target patterns

Assign the three patterns to different data and workload categories.

Step 4: Evaluate options with facts

Compare candidate architectures on cost, compliance, innovation, dependency risk and long-term viability.

Step 5: Educate and align the organisation

A sovereign cloud strategy only works if leadership and teams understand the trade-offs and practices.

8. What does true cloud sovereignty actually mean?

The industry often uses the term “sovereign cloud” without defining what sovereignty really includes. In reality, true cloud sovereignty spans several layers, and each layer raises difficult questions that go far beyond data location.

8.1 Where the data resides

Data residency is the simplest dimension: storage, processing and backups kept within a specific geography. But residency alone does not guarantee sovereignty.

8.2 Who operates the cloud

Operational sovereignty requires that the people administering, supporting and securing the cloud are subject only to the laws of the intended jurisdiction. This raises questions:

• Are operations performed exclusively by EU-based and EU-vetted individuals?
• Are support escalations fully isolated?
• Are monitoring, logging and incident management pipelines truly local?

8.3 The nationality and jurisdiction of the provider

Even if data is local and staff are local, a provider headquartered elsewhere may still be subject to foreign laws, potentially enabling extraterritorial access requests. This is where the risk lies with global hyperscalers.

8.4 The codebase question

Even the best-isolated region still depends on a global codebase maintained by engineering teams outside the jurisdiction. Key questions remain:

• Could code updates introduce obligations or backdoors under another jurisdiction?
• Could features be withheld from sovereign regions, intentionally or unintentionally?
• Could an update be blocked, causing a degraded or lagging service?
• Is it realistic for a provider to maintain parallel, jurisdiction-specific versions of their entire service catalog?

In most cases, the answer is no—cloud services are too deeply integrated globally.

Cloud is not just a data repository, it's based on very important services that make applications, products and most of the internet.

8.5 Political or strategic shutdown risk

Another dimension seldom discussed openly: could a sovereign or semi-sovereign cloud be unplugged for political reasons?

• Could a global provider disable a region under geopolitical pressure?
• Could a local operator lose access to upstream technology or patches if a partnership breaks down?
• Could export regulations suddenly restrict essential components?

True sovereignty requires thinking through the resilience of the entire ecosystem.

8.6 The conclusion

Cloud sovereignty is not about one factor but a multi-dimensional posture combining:

• Data location
• Operational control
• Jurisdictional protection
• Engineering independence
• Political and supply-chain resilience

This is why cloud sovereignty is inherently complex and why simplistic yes/no positions are inadequate.

9. Conclusion: sovereign cloud as a strategy, not a sticker

European organisations must take sovereignty seriously. But choosing a provider without deep analysis is dangerous.

The real work is:

• Accepting that there is no universal answer.
• Designing patterns aligned with industry, data and risk.
• Avoiding naïve multi-cloud complexity.
• Building an educated, transparent decision that the whole C-suite owns.

More details about my approach are available at: www.douchinconsulting.com.

#CloudSovereignty #SovereignCloud #CloudStrategy #DigitalSovereignty #DataGovernance #CloudSecurity #CIO #CDO #CTO #EUDataAct #GaiaX #MultiCloud #HybridCloud #CloudTransformation #EnterpriseCloud #TechLeadership

‍