Compléter la conformité par la preuve : une approche bottom-up pour NIS2, DORA et le Cyber Resilience Act

Un changement de paradigme pour la cybersécurité

L'approche proposée ici ne cherche pas à remplacer la démarche documentaire, mais à la compléter par une autre source de preuve. L'idée est d'inverser ponctuellement le sens de lecture : plutôt que de partir de l'article de loi, partir d'une question technique vérifiable. Un attaquant peut-il s’introduire dans le SI ? Exfiltrer des données sensibles ? le détectons-nous ? Pouvons-nous nous en remettre et en combien de temps ? puis de relier la réponse obtenue aux exigences qu'elle vient documenter. La conformité s'appuie alors aussi sur des éléments mesurés en plus de ceux déclarés.

Le contexte réglementaire rend ce basculement non plus souhaitable mais inévitable : les trois textes structurants du moment exigent désormais explicitement de la résilience démontrée.

Exigences réglementaires cibles

1. NIS2 (Directive UE 2022/2555). Impose des mesures de gestion des risques (article 21), une notification d'incident sous contrainte de délai, et point souvent sous-estimé une responsabilité personnelle des organes de direction. Une mesure « documentée » mais inopérante n'est plus une couverture : c'est une exposition juridique pour le dirigeant qui l'a validée.
2. DORA (Règlement UE 2022/2554).C'est le texte qui ouvre le plus explicitement la porte à la preuve technique. Au-delà de la gestion du risque TIC (Technologies de l’Information et de la communication) , il prévoit un programme de tests de résilience opérationnelle, incluant pour les entités significatives du Threat-Led Penetration Testing (TLPT) inspiré du cadre TIBER-EU. Le test offensif y trouve donc une assise réglementaire directe, ce qui en fait un point d'entrée naturel pour une démarche fondée sur la preuve.
3. Cyber Resilience Act (Règlement UE 2024/2847). Déplace la charge vers les fabricants de produits comportant des éléments numériques : sécurité dès la conception, gestion documentée des vulnérabilités sur tout le cycle de vie, SBOM (Software Bill of Materials ou Nomenclature des composants logiciels), et marquage CE conditionné à ces obligations. Ici encore, une auto-déclaration ne suffira pas à porter la responsabilité produit : il faut une chaîne de preuve technique (build sécurisé, analyse de composition, traitement des CVE, audit de configuration, audit de code et audit d’architecture).

Ces trois régimes réglementaires partagent une même exigence de fond, la résilience doit être attestée par des éléments vérifiables, et non simplement déclarée.

Les audits qui peuvent objectiver la maturité

Répondre à ces nouvelles exigences implique d'aller au-delà de la documentation. Voici un panel d'évaluations techniques, classées par capacité défensive démontrée. Chacune produit une preuve datée, reproductible et exploitable.

Le critère discriminant face à la GRC classique : aucune de ces preuves n'est déclarative. Chacune répond à une assertion testable par un résultat mesuré, horodaté et rejouable.

L'expertise Synacktiv au service de la conformité

Chez Synacktiv, nous aidons les organisations à traduire les exigences de NIS2, DORA et du Cyber Resilience Act en évaluations techniques adaptées à leurs enjeux.

Nos équipes interviennent notamment pour :

1. Évaluer la robustesse des systèmes d'information au travers de tests d'intrusion et d'exercices Red Team ;
2. Accompagner les acteurs financiers dans leurs démarches de résilience opérationnelle et leurs exercices avancés de sécurité ;
3. Auditer la sécurité des produits numériques grâce à l'analyse de code, au reverse engineering et à la recherche de vulnérabilités ;
4. Fournir des résultats techniques exploitables à la fois par les équipes de sécurité, les directions et les autorités de contrôle.
5. Effectuer une analyse approfondie des équipements compromis pour comprendre le mode opératoire, délimiter le périmètre visé et mesurer les impacts de l'attaque.

L’objectif est simple : apporter une vision objective du niveau de sécurité réel et permettre aux organisations de démontrer leur conformité de manière tangible.

Comment expérimenter la méthodologie

La démarche peut se dérouler en cinq temps. L'objectif visé : qu'une même preuve technique puisse, autant que possible, documenter plusieurs exigences à la fois,  tester une fois et faire la liaison avec plusieurs référentiels.

1. Traduire les exigences en assertions testables : Plutôt que de reformuler l'article de loi en politique, on peut le décliner en question vérifiable : « DORA prévoit des tests de résilience » devient « notre dernier exercice a-t-il permis de détecter une exfiltration sur le périmètre critique ? ».
2. Adosser ces assertions à un référentiel technique : MITRE ATT&CK pour l'offensif et la détection, benchmarks CIS pour la configuration, exigences de cycle de vie du CRA pour le produit. Cela donne un langage commun entre l'équipe technique et l'auditeur.
3. Exécuter et produire la preuve : Chaque test génère un artefact exploitable : rapport TLPT, matrice de couverture ATT&CK, journal de restauration horodaté, SBOM, résultat de scan CI.
4. Remonter vers une matrice de preuves : Chaque artefact peut être cartographié vers les contrôles (ISO 27002:2022) puis vers les articles NIS2/DORA/CRA correspondants. On obtient une matrice où, à côté des preuves documentaires habituelles, figurent aussi des éléments issus de tests réels.
5. Inscrire la démarche dans la durée : Le BAS et l'intégration à la CI/CD permettent de passer, progressivement, d'une vérification ponctuelle à une validation plus régulière. La conformité s'appuie alors sur une photographie actualisée plus souvent qu'au seul rythme de l'audit.

Le jour de l'audit, l'organisation peut ainsi présenter, en plus de son corpus documentaire, un ensemble d'éléments mesurés dont chacun renvoie à un test que l'on peut, si besoin, rejouer.

La conformité fondée sur la preuve technique

Pourquoi cette approche mérite d'être considérée ?

Sans prétendre qu'elle constitue la « bonne » méthode unique, plusieurs éléments plaident pour explorer cette démarche en complément de la GRC classique.

1. Elle s'inscrit dans le sens des textes. DORA donne une assise réglementaire au test offensif (TLPT) ; le CRA met l'accent sur la SBOM et le suivi des vulnérabilités. Disposer de preuves techniques semble cohérent avec cette évolution.
2. Elle peut réduire certaines expositions. Sous NIS2, montrer qu'une mesure fonctionne réellement offre un appui plus tangible qu'une simple déclaration ; sous CRA, une chaîne de preuve technique tend à mieux soutenir la responsabilité produit.
3. Elle peut être plus efficiente. Une preuve technique bien cartographiée a vocation à servir plusieurs référentiels (ISO/IEC, NIS2, DORA, CRA) à la fois, ce qui peut limiter les redondances et rapprocher les équipes sécurité et conformité autour d'un même artefact.

En complément de l'approche classique, une démarche fondée sur l'analyse de risques permet d'identifier en amont les périmètres critiques, offrant ainsi à l'approche bottom-up toute sa pertinence. Cette articulation crée un cycle vertueux : la GRC s'appuie sur la réalité technique pour gagner en précision, tandis que la technique trouve dans la GRC un cadre qui lui confère cohérence et efficacité, optimisant ainsi le recueil de preuves et l'allocation des ressources.