On July 23, 2026, Atos announced a cloud platform designed and operated in the European Union. On July 27, Orange and Morrison presented plans for a French data centre joint venture targeting 400 MW of capacity and backed by a €3 billion investment programme. These announcements confirm that digital sovereignty has become a major commercial argument—but they do not remove the need for each business to define what it actually wants to control. See “Atos launches Atos Sovereign Cloud” and “Orange and Morrison announce plans to create a data centre joint venture”.
For executives, the decision is not simply between “sovereign” and “non-sovereign” services based on a brochure. It is about deciding which dependencies are acceptable, which evidence the supplier must provide and how the company will leave if contractual or geopolitical conditions change.
The promise everyone is selling: regain control with sovereign cloud
The prevailing argument is understandable. By choosing a cloud hosted and operated in Europe, a company would protect its data from extraterritorial laws, strengthen cybersecurity and reduce its dependency on global technology providers.
The promise usually covers four areas:
- data and backups remain within an agreed geographical perimeter;
- administration and support operations are performed from Europe;
- the environment is protected against certain requests from non-European authorities;
- applications can be moved to another infrastructure if required.
These are legitimate concerns. Technology dependency, business continuity, sensitive information and subcontractor control belong on the executive agenda, especially for financial, industrial, HR and research systems.
But a “sovereign cloud” label is not an architecture, a contractual guarantee or a continuity plan.
What is true: some services provide meaningful safeguards
A properly qualified offering can reduce several risks. The French SecNumCloud framework includes technical, operational and legal requirements designed to protect sensitive workloads from cybercrime and certain extraterritorial laws.
However, ANSSI states that qualification applies to a specific service, not automatically to an entire provider or the data centre housing its servers. It also explains that a digital service hosted on qualified infrastructure does not automatically inherit the qualification. These distinctions appear in ANSSI’s official SecNumCloud qualification FAQ.
Location also has genuine value. It helps identify applicable law, document the subcontracting chain and define authorised locations for data, backups and logs. Nevertheless, the customer generally remains responsible for the processing it performs and for configuring the cloud service, as explained in the CNIL guidance on qualifications and responsibilities in cloud computing.
A trusted infrastructure is therefore a stronger foundation. It does not automatically secure access rights, applications, administrator accounts or connections to the rest of the information system.
What is false, or only true under specific conditions
“Our data is in France, so we are sovereign”
This is only true if the business also knows where its backups, metadata, technical logs and monitoring tools are located—and where the people able to administer the platform work.
The contract must identify downstream subcontractors, countries from which interventions may occur and conditions governing exceptional access. A data centre address does not answer these questions.
“A sovereign service removes vendor dependency”
It may reduce legal dependency while creating technical dependency. An application built around a proprietary database, identity system or monitoring stack may remain difficult and expensive to move.
Portability must therefore be demonstrated through a complete export, usable documentation and a restoration test outside the original platform. A reversibility clause does not prove that the application will run elsewhere.
“Qualification automatically secures our applications”
ANSSI explicitly states that SecNumCloud qualification does not determine the security level of the customer’s digital service hosted on the qualified offering. Poor identity management, shared administrator accounts and vulnerable applications remain dangerous on qualified infrastructure.
“Everything should move to a sovereign cloud”
Sovereignty requirements should reflect business impact. Treating a corporate website, CRM, industrial database and payroll system in exactly the same way raises costs without addressing risks proportionately.
The practical extension of our cloud migration checklist is to assess sovereignty requirements workload by workload rather than impose one destination on the entire information system.
What an unprepared move really costs
The first cost is a migration that relocates dependency instead of reducing it. The company changes provider but recreates the same technical coupling, sometimes with fewer managed services and more custom components to maintain.
The second cost is dual operation. The legacy environment remains active because interfaces, backups or recovery procedures have not been validated. Teams must then pay for and monitor two operating chains.
The third cost appears during exit. The EU Data Act regulates cloud switching and prohibits provider-imposed switching charges from January 12, 2027. However, it does not eliminate proportionate early termination penalties or the cost of a third party hired to transform and reinstall applications. The details are set out in the EU Data Act.
Consider an illustrative scenario: an ERP is moved to a new platform without testing whether its database can be restored in a secondary environment. At contract renewal, management discovers that exporting the data is technically possible, but several application components must be replaced. Reversibility exists on paper; operational exit becomes a transformation project.
Finally, a purely technical decision can create governance debt. No one knows who may approve a new subcontractor, authorise an additional region or arbitrate between continuity, cost and sovereignty. This is exactly the kind of blind spot that a documented digital strategy should prevent.
A reasonable way forward
1. Classify workloads by business consequence
Between the start of the assessment and the first investment decision, the executive sponsor asks IT, business owners and legal counsel to produce an application register. For each workload, the deliverable identifies its business owner, processed data, outage impact, legal constraints and intended exit route.
The goal is not to label everything “sensitive.” It is to reserve the strongest requirements for systems whose compromise or interruption would materially affect the company.
2. Turn “sovereign” into verifiable evidence
Throughout supplier selection, procurement and IT maintain an evidence matrix covering the exact scope of qualifications, location of data and metadata, operator identity, subcontracting chain, encryption-key control, audit rights and procedures for foreign government requests.
Every sales claim should be backed by a contract, certificate or architecture document. Without evidence, it remains an intention rather than a commitment.
3. Test the exit before signing the entry
Before signature and again during acceptance testing, the architect and application owner perform a representative export and restore it in a separate environment. The deliverable records exported files, non-portable dependencies, reconstruction steps and ownership of each operation.
The test must cover not only application data but also identities, logs, backups, secrets and ERP or CRM integrations.
4. Put operational control into the contract
During negotiation, legal and procurement teams attach a schedule defining data-return deadlines, export formats, deletion of copies, backup handling, subcontractor changes, price revisions and exit assistance.
The contract must also name the internal authority responsible for approving significant changes. Companies without permanent IT leadership can review our article on the role of a part-time CIO.
5. Migrate through reversible waves
From the initial wave through production handover, the project team begins with an application whose interfaces and restoration process can be tested without exposing a critical business operation. The next wave starts only after formal acceptance of security, performance, backup, recovery, monitoring and exit capabilities.
This prevents the organisation from confusing a signed cloud contract with a controlled transformation. Each workload needs a business owner, documented decisions and explicit stop criteria.
Our position at D1 Consulting
We see sovereign cloud as a relevant response to identified risks, not as a mandatory destination for the entire information system. A company retains control when it can prove who administers its data, understand its dependencies and operate its applications elsewhere.
Our IT Project Management service helps organisations structure supplier selection, organise acceptance testing, validate reversibility and manage phased migrations without leaving the decision entirely to the provider. We also identify applications that do not require a costly sovereign target—and those that genuinely need stronger safeguards.
👉 Book your free 30-minute diagnostic to identify critical workloads and define the evidence you should require before signing your next cloud contract.
