Germany’s Federal Office for Information Security (BSI) has published a new reference document, C3A (Criteria enabling Cloud Computing Autonomy), transposing the European Commission’s Cloud Sovereignty Framework into concrete national criteria. The framework, designed to assess cloud services for public procurement, defines eight sovereignty objectives, each rated across five assurance levels to produce a weighted sovereignty score. The BSI’s C3A omits security/compliance (already covered by the domestic C5 standard) and environmental factors, and focuses on extending the remaining six dimensions. Critically, the criteria are not monolithic: contracting authorities select them “à la carte” according to use-case, with some flagged as “additional” for higher assurance.

One headline technical requirement underpins technological sovereignty: the cloud provider must maintain, within the EU, a backup of the full source code (including build scripts and deployment toolchains) that is at most 24 hours old and preserves at least five versions. This backup must come with documentation enabling continued independent development, ensuring operation without external dependencies. Contingency strategies are mandatory for disconnection from third-party software or services, with optional criteria demanding local teams and environments to compile, test, and deploy security patches autonomously. Access to maintenance environments must be restricted to authorised personnel with corresponding contingency procedures.

On strategic sovereignty, the BSI introduces a dual EU/Germany lens for jurisdiction, registered office (including subcontractors), and effective control, defined as direct or indirect influence over key strategic, financial, or operational decisions. Providers must notify customers at least 90 days in advance of events that could affect C3A controls—such as ownership or governance changes.

Legal sovereignty requires that once a year, the CSP identify any extraterritorial law directly relating to its services that could impact cross-border availability, confidentiality, or data integrity. A unique clause activates if an EU member state (or Germany alone) declares a “state of defence” (a distinct legal status under German law): the state must be able, within legal bounds, to take over cloud operations, with the provider supplying portable documentation, source code, and administration tools.

Data sovereignty differentiates customer data, account data, and derived data. Storage and processing locality can be restricted to the EU or exclusively to Germany for customer data, while other data only has an EU option. External encryption key management is expected for IaaS and PaaS (or functionally equivalent mechanisms); for SaaS it should be offered if technically feasible. The CSP must support integration of third-party identity providers, with optional upgrades such as open standards, stateless authentication (no customer accounts in the CSP directory), and dynamic authorisation attributes. Customer data encryption keys must be available exclusively outside the CSP’s environment. Logging all access to customer data is mandatory, with granular filtering and real-time API-based stream access as additional enhancements.

Operational sovereignty splits personnel requirements: an EU-wide criterion demands both citizenship and residency within the Union, while a Germany-restricted version requires only residency. This covers anyone with logical or physical infrastructure access, support staff, and management. Administrative access from outside the EU (or Germany, depending on the chosen scope) must be technically restricted. Redundant connectivity must guarantee SLA continuity, with at least one alternative provider based in the EU (optionally outside the CSP’s corporate group). The Security Operations Centre must be located in the EU or Germany, with an autonomous equivalent available if disconnected. CSPs must be able to sever all extra-EU network connections—including heartbeats and licence servers—without disrupting services, test this process, remain independent of non-EU entities, and have a procedure to install updates during up to 90 days of isolation. All data exchanges with third parties must be documented by type and flow, and updates validated in a secured CSP-controlled network zone.

Supply-chain sovereignty mandates identification of all software components and their countries of origin, a process to mitigate dependencies through architectural flexibility, and a list of relevant suppliers available on request. The same rigour applies to hardware and external service dependencies, with explicit risk management for export restrictions and supply-chain disruptions.

C3A thus provides a granular, operationally focused blueprint for cloud sovereignty, blending EU-wide and nationally specific requirements, and equipping public buyers to demand verifiable independence from non-European influence across the entire service stack.

La « souveraineté technologique » d’un service cloud implique que le fournisseur conserve, dans l’UE, une sauvegarde du code source ayant au maximum 24 heures et contenant au minimum 5 versions.

Le BSI (homologue allemand de notre ANSSI) a inscrit cette exigence dans son référentiel C3A (Criteria enabling Cloud Computing Autonomy). À travers lui, elle décline le Cloud Sovereignty Framework de la Commission européenne. Cette dernière s’est dotée, avec ce document, d’un cadre de référence pour évaluer la souveraineté des offres cloud dans le cadre de la commande publique.

Le Cloud Sovereignty Framework fournit une grille de lecture articulée en 8 objectifs. Sur chacun, on peut déterminer un niveau d’assurance, entre 5 échelons (de « pas de souveraineté » à « souveraineté numérique complète »). Et calculer un « score de souveraineté », avec une pondération par objectif.

Avec la pondération qu’elle propose, l’UE a essuyé des critiques. Le BSI n’aborde pas cet aspect. Elle se concentre sur la déclinaison des critères du Cloud Sovereignty Framework, non sans en étendre certains. Deux objectifs sont cependant écartés : sécurité/conformité (déjà couverts par des publications telles que C5, « le SecNumCloud allemand ») et environnement (pas dans le champ de responsabilité de l’agence).

Les critères pour évaluer les offres sont à choisir « à la carte », selon les cas d’usage. Certains sont dits « additionnels » : ils rehaussent des exigences ou élargissent leur périmètre.

Souveraineté stratégique

Que ce soit sur la juridiction, sur l’implantation du siège social ou sur le contrôle effectif, le BSI introduit un double prisme UE-Allemagne. À choisir à la carte, donc.

Quant au critère d’implantation du siège social, l’agence précise qu’il concerne aussi les éventuels sous-traitants. Elle ajoute que le « contrôle effectif » s’entend comme la possibilité d’exercer une influence directe ou indirecte sur les décisions stratégiques, financières ou opérationnelles clés.

Autre critère à évaluer : l’information des clients au moins 90 jours à l’avance en cas d’événements susceptibles d’affecter les contrôles C3A associés à un service (changement de propriétaire, d’actionnariat, de gouvernance…).

Souveraineté légale et juridictionnelle

Le C3A comprend un critère selon lequel un CSP doit, au moins une fois par an, identifier toute loi extraterritoriale touchant directement (« relating directly ») ses services et ayant des implications transfrontalières sur leur disponibilité, ainsi que sur la confidentialité et l’intégrité des données client.

Le BSI a aussi établi un critère relatif à l’état de défense – que la législation allemande distingue des états de tension, d’urgence interne et de catastrophe. Si un État membre de l’UE – ou seulement l’Allemagne, là aussi au choix – déclare cet état de défense, il doit pouvoir, dans la limite des possibilités légales, prendre la main sur l’exploitation du cloud, avec les actifs physiques et le personnel nécessaires.

Cela signifie que le CSP dispose de la documentation, du code source et des outils d’administration dans un format portable, précise le référentiel.

Souveraineté des données

Le C3A distingue les données client, celles relatives à leurs comptes et celles dites « dérivées » (résultant de l’interaction avec les services cloud). Pour les données client, deux critères de localisation du stockage et du traitement sont proposés : UE ou Allemagne. Pour les autres données, le référentiel ne propose que l’option UE.

Concernant la gestion externe des clés de chiffrement, il est attendu que le CSP la propose pour IaaS et PaaS. Ou qu’il fournisse des mécanismes fonctionnemment équivalents. L’option est plus rare pour le SaaS, reconnaît le BSI ; mais elle devrait être proposée si c’est « techniquement faisable et approprié », ajoute-t-il.

Autre élément attendu : permettre d’intégrer des fournisseurs d’identités tiers. En critères additionnels, il y a notamment :

Implémenter cette intégration avec des standards ouverts

Gérer un modèle d’authentification sans état dispensant de stocker les comptes dans l’annuaire du CSP

Autorisation contrôlable via des déclarations et des attributs dynamiques émis directement par le fournisseur d’identités

Il y a aussi un critère de supervision : permettre d’enregistrer, de conserver et de consulter les journaux d’accès aux données client. Et, éventuellement (critères additionnels), de permettre un filtrage granulaire et de fournir un accès en temps réel aux flux de données via des API standardisées.

Le C3A y ajoute un critère de chiffrement des données client, avec une clé disponible exclusivement en dehors de l’environnement du CSP.

Souveraineté opérationnelle

Double prisme géographique également pour le personnel d’exploitation. Un des critères impose que les personnes concernées soient à la fois citoyennes et résidentes de pays de l’UE. Celui restreint au périmètre allemand ne concerne que la résidence (pas d’obligation de citoyenneté).

Le personnel en question inclut quiconque a un accès logique ou physique à l’infrastructure d’exploitation. Il comprend aussi le support client et tous les individus qui assument un rôle de gestion du CSP.

Le C3A opère une autre distinction géographique, sur l’aspect télétravail. Il impose, d’un côté, que les accès administratifs aux systèmes exploités pour opérer les services soient restreints à l’UE. De l’autre, que les accès effectués en dehors de l’UE… ou de l’Allemagne fassent, de manière générale, l’objet de restrictions techniques.

Connectivité : au moins un fournisseur alternatif basé dans l’UE

Le référentiel comporte un critère de connectivité redondante. En cas de perturbation d’un fournisseur, le basculement vers les autres doit permettre de maintenir les SLA. Au moins un de ces fournisseurs alternatifs doit se trouver dans l’UE. Et, éventuellement (critère additionnel), ne pas faire partie de la structure corporate du CSP.

Même logique de redondance pour le SOC. Celui-ci devra, au choix, se trouver dans l’UE ou en Allemagne. En cas de déconnexion, le CSP devra pouvoir fournir un SOC autonome équivalent, lui aussi situé dans l’UE ou en Allemagne.

Le C3A comporte aussi un critère relatif aux mises à jour et aux données opérationnelles. Elles doivent être réceptionnées et validées dans une zone réseau sécurisée que le CSP contrôle. Il lui appartient par ailleurs de vérifier la présence de vulnérabilités dans les mises à jour. Éventuellement, il pourra implémenter la zone réseau sur des systèmes physiques dédiés.

Toujours sur la souveraineté opérationnelle, le C3A établit la nécessité de superviser tout échange de données entre le CSP et des tiers. Cela doit se traduire par la documentation des types de données concernées et des flux.

Les CSP doivent aussi pouvoir couper toutes les connexions avec des réseaux situés hors de l’UE, sans perturber la disponibilité, l’intégrité, l’authenticité et la confidentialité de leurs services. Cela inclut les « battements de cœur » et les serveurs de licences, nous précise-t-on.

Les CSP devront tester leur processus d’exécution de la déconnexion et s’assurer qu’il est indépendant d’entités non européennes. Ils devront être en mesure de rétablir la connexion. Et avoir un processus d’installation des mises à jour si l’environnement a été déconnecté pour un maximum de 90 jours.

Souveraineté de la supply chain

Pour chaque service, on attend du CSP qu’il identifie les composants logiciels et leurs pays d’origine. Et qu’ils fournissent aux clients, sur demande, une « liste des fournisseurs pertinents ». Tout en ayant un processus pour identifier et atténuer les dépendances ; entre autres en maintenant une « flexibilité architecturale » favorisant les substitutions.

On retrouve cette logique pour les dépendances matérielles et les dépendances à des services externes. Le C3A y ajoute le besoin d’un processus d’identification et d’atténuation des risques liés aux restrictions à l’export et aux perturbations de la supply chain.

Souveraineté technologique

Les exigences de sauvegarde du code source sus-évoquées doivent permettre une exploitation sans dépendances externes. Cela inclut les scripts de build et les toolchains de déploiement. Le backup doit s’assortir d’une documentation permettant de poursuivre le développement de ce code.

Le C3A établit aussi comme critère l’existence de stratégies de contingence en cas de déconnexion de tierces parties : fournisseurs de logiciels alternatifs, capacités internes de remédiation, contrôles de sécurité compensatoires… On pourra éventuellement exiger (critère additionnel) que le CSP ait ses équipes et environnements locaux pour compiler, tester et déployer indépendamment des correctifs de sécurité. Dans tous les cas (critère principal), on s’assurera que seul du personnel autorisé a accès aux environnements nécessaires à la maintenance des services. Et qu’il existe là aussi des procédures de contingence.

Illustration générée par IA

The post En Allemagne, une certaine idée de la « souveraineté » du cloud appeared first on Silicon.fr.