DORA : le règlement qui change tout pour l'informatique financière
Le Digital Operational Resilience Act (DORA) est la réponse de l'Union européenne à une question simple mais cruciale : le système financier peut-il résister à une perturbation ICT majeure ? Après des années d'incidents marquants — pannes cloud ayant paralysé des systèmes de paiement, attaques par ransomware visant des institutions financières, compromissions de chaînes d'approvisionnement touchant simultanément plusieurs entités —, les régulateurs européens ont conclu que les cadres existants étaient insuffisants.
DORA est entré en vigueur le 16 janvier 2023 et s'applique à partir du 17 janvier 2025. Contrairement à une directive (qui doit être transposée en droit national), DORA est un règlement, ce qui signifie qu'il s'applique directement et uniformément dans tous les États membres de l'UE, y compris le Luxembourg. Il n'existe aucune ambiguïté quant à son applicabilité, aucune attente de transposition nationale, et aucune marge pour une mise en œuvre allégée.
Pour le Luxembourg, qui abrite la plus grande industrie des fonds d'investissement d'Europe et constitue un centre majeur pour les services bancaires, d'assurance et de paiement, l'impact de DORA est considérable. Pratiquement toutes les entités supervisées par la CSSF sont dans le champ d'application.
Le changement fondamental : DORA fait passer la gestion des risques ICT d'une « bonne pratique » facultative à une responsabilité légalement imposée au niveau du Conseil d'administration, assortie de mécanismes d'exécution. Votre cadre de gestion des risques ICT n'est plus seulement une préoccupation informatique ; c'est une obligation réglementaire.
Qui est concerné ?
DORA s'applique à un large éventail d'entités financières, notamment :
- Les établissements de crédit (banques)
- Les établissements de paiement et les établissements de monnaie électronique
- Les entreprises d'investissement
- Les sociétés de gestion (OPCVM et AIFM)
- Les entreprises d'assurance et de réassurance
- Les prestataires de services sur crypto-actifs
- Les dépositaires centraux de titres
- Les référentiels centraux
- Les agences de notation de crédit
- Les prestataires de services de financement participatif
- Les prestataires tiers de services ICT critiques (fournisseurs cloud, opérateurs de centres de données, éditeurs de logiciels désignés comme critiques)
Cette dernière catégorie est particulièrement significative. DORA étend la supervision réglementaire aux fournisseurs de technologie dont dépendent les entités financières. Si vous fournissez des services cloud, d'hébergement infogéré ou des logiciels critiques à des entités financières luxembourgeoises, vous pouvez être désigné comme prestataire tiers de services ICT critique et faire l'objet d'une surveillance directe.
Les cinq piliers de DORA
DORA s'articule autour de cinq domaines fondamentaux. Les équipes sécurité doivent comprendre chacun d'eux et leurs implications pratiques.
Pilier 1 : cadre de gestion des risques ICT
Les articles 5 à 16 imposent aux entités financières de mettre en place un cadre complet de gestion des risques ICT comprenant :
- Gouvernance : l'organe de direction (Conseil d'administration) doit définir, approuver, superviser et assumer la responsabilité du cadre de gestion des risques ICT. Les membres du Conseil doivent maintenir une connaissance suffisante des risques ICT, notamment par des formations régulières.
- Stratégie de gestion des risques ICT : une stratégie documentée fixant le niveau de tolérance au risque, des objectifs clairs et des politiques de sécurité ICT.
- Classification des actifs : inventaire complet et classification des actifs ICT, des actifs informationnels et de leurs interdépendances.
- Protection et prévention : politiques et outils de sécurité ICT, notamment la gestion des accès, le chiffrement, la sécurité des réseaux et la gestion des vulnérabilités.
- Détection : mécanismes de détection des activités anormales, incluant la surveillance de la sécurité, les alertes et des tests réguliers.
- Réponse et rétablissement : plans de continuité des activités ICT, plans de réponse et de rétablissement ICT, politiques de sauvegarde et procédures de récupération testées régulièrement.
- Apprentissage et évolution : bilans post-incident, intégration du renseignement sur les menaces et amélioration continue du cadre.
Pour les entités luxembourgeoises qui se conforment déjà à la circulaire CSSF 20/750 (sur les risques ICT), une grande partie de cette structure est familière. Cependant, DORA est plus prescriptif et introduit des exigences spécifiques qui vont au-delà de la circulaire existante.
Pilier 2 : gestion des incidents liés aux ICT
Les articles 17 à 23 établissent un cadre harmonisé de classification et de notification des incidents :
- Critères de classification : les incidents doivent être classifiés sur la base de critères définis, notamment le nombre de clients affectés, la durée, l'étendue géographique, les pertes de données, la criticité des services touchés et l'impact économique.
- Délais de notification : les incidents ICT majeurs doivent être notifiés à l'autorité compétente (la CSSF pour la plupart des entités luxembourgeoises) dans des délais stricts :
- Notification initiale : dans les 4 heures suivant la classification de l'incident comme majeur (et au plus tard 24 heures après la détection)
- Rapport intermédiaire : dans les 72 heures
- Rapport final : dans le mois
- Notification volontaire : les entités peuvent notifier volontairement les cybermenaces significatives, et pas uniquement les incidents avérés.
Le délai de notification initiale de 4 heures est extrêmement exigeant et nettement plus contraignant que le préavis de 24 heures prévu par NIS2. Les entités financières doivent disposer de modèles prédéfinis, de chaînes d'escalade claires et de procédures de notification éprouvées pour satisfaire à cette exigence.
Pilier 3 : tests de résilience opérationnelle numérique
Les articles 24 à 27 imposent aux entités financières de procéder à des tests réguliers de leurs systèmes et outils ICT. C'est ici que les tests d'intrusion et le red teaming deviennent des exigences réglementaires, et non de simples bonnes pratiques.
Tests de base (toutes les entités dans le champ d'application) :
- Évaluations et analyses de vulnérabilités
- Évaluations de sources ouvertes (OSINT)
- Évaluations de la sécurité des réseaux
- Analyses d'écarts
- Revues de sécurité physique
- Revues de code source (lorsque cela est faisable)
- Tests basés sur des scénarios
- Tests de compatibilité
- Tests de performance
- Tests de bout en bout
- Tests d'intrusion
Tests avancés (Threat-Led Penetration Testing, TLPT) :
Les entités financières d'importance systémique doivent réaliser des TLPT au moins tous les 3 ans, sur la base du cadre TIBER-EU. Le TLPT est essentiellement un exercice de red team guidé par un renseignement sur les menaces réelles spécifiques à l'entité. Il doit être réalisé par des testeurs externes qualifiés (avec des exceptions limitées pour les équipes red team internes sous des conditions strictes).
La CSSF, en coordination avec la BCE pour les établissements significatifs, désignera les entités devant réaliser des TLPT. Si vous êtes une banque, un assureur ou une infrastructure de marchés financiers d'importance systémique au Luxembourg, préparez-vous à être désigné.
Pilier 4 : gestion des risques ICT liés aux tiers
Les articles 28 à 44 constituent sans doute l'aspect le plus transformateur de DORA. Ils imposent aux entités financières de :
- Tenir un registre de tous les arrangements contractuels avec les prestataires tiers de services ICT, classifiés par criticité.
- Effectuer une diligence raisonnable avant de conclure des arrangements d'externalisation ICT, notamment en évaluant les capacités de gestion des risques ICT du prestataire.
- Inclure des clauses contractuelles obligatoires dans tous les contrats de services ICT, couvrant : les SLA, la localisation et le traitement des données, les droits d'audit, les obligations de notification des incidents, les stratégies de sortie et la coopération avec les autorités réglementaires.
- Surveiller le risque de concentration : évaluer si l'entité est excessivement dépendante d'un seul prestataire ICT et maintenir des plans de substitution.
Pour les sociétés de gestion luxembourgeoises et les administrateurs de fonds qui s'appuient fortement sur des plateformes technologiques externalisées, ce pilier impose une révision approfondie des contrats et des relations avec les fournisseurs existants. De nombreux accords existants devront être amendés pour inclure les clauses imposées par DORA.
Pilier 5 : partage d'informations
L'article 45 encourage (sans l'imposer) les entités financières à participer à des dispositifs de partage de renseignements sur les cybermenaces dans un cadre de confiance. Au Luxembourg, la plateforme MISP de CIRCL constitue une excellente base pour cela, et plusieurs groupes de partage sectoriels existent déjà.
DORA vs. NIS2 : comprendre le chevauchement
Il existe une confusion importante quant à la manière dont DORA et NIS2 interagissent. Le principe clé est celui de la lex specialis : DORA est le règlement sectoriel applicable aux entités financières, et lorsqu'il entre en conflit avec NIS2 ou prévoit des exigences plus spécifiques, DORA prime.
En pratique, cela signifie que :
- Les entités financières dans le champ d'application de DORA sont exemptées des exigences de cybersécurité de NIS2 (mais pas des autres obligations de NIS2, telles que le devoir de notification aux autorités compétentes)
- Les exigences de notification des incidents de DORA (notification initiale dans les 4 heures) sont plus strictes que celles de NIS2 (préavis de 24 heures)
- Les exigences de tests de DORA sont plus complètes que l'obligation générale de tests de sécurité de NIS2
Cependant, les entités financières ne doivent pas ignorer NIS2 dans sa totalité. Si une entité financière fournit également des services couverts par NIS2 (par exemple, si une banque exploite aussi un centre de données pour des tiers), les deux règlements peuvent s'appliquer à différentes parties de l'activité.
Étapes pratiques de mise en œuvre pour les entités luxembourgeoises
Étape 1 : analyse des écarts (mois 1-2)
Cartographiez votre cadre actuel de gestion des risques ICT par rapport aux exigences de DORA. Si vous vous conformez déjà à la circulaire CSSF 20/750, vous disposez d'une base, mais attendez-vous à des lacunes dans des domaines tels que la préparation au TLPT, le registre des tiers ICT et la précision de vos tests de continuité d'activité.
Étape 2 : inventaire et classification des actifs ICT (mois 2-3)
Constituez ou mettez à jour un inventaire complet de tous les actifs ICT, des actifs informationnels et de leurs interdépendances. DORA exige que vous compreniez non seulement ce que vous possédez, mais aussi comment les systèmes dépendent les uns des autres et des services tiers.
Étape 3 : révision des contrats avec les tiers (mois 3-6)
Passez en revue tous les contrats de prestataires de services ICT pour vérifier les clauses imposées par DORA. Priorisez les prestataires ICT critiques et importants. Cette étape sera sans doute la plus chronophage, car la renégociation des contrats avec les grands prestataires (plateformes cloud, systèmes bancaires de base) peut prendre plusieurs mois.
Étape 4 : renforcement de la réponse aux incidents (mois 3-4)
Mettez à jour votre cadre de classification des incidents pour l'aligner sur les critères de DORA. Préparez des modèles de notification pour la CSSF. Testez votre capacité à respecter le délai de notification initiale de 4 heures par un exercice de simulation sur table.
Étape 5 : conception du programme de tests (mois 4-6)
Concevez un programme de tests de résilience opérationnelle numérique couvrant toutes les exigences de l'article 25 de DORA. Planifiez des tests d'intrusion, des évaluations de vulnérabilités et des tests basés sur des scénarios. Si vous êtes susceptible d'être désigné pour un TLPT, commencez tôt à vous engager avec des prestataires TIBER-EU qualifiés et des équipes de renseignement sur les menaces.
Étape 6 : engagement et formation du Conseil d'administration (en continu)
DORA place une responsabilité explicite sur l'organe de direction. Assurez-vous que les membres du Conseil reçoivent une formation sur les risques ICT, comprennent les exigences de DORA et approuvent le cadre de gestion des risques ICT. Un reporting régulier au Conseil sur les risques ICT doit être mis en place s'il ne l'est pas déjà.
Les attentes de la CSSF
La CSSF a été proactive dans la communication de ses attentes en matière de conformité DORA. Les entités financières luxembourgeoises doivent suivre les publications de la CSSF, participer aux réunions sectorielles et consulter leurs interlocuteurs à la CSSF pour toute question relative à la mise en œuvre.
Les domaines sur lesquels la CSSF a signalé une attention particulière comprennent :
- Le risque de concentration ICT lié aux tiers dans l'industrie des fonds, où plusieurs grands prestataires de plateformes servent une part significative du marché
- Les arrangements d'externalisation cloud, en s'appuyant sur les orientations existantes de la CSSF sur l'informatique en nuage
- La qualité de la notification des incidents, avec un accent mis sur l'analyse des causes profondes dans les rapports finaux
- La responsabilité du Conseil d'administration pour les décisions relatives à la gestion des risques ICT
La voie à suivre
DORA représente un changement fondamental dans la façon dont le secteur financier européen aborde la résilience ICT. Pour les entités luxembourgeoises, le défi est réel mais gérable, en particulier pour les organisations qui ont déjà investi dans la conformité à la circulaire CSSF 20/750 et dans la certification ISO 27001.
La clé est de commencer maintenant, de prioriser les lacunes présentant le risque le plus élevé et de construire un programme de conformité durable plutôt qu'un exercice de validation de case de dernière minute. Les entités qui traitent DORA comme une opportunité d'améliorer véritablement leur résilience opérationnelle seront mieux positionnées que celles qui le perçoivent comme une contrainte réglementaire.
