Règlement DORA : comment préparer sa mise en conformité ?

Le règlement DORA (pour Digital Operational Resilience Act, ou “Règlement sur la résilience opérationnelle numérique du secteur financier”) est un règlement européen qui vise à unifier la gestion des risques informatiques dans le secteur financier.

Ce règlement, qui entre en application en janvier 2025, impose un certain nombre de pratiques liées à la gestion du risque informatique aux acteurs du secteur financier. Le but de cet article est de vous en donner un rapide overview pour vous aider à anticiper le mieux possible votre conformité au règlement DORA.

⚠️DISCLAIMER : Vous vous en doutez, cet article est un condensé et n’entre donc pas dans le détail ni des obligations, ni des cas particuliers. Il peut servir de base à votre réflexion, mais ne doit pas remplacer un accompagnement par un professionnel du sujet.

Le règlement DORA en bref

Comme dit ci-dessus, le règlement DORA est la réponse de l’Europe au risque cyber toujours plus important qui cible son secteur financier. Avec la multiplication des canaux et des acteurs, ce règlement vise à améliorer la résilience numérique du secteur en imposant aux entités financières une meilleure gestion des risques liés aux TIC, c’est-à-dire tout ce qui est lié "à l’utilisation des réseaux et des systèmes d’information".

Qui est concerné par le règlement DORA ?

De façon générale, tous les acteurs du secteur financier sont concernés. Nous vous avons repris la liste des acteurs précis qui doivent être conformes au règlement DORA, que vous pouvez aussi retrouver dans le texte officiel.

Quelles sont les exigences ?

En janvier 2025, toutes les entreprises concernées par DORA devront avoir mis en place des mesures concrètes sur 4 grands piliers :

• Gestion du risque informatique
• Processus de gestion/classification/notification des incidents
• Tests de leur résilience opérationnelle
• Gestion des risques liés à leurs prestataires de services

Le 5e grand axe du règlement concerne la possibilité de partage des informations liées aux risques TIC entre les acteurs du secteur financier, mais celle-ci n’étant liée à aucune obligation, nous ne la détaillerons pas ici.

Quelles sont les sanctions ?

Il est important de noter que le règlement DORA ne prévoit pas de sanction en cas de non-respect des obligations, mais permet aux pays membres d’en mettre en place au niveau national.

La France ayant une tradition pénale en matière de sanction des non-conformités aux obligations liées au risque cyber, on peut s’attendre à des mesures du même type que celles infligées par la CNIL pour le RGPD par exemple (jusqu’à 20 millions d’euros ou 4 % du chiffre d’affaires annuel mondial).

Principe essentiel : la proportionnalité

Le règlement DORA inclut un principe de proportionnalité. En effet, il précise bien qu’il faut prendre en compte dans le niveau de mise en conformité certains critères, comme :

• La taille de l’entité
• Le profil de risque global
• La nature, de l'échelle et de la complexité des activités

Concrètement, une petite banque locale n'aura pas les mêmes obligations qu'une grande banque internationale, et une banque qui propose des services de paiement en ligne aura des obligations plus strictes en matière de sécurité que celle qui propose des services bancaires traditionnels.

Cela permet d’assurer que chaque acteur, à son niveau, contribue à la résilience du secteur financier.

DORA : comment préparer sa conformité sur ses 4 grands piliers

Gestion du risque lié aux TIC

Le premier pilier est sans doute celui qui va demander le plus de réflexion, mais aussi celui qui va permettre d’utiliser la mise en conformité avec le règlement DORA pour améliorer le plus efficacement le service rendu par les acteurs financiers à leurs utilisateurs.

Les obligations liées à la gestion du risque liées aux TIC peuvent être découpées en 6 parties majeures.

• L’obligation de mettre en place une organisation de gouvernance pour gérer les risques liés aux TIC

Les acteurs qui sont soumis au règlement DORA doivent mettre en place un système de gouvernance/contrôle des risques. Ce système est défini, et supervisé par la direction de l’entité, qui en est responsable. Le règlement liste un certain nombre d’obligations très précises concernant la direction de l’entité dans son article 5.2.

Ce système doit intégrer un rôle spécifique, désigné pour gérer le risque lié aux 3rd party. Il doit prendre en compte des actions de sensibilisation et formation du management aux risques TIC.

Afin de rester pertinents dans les décisions prises, les membres de l’organe de direction doivent se former régulièrement sur les risques TIC.

• Cette gouvernance est garante de l’implémentation d’un cadre de gestion des risques liés aux TIC :

La stratégie de l’acteur doit reposer sur la mise en place d’un cadre documenté de gestion des risques liés aux TIC. Ce cadre doit lister tout ce qui est mis en place pour gérer les risques TIC : stratégies, politiques, procédures, protocoles, outils…

La gestion de ce cadre doit être confiée à une fonction suffisamment indépendante. Ce cadre doit être revu annuellement, avec une dynamique d’amélioration continue (comme ISO27001), et audité régulièrement. À la demande, il doit être possible de fournir un rapport sur son fonctionnement à une autorité compétente.

Ce cadre doit contenir une section qui identifie, classifie et documents tous les assets liés aux TIC (les logiciels, le matériel informatique, les serveurs, les composantes et infrastructures physiques comme des locaux, centres de données et zones sensibles désignées), ainsi que les fonctions supportées par des assets informatiques.

• Ce cadre de gestion est complémenté par des mesures opérationnelles de sécurité

Afin de s’assurer que ce cadre s’appuie sur une base opérationnelle solide, le règlement DORA fait peser sur les acteurs financiers une obligation de mise en place d’un système de détection des risques, et de respect des bonnes pratiques de sécurité.

L’acteur visé doit implémenter un système opérationnel de détection des risques. Celui-ci peut contenir plusieurs niveaux de contrôles en fonction de la criticité des assets visés, avec chacun des seuils d’alertes et procédures de réaction propres. Ce système doit bénéficier de ressources suffisantes pour pouvoir surveiller efficacement l’activité liée aux TIC. Pour une structure de taille petite ou moyenne, on pourra par exemple se diriger vers un SOC managé.

L’acteur visé par DORA doit également implémenter de la sécurité en profondeur, en respectant un certain nombre de bonnes pratiques techniques : chiffrement des données, sécurité des configurations de l’infrastructure, respect du principe de moindre privilège dans la gestion d’accès…

• La gestion des risques doit intégrer la gestion du cycle de vie des sauvegardes, ainsi que des plans de continuité et reprise d’activité.

Le règlement DORA intègre explicitement la gestion des sauvegardes au cadre de gestion des risques TIC : un acteur visé par DORA doit pouvoir montrer la preuve d’une gestion documentée du cycle de vie des sauvegardes, c’est-à-dire :

• Des procédures documentées
• Automatisées autant que possibles
• Qui utilisent des ressources redondantes, physiquement et logiquement séparées des systèmes principaux
• Et qui sont vérifiées régulièrement, en suivant une démarche documentée d’amélioration continue

Ces procédures de sauvegarde permettent d’établir un plan de continuité d’activité pour les fonctions critiques (PCA), ainsi qu’un plan de reprise d’activité (PRA) suite à un incident. Ces plans doivent être testés régulièrement, et comporter une partie qui détaille les communications à faire en interne, en externe et au public.

Le processus de gestion, classification et notification des incidents

L’accent est mis par DORA sur la documentation et la traçabilité, dans le but de permettre aux acteurs du système financiers d’apprendre et d’échanger sur leurs incidents, et de permettre à tout le système d’améliorer progressivement sa résilience.

Le 2ème pilier du règlement est donc celui de la gestion, classification et notification des incidents.

• Gestion des incidents

Tous les acteurs doivent mettre en place un processus de gestion des incidents liés aux TIC. Ce processus va s’appuyer sur les éléments mis en place dans le volet “gestion des risques”, et détailler l’articulation entre les procédures opérationnelles de gestion de l’incident, la mise en œuvre de mesures de crise (activation du PCA, PRA…) et les actions de classification et notification des incidents.

• Classification des incidents

Les acteurs doivent garder une trace de tous les incidents et menaces TIC. Le règlement DORA précise un certain nombre de critères qui doivent être utilisés pour cette classification, parmi lesquels :

• Le nombre et/ou l'importance des clients ou des contreparties financières
• Le montant ou le nombre de transactions touchées,
• L’impact réputationnel et la durée de l'incident
• Que sa portée géographique.
• Les pertes de données,
• La criticité des services touchés
• L’impact économique de l'incident, y compris les coûts et les pertes directs et indirects.

Il est important de veiller à ce que tous les critères soient utilisés.

• Notification des incidents

Le règlement DORA prévoit que les incidents “majeurs” liés aux TIC devront être notifiés à l’autorité de référence (qui dépend du type d’acteur visé), selon le processus suivant :

• Notification initiale
• Rapport intermédiaire en cas de changement de situation, avec si nécessaire des actualisations
• Rapport final une fois que l’analyse des causes originelles est terminée et que l’on dispose de données réelles sur l’impact. Ce rapport peut être remis avant que des mesures d’atténuation aient été mises en œuvre.

En plus de cette notification à l’autorité de référence, si un incident impacte les intérêts financiers des clients, les entités financières doivent en informer leurs clients, en expliquant les mesures qui ont été prises pour atténuer les effets l’incident.

La définition d’un incident “majeur” doit être précisée par une concertation mixte entre les agences européennes de sécurité, la BCE et l’ENISA (agence de l'Union européenne pour la cybersécurité).

Les tests de résilience opérationnelle

Une fois que des fondations solides de sécurité opérationnelle, de détection et de gestion des incidents ont été mises en place, le règlement DORA prévoit une obligation de soumettre ces fondations à des tests de résilience, pour anticiper au mieux les défauts du système en situation réelle.

• La fréquence des tests

Le règlement DORA transforme en obligation ce qui était jusqu’ici une bonne pratique : effectuer un test de tous les systèmes et applications de TIC qui soutiennent des fonctions critiques ou importantes, au moins une fois par an.

Le règlement prévoit cependant un allègement de cette obligation dans le cas des microentreprises, pour lesquelles le principe de proportionnalité permet de diminuer cette fréquence tout en restant conforme aux exigences DORA.

Le règlement prévoit aussi l’obligation d’effectuer au moins tous les trois ans des tests plus poussés, au moyen d’un programme red team.

• Le périmètre

Selon le périmètre visé, le test peut être plutôt orienté white box (comme un audit de sécurité) ou black box (comme un test d’intrusion). Le règlement liste une série de types de tests qui peuvent être pertinents :

• Analyses de vulnérabilité,
• Analyses de sources ouvertes,
• Évaluations de la sécurité des réseaux,
• Analyses des écarts,
• Examens de la sécurité physique,
• Questionnaires et solutions logicielles de balayage,
• Examens du code source,
• Tests fondés sur des scénarios,
• Tests de compatibilité,
• Tests de performance,
• Tests de bout en bout,
• Tests de pénétration

Gestion des risques liés aux prestataires de services

Le dernier pilier de la conformité au règlement DORA est la gestion des risques TIC liés à l’interconnexion des réseaux informatiques entre donneur d’ordre et prestataires. Le but de ce pilier est de permettre à des acteurs qui mettent en place les bonnes pratiques proposées par le règlement DORA de faire pression sur leur écosystème pour que celui-ci soit aussi acteur de l’augmentation de la résilience du système.

Cet axe porte à la fois sur des actions qui doivent être mises en place par l’acteur financier, et sur des obligations qui portent sur les relations contractuelles entre l’acteur et ses prestataires.

Les prestataires liés aux TIC font partie intégrante des risques à prendre en compte, toujours sous le principe de proportionnalité (ampleur des relations de dépendance, criticité des services supportés…)

• Les obligations de l’acteur financier liées à ses prestataires de services

L’acteur financier (hors microentreprise) qui souhaite être conforme au règlement DORA doit mettre en place une stratégie de gestion des risques liés à ses prestataires. Pour cela, il doit mettre en place :

Une politique sur l’utilisation de prestataires pour les services qui soutiennent des fonctions critiques ou importantes.

Un registre de ses prestataires, qui liste pour chaque prestataire les informations contractuelles et les fonctions supportées, et fait une différence claire entre les accords qui touchent aux fonctions critiques et les autres.

Ce registre peut être demandé à tout moment, et ses changements (nouveaux accords contractuels…) doivent être communiqués au moins une fois par an aux autorités compétentes.

• Les obligations liées à la contractualisation avec des prestataires de services

Le règlement DORA précise un processus à suivre lors de la contractualisation avec un prestataire de services TIC, ainsi qu’un certain nombre de clauses à inclure dans le contrat.

Avant de conclure un contrat avec un prestataire, les acteurs financiers doivent :

• Déterminer si les fonctions visées sont considérées comme importantes ou critiques
• Identifier les risques liés à ce contrat (y compris le risque de concentration des prestations informatiques dans les mains d’un nombre réduit de prestataires)
• Évaluer si les prestataires respectent les normes, bonnes pratiques et qualités requises pour la fonction
• Évaluer si le contrat peut donner lieu à un conflit d’intérêts

Lors de la conclusion de l’accord, les acteurs financiers doivent pour assurer leur conformité au règlement DORA :

• S’assurer que le contrat peut être résilié en cas d’infraction de dispositions législatives, de changement qui pourraient altérer l’exécution des fonctions visées, de faiblesses dans la gestion des risques TIC du prestataire, ou d’incapacité de l’autorité compétente à surveiller efficacement l’acteur financier à cause du contrat
• Prévoir une stratégie de sortie dans le cadre des fonctions importantes/critiques, sans perturber les activités/restreindre le respect des exigences/interrompre le service
• S’assurer que les services critiques/importants doivent être gérés par des prestataires différents et non liés pour éviter une trop forte concentration
• Inclure un certain nombre de clauses, précisées dans l’article 30 du règlement

Conclusion

En conclusion, le règlement DORA est un geste fort de l’Europe pour instaurer une ligne de défense autour de son périmètre financier, par l’augmentation de la résilience des acteurs (gestion du risque TIC, gestion des incidents et tests de résilience), de leur écosystème proche (gestion du risque lié aux prestataires de services) et par le partage de ces données entre acteurs (non traité ici).

Même si le processus de mise en conformité va demander des efforts importants pour certains acteurs, le règlement DORA donne un cadre assez clair qui permet de décliner les mesures à prendre par chaque entité financière sur la partie gouvernance et sécurité opérationnelle, en gardant en tête le principe de proportionnalité pour les petits acteurs.

P.S. : Comme précisé au début de cet article, le contenu présenté ici n’est qu’un résumé. Pour vous assurer que la mise en conformité DORA soit la plus bénéfique et pragmatique pour votre entreprise, n’hésitez pas à aller lire le règlement et/ou à vous faire accompagner d’une entreprise spécialisée.