BSI KRITIS et le Cloud 2026 : NIS2, loi-cadre et C5 comme triade de conformité

8 Min. temps de lecture Mise à jour : 22.04.2026

La loi de transposition de la directive NIS2 est en vigueur depuis le 6 décembre 2025, le Bundestag a adopté la loi-cadre KRITIS le 29 janvier 2026. Le BSI a publié avec le C5:2026 un catalogue de critères révisé pour le cloud computing sécurisé. Les opérateurs de cloud en Allemagne doivent désormais lire ces trois ensembles de règles de manière conjointe, au lieu de les traiter séparément. Quiconque ne considère pas cette triade comme un tout double les coûts de conformité et crée des structures parallèles que personne ne souhaite entretenir.

L’essentiel en bref

• Trois ensembles de règles simultanés : La loi de transposition de la directive NIS2 (en vigueur depuis le 06.12.2025), la loi-cadre KRITIS (Bundestag, 29.01.2026) et le catalogue BSI C5:2026 s’appliquent en parallèle aux opérateurs de cloud concernés par KRITIS (Gouvernement fédéral sur la transposition de la directive NIS2).
• Portée élargie : Plus de 30 000 entreprises en Allemagne sont désormais soumises à des obligations de sécurité renforcées. Les opérateurs de cloud sont, dans de nombreux cas, concernés à triple titre : en tant qu’établissement important ou particulièrement important, en tant qu’installation KRITIS et en tant que sous-traitant pour des tiers.
• C5:2026 réajusté : Le catalogue révisé du BSI comprend 168 critères répartis en 17 domaines thématiques, avec de nouvelles exigences en matière de gestion des conteneurs, de cryptographie post-quantique et de confidential computing.
• Le multi-cloud est possible, mais pas neutre : AWS, Microsoft Azure et Google Cloud satisfont aux certifications C5, mais le périmètre par service diffère. Quiconque utilise plusieurs hyperscalers doit clarifier, pour chaque charge de travail KRITIS, quel périmètre cloud s’applique.
• Délai serré : Les obligations d’enregistrement et de déclaration liées à NIS2 sont désormais effectives, les premières vérifications du BSI sur la base des nouveaux cadres réglementaires débuteront à l’été 2026.

LiéArchitecture d’inférence IA pour la région DACH en 2026  /  Reshoring dans les PME allemandes

Ce qui s’applique exactement et depuis quand

Qu’entend-on par KRITIS sur le plan réglementaire ? KRITIS désigne les infrastructures critiques dont la défaillance ou l’altération entraînerait des pénuries d’approvisionnement majeures ou des risques pour la sécurité publique. Les secteurs concernés incluent l’énergie, l’eau, l’alimentation, les technologies de l’information et les télécommunications, la santé, le secteur financier et assurantiel, les transports et la circulation, ainsi que l’État et l’administration. Le législateur définit des seuils par secteur, à partir desquels une installation est considérée comme KRITIS et doit assumer les obligations correspondantes.

La loi de transposition de NIS2 a considérablement élargi le cercle des destinataires. Outre les exploitants KRITIS classiques, les établissements particulièrement importants et importants sont désormais soumis à des obligations de sécurité renforcées, ce qui, selon les analyses du BSI et du portail spécialisé OpenKRITIS, concerne environ 30 000 entreprises en Allemagne. Pour les exploitants de cloud, cela est pertinent car, dans de nombreux cas, ils gèrent eux-mêmes des infrastructures informatiques critiques et fournissent également des services à d’autres établissements KRITIS.

La loi-cadre KRITIS, adoptée par le Bundestag le 29 janvier 2026, complète cette approche en intégrant la résilience physique. Alors que NIS2 met l’accent sur la cybersécurité, la loi-cadre vise à protéger contre les risques naturels, les actes de 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 de secours bénéficient désormais d’un cadre réglementaire supplémentaire.

Source : BSI Bundesamt für Sicherheit in der Informationstechnik, OpenKRITIS, état avril 2026.

Les nouveautés du C5:2026

Le catalogue de critères C5 du BSI est, depuis 2016, le 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 intègre trois nouveaux thèmes, absents ou seulement évoqués en marge dans les versions précédentes. Premièrement, la gestion des conteneurs : les exigences en matière de sécurité d’exécution (runtime security), de scan d’images et de politiques réseau sont étendues et formulées de manière plus explicite. Deuxièmement, la cryptographie post-quantique : les exploitants de cloud doivent présenter un plan de migration documenté pour les données sensibles à longue durée de protection. Troisièmement, le confidential computing : pour les charges de travail nécessitant un haut niveau de protection, l’utilisation d’environnements d’exécution de confiance matériels, tels que les Trusted Execution Environments, est désormais intégrée au catalogue de critères.

Pour les exploitants de cloud concernés par les enjeux KRITIS, le C5 n’est plus une certification facultative, mais un standard industriel de fait. Les prestataires de santé doivent déjà, depuis juillet 2024, présenter une attestation C5 sur la base de la loi numérique (Digital-Gesetz), et d’autres secteurs réglementés suivent dans la pratique. L’audit est réalisé par des commissaires aux comptes, qui certifient la conformité aux critères après vérification.

En pratique, cela signifie pour les équipes cloud DACH : ceux qui utilisent des attestations C5 pour répondre aux exigences clients doivent intégrer les nouveaux thèmes de 2026 dans leur cycle d’audit. Ceux qui vérifient les attestations de leurs fournisseurs doivent prêter attention à la version utilisée – 2026 ou une version antérieure. Les périodes de transition sont définies 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, par service et par 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. Quiconque exploite un système de gestion des patients en Allemagne doit disposer d’une attestation C5 pour l’ensemble de la chaîne. Si la base de données et l’application tournent sur AWS Frankfurt, que la couche analytique repose sur Azure Germany-West-Central et que certains volumes de sauvegarde transitent par Google Cloud Europe-West3, les attestations doivent être disponibles par service. Si l’une manque, l’ensemble de la charge de travail sort de la conformité C5, jusqu’à ce que le prestataire comble la lacune ou que le sous-système soit migré.

Parallèlement, la loi-cadre KRITIS s’applique au niveau des sites. Quiconque fait fonctionner son environnement de production principal dans un centre de données francfortois avec une classification de site connue, et son plan de reprise d’activité (DR) en Irlande, doit intégrer le site 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) génère une matrice qui doit être élaborée individuellement pour chaque charge de travail KRITIS.

Comparaison des trois référentiels

Le plan de mise en œuvre pragmatique

Pour les opérateurs cloud concernés par les infrastructures critiques (KRITIS), un plan en cinq étapes a fait ses preuves dans la pratique, traitant les trois cadres réglementaires comme des lots de travail interdépendants. Première étape : l’inventaire. Quels workloads fonctionnent où, quelle est leur classification, quels fournisseurs sont impliqués ? Sans cet inventaire, toute étape ultérieure relève du pilotage à l’aveugle.

Deuxième étape : le classement des destinataires. Votre organisation relève-t-elle des KRITIS, d’une entité importante ou particulièrement importante au sens de NIS2, et où s’applique en plus la loi-cadre KRITIS ? Ce classement détermine la profondeur des obligations, le rythme de reporting et les modalités d’enregistrement.

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

Quatrième étape : l’harmonisation des politiques. Vos directives internes en matière de protection des accès, de réaction aux incidents, de classification des données et de sauvegarde doivent être alignées sur les exigences des trois cadres réglementaires. Dans de nombreuses organisations, des politiques historiques régissent plusieurs sujets en parallèle et présentent des incohérences. Un sprint d’harmonisation permet de clarifier cela et d’économiser un temps considérable lors des audits ultérieurs.

Cinquième étape : le rythme des audits. Si vous utilisez des attestations C5, planifiez le cycle de contrôle avec votre commissaire aux comptes. Si vous êtes soumis au reporting NIS2, clarifiez le rythme avec le BSI. Si vous répondez aux obligations de la loi-cadre KRITIS, planifiez des exercices de résilience. Gérer trois cycles en parallèle dans un planning annuel est logistiquement exigeant, mais maîtrisable si une équipe GRC en assure la coordination.

Ce qui dérape régulièrement dans la pratique

Deux erreurs se répètent dans la pratique du conseil. La première est l’organisation parallèle. Une équipe travaille sur NIS2, une autre sur C5, une troisième sur la loi-cadre KRITIS. Personne ne voit les chevauchements. Résultat : des listes d’actifs entretenues en triple exemplaire, 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 ces 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 aux fournisseurs. Un opérateur cloud qui base son attestation sur un service d’un hyperscaler utilisant une pré-attestation se retrouve, en cas de problème, sans confirmation à jour si l’hyperscaler modifie le périmètre du service. De telles modifications surviennent plus fréquemment que les entreprises ne l’anticipent, car les catalogues cloud évoluent dynamiquement. Un droit contractuel de notification des changements auprès du fournisseur est donc devenu la norme, mais n’est pas encore généralisé.

Une troisième question est souvent sous-estimée : quels indicateurs internes reflètent la conformité. Une conformité des processus sans métriques est un sujet d’audit lors du prochain cycle. 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 des attestations par charge de travail et du nombre de constats ouverts, peut s’adresser au conseil de surveillance et au BSI. Sans ces chiffres, la conformité reste narrative.

Une quatrième lacune apparaît dans la documentation des chaînes de signalement. NIS2 exige une alerte précoce dans les 24 heures, une déclaration d’exportation dans les 72 heures et un rapport final dans un délai d’un mois. La loi-cadre KRITIS complète les voies de signalement pour les événements physiques. Celui qui n’a pas testé les chemins d’escalade perd, en cas d’urgence, des heures en coordination, alors qu’il en aurait besoin pour l’analyse et la maîtrise de la situation. Un exercice semestriel sur table avec les services juridique et communication fait donc partie intégrante d’une organisation de conformité mature, et n’est pas un simple accessoire 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 des polices, les assureurs demandent aujourd’hui, lors de l’entretien d’audit, la version de l’attestation C5, le classement NIS2 et les temps de réponse documentés en cas d’incident. Celui qui ne dispose pas de ces documents à portée de main risque des majorations de primes ou des réductions de prestations en cas de sinistre.

Conclusion

La loi de transposition de NIS2, la loi-cadre KRITIS et le BSI C5:2026 ne forment pas une trilogie à cocher, mais un cadre réglementaire intégré pour les opérateurs cloud concernés par KRITIS. Celui qui traite ces trois cadres comme un ensemble réduit à la fois les efforts et les risques. Celui qui les aborde séparément crée des structures parallèles qui s’effondreront lors de l’audit. Le calendrier de mise en œuvre d’ici l’automne est serré, mais réalisable si l’inventaire, la matrice des fournisseurs et l’harmonisation des politiques commencent dès maintenant. La différence entre un opérateur cloud bien préparé et un autre mal préparé sera visible au quatrième trimestre 2026, lorsque les premiers cycles complets de contrôle seront en cours.

Questions fréquentes

Chaque start-up cloud doit-elle désormais mettre en œuvre la triade de conformité ?

Non, les seuils d’application de la transposition NIS2 et du règlement KRITIS délimitent le périmètre des destinataires selon la taille, le secteur et les valeurs seuils. Pour les prestataires de petite taille sans lien avec KRITIS, seules les obligations générales de sécurité informatique issues du RGPD et du droit des télécommunications restent applicables. La triade devient pertinente à partir du statut d’entité importante, d’entité hautement importante ou d’installation KRITIS.

Quels secteurs sont particulièrement touchés ?

La santé, le secteur financier, l’énergie, les transports et l’administration publique sont au cœur des obligations renforcées. Les opérateurs cloud qui fournissent des services à ces secteurs se retrouvent fréquemment dans le champ d’application de manière indirecte, car leurs clients exigent des attestations et des preuves que l’opérateur ne peut fournir qu’en mettant lui-même en œuvre la triade.

L’attestation C5 de l’hyperscaler suffit-elle pour assurer sa propre conformité ?

Non. L’attestation C5 de l’hyperscaler couvre l’infrastructure de base, non l’application propre, la classification des données ou les processus internes. Les opérateurs cloud ont généralement besoin d’une attestation combinée qui intègre leurs propres services et les composants cloud utilisés.

Quel est le lien entre la loi-cadre KRITIS et NIS2 ?

NIS2 traite de la cybersécurité, la loi-cadre de la résilience physique. Dans la mise en œuvre pratique, la gestion des incidents, l’analyse des risques et les obligations de notification se recoupent. Quiconque conçoit un processus répondant simultanément aux deux référentiels économise des doublons et réduit le risque de notifications contradictoires.

Que signifie la cryptographie post-quantique dans le contexte C5 ?

C5:2026 exige un plan de migration documenté pour les données sensibles à longue durée de vie. Cela ne signifie pas que tous les algorithmes actuellement utilisés doivent être remplacés immédiatement. Cela signifie que les opérateurs cloud doivent présenter un plan indiquant comment ils migrent vers des procédés résistants aux quanta approuvés par le NIST, quelles données sont prioritaires et quels délais de transition s’appliquent.

Plus du réseau MBF Media

• La faille Vercel comme cas de chaîne d’approvisionnement OAuth sur SecurityToday
• Check-list de mise en production GenAI pour les DSI sur Digital Chiefs
• EU Digital Omnibus en trilogue sur MyBusinessFuture

Source image de couverture : Pexels / Brett Sayles (px:5480781)