TL;DR

La loi DORA (Digital Operational Resilience Act) vise la résilience numérique du secteur financier. Si vous êtes une banque, un assureur, une fintech ou un fournisseur de technologie à leur service, vous êtes concerné.

Elle couvre la gestion des risques liés aux TIC, les tests obligatoires de détection des menaces (comme le TLPT), la surveillance des risques par des tiers et le signalement rigoureux des incidents.

Opérationnel depuis le 17 janvier 2025, avec de lourdes pénalités en cas de surprise.

Résumé du tableau de bord DORA :

• Effort du développeur : Modéré à élevé (nécessite la mise en œuvre de pratiques de codage sûres et résilientes, le soutien d'une gestion solide des risques liés aux TIC, la mise en place d'un système détaillé d'enregistrement et de signalement des incidents, la participation à des tests de résilience avancés).
• Coût de l'outillage : élevé (il faut investir dans des outils de gestion des risques liés aux TIC, des outils de test de sécurité avancés (pentesting, TLPT), une surveillance/SIEM solide, des plateformes de gestion des risques de tiers, des solutions de continuité des activités/de reprise après sinistre).
• Impact sur le marché : Critique (obligatoire pour la quasi-totalité des entités financières de l'UE et leurs fournisseurs de TIC essentiels ; place la barre très haut en matière de résilience opérationnelle).
• Flexibilité : Modérée (le règlement spécifie des exigences pour les principaux piliers, mais permet la proportionnalité en fonction de la taille, du profil de risque et de la nature/complexité des services).
• Intensité de l'audit : Élevée (conformité supervisée par les autorités nationales compétentes et les autorités européennes de surveillance (AES) ; implique la démonstration de cadres solides, de résultats de tests et de capacités de gestion des incidents).

Qu'est-ce que DORA ?

La loi sur la résilience opérationnelle numérique (règlement (UE) 2022/2554), ou DORA, est un élément clé de la législation de l'UE établissant des exigences uniformes concernant la sécurité des réseaux et des systèmes d'information soutenant les processus opérationnels des entités financières. Elle crée un cadre contraignant et complet spécialement conçu pour renforcer la sécurité informatique et la résilience opérationnelle du secteur financier de l'UE.

Contrairement à NIS2 qui s'applique de manière générale, DORA se concentre exclusivement sur les entités financières (banques, assureurs, entreprises d'investissement, institutions de paiement, fournisseurs de crypto-actifs, etc.) et les fournisseurs tiers de TIC critiques (comme les plateformes en nuage, les fournisseurs de logiciels, les fournisseurs d'analyse de données) qui les desservent.

DORA repose sur cinq piliers fondamentaux :

1. Gestion des risques liés aux TIC : Les entités doivent disposer d'un cadre de gestion des risques liés aux TIC complet et bien documenté, comprenant des stratégies, des politiques, des procédures, des protocoles et des outils permettant d'identifier, de protéger, de détecter, de répondre et de récupérer les risques liés aux TIC. Les organes de gestion sont responsables en dernier ressort.
2. Gestion et signalement des incidents liés aux TIC : Mandate des processus pour détecter, gérer, enregistrer, classer et signaler aux autorités compétentes les incidents majeurs liés aux TIC en utilisant des modèles et des calendriers normalisés.
3. Tests de résilience opérationnelle numérique : Les entités doivent mettre en place un programme de tests de résilience opérationnelle numérique proportionnel et basé sur les risques, comprenant des évaluations de vulnérabilité, des évaluations de la sécurité du réseau, des tests basés sur des scénarios et, pour les entités importantes, des tests de pénétration avancés basés sur les menaces (TLPT) au moins tous les trois ans.
4. Gestion des risques liés aux tiers dans le domaine des TIC : Impose des règles strictes pour la gestion des risques associés à la dépendance à l'égard de fournisseurs de services TIC tiers. Ces règles comprennent un contrôle préalable, des dispositions contractuelles spécifiques (couvrant l'accès, l'audit, la sécurité, les stratégies de sortie), une évaluation du risque de concentration et un contrôle permanent.
5. Partage d'informations : Encourage le partage volontaire d'informations et de renseignements sur les cybermenaces entre les entités financières afin d'améliorer la prise de conscience collective et la résilience.

La loi DORA vise à garantir la résilience du système financier, même en cas de graves perturbations opérationnelles dues à des problèmes liés aux TIC ou à des cyberattaques. Elle est entrée en vigueur en janvier 2023 et les entités financières doivent s'y conformer avant le 17 janvier 2025.

Pourquoi est-ce important ?

DORA est d'une importance capitale pour le secteur financier de l'UE et son écosystème :

• Harmonisation : Crée un ensemble unique et cohérent de règles pour la résilience opérationnelle numérique dans tous les États membres de l'UE, remplaçant les approches nationales fragmentées.
• Stabilité financière : L'objectif est d'éviter que les incidents liés aux TIC ne déstabilisent des entreprises financières individuelles ou le système financier dans son ensemble.
• Prise en compte du risque systémique : reconnaît la dépendance croissante à l'égard des TIC et les risques systémiques potentiels posés par les défaillances, en particulier en ce qui concerne les fournisseurs tiers essentiels.
• Surveillance directe des fournisseurs critiques : Les autorités européennes de surveillance (AES, telles que l'ABE, l'AEMF et l'AEAPP) disposent d'un pouvoir de contrôle direct sur les fournisseurs tiers de TIC désignés comme critiques (CTPP).
• Conformité obligatoire : Contrairement à certains cadres, le DORA est un règlement, directement applicable et juridiquement contraignant pour toutes les entités du champ d'application.
• Exigences renforcées en matière de résilience : Va au-delà de la cybersécurité de base, exigeant des tests robustes (y compris TLPT), une gestion détaillée des incidents et une gestion rigoureuse des risques par des tiers.
• Responsabilité de la direction : Comme pour le NIS2, l'organe de gestion est clairement responsable de la supervision des risques liés aux TIC.

Pour les entités financières et leurs principaux fournisseurs de technologie, la conformité à la loi DORA est essentielle pour l'approbation réglementaire, l'accès au marché et le maintien de la stabilité opérationnelle dans l'UE.

Quoi et comment mettre en œuvre (technique et politique)

La mise en œuvre de la DORA nécessite des efforts considérables dans ses cinq piliers, impliquant des mesures techniques et politiques :

1. Cadre de gestion des risques liés aux TIC (art. 5-16) :
   
   • Politique/stratégie : Élaborer et maintenir un cadre solide et complet de gestion des risques liés aux TIC, approuvé par la direction.
   • Contrôles techniques : Mettre en œuvre des mesures de sécurité basées sur l'évaluation des risques - identification, protection (configurations sécurisées, correctifs, sécurité du réseau, sécurité physique), détection (systèmes de surveillance, détection des anomalies), réponse et récupération (sauvegardes, plans de reprise après sinistre). Cela implique des outils tels que les pare-feu, le SIEM, l'EDR, la gestion des vulnérabilités, l'IAM.
   • Documentation : Conserver une documentation complète sur le cadre, les évaluations des risques, la mise en œuvre des contrôles et les tests d'efficacité.
2. Gestion et signalement des incidents (art. 17-23) :
   
   • Processus : Mettre en place des processus de surveillance, de détection, de classification (sur la base de critères définis dans les normes techniques réglementaires - RTS), de gestion, d'enregistrement et de signalement des incidents majeurs liés aux TIC.
   • Support technique : Mettre en œuvre des outils de journalisation et de surveillance (SIEM) capables de détecter les incidents et de collecter les données nécessaires à l'établissement de rapports. Élaborer des flux de travail pour l'établissement de rapports.
3. Essais de résilience opérationnelle numérique (articles 24 à 27) :
   
   • Programme de test : Établir un programme fondé sur les risques, comprenant des évaluations de la vulnérabilité, des analyses de sources ouvertes, des évaluations de la sécurité des réseaux, des examens de la sécurité physique, des tests basés sur des scénarios et des tests de compatibilité.
   • Outils : Utiliser des scanners de vulnérabilité, des scanners de configuration, des outils DAST, SAST, SCA.
   • Test de pénétration basé sur la menace (TLPT) : pour les entités importantes, effectuer un TLPT avancé (comme TIBER-EU) basé sur des RTS spécifiques, impliquant des testeurs externes certifiés simulant des attaquants du monde réel. Pour être efficace, il faut que les capacités de détection et de réaction soient au point.
4. Gestion des risques liés aux TIC pour les tiers (article 28-44) :
   
   • Stratégie et politique : Élaborer une stratégie et une politique de gestion des risques associés aux fournisseurs tiers de TIC.
   • Registre des informations : Tenir un registre détaillé de tous les contrats de services TIC passés avec des tiers.
   • Diligence raisonnable : Effectuer des évaluations rigoureuses de la sécurité et de la résilience avant de conclure des contrats avec des fournisseurs de TIC.
   • Exigences contractuelles (article 30) : Veiller à ce que les contrats contiennent des clauses obligatoires concernant les normes de sécurité, les droits d'audit, la coopération en matière de signalement des incidents, des descriptions claires des services, les lieux de traitement des données et les stratégies de sortie.
   • Contrôle des prestataires essentiels (CTPP) : Coopérer avec les ASE lors des activités de contrôle direct des PTPC désignés.
   • Risque de concentration : évaluer et gérer les risques liés à la dépendance à l'égard d'un seul ou d'un petit nombre de fournisseurs.
5. Échange d'informations (article 45) :
   
   • Participer (volontairement) à des accords de partage de renseignements et d'informations sur les cybermenaces, en veillant à la conformité avec le GDPR.

La mise en œuvre nécessite une gouvernance solide, des ressources dédiées, une collaboration interdépartementale (informatique, sécurité, risque, juridique, achats) et souvent un investissement important dans la technologie et l'expertise.

Les erreurs courantes à éviter

Les entités qui mettent en œuvre la DORA doivent éviter ces erreurs courantes :

1. Retarder la mise en œuvre : Attendre trop longtemps pour commencer le travail considérable nécessaire à l'analyse des lacunes, au développement du cadre, à la mise en œuvre des tests et à l'assainissement des contrats avec des tiers avant l'échéance de janvier 2025.
2. Sous-estimation de la portée et de l'effort : Ne pas saisir l'ampleur des exigences de la loi DORA dans les cinq piliers et sous-doter l'effort de mise en conformité de ressources suffisantes.
3. Traiter la question comme s'il s'agissait uniquement de l'informatique et de la sécurité : Ne pas impliquer suffisamment les services des risques, les services juridiques, les services d'approvisionnement et les cadres supérieurs, en particulier en ce qui concerne le cadre des risques liés aux TIC et la gestion des risques liés aux tiers.
4. Gestion insuffisante des risques liés aux tiers : Absence de diligence raisonnable, de mise à jour des contrats avec des clauses obligatoires ou de gestion du risque de concentration lié aux fournisseurs de TIC.
5. Tests de résilience inadéquats : Se contenter d'une analyse de base des vulnérabilités au lieu d'effectuer les tests complets fondés sur les risques (y compris le TLPT, le cas échéant) exigés par le DORA.
6. Mauvaise préparation des rapports d'incidents : Absence de contrôle technique ou de processus internes permettant de classer et de signaler les incidents majeurs avec précision et dans les délais requis.
7. Supposer que d'autres cadres suffisent : S'appuyer uniquement sur la norme ISO 27001 ou sur une autre norme de conformité sans procéder à une analyse spécifique des lacunes par rapport aux exigences détaillées du DORA, en particulier en ce qui concerne les tests de risque et de résilience effectués par des tiers.

Ce que les auditeurs/régulateurs pourraient demander (accent mis sur les développeurs)

Les autorités de surveillance chargées de vérifier la conformité à la loi DORA disposeront de pouvoirs étendus. Les questions concernant les équipes de développement pourraient porter sur la résilience, la sécurité dès la conception, les tests et l'assistance en cas d'incident :

• (ICT Risk Mgmt) "Comment les exigences en matière de sécurité et de résilience sont-elles intégrées dans le cycle de développement des logiciels ?"
• (Gestion des risques liés aux TIC) "Démontrer l'existence de pratiques de codage sécurisées et de gestion des vulnérabilités dans le cadre du développement".
• (Gestion des incidents) "Comment la journalisation de l'application facilite-t-elle la détection, l'analyse et le signalement des incidents liés aux TIC ?"
• (Tests de résilience) "Quels sont les tests de sécurité (statiques, dynamiques, composants) effectués sur l'application ? Fournir des résultats récents."
• (Test de résilience) "Comment l'application est-elle conçue pour résister aux pannes ou à une charge élevée (par exemple, redondance, évolutivité, mécanismes de basculement) ?"
• (Test de résilience) "Pouvez-vous démontrer le processus de restauration de l'application et de ses données à partir des sauvegardes ?"
• (Risque lié aux tiers) "Comment gérez-vous les risques de sécurité liés aux composants logiciels tiers ou aux API intégrés dans l'application ?"

Les régulateurs attendront des cadres documentés, des politiques, des procédures, des résultats de tests, des journaux d'incidents et des preuves que la résilience est intégrée dans les systèmes et les processus.

Des gains rapides pour les équipes de développement

Bien que la conformité totale à la loi DORA soit complexe, les équipes de développement peuvent y contribuer grâce à des pratiques fondamentales :

1. Améliorer la journalisation des applications : Améliorer les journaux d'application afin de capturer les événements et les erreurs liés à la sécurité et utiles pour l'analyse des incidents. Veiller à ce que les journaux soient centralisés.
2. Intégrer SAST/SCA : intégrer l'analyse automatisée de la sécurité du code et des dépendances dès le début du pipeline CI/CD.
3. Se concentrer sur les modèles de résilience : Mettre l'accent sur les pratiques de codage qui améliorent la résilience (par exemple, traitement approprié des erreurs, délais d'attente, nouvelles tentatives, absence d'état dans la mesure du possible).
4. Documenter les dépendances : Maintenir une nomenclature logicielle précise pour les applications.
5. Tester les scénarios d'échec : Inclure des tests sur le comportement de l'application dans des conditions d'échec (par exemple, dépendance indisponible, charge élevée).
6. Configuration sécurisée : S'assurer que les applications ont des configurations par défaut sécurisées et externaliser les paramètres de configuration de manière appropriée.

Ignorez ceci et... (Conséquences de la non-conformité)

La loi DORA confère aux autorités compétentes d'importants pouvoirs de surveillance et d'exécution. La non-conformité peut entraîner

• Sanctions administratives/amendes : Bien que la loi DORA elle-même ne fixe pas de montants d'amendes spécifiques (laissant aux États membres le soin de la mettre en œuvre), le non-respect des directives/réglementations sous-jacentes qu'elle renforce, ou le fait de ne pas suivre les ordres des autorités compétentes, peut entraîner des amendes substantielles (potentiellement jusqu'à 1 à 2 % du chiffre d'affaires global ou des montants spécifiques comme 10 millions d'euros, en fonction de la mise en œuvre nationale et des violations spécifiques). Correction : Certaines sources mentionnent des astreintes allant jusqu'à 1 % du chiffre d'affaires mondial quotidien moyen pour les fournisseurs tiers critiques directement surveillés par les AES. Les sanctions nationales pour les entités financières elles-mêmes varieront mais devraient être importantes.
• Mesures correctives : Les autorités peuvent ordonner aux entités de cesser leur comportement, de mettre en œuvre des mesures correctives spécifiques ou de fournir des informations spécifiques.
• Avis publics : Les autorités peuvent émettre des avis publics identifiant l'entité non conforme et la nature de l'infraction.
• Retrait de l'autorisation : Dans les cas les plus graves, l'autorisation de l'entité financière peut être retirée.
• Sanctions de la direction : Sanctions administratives potentielles ou interdictions temporaires pour les membres de l'organe de gestion responsables d'infractions.
• Atteinte à la réputation : La divulgation publique de cas de non-conformité ou d'incidents qui en découlent nuit gravement à la confiance dans le secteur financier.
• Restrictions opérationnelles : Les autorités peuvent imposer des restrictions aux opérations jusqu'à ce que la conformité soit rétablie.

FAQ

Qui doit se conformer à la loi DORA ?

La loi DORA s'applique à un large éventail d'entités financières de l'UE, notamment les banques, les établissements de crédit, les établissements de paiement, les entreprises d'investissement, les entreprises d'assurance/de réassurance, les prestataires de services liés aux crypto-actifs, les plateformes de crowdfunding, les contreparties centrales (CCP), les référentiels centraux, les gestionnaires de fonds d'investissement alternatifs (AIFM), les sociétés de gestion d'OPCVM, ainsi que les prestataires de services TIC critiques désignés par les autorités de surveillance européennes.

Quelle est la date limite pour la mise en conformité avec la loi DORA ?

Les entités financières doivent être entièrement conformes à la loi DORA d' ici le 17 janvier 2025.

Quel est le lien entre DORA et NIS2 ?

Le DORA constitue une lex specialis pour le secteur financier. Cela signifie que les entités financières couvertes à la fois par la DORA et la NIS2 suivent principalement les exigences plus spécifiques de la DORA concernant la gestion des risques liés aux TIC, la notification des incidents, les tests de résilience et les risques liés aux tiers. La NIS2 reste d'application pour les aspects non couverts par la DORA.

Qu'est-ce qu'un test de pénétration basé sur la menace (TLPT) dans le cadre du DORA ?

Le TLPT est une forme avancée de test de résilience imposée aux entités financières importantes en vertu de la loi DORA (article 26). Il s'agit de simuler les tactiques, techniques et procédures (TTP) d'acteurs de menaces réelles ciblant les fonctions critiques et les systèmes sous-jacents de l'entité. Il est basé sur des cadres tels que TIBER-EU et nécessite des testeurs externes certifiés.

La loi DORA s'applique-t-elle aux fournisseurs de services d'informatique dématérialisée ?

Oui, de manière significative. Les fournisseurs de services en nuage sont considérés comme des fournisseurs de services TIC tiers au sens de la loi DORA. Les entités financières qui utilisent des services en nuage doivent appliquer des exigences strictes en matière de gestion des risques liés aux tiers (articles 28 à 30). En outre, les fournisseurs de services en nuage jugés "critiques" par les autorités européennes de surveillance feront l'objet d'une surveillance directe et de sanctions potentielles (articles 31 à 44).

Quels sont les principaux piliers de DORA ?

Les cinq piliers fondamentaux sont les suivants

1. Gestion des risques liés aux TIC
2. Gestion et signalement des incidents liés aux TIC
3. Test de résilience opérationnelle numérique
4. Gestion des risques liés aux TIC pour les tiers
5. Dispositions relatives à l'échange d'informations

Existe-t-il une certification pour DORA ?

Non, le DORA lui-même n'établit pas de système de certification. La conformité est supervisée et appliquée par les autorités nationales compétentes et les autorités européennes de surveillance (pour les fournisseurs tiers de TIC critiques). Les entités démontrent leur conformité en mettant en œuvre des cadres, des politiques, des résultats de tests, des rapports d'incidents et en coopérant avec les autorités de surveillance.