NIS2 article 21(2)(a) : les deux documents que tout auditeur demande en premier

Le 15 août 2026, la loi néerlandaise Cyberbeveiligingswet est entrée en vigueur. Plus de 8 000 organisations ont désormais un devoir de diligence, une obligation d'enregistrement auprès du NCSC et un délai de notification de 24 heures.

Aucune d'elles ne sera d'abord interrogée sur sa console EDR.

L'article 21(2)(a) de NIS2 est le point de départ de toute conversation avec un superviseur : votre politique de sécurité des réseaux et des systèmes d'information, et votre cadre de gestion des risques. Deux documents. Tous deux approuvés par l'organe de direction. Tous deux datés.

La plupart des organisations n'ont ni l'un ni l'autre sous la forme réellement exigée par la réglementation. Voici ce qu'exige l'article 21(2)(a), mesure par mesure, et ce que cela implique pour les consultants chargés de le livrer.

L'article 21(2)(a) contient deux obligations, pas une

Le texte de la directive est bref : « politiques relatives à l'analyse des risques et à la sécurité des systèmes d'information ». Lu rapidement, cela ressemble à un document unique.

Le règlement d'exécution (UE) 2024/2690 en juge autrement. Son annexe scinde l'article 21(2)(a) en deux sections distinctes :

• Section 1 — Politique de sécurité des réseaux et des systèmes d'information, ainsi que rôles, responsabilités et autorités.
• Section 2 — Politique de gestion des risques : le cadre, le suivi de la conformité et l'examen indépendant.

Le règlement s'applique directement aux fournisseurs DNS, registres de TLD, fournisseurs de cloud, opérateurs de centres de données, CDN, fournisseurs de services gérés, fournisseurs de services de sécurité gérés, places de marché en ligne, moteurs de recherche, plateformes sociales et prestataires de services de confiance. Pour tous les autres, il constitue la référence de fait, faute de repère plus précis pour les autorités nationales.

Si vous livrez une seule « politique de sécurité de l'information » combinée et considérez l'article 21(2)(a) comme traité, vous en avez satisfait environ la moitié.

Votre politique de sécurité comporte onze contenus obligatoires

Le point 1.1.1 de l'annexe énumère ce que la politique de plus haut niveau doit contenir. Non pas « devrait envisager » — doit établir :

1. L'approche de l'entité pour gérer la sécurité de ses réseaux et systèmes d'information
2. La cohérence avec la stratégie et les objectifs de l'entreprise
3. Des objectifs de sécurité énoncés
4. Un engagement d'amélioration continue
5. Un engagement à fournir les ressources — personnel, budget, processus, outils, technologies
6. La communication aux employés et parties externes concernés, et leur prise de connaissance
7. Les rôles et responsabilités visés au point 1.2
8. La documentation à conserver et sa durée de conservation
9. La liste des politiques thématiques
10. Des indicateurs et mesures pour suivre la mise en œuvre et le niveau de maturité actuel
11. La date d'approbation formelle par les organes de direction

Le point 5 est celui qui fait échouer le plus d'audits. Une politique qui s'engage sur la sécurité mais jamais sur le budget ou les effectifs ne respecte pas 1.1.1(e). Le point 10 non plus : si vous ne pouvez pas montrer les indicateurs qui mesurent votre propre politique, vous avez une déclaration d'intention, pas une politique.

Le point 11 est le moins coûteux à corriger et le plus souvent absent. Une politique sans approbation datée de l'organe de direction est, du point de vue du superviseur, un projet.

La place de 21(2)(a) parmi les dix mesures

L'article 21(2)(a) est la première des dix mesures de gestion des risques — et celle dont toutes les autres découlent. Le contrôle d'accès au titre de 21(2)(i) doit être une politique thématique rattachée à votre politique de haut niveau. Les exigences de sauvegarde au titre de 21(2)(c) doivent découler d'une analyse d'impact sur l'activité qui alimente votre plan de traitement des risques. Si (a) est mal fait, les neuf autres n'ont pas de fondation.

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

L'organe de direction doit signer — puis signer de nouveau

Le point 1.1.2 exige que la politique soit examinée et, le cas échéant, mise à jour par les organes de direction au moins une fois par an, et en outre chaque fois que surviennent des incidents importants ou des changements importants dans les opérations ou les risques. Le résultat de chaque examen doit être documenté.

Deux conséquences pratiques.

D'abord, « annuellement » est un plancher, pas un calendrier. Une fusion, une nouvelle plateforme cloud, un incident de rançongiciel chez un fournisseur clé — chacun déclenche un examen hors cycle. Si votre client a déployé un nouvel ERP en mars et que la politique a été revue pour la dernière fois en janvier, c'est une lacune qu'un superviseur trouve en une question.

Ensuite, l'examen est une activité de direction, pas une activité informatique. Le RSSI peut le préparer. L'organe de direction doit le réaliser. C'est l'expression opérationnelle de la responsabilité personnelle prévue à l'article 20 — et la raison pour laquelle les procès-verbaux sont devenus des preuves d'audit.

Au moins une personne doit rendre compte directement à la direction

Le point 1.2.3 est une phrase aux conséquences démesurées : au moins une personne rend compte directement aux organes de direction sur les questions de sécurité des réseaux et systèmes d'information.

Pour un MSP, c'est la ligne que vous ne pouvez pas franchir au nom de votre client. Vous pouvez exploiter le SOC, rédiger la politique, tenir le registre des risques et préparer le dossier destiné au conseil. Vous ne pouvez pas être la personne qui rend compte à la direction en leur nom, car la responsabilité se situe à l'intérieur de l'entité.

Le point 1.2.5 ajoute la séparation des tâches incompatibles, le cas échéant. Le point 1.2.4 admet la réalité des entités plus petites : la sécurité peut être une tâche exercée en plus d'un rôle existant plutôt qu'une fonction dédiée. Ce qu'il n'admet pas, c'est l'absence de cette tâche.

Le cadre de gestion des risques est un processus, pas un tableur

Le point 2.1.2 de l'annexe définit le processus de gestion des risques cyber en dix étapes. Les entités doivent :

• Suivre une méthodologie de gestion des risques
• Établir un niveau de tolérance au risque conforme à leur appétence
• Établir et maintenir des critères de risque
• Identifier et documenter les risques selon une approche tous risques, incluant explicitement les tiers et les points de défaillance unique
• Analyser menace, probabilité, impact et niveau de risque, en s'appuyant sur le renseignement sur les menaces et les données de vulnérabilité
• Évaluer les risques au regard des critères
• Identifier et hiérarchiser les options de traitement
• Suivre en continu la mise en œuvre des mesures de traitement
• Désigner qui est responsable de chaque mesure de traitement et à quelle échéance
• Documenter les mesures dans un plan de traitement des risques, avec une justification compréhensible de tout risque résiduel accepté

Comparez cette liste au registre des risques d'un client moyen. La plupart contiennent une liste de risques avec une notation rouge-orange-vert. Très peu disposent d'une méthodologie documentée, d'un niveau de tolérance défini, de propriétaires nommés avec échéances et d'une justification écrite du risque résiduel.

L'exigence « tous risques » est aussi plus large que ne le supposent la plupart des équipes. Elle couvre les menaces physiques et environnementales, la défaillance d'un fournisseur et l'indisponibilité du personnel — pas seulement les cyberattaques. Si votre registre ne contient que des scénarios d'attaque, il ne satisfait pas 2.1.2(d). Le risque tiers en particulier doit être identifiable dans le registre lui-même, ce qui le relie aux obligations de chaîne d'approvisionnement au titre de l'article 21(2)(d).

Le point 2.1.3 ajoute une contrainte que les consultants devraient accueillir favorablement : pour hiérarchiser le traitement, les entités doivent mettre en balance le coût de mise en œuvre et le bénéfice attendu. La proportionnalité est inscrite dans le règlement. Vous n'êtes pas tenu de tout recommander — vous êtes tenu de justifier ce que vous avez fait et ce que vous n'avez pas fait.

Le risque résiduel doit porter un nom

Le point 2.1.1 est la phrase qui change la gouvernance : les résultats de l'évaluation des risques et les risques résiduels doivent être acceptés par les organes de direction, ou par des personnes responsables et habilitées à gérer les risques, avec un reporting adéquat aux organes de direction.

C'est une exigence de signature. « Le conseil a été informé » n'est pas une acceptation. Il faut une décision, prise par une personne responsable nommément désignée, et consignée.

Le point 2.1.4 exige ensuite que l'évaluation des risques et le plan de traitement soient revus à intervalles planifiés et au moins annuellement, ainsi qu'après des incidents importants ou des changements importants. Même logique de déclenchement que pour la revue de la politique, appliquée au registre.

Suivi de la conformité et examen indépendant sont deux choses différentes

Le point 2.2 exige un examen régulier du respect de vos propres politiques, normes et règles, avec un reporting régulier aux organes de direction via un système de reporting de conformité efficace.

Le point 2.3 exige tout autre chose : un examen indépendant de l'approche de l'entité en matière de gestion de la sécurité — personnes, processus et technologies — réalisé par des personnes disposant d'une compétence d'audit appropriée et n'appartenant pas à la ligne hiérarchique du domaine examiné.

Lorsque la séparation est impossible en raison de la taille, l'entité doit mettre en place des mesures alternatives garantissant l'impartialité. Elle ne peut pas simplement omettre l'examen.

C'est l'ouverture commerciale la plus claire de l'article 21(2)(a) pour les consultants et vCISO. Une entité importante de dix personnes ne peut pas produire un examinateur indépendant en interne. Un examinateur externe est la mesure alternative. Notez que 2.3 s'ajoute à, et ne remplace pas, l'évaluation d'efficacité prévue à l'article 21(2)(f) — les superviseurs attendront les deux.

Les superviseurs n'attendent plus

La pression vient de deux directions à la fois.

Au niveau national : les Pays-Bas sont passés en vigueur le 15 août 2026 avec le Cyberbeveiligingswet, couvrant 18 secteurs et plus de 8 000 entités. La fenêtre d'enregistrement allemande s'est fermée il y a des mois alors qu'une large part des entités concernées n'était toujours pas enregistrée. L'Autriche, la Suède, la Pologne et le Portugal sont tous en vigueur.

Depuis Bruxelles : le 8 juillet 2026, la Commission européenne a saisi la Cour de justice de l'UE contre l'Irlande, l'Espagne, la France et les Pays-Bas pour transposition incomplète, en demandant des sanctions financières. Les États membres lents à transposer sont fortement poussés — ce qui, historiquement, se traduit par des autorités nationales désireuses de montrer une activité de contrôle dès que leur loi est adoptée.

Statut de Mise en Œuvre NIS2 par Pays (2025–2026)
✅
Pleinement en vigueur
🇧🇪Belgique
🇭🇷Croatie
🇭🇺Hongrie
🇱🇹Lituanie
🇱🇻Lettonie
🇮🇹Italie
6 pays
📋
Adopté — fin 2025
🇩🇪Allemagne
🇨🇿République tchèque
🇫🇮Finlande
3 pays
⏳
En cours — prévu 2026
🇳🇱Pays-Bas
🇫🇷France
🇪🇸Espagne
🇵🇱Pologne
🇦🇹Autriche
🇸🇪Suède
🇮🇪Irlande
7 pays

Ce qui se passe quand 21(2)(a) manque

Une politique absente ou non datée est rarement le constat qui clôt une inspection. C'est le constat qui en ouvre une. Si la politique de haut niveau n'est pas approuvée, les politiques thématiques qui en dépendent n'ont aucun mandat. Si le registre des risques n'a pas de méthodologie, toute décision de contrôle en aval devient injustifiable.

À partir de là, la boîte à outils de supervision s'intensifie : instructions contraignantes, audits obligatoires aux frais de l'entité, publication de la non-conformité, amendes administratives jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial pour les entités essentielles, et — pour les entités essentielles — suspension temporaire des fonctions de direction.

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

Un plan de 30 jours pour les consultants

Si vous accompagnez des clients concernés, voici la séquence qui produit le plus vite des preuves défendables :

Jours 1–5. Récupérez la politique de sécurité actuelle du client. Confrontez-la aux onze contenus du point 1.1.1. La plupart échouent sur les ressources, les indicateurs et la date d'approbation.

Jours 6–10. Déterminez si quelqu'un rend compte directement à l'organe de direction sur la sécurité. Sinon, désignez cette personne et faites-le consigner.

Jours 11–20. Reconstruisez le registre des risques autour de 2.1.2 : méthodologie documentée, tolérance définie, périmètre tous risques incluant fournisseurs et points de défaillance unique, propriétaires nommés, échéances et justification écrite du risque résiduel.

Jours 21–25. Présentez la politique et le plan de traitement des risques à l'organe de direction. Obtenez une approbation formelle, datée et consignée.

Jours 26–30. Définissez la cadence du suivi de conformité au titre de 2.2 et planifiez le premier examen indépendant au titre de 2.3, avec une note explicite sur la garantie d'impartialité.

Cela produit les deux artefacts qu'un superviseur demande en premier — avec la traçabilité de gouvernance qui prouve qu'ils sont réels.

Pour évaluer rapidement la position d'un client au regard de l'article 21 avant d'engager un périmètre de projet, lancez le quick scan NIS2. Il cartographie les écarts en quelques minutes, ce qui vous permet de chiffrer le travail au lieu de le deviner.

En résumé

L'article 21(2)(a) n'est pas de la surcharge documentaire. C'est le contrôle qui rend tous les autres défendables. Une politique aux onze contenus définis et une approbation datée du conseil. Un cadre de risque avec méthodologie, propriétaires nommés et risque résiduel accepté. Un suivi de conformité, et un examen indépendant par quelqu'un hors de la ligne hiérarchique.

Tout le reste de l'article 21 repose là-dessus. Construisez-le d'abord.