3.Section 2 : La notion d’incident selon DORA (thématique 4)

Définition et innovations

Définition de la notion d’incident selon DORA


   DORA, dans son Article 13, définit un incident TIC comme « tout événement ayant un impact négatif sur la sécurité des réseaux et des systèmes d’information, compromettant la disponibilité, l’authenticité, l’intégrité ou la confidentialité des données, ou ayant un impact sur la continuité des services financiers ».  
   Explication
   Cette définition est plus complète et structurée que celles des régulateurs précédents. Elle met l’accent sur :  
La sécurité des systèmes : Confidentialité, intégrité, disponibilité.  
L’impact opérationnel : Perturbation des services financiers.  
La continuité des activités : Nécessité de restaurer rapidement les opérations.  
Grandes notions clés


Identification des incidents :  


     DORA exige une détection proactive des incidents grâce à des systèmes de surveillance en temps réel et des outils de monitoring. Par exemple, une institution doit être capable de détecter une cyberattaque ou une panne de système dès les premiers signes.
Avant DORA, la détection reposait souvent sur des alertes manuelles ou des outils basiques. DORA impose une surveillance continue et automatisée.

Notification et communication :  


     Les incidents doivent être signalés aux parties prenantes internes (direction, équipes techniques) et aux régulateurs dans des délais précis. Par exemple, un incident majeur doit être notifié à l’autorité de supervision dans les 24 heures.  
    « Contrairement aux pratiques antérieures, où la notification était souvent facultative ou peu formalisée, DORA rend cette étape obligatoire et standardisée. »

Gestion et réponse


     Les plans de réponse doivent inclure des étapes claires pour :  
     – Confinement : Limiter la propagation de l’incident.  
     – Éradication : Supprimer la cause de l’incident.  
     – Récupération : Restaurer les opérations normales.  
     « DORA exige que ces plans soient documentés, testés régulièrement et mis à jour en fonction des leçons apprises. » 

Analyse post-incident


     Les causes racines doivent être analysées pour prévenir des incidents similaires à l’avenir. Par exemple, une institution doit identifier si l’incident était dû à une vulnérabilité technique, une erreur humaine ou une faille dans les processus.  
« Cette étape, souvent négligée avant DORA, devient une exigence réglementaire. »

Reporting aux régulateurs


     DORA impose des rapports réguliers et détaillés aux régulateurs, avec des modèles standardisés fournis par les RTS et ITS. Par exemple, un rapport doit inclure :  
La nature de l’incident.  
Les mesures prises pour y répondre.  
Les impacts sur les opérations et les clients.  
     « Cette transparence accrue permet aux régulateurs de mieux comprendre les risques sectoriels et d’adapter leurs politiques. »

  1. Encadré :  
    « DORA introduit un cadre réglementaire contraignant, harmonisant les exigences à l’échelle européenne. Les institutions financières doivent désormais documenter et tester leurs plans de réponse, et produire des rapports détaillés pour les régulateurs. Ces innovations marquent une rupture avec les pratiques antérieures, souvent basées sur des recommandations facultatives. »
    Références
    Article 13 de DORA : Texte officiel  
    RTS et ITS : Lien vers les textes techniques  

Retour en haut