Aller au contenu principal
Retour à l'aperçu

NIS2 Article 21(2)(c) : ce qu'exigent vraiment la sauvegarde et la continuité

Par NIS2Certify
nis2continuite-activitesauvegardereprise-apres-sinistrearticle-21cir-2024-2690
NIS2 Article 21(2)(c) : ce qu'exigent vraiment la sauvegarde et la continuité

Un groupe de rançongiciel chiffre l'environnement de production d'un client un vendredi soir. Le lundi, le client veut savoir deux choses : quand serons-nous de retour, et pouvons-nous prouver au régulateur que nous avons tout fait correctement ? Si votre plan de continuité d'activité réside dans un dossier SharePoint que personne n'a ouvert depuis 2023, vous connaissez déjà la réponse aux deux questions.

L'article 21(2)(c) de NIS2 est la mesure que la plupart des organisations pensent avoir maîtrisée et que les auditeurs jugent le plus souvent insuffisante. « La continuité des activités, par exemple la gestion des sauvegardes et la reprise après sinistre, et la gestion des crises » ressemble à une case que l'on coche avec un plan de reprise existant. Ce n'en est pas une. Le règlement d'exécution (UE) 2024/2690 de la Commission a transformé cette seule sous-disposition en plus de vingt exigences spécifiques et justifiables — et à partir du cycle d'audit de juin 2026, ce règlement est l'étalon que les auditeurs utilisent en premier.

Voici ce que vos clients doivent réellement produire, et où se trouvent généralement les lacunes.

Le règlement d'exécution est la norme à laquelle les auditeurs mesurent

NIS2 lui-même est délibérément vague. Il énumère dix mesures à l'article 21(2) et laisse le détail aux États membres et à la Commission. Pour un ensemble défini d'entités — fournisseurs DNS, registres de noms de domaine de premier niveau, fournisseurs de cloud et de centres de données, fournisseurs de services gérés et autres infrastructures numériques — la Commission a comblé ce détail directement avec le CIR 2024/2690, applicable depuis le 18 octobre 2024.

Pour tous les autres, le règlement n'est pas juridiquement contraignant. Mais c'est la lecture la plus concrète de l'article 21 qui existe, les autorités nationales alignent leurs listes de contrôle d'audit dessus, et l'ENISA a publié des orientations techniques de mise en œuvre fondées sur la même structure. Traitez-le comme l'étalon de fait. Si un client satisfait au CIR 2024/2690 en matière de continuité d'activité, aucun auditeur de l'UE ne soutiendra qu'il a manqué à l'article 21(2)(c).

Le règlement décompose la mesure en trois éléments qui doivent exister indépendamment : un plan de continuité d'activité et de reprise après sinistre, la gestion des sauvegardes, et la gestion des crises. La plupart des organisations en ont un sur trois et supposent qu'il couvre les autres. Ce n'est pas le cas.

Article 21 — 10 Mesures de Cybersécurité NIS2

Article 21

10 Mesures de Cybersécurité

Gouvernance & Stratégie

1Analyse des risques & politiques de sécurité de l'information
6Évaluation de l'efficacité des mesures de sécurité

Incidents & Continuité

2Gestion des incidents & notification
3Continuité des activités & reprise après sinistre

Chaîne d'approvisionnement & Systèmes

4Sécurité de la chaîne d'approvisionnement
5Sécurité dans le développement des systèmes d'information

Contrôles Techniques

8Cryptographie & chiffrement
10Authentification multifacteur & communications sécurisées

Personnel & Actifs

7Cyber-hygiène & formation
9Sécurité RH & contrôle d'accès

Un plan de continuité sans analyse d'impact est une supposition

La première exigence est un plan documenté de continuité et de reprise — mais le plan doit découler d'une analyse d'impact sur l'activité (BIA), et non de l'intuition de l'équipe informatique sur ce qui compte.

Dans la BIA, vous identifiez les services critiques et les systèmes qui les sous-tendent, puis attribuez à chacun une durée d'indisponibilité maximale tolérable. Vous en déduisez un objectif de temps de reprise (RTO, à quelle vitesse vous restaurez) et un objectif de point de reprise (RPO, combien de données vous pouvez perdre). Ces deux chiffres pilotent chaque décision en aval : la fréquence des sauvegardes, leur lieu de stockage, la conception du basculement.

Voici la lacune que les auditeurs trouvent constamment. Le client a noté des valeurs RTO et RPO — quatre heures, quinze minutes, peu importe — mais le calendrier de sauvegarde et la conception de reprise ne les délivrent pas. Un RPO de quinze minutes avec des sauvegardes nocturnes n'est pas un objectif, c'est une fiction. Le règlement attend que les objectifs et l'architecture concordent, et exige que vous prouviez cette concordance par un résultat de test, pas par une affirmation.

Pour les consultants, la BIA est aussi le travail à plus fort effet de levier que vous puissiez vendre. Elle est indépendante des référentiels, elle alimente ISO 27001 et DORA en même temps, et presque aucun client PME n'en a réalisé une correctement.

Les sauvegardes doivent être isolées, immuables et prouvées restaurables

La gestion des sauvegardes selon le CIR 2024/2690 est le point où la réalité des rançongiciels rencontre la conformité. Trois choses ne sont pas négociables.

Les sauvegardes doivent être séparées de la production. Une sauvegarde sur le même domaine, accessible avec les mêmes identifiants, est chiffrée en même temps que tout le reste. Le règlement attend une séparation logique et idéalement physique.

Les sauvegardes doivent être protégées contre la modification — immuabilité ou contrôles équivalents, afin qu'un attaquant disposant de droits d'administrateur ne puisse pas supprimer ou écraser les points de restauration. C'est le plus grand changement d'architecture que la plupart des clients doivent encore opérer.

Et les sauvegardes doivent être testées en les restaurant réellement. Une tâche de sauvegarde qui signale « succès » chaque nuit vous indique que l'écriture a fonctionné. Elle ne dit rien sur la capacité des données à se restaurer dans un système opérationnel dans le respect de votre RTO. L'annexe 4.3 du règlement exige spécifiquement des tests de restauration avec résultats documentés et actions correctives.

L'appel à l'action s'écrit de lui-même pour tout MSP : la posture de sauvegarde de vos clients est la partie de NIS2 la plus rapide à évaluer et la plus facile à améliorer de manière démontrable. Notre scan rapide NIS2 gratuit vous donne une base de départ défendable pour exactement cette conversation.

La gestion de crise est une équipe nommée et une chaîne de décision répétée, pas un répertoire téléphonique

Le troisième pilier est celui que les organisations oublient jusqu'à ce qu'elles en aient besoin. La gestion de crise selon NIS2 signifie une structure de direction définie avec des rôles clairs, un pouvoir décisionnel et des procédures de communication qui fonctionnent sous pression.

Concrètement, cela signifie une équipe de crise nommée, des seuils d'escalade documentés, des modèles de communication pré-rédigés (y compris pour les régulateurs et les clients), et la connaissance de qui peut autoriser quoi lorsque les systèmes sont en panne et que les approbateurs habituels sont injoignables. Le règlement traite les modèles de communication de crise comme un élément de preuve spécifique — les auditeurs les demanderont.

Cela se rattache directement à l'horloge de notification de NIS2. Le plan de crise est ce qui réunit les bonnes personnes assez vite pour respecter les délais de 24 heures (alerte précoce) et de 72 heures (notification) au titre de l'article 23. Une sauvegarde qui se restaure en quatre heures ne vaut rien si personne n'a décidé de déclarer un incident pendant les trois premiers jours.

Calendrier de Notification des Incidents NIS2

24h

Alerte Précoce

Notifiez l'autorité compétente (CSIRT/ANC) dans les 24 heures suivant la prise de connaissance d'un incident significatif.

72h

Notification d'Incident

Soumettez une notification détaillée dans les 72 heures avec une première évaluation de la gravité, de l'impact et des indicateurs de compromission.

1mo

Rapport Final

Remettez un rapport final complet dans un délai d'un mois couvrant l'analyse des causes, les mesures prises et l'impact transfrontalier.

Ce que « preuve » signifie dans un audit en 2026

Le changement qui prend les organisations au dépourvu dans ce cycle d'audit est de nature probatoire. Les auditeurs ne se contentent plus de l'existence d'un plan. Ils veulent voir qu'il a été testé, que le test a révélé des problèmes et que ces problèmes ont été corrigés.

Pour chaque test de restauration, le règlement attend une sortie documentée : la date et les participants, le scénario utilisé, les problèmes identifiés avec niveaux de gravité, les actions correctives avec responsables nommés et échéances, les résultats mesurés par rapport à vos RTO et RPO déclarés, et une validation de la direction. Un plan sans compte rendu de test est traité comme un plan qui ne fonctionne pas.

Construisez la piste de preuves au fur et à mesure, pas la semaine précédant l'audit. Les organisations qui peinent en juin 2026 sont celles qui traitent la documentation comme une réflexion après coup plutôt que comme un sous-produit de l'exécution réelle du processus.

Escalade des sanctions NIS2 — Au-delà de l'amende

!

Déclencheur

Non-conformité détectée ou incident survenu

Une autorité de contrôle identifie une lacune de conformité ou une organisation ne respecte pas les exigences NIS2

Les autorités peuvent imposer
Sanctions non financières
1

Ordres de mise en conformité avec délais contraignants

2

Audits de sécurité obligatoires à vos frais

3

Divulgation publique des violations

4

Instructions contraignantes sur des mesures de sécurité spécifiques

Escalade vers
Conséquences opérationnelles et personnelles
1

Suspension de certifications ou licences d'exploitation

2

Interdiction temporaire de fonctions de direction pour les individus

3

Désignation publique des personnes physiques responsables

Déclencheur
Non financier
Opérationnel / personnel

L'exposition aux sanctions plaide à elle seule. Les entités essentielles encourent des amendes allant jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial, et une défaillance de continuité qui transforme un incident récupérable en panne prolongée est précisément le type de négligence que les régulateurs signalent vouloir poursuivre. Mais l'argument le plus fort auprès des clients est opérationnel, pas réglementaire : une organisation qui peut prouver qu'elle restaure les services critiques dans une fenêtre définie est simplement une entreprise mieux gérée.

Par où commencer avec un client ce trimestre

Réalisez d'abord l'analyse d'impact sur l'activité — sans elle, toute autre décision relève de la supposition. Vérifiez ensuite trois choses dans l'ordre : les sauvegardes sont-elles isolées et immuables, un vrai test de restauration a-t-il eu lieu au cours des douze derniers mois, et existe-t-il une équipe de crise nommée avec des modèles prêts à envoyer. Ces trois vérifications séparent les clients réellement prêts de ceux qui ont un document.

Pour une lecture rapide de la situation d'une organisation sur les dix mesures de l'article 21, le scan rapide NIS2 transforme un vague « sommes-nous conformes ? » en une liste concrète de lacunes sur laquelle agir.

L'article 21(2)(c) récompense le travail ingrat : sauvegardes testées, décisions consignées, réponses répétées. C'est aussi le travail qui fait qu'une attaque par rançongiciel un vendredi soir est un mauvais week-end plutôt qu'un événement fatal pour l'entreprise.