Règlement DORA

Qu’est-ce que le règlement DORA ?

DORA — Digital Operational Resilience Act — est le règlement européen (UE) 2022/2554 sur la résilience opérationnelle numérique du secteur financier. Adopté le 14 décembre 2022, il est entré en application le 17 janvier 2025.

DORA est un règlement, pas une directive. Cette distinction juridique a une conséquence directe : il s’applique uniformément dans tous les États membres de l’UE sans transposition nationale. Les mêmes obligations, les mêmes délais, les mêmes exigences — de Lisbonne à Helsinki.

Le constat derrière DORA : le secteur financier dépend massivement des technologies numériques, mais les cadres réglementaires existants couvraient les risques informatiques de manière fragmentée selon les pays. Une attaque par ransomware sur un prestataire cloud peut paralyser des dizaines d’institutions financières simultanément. DORA crée un cadre unifié pour gérer ce risque systémique.

Qui est concerné par DORA ?

Le périmètre de DORA est large. L’article 2 liste plus de 20 catégories d’entités financières : établissements de crédit, entreprises d’investissement, assureurs et réassureurs, institutions de retraite professionnelle, sociétés de gestion d’actifs, prestataires de services de paiement, établissements de monnaie électronique, prestataires de services sur crypto-actifs, plateformes de financement participatif, dépositaires centraux de titres, agences de notation et cabinets d’audit.

DORA ne s’arrête pas aux entités financières elles-mêmes. Les prestataires tiers de services TIC — hébergeurs cloud, éditeurs de logiciels, fournisseurs de flux de données, prestataires de services managés — sont dans le périmètre quand ils sont désignés comme « critiques » par les autorités européennes de surveillance (ABE, AEAPP, AEMF).

En France, l’ACPR supervise les établissements de crédit et les assureurs. L’AMF supervise les sociétés de gestion et les prestataires crypto.

Le principe de proportionnalité

DORA applique un principe de proportionnalité (article 4). Les exigences s’adaptent à la taille, au profil de risque et à la complexité des activités de l’entité. Une fintech de 30 personnes n’a pas les mêmes obligations de test qu’une banque systémique. Mais les obligations de base — gestion des risques TIC, signalement des incidents, sensibilisation du personnel — s’appliquent à toutes les entités couvertes.

Les 5 axes du règlement DORA

1. Gestion des risques TIC (articles 5 à 16)

Chaque entité financière doit disposer d’un cadre de gestion des risques TIC documenté et tenu à jour : stratégies, politiques et procédures pour protéger les actifs informationnels, détecter les anomalies, assurer la continuité d’activité et tirer les enseignements des incidents.

L’organe de direction est directement responsable : il doit approuver la stratégie de résilience numérique, superviser sa mise en œuvre et suivre une formation suffisante pour comprendre les risques TIC.

2. Signalement des incidents TIC (articles 17 à 23)

Les entités financières doivent classifier les incidents TIC selon des critères harmonisés (clients affectés, durée, impact géographique, pertes financières, criticité des services) et signaler les incidents majeurs à leur autorité compétente.

Le calendrier de notification est contraint :

• Notification initiale : dès la classification de l’incident comme majeur
• Rapport intermédiaire : dans la semaine suivant la notification initiale
• Rapport final : dans le mois suivant la résolution de l’incident

Ce signalement standardisé permet aux régulateurs de détecter les menaces systémiques — par exemple, plusieurs entités touchées par le même prestataire compromis.

3. Tests de résilience opérationnelle numérique (articles 24 à 27)

DORA impose deux niveaux de tests.

Tests de base (toutes les entités) : évaluations de vulnérabilités, analyses de code source, tests de performance, tests de pénétration, revues de sécurité des réseaux. Ces tests doivent être réalisés régulièrement et couvrir les systèmes et applications TIC qui supportent des fonctions critiques.

Tests avancés — TLPT (entités identifiées par les autorités) : les tests de pénétration fondés sur la menace (Threat-Led Penetration Testing) simulent des scénarios d’attaque réalistes basés sur le profil de menaces spécifique à l’entité. Ces tests sont conduits par des testeurs externes qualifiés et couvrent les systèmes en production. Voir la section détaillée ci-dessous.

4. Gestion des risques liés aux prestataires tiers TIC (articles 28 à 44)

C’est l’axe le plus structurant pour l’ensemble de la chaîne de valeur. DORA impose :

• Un registre de tous les accords contractuels avec les prestataires TIC
• Des clauses contractuelles obligatoires (niveaux de service, droits d’audit, obligations de notification, plans de sortie)
• Une évaluation des risques de concentration : l’entité doit évaluer si une défaillance d’un prestataire unique pourrait affecter ses fonctions critiques
• Des stratégies de sortie documentées pour chaque prestataire supportant des fonctions critiques

Les prestataires TIC désignés comme critiques à l’échelle européenne sont soumis à un cadre de supervision direct par les autorités européennes de surveillance. Cette supervision inclut des inspections, des recommandations et des astreintes en cas de non-conformité.

5. Partage d’informations (article 45)

DORA encourage les entités financières à échanger des informations sur les cybermenaces : indicateurs de compromission, tactiques d’attaque, alertes de sécurité. Ce partage est volontaire mais encadré par la confidentialité commerciale et la protection des données personnelles.

DORA et la sensibilisation des collaborateurs

L’article 13 du règlement est explicite : les entités financières doivent mettre en place des programmes de sensibilisation à la sécurité TIC obligatoires pour l’ensemble du personnel. Ce n’est pas une recommandation — c’est une obligation réglementaire vérifiable par les autorités de supervision.

Ce que l’article 13 exige

Programmes de sensibilisation pour tous les collaborateurs. Chaque membre du personnel doit être formé aux risques TIC et aux procédures de sécurité, avec un contenu adapté à son niveau de responsabilité et à son rôle dans l’organisation.

Formation spécifique de l’organe de direction. Les dirigeants doivent suivre une formation leur permettant de comprendre et d’évaluer les risques TIC, et de superviser la stratégie de résilience numérique. L’objectif : que les décisions de sécurité soient prises par des dirigeants qui comprennent les enjeux techniques.

Modules de formation à la sécurité numérique. L’article 13.6 mentionne spécifiquement les « modules de formation à la sécurité des TIC » comme un dispositif à déployer selon le profil de risque de l’entité. Ces modules doivent être documentés et leur efficacité évaluée.

Comment appliquer concrètement l’article 13

La sensibilisation théorique ne suffit pas. Le phishing reste le vecteur d’entrée principal dans le secteur financier. Les programmes conformes à DORA devraient inclure :

• Simulations de phishing régulières : tester la capacité des collaborateurs à détecter des emails de spear phishing, de BEC (fraude au président) et de vishing ciblant le secteur financier
• Formation aux scénarios sectoriels : fausses demandes de virement, usurpation d’identité SWIFT, tentatives d’accès aux systèmes de paiement
• Exercices pour la direction : scénarios de crise impliquant une compromission majeure, prise de décision sous pression
• Documentation et traçabilité : registre des formations suivies, taux de participation, résultats des simulations, actions correctives

Consultez notre page sur la cybersécurité dans la finance pour les scénarios d’attaque spécifiques au secteur.

DORA vs NIS2

DORA et NIS2 coexistent dans le cadre réglementaire européen. La confusion entre les deux est fréquente, mais la distinction est nette.

	DORA	NIS2
Nature juridique	Règlement (directement applicable)	Directive (transposition nationale)
Périmètre	Secteur financier uniquement	Transversal (18 secteurs)
Relation	Lex specialis (règle spéciale)	Lex generalis (règle générale)
Entrée en application	17 janvier 2025	Octobre 2024 (transposition nationale)
Prestataires TIC	Supervision directe des prestataires critiques	Exigences sur la supply chain
Tests de résilience	TLPT obligatoire pour certaines entités	Tests réguliers, moins prescriptifs
Signalement d’incidents	Critères et délais harmonisés au niveau UE	Cadre général, détails nationaux

DORA est lex specialis : pour les entités financières, ses exigences remplacent les dispositions équivalentes de NIS2. Une banque se conforme à DORA, pas à NIS2, pour sa résilience numérique. Exception : si une entité financière opère aussi dans un secteur couvert par NIS2 (par exemple, en fournissant des services numériques), les obligations NIS2 peuvent s’appliquer pour cette activité.

Les deux textes partagent une logique commune : structurer la gestion des risques informatiques, signaler les incidents et évaluer les prestataires. Un programme de sensibilisation au phishing conçu pour DORA satisfera aussi les attentes de NIS2 sur le volet formation.

Les tests de résilience sous DORA

Tests de base

Toutes les entités couvertes doivent conduire des tests de résilience réguliers sur leurs systèmes TIC supportant des fonctions critiques : analyses de vulnérabilités, évaluations de sécurité réseau, tests de performance, revues de code source, tests de scénarios (continuité d’activité, reprise après sinistre). Les résultats doivent être documentés et les vulnérabilités corrigées.

TLPT — Threat-Led Penetration Testing

Le TLPT est l’exigence de test la plus avancée de DORA (article 26). Il s’adresse aux entités identifiées par les autorités compétentes sur la base de critères liés à leur importance systémique, leur profil de risque et la criticité de leurs services.

Ce qu’est un TLPT : un test de pénétration simulant une attaque réaliste, conduit par une équipe de testeurs externes qualifiés (la « Red Team »), basé sur des scénarios de menace spécifiques à l’entité. Le test couvre les systèmes en production et peut inclure des vecteurs humains — y compris des tentatives de phishing et d’ingénierie sociale ciblées sur les collaborateurs.

Les exigences clés du TLPT :

• Réalisé au minimum tous les trois ans sur les systèmes en production
• Basé sur un threat intelligence briefing décrivant les menaces réelles auxquelles l’entité est exposée
• Conduit par des testeurs externes qualifiés selon les critères du règlement
• Le périmètre inclut les prestataires TIC critiques de l’entité
• Les résultats et mesures correctives sont communiqués à l’autorité compétente

Le cadre TLPT s’inspire du framework européen TIBER-EU, utilisé par plusieurs banques centrales.

Le lien avec la sensibilisation

Les TLPT incluent régulièrement des scénarios de phishing et d’ingénierie sociale dans leurs tests. Un collaborateur qui clique sur un email de simulation durant un TLPT expose une faille que l’entité doit corriger — et la correction passe par la formation.

Les résultats des TLPT alimentent les programmes de sensibilisation exigés par l’article 13 : les scénarios qui ont fonctionné lors du test deviennent des cas d’étude pour les formations. Tester, identifier les faiblesses humaines, former, retester.

Comment se préparer à DORA

DORA est applicable depuis janvier 2025. Si votre entité est dans le périmètre, la conformité n’est plus un projet — c’est une obligation en cours.

Étape 1 : évaluer votre situation

Identifiez où votre organisation se situe par rapport aux cinq axes. Les écarts fréquents chez les PME du secteur financier : cadre de gestion des risques TIC non formalisé, registre des prestataires TIC incomplet, programme de sensibilisation absent ou limité à un module e-learning annuel, tests de résilience non planifiés.

Étape 2 : structurer la gestion des risques TIC

Formalisez votre cadre de gestion des risques conformément aux articles 5 à 16. Documentez votre politique de sécurité TIC et faites-la approuver par la direction. Déployez les protections techniques de base : MFA sur tous les accès, EDR sur les postes, supervision via un SIEM ou un SOC externalisé.

Étape 3 : cartographier vos prestataires TIC

Constituez le registre de vos prestataires TIC. Pour chaque prestataire supportant une fonction critique, documentez la nature du service et la dépendance, vérifiez les clauses contractuelles obligatoires (niveaux de service, droits d’audit, notification d’incidents, stratégie de sortie) et évaluez les risques de concentration.

Étape 4 : déployer un programme de sensibilisation conforme

Lancez des simulations de phishing régulières adaptées au contexte financier, formez la direction aux risques TIC (obligation de l’article 13), documentez chaque session et mesurez l’évolution des indicateurs (taux de clic, taux de signalement).

Notre solution de simulation de phishing et nos modules de conformité sont conçus pour répondre aux exigences de l’article 13 de DORA — scénarios sectoriels financiers, reporting documenté, traçabilité complète.

Étape 5 : planifier les tests de résilience

Établissez un calendrier de tests conforme aux exigences de DORA. Si votre entité est identifiée pour les TLPT, engagez un prestataire qualifié et préparez le périmètre de test en amont. Pour les autres entités, un programme régulier de tests de vulnérabilités et de pentests couvre les exigences de base.

Évaluez la première ligne de défense de votre entité financière. Notre test de sécurité email vérifie la configuration SPF, DKIM et DMARC de votre domaine — les protocoles d’authentification qui empêchent l’usurpation d’identité par email, un vecteur d’attaque récurrent dans le secteur financier.

Le texte intégral du règlement DORA est disponible sur EUR-Lex. L’ACPR et l’ANSSI publient des recommandations et guides d’accompagnement pour les entités françaises concernées.