Stratégie de sauvegarde NIS 2 au titre de l'article 21(2)(c)
NIS 2 impose de maintenir l'activité pendant et après un incident. L'article 21(2)(c) nomme la gestion des sauvegardes, la reprise après sinistre et la gestion de crise. Le CIR (UE) 2024/2690 §4.2 traduit cela en un plan de sauvegarde documenté, des tests de reprise réguliers et de la redondance.
En bref
La sauvegarde sous NIS 2, ce n'est pas « avons-nous des sauvegardes ». Chaque atelier informatique du Mittelstand a des travaux nocturnes sur bande ou par instantané. La question que posent réellement la directive et le CIR, c'est de savoir si vous avez un plan documenté, avec des temps de reprise, un stockage hors site, des contrôles d'accès, des durées de conservation, et une capacité testée de remettre les systèmes en service.
Le CIR §4.2 comporte six éléments. Un plan de sauvegarde avec six points nommés. Des tests d'intégrité réguliers. La redondance du réseau, des actifs, du personnel et des communications. La surveillance des ressources. Et des tests de reprise réguliers avec résultats documentés. Les six figurent dans une seule section de l'annexe. Aucun n'est facultatif.
L'Allemagne transpose la même règle en droit national par le §30(2)(3) BSIG. Le libellé transpose l'article 21(2)(c) presque mot pour mot. Cette page parcourt la directive, le règlement d'exécution de l'UE qui en découle, et la transposition allemande, dans cet ordre.
Article 21(2)(c) de la directive NIS 2 (2022/2555)
La continuité des activités, telle que la gestion des sauvegardes et la reprise après sinistre, et la gestion de crise.
Il s'agit du point (c) de la liste des dix mesures de cybersécurité que toute entité essentielle et importante doit mettre en place. La gestion des sauvegardes est nommée directement dans le texte de la directive, pas seulement enfouie dans le règlement d'exécution.
CIR (UE) 2024/2690, annexe §4.2
Gestion des sauvegardes, des mesures de protection et de la redondance. Aux fins de l'article 21(2)(c) de la directive (UE) 2022/2555, les entités concernées effectuent des sauvegardes et prévoient des ressources suffisantes, y compris des installations, des réseaux et systèmes d'information et du personnel, afin d'assurer un niveau de redondance approprié.
Parce qu'il s'agit d'un règlement (et non d'une directive), c'est un droit de l'UE directement contraignant. Aucune transposition nationale n'est nécessaire. Le §4.2 comporte six sous-sections numérotées couvrant le plan de sauvegarde, les tests d'intégrité, la redondance, la surveillance des ressources et les tests de reprise. Il s'applique aux fournisseurs de DNS, aux fournisseurs de cloud, aux centres de données, aux MSP, aux services de confiance et aux autres secteurs cités dans l'annexe du CIR.
§30(2)(3) BSIG (Allemagne)
Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement.
L'Allemagne reprend le texte de l'UE mot pour mot. La transposition allemande renvoie aux blocs IT-Grundschutz CON.3 (Datensicherungskonzept) et DER.2.3 (Wiederherstellung) comme voie pratique de mise en œuvre.
Rédiger le plan de sauvegarde en six points
Sur la base de votre évaluation des risques et de votre PCA, consignez par écrit : (a) les temps de reprise, (b) comment vous garantissez que les sauvegardes sont complètes et exactes, y compris les données de configuration et les données stockées dans le cloud, (c) où résident les sauvegardes (en ligne ou hors ligne) sur un ou plusieurs sites sécurisés, pas sur le même réseau que le système primaire, suffisamment éloignées pour qu'un incident sur le site primaire ne les fasse pas tomber, (d) des contrôles d'accès physiques et logiques proportionnés à la classification de l'actif, (e) comment la reprise à partir des sauvegardes s'exécute réellement, (f) les durées de conservation selon les exigences métier et réglementaires.
Tester l'intégrité et la reprise à une cadence
Le §4.2.3 exige des tests d'intégrité réguliers des sauvegardes elles-mêmes. Le §4.2.6 va plus loin : des tests réguliers du processus de reprise effectif. Vérifiez que la reprise est fiable, que toutes les copies et procédures fonctionnent, et que les personnes qui mèneraient la reprise ont encore les connaissances pour le faire. Documentez les résultats. Prenez des mesures correctives lorsqu'un test échoue.
Construire la redondance sur quatre ressources
Sur la base de votre évaluation des risques et de votre PCA, assurez au moins une redondance partielle de : (a) réseaux et systèmes d'information, (b) actifs et valeurs, y compris sites, équipements et consommables, (c) personnel doté de la responsabilité, de l'autorité et de la compétence requises, (d) canaux de communication. La sauvegarde concerne les données. La redondance concerne tout le reste dont vous avez besoin pour continuer à fonctionner.
Sauvegardes et redondance ensemble
Le CIR §4.2 nomme les deux dans le même titre de section : « Gestion des sauvegardes, des mesures de protection et de la redondance ». Les sauvegardes protègent les données pour que vous puissiez reconstruire à partir d'une copie saine connue. La redondance protège les opérations pour que vous ne vous arrêtiez pas en premier lieu. Les deux ont leur place dans le plan. Une équipe qui a des sauvegardes mais pas de redondance récupère les données et ne peut toujours pas fonctionner.
Testées, pas seulement effectuées
Le §4.2.6 exige spécifiquement des tests de reprise réguliers, pas seulement des sauvegardes régulières. Une sauvegarde à partir de laquelle personne n'a restauré n'est pas une capacité de reprise, c'est un espoir. L'auditeur demandera quand vous avez effectué pour la dernière fois une restauration complète, qui l'a menée, ce qui a échoué et ce que vous avez corrigé ensuite. Si la réponse est « à la mise en place, il y a trois ans », vous avez un constat d'audit.
BSI / IT-Grundschutz CON.3 + DER.2.3
L'IT-Grundschutz du BSI comporte deux blocs qui correspondent directement au CIR §4.2. CON.3 « Datensicherungskonzept » couvre le concept de sauvegarde lui-même (ce qui est sauvegardé, à quelle fréquence, où résident les copies, la conservation). DER.2.3 « Notfallwiederherstellung der IT » couvre le volet reprise (procédures, rôles, tests de restauration). Ensemble, ils vous donnent le dossier de preuves du §4.2 dans un langage qu'un auditeur allemand lit tous les jours.
Orientations techniques de mise en œuvre de l'ENISA
Le TIG de l'ENISA prend le texte abstrait du §4.2 et vous montre quoi faire en pratique pour chaque sous-section. Il met aussi en correspondance l'exigence avec l'annexe A.8.13 (sauvegarde des informations) et A.8.14 (redondance des moyens de traitement de l'information) de l'ISO/IEC 27001:2022. Les contrôles ISO 27001 existants vous donnent une longueur d'avance sur les preuves du §4.2.
Lois nationales de transposition
Chaque État membre transpose l'article 21(2)(c) dans sa propre loi (Pays-Bas : Cyberbeveiligingswet, Autriche : NISG, Belgique : NIS2-Wet). Les obligations sont les mêmes parce que la directive fixe une norme unique à l'échelle de l'UE. Ce qui diffère : l'agence nationale dont vous relevez et la manière dont elle mène les inspections.
Nous effectuons des sauvegardes nocturnes, donc nous sommes couverts.
Les sauvegardes nocturnes sont nécessaires, pas suffisantes. Le §4.2.2(c) les veut stockées hors site, pas sur le même réseau que le système primaire, et suffisamment éloignées pour qu'un seul incident ne puisse pas faire tomber les deux. Le §4.2.2(f) veut des durées de conservation documentées, pas « nous les gardons jusqu'à ce que le disque soit plein ». Le §4.2.6 veut une cadence régulière de tests de reprise avec résultats documentés. L'auditeur demandera les trois. « Nous avons des sauvegardes » répond à l'un d'eux.
Nous avons testé la reprise une fois lors de la mise en place du système.
Le §4.2.6 dit des tests réguliers, pas des tests ponctuels. Un test d'il y a trois ans ne prouve pas que le format de sauvegarde d'aujourd'hui, la procédure de restauration d'aujourd'hui et les personnes d'aujourd'hui fonctionnent encore ensemble. Choisissez une cadence (trimestrielle ou semestrielle pour les systèmes critiques, annuelle pour le reste), inscrivez-la dans le plan, exécutez-la, documentez chaque test.
Nous sauvegardons les données ; les configurations, nous pouvons les reconstruire de zéro.
Non. Le §4.2.2(b) exige explicitement que la sauvegarde soit complète et exacte, « y compris les données de configuration, y compris les données stockées dans des environnements d'informatique en nuage ». Une base de données sans la configuration de l'application, les règles de pare-feu et les paramètres du fournisseur d'identité n'est pas un système restaurable, c'est un amas d'enregistrements auxquels vous ne pouvez pas accéder. Le plan doit couvrir les configurations et les données stockées dans le cloud, pas seulement les tables de production.
Ce que nous voyons en pratique : la plupart des Mittelstand ont des sauvegardes. La plupart ont des travaux nocturnes s'exécutant vers un NAS ou un compartiment cloud. Ce qui leur manque généralement, c'est le plan documenté du §4.2.2 avec des temps de reprise par système, l'emplacement nommé du stockage hors site, les contrôles d'accès physiques et logiques par écrit, les durées de conservation par système et par régulateur, et le calendrier des tests de reprise. Le travail de sauvegarde existe ; le plan qui l'entoure n'existe pas.
La correction est modeste. Rédigez le plan en six points du §4.2.2 une fois, validez-le, et inscrivez un test de reprise au calendrier (trimestriel pour les systèmes critiques, semestriel ou annuel pour le reste). Après le premier cycle de tests, vous disposez du dossier de preuves que le règlement réclame. La partie difficile n'est pas la technologie. La partie difficile, c'est d'avoir le plan sur le papier et le test au calendrier.
Le module PCA capture le plan de sauvegarde en six points du §4.2.2, le calendrier des tests de reprise, le registre de redondance pour le réseau, les actifs, le personnel et les communications, et les résultats des tests de reprise avec validation. Un seul module couvre du §4.2.2 au §4.2.6.
Les tests sont des tâches planifiées, pas des rappels en texte libre. Lorsqu'un test de reprise s'exécute, le résultat, les lacunes et les mesures correctives sont saisis par rapport au même enregistrement. La piste d'audit répond alors à « quand avez-vous testé la reprise pour la dernière fois, qu'est-ce qui a échoué, qu'avez-vous fait à ce sujet » en un clic. Pas de journal de tests distinct à tenir.
- Directive (UE) 2022/2555 (NIS 2), article 21(2)(c) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Règlement d'exécution (UE) 2024/2690 de la Commission (CIR), annexe §4.2 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Loi BSI (BSIG), §30(2)(3) tel que modifié par la loi de mise en œuvre de NIS2 et de renforcement de la cybersécurité
- BSI IT-Grundschutz Baustein CON.3 « Datensicherungskonzept » — bsi.bund.de/grundschutz
- BSI IT-Grundschutz Baustein DER.2.3 « Notfallwiederherstellung der IT » — bsi.bund.de/grundschutz
- Orientations techniques de mise en œuvre de l'ENISA pour le CIR (UE) 2024/2690 (état de mai 2026)