Obligations essentielles

Ce que couvre réellement l'article 21

L'article 21 de la directive NIS2 est le cœur opérationnel du texte. Il ne se contente pas de fixer un objectif général de « sécurité » : il énumère dix catégories de mesures que toute entité essentielle ou importante doit mettre en œuvre, en les qualifiant d'« appropriées et proportionnées » au regard de son exposition au risque, de sa taille et de la probabilité et gravité des incidents susceptibles de l'affecter. Cette formulation n'est pas une clause de style. Elle signifie qu'il n'existe pas un standard unique à appliquer mécaniquement : une collectivité territoriale de 40 agentsagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire et un opérateur d'infrastructure numérique de 3 000 salariés répondent au même article, avec des dispositifs radicalement différents dans leur ampleur.

Ce chapitre traite chaque mesure comme une exigence opérationnelle et non comme un intitulé juridique à recopier dans une politique. L'objectif est de savoir, pour chacune, ce qu'un auditeur ou une autorité de contrôle s'attend à trouver comme preuve tangible.

La proportionnalité n'est pas une option de confort. Une entité qui applique un dispositif disproportionné par rapport à son risque réel (trop lourd ou trop léger) s'expose de la même façon : soit à un gaspillage de ressources difficile à justifier, soit à une non-conformité caractérisée en cas d'incident. La cartographie des risques (mesure a) doit précéder tout choix de dimensionnement, jamais l'inverse.

Les dix mesures minimales, sans paraphrase

Gouvernance : cartographier avant d'agir (mesures a, f, g, i)

La mesure a) est le socle : sans analyse de risques documentée, aucune des neuf autres mesures ne peut être qualifiée d'« appropriée ». Une analyse de risques recevable identifie les actifs critiques (systèmes, donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire, processus métier), les scénarios de menace plausibles et leur impact, puis débouche sur une politique de sécurité des systèmes d'information formellement approuvée par l'organe de direction. Ce dernier point est souvent négligé : une politique rédigée par la DSI mais jamais validée en comité de direction ne constitue pas une preuve de gouvernance au sens de NIS2.

La mesure f) exige que l'entité évalue elle-même l'efficacité de ses mesures, via des audits internes ou externes, des indicateurs de sécurité suivis dans le temps, et des revues de direction documentées. Un dispositif de sécurité qui n'a jamais été testé (exercice de crise, test d'intrusion, audit de configuration) ne peut pas démontrer son efficacité, même s'il est correctement documenté sur le papier.

La mesure g) couvre la cyberhygiène et la formation. Il ne s'agit pas d'une session annuelle de sensibilisation générique, mais d'un programme différencié selon les populations : utilisateurs finaux (hameçonnage, mots de passe), administrateurs systèmes (durcissement, gestion des privilèges), développeurs (codage sécurisé), et dirigeants (obligations légales, responsabilité).

La mesure i) regroupe la sécurité RH, le contrôle d'accès et la gestion des actifs. Trois processus concrets sont attendus : un inventaire des actifs numériques tenu à jour, une procédure d'habilitation basée sur le principe du moindre privilège, et une procédure de départ garantissant la révocation effective des accès (souvent le point faible constaté en audit).

Avant de lancer un nouveau projet de mise en conformité, cartographiez ce qui existe déjà (certification ISO 27001, PSSI existante, plan de continuité). L'article 21 ne demande pas de tout reconstruire : il demande de démontrer une couverture complète des dix domaines, y compris via des dispositifs préexistants correctement documentés et reliés entre eux.

Résilience opérationnelle : incidents et continuité (mesures b, c)

La mesure b) impose une procédure de gestion des incidents qui va de la détection à la notification réglementaire. NIS2 fixe un calendrier strict pour les incidents dits « importants » : une alerte précoce sous 24 heures après la prise de connaissance, une notification détaillée sous 72 heures précisant l'évaluation initiale de gravité et d'impact, et un rapport final dans un délai d'un mois (ou un rapport intermédiaire si l'incident est toujours en cours). Ce calendrier ne peut être respecté que si la procédure de détection et de qualification interne est elle-même rapide : une entité qui met deux semaines à identifier qu'un incident relève du périmètre « important » a déjà manqué son obligation avant même d'avoir notifié quoi que ce soit.

La mesure c) couvre la continuité d'activité : gestion des sauvegardes (avec test de restauration effectif, pas seulement planification), plan de reprise d'activité pour les systèmes critiques, et gestion de crise au sens large (cellule de crise identifiée, rôles définis, exercices réguliers). Un plan de continuité qui existe uniquement sous forme de document jamais testé ne répond pas à l'exigence : la preuve attendue est celle d'un exercice réalisé et de ses enseignements intégrés.

Le non-respect grave et répété des mesures de gestion des risques peut engager la responsabilité personnelle des organes de direction, au-delà de la seule responsabilité de l'entité. Ce n'est pas une clause théorique : elle change la nature des arbitrages budgétaires en interne, la sécurité cessant d'être un sujet purement technique délégué à la DSI.

Chaîne d'approvisionnement et sécurité technique (mesures d, e, h, j)

La mesure d) est souvent la plus sous-estimée. Elle exige une sécurisation de la chaîne d'approvisionnement, c'est-à-dire une évaluation du risque cyber posé par chaque fournisseur et prestataire ayant accès au système d'information ou fournissant des composants logiciels. Concrètement : clauses contractuelles de sécurité, exigence de notification d'incident par le fournisseur, et évaluation périodique (pas seulement à la signature du contrat).

Un établissement de santé sous-traite l'hébergement de son dossier patient à un prestataire cloud, et achète un logiciel de gestion des rendez-vous auprès d'un éditeur tiers. Pour la mesure d), l'établissement doit démontrer qu'il a évalué le niveau de sécurité de ces deux tiers avant contractualisation, qu'il dispose d'une clause imposant leur notification en cas d'incident les concernant, et qu'il réévalue ce risque au moins annuellement. Pour la mesure e), si l'éditeur du logiciel de rendez-vous publie une mise à jour corrective, l'établissement doit avoir une procédure de déploiement des correctifs sous un délai défini, et savoir tracer que ce correctif a bien été appliqué sur l'ensemble du parc concerné.

La mesure e) porte sur l'acquisition, le développement et la maintenance des systèmes : cycle de développement intégrant la sécurité dès la conception, procédure de gestion des vulnérabilités (veille, priorisation, correction), et politique de divulgation responsable pour les vulnérabilités découvertes dans les systèmes propres à l'entité.

La mesure h) demande une politique de cryptographie formalisée : quels types de données sont chiffrées, avec quels algorithmes, au repos comme en transit, et selon quelle gestion des clés. L'absence de politique écrite, même si le chiffrement est techniquement en place, constitue une lacune documentaire fréquemment relevée.

La mesure j) impose l'authentification à plusieurs facteurs ou continue là où c'est pertinent, ainsi que des moyens de communication sécurisés — y compris des canaux de secours utilisables si les systèmes habituels sont compromis, un point souvent oublié : comment la cellule de crise communique-t-elle si la messagerie d'entreprise est elle-même hors service ?

ReCyF : traduire le texte en preuves vérifiables

L'article 21 fixe des objectifs, pas des contrôles techniques précis. C'est là qu'intervient ReCyF, le référentiel opérationnel qui décline chacune des dix mesures en contrôles concrets, niveaux de maturité et éléments de preuve attendus, en s'appuyant sur les référentiels déjà connus des équipes sécurité (ISO 27001, EBIOS RM, guides d'hygiène existants). Là où l'article 21 dit « gestion des incidents », ReCyF précise les artefacts attendus : registre des incidents, preuve du respect des délais 24h/72h/1 mois, procédure d'escalade documentée et testée.

L'intérêt pratique de ReCyF est double. D'abord, il évite à chaque entité de réinventer sa propre interprétation du texte, avec le risque de sous-couvrir certains points lors d'un contrôle. Ensuite, il permet de mapper l'existant : une entité déjà certifiée ISO 27001 peut identifier rapidement les écarts résiduels plutôt que repartir d'une page blanche.

Le niveau de preuve attendu diffère selon que l'entité est qualifiée d'essentielle ou d'importante. Les entités essentielles font l'objet d'un contrôle proactif (audits programmés par l'autorité), tandis que les entités importantes sont contrôlées a posteriori, en général déclenché par un incident ou un signalement. Ce statut ne change rien aux dix mesures à mettre en œuvre, mais il change la probabilité et le moment où l'absence de preuve sera constatée.

Pièges fréquents

• Traiter les dix mesures comme une liste de cases à cocher indépendantes plutôt que comme un système cohérent issu d'une même analyse de risques initiale.
• Confondre document et preuve d'application : une politique signée n'est pas une preuve d'efficacité si aucun contrôle n'atteste qu'elle est appliquée sur le terrain.
• Sous-traiter sans transférer les exigences contractuelles : le risque porté par un prestataire reste un risque de l'entité au regard de NIS2, même si l'incident se produit chez le fournisseur.
• Oublier la temporalité : un plan de continuité jamais testé, une clé de chiffrement jamais renouvelée, une formation dispensée une seule fois il y a trois ans — la conformité s'évalue dans la durée, pas à un instant T.
• Laisser la sécurité comme sujet exclusivement technique : sans portage par la direction (approbation de la politique, arbitrage budgétaire, participation aux exercices de crise), les preuves de gouvernance attendues en mesure a) et f) font défaut.

Checklist de mise en œuvre opérationnelle

• Cartographie des actifs et analyse de risques formalisée et datée de moins de 12 mois
• Politique de sécurité des SI approuvée par l'organe de direction (procès-verbal à l'appui)
• Procédure d'incident testée, avec calendrier de notification 24h/72h/1 mois documenté
• Plan de continuité avec au moins un exercice de restauration réalisé dans l'année
• Registre des fournisseurs critiques avec clauses de sécurité et évaluation périodique
• Procédure de gestion des vulnérabilités avec délais de correction définis par criticité
• Politique de cryptographie écrite couvrant repos et transit
• Inventaire des accès avec revue périodique et procédure de départ vérifiée
• MFA déployé sur les accès sensibles, canal de communication de secours identifié
• Indicateurs de sécurité suivis et revus au moins une fois par an en comité de direction

Ce qu'il faut retenir avant le prochain chapitre

Les dix mesures de l'article 21 ne sont pas une liste plate : elles s'articulent autour d'un socle de gouvernance (analyse de risques, politique, évaluation), d'un axe de résilience (incidents, continuité) et d'un axe technique et contractuel (chaîne d'approvisionnement, développement, cryptographie, authentification). ReCyF ne remplace pas ce travail d'analyse : il en structure la preuve. Le chapitre suivant approfondit précisément le point le plus sensible en pratique — la mécanique de notification des incidents, ses délais, et les erreurs de qualification qui font basculer une entité en défaut de conformité alors même que l'incident a été correctement traité sur le plan technique.