DORA étape par étape pour les entités financières du Bénélux

Un parcours DORA pratique pour les banques, assureurs, institutions de paiement et gestionnaires d'actifs en Belgique, aux Pays-Bas et au Luxembourg, de la gouvernance du risque TIC à la déclaration des incidents majeurs.

Ce guide s'adresse aux RSSI, aux responsables des risques, aux responsables de la conformité et aux responsables informatiques des banques, assureurs, institutions de paiement et de monnaie électronique, entreprises d'investissement, gestionnaires d'actifs et autres entités financières en Belgique, aux Pays-Bas et au Luxembourg. Utilisez-le pour une première évaluation des écarts ou pour restructurer un référentiel construit à la hâte avant janvier 2025. L'accent est mis sur la gestion du risque lié aux TIC et la gestion des incidents. Les tests, le risque tiers et le partage d'informations sont couverts plus brièvement.

Avant de commencer

DORA confère la responsabilité ultime du risque lié aux TIC à l'organe de direction (article 5)^[1]. Avant de commencer, assurez-vous qu'un membre du conseil parraine le travail, que la fonction de contrôle du risque lié aux TIC est indépendante des opérations informatiques, et que vous savez quelle autorité de contrôle est compétente pour chaque entité agréée de votre groupe. Rassemblez votre documentation SMSI existante, votre analyse d'impact sur l'activité, votre procédure d'incident et votre registre d'externalisation, car la plupart des preuves DORA s'appuient sur eux. La proportionnalité (article 4) s'applique partout : la taille, le profil de risque et la nature, l'ampleur et la complexité de vos services déterminent jusqu'où vous allez.

Étape 1 : Confirmer le périmètre et le référentiel applicable

Commencez par déterminer quelles entités du groupe sont concernées et si l'une d'elles remplit les conditions pour le référentiel simplifié de gestion du risque lié aux TIC de l'article 16. Ce régime couvre, entre autres, les petites entreprises d'investissement non interconnectées, les établissements de paiement et de monnaie électronique exemptés en vertu de la DSP2 ou de la directive sur la monnaie électronique, et les petits IORP. Ces entités suivent le titre III du règlement délégué 2024/1774 (articles 28–41), tandis que toutes les autres suivent le titre II (articles 2–27).^[2].

• Énumérez chaque entité, son agrément, son autorité compétente et si l'article 16 s'applique.
• Vérifiez si une entité est également une entité essentielle ou importante en vertu de NIS2. En général, DORA s'applique comme lex specialis, mais les arrangements de déclaration nationaux peuvent différer.
• Convenez de la manière dont les politiques au niveau du groupe seront adoptées par l'organe de direction de chaque entité.

Étape 2 : Établir la gouvernance et le référentiel de gestion du risque lié aux TIC

L'article 5 exige que l'organe de direction définisse, approuve, supervise et soit responsable du référentiel de gestion du risque lié aux TIC. Il exige également que les membres du conseil maintiennent leurs connaissances en matière de risque lié aux TIC à jour par le biais d'une formation régulière. L'article 6 exige un référentiel solide, complet et documenté, une stratégie de résilience opérationnelle numérique, une fonction de contrôle indépendante, un audit interne, et un examen au moins une fois par an et après les incidents importants liés aux TIC. Les entités soumises au régime simplifié examinent leur référentiel périodiquement et rendent compte de cet examen tel que décrit à l'article 41 des RTS.

• Faites approuver par l'organe de direction le référentiel, la stratégie de résilience opérationnelle numérique et la tolérance au risque lié aux TIC.
• Assignez la fonction de contrôle du risque lié aux TIC selon le modèle des trois lignes de défense, ou un modèle équivalent, et documentez son indépendance.
• Planifiez la formation du conseil sur le risque lié aux TIC et enregistrez la participation.
• Planifiez l'examen annuel du référentiel et le rapport d'examen requis par l'article 27 du RTS.

Étape 3 : Identifier et classer les actifs et fonctions informatiques

L'article 8 vous impose d'identifier et de documenter vos fonctions métier, rôles, actifs informationnels et actifs TIC, ainsi que les dépendances entre eux. Vous devez identifier les fonctions critiques ou importantes, mettre en correspondance les actifs TIC qui les soutiennent et évaluer le risque lié aux TIC chaque fois qu'il y a un changement majeur. Les systèmes hérités et les actifs gérés par des tiers sont explicitement inclus.

• Construisez ou mettez à jour l'inventaire des actifs informationnels et informatiques, en reliant chacun aux fonctions métier qu'il soutient.
• Classez les actifs par criticité et enregistrez la configuration des actifs critiques.
• Identifiez toutes les dépendances TIC envers des tiers, en particulier celles qui soutiennent les fonctions critiques ou importantes.
• Effectuez une évaluation des risques sur les systèmes TIC hérités au moins une fois par an.

Étape 4 : Mettre en place les contrôles de protection et de détection

L'article 9 couvre la protection et la prévention, et l'article 10 la détection. Le titre II, chapitres 1 et 2 du RTS (articles 2–21) en détaillent le contenu : politiques de sécurité TIC, gestion des actifs, chiffrement et gestion des clés cryptographiques, sécurité des opérations TIC, sécurité du réseau, gestion des projets et des changements, sécurité physique, politiques de ressources humaines, et gestion de l'identité et des accès. L'article 23 du RTS précise ce que la détection d'activités anormales doit couvrir.

• Associez chaque article du RTS à une politique ou un contrôle existant, et enregistrez les lacunes.
• Vérifiez que vos procédures de gestion des correctifs, d'analyse des vulnérabilités, de journalisation et de gestion des changements répondent aux exigences spécifiques du RTS.
• Définissez les seuils de détection et les critères d'alerte, et assurez-vous que vous disposez de ressources suffisantes pour la surveillance.

Le modèle d'accompagnement comprend une évaluation des lacunes qui met en correspondance les articles 5 à 45 de DORA et les principaux articles du RTS avec les propriétaires, le statut et les preuves.

Étape 5 : Préparer la réponse, la récupération et les sauvegardes

Les articles 11 et 12 exigent une politique de continuité des activités liée aux TIC, des plans de réponse et de rétablissement, une analyse d'impact métier, et des procédures de sauvegarde et de restauration, avec des objectifs de rétablissement pour chaque fonction. Les plans de continuité des activités doivent être testés régulièrement, et les plans pour les fonctions critiques ou importantes au moins une fois par an. Les articles 24–26 du RTS ajoutent les détails sur la politique de continuité, les tests et les plans de réponse et de rétablissement.

• Mettez à jour l'analyse d'impact métier et définissez les objectifs de délai de récupération et de point de récupération pour les fonctions critiques ou importantes.
• Assurez-vous que les sauvegardes sont physiquement et logiquement séparées des systèmes source, et testez la restauration.
• Menez au moins un test de continuité basé sur des scénarios par an, incluant un scénario de cyberattaque grave.
• Préparez des plans de communication de crise pour les clients, le personnel, les contreparties et le public (article 14).

Étape 6 : Mettre en place la gestion des incidents, la classification et la notification

L'article 17 exige un processus de gestion des incidents liés aux TIC, l'article 18 la classification, et l'article 19 la notification des incidents majeurs à l'autorité compétente. Le Règlement délégué 2024/1772 fixe les critères et seuils de classification. Le Règlement délégué 2025/301 fixe le contenu et les délais, et le Règlement d'exécution 2025/302 les modèles.^[3].

Rapport	Délai
Notification initiale	Dans les 4 heures suivant la classification de l'incident comme majeur, et au plus tard 24 heures après en avoir eu connaissance
Rapport intermédiaire	Dans les 72 heures suivant la notification initiale, avec des mises à jour en cas de changement significatif du statut
Rapport final	Au plus tard un mois après le dernier rapport intermédiaire

Pour certaines entités, un délai qui tombe un week-end ou un jour férié peut être reporté à midi le jour ouvrable suivant. Cela ne s'applique pas aux rapports initiaux et intermédiaires des établissements de crédit, des contreparties centrales, des opérateurs de marchés de négociation et des entités essentielles ou importantes en vertu de NIS2.

• Intégrez les critères de classification (clients affectés, durée, étendue géographique, pertes de données, criticité des services, impact économique) dans votre outil de gestion des incidents.
• Définissez qui classe un incident comme majeur et qui approuve les rapports.
• Configurez l'accès au canal de déclaration de l'autorité de contrôle pour le personnel désigné et leurs suppléants, et entraînez-vous à effectuer une soumission.
• Décidez comment vous traiterez la notification volontaire des cybermenaces importantes et la communication aux clients affectés.

Pour une vue côte à côte de DORA, NIS2, CRA et RGPD en matière de notification, consultez notre guide opérationnel de réponse aux incidents.

Étape 7 : Tester la résilience opérationnelle numérique

Les articles 24 et 25 exigent un programme de test fondé sur le risque, avec des tests appropriés des systèmes et applications TIC qui soutiennent les fonctions critiques ou importantes au moins une fois par an. Les tests vont des évaluations de vulnérabilité et des analyses aux tests basés sur des scénarios et aux tests de pénétration. L'article 26 ajoute les tests de pénétration menés par la menace (TLPT) au moins tous les trois ans pour les entités identifiées par l'autorité compétente. En pratique, cela suit le référentiel TIBER-EU et ses versions nationales.

• Élaborez un plan de tests pluriannuel lié à la criticité des actifs de l'étape 3.
• Suivez les constats jusqu'à la remédiation, et signalez les résultats à l'organe de direction.

Étape 8 : Gérer le risque lié aux tiers TIC et tenir le registre à jour

Les articles 28–30 exigent une stratégie de gestion des risques liés aux tiers TIC, une diligence raisonnable, des dispositions contractuelles obligatoires et des stratégies de sortie. L'article 28(3) exige un registre des informations relatives à tous les arrangements contractuels avec les prestataires de services TIC tiers, au format défini dans le règlement d'exécution 2024/2956. Le registre doit être fourni à l'autorité compétente sur demande et est collecté annuellement. Pour un traitement plus approfondi, consultez notre article sur la gestion des risques liés aux tiers en 2026.

• Rapprochez le registre des données d'approvisionnement et de contrats au moins trimestriellement.
• Vérifiez les contrats pour les fonctions critiques ou importantes par rapport à l'article 30 et planifiez la renégociation si nécessaire.

Étape 9 : Apprendre, partager et rendre compte à l'organe de direction

L'article 13 exige des examens post-incident, l'utilisation des enseignements tirés, et la sensibilisation et la formation à la sécurité TIC pour tout le personnel. L'article 45 permet aux entités financières d'échanger des informations et du renseignement sur les menaces cybernétiques au sein de communautés de confiance, et les entités qui adhèrent doivent notifier leur autorité compétente. Dans Secrato, ces activités récurrentes sont mises en correspondance avec des tests de contrôle dans le Moteur de conformité, de sorte qu'un seul résultat sert DORA, NIS2 et ISO/IEC 27001 en même temps.

• Menez un examen post-incident pour chaque incident majeur et intégrez les constats à l'examen du référentiel.
• Envisagez d'adhérer à un dispositif de partage d'informations sectoriel et notifiez votre autorité de contrôle si vous le faites.
• Rendez compte du statut, des résultats des tests et des tendances en matière d'incidents à l'organe de direction au moins une fois par an.

Comment cela se connecte à d'autres référentiels

Un système de gestion de la sécurité de l'information ISO/IEC 27001 bien géré couvre une grande partie du chapitre sur la gestion du risque lié aux TIC de DORA, et les mesures de l'article 21 de NIS2 correspondent étroitement aux articles 8 à 14. DORA va plus loin sur la responsabilité du conseil d'administration, les tests de continuité des activités, les seuils de classification des incidents, les tests de pénétration ciblés et les dispositions contractuelles avec les prestataires TIC. Mettez en correspondance chaque article de DORA avec les contrôles que vous testez déjà pour ISO/IEC 27001 afin d'éviter les doublons.

Questions fréquemment posées

Une institution de paiement peut-elle utiliser le référentiel simplifié ?

Uniquement si elle est exemptée en vertu de la DSP2. Les institutions de paiement agréées appliquent le référentiel complet, proportionnellement.

Le signalement des incidents DORA est-il identique au signalement NIS2 ?

Non. DORA a ses propres critères de classification, modèles et délais. Lorsqu'une entité financière relève également des règles nationales NIS2, vérifiez auprès de votre autorité de contrôle si une notification NIS2 distincte est nécessaire.

À quelle fréquence le registre des informations doit-il être soumis ?

Les autorités de contrôle le collectent annuellement et peuvent le demander à tout moment. Vérifiez le calendrier de collecte et les exigences de format de votre autorité de contrôle.

Sommes-nous tenus de faire un TLPT ?

Uniquement si votre autorité compétente vous identifie pour cela. Toutes les entités doivent disposer d'un programme de test avec des tests annuels des systèmes prenant en charge les fonctions critiques ou importantes.