BSI KRITIS et le Cloud 2026 : NIS2, loi-cadre et C5

La loi allemande de transposition de NIS2 est en vigueur depuis le 6 décembre 2025, et le Bundestag a adopté la loi-cadre KRITIS le 29 janvier 2026. Avec C5:2026, le BSI a publié un catalogue de critères révisé pour un cloud computing sécurisé. Les opérateurs cloud en Allemagne doivent désormais lire ces trois cadres réglementaires ensemble, au lieu de les traiter séparément. Ceux qui ne pensent pas cette triade comme un tout doublent leurs coûts de conformité et mettent en place des structures parallèles que personne ne voudra maintenir.

L’essentiel en bref

Articles liésArchitecture d’inférence IA pour la région DACH 2026  /  Relocalisation dans les PME

Ce qui s’applique exactement, et depuis quand

Qu’est-ce que KRITIS au sens réglementaire ? KRITIS désigne les infrastructures critiques dont la défaillance ou l’altération entraînerait d’importants goulets d’étranglement dans l’approvisionnement ou des menaces pour la sécurité publique. Les secteurs concernés comprennent l’énergie, l’eau, l’alimentation, l’informatique et les télécommunications, la santé, la finance et l’assurance, le transport et la circulation ainsi que l’État et l’administration. Le législateur définit, pour chaque secteur, des seuils à partir desquels une installation est considérée comme KRITIS et doit assumer les obligations correspondantes.

La loi de transposition de NIS2 a nettement élargi le cercle des destinataires. Outre les exploitants KRITIS classiques, les entités particulièrement importantes et importantes relèvent désormais elles aussi d’obligations de sécurité élargies, ce qui, selon les analyses du BSI et du portail spécialisé OpenKRITIS, concerne environ 30.000 entreprises en Allemagne. Pour les opérateurs cloud, c’est pertinent, car, dans de nombreux cas, ils exploitent leur propre infrastructure informatique comme infrastructure critique tout en fournissant des services à d’autres entités KRITIS.

La loi-cadre KRITIS, adoptée par le Bundestag le 29 janvier 2026, complète cette approche par l’angle de la résilience physique. Alors que NIS2 met l’accent sur la cybersécurité, la loi-cadre vise la protection contre les risques naturels, le sabotage et les menaces hybrides. Pour les exploitants de centres de données, c’est un signal clair : la sécurité des sites, le contrôle d’accès et l’alimentation électrique de secours bénéficient d’un cadre réglementaire supplémentaire.

Source : BSI, Office fédéral allemand de la sécurité des technologies de l’information, OpenKRITIS, situation en avril 2026.

Ce qui change avec C5:2026

Depuis 2016, le catalogue de critères C5 du BSI sert de cadre de référence pour le cloud computing sécurisé en Allemagne. La version révisée C5:2026 restructure les domaines d’audit et ajoute trois thèmes qui étaient absents des versions précédentes ou n’y figuraient qu’en marge. Premièrement, la gestion des conteneurs : les exigences en matière de sécurité à l’exécution, de scan d’images et de politiques réseau ont été étendues et formulées plus explicitement. Deuxièmement, la cryptographie post-quantique : les opérateurs cloud doivent présenter une trajectoire de migration documentée pour les données sensibles à protéger sur le long terme. Troisièmement, le Confidential Computing : pour les charges de travail à classe de protection élevée, l’utilisation d’environnements de confiance assistés par matériel, tels que les Trusted Execution Environments, est intégrée au catalogue de critères.

Pour les opérateurs cloud concernés par KRITIS, C5 n’est plus une attestation volontaire, mais un standard industriel de fait. Depuis juillet 2024, les prestataires de santé doivent déjà présenter une attestation C5 sur la base de la loi numérique ; d’autres secteurs réglementés suivent dans la pratique. L’audit est réalisé par des commissaires aux comptes, qui certifient le respect des critères à l’issue d’un contrôle réussi.

En pratique, cela signifie pour les équipes cloud de la région DACH : celles qui utilisent des attestations C5 pour répondre aux exigences de leurs clients doivent intégrer les nouveaux thèmes de 2026 dans leur propre cycle d’audit. Celles qui examinent les attestations de leurs fournisseurs doivent vérifier précisément si elles reposent sur la version 2026 ou encore sur l’ancienne version. Les délais de transition sont définis dans le catalogue et varient selon les thèmes.

Ce que signifie le multi-cloud dans ce cadre

Les trois hyperscalers AWS, Microsoft Azure et Google Cloud disposent tous d’attestations C5 pour des services essentiels, mais pas de manière exhaustive. Chaque fournisseur définit, pour chaque service et chaque région, quels certificats s’appliquent et lesquels ne s’appliquent pas. Pour une charge de travail KRITIS répartie sur plusieurs hyperscalers, la comparaison des périmètres n’est donc pas une simple formalité.

Un exemple concret. Toute organisation qui exploite en Allemagne un système de gestion des patients a besoin d’une attestation C5 pour l’ensemble de la chaîne. Si la base de données et l’application fonctionnent sur AWS Francfort, que la couche d’analyse tourne sur Azure Germany-West-Central et que certains volumes de sauvegarde sont transférés via Google Cloud Europe-West3, les attestations doivent être disponibles pour chaque service. S’il en manque une, toute la charge de travail sort de la conformité C5 jusqu’à ce que le fournisseur ait comblé la lacune ou que le sous-système ait été déplacé.

En parallèle, la loi-cadre KRITIS s’applique au niveau des sites. Toute organisation qui exploite son environnement principal de production dans un centre de données à Francfort avec une classification de site connue et son dispositif de reprise après sinistre en Irlande doit intégrer le site de DR dans l’analyse de résilience, même s’il n’est pas utilisé en priorité. La combinaison des obligations NIS2 (cybersécurité), de la loi-cadre KRITIS (résilience physique) et des critères C5 (audit spécifique au cloud) forme une matrice qui doit être élaborée individuellement pour chaque charge de travail KRITIS.

Comparaison des trois cadres réglementaires

Le plan de mise en oeuvre pragmatique

Pour les opérateurs cloud concernés par les KRITIS, un plan en cinq étapes a fait ses preuves dans la pratique, en traitant les trois cadres réglementaires comme des lots de travail liés entre eux. Premièrement, l’inventaire. Quelles charges de travail fonctionnent où, quelle est leur classification, quels fournisseurs sont impliqués. Sans cet inventaire, toute étape ultérieure se fait à l’aveugle.

Deuxièmement, la classification des entités concernées. L’organisation relève-t-elle de NIS2 en tant que KRITIS, entité importante ou entité particulièrement importante, et où la loi-cadre KRITIS s’applique-t-elle en plus. Cette classification détermine l’étendue des obligations, le rythme du reporting et les modalités d’enregistrement.

Troisièmement, la matrice fournisseurs. Quel service cloud dispose de quelle attestation C5, dans quelle version, avec quel périmètre. Dans la pratique, c’est à ce stade que la plupart des projets finissent dans un tableau Excel, qui doit ensuite être mis à jour à chaque nouveau lancement de service. Des outils GRC spécialisés prennent en charge cette étape de travail, mais ils ne sont pas gratuits.

Quatrièmement, l’harmonisation des politiques. Les directives internes relatives à la protection des accès, à la réaction aux incidents, à la classification des données et aux sauvegardes doivent être comparées aux exigences des trois cadres. Dans de nombreuses organisations, il existe des directives héritées de l’histoire, qui couvrent plusieurs sujets en parallèle et présentent des incohérences aux marges. Un sprint d’harmonisation clarifie ces points et fait gagner un temps de discussion considérable lors des audits ultérieurs.

Cinquièmement, le rythme des audits. Ceux qui utilisent des attestations C5 planifient le cycle de contrôle avec l’auditeur financier. Ceux qui appliquent le reporting NIS2 clarifient le rythme avec le BSI. Ceux qui répondent aux obligations de la loi-cadre KRITIS planifient des exercices de résilience. Maintenir trois cycles en parallèle dans une planification annuelle est exigeant sur le plan logistique, mais maîtrisable si une équipe GRC dispose de l’autorité sur le calendrier.

Ce qui tourne régulièrement mal dans la pratique

Deux erreurs se répètent dans la pratique du conseil. La première est l’organisation en parallèle. Une équipe s’occupe de NIS2, une autre de C5, une troisième de la loi-cadre KRITIS. Personne ne voit les chevauchements. Résultat: des listes d’actifs tenues trois fois, des processus d’incident contradictoires et une facture de conformité inutilement élevée. Selon des analyses internes de grands exploitants de centres de données, ceux qui planifient les trois sujets ensemble dès le départ économisent entre 20 et 40 pour cent des efforts.

La deuxième erreur concerne la dépendance vis-à-vis des fournisseurs. Un opérateur cloud qui fonde son attestation sur un service de l’hyperscaler utilisant une attestation préalable se retrouve, en cas de problème sérieux, sans confirmation à jour si l’hyperscaler modifie le périmètre du service. De tels changements surviennent plus souvent que les entreprises ne s’y attendent, car les catalogues cloud se développent de manière dynamique. Un droit contractuel de notification des changements auprès du fournisseur est donc devenu un standard, mais il n’a pas encore été intégré partout.

Une troisième question est souvent sous-estimée: quels KPI internes attestent de la conformité. Une conformité des processus sans métriques devient un sujet d’audit lors du cycle suivant. Celui qui dispose, dans une structure de tableau de bord commune, du temps de réaction aux incidents, du délai entre la disponibilité d’un correctif et son déploiement, de la couverture d’attestation par workload et du nombre de constats ouverts peut dialoguer avec le conseil de surveillance et le BSI. Sans ces chiffres, la conformité reste narrative.

Une quatrième lacune apparaît dans la documentation des chaînes de notification. NIS2 exige une alerte précoce dans les 24 heures, une notification complète dans les 72 heures et un rapport final dans un délai d’un mois. La loi-cadre KRITIS ajoute des voies de notification pour les événements physiques. Ceux qui n’ont pas exercé les chemins d’escalade perdent, en cas de crise, des heures en coordination alors qu’ils en ont besoin pour l’analyse et le confinement. Un exercice de simulation semestriel avec les services juridique et communication fait donc partie intégrante d’une organisation de conformité mature, et n’est pas seulement un élément optionnel.

Un cinquième aspect concerne l’interface avec l’assureur. Les conditions des polices cyber se sont sensiblement durcies au cours des 18 derniers mois. Lors de la négociation de la police et de l’entretien d’audit, les assureurs demandent aujourd’hui la version de l’attestation C5, la classification NIS2 et les temps de réponse aux incidents documentés. Celui qui n’a pas ces documents à portée de main risque des majorations de prime ou des réductions de prestations en cas de sinistre.

Conclusion

La loi de transposition de NIS2, la loi-cadre KRITIS et BSI C5:2026 ne sont pas une trilogie à cocher, mais un cadre réglementaire intégré pour les opérateurs cloud ayant une pertinence KRITIS. Ceux qui traitent les trois cadres comme une unité réduisent à la fois l’effort et le risque. Ceux qui les gèrent séparément construisent des structures parallèles qui s’effondrent lors de l’audit. La feuille de route de mise en œuvre jusqu’à l’automne est serrée, mais réalisable si l’inventaire, la matrice fournisseurs et l’harmonisation des politiques démarrent maintenant. La différence entre un opérateur cloud bien préparé et un opérateur mal préparé deviendra visible au T4 2026, lorsque les premiers cycles d’audit complets seront en cours.

Questions fréquentes

Source de l’image de titre : Pexels / Brett Sayles (px:5480781)

Traduit de l’original allemand par intelligence artificielle. La version allemande fait foi.