Siège du BSI à Bonn : point de distribution pour C5 et les conditions-cadres KRITIS. Photo : Eckhard Henkel / Wikimedia Commons

8 min de lecture

BSI-KRITIS, NIS2 et C5 ne seront plus alignés en 2026, mais superposés. Celui qui intègre des services cloud dans une infrastructure critique doit gérer les trois cadres de référence simultanément, sans que l’architecture ne devienne une routine de conformité sans effet. Ce contrôle pratique montre auxquels points les cadres de référence entrent réellement en collision et comment un ensemble multi-cloud peut résister à l’examen.

Résumé : la conformité se joue dans l’interaction entre la sélection des services, la configuration des locataires, les preuves et l’organisation des notifications. Le fournisseur ne fournit qu’une seule pièce du puzzle.

Les points clés en bref

• Le cercle des établissements réglementés s’élargit : avec la mise en œuvre de la NIS2 dans la loi NIS2UmsuCG et la loi-cadre KRITIS, de nombreuses entreprises sont soumises à des obligations de cybersécurité et de résilience. Toute organisation ne deviendra pas un opérateur KRITIS au sens strict, mais les obligations NIS2/BSIG et les chaînes de preuves KRITIS s’appliqueront plus largement qu’auparavant.
• C5 est un cadre de preuve, et non un point final : le dossier de testat couvre le fournisseur. La configuration des locataires, la gestion des clés, le contrôle d’accès et la journalisation doivent être prouvables séparément par l’opérateur.
• Le multi-cloud génère plusieurs chemins d’audit par charge de travail : le testat du fournisseur, les preuves des locataires, les preuves de la chaîne d’approvisionnement et les sous-traitants se trouvent dans des mondes séparés sans couche centrale de preuves. L’effort d’audit augmente considérablement.

LiéBYOD dans l’entreprise allemande 2026  /  SAP Sovereign Cloud France

Ce qui est vraiment nouveau en 2026

Qu’est-ce que la conformité BSI-KRITIS lors de l’utilisation du cloud ? Il s’agit de l’obligation pour les exploitants d’infrastructures critiques de prouver chaque service cloud utilisé en production : classe de données, emplacement, certificat de fournisseur (typiquement BSI C5 Type 2), preuve de configuration propre dans le locataire, chaîne de déclaration d’incident documentée, y compris une alerte précoce de 24 heures conformément à la NIS2. Les certificats de fournisseur globaux ne sont plus suffisants depuis 2026.

La discussion autour de KRITIS et du cloud dure depuis des années, mais 2026 marque un tournant. Avec la deuxième ordonnance modifiant l’ordonnance BSI-KRITIS, les seuils sont fixés plus bas dans plusieurs secteurs. Parallèlement, le projet de loi sur le KRITIS-Dachgesetz relie pour la première fois la résilience physique et numérique. En outre, la mise en œuvre de la NIS2 dans la loi NIS2UmsuCG élargit considérablement le cercle des parties obligées. Ceux qui étaient jusqu’à présent juste en dessous du seuil KRITIS sont maintenant inclus ou très proches.

Il est important de noter que pour les configurations cloud, la NIS2/BSIG est le levier de cybersécurité le plus direct. La loi KRITIS-Dachgesetz augmente également la pression de résilience et de preuve sur les exploitants d’installations critiques, mais doit être en partie concrétisée par des règlements. Ceux qui séparent les régimes planifient de manière plus précise.

L’effet sur les stratégies cloud n’est pas subtil. Chaque service cloud utilisé en production doit être prouvé individuellement : catégorie, classe de données, emplacement, certificat de fournisseur, preuve de configuration. Ce qui il y a trois ans passait pour un certificat global « nous avons C5 » sera décomposé lors d’un audit KRITIS en 2026. Les auditeurs attendent une granularité de niveau de service, et non une image globale des hyperscaleurs.

Le C5 reste un cadre de preuve important pour les fournisseurs de cloud. Mais pour les exploitants, il ne constitue qu’un élément : la configuration du locataire, le contrôle d’accès, la gestion des clés et la journalisation doivent être prouvables séparément. La séparation a longtemps été minimisée et retombe maintenant sur l’exploitant lors de l’audit.

Les trois cadres de référence et où ils se croisent

Celui qui traite KRITIS, NIS2 et C5 comme des pistes séparées crée trois univers d’audit parallèles. C’est coûteux et inutile. Dans la pratique, les exigences se chevauchent pour environ deux tiers. Il est essentiel de comprendre les 30 % restants, sinon il y aura des constats.

Le conflit le plus important dans la pratique : NIS2 exige un avertissement précoce de 24 heures en cas d’incidents déclarables. Les directives de secteur KRITIS sont parfois plus étroites, parfois plus larges. C5 oblige le fournisseur à informer ses clients. L’escalade vers le BSI doit être effectuée par le client lui-même. Celui qui n’a pas établi l’interface reçoit une notification d’incident du fournisseur de cloud et ne peut pas la traiter de manière organisationnelle.

Précision importante sur le délai : l’horloge de 24 heures commence dès que l’organisme responsable prend connaissance d’un incident de sécurité important et doit déclencher la procédure de déclaration. Les alertes des fournisseurs ne sont qu’un déclencheur possible, pas le seul. Celui qui n’a pas établi la voie de déclaration et d’escalade interne brûle une grande partie des 24 heures avec des clarifications organisationnelles.

Deuxième conflit : la sécurité des fournisseurs. NIS2 met l’accent sur la protection de la chaîne d’approvisionnement. La réalité du multi-cloud signifie que chaque fournisseur de cloud et chaque fournisseur de SaaS de niveau 2 fait partie de cette chaîne. C5 ne couvre que le premier fournisseur de cloud, pas ses sous-traitants. Celui qui exploite un SaaS sur le fournisseur de cloud X a deux niveaux de fournisseurs avec des obligations de preuve différentes.

Du framework au setup : quatre semaines, un chemin

La démarche suivante est condensée à partir de projets de conformité dans les fournisseurs de services, l’industrie proche des infrastructures critiques (KRITIS) et les assureurs. Le calendrier est adapté pour un setup multi-cloud existant avec deux ou trois hyperscalers et une poignée d’outils SaaS avec accès aux données client.

La pression ressentie pour traiter tout en parallèle est compréhensible, mais inefficace. Sans inventaire propre, chaque outil de posture est superflu. Sans détermination des besoins de protection, personne ne sait quelle évidence de configuration est vraiment critique. Cette séquence est la plus fiable dans la pratique.

Celui qui exploite déjà une plate-forme cloud centrale pour l’inventaire et la détection de dérive peut raccourcir la semaine 3. Celui qui pense encore en termes de listes Excel par domaine fonctionnel devrait prolonger la semaine 1 et ne pas l’abréger. Un inventaire incomplet ressortira lors de l’audit KRITIS à la page un. Alors commence la course aux corrections sous pression.

Ce qui résiste, ce qui casse : le multi-cloud sous examen

Dans le conflit entre l’idéalisme architectural et la réalité de l’audit, c’est le setup qui décide s’il survivra aux tests. Les modèles suivants ont souvent conduit à des constats dans les deux dernières années – ou pas.

Il est frappant de constater que cela échoue souvent non pas à cause de la technique, mais à cause de l’organisation. Les architectures cloud sont techniquement propres dans la plupart des opérateurs KRITIS. Ce qui manque, ce sont des interfaces documentées entre la sécurité informatique, la conformité et le département technique. Celui qui ne joue pas même une fois par trimestre son chemin de déclaration ne le connaît pas en fait.

Le deuxième obstacle fréquent est le niveau d’ombre SaaS. Les outils de marketing, les systèmes RH, les plateformes juridiques – tous atterrissent tôt ou tard dans la proximité KRITIS, car ils traitent des données d’installations critiques ou détiennent des identités de personnel d’exploitation. Celui qui a un trou dans l’inventaire a un trou dans l’audit.

Décisions d’architecture avec levier de conformité

Trois briques d’architecture ont un impact disproportionné. Elles ne sont pas nouvelles, mais en 2026, elles ne sont plus une option.

Tout d’abord : la fédération d’identités avec un système d’audit central. Celui qui utilise l’hyperscaleur X, Y et trois fournisseurs de logiciels en tant que service (SaaS) avec des piles d’identités séparées a cinq journaux d’audit. Celui qui utilise un fournisseur d’identités central avec une fédération cohérente n’en a qu’un. L’effort d’audit ne diminue pas de manière linéaire, mais de manière disproportionnée, car la forensique des incidents suit un seul chemin.

Deuxièmement : les clés gérées par le client, au moins pour les classes de données « élevées » et « très élevées ». Les clés gérées par le fournisseur sont pratiques et suffisent pour les données « normales ». Pour les classes de données KRITIS, la discussion sur la maîtrise des clés est l’une que l’audit lit et évalue. Une infrastructure de clés propre, qu’il s’agisse d’un gestionnaire de clés externe ou d’une connexion dédiée à un module de sécurité matériel (HSM), rapporte des points dans le rapport d’audit et offre une marge de manœuvre en cas d’incident.

Troisièmement : les preuves de configuration comme citoyen de première classe. Les attestations des fournisseurs sont des déclarations ponctuelles. Un cloud productif change tous les jours. Celui qui n’a pas de détecteur de dérive qui signale les écarts de configuration par rapport à un état souhaité ne peut pas prouver, entre les points de contrôle, que les contrôles sont efficaces. La question des auditeurs « quand avez-vous su cela » ne peut être répondue qu’avec une entrée de journal, et non avec une supposition.

Un certificat C5 dans un dossier ne remplace pas la traçabilité de l’audit dans le locataire. C’est la leçon tirée de chaque rapport d’audit KRITIS sérieux des deux dernières années.

Chaînes d’approvisionnement et nœud des sous-traitants

Le NIS2 a sorti la sécurité de la chaîne d’approvisionnement de l’annexe. Pour les configurations cloud multiples, cela signifie : chaque sous-traitant devient visible. L’hyperscaleur X utilise le sous-traitant A pour la journalisation, le sous-traitant B pour l’intelligence des menaces, le sous-traitant C pour la maintenance matérielle. Cette liste doit être fournie, elle doit être mise à jour. Ses modifications doivent être signalées contractuellement.

Dans un environnement cloud multiple, cela se multiplie. Trois hyperscaleurs avec chacun douze à vingt sous-traitants donnent environ cinquante entrées de chaîne d’approvisionnement. Sans un registre de sous-traitance central qui maintient cette liste et enregistre les modifications avec date, la question NIS2 sur la gestion des risques de la chaîne d’approvisionnement ne peut pas être répondue.

Étape pratique : registre de sous-traitance sous forme de fichier CSV ou de tableau de base de données, comparé mensuellement avec les listes de sous-traitants des fournisseurs. Avis de modification dans le contrat, responsabilité de l’examen désignée. Cela ressemble à la bureaucratie, mais c’est la condition préalable à un audit NIS2 sans constatations évidentes.

Ce que les auditeurs veulent vraiment voir en 2026

À partir de discussions avec les auditeurs, sans que les détails de chaque rapport d’audit soient publics, un modèle se dégage. Trois domaines recevront en 2026 une attention disproportionnée.

Le premier domaine est l’exhaustivité de l’inventaire. Celui qui n’inventorie pas les services cloud par service, mais par fournisseur, se fait immédiatement remarquer. Les auditeurs demandent une annexe, examinent la liste de services et la comparent avec la télémétrie du réseau. Si des outils SaaS apparaissent dans la liste qui ne sont pas dans l’inventaire, c’est une constatation directe.

Le deuxième domaine est l’efficacité de la chaîne de déclaration d’incident. Le NIS2 exige une alerte précoce de 24 heures. Les auditeurs ne demandent pas le processus, mais la dernière simulation. Une simulation trimestrielle avec une règle de remplacement et une communication de secours suffit généralement.

Le troisième domaine est la cohérence de la maîtrise des clés et des identités sur tous les locataires cloud. C’est ici que la complexité du cloud multiple se fait pleinement sentir. Une vue unique sur les clés tournantes et les événements d’identité critiques des 90 derniers jours est l’exigence minimale. Si elle manque, un problème d’audit se pose.

Foire aux questions

Photo : Eckhard Henkel / Wikimedia Commons (CC BY-SA 3.0 DE)

Source de l’image : générée par IA (mai 2026), certificat C2PA intégré à l’image