DORA et Cybersécurité : ce que le règlement impose au secteur financier

Quand la panne CrowdStrike du 19 juillet 2024 a paralysé 8,5 millions de machines dans le monde — dont des terminaux bancaires, des systèmes de trading et des plateformes d'assurance —, une chose est devenue limpide : la cybersécurité n'est pas un sujet technique isolé, c'est un enjeu de stabilité financière. Le règlement DORA (EU) 2022/2554 traduit cette prise de conscience en obligations juridiques contraignantes. Voici ce qu'il impose concrètement en matière de cybersécurité.

DORA et Cybersécurité : un cadre unifié pour toute l'Europe

Avant DORA, chaque régulateur national avait ses propres exigences en matière de cybersécurité financière. L'ACPR en France, la BaFin en Allemagne, la PRA au Royaume-Uni — chacun avec ses guidelines, ses questionnaires et ses attentes. Pour un groupe bancaire opérant dans 5 pays européens, c'était un cauchemar de conformité. DORA met fin à cette fragmentation en imposant un cadre unique, directement applicable dans les 27 États membres, couvrant la gestion des risques ICT, la détection et la réponse aux incidents, les tests de résilience et la supervision des prestataires.

Les exigences cyber de DORA vs les standards existants

DORA ne réinvente pas la roue. Il s'appuie sur des standards reconnus — ISO 27001, NIST CSF, TIBER-EU — en les rendant juridiquement contraignants pour le secteur financier. La différence fondamentale : avant DORA, adopter ISO 27001 était un choix volontaire ; depuis le 17 janvier 2025, les obligations cyber de DORA sont une obligation légale. Et les sanctions ne sont pas symboliques : jusqu'à 10 millions d'euros ou 5 % du chiffre d'affaires.

Les 4 Piliers Cyber de DORA en Détail

Sur les cinq piliers de DORA, quatre ont un lien direct avec la cybersécurité. Seul le pilier 5 (partage d'informations) est facultatif — et même celui-ci concerne le renseignement sur les cybermenaces.

Pilier 1 : Prévention et protection (Articles 5-16)

Le cadre de gestion des risques ICT doit inclure des mesures de cybersécurité concrètes : politique de sécurité de l'information couvrant le réseau, les données et la cryptographie ; contrôles d'accès basés sur le principe du moindre privilège ; gestion des vulnérabilités et correctifs (patch management) ; segmentation réseau pour limiter la propagation des attaques ; protection des endpoints (EDR/XDR) ; et sécurité des environnements cloud. L'organe de direction doit approuver cette politique et en assumer la responsabilité — plus question de déléguer au RSSI sans regard managérial.

Pilier 2 : Détection et notification des incidents (Articles 17-23)

DORA impose une capacité de détection continue des anomalies et des incidents cyber. Concrètement, cela signifie un SOC (Security Operations Center) opérationnel, des outils SIEM/SOAR pour la corrélation des alertes, et des processus de classification des incidents selon les critères de l'article 18. Quand un incident est classifié comme majeur — plus de 10 % des clients affectés, durée supérieure à 2 heures, ou impact sur des services critiques —, la notification à l'autorité compétente doit intervenir dans les 4 heures.

Pilier 3 : Tests de résilience et red team (Articles 24-27)

C'est le pilier le plus opérationnel en termes de cybersécurité. DORA impose deux niveaux de tests. Les tests de base — scans de vulnérabilité, tests de pénétration, analyses de code, tests de performance — s'appliquent à toutes les entités au moins annuellement. Les tests TLPT (Threat-Led Penetration Testing), basés sur le framework TIBER-EU, sont réservés aux entités systémiques et doivent être conduits par des red teams externes qualifiées, au moins tous les 3 ans. Ces tests simulent des scénarios d'attaque réalistes basés sur le renseignement sur les menaces actuelles.

Pilier 4 : Sécurité de la chaîne d'approvisionnement ICT (Articles 28-44)

La panne CrowdStrike l'a montré : la cybersécurité d'une entité financière dépend de celle de ses fournisseurs. DORA impose un registre complet des prestataires ICT, des clauses de sécurité minimales dans les contrats (article 30), des droits d'audit sur les prestataires, et une évaluation du risque de concentration. Les prestataires critiques — pensez AWS, Azure, Google Cloud, mais aussi des éditeurs comme Temenos, FIS, Finastra — sont désormais supervisés directement par les autorités européennes.

Incidents Cyber Majeurs qui Ont Accéléré DORA

DORA n'est pas né dans le vide. Plusieurs incidents majeurs ont convaincu les législateurs européens de l'urgence d'agir.

Le hack SWIFT de la Banque du Bangladesh (2016)

En février 2016, des hackers — attribués au groupe Lazarus lié à la Corée du Nord — ont exploité des faiblesses dans l'accès SWIFT de la Banque centrale du Bangladesh pour émettre des ordres de virement frauduleux de 951 millions de dollars. 81 millions ont été effectivement détournés vers des comptes aux Philippines. L'attaque a révélé l'absence de contrôles de sécurité multicouches sur des systèmes critiques de messagerie financière.

Le ransomware NotPetya et le secteur financier (2017)

L'attaque NotPetya de juin 2017, initialement ciblée sur l'Ukraine, s'est propagée mondialement. Le géant du transport Maersk a perdu 300 millions de dollars. Plusieurs institutions financières européennes ont été touchées, notamment la banque ukrainienne Oschadbank et le groupe français Saint-Gobain (dont les activités incluent des filiales financières). Le coût global est estimé à 10 milliards de dollars.

La panne CrowdStrike (juillet 2024)

Le 19 juillet 2024, une mise à jour défectueuse du logiciel de sécurité CrowdStrike Falcon a provoqué un écran bleu (BSOD) sur 8,5 millions de machines Windows. Des banques, des systèmes de paiement et des plateformes de trading ont été paralysés. JPMorgan Chase, Bank of America et des dizaines d'autres institutions ont signalé des perturbations. Delta Air Lines a estimé ses pertes à 500 millions de dollars. C'est l'incident qui a le plus validé l'approche DORA sur la gestion des risques prestataires tiers.

Le ransomware contre ION Group (janvier 2023)

ION Trading Technologies, prestataire logiciel pour les marchés de dérivés, a été victime du ransomware LockBit. ABN Amro, Intesa Sanpaolo et d'autres grandes banques ont dû traiter manuellement leurs positions sur dérivés pendant plusieurs jours. L'incident a démontré qu'un seul prestataire tiers pouvait paralyser des pans entiers du marché financier.

Ce que les RSSI Doivent Mettre en Place Concrètement

Au-delà de la théorie réglementaire, voici les chantiers prioritaires pour un RSSI en 2025-2026.

SOC et capacités de détection

DORA exige des capacités de détection opérationnelles, pas un SOC sur le papier. Cela signifie des outils SIEM configurés et maintenus, des analystes formés aux menaces actuelles, des playbooks de réponse testés, et une astreinte 24/7 pour les entités critiques. Pour les entités de taille modeste, un SOC externalisé (MSSP) est une option acceptable sous DORA, à condition que le contrat respecte les clauses de l'article 30.

Programme de tests continu

Les tests de résilience ne sont pas un exercice ponctuel. DORA attend un programme annuel incluant des scans de vulnérabilité trimestriels, des tests de pénétration au moins annuels, des exercices de continuité d'activité, et des simulations de crise cyber. Pour les entités systémiques, les TLPT tous les 3 ans s'ajoutent à ce programme de base.

Processus de notification en 4 heures

Le délai de 4 heures pour la notification initiale d'un incident majeur est très serré. En pratique, cela nécessite des critères de classification pré-définis, un template de notification pré-rempli, une chaîne de communication claire (RSSI → direction → régulateur), et des exercices réguliers de notification à blanc. Les entités qui n'ont pas automatisé une partie de ce processus risquent de dépasser le délai.

DORA vs NIS2 : Quelle Articulation pour la Cybersécurité ?

DORA et la directive NIS2 (2022/2555) coexistent avec un principe clair : DORA prévaut pour le secteur financier en tant que lex specialis. Concrètement, une banque soumise à DORA n'a pas à se conformer aux obligations de cybersécurité de NIS2 — DORA les couvre intégralement. En revanche, les prestataires ICT qui ne sont pas exclusivement au service du secteur financier (un cloud provider comme AWS, par exemple) peuvent être soumis aux deux textes. L'important pour les entités financières est de ne pas confondre les obligations : DORA est leur cadre de référence unique.

Conclusion

DORA transforme la cybersécurité financière d'un sujet technique en un sujet de gouvernance et de conformité juridique. Les entités qui l'auront compris — et qui investiront dans des capacités cyber réelles plutôt que dans une conformité documentaire de façade — seront mieux protégées et mieux positionnées face à des menaces qui ne cessent de croître. Le règlement (EU) 2022/2554 n'est pas parfait, mais il pose un plancher de sécurité dont le secteur avait cruellement besoin.