Classification de la gravité des incidents pour DORA, NIS2 et GDPR

L’appel d’incident de 02 h 17 qui devient une décision réglementaire

À 02 h 17, un jeudi matin, Sarah, RSSI de FinScale, voit apparaître la première alerte : trafic API anormal, pics d’échecs d’authentification et latence du tableau de bord des paiements supérieure à 3 000 ms. En quelques minutes, le support client signale des erreurs de statut de paiement. Le fournisseur cloud indique qu’aucun incident généralisé n’affecte sa plateforme. Le SOC observe des jetons d’accès suspects provenant de deux zones géographiques. L’équipe produit confirme que le tableau de bord est de nouveau en ligne après 19 minutes, mais douze clients ont déjà ouvert des tickets.

À 03 h 05, Sarah rejoint la cellule de crise avec le responsable de gestion d’incident, le service juridique, le délégué à la protection des données, le responsable des opérations cloud et le sponsor de direction. La question technique est assez claire : que s’est-il passé sur la passerelle API ? Les questions réglementaires sont plus difficiles :

1. S’agit-il d’un incident majeur lié aux TIC au sens de DORA ?
2. S’agit-il d’un incident significatif au sens de NIS2 ?
3. Existe-t-il une violation de données à caractère personnel au sens du GDPR nécessitant une notification ?
4. L’organisation peut-elle démontrer comment elle est parvenue à ces réponses ?

Une mauvaise réponse peut créer une exposition réglementaire. Une réponse trop lente peut faire manquer une fenêtre de notification. Une réponse non documentée peut échouer lors d’un audit ISO/IEC 27001:2022 plusieurs mois plus tard.

C’est le défi de la réponse aux incidents en 2026. De nombreuses organisations disposent d’un plan de réponse aux incidents, de procédures forensiques, de playbooks de protection des données et de modèles de communication de crise. Moins nombreuses sont celles qui disposent d’un modèle défendable de classification de la gravité des incidents, capable de transformer un événement de sécurité bruité en décision documentée au regard des attentes de DORA, NIS2, GDPR et ISO/IEC 27001:2022 en matière d’éléments de preuve.

La solution ne consiste pas à mettre en place trois processus de triage distincts. Elle consiste à disposer d’un modèle de gravité gouverné, assorti de volets réglementaires distincts, de seuils mesurables, de règles d’escalade, de journaux de décision et d’exigences de collecte des éléments de preuve. En pratique, la gravité d’un incident ne doit pas être une étiquette choisie sous pression. Elle doit être une décision métier maîtrisée, capable de résister à l’examen des autorités de régulation, des auditeurs, des membres du conseil d’administration, des clients et du DPO.

Pourquoi la classification de la gravité des incidents est désormais un contrôle au niveau du conseil d’administration

La classification des incidents était auparavant principalement technique : gravité du logiciel malveillant, hôtes affectés, vulnérabilités exploitées et éventuelle exfiltration de données. En 2026, elle est aussi juridique, financière, sociétale et contractuelle.

DORA fait de la résilience opérationnelle numérique une obligation de gouvernance pour les entités financières. L’organe de direction doit définir, approuver, superviser et assumer la responsabilité du cadre de gestion des risques liés aux TIC. Cela inclut la continuité d’activité TIC, les plans de réponse et de rétablissement, les canaux de notification des incidents majeurs, le risque lié aux prestataires tiers TIC et les enseignements tirés.

NIS2 élève les enjeux de gouvernance pour les entités essentielles et importantes. Article 20 impose aux organes de direction d’approuver les mesures de gestion des risques de cybersécurité, d’en superviser la mise en œuvre et de suivre une formation. Il relie également les défaillances de gestion des risques et de notification des incidents à des conséquences significatives en matière de supervision. Pour les entités essentielles, les plafonds de référence des amendes administratives peuvent atteindre au moins 10 000 000 EUR ou 2 % du chiffre d’affaires annuel mondial total, le montant le plus élevé étant retenu. Pour les entités importantes, le seuil de référence est d’au moins 7 000 000 EUR ou 1,4 % du chiffre d’affaires, le montant le plus élevé étant retenu.

GDPR ajoute un angle différent. Une violation de données à caractère personnel ne se limite pas à une divulgation publique confirmée ou à des fichiers volés. Elle inclut la destruction, la perte, l’altération, la divulgation non autorisée ou l’accès non autorisé à des données à caractère personnel, de manière accidentelle ou illicite. Les responsables du traitement doivent évaluer le risque pour les personnes concernées et démontrer leur responsabilité dans la décision de notifier ou de ne pas notifier.

ISO/IEC 27001:2022 fournit à ces obligations une ossature probatoire. Les clauses 4.1 à 4.4 exigent que l’organisation comprenne son contexte, les exigences des parties intéressées, son périmètre, ses interfaces et ses dépendances. Les clauses 5.1 à 5.3 exigent l’engagement de la direction, une politique, des rôles, des responsabilités et des modalités de reporting. Les clauses 6.1.1 à 6.1.3 exigent une planification fondée sur les risques, une appréciation des risques, un traitement des risques et une Déclaration d’applicabilité (SoA). Les clauses 8.1 à 8.3 exigent la maîtrise opérationnelle, la maîtrise des changements, la conservation des éléments de preuve et la réévaluation lorsque les conditions de risque changent. ISO/IEC 27001:2022

Lorsque l’appel d’incident survient, la question ne devrait pas être : « Qui pense que c’est critique ? » Elle devrait être : « Que nous imposent maintenant nos critères approuvés, nos déclencheurs juridiques, nos éléments de preuve et nos règles d’escalade ? »

Un événement, trois systèmes de classification réglementaire

DORA, NIS2 et GDPR n’utilisent pas le même langage pour les incidents. C’est la raison principale pour laquelle les organisations peinent pendant la première heure.

DORA Article 17 impose aux entités financières d’établir un processus de gestion des incidents liés aux TIC permettant de détecter, gérer et notifier les incidents liés aux TIC, d’enregistrer les incidents liés aux TIC et les cybermenaces significatives, de traiter les causes racines, d’utiliser des indicateurs d’alerte précoce, de catégoriser et classifier les incidents, d’attribuer les rôles, de gérer les communications, d’escalader les incidents majeurs à la direction générale et de rétablir des opérations sécurisées.

DORA Article 18 exige une classification selon des critères tels que les clients affectés, les contreparties affectées, les transactions, la durée, le temps d’indisponibilité, l’étendue géographique, la perte de données affectant la disponibilité, l’authenticité, l’intégrité ou la confidentialité, la criticité des services affectés et l’impact économique. DORA Article 19 exige la notification des incidents majeurs liés aux TIC et la communication aux clients lorsque leurs intérêts financiers sont affectés.

NIS2 Article 23 définit un incident significatif comme un incident ayant causé ou susceptible de causer une perturbation opérationnelle grave ou une perte financière, ou ayant affecté ou susceptible d’affecter des tiers en causant un dommage matériel ou immatériel considérable. Il exige un avertissement précoce dans les 24 heures suivant la prise de connaissance de l’incident significatif, une notification d’incident dans les 72 heures, des rapports intermédiaires sur demande et un rapport final dans le mois suivant la notification d’incident. Le cas échéant, les destinataires de services affectés doivent également être informés des mesures ou remèdes qu’ils peuvent prendre.

GDPR pose une question de risque pour la vie privée. Une violation de sécurité a-t-elle entraîné la destruction, la perte, l’altération, la divulgation non autorisée ou l’accès non autorisé à des données à caractère personnel ? Si oui, le responsable du traitement doit évaluer le risque pour les droits et libertés des personnes physiques. Si la violation est susceptible d’engendrer un risque, l’autorité de contrôle doit généralement être notifiée dans les 72 heures suivant la prise de connaissance. Si elle est susceptible d’engendrer un risque élevé, les personnes concernées peuvent devoir être informées dans les meilleurs délais.

Un même incident nécessite donc une classification simultanée.

Pour les entités financières, DORA constitue l’acte juridique sectoriel de l’Union relatif à la gestion des risques TIC et aux obligations de notification des incidents qui recoupent NIS2. Cela ne rend pas NIS2 sans objet. Elle peut encore compter pour la coopération, les flux d’information, les services hors du périmètre DORA, les entités non financières du groupe, les services cloud, les services managés et les obligations contractuelles envers les clients. Le modèle de gravité doit consigner non seulement le résultat, mais aussi la logique d’applicabilité.

Le modèle Clarysec : classifier l’événement, pas l’émotion

Clarysec part du contrôle ISO/IEC 27002:2022 5.25, appréciation et décision concernant les événements de sécurité de l’information, comme point d’ancrage transverse de conformité. Dans Zenith Controls: The Cross-Compliance Guide Zenith Controls, ce sujet est cartographié au moyen de l’entrée « Appréciation et décision concernant les événements de sécurité de l’information » pour le contrôle 5.25, soutenue par « Planification et préparation de la gestion des incidents de sécurité de l’information » pour le contrôle 5.24 et « Collecte des éléments de preuve » pour le contrôle 5.28.

Le moment de conformité le plus important n’est souvent pas le confinement. C’est la bifurcation où un événement de sécurité devient un incident réglementaire, ou bien est enregistré de façon défendable comme événement de gravité inférieure.

Le Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec Zenith Blueprint décrit ce moment dans la phase Controls in Action, Step 23 :

« Toutes les anomalies ne sont pas des catastrophes. Toutes les alertes ne signalent pas une compromission. Dans le monde réel, les équipes de sécurité et les unités métier sont submergées par le bruit : tentatives de connexion, anomalies de journaux, manquements mineurs aux politiques, activités de shadow IT. Le véritable défi ne réside pas seulement dans la détection, mais dans la capacité à distinguer l’inoffensif du dangereux et à savoir ce qui exige une escalade. »

Cette phrase résume le problème opérationnel. Une alerte SIEM n’équivaut pas automatiquement à un incident majeur DORA. Une indisponibilité temporaire n’équivaut pas automatiquement à un incident significatif NIS2. Une requête suspecte sur une base de données n’équivaut pas automatiquement à une notification obligatoire au titre du GDPR. Chacun de ces événements peut devenir notifiable selon l’impact, le périmètre, les données, les parties affectées et les éléments de preuve.

Le Zenith Blueprint, phase Gestion des risques, Step 10, recommande également d’adapter les définitions d’impact à l’échelle de l’activité et à l’exposition réglementaire :

« Lorsque vous définissez l’impact, il est judicieux de relier les niveaux à votre propre échelle d’activité. Par exemple, “Impact financier majeur = perte > 100 k$” (à ajuster selon votre contexte). Tenez également compte de l’impact réglementaire : par exemple, une violation de données à caractère personnel peut être automatiquement “Majeure” ou “Grave” en raison des amendes et exigences de notification du GDPR, même si la perte financière directe n’est pas claire. »

C’est le principe de conception de la classification de la gravité des incidents en 2026 : la gravité correspond à l’impact métier, plus l’impact juridique, plus le niveau de confiance dans les éléments de preuve.

Une taxonomie pratique de gravité des incidents pour DORA, NIS2 et GDPR

Une taxonomie défendable doit séparer la gravité interne de la classification réglementaire. La gravité interne pilote l’urgence de réponse, l’allocation des ressources et l’escalade vers la direction. La classification réglementaire pilote la notification, la revue juridique et la communication externe.

Le niveau de gravité interne n’est pas la réponse réglementaire finale. C’est le mode opératoire. Un événement SEV 3 peut devenir notifiable au titre du GDPR après revue des journaux. Une interruption SEV 2 peut ne pas constituer un incident majeur DORA si les seuils d’impact ne sont pas atteints. Un incident de rançongiciel SEV 1 peut déclencher simultanément DORA, NIS2, GDPR, des contrats clients et une coordination avec les autorités répressives compétentes.

Une matrice de classification plus détaillée aide l’équipe à passer de l’alerte à l’action.

Le modèle doit être intégré dans la politique, plutôt que laissé à la voix la plus forte sur le pont de crise. La politique PME Politique de réponse aux incidents-sme Politique de réponse aux incidents-sme - PME, Exigences de gouvernance, clause 5.3.1, indique :

« Le Directeur général, avec l’appui du prestataire informatique, doit classifier tous les incidents par gravité dans l’heure suivant leur notification. »

La même politique PME, Traitement des risques et exceptions, clause 7.4.1, ajoute :

« Lorsque des données clients sont concernées, le Directeur général doit évaluer les obligations légales de notification selon l’applicabilité du GDPR, de NIS2 ou de DORA. »

Pour les organisations plus grandes, la Politique de réponse aux incidents d’entreprise Politique de réponse aux incidents, Exigences de gouvernance, clause 5.3, formalise le même concept :

« La classification des incidents doit suivre un modèle à plusieurs niveaux : »

Le langage de la politique est important, car les autorités de régulation et les auditeurs demanderont si les critères de classification existaient avant l’incident. Une matrice inventée après coup constitue un élément de preuve faible. Une matrice approuvée, enseignée, exercée et utilisée de manière cohérente est défendable.

Le journal de décision : le livrable probatoire le plus important

Lorsque des auditeurs, des autorités de régulation ou des membres du conseil d’administration examinent un incident, ils ne demandent que rarement : « Que s’est-il passé ? » Ils demandent : « Quand l’avez-vous su, qui a décidé, sur la base de quels éléments de preuve, et pourquoi n’avez-vous pas notifié plus tôt ? »

C’est pourquoi Clarysec recommande un journal de décision sur la gravité pour chaque événement SEV 3 et supérieur, ainsi que pour tout événement impliquant des données à caractère personnel, des services critiques, des clients financiers, des services managés, une infrastructure cloud ou un impact transfrontalier.

Cela se rattache directement à ISO/IEC 27001:2022. La clause 8.1 exige que les processus soient planifiés, mis en œuvre et maîtrisés, avec des informations documentées suffisantes conservées pour montrer qu’ils ont fonctionné comme prévu. Les clauses 8.2 et 8.3 exigent une réévaluation lorsque des changements significatifs surviennent, ainsi que la conservation des éléments de preuve du traitement des risques. Les contrôles de l’Annexe A, de A.5.24 à A.5.28, constituent l’ossature de la gestion des incidents : planification et préparation, appréciation et décision sur les événements, réponse, enseignements tirés des incidents et collecte des éléments de preuve.

La politique PME Politique de protection des données et de la vie privée-sme Politique de protection des données et de la vie privée-sme - PME, Application et conformité, clause 8.3.2, soutient le volet GDPR du modèle :

« Le Coordinateur Protection des données déterminera la gravité, initiera les actions de confinement et documentera le dossier. »

L’évaluation Protection des données ne doit pas commencer lorsque l’horloge réglementaire devient inconfortable. Elle doit être intégrée au processus de triage.

Exemple pratique : classifier l’incident API de Sarah

Revenons à FinScale. Il s’agit d’une plateforme fintech B2B utilisant une infrastructure cloud, un fournisseur externe d’analyse de fraude et un prestataire de sécurité managée. Elle est une entité financière couverte par DORA pour certaines activités. Elle est également un fournisseur de services numériques exerçant des opérations pertinentes au titre de NIS2 dans un État membre. Elle traite des données à caractère personnel de clients en tant que responsable du traitement pour les services de compte et en tant que sous-traitant pour certains clients entreprises.

À 02 h 17, un trafic API anormal est détecté. À 02 h 35, le ticket d’incident est ouvert. À 03 h 00, Sarah termine le triage initial avec le responsable de gestion d’incident.

Premièrement, la gravité interne est fixée. L’incident a affecté la disponibilité du tableau de bord client pendant 19 minutes, impliqué des jetons d’accès suspects et touché une fonction critique orientée client. Il est classé SEV 3 Modéré dans l’attente de confirmation, avec escalade au responsable de gestion d’incident, au délégué à la protection des données, au service juridique et au responsable de service.

Deuxièmement, l’analyse DORA est réalisée. L’équipe vérifie les clients affectés, les contreparties, les transactions, la durée, le temps d’indisponibilité, l’étendue géographique, la perte de données, la criticité et l’impact économique. Aucune transaction échouée ou altérée n’est confirmée. Le temps d’indisponibilité est limité. Aucune perte de données n’est démontrée. Toutefois, comme un composant critique de service financier et les intérêts financiers des clients peuvent être affectés, l’incident reste sous surveillance DORA et peut être reclassé.

Troisièmement, l’analyse NIS2 est enregistrée. L’équipe note que DORA constitue le régime sectoriel principal de notification pour les obligations de l’entité financière couverte. Elle vérifie également si l’incident affecte des services ou des clients hors du périmètre DORA. À ce stade, aucune perturbation opérationnelle grave ni aucun dommage considérable n’est confirmé.

Quatrièmement, l’analyse GDPR est lancée. Les jetons suspects peuvent avoir permis l’accès aux données du tableau de bord client. Le délégué à la protection des données documente les catégories de données, les utilisateurs affectés, le périmètre des jetons, les journaux examinés, si des données ont été consultées ou exportées, ainsi que les mesures de protection telles que l’expiration des jetons et les contrôles d’accès.

À 04 h 20, l’analyse des journaux montre que deux jetons ont été utilisés pour accéder aux métadonnées du tableau de bord de 41 clients, notamment les noms, les identifiants de compte et le statut des transactions, mais pas les identifiants de paiement ni les documents d’identité. L’équipe met à jour l’incident en SEV 2 Majeur, car la confidentialité des données à caractère personnel a été affectée et une communication client peut être requise. Le DPO évalue le risque GDPR pour les personnes concernées. La décision DORA est réexaminée au regard de l’impact client, de l’impact transactionnel et de l’impact économique.

C’est la valeur pratique du modèle. La classification initiale n’est pas une conclusion juridique définitive. C’est une décision fondée sur les éléments de preuve, qui peut être mise à jour à mesure que les faits se précisent.

Journalisation, surveillance et éléments de preuve forensiques : la couche probatoire

Un modèle de gravité sans éléments de preuve n’est qu’une opinion de réunion. En 2026, il est attendu que la classification soit étayée par des journaux, de la surveillance, des artefacts probants préservés et une chaîne de conservation.

La politique PME Politique de journalisation et de surveillance-sme Politique de journalisation et de surveillance-sme - PME, Application et conformité, clause 8.3.4, indique :

« Les investigations relatives aux violations doivent s’appuyer sur des journaux adéquats afin de respecter le principe de responsabilité prévu par le GDPR et DORA. »

La gestion forensique est tout aussi importante. La politique PME Politique de collecte des éléments de preuve et d’investigation forensique-sme Politique de collecte des éléments de preuve et d’investigation forensique-sme - PME, Exigences de gouvernance, clause 5.3.1, exige :

« Un journal simple de chaîne de conservation (par exemple, fichier Excel ou modèle de document) doit être tenu pour chaque incident. »

Pour les environnements d’entreprise, la Politique de collecte des éléments de preuve et d’investigation forensique Politique de collecte des éléments de preuve et d’investigation forensique, Exigences de gouvernance, clause 5.5, exige :

« Tous les éléments de preuve collectés doivent être identifiés de manière unique, étiquetés et stockés dans un référentiel sécurisé avec : »

Le Zenith Blueprint, phase Controls in Action, Step 23, explique pourquoi cela compte pour le contrôle ISO/IEC 27002:2022 5.28 :

« Lorsqu’un incident de sécurité de l’information survient, l’un des éléments les plus critiques de la réponse, et pourtant souvent négligé, est la preuve. Pas des journaux, pas des captures d’écran, pas des récits dispersés, mais des éléments de preuve correctement préservés, respectant la chaîne de conservation et protégés contre les altérations. »

Un dossier probatoire pratique pour un incident majeur ou potentiellement notifiable doit inclure :

• Le ticket d’incident et la chronologie
• Le journal de décision sur la gravité et l’historique des reclassifications
• Les alertes SIEM, les alertes EDR, les journaux cloud et les journaux d’identité
• Les journaux d’accès aux données et les journaux d’export
• Les entrées d’inventaire des actifs et services affectés
• L’évaluation de l’impact sur les clients, les transactions et les zones géographiques
• La fiche d’analyse DORA, NIS2 et GDPR
• L’évaluation DPO ou juridique
• Les validations de communication et les messages envoyés
• L’enregistrement de chaîne de conservation
• L’analyse de la cause racine
• Les actions correctives et les enseignements tirés

Ce dossier probatoire soutient également les contrôles de l’Annexe A d’ISO/IEC 27001:2022 : A.8.15 journalisation, A.8.16 activités de surveillance, A.5.28 collecte des éléments de preuve, A.5.27 enseignements tirés des incidents de sécurité de l’information, A.5.31 exigences légales, statutaires, réglementaires et contractuelles, et A.5.34 protection de la vie privée et des informations personnellement identifiables (PII).

Cartographie de conformité croisée : construire une fois, répondre à plusieurs auditeurs

Les modèles de gravité des incidents les plus solides sont construits une fois et cartographiés plusieurs fois. Zenith Controls est conçu comme une boussole de conformité croisée pour ce travail. Pour ce sujet, les entrées essentielles d’ISO/IEC 27002:2022 sont 5.24 planification et préparation de la gestion des incidents de sécurité de l’information, 5.25 appréciation et décision concernant les événements de sécurité de l’information, 5.26 réponse aux incidents de sécurité de l’information, 5.27 enseignements tirés des incidents de sécurité de l’information et 5.28 collecte des éléments de preuve.

Ces contrôles s’articulent naturellement avec le système de management ISO/IEC 27001:2022. Les clauses 4, 5, 6 et 8 définissent le périmètre, le leadership, les critères de risque, le traitement et les éléments de preuve opérationnels. ISO/IEC 27002:2022 fournit le langage de mise en œuvre des contrôles. La logique de continuité d’activité de type ISO 22301 soutient les seuils de perturbation, les priorités de rétablissement et la gestion de crise. Les pratiques de gestion des incidents de type ISO/IEC 27035 soutiennent la détection, le reporting, l’évaluation, la réponse et l’apprentissage structurés. La gouvernance de la protection des données de type ISO/IEC 27701 soutient les rôles liés aux violations de données à caractère personnel, les considérations relatives au responsable du traitement et au sous-traitant, les éléments de preuve liés à la vie privée et la responsabilité.

Le même modèle se rattache au NIST Cybersecurity Framework 2.0. La fonction GOVERN exige que les obligations légales, réglementaires, contractuelles, de protection de la vie privée et relatives aux libertés civiles soient comprises et gérées. Elle attend également que l’appétence au risque, les rôles, les autorités, les politiques et la supervision soient définis. Les fonctions DETECT, RESPOND et RECOVER soutiennent le triage, l’analyse, l’escalade, le confinement, la restauration, les communications et l’amélioration.

Le bénéfice est concret. Lorsqu’un superviseur DORA demande la justification d’un incident majeur lié aux TIC, qu’une autorité NIS2 interroge la décision d’avertissement précoce sous 24 heures, qu’une autorité de contrôle demande pourquoi une notification GDPR a été ou non effectuée, et qu’un auditeur ISO demande si le SMSI a fonctionné comme prévu, l’organisation peut répondre à partir du même ensemble d’éléments de preuve.

Comment les auditeurs et les autorités de régulation testeront votre modèle

Un auditeur ISO/IEC 27001:2022 commence généralement par le périmètre et les exigences légales. Il demandera si DORA, NIS2, GDPR, les contrats clients et les obligations liées aux prestataires tiers TIC ont été identifiés comme exigences des parties intéressées. Il suivra ensuite la piste vers les critères de risque, la Déclaration d’applicabilité (SoA), les procédures de gestion des incidents, les enregistrements opérationnels et la conservation des éléments de preuve. Il attend la preuve que le processus de classification n’a pas été inventé pendant l’incident.

Un superviseur DORA ou une équipe d’audit interne recherchera une boucle de cycle de vie : processus de gestion des incidents, indicateurs d’alerte précoce, critères de classification, escalade des incidents majeurs, communication aux clients, cause racine, chiffres d’impact finaux, tests de résilience et supervision par l’organe de direction. Il demandera également si les dépendances envers des prestataires tiers TIC ont été prises en compte, en particulier lorsque des fournisseurs cloud, SaaS, de sécurité managée ou d’externalisation ont été impliqués.

Un auditeur ou une autorité focalisé sur NIS2 vérifiera si l’entité peut identifier les incidents significatifs, respecter les délais par étapes, communiquer avec les destinataires de services affectés et fournir les éléments de preuve de l’évaluation de l’impact transfrontalier. Il reliera la gestion des incidents aux mesures de gestion des risques de Article 21, notamment la continuité d’activité, la gestion de crise, la sécurité de la chaîne d’approvisionnement, le contrôle d’accès, la gestion des actifs et la formation.

Un DPO GDPR ou une autorité de contrôle examinera si l’organisation a identifié les données à caractère personnel, les rôles, les personnes concernées, les catégories, les systèmes affectés, le type de violation et le risque pour les personnes concernées. Il vérifiera si le responsable du traitement peut démontrer sa responsabilité et si les notifications des sous-traitants aux responsables du traitement ont été réalisées en temps utile et de manière complète.

Un auditeur de type ISACA ou COBIT 2019 se concentrera sur les éléments de preuve de gouvernance. Qui a approuvé la taxonomie de gravité ? Qui est propriétaire du risque ? Quelles métriques sont communiquées à la direction ? Comment les exceptions sont-elles gérées ? Comment les enseignements tirés sont-ils convertis en améliorations des contrôles ?

Schémas de défaillance courants dans la classification des incidents

Le premier échec est la pensée à étiquette unique. Les équipes classent un événement en élevé, moyen ou faible, mais n’évaluent jamais séparément les déclencheurs DORA, NIS2 et GDPR. Le résultat est une étiquette de gravité incapable d’expliquer une décision de notification.

Le deuxième échec est le biais de la violation confirmée. Les équipes attendent une preuve absolue d’exfiltration avant d’impliquer la fonction Protection des données ou le service juridique. L’évaluation d’une violation au titre du GDPR commence souvent par un accès, une perte, une altération ou une divulgation non autorisée possible, et non seulement par une publication confirmée de données.

Le troisième échec est la confusion sur les horloges. Les délais NIS2 et GDPR dépendent de la prise de connaissance et de l’évaluation. Si le ticket d’incident ne capture pas l’heure de prise de connaissance, l’heure de classification et l’heure d’escalade, l’organisation peut avoir des difficultés à démontrer le respect des délais.

Le quatrième échec est la forensique après nettoyage. Les ingénieurs effectuent une rotation des clés, reconstruisent les hôtes et suppriment des éléments de preuve temporaires avant que la posture d’investigation ne soit déclenchée. Cela peut détruire les preuves nécessaires à la revue réglementaire, contractuelle ou juridique.

Le cinquième échec est l’angle mort fournisseurs. DORA, NIS2 et NIST CSF 2.0 mettent tous l’accent sur les risques liés aux tiers et à la chaîne d’approvisionnement. Si un fournisseur cloud, un prestataire de services managés, un processeur de paiement, un fournisseur d’identité ou un fournisseur SaaS fait partie de la chaîne d’incident, le modèle de classification doit intégrer l’impact fournisseur et les obligations contractuelles de notification.

Une checklist de mise en œuvre Clarysec pour 2026

Pour opérationnaliser un modèle défendable de classification de la gravité des incidents, Clarysec recommande la séquence suivante :

1. Confirmer l’applicabilité réglementaire au regard de DORA, NIS2, GDPR, des contrats clients et des règles sectorielles.
2. Mettre à jour le périmètre du SMSI et les exigences des parties intéressées au titre d’ISO/IEC 27001:2022.
3. Définir les niveaux de gravité internes avec des seuils mesurables pour le temps d’indisponibilité, les données, les clients, la géographie, la perte financière et la criticité.
4. Ajouter des questions d’analyse DORA, NIS2 et GDPR distinctes au processus de ticket d’incident.
5. Définir les déclencheurs d’escalade pour le responsable de gestion d’incident, le DPO, le service juridique, la direction générale et le conseil d’administration.
6. Créer un modèle de journal de décision sur la gravité.
7. Relier la classification aux procédures de collecte des éléments de preuve et de chaîne de conservation.
8. Valider la couverture de journalisation pour les événements d’identité, cloud, applicatifs, bases de données, réseau et fournisseurs.
9. Réaliser des exercices sur table pour les scénarios d’incident majeur DORA, d’incident significatif NIS2 et de violation GDPR.
10. Alimenter le traitement des risques, la Déclaration d’applicabilité (SoA), la formation et les tests de résilience avec les enseignements tirés.

Le Zenith Blueprint, phase Controls in Action, Step 16, renforce la dimension humaine de ce modèle : les signalements doivent être journalisés, triés, escaladés via le plan de réponse aux incidents, et même les événements mineurs doivent être suivis, car les tendances révèlent des faiblesses de contrôle. Il promeut une culture de signalement à seuil bas : « En cas de doute, signalez. »

Ce point culturel est essentiel. Un modèle de gravité échoue si les employés retardent le signalement par crainte d’une réaction excessive. L’objectif est un signalement rapide, un triage discipliné et une classification défendable.

Transformer l’incertitude liée aux incidents en éléments de preuve prêts pour l’audit

En 2026, la classification de la gravité des incidents n’est plus une décision relevant uniquement du SOC. C’est un processus de gouvernance réglementé qui doit relier les critères d’incident majeur lié aux TIC de DORA, les seuils d’incident significatif de NIS2, le risque de violation au titre du GDPR et les éléments de preuve ISO/IEC 27001:2022.

Les organisations les plus performantes lors des incidents ne seront pas celles qui disposent du classeur de réponse le plus épais. Ce seront celles qui peuvent répondre rapidement à quatre questions et prouver ensuite chacune de leurs réponses :

• Que s’est-il passé ?
• Quelle est la gravité ?
• Quelles obligations réglementaires peuvent s’appliquer ?
• Quels éléments de preuve soutiennent la décision ?

Clarysec aide les organisations à construire ce pont au moyen de modèles de politiques, de taxonomies de gravité, de journaux de décision, de scénarios d’exercices sur table et de cartographies de conformité croisée. Commencez par les politiques d’incident, validez vos critères de risque dans Zenith Blueprint Zenith Blueprint, puis utilisez Zenith Controls Zenith Controls pour cartographier les contrôles ISO/IEC 27002:2022 5.24, 5.25, 5.26, 5.27 et 5.28 avec DORA, NIS2, GDPR, NIST CSF et les attentes d’audit.

Si votre équipe ne peut pas répondre à la question « Est-ce un incident majeur DORA, un incident significatif NIS2 ou un événement notifiable au titre du GDPR ? » dans la première heure, l’étape suivante n’est pas un autre plan générique de réponse aux incidents. L’étape suivante est un modèle opérationnel défendable de classification de la gravité des incidents, testé avant le prochain appel de 02 h 17.

Prêt à remplacer la panique par le processus ? Téléchargez les modèles Clarysec de politiques de réponse aux incidents et de collecte des éléments de preuve, évaluez votre taxonomie de gravité actuelle au regard du Zenith Blueprint, ou demandez une évaluation de préparation Clarysec afin de construire un modèle de classification des incidents DORA, NIS2, GDPR et ISO/IEC 27001 prêt pour l’audit.