Signalement des incidents DORA et mesures ISO 27001 en 2026

Il est 08 h 17 un mardi matin de 2026. Sarah, RSSI d’une FinTech européenne, voit un tableau de bord passer à l’orange, pas au rouge. Une plateforme critique de règlement des paiements ralentit. Les transactions n’échouent pas complètement, mais elles prennent trois fois plus de temps que ne le prévoit l’accord de niveau de service. Le SOC observe des tentatives d’authentification inhabituelles visant un compte administrateur. Le fournisseur d’infrastructure cloud signale une dégradation de service dans une zone de disponibilité. Le support client commence à recevoir des appels de clients entreprises qui demandent pourquoi les fichiers de paiement sont retardés.

Personne ne sait encore s’il s’agit d’une cyberattaque, d’une défaillance de résilience opérationnelle, d’une interruption fournisseur, d’un incident de protection des données, ou de tout cela à la fois.

Sarah a déjà un problème DORA avant même que les faits techniques soient établis. S’agit-il d’un incident majeur lié aux TIC ? Affecte-t-il une fonction critique ou importante ? A-t-il franchi le seuil interne de gravité ? Qui doit être notifié, quand, et avec quels éléments probants ? Si des données à caractère personnel sont concernées, le délai de notification GDPR a-t-il également commencé à courir ? Si un prestataire tiers de services TIC fait partie de la chaîne d’incident, qui est responsable de l’établissement des faits ?

C’est à ce moment que les entités financières découvrent l’écart entre disposer d’un plan de réponse aux incidents et disposer d’un modèle opérationnel de signalement des incidents DORA vérifiable en audit.

En 2026, le signalement des incidents DORA exige davantage qu’une escalade rapide. Il exige une chaîne défendable depuis la détection jusqu’à la classification, de la classification au signalement à l’autorité de contrôle, du signalement à la remédiation, puis de la remédiation au retour d’expérience. ISO/IEC 27001:2022 fournit la structure du système de management. Les mesures de l’Annexe A ISO/IEC 27002:2022 fournissent les attentes pratiques de contrôle. Les politiques, la feuille de route en 30 étapes et le guide de conformité croisée de Clarysec transforment ces attentes en mise en œuvre prête à produire des éléments probants.

Pourquoi le signalement des incidents DORA échoue sous pression

La plupart des défaillances de signalement des incidents DORA ne commencent pas par de la négligence. Elles commencent par de l’ambiguïté.

Un analyste sécurité voit une alerte, mais ne sait pas si elle constitue un incident lié aux TIC au sens de DORA. Le responsable des services informatiques traite la dégradation de performance comme un problème technique de service, tandis que la fonction conformité la considère comme un événement réglementaire. Le juridique attend une confirmation avant d’escalader. Le propriétaire métier ne peut pas encore quantifier l’impact client. Le RSSI veut des éléments probants, mais les journaux pertinents sont dispersés entre services cloud, terminaux, systèmes d’identité, SIEM et plateformes fournisseurs.

Lorsque l’organisation s’accorde enfin sur la classification, la fenêtre de signalement est déjà sous tension.

Les Articles 17 à 21 de DORA établissent une attente structurée en matière de gestion, de classification, de signalement, de contenu de signalement et de traitement prudentiel des incidents liés aux TIC. Pour les entités financières, l’exigence opérationnelle est claire : surveiller, gérer, journaliser, classifier, signaler, mettre à jour et tirer des enseignements des incidents liés aux TIC d’une manière qui puisse être reconstituée ultérieurement.

La Politique de réponse aux incidents [IRP] de Clarysec intègre directement DORA dans le cadre de référence :

DORA de l’UE (2022/2554) : Article 17 : exigences de signalement des incidents TIC par les établissements financiers aux autorités compétentes.

La même politique relie la gestion des incidents aux mesures ISO/IEC 27002:2022 5.25 à 5.27, couvrant les responsabilités d’appréciation des incidents, de réponse, de communication et d’amélioration.

Pour les petites entreprises de technologie financière et les entités réglementées à structure légère, la Politique de réponse aux incidents - PME [IRP-SME] de Clarysec rend l’obligation opérationnelle en soulignant que DORA impose aux entités financières de classifier, signaler et suivre les incidents et perturbations liés aux TIC.

Cette formulation est importante. La conformité DORA ne se limite pas à un modèle de signalement. L’organisation doit classifier, signaler et suivre. Cela suppose des éléments probants sur l’événement initial, les critères de décision, le niveau de gravité, la décision de signalement, les communications, les actions de reprise, l’implication des fournisseurs et le suivi.

ISO/IEC 27001:2022 comme centre de commandement des incidents DORA

Un système de management de la sécurité de l’information ISO/IEC 27001:2022 mature ne doit pas devenir un silo de conformité supplémentaire à côté de DORA. Il doit devenir le centre de commandement du signalement des incidents DORA.

Le SMSI exige déjà la propriété du risque, la sélection des mesures de sécurité, l’audit interne, la revue de direction, les informations documentées, l’amélioration continue et les éléments probants du fonctionnement des contrôles. DORA ajoute une pression sectorielle de signalement, mais ISO/IEC 27001:2022 fournit la structure de gouvernance qui rend le processus répétable.

Le Zenith Blueprint : feuille de route en 30 étapes pour auditeurs [ZB] de Clarysec renforce cette intégration à l’étape 13, planification du traitement des risques et Déclaration d’applicabilité. Le Blueprint recommande de mettre en correspondance les mesures, les risques et les clauses pour assurer la traçabilité, notamment en ajoutant une référence à une mesure de l’Annexe A aux risques et en indiquant quand les mesures soutiennent GDPR, NIS2 ou DORA.

Pour l’incident de règlement des paiements de Sarah, l’entrée du registre des risques pourrait être :

« Perturbation ou compromission de la plateforme de traitement des paiements. »

Les mesures de l’Annexe A ISO/IEC 27001:2022 mises en correspondance comprendraient 5.24, 5.25, 5.26, 5.27, 5.28, 6.8, 8.15 et 8.16, avec une note DORA relative à la classification et au signalement des incidents majeurs liés aux TIC.

Le Zenith Controls : guide de conformité croisée [ZC] de Clarysec sert ensuite de boussole de conformité croisée. Dans Zenith Controls, Clarysec met en correspondance les mesures ISO/IEC 27002:2022 avec d’autres mesures ISO/IEC 27001:2022, les normes associées, les attentes d’audit et les réglementations telles que DORA, GDPR et NIS2. Il ne crée pas de « mesures Zenith » distinctes. Il montre comment les mesures ISO existantes fonctionnent ensemble et comment elles sont testées.

Le processus de signalement DORA peut être vu comme une chaîne de contrôles :

Vous ne pouvez pas signaler ce que vous n’avez pas détecté. Vous ne pouvez pas classifier ce que vous n’avez pas évalué. Vous ne pouvez pas justifier une décision de signalement sans enregistrements. Vous ne pouvez pas améliorer sans revue post-incident.

Mesure 6.8 : le chronomètre DORA démarre avec les personnes

Dans le scénario de Sarah, le premier signal utile peut ne pas venir du SOC. Il peut venir d’un responsable de relation client qui entend les réclamations des clients, d’un utilisateur financier qui constate l’échec de lots de règlement, ou d’un ingénieur qui observe une latence anormale.

C’est pourquoi la mesure 6.8 de l’Annexe A ISO/IEC 27001:2022, signalement des événements de sécurité de l’information, est essentielle pour DORA. Elle fait du signalement une responsabilité de l’ensemble du personnel, et pas seulement une fonction des opérations de sécurité.

Dans le Zenith Blueprint, étape 16, contrôles relatifs aux personnes II, Clarysec indique :

Un système efficace de réponse aux incidents commence non par les outils, mais par les personnes.

L’étape 16 recommande des canaux de signalement clairs, une formation de sensibilisation, une culture sans blâme, le triage, la confidentialité et des simulations périodiques. Le message opérationnel le plus utile est simple :

« En cas de doute, signalez. »

C’est un principe de contrôle DORA. Si les employés attendent d’être certains, l’organisation perd du temps. S’ils signalent tôt, l’organisation peut évaluer, classifier et décider.

Dans Zenith Controls, 6.8 est mise en correspondance comme un contrôle de détection soutenant la confidentialité, l’intégrité et la disponibilité. Elle se rattache à 5.24 parce que les canaux de signalement doivent faire partie du plan de gestion des incidents. Elle alimente 5.25 parce que les événements ne peuvent être évalués que s’ils sont signalés. Elle déclenche 5.26 parce que la réponse formelle commence après l’évaluation des signalements.

Pour DORA, cela soutient les Articles 17 et 18, selon lesquels les entités financières doivent gérer, classifier et signaler les incidents majeurs liés aux TIC et les cybermenaces significatives. Cela soutient également GDPR Article 33 et le considérant 85, car le signalement interne détermine la rapidité avec laquelle une violation de données à caractère personnel est identifiée et escaladée.

Une mise en œuvre pratique Clarysec consiste à établir une fiche d’instruction d’une page « Comment signaler un incident TIC ». Elle doit inclure :

• Ce qu’il faut signaler, notamment les interruptions de service, les courriels suspects, les appareils perdus, les comportements système inhabituels, les suspicions de compromission fournisseur, les accès non autorisés, les fuites de données et les dégradations de service ayant un impact client.
• Comment signaler, au moyen d’une boîte aux lettres surveillée, d’une catégorie de ticket, d’une ligne d’appel dédiée, d’un canal de collaboration ou d’un portail SOC.
• Ce qu’il faut inclure, par exemple l’heure, le système, l’utilisateur, le processus métier, l’impact observé, des captures d’écran si cela est sûr, et l’éventuelle incidence sur des clients ou des données à caractère personnel.
• Ce qu’il ne faut pas faire, notamment ne pas supprimer les journaux, ne pas redémarrer les systèmes critiques sans instruction, ne pas contacter les clients à l’extérieur sans approbation et ne pas enquêter au-delà de son rôle.
• Ce qui se passe ensuite, notamment le triage, la classification, l’escalade, la réponse, la conservation des preuves et une éventuelle appréciation réglementaire.

L’objectif n’est pas de transformer chaque employé en enquêteur. Il est de faire de chaque employé une source de signalement fiable.

Mesure 5.25 : le point de décision de classification DORA

Le signalement des incidents majeurs liés aux TIC au titre de DORA repose sur la classification. C’est là que la mesure 5.25 de l’Annexe A ISO/IEC 27001:2022, appréciation et décision relatives aux événements de sécurité de l’information, devient centrale.

Le Zenith Blueprint, étape 23, explique la difficulté pratique :

Toute anomalie n’est pas une catastrophe. Toute alerte ne signale pas une compromission.

Il décrit ensuite l’objet de 5.25 comme suit :

distinguer l’inoffensif du nuisible, et savoir ce qui exige une escalade.

Pour DORA, c’est le moment où un événement de sécurité, une dégradation de service, une interruption fournisseur, une exposition de données ou une perturbation opérationnelle est évalué au regard des critères d’incident majeur. L’organisation doit prendre en compte l’impact opérationnel, les services affectés, les fonctions critiques ou importantes, les clients et transactions concernés, la durée, l’étendue géographique, l’impact sur les données, les implications réputationnelles et l’impact économique.

Dans Zenith Controls, 5.25 est mise en correspondance directement avec DORA Article 18, classification des incidents majeurs liés aux TIC. Elle constitue le processus structuré d’évaluation permettant de déterminer si un événement observé est qualifié d’incident de sécurité. Elle se rattache également à 8.16, activités de surveillance, parce que les alertes et les données de journalisation doivent être triées, et à 5.26, parce que la classification déclenche la réponse.

C’est ici que de nombreuses organisations échouent en audit. Elles ont des tickets, mais pas d’enregistrements de classification. Elles ont des libellés de gravité, mais pas de critères. Elles ont des rapports réglementaires, mais pas la piste de décision démontrant pourquoi un incident a été considéré, ou non, comme majeur.

Clarysec traite ce point en intégrant la classification DORA dans le modèle de gravité des incidents. Dans la Politique de réponse aux incidents d’entreprise, la clause 5.3.1 inclut un exemple clair de niveau 1 :

Niveau 1 : critique (par exemple, violation de données confirmée, propagation de rançongiciel, compromission d’un système de production)

Pour les petites organisations, la Politique de réponse aux incidents - PME ajoute une exigence opérationnelle stricte :

Le directeur général, avec l’avis du prestataire informatique, doit classifier tous les incidents par gravité dans l’heure suivant la notification.

Cet objectif de classification en une heure est puissant, car il impose une discipline de gouvernance. Une petite entité réglementée peut ne pas disposer d’un SOC 24/7, mais elle peut tout de même définir qui classifie, qui conseille et dans quel délai la décision doit être prise.

Un enregistrement de triage d’incident DORA vers ISO

Pour rendre la classification défendable, créez un enregistrement de triage d’incident DORA dans votre système de gestion des tickets, de GRC ou de gestion des incidents. L’enregistrement doit être créé pour chaque événement TIC potentiellement significatif, même s’il est ultérieurement reclassifié à un niveau inférieur.

Ajoutez une note de décision :

« Compte tenu de la perturbation du service de paiement affectant un processus métier critique, de la cause racine non résolue et de l’impact client potentiel, l’événement est escaladé comme incident majeur potentiel lié aux TIC. La conformité et le juridique doivent apprécier les exigences de notification réglementaire. La conservation des preuves est initiée. »

Cet enregistrement unique soutient le suivi au titre de DORA Article 17, la classification au titre de Article 18, les décisions de signalement au titre de Article 19, l’appréciation ISO/IEC 27001:2022 Annexe A 5.25, le signalement 6.8, la réponse 5.26 et le traitement des preuves 5.28.

Mesures 5.24 et 5.26 : planification, rôles et réponse

Lorsqu’un incident DORA survient, le plan de réponse doit déjà répondre aux questions difficiles.

Qui a l’autorité pour classifier ? Qui contacte l’autorité compétente ? Qui approuve la notification initiale ? Qui communique avec les clients ? Qui contacte le prestataire tiers de services TIC ? Qui décide si l’incident déclenche également une notification GDPR ? Qui conserve les preuves ? Qui est responsable du rapport final ?

La mesure 5.24 de l’Annexe A ISO/IEC 27001:2022, planification et préparation de la gestion des incidents de sécurité de l’information, répond à ces questions avant la crise. La mesure 5.26, réponse aux incidents de sécurité de l’information, garantit que le plan se transforme en actions maîtrisées pendant l’incident.

Dans Zenith Controls, 5.24 est liée aux Articles 17 à 21 de DORA parce qu’elle opérationnalise une réponse aux incidents documentée, testée et revue, incluant l’escalade interne, la notification réglementaire externe, la communication avec les parties prenantes et le retour d’expérience.

ISO/IEC 27035-1:2023 soutient cela en étendant la gestion des incidents au-delà des procédures de réponse, vers la politique, la planification, les capacités, les relations, les mécanismes de support, la sensibilisation, la formation et les tests réguliers. ISO/IEC 27035-2:2023 détaille davantage le processus de gestion des incidents, de la préparation jusqu’au retour d’expérience.

Le Zenith Blueprint, étape 23, donne une instruction directe de mise en œuvre :

Assurez-vous de disposer d’un plan de réponse aux incidents à jour (5.24), couvrant la préparation, l’escalade, la réponse et la communication.

Un plan de réponse aux incidents prêt pour DORA doit définir :

• L’équipe de réponse aux incidents TIC et ses suppléants.
• L’autorité de classification de la gravité et d’escalade du signalement DORA.
• Les responsabilités du juridique, de la conformité, de la protection des données, de la communication, de l’informatique, de la sécurité, des fournisseurs et des propriétaires métier.
• Les critères de classification des incidents majeurs liés aux TIC.
• Les procédures de signalement réglementaire initial, intermédiaire et final.
• L’évaluation des déclencheurs de notification GDPR, NIS2, contractuelle, cyberassurance et conseil d’administration.
• Les étapes de confinement, d’éradication, de rétablissement et de validation.
• Les exigences de conservation des preuves.
• Les procédures d’escalade fournisseur et d’accès aux journaux.
• Le suivi des enseignements tirés et des actions correctives.

La Politique de réponse aux incidents - PME relie également les délais de réponse aux exigences légales :

Les délais de réponse, y compris les obligations de restauration des données et de notification, doivent être documentés et alignés sur les exigences légales, telles que l’exigence GDPR de notification d’une violation de données à caractère personnel dans les 72 heures.

Ce point est essentiel, car un même incident TIC peut devenir un incident majeur DORA, une violation de données à caractère personnel GDPR, un incident significatif NIS2, un événement de notification contractuelle à un client et une question de gestion fournisseur. Le plan doit coordonner ces superpositions au lieu de les traiter comme des univers séparés.

Mesures 8.15 et 8.16 : les journaux rendent le rapport défendable

Le signalement des incidents DORA dépend des faits. Les faits dépendent de la journalisation et de la surveillance.

Dans le scénario du règlement des paiements, Sarah doit savoir quand la dégradation a commencé, quels systèmes ont été affectés, si des comptes à privilèges ont été utilisés, si des données ont quitté l’environnement, si l’interruption du fournisseur cloud concorde avec la télémétrie interne, et quand le rétablissement a été achevé.

La mesure 8.15 de l’Annexe A ISO/IEC 27001:2022, journalisation, et la mesure 8.16, activités de surveillance, soutiennent cette base probatoire. Dans Zenith Controls, toutes deux se rattachent à 5.24 parce que la planification de la réponse aux incidents doit inclure des données de journalisation exploitables et des capacités de surveillance. La mesure 8.16 se rattache également à 5.25 parce que les alertes doivent être triées pour aboutir à des décisions.

La Politique de journalisation et de surveillance - PME [LMP-SME] de Clarysec inclut une exigence pratique d’escalade :

Les alertes de priorité élevée doivent être escaladées vers le DG et le coordinateur de la protection des données dans les 24 heures.

Pour les entités soumises à DORA, les incidents TIC potentiellement majeurs exigent généralement un modèle d’escalade opérationnelle plus rapide, notamment lorsque des fonctions critiques ou importantes sont affectées. Le schéma de gouvernance reste néanmoins correct : les alertes de priorité élevée ne peuvent pas rester cantonnées à l’informatique. Elles doivent atteindre les rôles métier, protection des données et direction.

Un modèle de journalisation prêt pour DORA doit inclure :

• Une journalisation centralisée pour les systèmes critiques, plateformes d’identité, terminaux, services cloud, outils de sécurité réseau et applications métier.
• Une synchronisation temporelle entre systèmes afin que les chronologies d’incident soient fiables.
• Une catégorisation des alertes alignée sur la gravité des incidents et la classification DORA.
• Une conservation des journaux alignée sur les besoins réglementaires, contractuels et forensiques.
• Des contrôles d’accès protégeant l’intégrité des journaux.
• Des procédures de capture d’instantanés de journaux pendant les incidents majeurs.
• Des exigences d’accès aux journaux fournisseur pour les services TIC critiques.

Les auditeurs n’accepteront pas « le SIEM l’a » comme élément probant suffisant. Ils demanderont si les bons journaux existaient, si les alertes ont été revues, si l’escalade a eu lieu à temps et si les journaux ont été conservés une fois l’incident devenu potentiellement notifiable.

Mesure 5.28 : collecte des preuves et chaîne de conservation

Dans un incident majeur lié aux TIC, les preuves servent trois finalités : l’investigation technique, la responsabilité réglementaire et la défendabilité juridique.

Si les preuves sont incomplètes, écrasées, altérées ou non documentées, l’organisation peut avoir des difficultés à démontrer ce qui s’est passé. Elle peut aussi avoir des difficultés à justifier sa décision de classification.

La Politique de collecte des preuves et d’analyse forensique [ECF] de Clarysec précise :

Un journal de chaîne de conservation doit accompagner tout élément de preuve physique ou numérique depuis son acquisition jusqu’à son archivage ou son transfert, et doit documenter :

La version PME, Politique de collecte des preuves et d’analyse forensique - PME [ECF-SME], conserve une exigence simple :

Chaque élément de preuve numérique doit être journalisé avec :

La leçon opérationnelle est directe. Le traitement des preuves ne peut pas commencer après que le juridique les demande. Il doit être intégré à la réponse aux incidents.

ISO/IEC 27006-1:2024 renforce cette attente d’audit en mettant l’accent sur les procédures permettant d’identifier, collecter et conserver les preuves issues des incidents de sécurité de l’information. Pour DORA, le même jeu de preuves peut soutenir la notification initiale, les mises à jour intermédiaires, le rapport final, la revue post-incident et les questions de l’autorité de contrôle.

Une liste de contrôle pratique des preuves pour les incidents liés à DORA doit inclure :

• Le ticket d’incident et les notes de triage.
• La chronologie de la détection, de l’escalade, de la classification, du signalement, du confinement, du rétablissement et de la clôture.
• Les alertes SIEM et les journaux corrélés.
• Les artefacts des terminaux et serveurs.
• Les journaux d’identité et d’accès à privilèges.
• Les synthèses de trafic réseau.
• Les statuts du fournisseur cloud et les journaux d’audit.
• Les communications fournisseur et les déclarations d’incident.
• Les enregistrements d’impact métier, y compris clients, services, transactions et indisponibilité.
• Les projets et dépôts de notification réglementaire.
• Les décisions et approbations de la direction.
• L’analyse de la cause racine.
• Les enseignements tirés et les actions correctives.

Les preuves doivent montrer à la fois les faits techniques et les décisions de gouvernance. Le signalement DORA ne porte pas seulement sur ce qui est arrivé aux systèmes. Il porte aussi sur la manière dont la direction a reconnu, évalué, escaladé, maîtrisé l’incident et amélioré le dispositif à la suite de celui-ci.

Mesure 5.27 : enseignements tirés et amélioration continue

Un incident DORA n’est pas clos lorsque le rapport final est soumis. Il est clos lorsque l’organisation en a tiré les enseignements, attribué les actions correctives, mis à jour les contrôles et vérifié l’amélioration.

La mesure 5.27 de l’Annexe A ISO/IEC 27001:2022, retour d’expérience sur les incidents de sécurité de l’information, relie le signalement DORA au cycle d’amélioration continue ISO/IEC 27001:2022. Dans Zenith Controls, 5.24 est liée à 5.27 parce que la gestion des incidents est incomplète sans analyse de la cause racine, enseignements tirés et amélioration des contrôles.

Le Zenith Blueprint, étape 23, demande aux organisations de mettre à jour le plan avec les enseignements tirés et de fournir une formation ciblée sur la réponse aux incidents et le traitement des preuves. C’est particulièrement important pour DORA, car des retards récurrents de classification, des preuves fournisseur manquantes, des journaux insuffisants ou des communications peu claires peuvent devenir des préoccupations pour l’autorité de contrôle.

Un modèle de retour d’expérience doit consigner :

• Ce qui s’est passé et quand.
• Quelles fonctions critiques ou importantes ont été affectées.
• Si la classification a été effectuée en temps utile et avec exactitude.
• Si les décisions de signalement DORA ont été prises avec des éléments probants suffisants.
• Si les déclencheurs de notification GDPR, NIS2, contractuels ou client ont été évalués.
• Si les fournisseurs ont répondu dans les délais convenus.
• Si les journaux et les preuves forensiques ont été conservés.
• Quels contrôles ont échoué ou manquaient.
• Quelles politiques, procédures opérationnelles, formations ou mesures techniques doivent être améliorées.
• Qui est responsable de chaque action corrective et pour quelle échéance.

Cela alimente également la revue de direction ISO/IEC 27001:2022. Les tendances des incidents doivent être revues par la direction, et non enfouies dans des retours d’expérience techniques.

Conformité croisée : DORA, GDPR, NIS2, NIST et COBIT 2019

DORA est le sujet central pour les entités financières, mais le signalement des incidents relève rarement d’un seul référentiel.

Un même incident TIC peut impliquer le signalement d’un incident majeur lié aux TIC au titre de DORA, la notification d’une violation de données à caractère personnel au titre de GDPR, le signalement d’un incident significatif NIS2, des obligations contractuelles client, une notification à la cyberassurance et une information du conseil d’administration.

Zenith Controls aide à réduire cette complexité en mettant en correspondance les mesures ISO/IEC 27002:2022 entre référentiels. Par exemple :

Du point de vue de NIST, le même modèle soutient les résultats Detect, Respond et Recover. Du point de vue de COBIT 2019 et de l’audit ISACA, l’enjeu est la gouvernance : déterminer si la gestion des incidents, la continuité, le risque, la conformité, les responsabilités fournisseurs et la surveillance de la performance sont maîtrisés.

Les organisations les plus matures ne créent pas de processus séparés pour chaque référentiel. Elles créent un processus unique de gestion des incidents avec des couches réglementaires. Le ticket saisit une seule fois les mêmes faits essentiels, puis les décline vers DORA, GDPR, NIS2, contractuel, assurance ou signalement sectoriel lorsque nécessaire.

Comment les auditeurs testeront votre processus d’incident DORA

Un processus de signalement des incidents prêt pour DORA doit résister à plusieurs angles d’audit.

Un auditeur ISO/IEC 27001:2022 examinera si le SMSI a sélectionné et mis en œuvre les mesures pertinentes de l’Annexe A, si la Déclaration d’applicabilité soutient ces mesures, si des enregistrements d’incident existent, et si l’audit interne et la revue de direction incluent la performance du processus incident.

Zenith Controls cite la méthodologie d’audit ISO/IEC 19011:2018 pour 5.24, 5.25 et 6.8. Pour 5.24, les auditeurs examinent le plan de réponse aux incidents pour les types d’incidents, les classifications de gravité, les rôles attribués, les listes de contacts, les circuits d’escalade, les instructions de signalement réglementaire et les responsabilités de communication. Pour 5.25, ils examinent si des critères de classification documentés existent, par exemple des matrices de gravité ou des arbres de décision fondés sur l’impact système, la sensibilité des données et la durée. Pour 6.8, ils évaluent les mécanismes de signalement, les indicateurs de délai de signalement et les éléments probants montrant que les événements signalés sont journalisés, triés et résolus.

Une revue de supervision DORA se concentrera sur la question de savoir si les incidents majeurs liés aux TIC sont détectés, classifiés, signalés, mis à jour et clôturés conformément aux attentes réglementaires. Le réviseur peut demander un échantillon d’incident et le retracer depuis la première alerte jusqu’au rapport final.

Un auditeur protection des données se concentrera sur l’évaluation du risque de violation de données à caractère personnel et sur le déclenchement éventuel des obligations GDPR Article 33 et Article 34. BS EN 17926:2023 est pertinente ici parce qu’elle ajoute des responsabilités relatives aux incidents de protection des données, des critères de notification, des délais et un alignement sur les attentes de divulgation aux autorités de contrôle.

Les mêmes éléments probants peuvent répondre à plusieurs questions d’audit s’ils sont structurés correctement dès le départ.

Liste de contrôle de préparation au signalement des incidents DORA pour 2026

Avant votre prochain exercice sur table, audit interne ou revue de supervision, testez votre organisation avec cette liste de contrôle :

• Les employés savent-ils comment signaler les incidents TIC suspectés ?
• Existe-t-il un canal dédié de signalement des incidents ?
• Les événements de sécurité sont-ils journalisés et triés de manière cohérente ?
• Existe-t-il une matrice documentée de gravité et de classification des incidents majeurs DORA ?
• La classification est-elle exigée dans un délai défini après notification ?
• Les fonctions critiques ou importantes sont-elles mises en correspondance avec les systèmes et les fournisseurs ?
• Les déclencheurs de notification DORA, GDPR, NIS2, contractuels, assurance et client sont-ils évalués dans un même processus ?
• Les rôles relatifs aux incidents sont-ils définis entre informatique, sécurité, juridique, conformité, protection des données, communication et propriétaires métier ?
• Les journaux sont-ils suffisants pour reconstituer les chronologies d’incident ?
• Les preuves sont-elles conservées avec une chaîne de conservation ?
• Les obligations fournisseur relatives aux incidents et les droits d’accès aux journaux sont-ils testés ?
• Des exercices sur table sont-ils réalisés avec des scénarios DORA réalistes ?
• Les enseignements tirés sont-ils suivis jusqu’aux actions correctives ?
• Les indicateurs d’incident sont-ils revus en revue de direction ?
• La Déclaration d’applicabilité est-elle mise en correspondance avec les mesures ISO/IEC 27001:2022 pertinentes pour DORA ?

Si la réponse à l’un de ces points est « partiellement », le problème n’est pas seulement un problème de conformité. C’est un problème de résilience opérationnelle.

Construire un modèle de signalement des incidents DORA prêt à produire des éléments probants

Le signalement des incidents DORA en 2026 est un test de gouvernance sous pression. Les organisations performantes ne seront pas celles qui possèdent les documents de réponse aux incidents les plus longs. Ce seront celles qui disposent de canaux de signalement clairs, d’une classification rapide, de journaux fiables, de preuves conservées, de personnes formées, d’une escalade fournisseur testée et d’une traçabilité entre référentiels.

Clarysec peut vous aider à construire ce modèle opérationnel.

Commencez par mettre en correspondance vos risques d’incident et votre Déclaration d’applicabilité avec le Zenith Blueprint : feuille de route en 30 étapes pour auditeurs. Alignez ensuite vos mesures relatives aux incidents avec Zenith Controls : guide de conformité croisée. Opérationnalisez le processus avec la Politique de réponse aux incidents, la Politique de réponse aux incidents - PME, la Politique de journalisation et de surveillance - PME, la Politique de collecte des preuves et d’analyse forensique et la Politique de collecte des preuves et d’analyse forensique - PME de Clarysec.

Si votre équipe de direction veut être rassurée avant le prochain incident réel, organisez avec le kit Clarysec un exercice sur table portant sur un incident majeur lié aux TIC au titre de DORA et produisez le dossier d’éléments probants qu’un auditeur ou une autorité de contrôle s’attendrait à voir.