NIS2 infrastructure numérique : la règle des 30 minutes que personne n'a configurée

Une plateforme RMM tombe en panne à 09h14 un mardi. Le prestataire la rétablit à 09h48. Trente-quatre minutes, quelques clients agacés, un avoir, terminé.

Sauf que ce n'est pas terminé. En vertu du règlement d'exécution (UE) 2024/2690, cette panne est un incident important, et le compte à rebours de 24 heures pour l'alerte précoce a démarré dès que le prestataire en a eu connaissance.

C'est la partie de la conformité NIS2 infrastructure numérique que les consultants continuent de sous-estimer. Pour les types d'entités couverts par le règlement 2024/2690, le langage vague de l'article 21 a déjà été remplacé par des chiffres. Des minutes. Des pourcentages. Votre client ne peut plus débattre de ce que signifie "approprié et proportionné" quand le règlement le lui a dit exactement.

L'infrastructure numérique est le seul secteur NIS2 qui ne négocie pas l'article 21

NIS2 est une directive. Elle a nécessité 27 lois nationales de transposition, arrivées tardivement, de manière inégale, et dans certains cas toujours absentes.

Le règlement 2024/2690 est un règlement. Publié au Journal officiel le 18 octobre 2024, il s'applique directement dans chaque État membre. Pas de transposition. Pas de couche d'interprétation nationale. Là où il fixe une exigence, cette exigence s'applique — indépendamment de ce que dit ou ne dit pas la loi NIS2 locale.

Son annexe découpe l'article 21(2) en 13 groupes d'exigences avec des sous-exigences numérotées. Le point 11 à lui seul divise le contrôle d'accès en gestion des droits d'accès, comptes privilégiés, systèmes d'administration, identification unique, authentification et authentification multifacteur. Les rédacteurs se sont appuyés sur ISO/IEC 27001, ISO/IEC 27002, ETSI EN 319 401 et CEN/TS 18026:2024 : un SMSI existant vous amène donc à mi-chemin — mais la correspondance n'est pas univoque, et c'est dans les écarts que tombent les audits.

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

Si votre client ne fait pas partie des types d'entités couverts, cela compte quand même. Le règlement 2024/2690 est l'expression officielle la plus détaillée de ce que la Commission entend par conformité à l'article 21. Les autorités de contrôle qui évaluent un client de l'énergie ou de la santé le liront. Vous aussi. Voir notre décryptage des dix mesures de l'article 21 pour la vue au niveau de la directive.

Onze types d'entités sont couverts, et les seuils de taille n'en sauvent pas la plupart

Le règlement nomme ses destinataires à l'article 1er :

• Fournisseurs de services DNS
• Registres de noms de domaine de premier niveau
• Fournisseurs de services d'informatique en nuage
• Fournisseurs de services de centres de données
• Fournisseurs de réseaux de diffusion de contenu
• Fournisseurs de services gérés
• Fournisseurs de services de sécurité gérés
• Fournisseurs de places de marché en ligne
• Fournisseurs de moteurs de recherche en ligne
• Fournisseurs de plateformes de réseaux sociaux
• Prestataires de services de confiance

Deux erreurs reviennent systématiquement chez les consultants.

Premièrement, les fournisseurs de services DNS, les registres de noms de domaine de premier niveau et les prestataires de services de confiance relèvent du champ d'application au titre de l'article 2(2) de NIS2, quel que soit leur effectif ou leur chiffre d'affaires. Un opérateur DNS de quatre personnes est concerné. La règle de taille qui sauve les petites entreprises dans la plupart des secteurs ne s'applique pas à eux.

Deuxièmement, "fournisseur de services gérés" est défini largement à l'article 6(39) de la directive : une entité fournissant des services liés à l'installation, à la gestion, à l'exploitation ou à la maintenance de produits TIC, de réseaux, d'infrastructures, d'applications ou de tout autre système de réseau et d'information, sur site client ou à distance. C'est l'essentiel du marché des MSP, plus un bon nombre de sociétés qui se présentent comme "support informatique" ou "partenaire de développement" sans jamais employer le mot géré. Si vous lisez ceci en tant que consultant, vérifiez si cela vous décrit avant de vérifier si cela décrit vos clients — notre guide NIS2 pour les MSP traite la double obligation en détail.

La compétence territoriale est le piège suivant. Les entités d'infrastructure numérique sont généralement supervisées là où se trouve leur établissement principal, pas là où se trouvent leurs clients. Si vous n'êtes pas certain de l'autorité qui supervise votre client, lisez notre article sur l'article 26 avant de présumer.

Les seuils d'importance sont des horloges, pas des appréciations

C'est là que le règlement 2024/2690 s'écarte le plus de la façon dont la plupart des organisations gèrent aujourd'hui le tri des incidents.

L'article 3 fixe des critères horizontaux applicables à toute entité couverte. Un incident est important s'il a causé ou est susceptible de causer une perte financière directe supérieure à 500 000 EUR ou à 5% du chiffre d'affaires annuel total de l'entité lors de l'exercice précédent, le montant le plus faible étant retenu. Également s'il peut entraîner l'exfiltration de secrets d'affaires. Également si un accès réussi, présumé malveillant et non autorisé s'est produit et est susceptible de causer une perturbation opérationnelle grave — et le considérant 39 précise qu'un acteur malveillant qui se positionne en vue d'une perturbation ultérieure compte, même sans perturbation à ce stade.

Viennent ensuite les critères spécifiques par type d'entité :

Fournisseurs cloud (article 7) — indisponibilité totale de plus de 30 minutes. Disponibilité limitée pendant plus d'une heure touchant plus de 5% des utilisateurs dans l'Union ou plus d'un million d'utilisateurs dans l'Union, le nombre le plus faible étant retenu. Toute atteinte à l'intégrité, à la confidentialité ou à l'authenticité des données résultant d'une action présumée malveillante, sans aucun seuil de nombre d'utilisateurs.

Fournisseurs de centres de données (article 8) — indisponibilité totale d'un service de centre de données, point, sans condition de durée. Disponibilité limitée pendant plus d'une heure. Atteinte aux données résultant d'une action présumée malveillante. Et compromission de l'accès physique à l'installation : un incident de talonnage au sas devient donc un événement à notifier.

MSP et MSSP (article 10) — indisponibilité totale de plus de 30 minutes. Disponibilité limitée pendant plus d'une heure touchant plus de 5% ou un million d'utilisateurs dans l'Union, le nombre le plus faible étant retenu. Atteinte aux données résultant d'une action présumée malveillante.

Notez le mode de comptage des utilisateurs. Au titre de l'article 3(3), vous comptez les clients sous contrat et les personnes physiques et morales associées aux clients professionnels qui utilisent le service. Un MSP comptant 60 entreprises clientes ne compte pas 60 utilisateurs. Il compte chaque salarié de ces 60 entreprises qui touche au service géré.

L'article 4 ferme la dernière brèche : les incidents récurrents qui, pris isolément, restent sous le seuil sont agrégés et traités comme un seul incident important lorsqu'ils remplissent collectivement les critères sur une fenêtre de six mois. Trois pannes distinctes de 20 minutes de même cause racine ne sont pas trois non-événements.

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.
Étape 1
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.
Étape 2
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.
Étape 3
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.

Les délais de notification eux-mêmes n'ont pas changé — 24 heures pour l'alerte précoce, 72 heures pour la notification d'incident, un mois pour le rapport final. Ce qui a changé, c'est la fréquence à laquelle l'horloge démarre. Nous détaillons le mécanisme dans les délais de notification d'incident NIS2.

La maintenance planifiée est exemptée, mais seulement si vous pouvez prouver qu'elle était planifiée

L'article 3(2) exclut les interruptions programmées et les conséquences prévues des opérations de maintenance programmées. Le considérant 33 étend cela à l'indisponibilité fondée sur des accords contractuels préétablis.

Cette exemption ne vaut que ce que valent vos enregistrements. Le considérant 34 indique que la durée d'un incident de disponibilité court de la perturbation de la fourniture correcte du service jusqu'au rétablissement — et lorsque l'entité ne peut déterminer le moment où la perturbation a commencé, la durée est mesurée à partir du moment de la détection, ou du moment de l'enregistrement dans les journaux, la date la plus précoce étant retenue.

Relisez cela depuis le siège d'un auditeur. Une journalisation médiocre ne vous accorde pas le bénéfice du doute. Elle produit l'heure de début défendable la plus précoce. Une entité à la supervision faible déclarera systématiquement des incidents plus longs qu'une entité bien outillée, pour exactement la même panne.

Le contrôle pratique ici n'est donc pas un document de politique. C'est un calendrier de maintenance horodaté, approuvé à l'avance et conservé — plus une supervision capable d'établir une heure de début à la minute près.

"Non applicable" est permis, mais doit être écrit

Le considérant 6 laisse aux entités la possibilité de conclure qu'une exigence précise de l'annexe n'est pas appropriée, pas applicable ou pas réalisable pour elles. Le considérant 5 autorise des mesures compensatoires lorsque la taille rend une exigence impraticable — une micro-entité incapable de séparer des tâches conflictuelles peut y substituer une surveillance ciblée de la direction ou une journalisation et une supervision renforcées.

Les deux sont assortis d'une condition : l'entité doit documenter son raisonnement de manière compréhensible.

C'est le livrable à plus forte valeur qu'un consultant puisse produire ce trimestre pour un client de l'infrastructure numérique. Pas un énième modèle de politique. Une déclaration d'applicabilité écrite, datée et approuvée par la direction, qui parcourt les 13 points de l'annexe et consigne quelles sous-exigences sont mises en œuvre, lesquelles ne le sont pas, et pourquoi — avec la mesure compensatoire nommée là où elle est utilisée.

Les autorités n'attendent pas qu'un MSSP de douze personnes ressemble à un hyperscaler. Elles attendent que l'entité y ait réfléchi sur le papier avant l'audit, pas pendant. Notre checklist des preuves pour les audits de supervision couvre ce que les régulateurs demandent par ailleurs.

Que faire dans les 30 prochains jours

1. Classifier. Déterminez si chaque client — et votre propre cabinet — relève de l'un des onze types d'entités de l'article 1er. Appliquez les exemptions de l'article 2(2) avant les seuils d'effectif.
2. Recalculer le nombre d'utilisateurs. Reconstruisez le chiffre des utilisateurs dans l'Union pour chaque service couvert, y compris les utilisateurs finaux chez les clients professionnels. La plupart des entités travaillent avec un chiffre inférieur d'un ordre de grandeur.
3. Réinitialiser les règles de tri. Intégrez les seuils de 30 minutes et d'une heure dans la plateforme de supervision comme conditions d'alerte, pas comme critères de revue a posteriori. Si un humain doit remarquer le franchissement du seuil, il le remarquera tard.
4. Corriger le registre de maintenance. Fenêtres planifiées approuvées et horodatées à l'avance, conservées au moins pour la période de supervision.
5. Rédiger la déclaration d'applicabilité. Treize points d'annexe, sous-exigence par sous-exigence, avec justification de chaque exclusion.

Les entités couvertes par le règlement 2024/2690 se situent en amont de la conformité de tous les autres. Quand un MSP ou un fournisseur cloud échoue à un audit, le constat descend la chaîne d'approvisionnement jusque dans chaque contrat client qui l'a désigné comme fournisseur critique — l'autre raison de traiter cela maintenant plutôt qu'après la première décision de sanction.

Si vous voulez une vision structurée de la position d'un client au regard de l'article 21 et du règlement d'exécution avant de vous engager sur un plan de remédiation, lancez un quick scan NIS2. Cela prend quelques minutes et vous donne un point de départ défendable pour la discussion.