Gestion du risque TIC sous DORA : ce que l'analyse de risque doit couvrir

Mis à jour le 9 octobre 2026

Le cadre en bref

Le règlement (UE) 2022/2554 sur la résilience opérationnelle numérique du secteur financier, dit DORA, date du 14 décembre 2022 et s'applique depuis le 17 janvier 2025. Règlement européen, il est directement applicable sans transposition ; seule la directive qui l'accompagne passe par la loi Résilience en France. Il vise vingt catégories d'entités financières (article 2, paragraphe 1, points a à t), des établissements de crédit aux référentiels des titrisations, ainsi que les prestataires tiers de services TIC (point u).

La gestion du risque lié aux TIC occupe le chapitre II, articles 5 à 16. Elle est précisée par le règlement délégué (UE) 2024/1774 du 13 mars 2024, publié au Journal officiel le 25 juin 2024 et composé de 42 articles : son titre II détaille le cadre complet, son titre III le cadre simplifié réservé aux entités visées à l'article 16. Aucun de ces textes n'impose une méthode d'analyse nommée.

Articles 5 à 16 : ce qui touche à l'analyse de risque

Le tableau résume chaque article du chapitre II sous l'angle de l'analyse de risque. Il ne remplace pas la lecture du texte.

Article	Objet	Point d'attention pour l'analyse
5	Gouvernance et organisation	L'organe de direction assume la responsabilité ultime du risque lié aux TIC, fixe le niveau de tolérance au risque, alloue le budget ; ses membres se forment régulièrement
6	Cadre de gestion du risque lié aux TIC	Cadre documenté, réexaminé au moins une fois par an (périodiquement pour les microentreprises) et après un incident majeur ; fonction de contrôle indépendante ; audit interne régulier ; stratégie de résilience opérationnelle numérique
7	Systèmes, protocoles et outils de TIC	Systèmes adaptés, fiables, dimensionnés et résilients en situation de tension
8	Identification	Fonctions métiers, actifs et dépendances classés et documentés ; sources de risque identifiées de manière continue ; hors microentreprises, évaluation des risques à chaque modification importante et évaluation des systèmes hérités au moins une fois par an, ainsi qu'avant et après toute connexion
9	Protection et prévention	Politique de sécurité de l'information ; gestion des changements fondée sur une approche d'évaluation des risques
10	Détection	Mécanismes de détection régulièrement testés
11	Réponse et rétablissement	Analyse d'impact sur l'activité avec critères quantitatifs et qualitatifs ; plans testés au moins une fois par an
12	Sauvegarde et restauration	Portée et fréquence des sauvegardes selon la criticité des données
13	Apprentissage et évolution	Retour d'expérience des incidents et des tests ; compte rendu au moins annuel de l'encadrement TIC à l'organe de direction ; formations obligatoires
14	Communication	Au moins une personne chargée de la communication sur les incidents liés aux TIC
15	Harmonisation	Base du règlement délégué 2024/1774
16	Cadre simplifié	Pour certaines entités (petites entreprises d'investissement non interconnectées, établissements de paiement exemptés, petites institutions de retraite professionnelle, etc.), les articles 5 à 15 ne s'appliquent pas et un cadre allégé les remplace

Ce que le règlement délégué 2024/1774 impose à la méthode

L'article 3 du règlement délégué est le texte le plus précis sur le contenu de la politique de gestion du risque lié aux TIC. Il en fixe six éléments, qui forment une bonne grille de relecture pour n'importe quelle méthode.

a) L'indication de l'approbation du niveau de tolérance au risque lié aux TIC.
b) Une procédure et une méthode d'évaluation précisant les vulnérabilités et menaces qui affectent les fonctions et actifs, et les indicateurs quantitatifs ou qualitatifs utilisés pour mesurer leur incidence et leur probabilité.
c) La procédure de choix, de mise en œuvre et de documentation des mesures de traitement, pour ramener le risque dans les limites de la tolérance.
d) Pour les risques résiduels : leur identification, les rôles pour accepter ceux qui dépassent la tolérance, un inventaire des risques résiduels acceptés avec la justification de leur acceptation, et leur réexamen au moins une fois par an (changements, mesures d'atténuation disponibles, validité des raisons d'acceptation).
e) Le suivi des évolutions de la menace, des vulnérabilités internes et externes et du profil de risque.
f) La prise en compte des changements de stratégie commerciale et de stratégie de résilience.

Le registre d'informations, point de départ de l'analyse

L'article 28, paragraphe 3, impose un registre d'informations sur tous les accords contractuels portant sur des services TIC fournis par des tiers, tenu au niveau de l'entité et aux niveaux sous-consolidé et consolidé, en distinguant les services qui soutiennent des fonctions critiques ou importantes. Le règlement d'exécution (UE) 2024/2956 du 29 novembre 2024 en fixe les modèles : quinze tableaux, de B_01.01 (entité qui tient le registre) à B_99.01 (terminologie), dont B_05.02 sur la chaîne d'approvisionnement, B_06.01 sur l'identification des fonctions et B_07.01 sur l'évaluation des services qui soutiennent une fonction critique ou importante. Les prestataires personnes morales y sont identifiés par un LEI ou un EUID.

En France, l'ACPR collecte ces registres chaque année. Pour la collecte 2026, la date limite de remise était le 31 mars 2026, pour une date d'arrêté au 31 décembre 2025, avec une ouverture de la plateforme le 1er janvier 2026 (support du webinaire ACPR du 23 janvier 2026).

Lien avec l'analyse : les tableaux B_06.01 et B_07.01 recoupent l'article 8 (fonctions, dépendances, prestataires) et l'atelier 3 d'EBIOS RM (dangerosité des parties prenantes). Utilisez le registre comme entrée de l'analyse, et non l'inverse.
Gardez les mêmes identifiants (fonction, prestataire, accord) dans le registre et dans l'étude de risque : c'est ce qui permet de répondre vite quand un prestataire critique subit un incident.

Relier les exigences DORA aux livrables d'une analyse

DORA couvre le risque lié aux TIC dans son ensemble, y compris les défaillances non malveillantes. Une méthode centrée sur les scénarios intentionnels, comme EBIOS RM, doit donc être complétée ; la page EBIOS RM ou ISO 27005 explique comment.

Exigence	Source	Livrable à produire
Niveau de tolérance approuvé	Article 6, paragraphe 8, b) ; RTS article 3 a)	Seuils d'acceptation de la stratégie de traitement, approuvés par l'organe de direction
Évaluation à chaque modification importante	Article 8, paragraphe 3	Procédure de révision incrémentale de l'étude, déclenchée par la gestion des changements
Systèmes hérités évalués chaque année	Article 8, paragraphe 7	Revue annuelle dédiée, alignée sur le cycle opérationnel
Inventaire des risques résiduels acceptés	RTS article 3 d) iii)	Registre des acceptations avec justification, signataire et date
Réexamen annuel des acceptations	RTS article 3 d) iv)	Compte rendu de revue indiquant si les raisons d'acceptation restent valables
Analyse d'impact sur l'activité	Article 11, paragraphe 5	BIA, à rapprocher des événements redoutés et de leur gravité

Pièges fréquents

Ces écarts sont ceux qui se repèrent le plus facilement lors d'un contrôle, parce qu'ils se voient sur pièces.

Une tolérance au risque non formalisée. Sans niveau approuvé par l'organe de direction, aucune acceptation de risque résiduel n'est traçable au sens de l'article 3 du règlement délégué.
Un registre d'informations tenu par les achats et ignoré par l'équipe risques. Les deux décrivent les mêmes dépendances ; deux versions divergentes se repèrent en contrôle.
Une analyse annuelle qui ignore les changements. L'article 8, paragraphe 3, demande aux entités autres que les microentreprises une évaluation à chaque modification importante, pas seulement au rythme de la revue du cadre.
Des acceptations sans date de réexamen. Le réexamen au moins annuel des risques résiduels acceptés est une exigence explicite.
Oublier le cadre simplifié. Une entité visée à l'article 16 relève du titre III du règlement délégué ; appliquer le titre II par défaut coûte cher sans être exigé.