DORA, pour Digital Operational Resilience Act, est le règlement européen qui impose au secteur financier une approche commune de la résilience opérationnelle numérique. Derrière l’expression « DORA cybersécurité », l’enjeu est clair : une banque, un assureur, une société de gestion ou un prestataire critique doit pouvoir prévenir, absorber et gérer un incident TIC sans mettre en péril ses services essentiels.
Applicable à partir du 17 janvier 2025, le règlement DORA 2022/2554 ne demande pas seulement davantage de sécurité informatique. Il structure la gouvernance, la gestion des risques, les tests, la notification des incidents majeurs et la surveillance des prestataires tiers de services TIC.
Ce que DORA change vraiment pour la cybersécurité financière
Un cadre commun pour remplacer les approches dispersées
Avant DORA, les exigences de cybersécurité du secteur financier existaient déjà, mais elles étaient réparties entre plusieurs textes, autorités et pratiques nationales. DORA vise une harmonisation européenne : les entités financières doivent appliquer un socle cohérent de règles pour gérer les risques liés aux technologies de l’information et de la communication.
Comprendre DORA
Question 1 sur 6
Chargement…
Le règlement couvre les attaques, mais aussi les pannes, les erreurs de configuration, les défaillances de sauvegarde, les interruptions de service, les dépendances fournisseurs et les capacités de restauration. La cybersécurité devient une composante de la résilience opérationnelle numérique, c’est-à-dire la capacité à continuer ou reprendre rapidement une activité malgré un choc technologique.
Une responsabilité portée par la gouvernance
DORA fait remonter le sujet au niveau de la direction. La gestion du risque TIC ne peut plus être cantonnée à une équipe technique isolée. Les organes de direction doivent approuver le cadre de gestion des risques, suivre les incidents significatifs, comprendre les dépendances critiques et s’assurer que les moyens sont adaptés.
Dans la pratique, cela implique de formaliser une politique de sécurité de l’information, de définir les rôles et responsabilités, de tenir à jour les procédures de continuité et de prévoir des mécanismes de contrôle. Une annexe RACI peut, par exemple, aider une banque ou une société de gestion à clarifier qui décide, qui exécute, qui valide et qui informe en cas d’incident.
Qui est concerné par DORA, et avec quel niveau d’exigence ?
Un périmètre large dans le secteur financier
DORA s’applique à 20 types d’entités financières, conformément à son article 2(1). Le périmètre couvre notamment les établissements de crédit, entreprises d’investissement, établissements de paiement, établissements de monnaie électronique, sociétés de gestion, gestionnaires de fonds d’investissement alternatifs, entreprises d’assurance et de réassurance, contreparties centrales, plateformes de négociation ou encore dépositaires centraux de titres.
Ce champ large reflète une réalité opérationnelle simple : le risque cyber ne s’arrête pas aux frontières d’un métier financier. Une rupture chez un acteur de paiement, un prestataire cloud, un opérateur de marché ou un sous-traitant logiciel peut avoir des effets en chaîne sur plusieurs entités et, potentiellement, sur plusieurs États membres.
Le principe de proportionnalité
DORA n’impose pas exactement le même niveau d’effort à toutes les structures. Le principe de proportionnalité, prévu notamment à l’article 4(1)(1), permet d’adapter certaines exigences à la taille, au profil de risque, à la nature des services et à la complexité de l’entité. Les petites structures ne sont donc pas invitées à reproduire mécaniquement l’organisation cyber d’un grand groupe bancaire.
Cela ne signifie pas une exemption générale. Même une entité plus modeste doit connaître ses actifs critiques, documenter ses dépendances TIC, prévoir une réponse aux incidents et assurer la continuité de ses fonctions importantes. La différence se joue dans le niveau de sophistication, de fréquence et de formalisation des dispositifs.
Les prestataires TIC dans la ligne de mire
DORA encadre aussi les prestataires tiers de services TIC. Hébergement, cloud, logiciels métiers, cybersécurité managée, connectivité, services de données : la chaîne d’approvisionnement numérique devient un sujet réglementaire central. Le marché compte environ 15 000 prestataires de services TIC, ce qui illustre l’ampleur de la dépendance fournisseur dans la finance.
Les prestataires considérés comme critiques peuvent faire l’objet d’une supervision européenne. Pour les entités financières, l’enjeu est double : mieux contractualiser les services TIC et conserver une vision consolidée des risques externalisés grâce à un registre d’information des contrats TIC.
Les obligations cybersécurité à transformer en actions concrètes
Identifier, protéger, détecter, répondre et rétablir
Le cadre DORA pousse les organisations à couvrir tout le cycle de gestion du risque TIC. Il faut d’abord identifier les actifs, processus et fonctions critiques. Ensuite viennent les mesures de protection : contrôle des accès, segmentation, sauvegarde, durcissement, supervision, journalisation et sensibilisation.
Le règlement européen DORA sur la résilience opérationnelle numérique — Le texte officiel du règlement (UE) 2022/2554 établissant des règles communes pour la résilience opérationnelle numérique du secteur ֆինանսcier.
La détection compte autant que la prévention. Une organisation conforme doit être capable de repérer rapidement un comportement anormal, d’escalader l’alerte, de qualifier l’incident et de mobiliser les bons interlocuteurs. Enfin, DORA insiste sur la restauration et le rétablissement : sauvegardes testées, plans de continuité des activités TIC, procédures de reprise et communication de crise.
Pour gérer cet enchaînement, chaque étape doit être prête avant l’incident : inventaire des actifs, détection, décision, notification, restauration et retour d’expérience. Une sauvegarde non testée reste théorique. Un fournisseur critique sans contact d’urgence validé fait perdre du temps à la cellule de crise. DORA demande justement de synchroniser ces rouages avant la panne, plutôt qu’au moment où le service est déjà indisponible.
Tester la résilience au lieu de la supposer
Le règlement impose des tests de résilience opérationnelle numérique. Ils peuvent prendre plusieurs formes : scans de vulnérabilités, tests d’intrusion, exercices de crise, tests de restauration, simulations techniques ou tests fondés sur la menace. Pour certaines entités, des programmes plus avancés de type Threat-Led Penetration Testing peuvent être attendus, en cohérence avec des cadres comme TIBER-EU.
L’objectif n’est pas de cocher une case, mais de vérifier que les contrôles fonctionnent dans des conditions proches du réel. Un plan de continuité non testé reste une hypothèse. Une procédure d’escalade non exercée reste fragile. Un test utile doit donc produire des constats, des priorités de remédiation, des responsables et des échéances.
Incidents majeurs : classer vite, notifier correctement
La classification, première décision critique
DORA impose la notification des incidents majeurs aux autorités compétentes. Avant de notifier, l’entité doit classifier l’incident selon des critères de gravité. Cette étape est déterminante, car elle conditionne le niveau d’escalade, les délais de communication et la mobilisation interne.
La classification peut prendre en compte le nombre de clients touchés, la durée de l’incident, l’impact économique, les pertes de données, l’atteinte à des fonctions critiques ou importantes, l’impact réputationnel ou l’extension géographique. Des seuils comme 10 %, 100 000 clients affectés, 30 % ou encore la présence d’au moins 2 États membres dans le périmètre impacté figurent parmi les repères utilisés pour apprécier la criticité selon les cas.
Une notification en plusieurs temps
La notification d’un incident majeur n’est pas un simple message envoyé en fin de crise. Elle s’inscrit dans un processus structuré : notification initiale, rapport intermédiaire, puis rapport final. L’idée est de fournir rapidement aux autorités les informations disponibles, puis de les enrichir à mesure que l’analyse progresse.
Des repères temporels comme 24 heures ou 2 heures peuvent intervenir dans cette mécanique de déclaration selon la situation et le type de rapport attendu. Pour éviter l’improvisation, les entités doivent préparer à l’avance leurs modèles de notification, leurs circuits de validation et leurs points de contact internes. Le juridique, la conformité, la cybersécurité, les opérations et la communication doivent savoir qui fait quoi avant que l’incident survienne.
| Obligation DORA | Traduction opérationnelle | Preuve attendue |
|---|---|---|
| Gestion des risques TIC | Cartographier les actifs, menaces, contrôles et fonctions critiques | Cadre de gestion, registre des risques, revues périodiques |
| Notification d’incidents | Classifier et déclarer les incidents majeurs | Procédure, critères, rapports initial/intermédiaire/final |
| Tests de résilience | Vérifier la robustesse technique et organisationnelle | Plans de tests, résultats, remédiations suivies |
| Gestion des tiers TIC | Surveiller les prestataires critiques et les contrats | Registre d’information, clauses, évaluations fournisseurs |
Préparer sa conformité DORA sans réduire le sujet à un chantier juridique
Partir des fonctions critiques, pas des documents
Une mise en conformité efficace commence par les services qui ne doivent pas tomber : paiement, gestion d’ordres, accès client, conservation de données, calcul réglementaire, reporting ou processus de marché. À partir de ces fonctions, l’organisation peut identifier les applications, infrastructures, fournisseurs, dépendances et scénarios de rupture réellement prioritaires.
Cette approche évite deux pièges fréquents : produire une documentation abondante mais déconnectée du terrain, ou lancer des projets techniques sans hiérarchisation réglementaire. DORA demande les deux dimensions : une gouvernance démontrable et une capacité opérationnelle vérifiable.
Construire une feuille de route pragmatique
Pour avancer, une entité financière peut structurer sa feuille de route autour de quelques chantiers : état des lieux DORA, cartographie des risques TIC, revue des contrats fournisseurs, formalisation du registre d’information, plan de tests, procédures de notification, exercices de crise et plan de remédiation. Le rapport de réexamen du cadre de gestion des risques TIC permet ensuite d’inscrire le dispositif dans une logique d’amélioration continue.
La conformité DORA n’est donc pas seulement une obligation réglementaire. Bien menée, elle améliore la lisibilité des risques, renforce la capacité de décision en crise et réduit la dépendance non maîtrisée aux tiers. C’est précisément là que la cybersécurité devient un sujet de résilience métier, et non un simple empilement de contrôles techniques.