Digital Sovereignty: How to Choose a Controllable Cloud Architecture

Executive summary

In 2026, cloud sovereignty is becoming a decision criterion for companies that want to retain control over their data. However, a European alternative cannot be assessed solely on the location of its servers: the applicable jurisdiction, the provider’s certification, service continuity, traceability and reversibility matter just as much. European offerings are progressing, but they cannot immediately replace all the capabilities of American hyperscalers. A general migration could therefore shift the dependency without guaranteeing operational efficiency. The most robust decision is to segment data and services according to their criticality, then apply the appropriate level of sovereignty to each scope. The objective is not to choose sides, but to build an architecture that can be operated, audited and reversed.

TL;DR

• Locating data in Europe does not, by itself, guarantee sovereignty: jurisdiction, access, backups and operating conditions must also be examined.
• SecNumCloud certification is a useful reference for identifying offerings suited to sensitive systems; it does not remove the need to assess their fit with operational requirements.
• Reversibility must be prepared before signing: export formats, exit costs, transfer times, restoration and assistance must be specified and tested.
• A hybrid architecture can distribute services according to their criticality, at the cost of more complex integration, governance and supervision.
• The relevant choice concerns less the provider’s declared origin than the legal, technical and operational dependency that the company is genuinely prepared to accept.

1. What decision actually needs to be made?

The choice is not simply a matter of setting an American hyperscaler against a European provider. The company must decide, scope by scope, which data and services it can entrust to which type of provider, under which jurisdiction, with what level of continuity and what ability to exit.

The more useful question is: which data, services and dependencies is the company prepared to entrust to which type of provider?

Not all applications have the same criticality. The unavailability of a production, logistics, finance or human resources system can have a major impact on the business. Other services handle less sensitive information or can tolerate a longer interruption. Applying the same architecture, requirements and certification level to all of them generally creates unnecessary cost or insufficient protection.

Separating three different motivations

A sovereignty initiative may respond to at least three different rationales:

• A regulatory or contractual obligation, which considerably reduces the number of acceptable options
• A reduction in legal risk, particularly when the provider’s situation could expose data to a transfer outside the European legal framework
• A strategic preference, intended to reduce provider dependency or preserve future freedom of choice.

These motivations do not necessarily lead to the same decision. For some organizations and critical systems, using French or European providers is an obligation. For others, sovereignty is a trade-off between control, service availability, migration effort and accessible skills.

The first decision is therefore not to select a provider. It is to classify the scopes involved. Which data is sensitive? Which services are essential to business continuity? Which applications depend heavily on proprietary technologies? What level of interruption is acceptable?

This segmentation avoids two symmetrical mistakes: automatically preserving all existing dependencies or launching a general migration in the name of a principle without checking whether the target architecture meets actual needs.

2. What cloud sovereignty covers—and what it does not guarantee

A server located in Europe may meet a localization requirement. That alone is not enough to establish complete control over the service and the data.

Cloud sovereignty covers several related but distinct dimensions:

• The location of primary data and backups
• The jurisdiction to which the provider and processing activities are subject
• The people or entities authorized to access the data
• The provider’s structure and, depending on the certification sought, its ownership
• Operating, monitoring and restoration conditions
• The ability to audit the service and demonstrate compliance
• The ability to leave the provider without disproportionate cost or interruption.

A legal tension to examine provider by provider

A potential conflict may exist between the requirements of the General Data Protection Regulation (GDPR) and those of the US CLOUD Act. Depending on the provider’s situation and access arrangements, using an American solution may expose a European organization to a risk of data transfer outside the European legal framework.

This does not mean that all American offerings present exactly the same risk, or that every European offering automatically eliminates it. It does, however, require the company to examine jurisdiction, contracts, possible access and transfer mechanisms rather than stopping at the displayed location of the data center.

Control must also be verified under degraded conditions

Location alone says nothing about the ability to maintain or restore a service. Backups, redundancy, the disaster recovery plan, the business continuity plan, monitoring and restoration procedures must also be examined.

A service can therefore be located in Europe while leaving the company insufficiently prepared for an outage, incident or provider exit. Conversely, an architecture that is legally demanding but impossible to restore within acceptable timeframes does not truly protect the business.

Traceability completes this chain of control. The company must be able to demonstrate, including after the fact, who accessed which data, under what conditions and under whose responsibility. Sovereignty then becomes concrete: it is embodied in permissions, logs, controls, contracts and operational procedures.

3. What European alternatives can actually provide

Europe is capable of developing cloud solutions that offer alternatives to American providers. Several initiatives show that this trajectory is more than a political intention. They do not, however, demonstrate general equivalence with hyperscalers in terms of capabilities, prices or performance.

SecNumCloud: a reference point for sensitive systems

According to the French National Cybersecurity Agency (ANSSI), SecNumCloud certification distinguishes offerings suited to sensitive systems from those that are not. It therefore provides a more demanding reference point than a simple declaration of location or sovereignty.

One account describes the migration of a disaster-recovery information system to a SecNumCloud-certified offering, with security described as having been strengthened. This example indicates that a clearly defined scope can be a relevant entry point: the need is identifiable, recovery requirements are central and the desired outcome is not limited to moving data.

It does not, however, justify generalizing a security gain to all migrations. The level achieved depends on the system concerned, its configuration, its operation and the controls actually implemented.

Ecosystems are beginning to take shape

MAIF announced that it was strengthening its information system with Mistral AI, Scaleway and Diabolocom, in a context combining artificial intelligence development with the pursuit of sovereignty. This example illustrates an approach based on combining providers rather than replacing one single provider with another.

In the Netherlands, the Open Cloud Alliantie brings together seven technology companies that have adopted common technical standards. Such cooperation can support interoperability, which is an important condition for reducing dependencies. The existence of common standards does not, however, by itself prove that all platforms are interchangeable or that migration will be simple.

These initiatives make the European alternative credible for certain scopes, without demonstrating general substitutability. The decision depends on the gap between the operational need and the capabilities available for each service: if the gap is acceptable, a targeted migration becomes defensible; otherwise, the architecture must retain or distribute the missing capabilities.

4. What the sovereign option costs or requires

Changing cloud providers is not a simple file transfer. An application generally depends on interfaces, authentication mechanisms, backups, monitoring tools and operating procedures. The more these components are tied to the provider’s proprietary services, the more complex migration becomes.

Cost must be considered across the entire life cycle:

• Migration: dependency mapping, interface adaptation, data transfer and operational verification
• Continuity: redundancy, backup, disaster recovery, business continuity and restoration testing
• Operations: monitoring, incident management, skills retention and provider coordination
• Compliance: controls, auditability, documentation and evidence of compliance
• Exit: data export, transfer to another platform, service restoration and any period of coexistence.

This approach avoids comparing only published prices. An apparently less expensive offering may require more integration or skills. A more controlled solution may also reduce the available services or lengthen the provider-selection process.

Certification limits choice—that is also its purpose

Some certification requirements concern more than technical performance. They may relate to the provider’s structure and ownership, a criterion described as particularly difficult for providers to satisfy.

This restriction may limit the number of options and slow adoption. It should not, however, be treated as mere administrative complexity: when the organization is specifically trying to reduce an extraterritorial risk, the provider’s structure is part of the problem to be addressed.

Reversibility is not a decorative clause

Sovereignty implies the ability to move from one cloud to another without being blocked by prohibitive exit fees. In practice, this ability must be translated into the contract and tested in the architecture.

Before making a commitment, the company must examine export formats, return timeframes, transfer costs, exit assistance and the ability to restore the service elsewhere. A general reversibility clause offers little protection if the data can only be recovered in a difficult-to-use format or if the application relies on components that cannot be replaced within an acceptable timeframe.

The cost of sovereignty must therefore be compared with the cost of dependency. The former is often visible when the project begins; the latter emerges when the company wants to negotiate, migrate, restore or change its architecture.

5. Comparing the three options using explicit criteria

No option is superior on every criterion. The trade-off depends on data sensitivity, service criticality, applicable obligations and the capabilities the company actually needs.

| Option | Main benefit | Main constraint | Risk to control | Relevant use case |

|---|---|---|---|---|

| Non-European cloud | Access to established services that cannot always be replaced immediately | Potentially strong technical and contractual dependency | Jurisdiction, data access, transfers and exit cost | Less sensitive scopes where the required capabilities are decisive, after legal and technical analysis |

| European or certified cloud | Potentially stronger control over sensitive systems | More limited or less mature offering in some segments | Gap between claimed certification, available services and operating requirements | Data or services subject to strong regulatory, contractual or protection requirements |

| Hybrid architecture | Distribution of services according to their criticality | Greater integration and monitoring complexity | Fragmentation of governance, access, backups and responsibilities | Companies that need to protect certain scopes while retaining capabilities unavailable elsewhere |

This table is not a ranking. It highlights the questions that change the decision.

Criteria for differentiating offerings

Jurisdiction and ownership. Which entity provides the service? What obligations does it face? Does its structure meet the required level of sovereignty?

Certification. Does the offering have certification appropriate to the system concerned? SecNumCloud is a reference point for sensitive systems, not a label to apply indiscriminately to every use case.

Continuity. What guarantees cover availability, backups, redundancy and restoration? Have recovery procedures been tested under representative conditions?

Auditability. Can the company demonstrate regulatory and contractual compliance, including after an incident? Are access and sensitive operations traceable?

Reversibility. Can data and services be moved within acceptable timeframes, without prohibitive cost and without a complete rebuild?

Total operating cost. The service price must be supplemented with integration, monitoring, skills, maintenance, compliance and possible exit costs.

Capabilities actually required. A long list of features creates no value if the services are not used. Conversely, a sovereign architecture that removes an essential capability may degrade the process it was intended to protect.

Hybrid architecture often appears to be a compromise, but it is not a free solution. It reduces the need for a uniform choice while increasing the number of interfaces, access policies and monitoring mechanisms that must be managed.

6. When should each option be chosen?

A certified offering is particularly relevant when sensitive systems are subject to regulatory, contractual or strong data-protection requirements. Certification then provides a structuring selection criterion, provided that the offering also covers availability, restoration and operational needs.

A hybrid architecture becomes relevant when sovereignty requirements are high for certain scopes, but all the required capabilities are not available from a single European provider. Critical data and services can be isolated while other functions remain on different platforms. This choice requires clear governance of flows, access and responsibilities.

Keeping a non-European service may remain defensible for a less sensitive scope when its operational value justifies the dependency. This decision should nevertheless be made only after examining jurisdiction, possible transfers, access mechanisms and exit conditions.

Start with a defined and reversible scope

A general migration simultaneously multiplies technical, organizational and operational risks. A progressive approach, by contrast, makes it possible to test assumptions on an identifiable service.

The first scope can be selected according to four criteria: understood criticality, mappable dependencies, a target capable of meeting the need and a possible rollback. The objective is not to produce an isolated demonstration, but to verify migration, backup, restoration and day-to-day operations.

Before starting the transfer, the company must define its exit criteria: exportable data, an acceptable recovery time, an alternative solution and restoration conditions. Reversibility does not begin when the relationship with the provider deteriorates. It is designed before entry.

For organizations subject to specific obligations, compliance must be integrated into the architecture from the outset. A late review may require the provider choice, data flows or operating procedures to be reconsidered after migration.

7. A decision framework for moving from intention to architecture

Sovereignty becomes manageable when it is translated into a sequence of verifiable decisions.

1. Map the scopes

List the data, applications, critical processes and access required to operate them. The mapping must also reveal dependencies on interfaces or services specific to the current provider.

2. Define the expected level of sovereignty

For each scope, specify the legal, technical, operational and contractual requirements. Sensitive data, a critical system and an easily replaceable service do not require the same treatment.

3. Compare providers across the full operating model

Assess certification, jurisdiction, continuity, auditability, reversibility and the capabilities actually required. Hosting location represents only one line in this comparison.

4. Test the operations that reveal dependencies

On a controlled scope, test migration, backup, restoration and rollback. These operations reveal whether general clauses do—or do not—translate into real capabilities.

5. Calculate total cost of ownership

Total cost of ownership, or TCO, must include integration, operations, skills, maintenance, compliance controls and potential exit. The aim is not to assume that one option is cheaper, but to make the cost categories comparable.

6. Decide what should be entrusted, distributed or controlled

The final decision may combine a European cloud, a certified offering, non-European services and components operated in different ways. The choice must remain clear: who controls access, who monitors, who restores and who decides on a future migration?

Data governance assigns an owner to every decision: who authorizes access, who controls flows, who triggers restoration and who approves a provider exit. Without this allocation, a hybrid or certified architecture may be sovereign on paper but unusable during an incident.

Auroramind’s position

Cloud sovereignty justifies neither a uniform migration nor the status quo. The trade-off must focus on the criticality of data and services, jurisdiction, certification, continuity and reversibility. An alternative is effective only if it can be operated, audited, restored and exited under conditions compatible with the business.

About the Author

Sylvain · Founder-operator of Auroramind

Sylvain combines two worlds that rarely meet: executive leadership in large organizations and hands-on mastery of IT and AI architectures.

For more than 25 years, he has led organizations, complex projects and operational systems. Today, he designs and deploys AI solutions for companies with a simple conviction: AI only has value when it truly transforms uses, data and processes.

His role is to separate signal from noise, challenge hype cycles, and help both leaders and technical teams move from spectacular AI to reliable, governed and productive AI.

About Auroramind

Auroramind is not just another AI agency. It is an AI architecture, strategy and industrialization studio.

We help SMEs and mid-market companies build AI systems that hold up in real operating conditions: business assistants, document RAG, AI agents, process automation, usage governance and integration with existing tools.

Our approach is based on proven methods, a strong technical culture and one obsession: producing measurable value, not demonstrations that impress for five minutes.

Auroramind steps in where AI projects become serious: when teams need to frame, prioritize, secure, deploy, measure and drive adoption.

• Book a free 1-hour call to get answers about AI integration in your company.
• Assess your company's AI maturity with our free tools.