The essentials
A digital sovereignty decision must state what the organisation is trying to protect: confidentiality, availability, decision-making autonomy, legal control, continuity or the ability to change provider.
1. Classify the services and the data
Start with the business impact of an outage, a disclosure, a modification or an inability to migrate. This classification avoids applying the maximum level of requirement to the whole estate while under-protecting the assets that are genuinely critical.
2. Examine five axes of control
- Technical control: identities, keys, administration, logs and update chains.
- Legal exposure: contracting entities, subcontractors, applicable law and extraterritorial access.
- Dependency: formats, proprietary APIs, skills and exit costs.
- Operations: support, continuity, capacity, incident handling and evidence.
- Governance: decisions, exceptions, duration and re-evaluation.
3. Choose a combination, not a camp
Public cloud, qualified cloud, private hosting, in-house infrastructure and SaaS services can coexist. The right model separates components by criticality and makes the flows, the dependencies and the compensating controls explicit.
A service hosted in France can remain dependent on a foreign administration chain, software, capital or jurisdictions. Conversely, some low-sensitivity workloads can accept that exposure if exit and continuity are under control.
4. Contract for reversibility before entry
Export formats, frequency, volume, assistance, ownership of configurations, lead times, cost and an exit test must be negotiated before the migration. A clause without a rehearsal or exportable data is not a reversibility capability.
5. Produce a traceable decision
The expected deliverable connects classification, scenarios, weighted criteria, residual risks, total cost and trajectory. It also explains the exceptions and the review date, so that sovereignty remains a governed choice rather than a marketing statement.