La vision de Cyber Academy
DORA (Regulation (EU) 2022/2554) est le règlement de l'UE qui impose un cadre unifié de résilience opérationnelle numérique aux entités financières et à leurs prestataires tiers de services TIC critiques. Applicable depuis le 17 janvier 2025. Cinq piliers : gestion du risque TIC, notification des incidents, tests de résilience y compris les tests de pénétration fondés sur la menace, risque lié aux tiers TIC, partage d'informations. Lex specialis par rapport à NIS 2 sur les sujets TIC.
TL;DR
- 1S'applique à une vingtaine de catégories d'entités financières ainsi qu'aux prestataires tiers de services TIC critiques désignés, depuis le 17 janvier 2025.
- 2Cinq piliers. Le registre des tiers (pilier 4) et les tests de résilience (pilier 3, dont le TLPT pour les entités significatives) sont les plus opérationnels et les plus audités.
- 3Pour les entités significatives, des tests de pénétration fondés sur la menace tous les trois ans, supervisés par l'autorité nationale dans le cadre de TIBER-EU.
- 4Les prestataires tiers de services TIC critiques sont supervisés directement par les autorités européennes de surveillance (ESAs). Leur risque de concentration compte désormais à l'échelle de l'UE.
- 5À combiner avec ISO 22301 pour le BCMS, ISO 27001 pour la gestion du risque TIC, et Lead Operational Resilience Manager pour la couche face au régulateur.
La plupart des entités financières n'ont pas démarré DORA de zéro. Elles disposaient d'un ISMS, d'un plan de continuité d'activité, d'une politique d'externalisation et d'un inventaire des tiers qui se résumait surtout à des contrats d'achat. DORA ne jette pas tout cela. Il le recadre, relève le niveau d'exigence sur deux piliers en particulier, et déplace la conversation de « avez-vous un contrôle » vers « pouvez-vous prouver que votre service continue de fonctionner quand un prestataire TIC tombe ». Cette page traite de cet écart : comment les cinq piliers atterrissent réellement dans les opérations, ce qu'un superviseur ouvre en premier, et où les équipes perdent du temps.
Les cinq piliers, et qui est audité sur chacun
Le règlement repose sur cinq piliers. Ils ne pèsent pas tous d'un poids égal en pratique. Le pilier 1 est fondamental mais familier à quiconque exploite un ISMS. Les piliers 3 et 4 sont ceux où l'attention de la supervision se concentre, parce qu'ils produisent des preuves difficiles à falsifier et faciles à tester. Le tableau ci-dessous est la version que nous utilisons pour briefer un conseil : ce que chaque pilier exige, et qui, au sein de l'entité, se retrouve le plus exposé quand le régulateur demande des preuves.
| Pilier | Ce qu'il exige | Le plus audité dessus |
|---|---|---|
| 1. Gestion du risque TIC | Un cadre de gouvernance documenté : cartographie des actifs et des dépendances, identification des risques, contrôles de protection et de détection, réponse et reprise, avec une appropriation par le conseil et une fonction responsable nommément désignée. | Le CISO / RSSI et l'organe de direction, qui doit démontrer une supervision active, et non une délégation. |
| 2. Gestion et notification des incidents TIC | Classer les incidents liés aux TIC selon des critères harmonisés, puis notifier les incidents majeurs à l'autorité compétente selon le calendrier initial / intermédiaire / final. | La réponse aux incidents et le SOC, ainsi que celui ou celle qui pilote les notifications réglementaires. |
| 3. Tests de résilience opérationnelle numérique | Un programme de tests fondé sur les risques ; pour les entités significatives, des tests de pénétration fondés sur la menace (TLPT) sur des systèmes de production en service au moins tous les trois ans. | Les tests de sécurité, la red team, et les responsables métier des systèmes inclus dans le périmètre. |
| 4. Risque lié aux tiers TIC | Un registre de tous les accords avec des tiers TIC, des clauses contractuelles sur l'audit, la sortie et la sous-traitance, et une analyse du risque de concentration. | Les achats, la gestion des fournisseurs et le juridique, qui doivent produire le registre et les contrats à la demande. |
| 5. Partage d'informations | Des dispositifs volontaires d'échange de renseignement sur les cybermenaces entre entités financières. | Le renseignement sur la menace ; le pilier le plus léger et rarement une non-conformité à lui seul. |
Par quoi commencer
L'erreur consiste à débuter par la mise à jour des politiques, parce que c'est le travail confortable. Commencez plutôt par les deux artefacts qu'un superviseur peut réclamer par écrit et qui sont les plus longs à construire correctement : le registre des tiers TIC et la cartographie des fonctions critiques ou importantes vers les actifs et prestataires TIC qui les soutiennent. Tout le reste découle de cette cartographie. Vous ne pouvez pas cadrer les tests de résilience, vous ne pouvez pas classer la gravité des incidents, et vous ne pouvez pas raisonner sur le risque de concentration tant que vous ne savez pas quelles fonctions sont critiques et de quoi elles dépendent.
Une séquence réaliste pour les 90 premiers jours :
- Définissez vos fonctions critiques ou importantes. C'est une décision métier, pas une décision de sécurité. Elle conditionne le périmètre de presque toutes les autres obligations.
- Reliez chaque fonction critique aux services TIC, internes et externalisés, dont elle dépend. C'est votre graphe de dépendances.
- Construisez le registre des tiers à partir de ce graphe, et non à partir du tableur des achats. Le registre doit décrire les accords qui soutiennent des fonctions, y compris les sous-traitants présents dans la chaîne.
- Comblez les lacunes contractuelles exigées par DORA (droits d'audit, stratégies de sortie, transparence de la sous-traitance, coopération en cas d'incident) en priorité sur les accords qui soutiennent des fonctions critiques.
- Ce n'est qu'ensuite que vous formaliserez le cadre de gestion du risque TIC et le programme de tests, car les deux disposent désormais d'un périmètre défini sur lequel travailler.
Le registre des tiers TIC (pilier 4) en pratique
Le registre n'est pas une liste de fournisseurs. C'est un ensemble structuré de registres d'informations que l'entité tient à jour et que les autorités compétentes collectent, selon un modèle défini, pour observer la concentration TIC à l'échelle de tout le secteur financier. Cela change la façon de le construire. Un champ « suffisamment proche » pour un usage interne devient un problème de qualité des données lorsqu'il est agrégé à l'échelle nationale et de l'UE. Trois choses causent l'essentiel de la difficulté.
Premièrement, l'unité est l'accord contractuel, pas le fournisseur. Un même prestataire peut se trouver derrière plusieurs accords, et un même accord peut soutenir plusieurs fonctions. Vous décrivez un graphe plusieurs-à-plusieurs, et l'aplatir en une ligne par fournisseur ne survivra pas à la revue.
Deuxièmement, vous devez suivre la chaîne. Le registre doit recenser les sous-traitants qui soutiennent effectivement une fonction critique ou importante, ce qui signifie que votre visibilité sur les prestataires doit aller au-delà de votre cocontractant direct. Si votre contrat ne vous donne pas le droit de savoir qui est le quatrième tiers, c'est une lacune contractuelle à combler, pas un champ à laisser vide.
Troisièmement, l'indicateur de criticité de la fonction sur chaque accord est le champ dont tout le reste dépend. Marquez trop d'éléments comme critiques et vous noyez vos propres tests et votre remédiation contractuelle ; marquez-en trop peu et vous sous-estimez le risque de concentration et trompez le superviseur. Faites bien l'évaluation de criticité une fois, au niveau de la fonction, et laissez-la se propager.
Les tests de pénétration fondés sur la menace (pilier 3) : à quoi ressemble vraiment la salle
Le TLPT est le pilier qui surprend, parce qu'il ne ressemble pas à un test de pénétration de routine. Il est piloté par le renseignement, mené contre des systèmes de production en service, cadré sur les fonctions critiques ou importantes, et conduit selon la méthodologie TIBER-EU avec l'autorité nationale impliquée. Les entités significatives le réalisent sur un cycle d'au moins trois ans. Il s'apparente davantage à un exercice de red team supervisé qu'à un scan de vulnérabilités, et le livrable qui compte n'est pas la liste des constats ; c'est la preuve que la détection et la réponse ont fonctionné, ou le compte rendu honnête des raisons pour lesquelles elles n'ont pas fonctionné.
Trois réalités que les équipes sous-estiment :
- Le périmètre est déterminé par les fonctions critiques, pas par ce qu'il est commode de tester. Si une fonction passe par un prestataire externalisé, ce prestataire devra peut-être être inclus dans le périmètre, ce qui signifie que la coopération du prestataire doit être sécurisée contractuellement à l'avance.
- La blue team n'est généralement pas prévenue. La valeur réside dans le test de la détection et de la réponse réelles ; un TLPT dont les défenseurs ont été avertis a donc perdu l'essentiel de son intérêt. Cela a des conséquences organisationnelles que l'on anticipe, et que l'on ne découvre pas en cours d'exercice.
- Les testeurs et les prestataires de renseignement sur la menace doivent satisfaire à des exigences de compétence et d'indépendance, et l'autorité examine le processus. Vous ne pouvez pas simplement requalifier le pentest annuel de l'an dernier en TLPT.
Si votre entité est en dessous du seuil de significativité, vous ne réalisez pas de TLPT, mais vous devez tout de même un programme de tests fondé sur les risques : évaluations de vulnérabilités, tests fondés sur des scénarios, et tests de résilience du chemin de reprise. Le cours Lead Operational Resilience Manager est bâti précisément autour de cette couche de tests et de preuves face au régulateur, et le cours DORA Lead Manager couvre la manière dont l'ensemble du programme est gouverné de bout en bout.
DORA comme lex specialis sur NIS 2 pour les banques
Les banques, et la plupart des autres entités financières, entrent dans le périmètre à la fois de NIS 2 et de DORA. Les deux se recoupent largement sur le risque TIC, la notification des incidents et la sécurité de la chaîne d'approvisionnement, ce qui soulève la crainte évidente de tout faire deux fois. DORA tranche : sur les sujets TIC qu'il régit, DORA est lex specialis. La règle spécifique l'emporte sur la règle générale. Là où DORA fixe l'obligation de gestion du risque TIC et de notification des incidents, une entité financière suit DORA, et les autorités compétentes ne devraient pas appliquer par-dessus l'exigence NIS 2 équivalente pour le même sujet TIC.
Ce que cela ne signifie pas : cela ne désactive pas entièrement NIS 2 pour une entité financière, et cela ne change pas qui est votre autorité compétente pour les sujets non TIC. La décision pratique pour une banque est de relier chaque obligation à son instrument de rattachement : résilience opérationnelle TIC, notification des incidents et risque lié aux tiers TIC relèvent de DORA ; tout ce qui est hors DORA est un périmètre que vous évaluez séparément. Documentez cette cartographie. C'est la réponse à la question « comptez-vous deux fois ou pas assez » que posent à la fois les examinateurs et les auditeurs.
Erreurs fréquentes et où bâtir la compétence
Les échecs récurrents n'ont rien d'exotique. Le registre est construit par fournisseur au lieu de l'être par accord et se brise dès que la sous-traitance entre en jeu. La criticité des fonctions critiques est évaluée par l'IT au lieu de l'être par le métier, si bien que le périmètre de tout ce qui suit est faux. Les seuils de classification des incidents sont rédigés mais jamais éprouvés contre un incident réel, si bien que le premier événement majeur devient la première répétition du calendrier de notification. Et la continuité d'activité est traitée comme un projet ISO 22301 séparé plutôt que comme le muscle de reprise que les tests DORA sont censés exercer.
Ce dernier point compte : DORA ne remplace pas un système de management de la continuité d'activité, il en présuppose un. Les objectifs de reprise et le chemin de reprise testé qu'un BCMS vous procure sont ce que les tests de résilience valident. Construisez correctement le BCMS avec le cours ISO 22301 Lead Implementer, et il devient le substrat sur lequel reposent les obligations de résilience opérationnelle, plutôt qu'un classeur parallèle que personne n'ouvre.
Si vous partez du règlement lui-même, le cours DORA Foundation donne à toute l'équipe une lecture partagée et exacte des cinq piliers et du périmètre avant que quiconque touche au registre ou au programme de tests. À partir de là, le cours DORA Lead Manager constitue la couche de mise en œuvre et de gouvernance pour les personnes qui porteront le cadre, et le cours Lead Operational Resilience Manager s'adresse à la fonction qui devra se tenir devant le superviseur et démontrer que la résilience est réelle, et pas seulement documentée.
Frequently asked questions
01Qui entre dans le périmètre de DORA ?
Une vingtaine de catégories d'entités financières : établissements de crédit, établissements de paiement, établissements de monnaie électronique, entreprises d'investissement, contreparties centrales, plates-formes de négociation, dépositaires centraux de titres, entreprises d'assurance et de réassurance, intermédiaires, prestataires de services sur crypto-actifs, prestataires de services d'information sur les comptes, gestionnaires de fonds d'investissement alternatifs, sociétés de gestion, prestataires de services de communication de données, agences de notation de crédit, administrateurs d'indices de référence d'importance critique, prestataires de services de financement participatif, référentiels de titrisation.
S'y ajoute un régime distinct pour les prestataires tiers de services TIC critiques (CTPPs) désignés par les ESAs sur la base d'une évaluation de criticité. Les CTPPs font l'objet d'une supervision directe par un Joint Oversight Forum dirigé par une ESA.
02Qu'est-ce que le TLPT et qui doit le réaliser ?
Le Threat-Led Penetration Testing est un exercice de red team supervisé par le régulateur, exigé des entités financières significatives au titre de DORA. Construit sur le cadre TIBER-EU (Threat Intelligence-Based Ethical Red Teaming). Tous les trois ans au minimum.
Le TLPT est piloté par le renseignement (profil de menace établi par une équipe de renseignement distincte), cible les fonctions critiques ou importantes de l'entité, et est supervisé par l'autorité nationale. Pluri-mensuel, coûteux, et le test le plus rigoureux qu'un CISO du secteur financier aura à affronter.
03Comment DORA s'articule-t-il avec NIS 2 pour les banques ?
DORA est lex specialis sur les sujets TIC. Là où DORA s'applique, il prévaut sur NIS 2 pour les dispositions liées aux TIC. Pour les sujets NIS 2 non liés aux TIC (sécurité physique, certains aspects de gouvernance, périmètre de formation), NIS 2 continue de s'appliquer en parallèle.
En pratique, une banque entrant dans le périmètre des deux textes met en œuvre intégralement DORA pour le risque TIC, la notification des incidents, les tests de résilience et le risque lié aux tiers TIC, tout en lisant NIS 2 pour le socle de gouvernance de la cybersécurité restant.
04Que met-on dans le registre des tiers TIC ?
L'Article 28 ainsi que les RTS de l'EBA sur la sous-traitance et sur le registre d'informations précisent les champs. Chaque accord contractuel avec un prestataire de services TIC est consigné avec : nature des services, criticité, chaîne de sous-traitance visible par l'entité, localisation des services, localisation des données, SLA de performance, stratégie de sortie, dispositifs de gouvernance.
Le registre est le document que l'autorité de surveillance demande en premier. La plupart des entités financières sous-estiment la charge de maintenance ; un registre obsolète est traité comme une non-conformité.
05Quel est le lien entre DORA et ISO 22301 ?
DORA n'impose pas la certification ISO 22301, mais les obligations du règlement en matière de continuité d'activité et de reprise après sinistre (Articles 11-12) correspondent presque terme à terme à un BCMS conforme à ISO 22301. La plupart des entités qui exploitent déjà un BCMS 22301 y greffent la couche de tests et de reporting propre à DORA sans reconstruire les fondations.
