- Entrée en application
- 17 janvier 2025
- Type d'acte
- Règlement européen (applicable directement)
- Entités concernées
- ~22 000 entités financières UE + prestataires critiques
- Autorités FR
- ACPR · AMF
- Autorités européennes
- EBA · ESMA · EIOPA (ESAs)
01 — DéfinitionQu'est-ce que DORA ?
Source officielle : règlement DORA sur EUR-Lex.
DORA (Digital Operational Resilience Act) est un règlement européen adopté en décembre 2022 et applicable depuis le 17 janvier 2025. Il vise à harmoniser et renforcer la résilience opérationnelle numérique du secteur financier européen face aux risques informatiques, y compris cyber.
Avant DORA, la résilience numérique des entités financières était traitée à travers un patchwork de textes sectoriels par sous-secteur (banques, assurances, marchés, fonds) et par pays. DORA uniformise ces exigences en un règlement unique, directement applicable dans toute l'UE, avec une logique de résilience intégrée à la stabilité financière.
Le règlement couvre six grands domaines :
- La gouvernance et la gestion des risques TIC au plus haut niveau.
- La gestion et le reporting des incidents majeurs.
- Les tests de résilience, incluant les TLPT pour les entités significatives.
- La gestion des risques liés aux prestataires tiers de services TIC.
- Le partage d'informations sur les cybermenaces entre acteurs.
- La supervision directe des prestataires critiques par les autorités européennes.
Trois autorités européennes supervisent l'application : EBA (banques), ESMA (marchés) et EIOPA (assurances), regroupées sous l'acronyme ESAs (European Supervisory Authorities). En France, l'ACPR et l'AMF sont les autorités de contrôle nationales.
DORA est le premier texte européen à soumettre directement les hyperscalers cloud (AWS, Microsoft, Google Cloud) à la supervision des régulateurs financiers. Un changement de paradigme majeur dans le rapport de force entre banques et big tech.
02 — EntitésQui est concerné
Les 20 catégories d'entités financières
DORA s'applique à une liste exhaustive de 20 types d'entités, parmi lesquelles :
- Établissements de crédit (banques).
- Établissements de paiement et de monnaie électronique.
- Entreprises d'investissement.
- Sociétés de gestion d'OPCVM et de FIA.
- Entreprises d'assurance, de réassurance et intermédiaires.
- Infrastructures de marché (bourses, chambres de compensation, dépositaires centraux).
- Agences de notation.
- Prestataires de services sur actifs numériques (MiCA).
- Prestataires de financement participatif.
- Fonds de pension professionnels.
Au total, environ 22 000 entités sont concernées dans l'UE. En France, le périmètre représente plusieurs milliers d'entités supervisées par l'ACPR ou l'AMF.
Proportionnalité
DORA applique le principe de proportionnalité : les exigences sont plus légères pour les petites structures et plus strictes pour les grandes et les infrastructures critiques. Les micro-entreprises et certaines petites entités bénéficient d'un régime simplifié, mais les principes généraux restent applicables.
Prestataires tiers de services TIC
DORA introduit un périmètre inédit : les prestataires tiers de services TIC qui fournissent des services aux entités financières. Cette catégorie inclut les hyperscalers cloud (AWS, Microsoft Azure, Google Cloud), les éditeurs de logiciels métier (FIS, Temenos, Murex), les fournisseurs de données de marché, les télécoms, et toute entreprise IT fournissant le secteur financier.
Ces prestataires sont soumis à des exigences contractuelles et, pour ceux jugés critiques par les ESAs, à une supervision directe par les autorités européennes.
Extraterritorialité
Comme beaucoup de règlements européens récents, DORA s'applique aussi aux prestataires non-UE qui fournissent des entités financières européennes. Un hyperscaler américain opérant en Europe est donc directement soumis à DORA pour ses clients financiers UE.
03 — PiliersLes 5 piliers de DORA
1. Gestion des risques TIC
Chaque entité doit mettre en place un cadre de gestion des risques TIC complet et documenté, approuvé par l'organe de direction. Le cadre doit couvrir :
- Identification des actifs TIC et cartographie des dépendances.
- Analyses de risques régulières et stratégie de réduction des risques.
- Mesures techniques et organisationnelles (cybersécurité, protection des données, continuité).
- Gouvernance claire avec responsabilités au niveau du comité exécutif.
- Formation continue des collaborateurs.
- Revue annuelle du cadre par l'organe de direction.
2. Gestion et reporting des incidents TIC
Les entités doivent disposer d'un processus documenté pour détecter, gérer et notifier les incidents majeurs. Les critères de classification sont harmonisés par les ESAs, avec des seuils précis (nombre de clients affectés, montant financier impacté, durée, réputation, impact sur le marché).
Pour les incidents majeurs, un reporting structuré est obligatoire vers l'autorité compétente :
- Notification initiale rapide (délai strict, généralement 4 heures).
- Rapport intermédiaire dans les 72 heures.
- Rapport final dans le mois.
Les cybermenaces significatives font l'objet d'un reporting dédié, même en l'absence d'incident effectif.
3. Tests de résilience opérationnelle
DORA impose un programme de tests régulier adapté à la taille et au profil de risque. Le socle commun comprend :
- Scans de vulnérabilités.
- Revues de sécurité (code, architecture).
- Tests d'intrusion classiques périodiques.
- Tests de bout en bout des processus critiques.
- Tests de scénarios et simulations de crise.
Pour les entités significatives, une obligation renforcée : les TLPT (Threat-Led Penetration Testing) tous les trois ans minimum. Voir section dédiée.
4. Gestion des risques liés aux prestataires tiers
Un des apports majeurs de DORA. Chaque entité doit :
- Tenir un registre complet de tous ses prestataires TIC.
- Identifier ceux qui fournissent des fonctions critiques ou importantes.
- Encadrer contractuellement : exigences de sécurité, auditabilité, localisation des données, sous-traitance, réversibilité.
- Évaluer les risques de concentration sur un même prestataire.
- Prévoir des stratégies de sortie documentées pour chaque prestataire critique.
- Notifier à l'autorité tout arrangement contractuel concernant une fonction critique.
5. Partage d'informations sur les cybermenaces
DORA encourage (sans l'imposer) le partage d'informations entre entités financières sur les menaces cyber : IOC, TTP, campagnes actives, vulnérabilités exploitées. Ce partage se fait dans un cadre sécurisé, avec des garanties de confidentialité. Il s'appuie en pratique sur des structures sectorielles existantes (CERT sectoriels, ISACs, associations professionnelles).
04 — TLPTLes tests d'intrusion avancés
Les TLPT (Threat-Led Penetration Testing) sont des exercices Red Team avancés obligatoires pour les entités significatives sous DORA. Ils s'inspirent directement du framework TIBER-EU (Threat Intelligence-Based Ethical Red Teaming) développé par la BCE depuis 2018.
Principe
Un TLPT simule une attaque cyber réaliste contre les fonctions critiques en production, en suivant des TTP d'acteurs de menace actuellement actifs contre le secteur financier. L'objectif : tester la chaîne complète détection-réponse-résilience dans des conditions proches du réel.
Organisation
Un TLPT mobilise plusieurs acteurs :
- L'équipe TLPT côté entité — confidentielle, pilote le test.
- Le TI provider — fournit le renseignement de menace adapté à l'entité.
- Le Red Team provider — exécute l'attaque simulée.
- Le SOC / Blue Team — ne sait pas qu'un test est en cours, détecte et répond comme pour une vraie attaque.
- L'autorité de contrôle — supervise l'exercice et reçoit les conclusions.
Déroulement typique
- Préparation (2-3 mois) : cadrage, identification des fonctions critiques, constitution des équipes.
- Threat intelligence (1-2 mois) : le TI provider produit un rapport de menace spécifique.
- Attaque (3-6 mois) : le Red Team mène l'attaque en conditions réelles, sans prévenir le SOC.
- Retour d'expérience : analyse conjointe, plan d'actions correctives, reporting à l'autorité.
Durée et fréquence
Un TLPT complet dure généralement 6 à 12 mois de l'initiation au rapport final. La fréquence obligatoire est d'au moins un tous les 3 ans pour les entités soumises. Le coût typique se situe entre 500 000 € et plusieurs millions d'euros selon l'ampleur.
Entités concernées
Les autorités nationales identifient chaque année les entités soumises à TLPT selon des critères harmonisés : taille, criticité systémique, complexité, profil de risque. En France, cela concerne principalement les grands groupes bancaires, les grandes infrastructures de marché, les grandes entreprises d'assurance. Environ 100-200 entités en France sont dans le périmètre TLPT.
05 — TiersLa supervision des prestataires critiques
C'est l'innovation la plus structurante de DORA. Les ESAs désignent certains prestataires tiers TIC comme « critiques » (Critical Third-Party Providers, CTPP) et les placent sous supervision directe européenne.
Critères de désignation
- Importance systémique pour le fonctionnement du secteur financier.
- Substituabilité limitée ou nulle des services fournis.
- Concentration forte de clients financiers.
- Volumétrie et criticité des services.
En pratique, les principaux prestataires désignés sont les hyperscalers cloud (AWS, Microsoft, Google Cloud), certains éditeurs de core banking et d'infrastructure financière, certains fournisseurs de données de marché critiques, et quelques acteurs télécom.
Pouvoirs des ESAs
Pour les prestataires critiques, les ESAs disposent de pouvoirs étendus :
- Demande d'informations et d'auditabilité.
- Inspections sur site, y compris des datacenters.
- Émission de recommandations contraignantes.
- Demande de plans d'actions correctives.
- Amendes pouvant atteindre 1% du CA mondial journalier pour non-respect (application progressive).
- Obligation pour les entités financières de ne plus utiliser un prestataire jugé non conforme.
Impact concret pour les prestataires
Les hyperscalers et éditeurs critiques ont dû adapter leurs offres, leurs contrats et leur organisation :
- Équipes dédiées de liaison réglementaire avec les ESAs.
- Offres spécifiques « DORA ready » avec garanties contractuelles renforcées.
- Transparence accrue sur les datacenters, les sous-traitants, les procédures.
- Capacité d'audit étendue pour les entités financières clientes.
- Localisation européenne de certaines fonctions critiques (souveraineté de facto).
Impact pour les entités financières
Les entités financières bénéficient indirectement de cette supervision (transparence, pouvoir de négociation contractuelle) mais ne sont pas dédouanées. Elles restent intégralement responsables de la gestion de leurs prestataires, même quand ces derniers sont sous supervision européenne. Le registre des prestataires, l'évaluation des risques et les stratégies de sortie restent de leur responsabilité pleine et entière.
06 — ArticulationDORA et NIS2
Lex specialis
DORA et NIS2 partagent des objectifs communs (résilience cyber, reporting d'incidents, gestion des risques). Pour éviter le cumul d'obligations redondantes, DORA est le texte spécial pour le secteur financier : il prime sur NIS2 pour les entités qu'il couvre.
Concrètement : une banque ou un assureur n'est pas soumis à NIS2 pour ses activités financières — DORA suffit. Seules certaines obligations très spécifiques de NIS2 (notamment en matière de chaîne d'approvisionnement pour certains services) peuvent encore s'appliquer marginalement.
Différences clés
- Spécialisation sectorielle : DORA est taillé pour le financier ; NIS2 couvre de nombreux secteurs.
- Détail opérationnel : DORA est plus prescriptif (contenu du registre des prestataires, exigences contractuelles précises, modalités de tests).
- TLPT : spécifique à DORA, pas d'équivalent obligatoire dans NIS2.
- Supervision des prestataires : DORA introduit une supervision directe des prestataires critiques, inexistante dans NIS2.
- Reporting : délais et formats harmonisés dans DORA, plus variables dans NIS2.
Articulation avec le RGPD
Le RGPD reste pleinement applicable en parallèle pour la protection des données personnelles. Un incident DORA qui implique une fuite de données personnelles doit être notifié à la fois à l'autorité financière (ACPR/AMF au titre de DORA) et à la CNIL (au titre du RGPD), dans leurs délais respectifs.
07 — SanctionsRégime de sanctions et gouvernance
Sanctions aux entités financières
DORA ne définit pas de plafond d'amende uniforme à l'échelle UE — les sanctions sont précisées par chaque État membre dans sa transposition. En France, l'ACPR et l'AMF disposent de leurs pouvoirs habituels :
- Avertissement et blâme.
- Sanctions pécuniaires pouvant atteindre plusieurs millions d'euros.
- Interdiction temporaire ou définitive d'exercer certaines activités.
- Injonction de mise en conformité.
- Publication des décisions — impact réputationnel majeur.
Sanctions aux prestataires critiques
Les ESAs peuvent imposer des sanctions administratives aux prestataires critiques sous leur supervision directe. Le plafond est significatif : 1% du CA mondial journalier moyen pour non-respect des recommandations contraignantes. Ces sanctions s'ajoutent aux conséquences contractuelles et commerciales (perte de clients financiers, désignation obligatoire).
Gouvernance interne exigée
Au-delà des sanctions, DORA impose un niveau de gouvernance interne élevée :
- Responsabilité finale du conseil d'administration / direction.
- Approbation formelle du cadre de gestion des risques TIC.
- Reporting régulier du RSSI ou équivalent au conseil.
- Formation continue des membres du conseil aux enjeux cyber.
- Revue annuelle formelle de l'ensemble du dispositif.
La responsabilité n'est plus déléguable au seul service IT ou sécurité : les dirigeants sont personnellement engagés.
Première année d'application — retours
L'entrée en application au 17 janvier 2025 a été préparée pendant deux ans. Les premiers retours : un effort massif des grands établissements sur le registre des prestataires et la classification des fonctions critiques, tensions contractuelles avec les hyperscalers, premières désignations de prestataires critiques par les ESAs en 2025, premiers reportings d'incidents au nouveau format. Les autorités ont adopté une posture pédagogique durant la première année, laissant anticiper un passage à une phase plus contrôlante en 2026-2027.
08 — FAQQuestions fréquentes
Je suis un éditeur de logiciel qui vend aux banques, suis-je concerné ?
Oui, indirectement mais concrètement. Même si vous n'êtes pas directement désigné comme prestataire critique, vos clients financiers vont vous imposer des exigences contractuelles fortes issues de DORA : auditabilité, résilience documentée, obligations de reporting d'incidents, clauses de réversibilité. Anticiper ces demandes dans votre offre est devenu un avantage commercial significatif.
DORA impose-t-il le cloud souverain européen ?
Non directement. DORA n'impose pas de localisation géographique stricte. Mais les exigences sur l'auditabilité, la juridiction applicable, les stratégies de sortie, et la concentration poussent de fait vers plus de diversification et plus de souveraineté. Certaines autorités nationales recommandent explicitement les offres cloud qualifiées (en France : SecNumCloud) pour les fonctions les plus critiques.
Comment préparer un registre des prestataires conforme ?
Les ESAs ont publié en 2024 un format standardisé précis (ITS — Implementing Technical Standards). Le registre doit inclure pour chaque prestataire : identité complète, services fournis, localisation, sous-traitants, fonctions critiques associées, évaluation des risques, stratégies de sortie, contrat. Le registre est transmis annuellement à l'autorité de contrôle. La construction initiale représente typiquement 3 à 6 mois de travail pour une grande entité.
Faut-il un cadre TIC séparé de la gouvernance globale ?
Non, l'idée est plutôt d'intégrer le cadre TIC à la gouvernance des risques globale de l'entité. Cela évite la duplication, assure la cohérence avec la gestion des risques opérationnels plus large, et facilite le reporting au comité exécutif. Le cadre peut toutefois faire l'objet d'une section dédiée bien identifiable dans la documentation globale.
Quel rôle pour le RSSI sous DORA ?
Renforcé et élargi. Le RSSI devient un acteur central de la conformité DORA, avec un rôle de pilotage technique mais aussi stratégique. Il participe à la gouvernance, présente régulièrement au comité exécutif, pilote les exercices de test, coordonne le reporting d'incidents, supervise la gestion des prestataires TIC critiques. Dans plusieurs grandes entités, le poste a été revu avec un rattachement direct à la direction générale plutôt qu'à la DSI.