Suivre Les obligations de détection réglementaires sont les résultats de sécurité que DORA, NIS2, PCI DSS v4.0.1, et les règles de divulgation de la SEC exigent qu’une organisation atteigne et démontre par la détection, la surveillance, la journalisation, et la divulgation.
Aucun de ces quatre régimes ne prescrit un outil de détection spécifique. Seul DORA nomme la détection comme une obligation autonome. Chaque cadre nécessite un résultat : détection en temps opportun, surveillance continue, journalisation structurée, ou divulgation en temps opportun. La capacité de détection est ce que prouve l’évidence, pas un contrôle imposé par un nom par tout régulateur.
MITRE ATT&CK organise ces preuves dans une structure que l’auditeur peut interroger par catégorie de comportement d’adversaire. ATT&CK n’est pas requis par DORA, NIS2, PCI DSS, ou les règles de la SEC.
DORA est lex specialis ou une loi spécifique qui prévaut sur une loi générale. DORA Article 1(2) en fait un acte juridique sectoriel de l’Union aux fins de l’article 4 de NIS2. Une entité financière dans le champ d’application de DORA applique DORA pour la gestion des risques ICT et le rapport d’incidents. NIS2 atteint la chaîne d’approvisionnement non financière d’une banque, pas la banque elle-même.
Quelles preuves de détection soutiennent les obligations sous PCI DSS 4.0 et DORA?
Les deux PCI DSS v4.0.1 et DORA considèrent la détection comme un moyen vers une fin probatoire. La réglementation demande si les détections génèrent les enregistrements que l’obligation de surveillance exige, et non si des détections existent.
Cinq classes de preuves transportent cette preuve. Les deux régimes les exigent en substance.
| Classe de preuves | PCI DSS v4.0.1 | DORA |
|---|---|---|
| Sources de journaux collectées | Exigence 10 : capturer les journaux d’audit, conserver l’historique | Article 9(1) : surveiller et contrôler en continu la sécurité et le fonctionnement des systèmes ICT; Article 10(3) : surveiller l’activité des utilisateurs, les anomalies ICT et les incidents liés aux ICT |
| Règles déployées, avec propriétaire | Exigence 11 : détection/prévention des intrusions, détection des changements en place | Article 10 : plusieurs couches de contrôle, seuils d’alerte définis et critères |
| Preuve de déclenchement | Exigence 10 : revoir les journaux, détecter les défaillances des systèmes de contrôle | Article 10 : alertes déclenchées et atteignant le personnel responsable |
| Historique des changements | Exigence 11 : détection des changements et altérations | Article 17 : processus documenté de gestion des incidents avec suivi de la cause racine |
| Rapport de couverture daté | Exigence 10.5.1 : l’historique des journaux d’audit est conservé pendant au moins 12 mois, les trois mois les plus récents étant immédiatement disponibles (bibliothèque de documents PCI SSC) | Article 10(1) : les mécanismes de détection sont régulièrement testés conformément à l’article 25 |
PCI DSS v4.0 a été retiré le 31 décembre 2024 et PCI DSS v4.0.1 est la seule version active (PCI SSC, juin 2024). Les 51 exigences futures datées sont devenues effectives le 31 mars 2025 (PCI SSC, août 2024). Le H2 ci-dessus utilise « PCI DSS 4.0 » pour correspondre à la requête du chercheur.
Une règle de détection qui se déploie mais ne génère aucun enregistrement auditable est invisible pour un évaluateur.
Quelles obligations de détection et de surveillance imposent réellement DORA, NIS2, PCI DSS 4.0 et les règles de divulgation de la SEC ?
Chaque régime impose une obligation de résultat plutôt qu’un mandat d’outil. Le tableau ci-dessous cartographie chaque obligation à l’évidence de détection qu’elle implique.
| Régime | Article ou Exigence | Obligation | Preuve de détection implicite |
|---|---|---|---|
| DORA | Art 9(1), Art 10(3) | Surveiller et contrôler en continu la sécurité et le fonctionnement des systèmes ICT (Art 9(1)); surveiller l’activité des utilisateurs, les anomalies ICT et les incidents liés aux ICT (Art 10(3)) | Inventaire des sources de journaux, enregistrements de collecte continue |
| DORA | Art 10(1), (2) | Détecter les activités anormales; plusieurs couches de contrôle avec des seuils et critères d’alerte, y compris des alertes automatiques au personnel chargé de la réponse aux incidents; les mécanismes de détection sont régulièrement testés en vertu de l’article 25 | Inventaire des règles avec propriétaires, justification des seuils, preuve que les alertes ont atteint les répondants, enregistrements des tests |
| DORA | Art 17 | Détecter, gérer et notifier les incidents liés aux ICT avec un suivi de la cause racine | Documentation des processus, enregistrements de détection et de traitement incident par incident |
| DORA | Art 19 + Réglementation déléguée (UE) 2025/301 | Rapporter les incidents majeurs à l’autorité compétente | Enregistrement de détection et de classification horodaté (notification initiale dans les 4 heures suivant la classification de l’incident comme majeur et au plus tard 24 heures après en avoir pris connaissance; rapport intermédiaire dans les 72 heures de la notification initiale; rapport final dans un mois du rapport intermédiaire) |
| NIS2 | Art 21(2) | Mesures de gestion des risques incluant le traitement des incidents (point (b)) et politiques pour évaluer l’efficacité des mesures (point (f)); les devoirs de surveillance et de journalisation se situent dans les règles d’exécution ci-dessous, pas dans l’article 21 lui-même | Mesures documentées, enregistrements de détection |
| NIS2 | Art 23(4) | Notification d’incidents significatifs | Alerte précoce dans les 24 heures après en avoir pris connaissance, notification d’incident dans les 72 heures, rapport final au plus tard un mois après la notification de l’incident |
| NIS2 | Règlement d’exécution (UE) 2024/2690 | Surveillance et journalisation (Annexe section 3.2) pour les onze types d’entités de l’article 1(1), y compris les fournisseurs de services de sécurité gérés | Enregistrements explicites de journalisation pour les entités couvertes |
| PCI DSS v4.0.1 | Exigence 10 | Journaliser et surveiller tous les accès aux composants système et aux données des détenteurs de cartes | Les journaux d’audit sont examinés au moins quotidiennement (10.4.1), examen automatique des journaux (10.4.1.1), historique des journaux conservée (10.5.1), les défaillances des systèmes de contrôle de sécurité critiques sont détectées, signalées, et traitées rapidement (10.7, 10.7.2); texte dans le bibliothèque de documents PCI SSC |
| PCI DSS v4.0.1 | Exigence 11 | Tester régulièrement la sécurité des systèmes et réseaux | Enregistrements de détection et de prévention des intrusions (11.5.1), alertes de détection des changements (11.5.2), alertes de détection des changements et altérations des pages de paiement (11.6.1) |
| SEC | 8-K Article 1.05 | Divulguer les incidents matériels dans les quatre jours ouvrables suivant la détermination de la matérialité, qui elle-même doit être faite sans retard déraisonnable après la découverte (Formulaire 8-K, Article 1.05) | Processus de détermination de la matérialité, enregistrements de détection d’incidents |
| SEC | S-K Article 106 | Décrire les processus d’évaluation, d’identification et de gestion des risques matériels en cybersécurité dans le rapport annuel 10-K (Article 1C) | Processus documenté d’identification des risques incluant la capacité de détection |
DORA (Réglementation (UE) 2022/2554, appliquée depuis le 17 janvier 2025) est directement applicable. Ses horloges de notification sont fixées par Réglementation déléguée (UE) 2025/301: notification initiale dans les 4 heures suivant la classification d’un incident comme majeur et au plus tard 24 heures après en avoir pris connaissance, un rapport intermédiaire dans les 72 heures de la notification initiale, et un rapport final dans un mois du rapport intermédiaire. Parce que la première horloge commence à la détection et la classification, la chronologie de l’incident elle-même est une preuve auditable.
NIS2 (Directive (UE) 2022/2555) lie par la loi nationale de transposition de chaque État membre, pas directement. La date limite de transposition était le 17 octobre 2024 (Article 41). Le 7 mai 2025, la Commission européenne a envoyé des avis motivés à 19 États membres pour n’avoir pas notifié la pleine transposition, et le 8 juillet 2026, elle a renvoyé l’Irlande, l’Espagne, la France et les Pays-Bas à la Cour de justice. Le 20 janvier 2026, la Commission a proposé des amendements à NIS2 (COM(2026) 13) qui touchent l’article 21(5) et ajoutent des paragraphes sur le ransomware à l’article 23, laissant inchangés les mesures de l’article 21(2) et les horloges de rapport de l’article 23(4). L’obligation à laquelle un acheteur est confronté dépend de la loi de transposition de son État membre.
Règlement d’exécution (UE) 2024/2690, publié le 18 octobre 2024 et en vigueur depuis le 7 novembre 2024, établit des exigences explicites de surveillance et de journalisation (section 3.2 de l’annexe) pour les fournisseurs de services DNS, registres de nom TLD, informatique en nuage, centre de données, réseau de diffusion de contenu, services gérés et fournisseurs de services de sécurité gérés, places de marché en ligne, moteurs de recherche, plateformes de réseautage social, et fournisseurs de services de confiance. Cela s’étend aux MSSP en tant qu’entités réglementées de leur propre droit, distinctes des obligations de leurs clients.
PCI DSS v4.0.1 est la seule version active. Les exigences 10 et 11 portent les obligations de détection et de surveillance.
SEC (règle finale Publié 33-11216, adoptée le 26 juillet 2023) est une règle de divulgation et de gouvernance, pas un mandat de contrôles de détection. La détection est dérivée : un déclarant ne peut déterminer la matérialité sans la capacité de détecter et d’évaluer les incidents. Le respect de l’Article 1.05 était requis à partir du 18 décembre 2023 pour la plupart des déclarants et à partir du 15 juin 2024 pour les petites entreprises rapportant.
Quelles preuves les auditeurs recherchent-ils généralement pour confirmer que nos systèmes de détection sont efficaces ?
Cinq classes de preuves se répètent dans ces régimes. Un pourcentage de couverture seul ne constitue une preuve pour aucun d’entre eux.
| # | Classe de preuves | Ce qu’il prouve |
|---|---|---|
| 1 | Sources de journaux collectées | Quelle télémétrie est ingérée, à partir de quels systèmes, et que la collecte est continue. L’auditeur vérifie si la surveillance est en cours, pas si elle a été une fois configurée. |
| 2 | Règles déployées | Règles de détection en place, chacune mappée à l’obligation qu’elle soutient et à sa ATT&CK technique où applicable, avec un propriétaire. |
| 3 | Preuve de déclenchement | Les règles ont fonctionné sur des événements réels ou simulés et les alertes ont atteint les répondants. Une règle déployée qui n’a jamais fonctionné n’est pas testée du point de vue de l’auditeur. |
| 4 | Historique des changements | Qui a changé une règle, quand, et pourquoi : contrôle de version, piste de révision, et justification documentée pour chaque changement. |
| 5 | Rapport de couverture daté | Rapport à un instant donné avec une date, ainsi les tendances et la monnaie sont prouvables. Un rapport non daté ne prouve rien sur quand la couverture existait. |
ATT&CK fonctionne comme le tableau croisé qui rend cette preuve interrogeable par comportement d’adversaire. Un ID technique est une métadonnée attachée aux preuves déjà existantes (sources de données, règles déployées, enregistrements de déclenchement) pour que les preuves deviennent récupérables par catégorie de comportement. ATT&CK n’est requis par aucun de ces quatre régimes. Il organise les preuves contre les obligations qu’ils imposent.
Pouvez-vous montrer à un auditeur qui a changé une règle, quand, et pourquoi ?
Détection-comme-Code répond à cela. Chaque règle de détection est un artefact versionné dans le contrôle source. L’historique des changements enregistre l’auteur, l’horodatage, l’approbation de la révision, et la raison du changement.
Cette piste cartographie les obligations spécifiques :
- L’article 17 de DORA nécessite un processus documenté de gestion des incidents avec suivi de la cause racine.
- PCI DSS v4.0.1 L’exigence 11 comprend la détection des changements et des altérations.
- L’Article 106 de la SEC s’attend à ce qu’un déclarant décrive ses processus d’identification des risques.
Chaque cadre demande si l’organisation gouverne les règles de détection comme des artefacts contrôlés, et non simplement si des règles existent.
Le test opérationnel : étant donné une règle qui a fonctionné le trimestre dernier, l’équipe peut-elle produire sa lignée complète ? Qui l’a écrite, qui l’a révisée, quand elle a été modifiée pour la dernière fois, pourquoi, à quelle obligation elle est mappée, et quelle technique elle adresse. Une plateforme de contenu de détection qui gère les règles comme du code versionné produit cette piste en tant que sous-produit des opérations normales.
Là où les règles sont éditées dans une console sans contrôle de version, l’auditeur n’a pas de provenance pour l’état actuel des règles. La gouvernance Détection-comme-Code élimine cette ambiguïté par construction.
Comment la couverture de détection devient-elle un élément de ligne de conformité ?
La capacité de détection tend à se situer dans les budgets d’opérations, visible pour le gestionnaire du SOC, invisible pour le CFO. Trois faits font de la couverture une conversation au conseil d’administration.
- Les horloges de rapport démarrent à la détection. L’horloge de classification de 4 heures de DORA et l’horloge de matérialité de quatre jours ouvrables de la SEC commencent toutes deux lorsque l’organisation détecte ou en prend conscience. Une détection plus rapide est le début de la chronologie de conformité.
- Les preuves de détection sont auditables. Les cinq classes de preuves ci-dessus sont celles qu’un auditeur examine. Les produire coûte du temps et du personnel, que l’équipe construise ses propres règles ou s’abonne à une source de contenu de détection.
- Le temps pour la couverture est mesurable. La fenêtre entre une technique devenant publique et une détection validée fonctionnant dans l’environnement propre de l’organisation est traçable.
Une équipe d’ingénierie demande une capacité de détection en termes d’effectifs et d’outillage. Une équipe de conformité la demande en termes de production de preuves. Le second cadrage lie les dépenses de détection à une obligation réglementaire que le conseil suit déjà.
Un audit de posture SIEM produit la carte de couverture qu’exigent les auditeurs : règles mappées à MITRE ATT&CK, sources de journaux mappées à la même matrice, et les lacunes listées avec un plan.
Là où cela ne tient pas
Plusieurs limitations s’appliquent.
Toutes les obligations ne se mappent pas à la détection. L’article 1.05 de la SEC exige la divulgation, pas des contrôles spécifiques. L’article 21 de NIS2 et DORA incluent à la fois la sécurité de la chaîne d’approvisionnement, la continuité des affaires, et la gestion des accès. Aucun de ceux-ci ne se mappent aux techniques ATT&CK. ATT&CK organise le sous-ensemble de détection et de surveillance, pas toute la surface de conformité.
La transposition NIS2 est incomplète. Là où la loi de transposition d’un État membre n’est pas en vigueur, les articles 21 et 23 de NIS2 ne sont pas localement exécutoires. Les amendements proposés en janvier 2026 ne renumérotent pas les articles 21 ou 23.
Les règles de la SEC sont contestées. The pétition de rétorsion contre l’article 1.05, déposée le 22 mai 2025 par cinq associations professionnelles bancaires et boursières (SEC File No. 4-856), reste non résolue : au 21 septembre 2026, la SEC n’a proposé aucun amendement à l’article 1.05, bien que les pétitionnaires aient renouvelé la demande dans une lettre de commentaires d’avril 2026 dans le cadre de l’examen de la Régulation S-K de la Commission. Un déclaration du 21 mai 2024 par Erik Gerding, alors directeur de la Division of Corporation Finance, a clarifié que l’article 1.05 est réservé aux incidents qu’un déclarant a déterminé comme matériels et a encouragé la divulgation d’autres incidents sous un article différent tel que l’article 8.01; la division a suivi avec des interprétations complètes des divulgations le 24 juin 2024.
Les numéros de sous-exigence suivent v4.0.1. Les sous-exigences PCI DSS citées ici (10.4.1, 10.4.1.1, 10.5.1, 10.7, 10.7.2, 11.5.1, 11.5.2, 11.6.1) utilisent la numérotation v4.0.1; la norme elle-même est dans le bibliothèque de documents PCI SSC, et l’exigence 10.7.2 s’applique à toutes les entités à partir du 31 mars 2025.
ATT&CK est une passerelle, pas une obligation réglementaire. Mapper les détections aux techniques ATT&CK organise les preuves. Cela ne libère aucune obligation réglementaire, et aucun cadre examiné ici ne l’exige.
DORA est lex specialis pour les entités financières. Une banque dans le champ d’application de DORA n’applique pas les articles 21 et 23 de NIS2 en plus pour sa propre gestion des risques ICT et son rapport d’incidents. NIS2 atteint la chaîne d’approvisionnement non financière d’une banque, pas les opérations ICT propres de la banque.
LISTE DE CONTRÔLE DES PREUVES D'AUDIT : OBLIGATIONS DE DÉTECTION
1. SOURCES DE JOURNAL COLLECTÉES
[ ] Inventaire des sources de télémétrie ingérées
[ ] Preuve de collecte continue (pas ponctuelle)
[ ] Chaque source mappée aux systèmes, actifs, et
obligations qu'elle couvre
2. RÈGLES DÉPLOYÉES
[ ] Inventaire des règles de détection avec propriétaires nommés
[ ] Chaque règle mappée à l'obligation réglementaire qu'elle soutient
[ ] Chaque règle mappée à la technique ATT&CK où applicable
(passerelle, non requise par la régulation)
[ ] Seuils d'alerte documentés avec justification
3. PREUVE DE DÉCLENCHEMENT
[ ] Preuve que des règles ont fonctionné sur des événements réels ou simulés
[ ] Enregistrements que les alertes ont atteint les répondants désignés
[ ] Enregistrements de tests datés pour les mécanismes de détection
(Article 10 de DORA)
4. HISTORIQUE DES CHANGEMENTS
[ ] Contrôle de version pour chaque règle de détection
(Détection-comme-Code)
[ ] Auteur, réviseur, horodatage, et justification par changement
[ ] Piste de révision et d'approbation
[ ] Enregistrements de détection des changements et des altérations
5. RAPPORT DE COUVERTURE DATÉ
[ ] Rapport de couverture ponctuel avec date
[ ] Couverture mesurée par rapport à un ensemble de techniques priorisées,
pas la matrice ATT&CK complète
[ ] Données de tendance montrant la couverture dans le temps
[ ] Reporting par environnement (pas un seul chiffre agrégé)
ÉLÉMENTS SPÉCIFIQUES AU RÉGIME
[ ] DORA : seuils d'alerte documentés avec justification
(Article 10)
[ ] DORA : horodater les incidents sur les horloges de rapport
(4h depuis la classification / 24h depuis la connaissance,
72h intermédiaire, 1 mois final)
[ ] NIS2 : preuves mappées à la loi nationale transposée,
non au texte de la directive seul
[ ] PCI DSS v4.0.1 : rétention des journaux selon les
sous-exigences applicables
[ ] SEC : processus documenté de détermination de la matérialité
(Article 1.05)
[ ] SEC : supervision par le conseil d'administration et rôle de gestion décrits
(Article 106)
NOTES
- ATT&CK est la passerelle utilisée pour organiser ces preuves.
Il n'est pas requis par DORA, NIS2, PCI DSS, ou les règles de la SEC.
- DORA est lex specialis : une banque dans le champ d'application de DORA applique DORA,
pas les articles 21 et 23 de NIS2, pour la gestion des risques ICT.
- PCI DSS v4.0.1 est la seule version active
(v4.0 retiré le 31 décembre 2024).
- Chaque spécificité réglementaire de ce document est validée
par ciso-cto-sme avant publication.
FAQ
Quelles preuves de détection soutiennent les obligations sous PCI DSS 4.0 et DORA?
Les deux régimes exigent des preuves de détection et de surveillance continues, non seulement des preuves que des outils de détection sont déployés. Les cinq classes de preuves sont : les sources de journaux collectées, les règles de détection déployées avec des propriétaires, la preuve que ces règles fonctionnent, l’historique des changements avec contrôle de version, et un rapport de couverture daté. MITRE ATT&CK organise ces preuves par catégorie de comportement d’adversaire. ATT&CK n’est requis par aucun des deux cadres.
Quelles preuves les auditeurs recherchent-ils pour confirmer que les systèmes de détection sont efficaces ?
Les auditeurs recherchent cinq classes de preuves : quelles sources de télémétrie sont collectées et que la collecte est continue, règles de détection mappées aux obligations et aux techniques ATT&CK avec des propriétaires nommés, preuve que ces règles fonctionnent sur des événements réels ou simulés, historique des changements versionné pour chaque règle, et un rapport de couverture daté à un instant donné. Un pourcentage de couverture seul, sans les enregistrements de support en dessous, n’est pas une preuve.
Est-ce que mapper les détections à MITRE ATT&CK satisfait un régulateur ?
ATT&CK est la passerelle qui organise les preuves de détection par comportement d’adversaire. Cela rend les preuves interrogeables et rapportables par technique. Cela ne libère pas en soi une obligation réglementaire. DORA, NIS2, PCI DSS, et les règles de la SEC demandent des preuves de l’opération : surveillance, détection, journalisation, et divulgation. ATT&CK organise ces preuves. Aucun cadre examiné ici ne l’exige.
Quels sont les délais de notification des incidents sous DORA et NIS2 ?
Sous DORA, le Réglement délégué (UE) 2025/301 fixe les délais pour les incidents majeurs : notification initiale dans les 4 heures suivant la classification de l’incident comme majeur (au plus tard 24 heures après la prise de conscience), un rapport intermédiaire dans les 72 heures suivant la notification initiale, et un rapport final dans un mois du rapport intermédiaire. Sous NIS2, des incidents significatifs nécessitent un avertissement précoce dans les 24 heures après en avoir pris connaissance, une notification d’incident dans les 72 heures, et un rapport final au plus tard un mois après la notification d’incident. Les deux délais commencent à la détection, faisant de l’horodatage de détection elle-même une preuve auditable.
Le contenu personnalisé de SOC Prime met en œuvre des détections dans votre SIEM ou EDR et fournit une documentation de haut niveau de leur objectif, fonction, et utilisation.
