Règlement DORA : ce qu’il change vraiment
Un incident cyber qui bloque un service critique ne relève plus seulement de la sécurité informatique. Pour les établissements financiers et leurs prestataires essentiels, le règlement DORA redéfinit le sujet comme une question de résilience opérationnelle, de gouvernance et de capacité démontrable à continuer, dégrader ou reprendre. C’est ce changement de perspective qui explique sa portée.
Le texte n’ajoute pas simplement une couche réglementaire de plus. Il cherche à corriger une faiblesse bien connue des organisations matures : des dispositifs parfois performants en silos, mais insuffisamment intégrés entre gestion des risques TIC, continuité d’activité, gestion de crise, supervision des tiers et tests. Pour les responsables PCA, PRA, SSI, risques ou conformité, l’enjeu est donc moins de produire de nouveaux documents que d’aligner des pratiques qui existent déjà, souvent partiellement.
Ce que couvre le règlement DORA
Le Digital Operational Resilience Act s’applique au secteur financier européen avec une ambition claire : faire de la résilience numérique un objet de pilotage homogène. Dans les faits, le règlement organise les attentes autour de cinq blocs étroitement liés.
Le premier bloc concerne la gestion des risques liés aux TIC. Ici, il ne s’agit pas seulement d’identifier des menaces cyber, mais de structurer un cadre de gouvernance, des rôles, des politiques, des processus de détection, de protection, de réponse et de rétablissement. Le niveau d’exigence attendu dépend de la taille, du profil de risque et de la complexité de l’entité. Ce point est essentiel, car DORA n’impose pas une standardisation aveugle. Il impose une approche démontrable et proportionnée.
Le deuxième bloc porte sur la gestion et la notification des incidents majeurs. Beaucoup d’organisations disposent déjà d’un processus de remontée des incidents de sécurité. DORA pousse plus loin en demandant des critères de classification, des circuits d’escalade, une coordination entre métiers, conformité, juridique, IT et communication, ainsi qu’une capacité à notifier selon un cadre formalisé. La difficulté n’est pas théorique. Elle réside souvent dans le délai, la qualité de qualification de l’incident et la cohérence des informations partagées.
Le troisième bloc traite des tests de résilience opérationnelle numérique. C’est un point particulièrement structurant pour les équipes. Les tests ne peuvent plus être perçus comme une vérification technique isolée. Ils doivent refléter les services critiques, les scénarios plausibles, les dépendances internes et externes, ainsi que la capacité réelle de l’organisation à fonctionner en mode dégradé. Pour certaines entités, des tests avancés, y compris de type threat-led, entrent dans le périmètre.
Le quatrième bloc concerne la gestion du risque lié aux prestataires TIC tiers. C’est souvent là que les écarts apparaissent le plus nettement. Une organisation peut avoir des procédures internes solides tout en reposant sur des fournisseurs insuffisamment évalués, mal contractualisés ou trop concentrés. DORA impose une vision plus rigoureuse de l’externalisation et des dépendances numériques, avec une attention particulière portée aux prestataires critiques.
Enfin, le cinquième bloc vise le partage d’informations sur les menaces cyber, dans un cadre organisé. Cette dimension reste parfois secondaire dans les feuilles de route, alors qu’elle participe à la maturité collective du secteur.
Pourquoi DORA concerne directement la continuité d’activité
Beaucoup d’acteurs ont d’abord lu DORA comme un texte cyber. C’est une erreur d’interprétation fréquente. Le règlement parle de résilience opérationnelle numérique, ce qui place immédiatement la continuité d’activité et la gestion de crise au centre du dispositif.
Un service peut être protégé par de bons contrôles de sécurité et rester pourtant insuffisamment résilient. Il suffit qu’une dépendance applicative soit mal cartographiée, qu’un fournisseur cloud soit insuffisamment intégré au dispositif de crise, ou qu’aucun scénario de fonctionnement dégradé n’ait été réellement testé. DORA oblige à relier disponibilité, reprise, décisions de crise, communication et gouvernance des tiers.
Pour lesresponsables PCAet PRA, cela change la nature des travaux attendus. Les plans ne doivent plus seulement exister. Ils doivent être cohérents avec l’architecture TIC, les impacts métier, les seuils de tolérance, les modalités d’escalade et les exigences de notification. Cette articulation est décisive au moment d’un contrôle ou d’un audit, car c’est souvent là que se révèle l’écart entre documentation et capacité opérationnelle.
Les écarts les plus fréquents sur le terrain
Dans les organisations déjà structurées, les difficultés ne viennent pas toujours d’un manque de dispositifs. Elles viennent plus souvent d’un manque d’alignement.
Le premier écart touche à la gouvernance. Les responsabilités existent, mais restent dispersées entre SSI, production, risques, conformité, achats, continuité d’activité et métiers. Or DORA suppose des arbitrages clairs, une supervision active et une capacité du management à comprendre les dépendances critiques. Sans ce pilotage transversal, les décisions sont lentes et les priorités contradictoires.
Le deuxième écart concerne la cartographie. Beaucoup d’entreprises connaissent leurs processus critiques sans disposer d’une vision suffisamment exploitable des ressources TIC, des applications support, des flux, des tiers et des points de concentration. Cette limite rend les analyses d’impact incomplètes et affaiblit les scénarios de test.
Le troisième écart apparaît dans les exercices. Les tests restent parfois techniques, ou au contraire trop déclaratifs. Or un exercice utile doit éprouver la chaîne complète : détection, qualification, décision, coordination de crise, reprise, communication et retour d’expérience. Le test n’a de valeur que s’il met en évidence des arbitrages réels.
Le quatrième écart se situe dans la relation fournisseurs. Les clauses contractuelles, les droits d’audit, les exigences de notification, les plans de sortie ou les mécanismes de surveillance continue ne sont pas toujours au niveau attendu. Ce sujet devient critique quand un petit nombre de prestataires supporte une grande partie des opérations essentielles.
Comment mettre le règlement DORA en œuvre de manière crédible
La tentation est forte de lancer un programme DORA comme un projet réglementaire classique, centré sur la production de preuves. Ce serait un angle trop étroit. Une démarche crédible commence par un diagnostic de maturité orienté opération.
Il faut d’abord identifier les services et processus critiques, puis vérifier si les actifs TIC, les applications, les données, les fournisseurs et les rôles de crise associés sont correctement cartographiés. Cette étape paraît basique, mais elle conditionne tout le reste. Sans elle, impossible de prioriser les tests, d’évaluer les impacts ou de qualifier un incident majeur avec fiabilité.
Vient ensuite le travail de convergence entre cadres existants. Dans beaucoup d’organisations, l’ISO 22301, les politiques SSI, les PRA, les procédures de gestion de crise et les exigences d’externalisation vivent encore à des rythmes différents. DORA ne demande pas nécessairement de repartir de zéro. Il demande de démontrer que ces briques fonctionnent ensemble. C’est une nuance importante, car elle permet d’éviter les programmes lourds et peu productifs.
Les tests doivent ensuite être revusavec une logique métier. Un bon programme de tests n’essaie pas de tout couvrir au même niveau. Il cible les scénarios les plus structurants, les dépendances les plus sensibles et les décisions les plus difficiles. Selon les cas, il peut être plus utile de tester un mode dégradé de service qu’une reprise complète idéalisée mais peu réaliste dans les délais attendus.
Sur les tiers, l’approche efficace combine revue contractuelle, analyse de concentration, évaluation de criticité et mécanismes de suivi. Là encore, tout dépend du contexte. Le niveau d’effort n’est pas le même pour un fournisseur périphérique et pour un prestataire qui supporte une fonction essentielle. La proportionnalité reste un principe utile, à condition d’être argumentée.
Enfin, la formation joue un rôle souvent sous-estimé. DORA crée une exigence de compétence collective, pas seulement de conformité documentaire. Les équipes en charge de la continuité, de la crise, des risques, de l’IT et de la cybersécurité doivent partager un langage commun, des critères communs et des réflexes communs. C’est précisément dans cette zone que la professionnalisation fait la différence entre un dispositif formel et une capacité réellement mobilisable.
Règlement DORA et supervision : ce que les autorités regarderont
Les autorités ne se limiteront pas à vérifier l’existence de politiques. Elles chercheront des preuves de pilotage, de cohérence et d’amélioration continue. Cela implique des indicateurs utiles, des décisions tracées, des revues régulières, des exercices documentés et des plans d’action suivis.
Une organisation mature n’est pas celle qui prétend tout maîtriser. C’est celle qui connaît ses dépendances, ses limites, ses scénarios de rupture et ses capacités de rétablissement. Sous cet angle, le règlement DORA agit comme un révélateur. Il distingue les dispositifs conçus pour être présentables de ceux conçus pour tenir sous contrainte.
Pour les professionnels de la résilience, le sujet est donc stratégique. Il ne s’agit pas seulement de répondre à une attente réglementaire, mais de renforcer un cadre de décision et d’action face à des incidents qui combinent désormais technologie, opérations, fournisseurs et réputation. Desparcours de formation spécialisés, comme ceux proposés par DRI France, peuvent utilement structurer cette montée en compétence lorsqu’il faut transformer des exigences transverses en pratiques opérationnelles maîtrisées.
Le bon réflexe n’est pas de demander si DORA ajoute du travail. Il est de se demander quelles fragilités de coordination, de test ou de gouvernance le texte met enfin en lumière, et lesquelles votre organisation peut traiter dès maintenant avec méthode.
This post is also available in:




Laisser un commentaire
Rejoindre la discussion?N’hésitez pas à contribuer !