Dans un contexte où les incidents informatiques, problèmes de sécurité informatique, cyberattaques se multiplient, l'Union européenne a adopté en décembre 2022 le règlement DORA.
DORA pour Digital Operational Resilience Act, traduit en français par Règlement sur la Résilience Opérationnelle Numérique. Ce règlement vise à renforcer la cybersécurité et la résilience informatique de l'ensemble du secteur financier européen. Il constitue un pilier essentiel de la stratégie numérique de l’Union Européenne, et marque une étape décisive vers l’harmonisation de la gestion des risques liés aux technologies de l’information et de la communication (TIC).
DORA ne se contente pas d’établir des recommandations, il impose des obligations juridiques en matière de gestion des risques informatiques et de continuité des activités pour les entités financières opérant dans l’Union Européenne. Ce règlement est entré en vigueur le 17 janvier 2025.
Il convient de noter qu’un règlement est applicable en l'état dès sa publication au Journal officiel contrairement à une directive (ex: NIS2) qui nécessite une transposition dans le droit national du pays concerné.
DORA s'impose d'ailleurs comme une lex specialis vis-à-vis de NIS2 : ce principe signifie que la réglementation spécifique au secteur financier prime sur la directive généraliste. En pratique, les entités concernées appliqueront donc les règles de DORA pour gérer leurs risques et notifier leurs incidents, en lieu et place des exigences de NIS2.
Qui est concerné par le règlement DORA ?
Le champ d’application de DORA est particulièrement large. Il s'applique à une multitude d'entités du secteur financier, notamment :
-
les banques,
-
les compagnies d’assurance et de réassurance,
-
les sociétés d’investissement,
-
les établissements de paiement et de monnaie électronique,
-
les infrastructures de marché (chambres de compensation, dépositaires centraux, plateformes de négociation),
-
les sociétés de gestion d’actifs,
-
les prestataires de services de crowdfunding,
-
les agences de notation de crédit,
-
et surtout : les prestataires tiers de services TIC critiques (comme les fournisseurs de services cloud ou de logiciels)
La portée de DORA est délibérément vaste pour couvrir toute la chaîne de valeur numérique. Sont concernés non seulement les acteurs traditionnels, mais aussi les nouveaux acteurs comme les prestataires de services sur crypto-actifs, les plateformes de financement participatif et les établissements de paiement.
Une nouveauté majeure réside dans l'inclusion directe des prestataires tiers de services TIC (technologies de l'information et de la communication), tels que les fournisseurs de cloud ou de centres de données, dans le périmètre de la régulation.
Cela montre la volonté de l’UE d'instituer un cadre réglementaire uniforme couvrant l’ensemble de la chaîne de valeur numérique du secteur financier.
Toutefois, le règlement applique un principe de proportionnalité. Les exigences sont adaptées à la taille et au profil de risque de l'entité. Ainsi, les microentreprises (moins de 10 employés, chiffre d'affaires < 2M€) et certaines petites entités bénéficient d'un cadre simplifié de gestion des risques
Les piliers de DORA
Le règlement DORA repose sur cinq piliers fondamentaux :
1. Gestion des risques liés aux TIC (Technologies de l’Information et de la Communication)
La gestion du risque cyber n’est plus qu’un sujet IT. La responsabilité incombe désormais à l’organe de direction. Le risque numérique devient un risque stratégique, piloté au plus haut niveau de l’entreprise.
Les entités doivent mettre en place des cadres de gouvernance solides pour identifier, protéger, détecter, répondre et se rétablir face aux incidents liés aux TIC. Cela inclut la maintenance des systèmes, des contrôles internes et des dispositifs de supervision de la sécurité des technologies numériques.
-
Identifier : Une cartographie exhaustive et tenue à jour des fonctions « métiers », des actifs informationnels et des dépendances vis-à-vis des tiers est exigée. L'entité doit identifier en continu ses sources de risques et évaluer la criticité de ses actifs (Article 8).
-
Protéger : Mise en œuvre de stratégies de défense proactives incluant le chiffrement des données, une gestion rigoureuse des identités et des accès (IAM), ainsi que des politiques de gestion des vulnérabilités et des correctifs pour garantir la disponibilité, l'intégrité et la confidentialité des systèmes (Article 9).
-
Détecter : Déploiement de mécanismes de surveillance continue capables de repérer rapidement les activités anormales, les incidents de performance et les points de défaillance uniques, avec des seuils d'alerte définis pour déclencher une réponse immédiate (Article 10).
-
Répondre et rétablir : Établissement de plans de continuité d’activité (PCA) et de réponse aux incidents, régulièrement testés. L'objectif est de contenir les incidents, de limiter les dommages et d'assurer la reprise rapide des fonctions critiques via des procédures de gestion de crise documentées (Article 11).
-
Sauvegarder : Définition de politiques de sauvegarde (backup) et de procédures de restauration éprouvées. Les systèmes de sauvegarde doivent être physiquement et logiquement isolés (« sanctuarisés ») des systèmes sources pour garantir la récupération des données sans compromission (Article 12).
-
Apprendre : Amélioration continue du dispositif de sécurité basée sur l'analyse post-incident (« RETEX »), la veille sur les cybermenaces et la formation obligatoire du personnel et de la direction pour adapter la stratégie de résilience aux évolutions technologiques (Article 13).
Ce cadre présente de nombreuses similitudes avec la norme ISO 27001, notamment sur l'approche par les risques et l'amélioration continue, ce qui avantage les entités déjà certifiées.
2. Gestion des incidents TIC
Les incidents majeurs liés aux technologies de l'information ne doivent plus être traités en silo. Ils doivent être identifiés, enregistrés, classifiés et, le cas échéant, signalés aux autorités compétentes selon un formalisme strict.
Les entités doivent établir un cadre de gestion complet s'articulant autour de trois axes :
-
Le processus de gestion des incidents : Les entités doivent définir des procédures robustes pour détecter, gérer et notifier les incidents (Article 17). Ce processus doit inclure des indicateurs d'alerte précoce, une attribution claire des rôles et responsabilités, ainsi que des plans de communication envers les parties prenantes (internes, clients, régulateurs). Un point crucial exigé par DORA est l'analyse des causes profondes (Root Cause Analysis) pour chaque incident, afin d'en éviter la récurrence.
-
Les critères de classification : Pour déterminer si un incident est « majeur » et donc soumis à une obligation de déclaration, l'entité doit l'évaluer selon des critères précis (Article 18). Ces critères incluent le nombre de clients ou contreparties affectés, la durée de l'incident, sa répartition géographique, la perte de données (intégrité, confidentialité, disponibilité), la criticité des services touchés et l'impact économique direct et indirect.
-
Les obligations et délais de notifications : L'article 19 du règlement, complété par l'article 5 du règlement délégué (UE) 2025/301, impose une chronologie de déclaration extrêmement stricte pour les incidents majeurs :
-
Notification initiale : Elle doit être soumise au plus tôt, et au plus tard 4 heures après la classification de l'incident comme majeur (avec une limite absolue de 24 heures après la prise de connaissance de l'incident).
-
Rapport intermédiaire : Attendu dans les 72 heures suivant la notification initiale, ou dès qu'une mise à jour significative de la situation est disponible.
-
Rapport final : Doit être transmis au plus tard un mois après le rapport intermédiaire (ou après la résolution et l'analyse des causes).
-
À noter : Pour les entités essentielles, ces délais s'appliquent y compris les week-ends et jours fériés.
3. Tests de résilience opérationnelle numérique
Les entités doivent établir un programme de tests complet et fondé sur les risques pour évaluer leur capacité à prévenir, détecter et répondre aux incidents. Le règlement DORA distingue deux niveaux d'exigence :
-
Tests réguliers et diversifiés : Toutes les entités financières (hors microentreprises sous régime simplifié) doivent soumettre leurs systèmes critiques à des tests au moins une fois par an. L'article 25 du règlement ne se limite pas aux simples tests d'intrusion ; il exige un éventail de méthodologies incluant des évaluations de vulnérabilités, des analyses de sécurité réseau, des analyses d'écarts (gap analysis), des revues de code source, ainsi que des tests de compatibilité et de performance. L'objectif est de couvrir l'ensemble de la surface d'attaque potentielle.
-
Tests avancés (TLPT) : Pour les entités financières d'importance significative, DORA impose tous les trois ans des tests de pénétration fondés sur la menace (pour plus d’informations, vous pouvez consulter notre article sur DORA et les Threat-Led Penetration Testing). Il s'agit d'exercices de Red Teaming de haute intensité, réalisés sur des systèmes en environnement de production, simulant des tactiques, techniques et procédures (TTP) d'attaquants réels. Ces tests s'appuient sur des standards techniques inspirés du cadre TIBER-EU (Threat Intelligence-based Ethical Red Teaming).
Un point critique de cette exigence est l'extension du périmètre : si une fonction critique est externalisée, le prestataire tiers TIC doit être inclus dans le test.
4. Gestion des tiers fournisseurs TIC
Le règlement DORA opère un changement de paradigme majeur : la gestion du risque de tiers n'est plus une simple formalité administrative, mais une composante critique de la stratégie de résilience. Le principe fondamental posé par l'article 28 est celui de la responsabilité pleine et entière de l'entité financière. L'externalisation d'une fonction, même critique, ne transfère jamais la responsabilité réglementaire vers le prestataire.
Pour opérationnaliser ce principe, DORA impose quatre axes majeurs :
-
Un Registre d'Information : Les entités doivent tenir à jour un registre exhaustif recensant tous les accords contractuels avec des tiers TIC. Ce document, qui distingue les fonctions critiques des fonctions non-critiques, doit être mis à la disposition des autorités compétentes et leur être communiqué annuellement (Article 28). Il constitue la base de l'analyse du risque de concentration par le régulateur.
-
Des exigences contractuelles renforcées (Article 30) : Le règlement impose un formalisme contractuel strict. Tout contrat doit préciser la localisation des données, les niveaux de service (SLA) et les mesures de sécurité garantissant la disponibilité, l'intégrité et la confidentialité des données.
Pour les fonctions critiques, les exigences vont plus loin : le contrat doit impérativement prévoir un droit d'accès, d'inspection et d'audit illimité pour l'entité financière et ses régulateurs. De plus, des clauses doivent garantir la récupération et la restitution intégrale des données en cas d'insolvabilité ou de cessation d'activité du prestataire. -
Des stratégies de sortie et de continuité : Afin d'éviter tout verrouillage technologique (vendor lock-in), l'entité doit définir et tester des stratégies de sortie pour ses prestataires critiques. Ces plans doivent garantir qu'il est possible de résilier le contrat sans perturber les activités, en migrant les services vers un autre tiers ou en les réintégrant en interne, tout en assurant la continuité opérationnelle durant la phase de transition.
-
Une surveillance des Tiers Critiques : Les prestataires jugés critiques au niveau européen (ex: géants du Cloud) seront soumis à une surveillance directe par les Autorités Européennes de Surveillance (AES), financée par des redevances. Les prestataires critiques hors-UE devront établir une filiale dans l'Union sous 12 mois pour continuer à opérer.
5. Information et coopération
Les entités doivent partager les informations pertinentes sur les cybermenaces (cyber threat intelligence) avec les autres acteurs du secteur et coopérer étroitement avec les autorités de supervision pour une analyse plus efficace des risques systémiques.
Les amendes en cas de non-conformité
Le non-respect du règlement peut entraîner des conséquences juridiques et financières significatives. Les autorités de régulation nationales pourront infliger des amendes pouvant atteindre plusieurs millions d’euros selon la gravité des violations relevées.
La réglementation DORA prévoit également des sanctions administratives, comme :
-
des injonctions de se conformer ;
-
des restrictions d’activités ;
-
la révocation d’agrément pour certaines fonctions ou entités ;
Les prestataires de services TIC tiers critiques feront l’objet d’un encadrement spécifique par des autorités de supervision désignées et pourront également être sanctionnés en cas de manquements répétés.
Le lien entre la réglementation DORA et la norme ISO 27001
La norme ISO/IEC 27001 est une référence internationale pour la gestion de la sécurité de l'information. Elle offre un cadre reconnu pour la mise en œuvre, le maintien et l’amélioration continue de la sécurité de l'information au sein d’une organisation.
Bien que DORA soit une réglementation juridiquement contraignante et que ISO 27001 soit une norme volontaire, les deux partagent de nombreux principes :
-
L’approche basée sur les risques (DORA article 5 => ISO 27001:2022 §5.1 / A5.31 / A5.34 / A5.35 / A5.36 / A6.3 )
-
La mise en place de contrôles de sécurité
-
La gestion des fournisseurs
-
La réponse aux incidents
-
L’amélioration continue de la sécurité
Ainsi, une entreprise déjà certifiée ISO 27001 est généralement bien positionnée pour répondre aux exigences de DORA — sous réserve d’y ajouter les aspects spécifiques à la réglementation européenne, comme la notification des incidents aux autorités et la structuration de la relation avec les prestataires externes sous l’angle réglementaire.
Conclusion
La réglementation DORA représente une transformation structurante pour le secteur financier européen. Il impose de nouvelles mesures dans la gestion des risques numériques et renforce la responsabilité des entreprises face aux menaces grandissantes liées aux technologies. En intégrant les principes de DORA dans leur stratégie de cyber résilience, les organisations ne se cantonnent pas à une obligation réglementaire : elles se préparent à un environnement numérique plus sûr, plus stable et plus résilient. Investir dès aujourd’hui dans la mise en œuvre de DORA, c’est anticiper les défis de demain.
En somme : DORA n’est pas qu’une contrainte réglementaire, c’est une opportunité pour renforcer la confiance numérique dans un monde financier toujours plus digitalisé.
À propos : Le blog d'AlgoSecure est un espace sur lequel notre équipe toute entière peut s'exprimer. Notre personnel marketing et commercial vous donne des informations sur la vie et l'évolution de notre société spécialisée en sécurité sur Lyon. Nos consultants techniques, entre deux tests d'intrusion ou analyses de risque, vous donnent leur avis ainsi que des détails techniques sur l'exploitation d'une faille de sécurité informatique. Ils vous expliqueront également comment sécuriser votre système d'informations ou vos usages informatiques particuliers, avec autant de méthodologie et de pédagogie que possible. Vous souhaitez retrouver sur ce blog des informations spécifiques sur certains sujets techniques ? N'hésitez pas à nous en faire part via notre formulaire de contact, nous lirons vos idées avec attention. Laissez-vous guider par nos rédacteurs : Alessio, Alexandre, Amine, Anas, Arnaud, Benjamin, Damien, Enzo, Eugénie, Fabien, Françoise, Gilles, Henri, Jean-Charles, Jean-Philippe, Jonathan, Joël, Joëlie, Julien, Jéromine, Lucas, Ludovic, Lyse, Matt, Nancy, Natacha, Nicolas, Pierre, PierreG, Quentin, QuentinR, Sébastien, Tristan, Yann, et bonne visite !