DORA: expliqué pour ceux qui doivent maintenir les systèmes en service.
Règlement (UE) 2022/2554 relatif à la résilience opérationnelle numérique du secteur financier
Direct answer
Le règlement DORA (Règlement (UE) 2022/2554 relatif à la résilience opérationnelle numérique du secteur financier) est le texte européen qui impose aux entités financières de résister, de réagir et de se remettre des perturbations liées aux technologies de l'information et de la communication (TIC). Applicable depuis le 17 janvier 2025, il couvre cinq domaines : la gestion des risques TIC, le signalement des incidents liés aux TIC, les tests de résilience opérationnelle numérique, le risque TIC lié aux tiers et le partage d'informations. Il s'applique à la plupart des entités financières réglementées dans l'UE et étend la supervision aux prestataires TIC critiques dont elles dépendent. En France, l'AMF et l'ACPR exercent la supervision des entités financières concernées.
Pourquoi DORA existe
Avant DORA, la résilience opérationnelle des services financiers européens relevait d'un patchwork de règles nationales et de lignes directrices sectorielles. DORA remplace cela par un règlement unique, directement applicable, de sorte qu'une banque, un assureur et une entreprise d'investissement sont tenus au même socle pour survivre à une défaillance technologique ou à une cyberattaque. Le changement de perspective est l'élément essentiel : DORA traite la perturbation TIC non comme un problème informatique, mais comme une menace pour la stabilité financière, et rend le conseil d'administration responsable de sa gestion.
Les cinq piliers
DORA s'organise autour de cinq domaines. Lus ensemble, ils décrivent un cycle de vie complet : gouverner le risque, détecter et signaler ce qui dysfonctionne, prouver votre résilience en la testant, maîtriser les tiers dont vous dépendez, et partager ce que vous apprenez.
| Pilier | Ce qu'il exige |
|---|---|
| Gestion des risques TIC | Un cadre documenté, porté par l'organe de direction, couvrant l'identification, la protection, la détection, la réponse et la reprise. |
| Gestion et signalement des incidents TIC | Classifier les incidents par gravité et signaler les incidents majeurs à l'autorité compétente dans les délais fixés. |
| Tests de résilience opérationnelle numérique | Un programme de tests, incluant des tests de pénétration fondés sur les menaces (TLPT) pour les entités significatives. |
| Risque TIC lié aux tiers | Un registre des arrangements contractuels TIC et des clauses contractuelles obligatoires, avec des règles plus strictes pour les fonctions critiques ou importantes. |
| Partage d'informations | Participation facultative à des dispositifs de partage d'informations sur les cybermenaces entre entités financières. |
À qui DORA s'applique
DORA couvre un large éventail d'entités financières établies dans l'UE, et s'étend au-delà d'elles aux prestataires technologiques dont elles dépendent. Le périmètre est volontairement large : pour une entité financière européenne, l'hypothèse prudente est d'être concernée jusqu'à confirmation contraire. En France, cela inclut notamment les établissements de crédit, les sociétés d'assurance, les entreprises d'investissement et les sociétés de gestion d'OPCVM, sous la supervision de l'AMF et de l'ACPR. Un régime de supervision distinct s'applique aux prestataires TIC tiers désignés comme critiques, qui deviennent soumis à une supervision directe par un superviseur principal.
| Catégorie | Exemples |
|---|---|
| Entités financières | Établissements de crédit, établissements de paiement et de monnaie électronique, entreprises d'investissement, assureurs et intermédiaires, prestataires de services sur crypto-actifs, sociétés de gestion d'OPCVM, et plus encore. |
| Prestataires TIC tiers | Plateformes cloud, fournisseurs de logiciels et de données, et autres fournisseurs technologiques, avec un régime de supervision dédié pour ceux désignés comme critiques. |
Le registre des prestataires TIC tiers
DORA impose à chaque entité financière de tenir un registre d'informations sur l'ensemble de ses arrangements contractuels pour l'utilisation de services TIC. Le registre doit être maintenu au niveau de l'entité et, le cas échéant, du groupe, tenu à jour lorsque les arrangements évoluent, et mis à disposition de l'autorité compétente sur demande. En pratique, c'est l'exigence la plus difficile à maintenir fiable, car elle n'est exacte que s'il est lié aux relations fournisseurs qu'il décrit plutôt que maintenu comme un document séparé. Acuna maintient ce registre en direct par rapport à votre inventaire fournisseurs de gestion des risques tiers, ce qui constitue l'alignement le plus étroit entre DORA et la plateforme.
Tests de résilience et TLPT
Chaque entité concernée conduit un programme de tests de résilience opérationnelle numérique dimensionné à son profil de risque. Les entités identifiées comme significatives vont plus loin et réalisent des tests de pénétration fondés sur les menaces (TLPT) au moins tous les trois ans, menés par des testeurs qualifiés sur des systèmes de production en service, en s'appuyant sur le cadre TIBER-EU. Le TLPT représente l'extrémité exigeante de l'obligation de test ; son périmètre est défini et validé avec l'autorité compétente.
Pourquoi le conseil d'administration est en première ligne
DORA précise explicitement que l'organe de direction assume la responsabilité finale de la gestion du risque TIC. Il doit approuver et superviser le cadre de gestion des risques TIC, et ne peut déléguer cette responsabilité. C'est la raison pratique pour laquelle DORA ne peut pas rester confiné à l'équipe sécurité : les personnes qui valident doivent pouvoir constater que le cadre est réel et maintenu, ce qu'un système en fonctionnement fournit mieux qu'un ensemble de documents.
Quand il s'applique
DORA est entré en vigueur en janvier 2023 et s'applique depuis le 17 janvier 2025. Les normes techniques détaillées qui le sous-tendent — les normes techniques réglementaires et d'exécution élaborées par les autorités européennes de supervision — précisent les modalités de domaines tels que la classification des incidents, le registre et les tests. Comme ces normes continuent d'être finalisées et mises à jour, vérifiez le détail actuel de toute exigence technique spécifique par rapport à la dernière norme publiée avant de vous y fier.
EXPLORER
DORA
Le règlement, son périmètre et ce qu'il change pour les entités financières.
Le programme de tests que chaque entité concernée doit conduire.
Le registre d'informations de l'article 28, et comment le maintenir à jour.
Classifier les incidents TIC majeurs et les signaler à votre autorité.
Les tests avancés que les entités significatives doivent réaliser.
Quelles entités financières et prestataires TIC sont concernés.
DORA: questions fréquentes.
Réponses associées
Questions que les praticiens se posent.
DORA est la première fois qu'un régulateur dit explicitement aux acteurs financiers que maintenir les systèmes en service est une responsabilité du conseil d'administration, et non une corvée informatique.
Équipe praticiens Acuna
Le registre d'informations est l'endroit où les programmes DORA se dégradent silencieusement. Il est exact le jour où vous le construisez et erroné la semaine où un contrat change, sauf s'il vit avec les relations fournisseurs qu'il décrit.
Équipe praticiens Acuna
La majeure partie de DORA n'est pas un travail nouveau si vous exécutez déjà ISO 27001 ou NIS2. L'erreur est de le traiter comme un projet séparé plutôt qu'un référentiel de plus sur les mêmes contrôles.
Équipe praticiens Acuna
Comment DORA se rapporte à NIS2 et ISO 27001
DORA ne fonctionne pas en vase clos. Une grande partie de sa substance en matière de gestion des risques TIC recoupe NIS2 et ISO 27001, et ses exigences en matière de tiers font écho aux contrôles fournisseurs des deux référentiels. Pour une entité qui exécute déjà l'un d'eux, la voie efficace consiste à cartographier les contrôles communs une fois et à les réutiliser, plutôt que de monter un programme DORA parallèle. Cette réutilisation justifie de traiter DORA comme un référentiel parmi d'autres sur un socle multi-référentiels, et non comme un projet autonome.