Panne d'un fournisseur de cloud au sens de NIS 2
La panne de votre fournisseur est le test de votre plan de continuité, pas une exemption de celui-ci.
Ce qu'est cette page
Un grand fournisseur de cloud tombe en panne. La production s'arrête. La question dans la pièce est de savoir si les obligations NIS 2 incombent au fournisseur ou à votre entité. La réponse de la directive est que les deux niveaux portent leurs propres obligations et que l'un ne décharge pas l'autre. Vos obligations au titre de l'article 21(2)(c) de NIS 2 de maintenir la continuité d'activité, les sauvegardes et la reprise, et au titre de l'article 23 de déclarer les incidents importants, s'appliquent à votre entité quoi que fasse votre fournisseur sur sa propre horloge.
Cette page est écrite pour un responsable informatique ou un dirigeant dans une entreprise de 50 à 250 personnes qui fait tourner la majeure partie de sa production sur un hyperscaler ou un cloud régional. Ce n'est pas un conseil juridique. C'est la mécanique de la clause qui s'applique à qui lorsque la page d'état du fournisseur passe au rouge.
La phrase la plus utile : une panne de cloud est le test en conditions réelles de votre plan de reprise de l'article 21(2)(c). Si le plan fonctionne, aucun incident important ne s'est produit chez votre entité. Si le plan ne fonctionne pas, l'article 23 commence à courir sur votre horloge, pas sur celle du fournisseur.
Directive (UE) 2022/2555 (NIS 2)
Article 21(2)(c) : politiques et procédures relatives à la continuité des activités, telles que la gestion des sauvegardes et la reprise après sinistre, et la gestion des crises. Article 21(2)(d) : sécurité de la chaîne d'approvisionnement, y compris les aspects liés à la sécurité concernant les relations entre chaque entité et ses fournisseurs directs ou prestataires de services directs.
L'article 21(2)(c) place l'obligation de continuité, de sauvegarde et de reprise sur l'entité. La directive ne permet pas que cette obligation soit déléguée à un fournisseur de cloud par un contrat. L'article 21(2)(d) est le volet risque fournisseur : vous êtes tenu d'évaluer et de gérer la sécurité de vos fournisseurs directs, ce qui inclut des clauses contractuelles de notification pour les pannes et les incidents chez le fournisseur. L'article 23 fixe ensuite la cascade de déclaration avec l'alerte précoce de 24 heures, la notification d'incident de 72 heures, une mise à jour intermédiaire sur demande, et un rapport final dans un délai d'un mois.
Règlement d'exécution (UE) 2024/2690 de la Commission
Article 23(3) de NIS 2 : Un incident est considéré comme important s'il a causé ou est susceptible de causer une perturbation opérationnelle grave des services ou des pertes financières pour l'entité concernée, ou s'il a affecté ou est susceptible d'affecter d'autres personnes physiques ou morales en causant un dommage matériel ou immatériel considérable.
Le CIR quantifie ce qui compte comme important pour les 11 catégories d'infrastructure numérique et de services numériques qu'il couvre, ce qui inclut les fournisseurs de services d'informatique en nuage au titre de l'Annexe I secteur 8 de NIS 2. La section 11 de l'annexe du CIR énumère les scénarios qui constituent un incident important à ce niveau du fournisseur. Pour les entités hors du champ du CIR, le test d'importance de l'article 23(3) est celui qui s'applique, et une panne en cascade qui arrête la production y satisfait presque toujours.
BSIG (Allemagne)
§30 BSIG : mesures techniques et organisationnelles appropriées au risque. §32 BSIG : notification des incidents importants au BSI via le Meldeportal à bsi.bund.de. §31 BSIG : obligations de sécurité de la chaîne d'approvisionnement pour l'entité.
Le BSIG est l'exemple de transposition allemand. Les Pays-Bas (Cyberbeveiligingswet) et l'Autriche (NISG 2024) ont les leurs. La cascade 24 / 72 heures / intermédiaire / un mois est de niveau directive et identique dans tous les États membres. Un fournisseur de cloud qui est lui-même une entité NIS 2 dans l'UE a sa propre obligation de déclaration au titre du §32 BSIG ou de l'équivalent national. Cette obligation n'éteint pas la vôtre.
Évaluez au regard de votre plan de l'article 21(2)(c)
Ouvrez le plan de continuité d'activité et de reprise après sinistre et exécutez-le. La question n'est pas de savoir si le fournisseur est en panne. La question est de savoir si vos services peuvent continuer à fonctionner dans le cadre du plan que vous avez rédigé. Basculez vers une région secondaire, passez à un flux de travail hors ligne documenté, ou restaurez à partir d'une sauvegarde détenue en dehors du fournisseur affecté. L'article 21(2)(c) de NIS 2 place l'obligation de continuité sur votre entité. Si la panne révèle qu'il n'y avait pas de plan, c'est cela le premier constat, pas la panne.
Déclenchez votre processus fournisseur de l'article 21(2)(d)
L'article 21(2)(d) de NIS 2 exige que vous gériez la sécurité de vos fournisseurs directs. En pratique, cela signifie trois choses lors d'une panne : ouvrir le contrat et lire les clauses de notification et de SLA, consigner la référence d'incident du fournisseur et tout calendrier qu'il publie, et capturer les preuves dans votre piste d'audit. Si le contrat n'exige pas la notification par le fournisseur des incidents qui vous affectent, c'est cela le deuxième constat, distinct de la panne elle-même.
Déclarez si votre entité a un incident important
Le test de l'article 23(3) est appliqué à votre entité, pas au fournisseur. Si la panne cause une perturbation opérationnelle grave de vos services, des pertes financières pour vous, ou un dommage considérable à d'autres qui dépendent de vous, alors l'article 23 de NIS 2 commence à courir sur votre horloge. Alerte précoce au CSIRT national ou à l'autorité compétente dans les 24 heures suivant la prise de connaissance, notification d'incident dans les 72 heures, rapport intermédiaire sur demande, rapport final dans un délai d'un mois. En Allemagne, cela passe par le Meldeportal du BSI au titre du §32 BSIG. La déclaration propre du fournisseur au titre de son propre statut NIS 2 est distincte et ne dépose pas pour vous.
La continuité est l'obligation de l'entité, pas du fournisseur
L'article 21(2)(c) de NIS 2 place l'obligation de continuité, de sauvegarde et de reprise sur l'entité. Un contrat avec un hyperscaler promettant une cible de disponibilité de 99,99 pour cent n'est pas un plan de continuité au sens de la directive. Le plan doit décrire ce que fait votre entité lorsque le fournisseur est indisponible. L'auditeur l'an prochain teste si un tel plan existe et s'il a été exercé, pas si le SLA a été honoré.
Les sauvegardes doivent être restaurables, pas seulement présentes
La position du BSI est que l'existence d'une sauvegarde n'est pas le test. La restaurabilité dans les conditions d'un incident réel l'est. Une sauvegarde détenue dans la même région cloud que le système de production, contre le même fournisseur d'identité, n'est pas une sauvegarde au sens de l'article 21(2)(c) lorsque c'est la région ou la couche d'identité qui défaille. L'obligation de sauvegarde restaurable exige une séparation à travers le domaine de défaillance que vous cherchez à survivre.
Meldeportal du BSI (Allemagne), CSIRT national (autres États membres)
Si la panne cause un incident important chez votre entité au titre de l'article 23(3), la déclaration passe par votre canal national. En Allemagne, c'est le Meldeportal du BSI au titre du §32 BSIG. Aux Pays-Bas, le National Cyber Security Centre, en Autriche le GovCERT. La déclaration vous incombe même si la cause racine se situe chez le fournisseur. La page d'état d'un fournisseur n'est pas un dépôt.
Le fournisseur de cloud en tant qu'entité NIS 2, Annexe I secteur 8
Un fournisseur de services d'informatique en nuage établi dans l'UE est une entité essentielle ou importante au titre de l'Annexe I secteur 8 de NIS 2 (infrastructure numérique). Il doit sa propre déclaration au titre de l'article 23 sur sa propre horloge à sa propre autorité compétente ou CSIRT. Le CIR 2024/2690 précise les seuils d'importance pour les fournisseurs d'infrastructure numérique. La déclaration du fournisseur n'est pas la vôtre. Un fournisseur hors de l'UE est hors du champ de la directive, auquel cas la gestion du risque fournisseur de l'article 21(2)(d) est votre seul levier sur lui.
L'ENISA et le réseau des CSIRT
Les pannes transfrontalières des grands fournisseurs de cloud sont coordonnées par le réseau des CSIRT coordonné par l'ENISA au titre de l'article 15 de NIS 2. L'ENISA publie une connaissance de la situation à travers les États membres. Pour une entité individuelle, ceci est un matériel de référence plutôt qu'un canal de déclaration. Le canal de déclaration est national. L'ENISA est l'endroit où vous lisez ce qui se passe au niveau de l'UE lorsque le fournisseur est en panne dans plusieurs pays.
Le cloud est le problème du fournisseur. NIS 2 lui incombe.
L'article 21(2)(c) de NIS 2 place l'obligation de continuité, de sauvegarde et de reprise sur votre entité. L'article 21(2)(d) place l'obligation de risque fournisseur sur votre entité. Le fournisseur a ses propres obligations au titre de la directive s'il est un fournisseur de cloud établi dans l'UE au titre de l'Annexe I secteur 8, mais ces obligations courent en parallèle des vôtres et ne les déchargent pas. L'audit l'an prochain teste votre plan, pas le SLA du fournisseur.
Attendre le rapport SLA post-incident du fournisseur avant de déposer ou de revoir.
L'article 23(4) de NIS 2 exige l'alerte précoce dans les 24 heures suivant la prise de connaissance d'un incident important chez votre entité. Le rapport du fournisseur peut prendre des semaines. Si la panne a causé une perturbation opérationnelle grave chez votre entité, l'horloge de 24 heures court contre vous, que le fournisseur ait publié quelque chose ou non. Attendre le rapport SLA est la raison la plus fréquente pour laquelle les entités manquent l'échéance dans les cas de panne de cloud.
Le fournisseur est revenu, tout fonctionne de nouveau, l'incident est clos.
L'article 21(2)(c) de NIS 2 attend que le plan de continuité et de reprise soit exercé et amélioré. Une panne de cloud est un exercice en conditions réelles de ce plan, et la revue post-incident est ce qui alimente l'itération suivante. L'auditeur demandera ce qui a changé dans le plan de reprise après la dernière panne. Si rien n'a changé et que la même lacune subsiste, c'est un constat. Un retour aux opérations normales n'est pas un incident clos au sens de la directive.
Une entreprise de logistique de 110 personnes en Rhénanie-du-Nord-Westphalie, classée comme wichtige Einrichtung au titre de NIS 2 parce que le secteur et l'effectif la placent dans le champ d'application. Mardi 09h14 : la région UE centrale de l'hyperscaler se dégrade et le système de gestion des transports, le fournisseur d'identité et le stockage de fichiers partagé de l'entreprise deviennent tous inaccessibles. 09h20 : le responsable informatique ouvre le plan de continuité, bascule la répartition vers le flux de travail hors ligne documenté sur des ordinateurs portables locaux, et informe le dirigeant. 09h35 : organe de direction informé, décision consignée dans la piste d'audit de traiter ceci comme un événement de continuité au titre de l'article 21(2)(c) et de surveiller au regard du test d'importance de l'article 23(3). La page d'état du fournisseur est capturée en copie d'écran et jointe à l'enregistrement de l'incident.
11h50 : la panne dure depuis plus de deux heures et affecte désormais les engagements de livraison clients. Le test de l'article 23(3) est réévalué : la perturbation opérationnelle grave des services est satisfaite. L'alerte précoce de 24 heures est déposée via le Meldeportal du BSI au titre du §32 BSIG en citant la référence d'incident du fournisseur et l'impact propre de l'entreprise. 14h30 : le fournisseur rétablit la région. L'entreprise mène la revue post-incident le lendemain matin. Constat : le fournisseur d'identité secondaire existait sur le papier mais n'avait jamais été exercé, de sorte que le basculement a pris 40 minutes de plus que ce que le plan supposait. Deux changements écrits entrent dans le plan : exercice mensuel du fournisseur d'identité secondaire, et un avenant contractuel avec le fournisseur de cloud pour exiger la notification des incidents régionaux dans les 30 minutes. Le rapport intermédiaire et le rapport final à un mois au titre de l'article 23 sont déposés à partir de la piste d'audit, pas de mémoire.
La plateforme stocke les quatre choses écrites dont vous avez besoin avant la prochaine panne de fournisseur : le plan de continuité lié à l'article 21(2)(c), la configuration de sauvegarde restaurable avec la preuve de sa séparation du domaine de défaillance primaire, le registre des fournisseurs avec les clauses de notification et de SLA liées à l'article 21(2)(d), et les modèles de déclaration et la liste de contacts pour la cascade de l'article 23. Chaque changement et chaque exercice est capturé dans la piste d'audit avec horodatage, de sorte que l'auditeur l'an prochain voit un plan qui a réellement été exécuté, pas un document qui a été rédigé une fois.
La plateforme est gratuite et open source. Il n'y a pas de palier payant ni de lock-in. Le but de cette page n'est pas de vendre quoi que ce soit. C'est de s'assurer que lorsque la page d'état du fournisseur passe au rouge, votre organe de direction sait si l'horloge de la directive tourne sur vous et quelle est la prochaine étape écrite.
- Directive (UE) 2022/2555 (NIS 2) : article 21(2)(c) (continuité d'activité, sauvegarde, reprise, gestion des crises), article 21(2)(d) (sécurité de la chaîne d'approvisionnement), article 23 (cascade de déclaration) et article 23(3) (test d'importance). Annexe I secteur 8 (infrastructure numérique, y compris les fournisseurs de services d'informatique en nuage). EUR-Lex.
- Règlement d'exécution (UE) 2024/2690 de la Commission : exigences techniques et méthodologiques et seuils d'importance pour les fournisseurs d'infrastructure numérique et de services numériques, y compris les fournisseurs de cloud. Annexe section 11. EUR-Lex.
- BSIG (Allemagne) : §30 (mesures de gestion des risques), §31 (sécurité de la chaîne d'approvisionnement), §32 (Meldeportal du BSI). Gesetze im Internet.
- BSI : paquets d'information NIS 2 sur la continuité, les sauvegardes restaurables et la position selon laquelle l'existence d'une sauvegarde n'est pas le test. bsi.bund.de.
- ENISA : coordination du réseau des CSIRT au titre de l'article 15 de NIS 2 pour les incidents transfrontaliers. enisa.europa.eu.