Le règlement DORA (Digital Operational Resilience Act, règlement UE 2022/2554) est entré en vigueur le 17 janvier 2025 pour toutes les entités financières soumises à la surveillance dans l'Union européenne. Il ne s'agit pas d'une directive que chaque État membre transpose à son propre rythme : c'est un règlement d'application directe, ce qui signifie qu'à partir de cette date les superviseurs — la BCE, l'EBA, l'EIOPA, l'ESMA et, en Espagne, la Banque d'Espagne et la CNMV — peuvent demander des preuves de conformité à tout moment. Si votre établissement n'a pas encore de programme formel, vous êtes déjà en infraction.
Cet article ne répète pas le texte du règlement. Ce que vous trouverez ici est une feuille de route opérationnelle : que faut-il faire, dans quel ordre, où la plupart des organisations se bloquent et comment structurer le travail pour atteindre un niveau de conformité défendable devant le superviseur sans consommer deux ans de ressources.
Que exige réellement DORA ? Les cinq piliers
Le règlement articule la résilience opérationnelle numérique autour de cinq blocs qui ne sont pas indépendants, mais qui s'alimentent mutuellement. Comprendre la logique de l'ensemble permet d'éviter l'erreur habituelle qui consiste à traiter DORA comme une liste de contrôle sans fil conducteur.
1. Gestion du risque TIC (articles 5 à 16)
L'entité doit disposer d'un cadre de gestion du risque TIC documenté, approuvé par l'organe de direction et révisé au moins une fois par an. Ce cadre comprend l'identification des actifs TIC critiques, l'évaluation des risques, les mesures de protection, les procédures de réponse et de récupération, ainsi que le retour d'expérience après les incidents. L'organe d'administration assume une responsabilité directe et non délégable : DORA est explicite sur le fait que les membres du conseil doivent maintenir une connaissance suffisante des risques TIC.
2. Gestion, classification et notification des incidents (articles 17 à 23)
Les entités doivent classifier les incidents TIC selon des critères harmonisés que les Autorités européennes de surveillance (AES) ont précisés dans des normes techniques de réglementation (RTS). Les incidents « majeurs » sont notifiés en trois étapes : notification initiale (dans les 4 heures suivant la classification, ou au maximum 24 heures après la détection), rapport intermédiaire et rapport final. Le non-respect du délai de notification constitue, à lui seul, un motif de sanction.
3. Tests de résilience opérationnelle numérique (articles 24 à 27)
Toutes les entités doivent tester leurs outils et systèmes TIC au moins une fois par an. Les entités significatives — définies par des seuils de taille et de criticité — doivent aller plus loin et réaliser des tests de pénétration fondés sur les menaces (TLPT) tous les trois ans, conformément au cadre TIBER-EU. En Espagne, la Banque d'Espagne a déjà lancé des exercices TIBER avec des entités du secteur bancaire ; la CNMV prévoit de faire de même avec les entreprises d'investissement et les fonds.
4. Gestion du risque lié aux prestataires TIC tiers (articles 28 à 44)
Ce bloc est, en pratique, le plus coûteux à mettre en œuvre. DORA exige que les contrats avec les prestataires TIC critiques comprennent des clauses obligatoires : droits d'audit, garanties de continuité, sortie sans perturbation, niveaux de service, localisation des données et sous-traitance. Les entités doivent tenir un registre d'informations de tous leurs arrangements contractuels avec des tiers TIC, dans un format normalisé conformément aux RTS des AES. De plus, les prestataires TIC critiques directement désignés par les AES sont soumis à un cadre de surveillance directe communautaire.
5. Partage d'informations (article 45)
DORA encourage — et dans certains cas oblige — les entités à participer à des mécanismes de partage de renseignements sur les cybermenaces. En Espagne, le CCN-CERT (Centre cryptologique national) et le CERT Financier canalisent une grande partie de ces informations pour les entités supervisées.
Tableau comparatif : obligations selon le type d'entité
| Type d'entité | Cadre de risque TIC | Notification des incidents | Tests annuels | TLPT tous les 3 ans | Registre des tiers |
|---|---|---|---|---|---|
| Banque significative (MSU) | Complet + approbation du conseil | Oui (4h / 24h) | Oui | Oui (TIBER-EU) | Oui (format RTS) |
| Établissement de crédit moins significatif | Complet | Oui (4h / 24h) | Oui | À la discrétion du superviseur | Oui |
| Entreprise d'investissement | Complet | Oui | Oui | Si les seuils sont dépassés | Oui |
| Entreprise d'assurance / de réassurance | Complet (coordination avec Solvabilité II) | Oui | Oui | Si les seuils EIOPA sont dépassés | Oui |
| Établissement de paiement / monnaie électronique | Simplifié (art. 16) | Oui | Oui (tests de base) | Non obligatoire | Oui |
| Société de gestion de fonds (OPCVM / FIA) | Complet | Oui | Oui | Si désignée | Oui |
| Microentreprise (art. 3.1.k) | Simplifié | Oui | Oui (de base) | Non | Registre simplifié |
Source : règlement UE 2022/2554 (DORA) et RTS publiées par l'EBA, l'EIOPA et l'ESMA en 2024.
Feuille de route pratique : six phases pour atteindre une conformité défendable
L'expérience accumulée depuis 2007 en accompagnant des projets de conformité réglementaire dans le secteur financier nous a appris que les organisations qui tentent d'aborder DORA « en parallèle de l'activité courante » échouent ou produisent une documentation qui ne résiste pas à un examen du superviseur. La feuille de route que nous proposons à travers notre service de conseil NIS2 et DORA organise le travail en six phases séquentielles, bien que les deux premières puissent être exécutées en parallèle.
Phase 1 — Inventaire et classification des actifs TIC (semaines 1 à 4)
Sans inventaire, aucune gestion des risques n'est possible. Le point de départ est une cartographie complète de tous les systèmes, applications, infrastructures, données et services TIC, en distinguant les actifs propres des services fournis par des tiers. Pour chaque actif, on détermine sa criticité par rapport aux fonctions métier qu'il soutient : si ce système tombait en panne, quelle capacité opérationnelle serait perdue et en combien de temps ? Cette analyse d'impact (BIA, Business Impact Analysis) est le fondement de l'ensemble du programme.
Phase 2 — Évaluation des écarts (gap analysis) par rapport au cadre DORA (semaines 3 à 6)
L'inventaire en main, la situation actuelle est confrontée aux exigences du règlement et aux normes techniques de réglementation (RTS) et d'exécution (ITS) qui le développent. Les lacunes les plus fréquentes que nous rencontrons dans les entités de taille intermédiaire sont : l'absence de procédure formelle de classification des incidents, des contrats avec des prestataires TIC dépourvus de clauses DORA, et l'absence de tests de résilience documentés au-delà d'un simple test de récupération de sauvegarde. Le résultat de cette phase est une liste d'actions priorisées.
Phase 3 — Cadre de gestion du risque TIC et politique (semaines 5 à 12)
Le cadre de gestion du risque TIC de l'entité est rédigé ou mis à jour : politique approuvée par le conseil, méthodologie d'évaluation des risques, appétit pour le risque, rôles et responsabilités (y compris la fonction de RSSI ou équivalent), et procédures opérationnelles d'identification, de protection, de détection, de réponse et de récupération. Ce corpus documentaire est ce que le superviseur demandera à voir en premier lors de toute inspection.
Phase 4 — Remédiation des contrats avec les tiers TIC (semaines 8 à 20)
La renégociation des contrats avec les prestataires TIC est, de loin, la phase la plus longue. Les grands fournisseurs de cloud (AWS, Azure, Google Cloud) disposent d'avenants DORA/NIS2 préapprouvés, mais les prestataires intermédiaires de logiciels bancaires cœur, de gestion des risques ou d'infrastructure nécessitent généralement une négociation directe. L'entité doit prioriser les contrats de ses prestataires TIC critiques (ceux qui soutiennent des fonctions critiques ou importantes) et y intégrer les clauses minimales de l'article 30 de DORA : accessibilité, intégrité, sécurité, audit, continuité et sortie.
Phase 5 — Programme de tests et premier cycle d'exercices (semaines 12 à 24)
Le programme annuel de tests de résilience est conçu : tests de connectivité et de disponibilité, tests de reprise après sinistre (DR tests), simulations d'incidents avec l'équipe de réponse et, pour les entités qui l'exigent, planification du premier exercice TLPT avec un prestataire de threat intelligence accrédité. Le premier cycle de tests génère également le rapport de résultats que DORA impose de conserver et de mettre à la disposition du superviseur.
Phase 6 — Registre d'informations et gouvernance continue (semaines 20 à 28)
La phase finale établit le registre d'informations des tiers TIC dans le format exigé par les RTS (champs obligatoires, mise à jour périodique, traçabilité des modifications), les indicateurs de suivi du programme, le plan de formation de l'organe de direction en matière de risque TIC, et le calendrier des révisions annuelles. À partir de là, DORA est un cycle continu, non un projet avec une date de fin.
Les cinq erreurs qui retardent le plus la mise en conformité
En travaillant avec des entités qui ont atteint janvier 2025 sans programme formel, nous avons identifié les blocages qui consomment le plus de temps :
- Traiter DORA comme un projet informatique. Le règlement attribue la responsabilité directe au conseil. Sans véritable parrainage exécutif, le projet reste au niveau technique et la politique n'est jamais approuvée.
- Commencer par la documentation plutôt que par l'inventaire. Rédiger des politiques sans connaître les systèmes existants produit des documents qui ne reflètent pas la réalité et que le superviseur écarte.
- Sous-estimer le volume de contrats à renégocier. Une entité de taille intermédiaire comptant 80 à 120 prestataires TIC peut avoir 30 à 40 contrats nécessitant un avenant. Le processus juridique prend des mois.
- Confondre ISO 27001 et conformité DORA. ISO 27001 est compatible et facilite le travail, mais ne couvre pas les exigences spécifiques de DORA : classification des incidents selon les critères des AES, TLPT, registre des tiers ou notification dans des délais précis.
- Ne pas tenir compte des normes techniques de développement. Les RTS et ITS publiées par l'EBA, l'EIOPA et l'ESMA en 2024 précisent de nombreuses exigences que le texte du règlement laisse ouvertes. Sans les lire, la conformité reste incomplète.
DORA et NIS2 : zones de chevauchement et différences
De nombreuses entités financières sont simultanément soumises à DORA et à la directive NIS2 (en cours de transposition en Espagne par le biais du projet de loi sur la coordination et la gouvernance de la cybersécurité, encore en cours de procédure parlementaire à la date de cet article). La relation entre les deux instruments suit le principe de la lex specialis : DORA prévaut sur NIS2 pour les entités financières dans les domaines qu'il réglemente. En pratique, cela signifie qu'une entité financière n'a pas à se conformer à NIS2 « par-dessus » DORA en matière de gestion du risque TIC, mais doit clairement savoir quel superviseur contrôle quoi.
Pour les entités faisant partie de groupes avec des filiales dans des secteurs non financiers, la question est plus complexe : les filiales non financières peuvent être soumises à NIS2 tandis que la société mère financière se conforme à DORA. Le conseil spécialisé en NIS2 et DORA est essentiel pour délimiter correctement le périmètre de chaque réglementation dans les structures de groupe.
Délais et état de la supervision en Espagne (2025-2026)
DORA est applicable depuis le 17 janvier 2025, sans période transitoire supplémentaire. Cependant, la surveillance n'a pas été activée de manière homogène dès cette date : les superviseurs sont en phase de révision documentaire initiale et de publication des attentes. La Banque d'Espagne a publié en janvier 2025 une communication interne adressée aux entités significatives demandant l'état de mise en œuvre. La CNMV a lancé des questionnaires d'autoévaluation auprès des entreprises d'investissement et des sociétés de gestion.
L'horizon des premières inspections formelles susceptibles de déboucher sur des sanctions se situe, selon les signaux du marché et les déclarations publiques des superviseurs, entre le second semestre 2025 et le premier semestre 2026. Les entités qui, dans cette fenêtre, ne peuvent pas présenter un programme documenté et des preuves de tests effectués s'exposent à des exigences formelles et, dans les cas les plus graves, aux sanctions relevant des régimes de sanction sectoriels auxquels DORA renvoie (chapitre VII, articles 50-51). Le seuil de 1 % du chiffre d'affaires journalier moyen mondial prévu à l'article 64 de DORA s'applique spécifiquement aux prestataires TIC critiques désignés par les AES, et non aux entités financières, dont les sanctions sont déterminées par chaque législation sectorielle nationale.
Questions fréquentes
DORA s'applique-t-il à une petite fintech titulaire d'un agrément d'établissement de paiement ?
Oui, mais selon un régime simplifié. L'article 16 de DORA établit un cadre de gestion du risque TIC simplifié pour les microentreprises et certaines entités de plus petite taille. Les établissements de paiement et de monnaie électronique qui ne dépassent pas les seuils de classification en tant qu'entités significatives peuvent bénéficier de ce régime, qui réduit les exigences documentaires et de gouvernance, tout en maintenant les obligations de notification des incidents et la tenue du registre des prestataires TIC. En pratique, même dans le cadre du régime simplifié, une fintech doit disposer d'une politique TIC, d'une procédure de gestion des incidents et de contrats adaptés avec ses prestataires.
Que se passe-t-il si un prestataire TIC refuse de renégocier le contrat ?
DORA n'oblige pas le prestataire, il oblige l'entité financière. Si un prestataire assurant des services pour une fonction critique ou importante refuse d'intégrer les clauses de l'article 30, l'entité dispose de trois options : initier un processus formel de substitution, solliciter une exemption temporaire justifiée auprès du superviseur, ou accepter que le contrat n'est pas conforme et documenter la situation dans un plan de remédiation. La première option est la plus propre mais la plus coûteuse. En pratique, la plupart des grands fournisseurs de logiciels financiers ont déjà publié des avenants DORA ou sont en cours de le faire, leurs clients l'exigeant de manière généralisée.
Combien de temps faut-il pour achever le programme DORA dans une entité de taille intermédiaire ?
Dans les entités comptant entre 200 et 1 000 employés et disposant d'une infrastructure TIC d'une complexité modérée (50 à 100 prestataires TIC, systèmes cœur internes et en cloud), le programme complet pour atteindre un niveau de conformité défendable devant le superviseur demande entre 9 et 18 mois. Les facteurs qui allongent le plus le processus sont le volume de contrats à renégocier, la maturité préalable en matière de gestion du risque TIC et la capacité de l'équipe interne à absorber le travail parallèle. Démarrer avec une équipe externe spécialisée réduit le temps de 30 à 40 % lors des phases de gap analysis et d'élaboration du cadre documentaire.
Quelle est la différence entre les tests annuels et les TLPT ?
Les tests annuels que DORA impose à toutes les entités sont des exercices de vérification interne : tests de connectivité, tests de reprise après sinistre, simulations d'incidents. Ils ne nécessitent pas de prestataire externe spécifique ni de validation du superviseur. Les TLPT (Threat-Led Penetration Tests) sont des exercices avancés qui simulent les tactiques, techniques et procédures d'acteurs malveillants réels, en utilisant du renseignement sur les menaces actualisé. Ils sont réalisés tous les trois ans, avec des prestataires accrédités conformément au cadre TIBER-EU, sous la coordination du superviseur et avec accès aux systèmes de production. Ils sont bien plus invasifs, coûteux (entre 150 000 et 500 000 euros pour des entités de taille intermédiaire, selon la portée) et révèlent des vulnérabilités que les tests internes ne détectent pas.