DORA : ce que le règlement sur la résilience opérationnelle numérique impose

Présentation du règlement

Le règlement (UE) 2022/2554 a été adopté le 14 décembre 2022 et publié au Journal officiel de l’Union européenne le 27 décembre 2022. Il est entré en vigueur le 16 janvier 2023, avec une période de transition de deux ans, avant de devenir pleinement applicable le 17 janvier 2025.

DORA s’inscrit dans le paquet "finance numérique" de la Commission européenne, aux côtés du règlement MiCA sur les crypto-actifs. Son objectif est d’établir un niveau élevé et commun de résilience opérationnelle numérique dans l’ensemble du secteur financier européen, en imposant à la fois aux entités financières et à leurs fournisseurs technologiques critiques un socle d’exigences uniformes.

Le texte se structure autour de cinq piliers : la gestion du risque lié aux TIC, la gestion et la déclaration des incidents, les tests de résilience opérationnelle numérique, la gestion du risque lié aux prestataires tiers de services TIC, et le partage d’informations sur les cybermenaces (ce dernier reste volontaire).

En France, l’application de DORA est supervisée par l’ACPR (Autorité de contrôle prudentiel et de résolution) pour les banques et les assurances, et par l’AMF (Autorité des marchés financiers) pour les entités des marchés financiers. Au niveau européen, l’ABE (Autorité bancaire européenne), l’AEAPP et l’AEMF coordonnent la production des normes techniques (RTS et ITS) qui précisent les obligations opérationnelles du règlement.

Qui est concerné

Le périmètre de DORA est large et mérite d’être précisé avec soin, car il inclut des catégories que certaines organisations n’anticipent pas.

Les entités financières au sens de DORA comprennent les établissements de crédit, les établissements de paiement, les établissements de monnaie électronique, les entreprises d’investissement, les gestionnaires de fonds, les prestataires de services sur crypto-actifs, les compagnies d’assurance et de réassurance, les contreparties centrales, les dépositaires centraux de titres, les plateformes de négociation, et plusieurs autres catégories. Les fintechs de taille modeste y figurent au même titre que les grandes banques systémiques.

Le principe de proportionnalité est explicitement inscrit dans le texte. Les microentreprises (moins de 10 salariés et moins de 2 millions d’euros de chiffre d’affaires) bénéficient d’un cadre simplifié de gestion du risque lié aux TIC. Les PME et petites entités non systémiques disposent également de marges d’adaptation sur certaines exigences.

Les prestataires tiers de services TIC entrent dans le périmètre de DORA d’une façon qui n’existait dans aucun autre texte sectoriel européen. Les fournisseurs cloud, les éditeurs de logiciels, les infogéreurs, les fournisseurs de data centers qui supportent des fonctions critiques pour des entités financières peuvent être désignés comme "prestataires tiers de services TIC critiques" (CTPP) par les Autorités européennes de surveillance. Cette désignation entraîne un régime de supervision spécifique et des obligations directes, indépendamment de la localisation géographique du prestataire.

Les exigences concrètes

Pilier 1 : Gestion du risque lié aux TIC. Chaque entité financière doit disposer d’un cadre de gestion du risque lié aux TIC documenté, validé par la direction et mis à jour régulièrement. Ce cadre inclut une cartographie des systèmes d’information critiques, une évaluation des risques, des stratégies de protection et de réponse, ainsi qu’une politique de continuité d’activité numérique.

Pilier 2 : Gestion et déclaration des incidents. Les entités financières doivent disposer d’un processus formalisé de détection, de classification et de déclaration des incidents majeurs liés aux TIC. Les incidents majeurs doivent être déclarés aux autorités compétentes selon une séquence en trois temps : notification initiale, rapport intermédiaire, rapport final. Des délais stricts s’appliquent à chaque étape.

Pilier 3 : Tests de résilience opérationnelle numérique. C’est le pilier le plus directement lié aux pratiques de test de sécurité, et probablement le plus mal compris. Deux niveaux de tests coexistent.

Les tests de base concernent toutes les entités financières : au minimum chaque année, elles doivent conduire des évaluations de vulnérabilité, des analyses de la sécurité réseau, des analyses en source ouverte, des examens de sécurité physique et des tests de pénétration. Le périmètre doit couvrir l’ensemble des systèmes et applications TIC supportant des fonctions critiques.

Les tests TLPT (Threat-Led Penetration Testing) sont réservés aux entités identifiées par les autorités compétentes sur la base de leur importance systémique. Ces tests doivent être réalisés au moins tous les trois ans, par des testeurs externes indépendants, selon la méthodologie du cadre TIBER-EU (Threat Intelligence Based Ethical Red Teaming). Ce ne sont pas des tests d’intrusion classiques : ils sont construits sur des scénarios de menace réalistes fondés sur une analyse de threat intelligence propre à chaque entité, ils couvrent les systèmes de production, et leurs résultats sont transmis aux autorités compétentes.

Pilier 4 : Gestion du risque tiers. Chaque entité financière doit tenir un registre exhaustif de ses fournisseurs TIC, avec des informations précises sur les services fournis, les systèmes supportés et les sous-traitances en cascade. Les contrats avec les prestataires doivent inclure des clauses obligatoires : droit d’audit, droit d’accès, niveaux de service définis, stratégie de sortie, traitement des incidents, sécurité des données.

Le piège le plus sous-estimé : confondre TLPT et pentest classique

C’est la distinction que beaucoup d’entités concernées n’ont pas encore intégrée, et qui crée des risques lors des contrôles.

Un test d’intrusion classique est une évaluation technique de la sécurité d’un système, réalisée par un ou plusieurs testeurs qui cherchent activement des vulnérabilités exploitables. Il peut être réalisé en boîte noire, grise ou blanche, sur des environnements de test ou de production.

Un test TLPT au sens de DORA et du cadre TIBER-EU est fondamentalement différent. Il commence par une phase de threat intelligence menée par un prestataire distinct du testeur, pour construire un scénario d’attaque basé sur les adversaires réels qui ciblent le secteur et le profil spécifique de l’entité. Le test est conduit sur les systèmes de production, avec une connaissance minimale du côté des équipes défensives. Les conclusions sont partagées avec l’autorité compétente. Le coût, la durée et la complexité d’un TLPT sont sans commune mesure avec ceux d’un pentest annuel standard.

La confusion crée deux risques opposés. Des entités qui pensent que leurs pentests annuels existants satisfont l’exigence TLPT alors que ce n’est pas le cas. Et des entités non désignées pour les TLPT qui surinvestissent dans des tests coûteux sans y être obligées, au détriment des tests de base annuels qui s’appliquent, eux, à toutes les entités.

Comment un audit PIIRATES s’articule avec une démarche DORA

Les obligations de tests annuels de base que DORA impose à toutes les entités financières, pentests, analyses de vulnérabilités, examens de sécurité réseau, correspondent exactement au périmètre d’un test d’intrusion bien calibré.

Pour une entité financière de taille moyenne, fintech, établissement de paiement, gestionnaire d’actifs, l’enjeu pratique est souvent le même : structurer une évaluation annuelle qui couvre l’ensemble des systèmes supportant les fonctions critiques, produit un rapport conforme aux attentes de l’ACPR ou de l’AMF en cas de contrôle, et laisse un plan de remédiation documenté.

Un audit de l’Active Directory est particulièrement pertinent dans ce contexte : c’est souvent l’infrastructure la plus critique pour les entités financières et l’une des plus exposées aux vecteurs d’attaque que DORA cherche à couvrir. La surveillance Active Directory constitue également un élément de la réponse à l’obligation de détection et de monitoring continu des incidents TIC imposée par le pilier 2.

Nous n’intervenons pas sur les missions TLPT au sens strict de TIBER-EU, dont le cadre impose des conditions de qualification spécifiques aux testeurs externes. En revanche, les tests de base annuels, les évaluations de vulnérabilités et les tests d’intrusion sur les systèmes critiques entrent pleinement dans notre périmètre d’intervention, avec des rapports structurés pour faciliter leur intégration dans votre dossier de conformité DORA.

La valeur au-delà de la conformité

DORA a été rédigé dans un contexte où la dépendance du secteur financier à un nombre restreint de grands prestataires technologiques est devenue un risque systémique documenté. Son exigence la plus ambitieuse n’est pas dans la liste des tests obligatoires. Elle est dans l’obligation de cartographier et de surveiller l’ensemble de la chaîne de dépendances technologiques, y compris les sous-traitants des sous-traitants.

Cette exigence de registre et de visibilité sur la chaîne TIC, pénible à mettre en oeuvre si on ne l’a jamais faite, est probablement l’actif de sécurité le plus durable que DORA produira dans les organisations qui s’y conformeront sérieusement. Comprendre précisément de quels systèmes dépend chaque fonction critique, qui les opère, et comment un incident chez un fournisseur de second rang peut se propager jusqu’à l’entité financière : c’est exactement la visibilité qui manquait lors de l’incident CrowdStrike de juillet 2024, et que les entités ayant travaillé sérieusement leur registre DORA avaient déjà constituée.