DORA 2025 : le rôle de l'EASM dans la conformité du secteur financier
Le règlement DORA (Digital Operational Resilience Act) est entré en application le 17 janvier 2025. Il impose aux entités financières de l'Union européenne un cadre rigoureux de résilience opérationnelle numérique. Et contrairement à NIS2, DORA s'applique à toutes les entités financières réglementées — sans seuil de taille.
Qui est soumis à DORA ?
DORA s'applique à plus de 20 types d'entités financières :
- Banques et établissements de crédit
- Compagnies d'assurance et de réassurance
- Entreprises d'investissement
- Gestionnaires d'actifs (OPCVM, FIA)
- Plateformes de financement participatif
- Établissements de paiement et monnaie électronique
- Contréparties centrales (CCP)
- Fournisseurs de services cloud (tiers critiques ICT)
Les 5 piliers de DORA et leur lien avec l'EASM
Pilier 1 : Gouvernance du risque ICT
DORA exige que le conseil d'administration assure la supervision du risque ICT, y compris la gestion des vulnérabilités et des cybermenaces. L'EASM fournit les indicateurs nécessaires pour un reporting COMEX/Conseil : nombre d'actifs exposés, vulnérabilités critiques, évolution dans le temps.
Pilier 2 : Gestion des incidents ICT
DORA impose des délais très stricts : alerte initiale en 4 heures, rapport intermédiaire en 72 heures. Sans détection continue, les incidents sont découverts trop tard. L'EASM détecte les nouvelles expositions et vulnérabilités en temps réel, avant qu'elles ne deviennent des incidents.
Pilier 3 : Tests de résilience opérationnelle
DORA exige des tests de pénétration basés sur la menace (TLPT) pour les entités significatives. L'EASM fournit le contexte nécessaire pour planifier ces tests : identification des actifs exposés, cartographie des vecteurs d'attaque possibles, priorisation des scénarios à tester.
Pilier 4 : Gestion du risque tiers ICT
DORA impose une évaluation rigoureuse des fournisseurs ICT critiques (fournisseurs cloud, éditeurs de logiciels, fournisseurs de télécommunications). L'EASM permet de scanner la surface d'attaque de ces tiers et de surveiller leur posture de sécurité externe.
Pilier 5 : Partage d'information
DORA encourage le partage d'informations sur les cybermenaces entre entités financières. L'EASM contribue en identifiant les indicateurs de compromission (IoC) et les nouvelles techniques d'attaque visant le secteur.
Les exigences DORA qui nécessitent directement un EASM
| Exigence DORA | Article | Apport EASM |
|---|---|---|
| Cartographie des actifs ICT critiques | Art. 8 | Découverte automatique, inventaire continu |
| Identification des vulnérabilités | Art. 8 | Scan continu, priorisation CVE |
| Tests de vulnérabilité (au moins annuels) | Art. 25 | Base pour les tests de pénétration |
| Surveillance des tiers ICT | Art. 28-30 | Scan de la surface d'attaque des fournisseurs |
| Reporting au régulateur | Art. 19-20 | Rapports audités, historique documentable |
Délais et sanctions DORA
Délai notification incident majeur : 4h (alerte), 72h (rapport intermédiaire), 1 mois (rapport final)
Sanctions : Le superviseur peut imposer des amendes périodiques jusqu'à 1% du chiffre d'affaires quotidien mondial, jusqu'à ce que la conformité soit atteinte. Pour les fournisseurs tiers critiques : jusqu'à 5 millions €.
Comment Breach Atlas supporte la conformité DORA ?
Brech Atlas a conçu des fonctionnalités spécifiques pour le secteur financier :
Tableau de bord conformité DORA
- Mapping des actifs ICT critiques selon la classification DORA
- Score de résilience externe par entité (entité mère, filiales, tiers)
- Évolution temporelle de la posture de sécurité
Gestion du risque tiers
- Scan automatique de la surface d'attaque de vos fournisseurs ICT critiques
- Alertes en cas de dégradation de leur posture
- Rapport de conformité tiers pour le superviseur
Documentation audit
- Historique complet des découvertes, alertes et actions
- Export PDF pour les contrôleurs BCE/ACPR/AMF
- Preuve de surveillance continue
Plan d'action DORA à 6 mois
Mois 1-2 : Cartographier les actifs ICT critiques avec un EASM. Identifier les vulnérabilités critiques.
Mois 3 : Définir les procédures d'alerte et de gestion des incidents. Calibrer les seuils d'alerte.
Mois 4 : Lancer les tests de vulnérabilité sur les actifs critiques identifiés.
Mois 5 : Étendre le scanning aux fournisseurs ICT critiques.
Mois 6 : Consolider le reporting pour le conseil d'administration et les superviseurs.
