Classification d’un incident TIC majeur DORA : l’arbre de décision opérationnel

La classification d’un incident TIC majeur DORA se décide en deux temps : déterminer si un service critique est affecté, puis tester les seuils réglementaires de gravité. La cellule de crise doit consigner ses réponses, ses inconnues et ses hypothèses dès la détection, puis réévaluer la qualification à chaque évolution significative. L’arbre ci-dessous accélère cette décision sans se substituer à l’analyse réglementaire du cas.

Les faits à établir avant de qualifier l’incident

N’attendez pas l’analyse de cause racine. Dès la détection, le responsable d’incident ouvre une fiche de qualification unique, horodatée et distincte du journal général de crise.

Étape 1 — Attribuer un propriétaire à chaque donnée

La fiche doit au minimum couvrir :

• l’heure de détection, le début estimé et la méthode utilisée pour l’estimer ;
• les composants, services financiers et fonctions métier touchés ;
• le caractère critique ou important des fonctions soutenues ;
• le nombre de clients affectés et le nombre total de clients utilisant le service ;
• le nombre de contreparties financières affectées et le dénominateur correspondant ;
• le nombre et la valeur des transactions affectées, comparés aux moyennes quotidiennes pertinentes ;
• les États membres concernés ;
• la durée de l’incident et celle de l’indisponibilité du service ;
• les atteintes à la disponibilité, à l’authenticité, à l’intégrité ou à la confidentialité des données ;
• tout accès malveillant et non autorisé réussi, ainsi que son potentiel de perte de données ;
• les indices d’impact réputationnel ;
• les coûts et pertes directs ou indirects déjà constatés ou prévisibles ;
• les incidents survenus pendant les six mois précédents présentant une cause apparente similaire.

Chaque champ reçoit un propriétaire : Opérations pour les clients et transactions, métier pour l’impact sur le service, RSSI ou DSI pour les données techniques, finance pour les coûts, conformité ou risques pour l’interprétation des critères.

Étape 2 — Relier le composant au service affecté

Un serveur indisponible ou un compte compromis ne suffit pas à qualifier l’incident. Il faut documenter la chaîne :

composant TIC → service TIC → service financier → fonction métier → clients ou obligations affectés.

La preuve attendue est la cartographie services-fonctions, complétée si nécessaire par le propriétaire métier. Cette étape détermine notamment si le service soutient une fonction critique ou importante.

Étape 3 — Photographier les impacts

Pour chaque mesure, inscrivez la valeur, le dénominateur, l’heure de mesure et la source : ticket d’incident, journaux techniques, outil de supervision, extraction clients, fichier de transactions, réclamations ou estimation financière. Une valeur sans dénominateur ne permet pas de tester un seuil en pourcentage.

Critère de fin : chaque donnée nécessaire à l’arbre porte une valeur, la mention « inconnu » ou « non applicable ». Aucune case ne reste vide.

L’arbre de décision pour tester les critères de gravité

Le règlement délégué (UE) 2024/1772 fixe les critères et seuils applicables. Le décompte doit être effectué par famille réglementaire : franchir deux sous-seuils relatifs aux clients ne constitue pas, à lui seul, le franchissement de deux critères distincts.

Étape 1 — Un service critique est-il affecté ?

Répondez oui si au moins une des situations de l’article 6 est établie :

1. le service soutient une fonction critique ou importante ;
2. le service financier affecté est soumis à autorisation, enregistrement ou surveillance par une autorité compétente ;
3. un accès malveillant et non autorisé aux réseaux et systèmes d’information a réussi.

Si la réponse est non, l’incident n’est pas majeur au titre de cet arbre. Conservez néanmoins la justification et réévaluez-la si le périmètre change.

Étape 2 — La branche spécifique aux données est-elle satisfaite ?

Posez la question suivante : un accès malveillant et non autorisé a-t-il réussi, avec un accès susceptible d’entraîner des pertes de données ?

• Oui : si la porte d’entrée relative au service critique est également satisfaite, classez l’incident comme majeur.
• Non : passez au cumul des autres critères.
• Inconnu ou plausible : attribuez le statut « qualification provisoire sous escalade ».

Cette branche ne doit pas être confondue avec toute atteinte à la disponibilité ou à l’intégrité. Elle vise le seuil spécifique de l’article 5, paragraphe 1, point b), du règlement délégué.

Étape 3 — Au moins deux autres critères sont-ils franchis ?

Testez chaque famille par une question oui/non :

• Clients ou contreparties : plus de 10 % des clients utilisant le service, plus de 100 000 clients, ou plus de 30 % des contreparties financières pertinentes sont-ils affectés ?
• Transactions : plus de 10 % du nombre quotidien moyen ou de la valeur quotidienne moyenne des transactions liées au service sont-ils affectés ?
• Réputation : l’incident a-t-il entraîné une couverture médiatique, des réclamations répétitives de différents clients ou contreparties, l’impossibilité probable de respecter des exigences réglementaires, ou un risque de perte de clientèle ayant une incidence significative sur l’activité ?
• Durée ou indisponibilité : l’incident dure-t-il plus de 24 heures, ou l’indisponibilité d’un service soutenant une fonction critique ou importante dépasse-t-elle deux heures ?
• Étendue géographique : l’incident produit-il un impact dans au moins deux États membres ?
• Données : l’atteinte à la disponibilité, l’authenticité, l’intégrité ou la confidentialité a-t-elle, ou aura-t-elle, une incidence négative sur les objectifs opérationnels ou le respect des exigences réglementaires ?
• Impact économique : les coûts et pertes dépassent-ils, ou devraient-ils dépasser, 100 000 euros ?

Si au moins deux de ces familles atteignent leur seuil et qu’un service critique est affecté, classez l’incident comme majeur.

Étape 4 — Faut-il agréger des incidents récurrents ?

Au moins une fois par mois, recherchez les incidents individuellement non majeurs qui :

• se sont produits au moins deux fois pendant une période de six mois ;
• présentent la même cause apparente ;
• remplissent collectivement les conditions de classification d’un incident majeur.

La « cause apparente » est celle disponible au moment de l’évaluation ; elle n’impose pas d’attendre une cause racine définitivement démontrée.

Sortie de l’arbre : retenez un seul statut — « majeur », « non majeur à ce stade » ou « qualification provisoire sous escalade ». Le classement comme majeur fait ensuite entrer l’incident dans le processus traité dans le mémo de gestion des incidents TIC DORA, sans reproduire ici les séquences de notification.

Que faire lorsque les impacts ou les seuils restent incertains

Une donnée inconnue ne vaut jamais réponse négative. Elle doit devenir une hypothèse mesurable, dotée d’un propriétaire et d’une échéance.

Étape 1 — Encadrer chaque inconnue

Tenez un tableau comprenant :

Donnée inconnue	Fourchette basse-haute	Source ou méthode	Propriétaire	Prochaine mise à jour	Effet possible
Clients affectés	8 000–14 000	Sessions en erreur	Opérations	14 h 30	Seuil de 10 % possible
Coûts prévisibles	60–120 k€	Estimation finance	Finance	16 h 00	Seuil économique possible

La fourchette doit reposer sur une méthode identifiable. Une borne haute purement spéculative justifie une investigation, pas une conclusion réglementaire.

Étape 2 — Tester les scénarios bas et haut

Exécutez l’arbre avec l’hypothèse basse, puis avec l’hypothèse haute. Si les deux scénarios aboutissent à des statuts différents, conservez une qualification provisoire et déclenchez une revue immédiate associant responsable d’incident, RSSI et conformité ou risques.

Escaladez également lorsque :

• deux critères sont proches de leur seuil ;
• plusieurs impacts se cumulent sans qu’un seuil isolé soit encore démontré ;
• un accès malveillant réussi ou une perte de données reste plausible ;
• la criticité du service n’est pas tranchée ;
• la qualité des dénominateurs ne permet pas un calcul fiable.

Étape 3 — Définir le prochain déclencheur de réévaluation

Ne programmez pas seulement une revue « plus tard ». Retenez le premier événement attendu : nouvelle extraction, dépassement possible d’une durée, extension à un autre service ou État membre, découverte d’une exfiltration, hausse des clients ou transactions affectés, nouvelle estimation des coûts ou rapprochement avec un incident récurrent.

Critère de fin : aucun statut « non majeur à ce stade » n’est maintenu lorsqu’une inconnue déterminante reste sans propriétaire, méthode d’estimation ou échéance.

Comment tracer et faire valider la décision de classification

La piste d’audit doit permettre à un tiers interne de reconstruire la décision sans interroger les participants à la crise.

Étape 1 — Constituer un dossier versionné

Conservez :

• l’identifiant, le périmètre et la chronologie de l’incident ;
• la version de l’arbre et du référentiel réglementaire utilisée ;
• le service financier et la fonction affectés ;
• pour chaque critère : seuil, valeur, dénominateur, source, heure de mesure et réponse ;
• les journaux, extractions ou références non modifiables des preuves ;
• les inconnues, fourchettes, hypothèses et niveaux de confiance ;
• l’analyse des incidents récurrents et de leur cause apparente ;
• le motif du classement ou du non-classement ;
• les avis divergents, réserves et arbitrages ;
• les dates de réévaluation et l’historique des changements.

Étape 2 — Organiser la validation

Le responsable d’incident valide les faits, le RSSI ou responsable TIC l’impact technique, le métier l’incidence sur le service, et conformité ou risques la lecture des critères. La conclusion revient au décideur désigné par la procédure interne de l’entité ; son identité, son heure de décision et ses éventuelles réserves sont consignées.

Toute requalification donne lieu à une nouvelle version, sans écraser la précédente. Elle doit citer le fait nouveau déclencheur : seuil de durée franchi, périmètre étendu, perte de données confirmée ou estimation économique révisée.

Critère de fin : chaque réponse positive, négative ou inconnue peut être reliée à une preuve horodatée, une hypothèse explicite et un validateur nommé.

Sources réglementaires : règlement (UE) 2022/2554 — DORA, règlement délégué (UE) 2024/1772 relatif aux critères de classification et page DORA de l’ESMA.

Questions fréquentes

Qui qualifie l’incident lorsqu’il provient d’un prestataire tiers de services TIC ?

L’entité financière reste responsable de la classification au regard de ses services, fonctions, clients et obligations. Le prestataire fournit les éléments techniques nécessaires — chronologie, périmètre, disponibilité, accès et données affectées — mais sa propre qualification ne remplace pas celle de la SGP ou de l’établissement de paiement.