European cloud providers, through the association CISPE, have proposed their own sovereignty framework that distinguishes between “sovereign” services (backed by legal guarantees) and “resilient” services (grounded in technical guarantees). This dual-label approach is a direct response to the EU’s Cloud Sovereignty Framework introduced in autumn 2025, which CISPE has sharply criticized for introducing a “score of sovereignty” (“you cannot be 75% sovereign”), containing unattainable objectives like full European control over all hardware, and relying on vague ideas around change-of-control guarantees.

The new framework draws on Gaia‑X Level 3 criteria but splits into two tracks and extends certification beyond Europe. A service hosted in Japan by a Japanese company could, for example, be labelled “sovereign” in Japan and “resilient” in Europe, introducing the concept of a “geographic zone of sovereignty.”

Legal and jurisdictional requirements

To earn the “resilient” label in a zone, the provider must simply be legally established there. The “sovereign” label imposes far stricter conditions: the provider’s registered office, central administration, and main establishment must all lie within the zone; no entity outside the zone may exercise direct or indirect control, individually or collectively; and management/board members must not, by nationality or residence, be subject to extraterritorial obligations that conflict with the framework’s principles. Additionally, no external entity or individual may hold veto rights or the power to appoint a majority of administrative, management, or supervisory body members.

For a “sovereign” service, customer and user data cannot be transferred outside the zone except as expressly authorised by the customer. If compelled by law, disclosure is minimised and the customer informed immediately—unless prohibited. Any change of control that violates the framework triggers a mandatory customer notification, and the service contract must be governed exclusively by the law and courts of a zone country. These requirements cascade to subcontractors, unless they are technically incapable of autonomously processing critical data. Where subcontractors can affect service availability (e.g., colocation providers), the provider must mirror critical workloads and data onto “sovereign-controlled” infrastructure inside the zone, or deploy on a federated, distributed, multi-provider platform.

Operational sovereignty

A “sovereign” service demands that all critical assets, including those managed by subcontractors, reside within the geographic zone. The “resilient” label permits assets outside the zone only with the client’s prior written consent, and an equivalent redundant asset—matching functional, technical, security, and service-level characteristics—must exist inside the zone. On support, “sovereign” means it is technically impossible to access data or operate critical assets from outside the zone; “resilient” allows documented external access with maintained operation lists, client consent, and access controls.

Both labels require compliance with the Data Act (or equivalent local law) and service portability (via open-source or widely used solutions in the zone) or reliance on federated/distributed infrastructure. “Resilient” services must additionally enable clients to perform autonomous backups with third-party tools in formats restorable outside the provider’s environment.

Technological sovereignty

For hardware management, the “sovereign” label requires securing critical components (isolation, validation of updates from non-sovereign suppliers). “Resilient” adds the obligation to define an appropriate stock of key equipment and components, and to notify clients of supply chain disruptions causing unavailability. If these components are designed or manufactured outside the zone, the stock requirement effectively mandates ensuring alternative sourced within the zone.

Software management rules are identical for both labels. Providers must seek commitments—or at least maintenance information—from the editor of any critical asset. Failing that, they must independently guarantee service continuity, including substituting alternative software to maintain minimum functional viability. For any proprietary third‑party software, at least one alternative must be identified, preferably open source. Where none exists (e.g., edge services, WAF, anti‑DDoS, CDN), a solution ensuring minimum functionality must be found, and for SaaS, Data Act compliance must be validated.

Operational autonomy is also uniform: the provider must be able to maintain the entire service itself or through at least two independent third parties, and ensure that critical assets from non‑sovereign entities do not contain kill switches.

Data sovereignty

Regardless of label, personal data processing must follow client instructions and applicable zone legislation. The provider must keep available a list of countries where personal, technical, user, and administrative data is stored and processed; except for administrative data, transfers outside the zone require client consent. Encryption is mandatory in transit and at rest (except for customer data), with keys retained inside the zone and protection against unauthorised access—including by parties involved in network failover infrastructure.

“Resilient” services face a specific transfer rule: data may be sent to a third country if applicable law permits and recognises an equivalent level of protection. In all cases, the client must be given the option to store and process critical data within the geographic zone.

The framework’s development committee includes Anexia, Aruba, Clever Cloud, Deda Cloud, Infomaniak, Jotelulu, Leaseweb, NumSpot, OUTSCALE, OpenNebula, Opiquad, oXya, ReeVo, and WaveCom. Auditing will involve BYCYB, a subsidiary of France’s LNE. CISPE plans to introduce multiple resilience levels in the future.

D’un côté, les services dits « souverains » de par les garanties juridiques qu’ils apportent. De l’autre, ceux qualifiés de « résilients » au titre des garanties techniques.

Cette distinction structure un référentiel made in CISPE*.

Difficile de ne pas y voir une réaction au Cloud Sovereignty Framework, même si l’association représentative des CSP européens ne le présente pas comme telle. Elle a en effet vivement critiqué ce cadre de référence dont l’UE s’est dotée à l’automne 2025 pour évaluer la « souveraineté » des offres cloud dans le cadre de la commande publique.

Le référentiel Gaia-X niveau 3, mais avec deux options

Le Cloud Sovereignty Framework établit 8 « objectifs » (souveraineté stratégique, opérationnelle, technologique, etc.) déclinés en critères. Pour chacun, on peut déterminer un niveau d’assurance, sur 5 échelons.

Bruxelles propose aussi de calculer un « score de souveraineté », éventuellement avec une pondération par objectif.

CISPE a dénoncé ce dernier élément. Un système créant une « moyenne de moyennes » ne favorise pas la transparence, estime l’association, qui considère plus globalement qu’on ne « peut pas être souverain à 75 % ». Elle a par ailleurs déploré la présence d’objectifs « inatteignables » (contrôle européen complet sur tous les composants matériel, par exemple) et d’idées « vagues » (en particulier quant aux garanties sur le changement de contrôle).

L’initiative s’inspire nettement du niveau 3 du référentiel Gaia-X. Elle s’en différencie toutefois par la double approche « souverain »/« résilient ». Tout en ouvrant la porte à une certification au-delà de l’Europe : un service hébergé au Japon par un fournisseur japonais pourrait être à la fois « souverain » sur place et « résilient » en Europe, explique CISPE. Est pour cela introduite la notion de « zone géographique de souveraineté ».

Souveraineté légale et juridictionnelle

Une offre peut prétendre au label « résilient » dans une zone géographique donnée dès lors que son fournisseur y est légalement établi.

Le label « souverain » implique beaucoup plus d’exigences sur ce volet. D’abord sur l’immunité juridictionnelle. Le siège social, l’administration centrale et l’établissement principal du fournisseur doivent être situés dans un pays de la zone. En parallèle, aucune entité située en dehors de la zone ne doit exercer de contrôle direct ou indirect, individuel ou collectif. Quant aux membres de l’équipe dirigeante et du conseil d’administration, ils ne doivent pas, en raison de leur nationalité ou de leur résidence, être sujets à des obligations extraterritoriales en conflit avec les principes énoncés dans le référentiel.

Autre spécificité du label « souverain » : aucune entité localisée hors de la zone, ni aucune personne physique citoyenne ou résidente d’un pays hors zone, ne doit avoir un droit de veto sur le fournisseur. Et pas plus le droit de nommer la majorité des membres des organes d’administration, de gestion ou de supervision.

Une option de mise en miroir des workloads critiques

Les fournisseurs de services « souverains » doivent aussi s’abstenir de transférer des données clients et des données utilisateurs vers des pays ou régions hors de la zone. Ni, plus globalement, vers tout sous-traitant ou destinataires que le client n’a pas expressément autorisé. Si la législation applicable l’impose, le fournisseur doit limiter la divulgation au strict minimum et informer le client sans délai – sauf la loi l’interdit.

La fourniture d’un service « souverain » suppose aussi de notifier le client en cas de prise de contrôle par un tiers qui ne respecte pas les exigences du référentiel. Et de soumettre le contrat de service exclusivement à la loi et à la juridiction d’un pays de la zone.

Toutes ces exigences s’appliquent aussi aux sous-traitants. Sauf s’ils n’ont pas techniquement la capacité de traiter les données critiques de manière autonome. Lorsqu’il leur est possible d’affecter la disponibilité de services (cas des prestataires de colocation, notamment), le fournisseur doit mettre en miroir les workloads et données critiques sur une infrastructure « sous contrôle souverain » dans la zone, ou bien déployer sur une infra « fédérée, distribuée, multifournisseur ».

Souveraineté opérationnelle

Peut être souverain un service dont tous les actifs critiques, y compris ceux qu gèrent des sous-traitants, se trouvent dans la zone géographique concernée.

Le label « résilient » tolère que des actifs se trouvent en dehors de la zone. Mais à condition d’avoir obtenu le consentement écrit préalable du client. Et de disposer, dans la zone, d’au moins un actif redondant équivalent sur les plans fonctionnel, technique, de sécurité et de niveau de service.

Le référentiel opère une distinction similaire pour ce qui est du support. Sur un service « souverain », il est techniquement impossible d’accéder aux données et à l’exploitation des actifs critiques depuis l’extérieur de la zone. Sur un service « résilient », les éventuels accès externes sont documentés, avec maintien à jour de la liste des opérations concernées. Le fournisseur obtient l’accord du client et implémente un contrôle des accès.

Qu’il soit « souverain » ou « résilient », un service doit être conforme au Data Act (ou à une législation locale similaire). Sinon, soit être portable (notamment par l’usage de solutions open source ou largement utilisées au sein de la zone concernée), soit reposer sur une infrastructure fédérée ou distribuée.

Les services « résilients » doivent, en complément, permettre au client de faire ses sauvegardes de manière autonome, avec des outils tiers et dans des formats qu’il peut restaurer hors de l’environnement du fournisseur.

Souveraineté technologique

En matière de gestion du matériel, le label « souverain » impose des mesues pour sécuriser les composants critiques (isolation, validation des mises à jour de fournisseurs non souverains…).

Le label « résilient » les reprend et y ajoute deux éléments. D’une part, définir un stock approprié pour les équipements et composants-clés. De l’autre, notifier le client de toute perturbation de la chaîne d’approvisionnement entraînant l’indisponibilité de ces équipements et composants.

Sur la question du stock, on aura noté que le référentiel impose, pour les équipements et composants conçus et fabriqués en dehors de la zone, d’assurer la disponibilité d’une alternative venant de l’intérieur de la zone…

Sur la gestion du logiciel, pas de différence entre « souverain » et « résilient ». Le fournisseur doit notamment s’efforcer d’obtenir des engagements – ou, au minimum, des informations – de la part de l’éditeur de tout actif critique quant aux conditions de sa maintenance. À défaut, il doit pouvoir assurer indépendamment la continuité du service. Y compris en substituant un autre logiciel afin d’assurer un minimum de viabilité fonctionnelle.

Dans le même esprit, pour tout logiciel tiers propriétaire utilisé ou mis à disposition, le fournisseur doit identifier au moins un logiciel alternatif, open source si possible. À défaut (par exemple pour l’edge et des services cyber comme WAF, anti-DDoS et CDN), il doit identifier une solution permettant un minimum de viabilité foncitonnelle. Tout en validant, pour les SaaS, la conformité avec le Data Act ou toute législation similaire.

Pas non plus de différence entre « souverain » et « résilient » sur le sujet de l’autonomie opérationnelle. Le fournisseur doit pouvoir maintenir l’entièreté de son service par lui-même ou en s’appuyant sur au moins deux sociétés tierces. Et s’assurer que les actifs critiques issus d’entités non souveraines n’incluent pas de kill switches…

Souveraineté des données

Qu’un fournisseur postule au label « souverain » ou « résilient », il ne doit traiter les données personnelles des clients qu’en accord avec leurs instructions et avec la législation applicable dans la zone. Il lui faut aussi tenir à leur disposition une liste des pays où sont stockées et traitées ces données, ainsi que les données techniques, les données utilisateur et les données administratives. Excepté pour ces dernières, il n’y a pas de transfert hors zone sans consentement du client.

Mêmes exigences également entre « souverain » et « résilient » concernant le chiffrement. Excepté les données client, il faut chiffrer en transit et au repos, en conservant les clés dans la zone… et en évitant les accès non autorisés, y compris par les tiers impliqués dans l’infrastructure de failover réseau.

Les services « résilients » ont un régime spécifique sur le transfert des données vers des pays tiers. C’est possible, à condition que la législation applicable l’autorise et reconnaisse que le pays en question assure un niveau équivalent de protection des données. Dans tous les cas, le fournisseur doit donner au client l’option de stocker et traiter ses données critiques dans la zone géographique concernée.

* Le comité qui pilote le développement du framework se compose d’Anexia (Autriche), Aruba (Italie), Clever Cloud (France), Deda Cloud (Italie), Infomaniak (Suisse), Jotelulu (Espagne), Leaseweb (Pays-Bas), NumSpot (France), OUTSCALE (France), OpenNebula (Espagne), Opiquad (Italie), OUTSCALE (France), oXya (France), ReeVo (Italie) et WaveCom (Estonie). BYCYB, filiale du LNE (Laboratoire national de métrologie et d’essais), est dans la boucle pour les audits. CISPE prévoit d’instaurer plusieurs niveaux de résilience.

Illustration générée par IA

The post Les cloud providers européens avancent leur propre référentiel de souveraineté appeared first on Silicon.fr.