DORA : ce que le règlement impose en tests de sécurité et de résilience

DORA : définition, pour Digital Operational Resilience Act, est un règlement européen : il s’applique directement, sans transposition nationale. Il vise un large éventail d’entités financières, dont les établissements de crédit, les établissements de paiement et de monnaie électronique, les entreprises d’investissement, les assureurs et intermédiaires d’assurance et les prestataires de services sur crypto-actifs, ainsi que les prestataires tiers de services informatiques critiques pour elles.

Le règlement module les exigences selon la taille et le profil de risque : les microentreprises bénéficient d’allégements, et certaines petites entités relèvent d’un cadre simplifié. Pour savoir ce qui s’applique à vous, lisez le champ d’application à l’article 2 du texte et faites valider votre situation avec votre autorité de supervision.

L’article 24 impose un programme de tests de résilience opérationnelle numérique, qui fait partie du cadre de gestion du risque informatique. Les tests suivent une approche fondée sur les risques, sont menés par des parties indépendantes, internes ou externes, avec des ressources suffisantes et l’absence de conflit d’intérêts lorsqu’un testeur interne intervient. Les faiblesses révélées doivent être classées, corrigées et vérifiées par des méthodes de validation internes. Les entités autres que les microentreprises doivent s’assurer, au moins une fois par an, que des tests appropriés sont menés sur tous les systèmes et applications qui soutiennent des fonctions critiques ou importantes.

L’article 25 donne une liste d’exemples de tests : évaluations de vulnérabilités et analyses, analyses de sources ouvertes, évaluations de sécurité du réseau, analyses d’écarts, revues de sécurité physique, questionnaires, revues de code source lorsque c’est possible, tests fondés sur des scénarios, tests de compatibilité, tests de performance, tests de bout en bout et tests d’intrusion. Le texte n’impose donc pas un test d’intrusion unique : il demande un programme combinant plusieurs types de tests.

L’article 26 prévoit que les entités financières identifiées par leur autorité réalisent, au moins tous les trois ans, des tests avancés par TLPT : définition (threat-led penetration testing). Ces tests couvrent plusieurs ou toutes les fonctions critiques ou importantes, et s’exécutent sur des systèmes de production en conditions réelles. L’autorité peut demander d’augmenter ou de réduire la fréquence selon le profil de risque.

Le TLPT ressemble à un exercice de red team : un scénario construit à partir de renseignements sur la menace qui pèse sur l’entité, mené contre ses systèmes réels, avec des règles d’engagement strictes. Le règlement délégué (UE) 2025/1190 précise les critères d’identification des entités soumises au TLPT, la méthode, le périmètre, les phases de test, la clôture et la remédiation.

Les tests ne sont qu’une partie du règlement. L’article 17 impose un processus de gestion des incidents liés aux technologies de l’information, qui enregistre tous les incidents et les cybermenaces importantes. L’article 19 impose la déclaration des incidents majeurs à l’autorité compétente. L’article 28 et suivants posent la gestion du risque lié aux prestataires informatiques tiers, avec un registre d’informations sur tous les accords contractuels de ce type.

La conséquence pratique est qu’un programme de tests ne suffit pas : il doit s’articuler avec la détection, la réponse à incident et le suivi des fournisseurs.

Les tests des articles 24 et 25 forment le socle, ouvert à toutes les entités autres que les microentreprises : tests d’intrusion applicatifs, évaluations de vulnérabilités, revues de configuration, revues de code, exercices fondés sur des scénarios. Ils peuvent être conduits par une équipe indépendante interne ou par un prestataire externe, selon les moyens et l’absence de conflit d’intérêts.

Le TLPT de l’article 26 est un exercice d’une autre ampleur, réservé aux entités désignées. Il se déroule sur les systèmes de production, vise des fonctions critiques ou importantes, part d’un renseignement sur la menace propre à l’entité et suit la méthode précisée par le règlement délégué. Il mobilise aussi l’équipe de défense de l’entité, souvent informée seulement d’une petite cellule de pilotage pour que la détection soit mise à l’épreuve.

En pratique, beaucoup d’entités financières n’ont pas à réaliser de TLPT, mais toutes celles qui entrent dans le champ doivent disposer du programme de tests. Pour savoir si vous êtes désigné, rapprochez-vous de votre autorité de supervision plutôt que d’une interprétation du texte.