Gestion des incidents ICT DORA : qualifier, escalader, notifier, prouver

Sous DORA, un incident n'est pas un événement : c'est une suite de décisions à qualifier, escalader, notifier et prouver.

Objectif : passer vite du « signal » à une qualification traçable.

1. Périmètre

Incident ICT = événement affectant la confidentialité, l'intégrité ou la disponibilité des SI, des données ou d'un service.

À distinguer : incident (événement) ≠ problème (cause racine) ≠ crise (pilotage élargi).

2. Chaîne de gestion end-to-end

1. Détection / alerte (SOC, IT, métiers, prestataires)
2. Triage (vrai incident ? périmètre ? hypothèses)
3. Décision : majeur / non majeur + escalade
4. Réponse (confinement, contournements, éradication)
5. Restauration (retour au nominal + surveillance renforcée)
6. Post-incident : RCA + plan d'actions + re-test

3. Rôles (RACI simple)

Rôle	Contribution
IT / Opérations	Stabiliser, restaurer, preuves techniques
SOC / SecOps	Détecter, qualifier, chronologie, IoC
RSSI	Arbitre sécurité / containment
Risques / Conformité	Qualifie « majeur », valide la traçabilité
Direction	Continuité, communication, acceptation
Tiers critiques	Faits, délais, preuves côté fournisseur

4. Est-ce un incident majeur ? (règle simple)

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

Service critique = service qui soutient une fonction critique ou un service financier régulé (paiement, exécution d'ordres, tenue de registre, reporting réglementaire…).

• Non → pas « majeur » au sens DORA
• Oui → étape 2

Étape 2 — Majeur si intrusion confirmée OU ≥ 2 impacts

Intrusion confirmée : accès malveillant non autorisé réussi (ex. compte admin compromis, accès persistant).

Ou au moins deux impacts parmi :

• clients / transactions impactés
• risque réputationnel significatif
• interruption significative (durée / indisponibilité)
• étendue géographique significative
• perte de données
• impact économique significatif

Résumé : service critique touché + (intrusion confirmée OU ≥ 2 impacts) = incident majeur.

Références : règlement (UE) 2022/2554 — notamment Art. 6, 9, 19.

5. Evidence pack (preuves minimales)

• Chronologie horodatée : alerte → décisions → actions → rétablissement
• Décisions clés : qui / quoi / quand / sur quelle base
• Périmètre & impacts : su / supposé / confirmé (horodaté)
• Actions & résultats : containment, correctifs, re-test
• Communication : qui informé, quand, quel message

6. Délais de notification (jalons)

Objectif : notifier vite sans bloquer l'investigation — commencer « léger », puis compléter.

Jalons	Délai
Notification initiale	Le plus tôt possible ; ≤ 4h après classification « majeur », et au plus tard ≤ 24h après prise de connaissance
Rapport intermédiaire	≤ 72h après la notification initiale ; mises à jour si évolution significative
Rapport final	≤ 1 mois après le rapport intermédiaire (ou après le dernier intermédiaire)

Déclassement : après notification initiale, un incident peut être requalifié si les faits ne répondent plus aux critères. Tracer la décision et informer l'autorité.

Cas pratiques : si un délai ne peut être tenu, prévenir avant l'échéance. Si l'échéance tombe week-end / férié : souvent possible jusqu'à midi le prochain jour ouvré (selon modalités nationales).

Détail : délais de notification d'incident DORA.

7. Livrables utiles

• Grille « majeur / non majeur »
• Matrice d'escalade (seuils, décideurs, astreinte)
• Playbooks (ransomware, fuite, indisponibilité, compromission admin…)
• Checklist preuves
• Modèles : journal de crise, fiche incident, RCA

8. Points de contrôle (où ça casse)

• Décision trop tardive ou non justifiée
• Pas de requalification horodatée
• Tiers : infos partielles, preuves indisponibles
• Preuves reconstruites après coup
• Remédiation non priorisée / non re-testée / non clôturée

Le rôle d'Axenia. Axenia structure le parcours incident : qualification, échéances, chronologie, actifs et fonctions impactés, tiers concernés — et prépare les exports attendus par le régulateur.