La conformité DORA s’impose depuis janvier 2025 à l’ensemble du secteur financier européen : banques, assurances, sociétés de gestion, établissements de paiement — et par ricochet à leurs prestataires IT critiques. Le règlement sur la résilience opérationnelle numérique (Digital Operational Resilience Act) transforme la gestion du risque informatique en obligation prudentielle contrôlée par les superviseurs.
Ce guide décompose la conformité DORA en 5 piliers opérationnels, avec les chantiers concrets pour un DSI ou RSSI. Voir aussi notre page management de transition IT banque & assurance.
Table des matières
Pilier 1 — Gouvernance et gestion des risques TIC
DORA place la responsabilité au sommet : l’organe de direction porte formellement le risque numérique, doit le comprendre et allouer les moyens. Le cadre de gestion des risques TIC doit être documenté, revu annuellement et couvrir l’ensemble du cycle : identification des fonctions critiques, protection, détection, réponse et rétablissement.
Concrètement, cela exige une cartographie à jour des actifs et des fonctions critiques ou importantes (FCI), avec leurs dépendances — le socle sur lequel tous les autres piliers s’appuient. C’est le premier chantier à lancer, et le plus structurant.
Pilier 2 — Gestion et notification des incidents
Les incidents TIC doivent être détectés, classifiés selon des critères harmonisés, et les incidents majeurs notifiés au superviseur selon un calendrier serré : notification initiale rapide, rapport intermédiaire, puis rapport final. Cela suppose une chaîne outillée : détection, qualification, escalade et modèles de rapports prêts à l’emploi.
Le test de réalité est simple : si un incident majeur survenait demain, sauriez-vous produire la notification initiale dans les délais avec les informations exigées ? Dans la plupart des organisations, la réponse honnête est non — c’est un chantier de processus plus que d’outils.
Pilier 3 — Tests de résilience opérationnelle numérique
DORA impose un programme de tests proportionné : tests de vulnérabilité, tests de scénarios, exercices de continuité — et pour les entités désignées comme significatives, des tests de pénétration fondés sur la menace (TLPT, cadre TIBER) tous les trois ans, menés par des testeurs qualifiés sur les systèmes de production.
L’esprit du texte : prouver par l’exercice, pas par le document. Un plan de continuité jamais testé ne vaut rien aux yeux du superviseur — planifiez un calendrier annuel de tests avec remédiation tracée des constats.
Pilier 4 — Maîtriser le risque des prestataires TIC
C’est le pilier le plus transformant : chaque entité doit tenir un registre d’information exhaustif de ses contrats TIC (transmis au superviseur), évaluer la criticité de chaque prestataire, et intégrer dans les contrats des clauses obligatoires — audit, sécurité, localisation des données, stratégie de sortie, sous-traitance en cascade.
Les prestataires critiques (cloud notamment) entrent en outre dans un régime de supervision européenne directe. Pour le DSI, cela signifie renégocier les contrats existants, documenter les stratégies de sortie et éviter les dépendances non substituables — un travail contractuel et d’architecture de 12 à 18 mois dans une organisation moyenne.
Pilier 5 — Partage d’information et mise en conformité
DORA encourage le partage de renseignements sur les cybermenaces entre entités financières, dans un cadre protégé. Au-delà, la conformité DORA se pilote comme un programme : gap analysis initiale contre les cinq piliers, feuille de route priorisée par le risque, et gouvernance de suivi impliquant DSI, RSSI, risques et conformité.
L’erreur classique est d’en faire un projet documentaire mené par la seule conformité : sans le DSI et le RSSI aux commandes, les exigences opérationnelles (cartographie, tests, incidents) restent sur le papier — et ne résistent pas à une inspection.
FAQ sur la conformité DORA
Qui est concerné par DORA ?
La quasi-totalité des entités financières régulées de l’UE — une vingtaine de catégories : banques, assurances, gestion d’actifs, paiement, crypto-actifs… — ainsi que, indirectement, tout prestataire TIC servant ces entités, via les clauses contractuelles obligatoires.
Quelles sanctions en cas de non-conformité ?
DORA s’appuie sur les pouvoirs des superviseurs nationaux (ACPR en France) : injonctions, astreintes et sanctions administratives selon les régimes sectoriels, sans plafond harmonisé. Le vrai risque immédiat est prudentiel et réputationnel — exigences renforcées, publicité des mesures.
Nous sommes prestataire IT de banques : que devons-nous faire ?
Attendez-vous à des avenants contractuels (audit, sécurité, réversibilité, sous-traitance) et à devoir documenter votre propre résilience. Anticiper ces exigences devient un avantage commercial pour vendre au secteur financier.
DORA remplace-t-il NIS2 ?
Non, les deux coexistent : DORA est la lex specialis du secteur financier (il prime pour les entités financières), NIS2 couvre un champ plus large d’entités essentielles et importantes. Un groupe peut être soumis aux deux selon ses activités.
Conformité DORA : l’essentiel
La conformité DORA tient en 5 piliers : gouvernance du risque TIC, gestion des incidents, tests de résilience, maîtrise des prestataires et partage d’information. Les chantiers les plus lourds — cartographie des fonctions critiques et registre des prestataires — sont aussi ceux qui apportent le plus de valeur au-delà de la conformité.
Nos DSI et RSSI de transition, rompus aux environnements régulés, pilotent votre programme DORA de la gap analysis à l’inspection. Parlons de votre situation.