DORA : Guide de conformité complet pour le secteur financier

C’est quoi, le Règlement DORA ?

Le Règlement DORA (n°2022/2554), ou Digital Operational Resilience Act, est un texte législatif majeur de l’Union européenne sur la cybersécurité des entités financières, comme les banques ou les établissements de crédit. En français, DORA répond au doux nom de Règlement sur la résilience opérationnelle du numérique.

Quelle loi prévaut entre DORA et NIS2 ?

Si vous êtes au fait du Règlement DORA, vous n’avez pas pu passer à côté de la Directive NIS2. Elle a été adoptée le même jour, et renforce les exigences en matière de cybersécurité au sein de l’UE, notamment pour les banques et les infrastructures des marchés financiers.

Mais alors, qui prime entre DORA et NIS2 en matière de finance numérique ? C’est bien simple : DORA est dite “lex specialis” de NIS2, un principe qui veut qu’une loi spécifique prime sur une loi généraliste. Dans les faits, DORA précise et complète NIS2 plus qu’elle ne la supplante.

“Le présent règlement constitue une lex specialis en ce qui concerne la directive (UE) 2022/2555. Dans le même temps, il est indispensable de maintenir un lien étroit entre le secteur financier et le cadre horizontal de l’Union en matière de cybersécurité tel qu’il est actuellement défini dans la directive (UE) 2022/2555 […]. ” – DORA, Considérant 16

Quel est l’objectif de DORA ?

L’objectif de DORA est clairement énoncé dans son Considérant 105 (un préambule qui précède un texte de loi et en explique les motivations): “atteindre un niveau élevé de résilience opérationnelle numérique pour toutes les entités financières réglementées.”

C’est bien beau, mais ça veut dire quoi la “résilience opérationnelle numérique” ? Hé bien d’après le texte de DORA lui-même, c’est :

“la capacité d’une entité financière à développer, garantir et réévaluer son intégrité et sa fiabilité opérationnelles en assurant directement ou indirectement par le recours aux services fournis par des prestataires tiers de services TIC, l’intégralité des capacités liées aux TIC nécessaires pour garantir la sécurité des réseaux et des systèmes d’information qu’elle utilise, et qui sous-tendent la fourniture continue de services financiers et leur qualité, y compris en cas de perturbations” – DORA, Article 3(1)

La défense c’est bien, la résilience c’est mieux !

Que faut-il comprendre de cette définition de la résilience opérationnelle numérique ? C’est bien simple : les entités financières ne doivent plus seulement se défendre, mais résister. L’enjeu réel de DORA est bien la disponibilité et l’intégrité des services financiers, même en cas de perturbations, d’incidents, d’attaques… bref, en cas de pépin ! Le secteur financier doit se donner les moyens de défendre ses actifs (informationnels, logiciels et matériels), mais ce n’est plus une fin en soi. Avec DORA, la défense sert une cause autrement supérieure : la résilience.

Quelle est la date d’application du Règlement DORA ?

Le Règlement DORA entrera en application le 17 janvier 2025, soit 24 mois après sa publication au Journal Officiel de l’UE. Si vous voulez vérifier par vous-même, cette date est marquée noir sur blanc dans l’Article 64.

Vers une précision des normes techniques par les AES et l’ENISA début 2024

Comme vous allez le voir, certaines politiques et procédures introduites par DORA sont, à ce jour, encore un peu nébuleuses. Néanmoins, cela devrait se préciser début 2024.

En effet, l’Article 15 dispose que les Autorités Européennes de Surveillance (AES) et l’Agence de l’Union européenne pour la cybersécurité (ENISA) doivent proposer des projets communs de normes techniques de réglementation, et ce au plus tard le 17 janvier 2024. Ces projets viendront préciser différents pans de la législation, des composantes des plans de réponse et de rétablissement à ceux des tests des plans de continuité des activités.

Pour autant, la Réglementation est déjà bien fournie et il n’est pas question de se tourner les pouces en attendant 2024. Les chantiers sont nombreux et exigeants, et mieux vaut s’y prendre au plus tôt.

Conformité DORA : un plan d’action en 17 étapes

A ce stade, nous avons déjà couvert le “quand” et le “pourquoi” de la conformité DORA. Mais comme vous vous en doutez, c’est le “comment” qui représente le gros du travail. Comme souvent en matière de compliance, il s’agit de procéder par étapes. Ces quelques pages sont justement là pour vous défricher le terrain.

Passons sans plus attendre aux choses sérieuses avec notre plan d’action pour préparer DORA du mieux possible avant le 17 janvier 2025.

1. Déterminez si vous êtes affecté par le Règlement DORA

Avant de se soucier de la mise en conformité avec DORA, encore faut-il savoir si vous êtes concerné. Le Règlement sur la résilience opérationnelle du numérique concerne 21 types d’entités. Les voici comme décrites dans l’Article 2 :

• les établissements de crédit;
• les établissements de paiement, y compris les établissements de paiement exemptés en vertu de la directive (UE) 2015/2366;
• les prestataires de services d’information sur les comptes;
• les établissements de monnaie électronique, y compris les établissements de monnaie électronique exemptés en vertu de la directive 2009/110/CE;
• les entreprises d’investissement;
• les prestataires de services sur crypto-actifs et les émetteurs de jetons se référant à un ou des actifs;
• les dépositaires centraux de titres;
• les contreparties centrales;
• les plateformes de négociation;
• les référentiels centraux;
• les gestionnaires de fonds d’investissement alternatifs;
• les sociétés de gestion;
• les prestataires de services de communication de données;
• les entreprises d’assurance et de réassurance;
• les intermédiaires d’assurance, les intermédiaires de réassurance et les intermédiaires d’assurance à titre accessoire;
• les institutions de retraite professionnelle;
• les agences de notation de crédit;
• les administrateurs d’indices de référence d’importance critique;
• les prestataires de services de financement participatif;
• les référentiels des titrisations;
• les prestataires tiers de services TIC (oui, c’est vaste)

DORA : la liste des exceptions

Certaines entités sont explicitement exclues du scope de DORA par l’Article 2(3). Nous ne pouvons que vous encourager à lire la liste ci-après pour savoir si vous faites partie des heureux élus.

Petite précision : les exceptions mentionnées dans le texte de DORA font souvent écho aux exceptions d’autres textes législatifs, avec eux-mêmes des ramifications à n’en plus finir. Par souci de concision, nous ne rentrerons pas dans le détail de toutes les législations citées par DORA. Néanmoins, vous trouverez à chaque fois un lien vers ladite loi si vous avez besoin d’approfondir sur un secteur en particulier.

Sont exclus du champ d’application de DORA :

• les gestionnaires de fonds d’investissement alternatifs visés à l’Article 3(2) de la directive 2011/61/UE;
• les entreprises d’assurance et de réassurance en fonction de leur taille, telles que visées à l’Article 4 de la directive 2009/138/CE;
• les institutions de retraite professionnelle qui gèrent des régimes de retraite qui, ensemble, ne comptent pas plus de quinze affiliés au total;
• les personnes physiques ou morales exemptées en vertu des Articles 2 et 3 de la directive 2014/65/UE;
• les intermédiaires d’assurance, intermédiaires de réassurance et intermédiaires d’assurance à titre accessoire qui sont des micro-entreprises ou des PME. La définition est donnée dans l’article 4(60) de DORA : qui emploie moins de dix personnes et dont le CA annuel et/ou le total du bilan annuel n’excède pas 2 millions d’euros;
• les offices des chèques postaux visés à l’article 2(5.3), de la Directive 2013/36/UE.

A noter que les États membres peuvent choisir d’exclure du scope de DORA certaines entités nationales de crédit ou d’investissement très spécifiques, telles que visées à l’Article 2(5) de la directive 2013/36/UE. En France par exemple, l’Etat pourrait choisir d’épargner la Caisse des dépôts et consignations.

2. Prenez connaissance des exigences fixées par DORA

Comme vu précédemment, l’objectif de DORA est d’élever la résilience opérationnelle numériques des organismes financiers. Pour ce faire, l’Article 1 fixe des exigences précises concernant la sécurité des réseaux et des systèmes d’information (SI), à savoir :

• les exigences applicables aux entités financières en ce qui concerne:
  • la gestion des risques liés aux technologies de l’information et de la communication (TIC);
  • la notification aux autorités compétentes des incidents majeurs liés aux TIC et la notification, à titre volontaire, des cybermenaces importantes aux autorités compétentes;
  • la notification aux autorités compétentes des incidents opérationnels ou de sécurité majeurs liés au paiement;
  • les tests de résilience opérationnelle numérique;
  • le partage d’informations et de renseignements en rapport avec les cybermenaces et les cyber vulnérabilités;
  • les mesures destinées à garantir la gestion saine du risque lié aux prestataires tiers de services TIC;
• les exigences relatives aux accords contractuels conclus entre des prestataires tiers de services TIC et des entités financières;

Comme vous vous en doutez, ces exigences sont au cœur du reste de cet article.

3. Mettez en place un cadre de gestion du risque lié aux TIC

Là, on attaque un GROS morceau de la législation. Le Digital Operational Resilience Act met en exergue l’absolue nécessité d’avoir un framework de gestion du risque lié aux TIC – les technologies de l’information et de la communication.

“Les entités financières disposent d’un cadre de gestion du risque lié aux TIC solide, complet et bien documenté, faisant partie de leur système global de gestion des risques, qui leur permet de parer au risque lié aux TIC de manière rapide, efficiente et exhaustive et de garantir un niveau élevé de résilience opérationnelle numérique.” – DORA, Article 6(1)

A titre d’information, est défini comme un risque TIC :

“Toute circonstance raisonnablement identifiable liée à l’utilisation des réseaux et des systèmes d’information qui, si elle se concrétise, peut compromettre la sécurité des réseaux et des systèmes d’information, de tout outil ou processus dépendant de la technologie, du fonctionnement et des processus ou de la fourniture de services en produisant des effets préjudiciables dans l’environnement numérique ou physique.” – DORA, Article 3(5)

DORA : protéger le logiciel, le matériel et la donnée

Le framework doit détailler les éléments mis en place pour protéger les actifs dits TIC et informationnels de l’organisation. Là encore, référons-nous à l’Article 3 pour les définitions :

• “actif informationnel” : un ensemble d’informations, matérielles ou immatérielles, qui justifie une protection;
• “actif de TIC” : un actif logiciel ou matériel dans les réseaux et les systèmes d’information utilisés par l’entité financière.

Autrement dit, les acteurs du secteur financier doivent protéger non seulement leurs logiciels et le matériel physique (serveurs, endpoints, etc.), mais aussi les données. C’est là une évolution législative logique et bienvenue. Après tout, l’attaque d’un data center n’est jamais une finalité : c’est bien de l’accès à la data dont il est question.

Lorsque nous parlerons d’actifs dans le suite de cet article, il faudra donc comprendre comprendre “actifs informationnels” et “actifs de TIC” au regard des définitions précédentes.

Que devez-vous inclure dans le cadre de gestion du risque TIC ?

Toujours en vertu de l’Article 6, ce cadre obligatoire de gestion du risque TIC doit inclure a minima :

• les stratégies, les politiques, les procédures, les protocoles et les outils TIC nécessaires à la protection :
  • de tous les actifs informationnels et actifs TIC, soit les logiciels, le matériel informatique, les serveurs, etc;
  • de toutes les composantes et infrastructures physiques pertinentes pour la protection des actifs, comme les locaux et les data centers.

Comme vous allez le voir par la suite, DORA fonctionne comme un système de poupées russes de politiques. Ce framework de gestion du risque va être lui-même alimenté par la rédaction d’autres politiques spécifiques à différents sujets, de la continuité des services aux plans de rétablissement.

A noter que les organisations doivent tenir cette documentation à la disposition des autorités compétentes, qui peuvent demander à y avoir accès. Elles peuvent également demander un rapport sur le réexamen du cadre, ce qui nous amène au point suivant.

Mettez le framework à jour au moins une fois par an

Pas question de rédiger le cadre de gestion puis de le laisser prendre la poussière dans un coin. Il doit être mis à jour :

• au moins une fois par an (ou périodiquement pour les microentreprises);
• ou en cas de survenance d’incidents majeurs liés aux TIC;
• ou conformément aux éventuelles instructions des autorités de surveillance;
• ou suite aux conclusions tirées des tests de résilience ou des processus d’audit pertinents.

Implémentez un SMSI en tenant compte de DORA

Si ce n’est pas déjà fait, il est indispensable d’adopter un SMSI pour soutenir cette obligation de cadre des gestion des risques introduite par DORA. Avoir un système de management de la sécurité de l’information (SMSI) permet de réduire les risques numériques, en structurant la gestion de la sécurité de l’information de l’entité par une approche systémique.

ISO 27001 comme certification de référence

NIS2 laisse présager de futurs frameworks de certification européens en matière de cybersécurité. Mais d’ici là, la norme internationale ISO 27001 reste une référence pour la création d’un SMSI. Décrocher la certification ISO 27001 demande du travail, de l’organisation et surtout du temps. Aussi, ça devrait être l’un des chantiers prioritaires de tout RSSI concerné par DORA.

Un cadre simplifié de gestion du risque lié aux TIC pour certaines entités

Certaines entités ont droit à “un cadre simplifié de gestion du risque lié aux TIC”, en vertu de l’Article 16 de DORA. C’est une version allégée du cadre de gestion obligatoire amené par le Règlement.

Voici la liste des entités qui ont droit à ce cadre simplifié :

• les petites entreprises d’investissement non interconnectées;
• les établissements de paiement exemptés en vertu de la directive (UE) 2015/2366;
• les établissements exemptés en vertu de la directive 2013/36/UE – cf notre paragraphe sur les exceptions du scope de DORA;
• les établissements de monnaie électronique exemptés en vertu de la directive 2009/110/CE;
• les petites institutions de retraite professionnelle – celles gèrent des régimes de retraite comptant moins de cent affiliés au total.

4. Auditez régulièrement le cadre de gestion du risque TIC

Le cadre de gestion du risque TIC doit “faire l’objet d’audits internes réguliers” (Article 6.6). Il doit y avoir une séparation claire entre les fonctions de gestion du risque TIC, les fonctions de contrôle et les fonctions d’audit. Pour ce faire, l’Article 6(4) de DORA enjoint les entités financières à adopter le modèle des Trois Lignes de Défense (3LoD).

Adoptez le modèle des Trois Lignes de Défense (3LoD)

Le modèle 3LoD permet une séparation organisationnelle des responsabilités et de la gouvernance des risques. Concrètement :

• Une première ligne de défense par les métiers opérationnels, ceux qui sont sur le terrain. Ils ont la charge de simplifier la gestion du risque pour les lignes suivantes, en prenant en compte les facteurs de risques. Pour prendre l’exemple d’une équipe de développement, il peut s’agir de définir clairement les responsabilités de chacun, ou d’adopter une culture de cybersécurité par design avec des méthodes de développement sécurisé.
• Une deuxième ligne de défense par les fonctions de gestion des risques et de conformité, le RSSI par exemple. Cette deuxième ligne a la responsabilité de contrôler la première. Cela passe par la création des processus de surveillance, la mise en œuvre de la gestion globale des risques de l’entité, ou encore la vérification que les fonctions de l’entreprise travaillent dans le respect des politiques de gestion du risque – les RH, les commerciaux, le marketing, la Direction, tout le monde en somme !
• Une troisième ligne de défense par des auditeurs internes indépendants. Ils doivent s’assurer que les défenses instaurées par les deux lignes précédentes sont imperméables. Autrement dit : un contrôle holistique de l’application de la gestion des risques. Les auditeurs doivent vérifier les process et leur bonne application, puis rédiger des rapports d’audits détaillés. DORA précise l’évidence, mais les auditeurs internes doivent avoir “des connaissances, des compétences et une expertise suffisantes” en matière de gestion du risque TIC.

Pour que le modèle 3LoD fonctionne, chaque ligne doit être parfaitement indépendante – en particulier la dernière. DORA précise ainsi que les organisations doivent assurer “une séparation et une indépendance adéquates des fonctions de gestion du risque lié aux TIC, des fonctions de contrôle et des fonctions d’audit interne” afin d’éviter les conflits d’intérêts. Il est temps de relire Montesquieu et la séparation des pouvoirs !

Il est difficile de détailler un modèle 3LoD universel et réplicable partout, tant il dépend de l’activité, de la structure et des métiers de chaque organisation. Néanmoins, vous trouverez sur le web de nombreuses ressources pour vous guider dans la mise en œuvre de vos fortifications. Le dernier modèle en date de l’IIA (Institute of Internal Auditors) est un bon point de départ.

Une responsabilité de l’entité même en cas d’externalisation

DORA autorise l’externalisation des “tâches de vérification du respect des exigences en matière de gestion du risque lié aux TIC”, que ce soit à des acteurs externes ou internes au groupe. L’entité financière reste néanmoins totalement responsable de cette vérification. En clair : pas question de faire porter le chapeau de la négligence à un presta, la responsabilité des risques appartient aux entités financières.

5. Définissez une “stratégie de résilience opérationnelle numérique”

Le cadre de la gestion du risque TIC doit s’accompagner d’une stratégie de résilience opérationnelle numérique. Ce sont deux facettes d’une même pièce : là où le cadre de gestion du risque a une approche holistique, la stratégie de résilience a une approche pratico-pratique. Elle doit préciser les méthodes mises en place pour parer les risques et atteindre les objectifs de résilience.

Selon l’Article 6(8), cette stratégie de résilience doit :

• expliquer comment le cadre soutient la stratégie d’entreprise et les objectifs de l’entité financière;
• déterminer le niveau de tolérance au risque lié aux TIC, en fonction de l’appétit pour le risque de l’entité financière, et en analysant la tolérance à l’incidence des dysfonctionnements des TIC;
• définir des objectifs clairs en matière de sécurité de l’information, y compris des indicateurs de performance clés et des indicateurs de risque clés;
• décrire l’architecture des TIC de référence et les changements nécessaires pour atteindre des objectifs spécifiques de l’entité financière;
• présenter les différents mécanismes mis en place pour détecter et prévenir les incidents liés aux TIC, ainsi que pour se protéger contre leurs effets;
• présenter la situation actuelle en matière de résilience opérationnelle numérique sur la base du nombre d’incidents majeurs liés aux TIC signalés et de l’efficacité des mesures de prévention;
• mettre en œuvre des tests de résilience opérationnelle numérique;
• et définir une stratégie de communication en cas d’incidents liés aux TIC qui doivent être divulgués.

Selon l’envergure du groupe, il est tout à fait possible de mettre en place une stratégie globale multi-fournisseurs. La stratégie devra alors motiver ce choix, et détailler les principales relations de dépendance à l’égard des différents prestataires.

Suivre et améliorer l’efficacité de la stratégie dans le temps

L’Article 13 appelle les entités financières à contrôler l’efficacité de la mise en œuvre de leur stratégie de résilience opérationnelle numérique. Cela passe par un suivi de l’évolution du risque TIC dans le temps, en analysant la fréquence, les types, l’ampleur et l’évolution des incidents. L’accent est mis sur le suivi des cyberattaques et leurs caractéristiques, afin de cerner l’évolution du niveau d’exposition au risque de l’entité, en particulier pour les fonctions critiques ou importantes.

La stratégie doit être améliorée en continu grâce aux enseignements tirés :

• des examens obligatoires après un incident majeur – cf. le point 11;
• des difficultés rencontrées lors de l’activation des plans de continuité des activités, et des plans de réponse et de rétablissement – cf. les points 8 et 9;
• de la veille sur les cybermenaces et des dispositifs d’échange d’informations – cf. le point 13;
• des tests de résilience opérationnelle – cf. les points 14 et 15;

Un compte-rendu doit être fait aux organes de direction de l’entité au moins une fois par an (Article 13.5). Il doit inclure les constatations des points précédents, ainsi que des recommandations.

6. Mettez en place des mécanismes de protection et de résilience des actifs

La stratégie de résilience doit “présenter les différents mécanismes mis en place pour détecter et prévenir les incidents, ainsi que pour se protéger contre leurs effets”. Ici, pas de secret, il va falloir recourir à une batterie de procédures et d’outils adéquats.

Les critères minimums de protection et de résilience

Pour protéger les actifs dans le respect de l’Article 9, les outils et les processus mis en place doivent a minima :

• garantir la sécurité des moyens de transfert de données;
• réduire au minimum le risque de corruption ou de perte de données, d’accès non autorisé et de défauts techniques susceptibles d’entraver les activités;
• empêcher le manque de disponibilité, les atteintes à l’authenticité et à l’intégrité, les violations de la confidentialité et la perte de données;
• garantir que les données sont protégées contre les risques découlant de la gestion des données, y compris une mauvaise administration, les risques relatifs au traitement et l’erreur humaine;
• garantir une gestion solide des réseaux et des infrastructures, pouvant inclure des mécanismes automatisés pour isoler les actifs informationnels affectés en cas de cyberattaques;

Afin de prévenir la contagion, l’infrastructure de connexion au réseau doit être pensée de manière à permettre une déconnexion instantanée ou segmentée, en particulier pour les processus financiers interconnectés. En clair : il faut pouvoir tout débrancher à la volée en cas de gros problème.

Toujours plus de politiques à documenter

Les entités financières doivent également documenter :

• une politique de sécurité de l’information qui définit les règles visant à protéger la disponibilité, l’authenticité, l’intégrité et la confidentialité des actifs et de la data, y compris de leurs clients le cas échéant;
• des politiques qui restreignent l’accès (physique ou logique) aux actifs et aux données selon les fonctions, les rôles et les missions de chacun. Autrement dit, adopter et documenter une logique du “besoin d’en connaître”;
• des politiques et des protocoles pour des mécanismes d’authentification forte et des mesures de protection des clés de chiffrement. Les pistes sont nombreuses, à commencer par l’adoption du 2FA comme méthode d’authentification par défaut pour tous les collaborateurs.
• des politiques, des procédures et des contrôles pour la gestion des changements dans les TIC, y compris les changements apportés aux logiciels, au matériel, aux composants de micrologiciels, aux systèmes ou aux paramètres de sécurité. Ils doivent être fondés sur une approche d’évaluation des risques et faire partie intégrante du processus global de gestion des changements de l’entité financière. A ce titre, le processus de gestion des changements dans les TIC doit être approuvé par la structure hiérarchique appropriée;
• des stratégies appropriées et globales en matière de correctifs et de mises à jour.

7. Installez des solutions de détection

Une bonne protection des actifs passe également par une bonne capacité de détection des anomalies, des incidents et des cyberattaques. On pense ici aux EDR, XDR, scanners, SIEM, etc. L’Article 10 de DORA précise ainsi que les entités financières doivent y allouer “des ressources et des capacités suffisantes”.

Pour répondre aux exigences de la Réglementation, les mécanismes de détection doivent :

• permettre plusieurs niveaux de contrôle, définir des seuils d’alerte et des critères de déclenchement et de lancement des processus de réponse en cas d’incident, y compris des mécanismes d’alerte automatique destinés au personnel compétent (le SOC à tout hasard);
• et être testés régulièrement.

On en profite pour vous recommander la lecture de notre article sur les EDR ainsi que celui sur les règles SIGMA, un outil collaboratif qui permet de standardiser les détections quel que soit le SIEM. Pratique si vous décidez de faire une migration vers une autre solution dans le cadre de DORA.

8. Rédigez une politique de continuité des activités TIC

La Réglement DORA veut que :

“les entités financières se dotent d’une politique de continuité des activités de TIC complète, qui peut être adoptée en tant que politique spécifique, et qui forme une partie intégrante de leur politique globale de continuité des activités” – DORA, Article 11

Cette politique de continuité des activités de TIC doit permettre :

1. de garantir la continuité des fonctions critiques ou importantes de l’entité financière;
2. de répondre aux incidents et les résoudre rapidement, dûment et efficacement de manière à limiter les dommages et à donner la priorité à la reprise des activités et aux mesures de rétablissement;
3. d’activer des plans spécifiques pour endiguer chaque type d’incident et prévenir tout dommage supplémentaire, ainsi que des procédures sur mesure de réponse et de rétablissement – cf. #9;
4. d’estimer les incidences, les dommages et les pertes préliminaires;
5. de définir des mesures de gestion des crises et de communication à destination des équipes internes, des parties prenantes externes concernés et des autorités compétentes – cf. #10. #10.

Là encore il faut prévenir, endiguer et remédier, mais surtout assurer la résilience des services.

Testez les plans de continuité au moins une fois par an

Une fois de plus, le texte de DORA se montre très terre à terre. Il faut documenter les mesures, mais aussi tester leur efficacité. L’Article 11(6) veut que les organismes financiers testent :

• les plans de continuité des activités TIC et les plans de réponse et de rétablissement des TIC :
  • au moins une fois par an;
  • ainsi qu’en cas de modifications substantielles apportées aux systèmes de TIC qui soutiennent des fonctions critiques ou importantes.
• ainsi que les plans de communication en situation de crise.

Les plans de test doivent intégrer des scénarios de cyberattaques et de basculement entre l’infrastructure de TIC principale et la capacité redondante, les sauvegardes et les installations redondantes enjointes par DORA.

Tenez un registre des activités en cas de perturbations

Si lesdits plans venaient à être activés, les entités doivent tenir “un registre, facile d’accès, des activités avant et pendant les perturbations”, cf. l’Article 11(8). Si les autorités compétentes le demandent, les organisations doivent également fournir une estimation des coûts et pertes annuels agrégés occasionnés par des incidents majeurs.

9. Prévoyez des procédures de sauvegarde, de restauration et de rétablissement (et les politiques associées)

Le Règlement sur la résilience opérationnelle du numérique cherche à limiter au maximum les perturbations et la durée d’indisponibilité des systèmes et des données. Concrètement, cela se traduit par trois axes de travail : sauvegarde, restauration et rétablissement. Ils se déclinent en autant de politiques, qui s’inscrivent elles-mêmes dans la politique de continuité des activités.

Les entités financières doivent ainsi mettre en place :

• des politiques et procédures de sauvegarde qui précisent :
  • la portée des données concernées par la sauvegarde;
  • et sa fréquence minimale, en fonction de la criticité des informations ou du niveau de confidentialité des données;
• des procédures et méthodes de restauration et de rétablissement.

Activer un système de sauvegarde ne doit pas compromettre la disponibilité, l’authenticité, l’intégrité ou la confidentialité des données. Pas question donc de geler les services le temps de faire marche arrière. Par ailleurs, DORA (Art. 12.4) introduit une obligation de redondance de systèmes. Ces derniers doivent donc être dupliqués afin d’assurer un relais si le système original venait à tomber.

Pour ce qui est de la restauration, si une entité décide de restaurer des données de sauvegarde à l’aide de ses propres systèmes, elle doit faire en sorte qu’ils soient séparés physiquement et logiquement du système source.

Enfin, l’ensemble des procédures de sauvegarde, de restauration et de rétablissement doivent faire l’objet de tests réguliers en vertu de l’Article 12(2).

Notons que les micro-entreprises ne sont pas concernées par la plupart de ces exigences, ou peuvent les apprécier selon leur profil de risque. Les dépositaires centraux de titres sont quant à eux soumis à des exigences supplémentaires, comme avoir un site de traitement des données secondaire. Au besoin, tout est détaillé dans l’Article 12(5).

10. Préparez des plans de communication en situation de crise

L’Article 14 de DORA est court mais précis. Il clarifie les obligations des entités financières en matière de communication en cas d’incidents.

“Les entités financières mettent en place des plans de communication en situation de crise qui favorisent une divulgation responsable, au minimum, des incidents majeurs liés aux TIC ou des vulnérabilités majeures aux clients et aux contreparties ainsi qu’au public, le cas échéant.” – DORA, Article 14(1)

Outre ces plans de communication à visée externe, les organisations doivent prévoir des plans similaires pour l’interne et les parties prenantes externes. En cas de survenance d’un incident, la politique de communication interne se doit de faire la distinction entre :

• le personnel qui doit être informé;
• et le personnel qui participe activement à la gestion du risque, notamment en ce qui concerne la réponse et le rétablissement.

Désignez un responsable des communications de crise

DORA demande noir sur blanc à ce qu’une personne au minimum soit désignée responsable de ce sujet. Il peut être judicieux de se synchroniser avec les équipes juridiques, de communication et marketing sur la posture à tenir, et les processus à adopter.

“Au moins une personne au sein de l’entité financière est chargée de mettre en œuvre la stratégie de communication concernant les incidents liés aux TIC et remplit la fonction d’information du public et des médias à cette fin.” – DORA, Article 14(3)

Le plan de communication nous amène tout droit au point suivant, puisqu’il doit être intégré au processus de gestion des incidents.

11. Etablissez un processus de gestion des incidents

Avec DORA, les entités financières doivent impérativement mettre en œuvre un processus de gestion des incidents – liés aux TIC évidemment, cette précision étant entendue dans l’ensemble de ce papier. Ce processus de gestion des incidents vient alimenter la politique de continuité des activités (cf. le point 8) et la stratégie de résilience (#5), qui s’inscrivent elles-mêmes dans le cadre de gestion du risque lié aux TIC (#3). Quand on vous disait que DORA était organisé comme une véritable matriochka de politiques…

DORA : une obligation d’enregistrer tous les incidents

Ce processus n’est pas une fin en soi : il doit permettre d’enregistrer toutes les cybermenaces importantes et tous les incidents (et pas seulement les plus importants). Il va sans dire que la consignation de l’intégralité des incidents est impossible sans une capacité de détection irréprochable – cf. le point 6 de cet article.

En vertu de l’Article 17, le processus de gestion des incidents doit :

• mettre en place des indicateurs d’alerte précoce;
• instaurer des procédures destinées à identifier, suivre, consigner, catégoriser et classer les incidents en fonction de leur priorité et de leur gravité, et en fonction de la criticité des services touchés;
• attribuer les rôles et les responsabilités qui doivent être activés pour différents types et scénarios d’incidents;
• établir des plans pour la communication à l’intention du personnel, des parties prenantes externes et des médias;
• permettre de notifier au minimum les incidents majeurs aux membres de la direction concernés, et de communiquer leurs incidences, la réponse à leur apporter et les contrôles supplémentaires à mettre en place par la suite;
• définir des procédures de réponse en cas d’incident, afin d’en atténuer les effets et de garantir que les services redeviennent opérationnels et sécurisés en temps utile.

La classification des incidents selon DORA

D’après l’Article 18 de DORA, les entités financières doivent classer les incidents sur la base des critères suivants:

1. le nombre et/ou l’importance des clients ou des contreparties financières touchés et, le cas échéant, le volume ou le nombre de transactions touchées par l’incident, et si cet incident a porté atteinte à la réputation;
2. la durée de l’incident, y compris les interruptions de service;
3. la répartition géographique des zones touchées par l’incident, en particulier si celui-ci touche plus de deux États membres;
4. les pertes de données occasionnées par l’incident en ce qui concerne la disponibilité, l’authenticité, l’intégrité ou la confidentialité des données;
5. la criticité des services touchés, y compris les transactions et les opérations de l’entité financière;
6. les conséquences économiques de l’incident, en particulier les coûts et pertes directs et indirects, en termes absolus et relatifs.

Les organisations doivent également déterminer si une cybermenace est significative ou non, sur une base similaire à la liste ci-dessus.

DORA fixe les grandes lignes en matière de classification des incidents, mais les seuils exacts sont encore incertains. Ils seront définis par les AES, la BCE et l’ENISA, qui ont jusqu’au 17 janvier 2024 pour soumettre leurs recommandations à la Commission. Il va donc falloir patienter, même si le bon sens et la connaissance de votre organisation devraient déjà vous permettre de coucher une première grille de classification qui vous est personnelle.

Des examens obligatoires après un incident majeur

L’Article 13 dispose que les organisations doivent conduire des examens post-incident obligatoires après la survenance d’un incident majeur qui a perturbé leurs activités principales.

Ces examens doivent déterminer :

• si les procédures établies ont été suivies;
• et si elles ont été efficaces en ce qui concerne :
  • la célérité de la réponse aux alertes de sécurité et de l’évaluation des effets de l’incident, et de sa gravité;
  • la qualité et la rapidité de l’analyse technico-légale;
  • l’efficacité de la remontée des incidents au sein de l’entité;
  • l’efficacité de la communication interne et externe.

C’est quoi, un “incident majeur” ?

Ah, c’est à cette question que l’on voit ceux qui suivent ! On vous laisse avec la définition telle que donnée par le texte :

«Incident majeur lié aux TIC» : un incident lié aux TIC qui a une incidence négative élevée sur les réseaux et les systèmes d’information qui soutiennent les fonctions critiques ou importantes de l’entité financière. – DORA, Article 3(10)

On en profite pour glisser la définition d’une “cybermenace importante” :

«Cybermenace importante»: une cybermenace dont les caractéristiques techniques indiquent qu’elle pourrait donner lieu à un incident majeur lié aux TIC ou à un incident opérationnel ou de sécurité majeur lié au paiement; – DORA, Article 3(13)

12. Rédigez et documentez votre plan de réponse aux incidents

L’une des premières choses à faire pour alimenter le processus de gestion des incidents est de rédiger (ou réviser) votre plan de réponse aux incidents – ou IRP pour Incident Response Plan. Il s’avèrera précieux quand vous serez confronté à une obligation de réponse – que ce soit à des partenaires, des clients ou des autorités compétentes.

Vous trouverez sur le web de nombreuses ressources utiles pour construire votre IRP. Gardez en tête qu’il doit respecter les obligations de réponse aux autorités compétentes introduites par DORA, ce qui nous amène directement au point suivant.

Sachez à quelle “autorité compétente” votre entité doit répondre

Précisons d’emblée que les autorités compétentes ne sont pas les mêmes pour toutes les entités financières. Le sujet est bien trop vaste pour que nous puissions toutes les détailler ici. Aussi, nous vous renvoyons plutôt vers l’Article 46 de DORA, le bien nommé “Autorités Compétentes”, qui vous éclairera sur votre propre situation. A noter que le principe de proportionnalité dont nous avons parlé précédemment s’applique ici. Si vous êtes soumis à plusieurs autorités nationales, c’est l’Etat qui devra se charger de trancher laquelle prévaut.

Par ailleurs, en vertu de l’Article 19(1), les Etats ont la liberté d’imposer à une ou plusieurs des entités financières sur leur territoire une double obligation de réponse :

• à l’autorité compétente au regard de DORA;
• mais aussi aux autorités compétentes ou aux centres de réponse aux incidents de sécurité informatique (CSIRT) désignés dans le cadre de NIS2.

Cela n’est pas obligatoire, mais possible. Il appartient donc à chaque entité de vérifier son cas particulier.

Les obligations de réponse aux autorités compétentes

Vous devriez maintenant savoir à quelle autorité compétente vous êtes assujetti ; reste à savoir quand la contacter.

En cas d’incident majeur, l’Article 19(4) dispose que les entités financières doivent soumettre à l’autorité compétente concernée :

• une notification initiale;
• un rapport intermédiaire dès que la situation de l’incident initial a sensiblement changé ou que le traitement de l’incident majeur a changé sur la base des nouvelles informations disponibles;
  • le cas échéant, des notifications actualisées doivent être envoyées à chaque fois qu’une mise à jour pertinente de la situation est disponible, ainsi que sur demande spécifique de l’autorité compétente;
• un rapport final, lorsque l’analyse des causes originelles est terminée, que des mesures d’atténuation aient déjà été mises en œuvre ou non, et lorsque les chiffres relatifs aux incidences réelles sont disponibles en lieu et place des estimations.

Les entités financières peuvent également notifier, à titre volontaire, les cybermenaces importantes à l’autorité compétente concernée lorsqu’elles estiment qu’elle est pertinente pour le système financier, les utilisateurs de services ou les clients.

Notons également que le Règlement DORA autorise l’externalisation des obligations de déclaration à un prestataire tiers de services – cf l’Article 19(5). Néanmoins, l’entité financière reste pleinement responsable du respect de ses exigences. Là encore, impossible de déporter la responsabilité sur un presta !

Quels sont les délais à respecter pour les obligations de réponse DORA ?

Les délais qui s’appliquent à chaque notification sont à ce jour encore inconnus, et doivent être précisés par les AES, l’ENISA et la BCE au plus tard le 17 janvier 2024. Néanmoins, il nous paraît crédible de supposer que les délais prévus par DORA seront similaires à ceux amenés par la directive NIS2, qui requiert :

• une notification initiale dans un délai de 24h après la survenance de l’incident majeur;
• une notification intermédiaire dans un délai de 72h;
• un rapport final au plus tard un mois après la remise du premier rapport

Là encore, rien ne dit que DORA s’alignera sur NIS2, ce n’est qu’une simple supposition de notre part. Si vous souhaitez en savoir plus sur ces délais de réponse, nous ne pouvons que vous conseiller de lire notre guide de conformité pour NIS2.

Les obligations de réponse aux clients

DORA n’amène pas que des obligations de réponse aux autorités compétentes, mais aussi aux clients ! On vous laisse ici l’extrait en question, qui est parfaitement limpide :

“Lorsqu’un incident majeur lié aux TIC survient et a une incidence sur les intérêts financiers des clients, les entités financières informent leurs clients de cet incident majeur lié aux TIC et des mesures qui ont été prises pour atténuer les effets préjudiciables de cet incident sans retard injustifié, dès qu’elles en ont connaissance.

En cas de cybermenace importante, les entités financières informent, le cas échéant, leurs clients susceptibles d’être affectés de toute mesure de protection appropriée que ces derniers pourraient envisager de prendre.” – DORA, Article 19(3)

Cette prise de contact avec les clients devra évidemment s’appuyer sur vos plans de communication en situation de crise – un sujet abordé au point 10.

13. Opérez une veille sur les cyber-menaces

Le savoir est une arme, en cybersécurité peut-être encore plus qu’ailleurs. Les attaquants rivalisent d’ingéniosité pour parvenir à leurs fins, et les sous-estimer serait une grave erreur. Un RSSI se doit donc d’être au courant du paysage mouvant des cybermenaces. Le Top 10 OWASP annuel est un bon début, mais loin d’être suffisant pour appréhender la totalité des risques. La veille doit être assidue, collective et continue.

La veille cyber est un sujet amené par DORA dans son Article 13. Il dispose que les entités financières doivent se doter de capacités et d’effectifs pour recueillir des informations sur les vulnérabilités et les cybermenaces. Elles doivent également assurer un suivi continu des évolutions technologiques, afin de déterminer l’incidence que leur déploiement pourrait avoir sur les exigences en matière de cybersécurité et de résilience opérationnelle numérique.

Notre recommandation est de mettre en place une cellule de veille interne, composée des éléments les plus alertes sur les sujets cyber, avec une mise en commun régulière des trouvailles. Mais c’est là une piste de réflexion parmi d’autres.

Un rapport annuel publié par les AES sur les incidents majeurs dans le secteur financier

L’Article 22 de DORA enjoint les AES à publier chaque année un rapport anonymisé et agrégé sur les incidents majeurs liés aux TIC. Il devra indiquer au minimum le nombre d’incidents majeurs, leur nature, leurs répercussions, les mesures correctives prises et les coûts. Il s’accompagnera d’avertissements et de statistiques “de haut niveau”.

On peut d’ores et déjà dire, sans trop nous risquer, que ce rapport annuel sera un incontournable de la veille cyber dans le secteur financier.

Des dispositifs de partage d’informations sur les cybermenaces entre les établissements financiers

L’entraide au sein du système bancaire est encouragée par DORA. Le Chapitre VI dispose ainsi que les entités financières peuvent créer des dispositifs pour partager entre elles des informations et des renseignements sur les cybermenaces, allant des indicateurs de compromis aux techniques et tactiques en passant par les procédures et les outils.

Ce partage d’informations entre établissements financiers doit :

• viser à améliorer la résilience opérationnelle numérique des entités;
• se dérouler au sein de communautés de confiance;
• reposer sur des dispositifs qui protègent la nature potentiellement sensible des informations partagées. Ces échanges doivent se faire dans le respect de la confidentialité des affaires, du RGPD et des lignes directrices sur la politique de concurrence.

Les dispositifs de partage en question doivent définir les modalités concrètes de partage (où, comment ?) et les conditions de participation à respecter – aussi bien pour les entités financières que pour les autorités publiques et les prestataires de services TIC. Par ailleurs, toute entité financière qui participe à un tel dispositif doit en notifier les autorités compétentes.

14. Conduisez des “tests de résilience opérationnelle numérique”

On attaque là un autre gros pan de la réglementation. Les tests de résilience font partie intégrante de la stratégie de résilience opérationnelle numérique, et DORA leur consacre tout son Chapitre IV. De notre côté, nous parlerons par la suite de “tests de résilience” ou de “tests de sécurité” par facilité de langage.

Précisons d’emblée que les microentreprises ne sont pas concernées par la plupart de ces exigences. Si c’est votre cas, nous vous invitons à parcourir le Chapitre IV (notamment l’Article 25.3) pour déterminer ce qui est applicable ou non. Inutile de faire durer le suspense plus longtemps, alors passons aux choses sérieuses.

Un guide de 60 pages sur les tests de sécurité DORA

Nous avons rédigé un guide complet de 60 pages consacré intégralement à la question des tests de sécurité pour les entités réglementées par DORA. Nous n’aborderons donc que brièvement ce sujet dans cet article.

Vous pouvez lire notre guide complet sur les tests de sécurité DORA sous forme d’articles sur notre blog, ou le télécharger au format PDF ci-dessous pour une lecture plus aisée.