SaaSFort
nis2 article-21 auto-audit conformité modèle-excel bsig

Comment remplir l'auto-audit NIS2 Article 21 (Excel gratuit)

Guide champ par champ pour un auto-audit NIS2 Article 21 défendable. 10 mesures obligatoires, exemples remplis, plus un modèle Excel gratuit.

ST
SaaSFort Team
· 10 Min. Lesezeit

Un responsable conformité d’une fintech de 140 personnes ouvre un Excel vierge et tape “contrôles NIS2 Article 21” dans la première cellule. Deux heures plus tard, le tableur a six lignes, trois couleurs et un partie prenante discrètement perplexe. La partie difficile n’est pas de construire les colonnes. La partie difficile est de savoir ce qui compte comme preuve pour chacune des dix mesures Article 21(2) — et à quel point la colonne “Statut” doit être stricte.

Cet article parcourt chaque mesure Article 21(2) avec la réponse remplie que les auditeurs attendent. Le modèle Excel gratuit vous donne la structure. Ce guide vous donne le remplissage.

Les dix mesures Article 21(2) (et pourquoi chacune fait trébucher les équipes)

L’Article 21(2) de NIS2 (UE 2022/2555) liste dix catégories de mesures de gestion des risques de cybersécurité que les entités essentielles et importantes doivent implémenter. Les catégories sont listées au niveau de la directive — ce qui signifie qu’elles sont délibérément larges. Les États membres les traduisent par la loi nationale (en Allemagne, §30 BSIG) ; le BSI publie ensuite des orientations interprétatives. Les dix catégories sont opérationnellement inséparables, ce qui explique pourquoi un audit par contrôle plutôt que par document tend à atterrir sur l’une de deux falaises : soit chaque ligne affiche “Oui” sans preuve derrière, soit chaque ligne affiche “Partiel” et personne ne sait quoi remédier en premier.

Le modèle impose une discipline : chaque ligne doit avoir un statut (Oui / Partiel / Non), une priorité (P0 / P1 / P2 / P3), une preuve requise, un responsable et une échéance. Le score de préparation COUNTIF en bas se met à jour à mesure que vous remplissez. Vous terminez avec un pourcentage défendable en réunion de conseil et un plan de remédiation classé par priorité — pas par celui qui a crié le plus fort.

21(2)(a) — Analyse de risque et politiques de sécurité des systèmes d’information

Ce qu’attendent les auditeurs : Une politique de sécurité de l’information documentée, approuvée par le conseil, révisée au moins annuellement. Un registre des risques qui mappe les actifs aux menaces et aux contrôles de 21(2)(b)–(j).

Défaillance courante : Un document de politique rédigé il y a trois ans par quelqu’un qui est parti, jamais révisé, jamais lié au registre des risques réel. Statut : Non. Priorité : P0.

Preuve à remplir : nom de fichier de la politique + version + date de dernière révision ; lien vers le registre des risques + date de dernière révision ; responsable SMSI nommé.

21(2)(b) — Gestion des incidents

Ce qu’attendent les auditeurs : Un runbook IR documenté, une procédure de notification de 24 heures alignée sur l’Article 23, des preuves d’au moins un tabletop ou post-mortem dans les 12 derniers mois.

Défaillance courante : Le runbook existe dans une page Notion ; la procédure de notification, c’est “pinguer le CTO sur Slack.” Statut : Partiel. Priorité : P0.

Preuve à remplir : URL du runbook IR ; date du dernier tabletop ; modèle de notification de 24h (le bundle de préparation aux incidents vous donne les trois).

21(2)(c) — Continuité d’activité, gestion des sauvegardes, gestion de crise

Ce qu’attendent les auditeurs : BCP / DRP avec objectifs RTO et RPO déclarés, testés dans les 12 derniers mois. Vérification de l’intégrité des sauvegardes (pas seulement leur existence).

Défaillance courante : Les sauvegardes s’exécutent nuitamment. La restauration n’a jamais été testée. Statut : Partiel. Priorité : P1.

Preuve à remplir : document BCP/DRP + version ; date du dernier test DR + résultat ; fréquence de vérification de l’intégrité des sauvegardes.

21(2)(d) — Sécurité de la chaîne d’approvisionnement

Ce qu’attendent les auditeurs : Un inventaire des fournisseurs critiques, des clauses de sécurité contractuelles avec chacun, un processus d’évaluation des risques fournisseurs, des preuves que l’évaluation s’exécute à l’intégration et au renouvellement.

Défaillance courante : “Nous utilisons AWS” traité comme toute la chaîne d’approvisionnement. Statut : Non. Priorité : P0.

Preuve à remplir : lien vers l’inventaire des fournisseurs ; exemple DPA / avenant sécurité ; responsable du processus d’évaluation des risques fournisseurs.

21(2)(e) — Sécurité dans l’acquisition, le développement et la maintenance des réseaux et systèmes d’information

Ce qu’attendent les auditeurs : Politique de gestion des vulnérabilités, SLA de correctifs défini par sévérité, inventaire des dépendances de production (SBOM), politique de divulgation coordonnée des vulnérabilités.

Défaillance courante : Le correctif est réactif — “on patche quand quelque chose se casse.” Pas de SLA, pas de SBOM, pas de politique de divulgation. Statut : Non. Priorité : P0.

Preuve à remplir : politique de correctifs + matrice SLA ; outil/processus SBOM ; URL de politique de divulgation.

21(2)(f) — Politiques et procédures pour évaluer l’efficacité des mesures de gestion des risques de cybersécurité

Ce qu’attendent les auditeurs : Scans de vulnérabilités externes exécutés régulièrement, dashboard KPI avec temps moyen de détection (MTTD) et temps moyen de réponse (MTTR), preuves que les constats entraînent des actions.

Défaillance courante : Un pentest d’il y a 18 mois est le seul artefact. Statut : Partiel. Priorité : P1.

Preuve à remplir : scanner externe / cadence de scan ; baseline MTTD/MTTR + actuel ; journal de remédiation lié aux constats de scan. Un scan SaaSFort gratuit remplit cette ligne en moins d’une heure.

21(2)(g) — Pratiques de cyber-hygiène de base et formation en cybersécurité

Ce qu’attendent les auditeurs : Enregistrements de formation annuelle à la sensibilisation sécurité pour tous les employés. Surtout : le §38 BSIG impose une formation en cybersécurité au niveau du conseil en Allemagne — la plupart des équipes oublient le conseil.

Défaillance courante : La formation existe pour les ingénieurs, pas pour la finance, les ventes ou le conseil. Statut : Partiel. Priorité : P0 si le conseil n’a pas été formé.

Preuve à remplir : plateforme de formation ; taux de complétion ; date de formation du conseil. L’article sur la responsabilité personnelle du conseil explique l’angle de responsabilité personnelle §38 BSIG qui rend cette ligne inhabituellement importante.

21(2)(h) — Politiques et procédures concernant l’utilisation de la cryptographie

Ce qu’attendent les auditeurs : TLS 1.2+ appliqué partout, chiffrement au repos pour les données sensibles, gestion des clés documentée, aucun cipher déprécié en production.

Défaillance courante : TLS 1.0 / 1.1 encore activé sur un sous-domaine oublié. Statut : Partiel. Priorité : P0 (c’est un constat gratuit et automatique pour tout scanner externe).

Preuve à remplir : audit de configuration TLS ; périmètre du chiffrement au repos ; procédure de gestion des clés.

21(2)(i) — Sécurité des ressources humaines, politiques de contrôle d’accès et gestion des actifs

Ce qu’attendent les auditeurs : Contrôle d’accès basé sur les rôles (RBAC), revues d’accès trimestrielles, gestion des accès privilégiés (PAM) pour les administrateurs, processus d’intégration-mobilité-départ documenté et exécuté.

Défaillance courante : Les revues d’accès se font “annuellement” — ce qui signifie jamais, ou sur un tableur ad-hoc. Statut : Partiel. Priorité : P1.

Preuve à remplir : matrice RBAC ; date de la dernière revue d’accès ; outil PAM ; checklist de départ.

21(2)(j) — Authentification multifacteur, communications voix/vidéo/texte sécurisées, communications d’urgence sécurisées

Ce qu’attendent les auditeurs : MFA appliqué sur tous les accès corporate, jetons FIDO2 / hardware pour les comptes privilégiés, canaux de communication chiffrés pour la réponse aux incidents.

Défaillance courante : Le MFA est appliqué pour les ingénieurs via SSO, mais l’équipe marketing se connecte toujours à HubSpot avec email + mot de passe. Statut : Partiel. Priorité : P0.

Preuve à remplir : périmètre d’application du MFA ; déploiement FIDO2 pour les utilisateurs privilégiés ; canal de communication d’urgence.

Comment mener l’audit (méthode de 90 minutes)

Le modèle s’adapte à une session de travail de 90 minutes si vous avez les bonnes personnes dans la salle.

Minute 0–15. Rôles. Un responsable par ligne. Le CTO ne possède pas les dix. Répartissez la charge : le responsable SMSI possède 21(2)(a), les opérations sécurité possèdent (b) et (f), l’équipe plateforme possède (c) et (h), les achats possèdent (d), la direction ingénierie possède (e) et (i), les RH/people ops possèdent (g), et l’IT possède (j). Sans responsables nommés, le statut devient “inconnu” et l’audit n’avance pas.

Minute 15–60. Statut. Remplissez le statut (Oui / Partiel / Non) pour chaque ligne en utilisant une règle stricte : “Oui” nécessite un artefact nommé et une date dans les 12 derniers mois. Tout ce qui est plus ancien ou verbal est “Partiel.” Tout ce qui n’a pas d’artefact est “Non.” Cette règle est sévère au premier passage et précise par conception.

Minute 60–75. Priorité. Le modèle utilise par défaut P0 / P1 / P2 / P3. La règle non évidente : la priorité suit le risque résiduel, pas le statut. Un “Non” sur 21(2)(j) MFA est P0 car le risque résiduel est catastrophique ; un “Non” sur 21(2)(g) formation du conseil est aussi P0 car l’exposition à la responsabilité personnelle est directe. Un “Partiel” sur 21(2)(c) test DR est P1 car le risque résiduel dépend de ce qui a été testé.

Minute 75–90. Responsables et échéances. Remplissez les colonnes “Responsable” et “Échéance” pour chaque ligne qui n’est pas “Oui.” Une ligne sans responsable est une ligne qui ne changera pas. Une échéance reportée après octobre 2026 est une échéance que vous ne pourrez pas défendre devant le BSI.

Le pourcentage de préparation COUNTIF en bas du modèle vous donne un seul chiffre à présenter en réunion de conseil. En dessous de 60 % avec trois mois avant la date limite, c’est une conversation au niveau du conseil. En dessous de 40 %, c’est une conversation au niveau du conseil qui devrait avoir lieu cette semaine.

Ce que le modèle ne peut pas faire

Trois limites honnêtes.

Il ne peut pas générer des preuves. Un modèle rempli est un auto-audit, pas une attestation tierce. La colonne “preuve requise” liste ce dont vous avez besoin ; le modèle ne la produit pas.

Il ne peut pas valider les contrôles techniques derrière les lignes. Une ligne qui dit “TLS 1.2+ appliqué” est vraie si et seulement si TLS 1.2+ est réellement appliqué — pas si la politique le dit. La validation externe est la moitié manquante. Un scan SaaSFort gratuit remplit les preuves techniques pour les lignes (e), (f), (h) et des parties de (j) automatiquement.

Il ne peut pas faire disparaître le problème de responsabilité personnelle §38 BSIG. Les membres du conseil des entités essentielles en Allemagne font face à une responsabilité personnelle directe pour les défaillances d’organisation. Le modèle documente si votre conseil a été formé. Corriger “Non” dans cette ligne est une invitation au calendrier, pas une mise à jour de tableur.

Utilisez le modèle, puis validez

Le modèle d’auto-audit Article 21 est gratuit, limité par email, et conçu pour les équipes de conformité sans budget de consultant à 50 000 €. Son companion est le bundle de préparation aux incidents, qui opérationnalise le processus de notification de 24 heures Article 23 — la contrepartie opérationnelle du cadre de contrôle de l’Article 21.

Les modèles documentent. Les scans vérifient. Utilisez les deux avant octobre 2026 et vous entrez dans la prochaine conversation BSI avec un pourcentage de préparation rempli, un plan de remédiation classé par priorité, et un scan externe validant la posture technique derrière vos lignes “Oui”.

FAQ

Le modèle d’auto-audit Article 21 est-il juridiquement suffisant pour la conformité NIS2 ?

Aucun modèle n’est juridiquement suffisant à lui seul. Le modèle est la documentation structurée que les régulateurs s’attendent à voir — mais la conformité Article 21 nécessite finalement que les contrôles sous-jacents existent réellement et soient testés. Utilisez le modèle pour cartographier votre posture ; utilisez la validation externe (scans, pentests, audits) pour la vérifier.

Quelle est la différence entre l’Article 21 et l’Article 23 ?

L’Article 21 impose les contrôles — ce que vous devez implémenter pour gérer le risque de cybersécurité. L’Article 23 impose le processus — comment et quand vous devez notifier les autorités des incidents significatifs. Ils sont opérationnellement inséparables : des contrôles Article 21 faibles produisent plus d’incidents Article 23.

Combien de temps devrait prendre un audit rempli ?

Un premier passage avec les bonnes personnes dans la salle prend 90 minutes. Remplir les preuves et remédier aux lignes “Non” prend des semaines à des mois selon la posture de départ. La plupart des équipes finissent l’audit structurel en une session et traitent la remédiation comme un projet de six mois.

Ai-je besoin d’un audit séparé pour §30 BSIG vs. Article 21 ?

Le §30 BSIG est la transposition allemande de l’Article 21. Les contrôles requis sont les mêmes ; l’autorité de surveillance et la jurisprudence diffèrent. Le modèle couvre directement l’Article 21(2) — ce qui est en correspondance biunivoque avec le §30 BSIG pour les entités essentielles allemandes.

Le modèle peut-il être utilisé par les entités importantes, pas seulement les entités essentielles ?

Oui. L’Article 21 s’applique aux deux types d’entités, avec proportionnalité basée sur la taille et le risque. Les entités importantes peuvent utiliser le modèle tel quel et ajuster les priorités en fonction de leur profil de risque.


La date limite d’enforcement d’octobre 2026 est dans six mois. Six mois suffisent pour remplir ce modèle, prioriser les lacunes et valider la posture technique si les travaux commencent maintenant. Ce n’est pas assez de temps pour les entreprises qui attendent jusqu’en septembre.


Téléchargez le modèle gratuit d’auto-audit NIS2 Article 21 — Excel, limité par email. Validez les lignes de posture technique avec un scan SaaSFort gratuit — 66 vérifications externes sur votre domaine en production, note A-F, cartographie NIS2. Pour le cadre de conformité complet, téléchargez notre SaaS Security Playbook 2026 gratuit. Companion : modèle de notification d’incident NIS2 de 24 heures + tabletop.

Artikel teilen
LinkedIn Post

Von der Theorie zur Praxis

Scannen Sie Ihre Domain kostenlos. Erste Ergebnisse in unter 10 Sekunden — ohne Registrierung.

Kostenlosen Scan starten

Weiterlesen