Qu’est-ce que le test de résilience opérationnelle au sens de DORA ?

L’article 24, paragraphe 1, impose aux entités financières, autres que les microentreprises, d’établir, de maintenir et de réexaminer un programme solide et complet de tests de résilience opérationnelle numérique, qui fait partie intégrante du cadre de gestion du risque lié aux TIC de l’article 6. Le même paragraphe en fixe le but : évaluer l’état de préparation face aux incidents liés aux TIC, recenser les faiblesses, défaillances et lacunes, et mettre rapidement en œuvre des mesures correctives.

Le programme repose sur une approche fondée sur le risque. L’article 24, paragraphe 3, demande de tenir compte de l’évolution du risque lié aux TIC, des risques spécifiques auxquels l’entité est ou pourrait être exposée, et de la criticité des actifs informationnels et des services fournis. L’article 25, paragraphe 1, énumère ensuite les tests dans lesquels le programme peut puiser :

• évaluations et analyses de vulnérabilité, analyses de sources ouvertes ;
• évaluations de la sécurité des réseaux et analyses des écarts ;
• examens de la sécurité physique, questionnaires et solutions logicielles de balayage ;
• examens du code source lorsque cela est possible ;
• tests fondés sur des scénarios, tests de compatibilité, de performance et de bout en bout ;
• tests de pénétration.

Il s’agit d’un éventail, pas d’une liste à cocher : le programme doit montrer quels tests s’appliquent à quels systèmes, et pourquoi.

Le rythme de base figure à l’article 24, paragraphe 6 : au moins une fois par an, des tests appropriés sur tous les systèmes et applications de TIC qui soutiennent des fonctions critiques ou importantes. La liste des fonctions critiques ou importantes est donc le point de départ du programme (voir ce qu’exige DORA).

L’article 24, paragraphe 4, exige que les tests soient effectués par des parties indépendantes, internes ou externes. Un testeur interne est admis, à condition que l’entité lui accorde des ressources suffisantes et évite les conflits d’intérêts pendant la conception et l’exécution du test.

Deux catégories ont leurs propres règles. Les dépositaires centraux de titres et les contreparties centrales procèdent à des évaluations de la vulnérabilité avant tout déploiement ou redéploiement d’applications, de composantes d’infrastructure et de services TIC qui soutiennent des fonctions critiques ou importantes (article 25, paragraphe 2). Les microentreprises effectuent elles aussi les tests de l’article 25, paragraphe 1, en combinant une approche fondée sur les risques avec une planification stratégique des tests, et en mettant en balance les ressources et le temps disponibles avec l’urgence, le type de risque et la criticité en jeu (article 25, paragraphe 3).

Au-delà du programme, les entités financières identifiées par leur autorité compétente effectuent au moins tous les trois ans un test de pénétration fondé sur la menace (article 26, paragraphe 1). L’autorité les identifie sur la base de facteurs liés à l’impact, d’éventuels enjeux de stabilité financière et de leur profil de risque et de maturité en matière de TIC (article 26, paragraphe 8). Le détail figure dans le règlement délégué (UE) 2025/1190 de la Commission et dans Qu’est-ce que le TLPT au sens de DORA ?.

Réaliser les tests ne couvre que la moitié de l’exigence. L’article 24, paragraphe 5, impose des procédures et des stratégies pour hiérarchiser, classer et résoudre tous les problèmes mis en évidence, ainsi que des méthodes de validation interne pour vérifier que toutes les faiblesses, défaillances ou lacunes recensées sont entièrement corrigées. Un constat est clos lorsque la correction a été validée, pas lorsque quelqu’un le marque comme traité.

Les résultats alimentent aussi le cadre d’ensemble. L’article 6, paragraphe 5, prévoit le réexamen du cadre de gestion du risque lié aux TIC au moins une fois par an, en cas d’incident majeur lié aux TIC et à la suite des conclusions tirées des tests de résilience opérationnelle numérique ou des processus d’audit. Pour les tests de pénétration fondés sur la menace, l’article 26, paragraphe 6, ajoute une clôture formelle : une fois les rapports et les plans de remédiation convenus, l’entité remet à l’autorité une synthèse des constatations pertinentes, les plans de remédiation et la documentation démontrant que le test respecte les exigences. L’autorité délivre ensuite une attestation (article 26, paragraphe 7).

• Les tests sont planifiés système par système, sans lien avec les fonctions critiques ou importantes, si bien que la couverture annuelle exigée par l’article 24, paragraphe 6, ne peut pas être démontrée.
• Un test d’intrusion annuel est présenté comme le programme, alors que l’article 24, paragraphe 2, attend une série d’évaluations, de tests, de méthodologies, de pratiques et d’outils choisis selon le risque.
• Des testeurs internes testent des systèmes que leur propre équipe exploite, ce qui fragilise l’indépendance et la prévention des conflits d’intérêts de l’article 24, paragraphe 4.
• Les constats sont corrigés mais jamais retestés, de sorte qu’il n’existe aucune preuve de la validation interne exigée par l’article 24, paragraphe 5.
• Les systèmes exploités par des prestataires tiers de services TIC sont exclus du périmètre, alors qu’ils peuvent soutenir des fonctions critiques ou importantes autant que les systèmes internes.