Tech Guru Tarek

Digital Operational Resilience Act

Je risque d’avoir des problèmes de copyright.

Table des matières

Pourquoi une nouvelle couche réglementaire ?

Avant de me plonger dans DORA, je pensais naïvement que le secteur financier avait déjà suffisamment de règles pour occuper tout un service conformité jusqu’à la retraite. Entre Bâle, MiFID, Solvabilité et tout le reste, ça me semblait complet. Mais non. Il manquait un truc. Et l’Union européenne a fini par lui donner un nom : Acte de résilience opérationnelle digitale.

AROD (ou DORA pour les non déviants) s’inscrit dans ce qu’on appelle aujourd’hui le Digital Finance Package, qui est en réalité un bloc législatif qui a vu le jour en 2020. C’est l’équivalent d’une boîte à outils réglementaire de l’Europe pour faire face à la digitalisation rapide du monde financier. Dedans, on retrouve trois instruments bien distincts :

  • MiCA, pour encadrer les crypto-actifs et éviter que le prochain stablecoin maison ne fasse sauter une banque.
  • Le Pilot Regime, une sorte de bac à sable réglementaire pour tester la tokenisation des titres financiers.
  • Et DORA, le sujet qui nous intéresse ici, qui s’attaque à la capacité des institutions financières à survivre à un incident technologique. (Dit comme ça, on se rend compte que c’était peut-être pas du luxe.)

Pourquoi un nouveau texte ? Parce que les règles existantes ne parlaient pas vraiment de ce qui se passe quand un serveur plante, qu’un ransomware bloque tout ou qu’un prestataire cloud décide de faire une mise à jour alors que le marché viens d’ouvrir et qu’on joue des millions sur quelques millisecondes. Or aujourd’hui, ces “petits incidents techniques” peuvent se transformer en gros chaos, et ça, aucun ratio de solvabilité ne pourra le compenser.

L’Union Européenne part d’un constat assez simple, que je trouve assez difficile à contester : la finance est désormais totalement dépendante du numérique. Et cette dépendance reprend les trois Grands Risques bien connues :

  1. Le risque financier, le classique : pertes, marchés volatils, défauts de paiement.
  2. Le risque opérationnel, souvent sous-estimé : erreur humaine, faille de sécurité, panne imprévue.
  3. Et le plus insidieux des trois, le risque systémique : celui qui fait tomber une boîte, puis une autre, puis une autre, puis tout un pan du système.

Ce dernier est le cauchemar des régulateurs. Et avec la place grandissante des technologies dans tous les pans de la chaîne de valeur financière, ce risque vire clairement vers le Digital.

La réponse de l’UE a été assez pragmatique : plutôt que de refaire une énième régulation monolithique, elle a choisi une approche modulaire. Chacun des textes du Digital Finance Package cible un angle spécifique. MiCA s’occupe de l’innovation un peu sauvage des crypto-actifs, le Pilot Regime donne de l’oxygène réglementaire à l’expérimentation (vive la BlockChain et les Smart Contracts), et DORA vient serrer les risques du numérique pour éviter que tout s’effondre au premier impact.

Personnellement, je trouve cette approche plutôt saine. On ne mélange pas tout, on n’improvise pas trop, et surtout, on reconnaît qu’un bug logiciel peut avoir autant d’impact systémique qu’une mauvaise gestion financière (2008, 2001, les tulipes hollandaises, etc.).

NB : je ne m’y connais pas du tout en finance, mes exemples sont très discutables. Ce blog traite de cybersécurité. Le jour où je m’y connaîtrais en finance, j’ouvrirais Tarekonomics.fr mais d’ici là contentez vous de ça.

Mélange étrange entre réglementation et directive

Quand j’ai commencé à m’intéresser à DORA, j’ai découvert qu’il repose à la fois sur une réglementation et une directive. Sur le moment, je me suis dit : « Super, encore des bureaucrates créatifs. »

Mais en y regardant de plus près, cette structure a une certaine logique.

La réglementation DORA (UE) 2022/2554 : le cœur du dispositif

La réglementation DORA établit un cadre harmonisé pour renforcer la résilience opérationnelle numérique des entités financières. Elle s’articule autour de cinq piliers principaux :

  1. Gestion des risques liés aux TIC : Mise en place d’un cadre de gestion des risques informatiques complet, incluant l’identification, la prévention, la détection, la réponse et la reprise après incident.
  2. La gestion, classification et notification des incidents liés aux TIC : Obligation de signaler les incidents majeurs aux autorités compétentes dans des délais stricts, avec des critères de classification clairs.
  3. Tests de résilience opérationnelle numérique : Réalisation régulière de tests, y compris des tests de pénétration avancés pour certaines entités, afin d’évaluer la robustesse des systèmes.
  4. Gestion des risques liés aux tiers prestataires de services TIC : Évaluation rigoureuse des fournisseurs critiques, avec des exigences contractuelles spécifiques et des droits d’audit.
  5. Partage d’informations sur les cybermenaces : Encouragement à l’échange d’informations entre entités financières pour renforcer la cybersécurité collective.

Cette réglementation est directement applicable dans tous les États membres depuis le 17 janvier 2025, sans nécessiter de transposition nationale.

La directive DORA (UE) 2022/2556 : l’alignement des législations sectorielles

Parallèlement, la directive DORA modifie plusieurs directives sectorielles existantes (Bâle III, CRD IV, CRR, PSD2, BRRD, Solvabilité II, IORP II, MiFID II, AIFM) pour les aligner avec les exigences de la réglementation DORA. Elle vise à assurer une cohérence entre les différentes législations encadrant les entités financières, en intégrant les principes de résilience opérationnelle numérique dans chaque secteur.

Contrairement à la réglementation, la directive nécessite une transposition dans le droit national de chaque État membre. Les États avaient jusqu’au 17 janvier 2025 pour effectuer cette transposition.

Les directives ciblées par la directive DORA (UE) 2022/2556

  1. Bâle III
    Bâle III (bientôt IV) est un cadre international de renforcement des exigences de fonds propres, de liquidité et de levier des banques, transposé en UE via la directive CRD IV et le règlement CRR. La directive DORA (UE 2022/2556) vient compléter cet arsenal prudentiel en y intégrant une dimension de résilience opérationnelle numérique : elle impose aux établissements assujettis à Bâle III d’identifier et de gérer les risques liés aux technologies de l’information et de la communication (TIC), de mettre en place des plans de continuité, de réaliser des tests de résilience et de reporter tout incident majeur affectant leurs services critiques.
  2. CRD IV (Directive 2013/36/EU)
    La CRD IV fixe les règles d’agrément, de gouvernance et de gestion des risques pour les établissements de crédit et les entreprises d’investissement. DORA (UE 2022/2556) modifie la CRD IV pour y adjoindre explicitement des obligations de gestion des risques TIC, d’organisation interne (comité TIC, fonctions de contrôle dédiées), de tests de résistance opérationnelle et de notification systématique des incidents numériques graves.
  3. CRR (Règlement UE 575/2013)
    Le CRR est le pendant réglementaire et directement applicable en UE de Bâle III, précisant les modalités de calcul des ratios prudentiels. Si DORA n’amende pas formellement le CRR, son propre règlement (UE 2022/2554 pas la directive 2556 cette fois-ci) s’applique aux entités soumises au CRR en exigeant l’intégration du risque TIC dans l’évaluation prudentielle (SREP) et dans la gestion opérationnelle journalière, assurant ainsi que la résilience digitale soit traitée au même rang que les risques financiers.
  4. PSD2 (Directive EU 2015/2366)
    PSD2 modernise le cadre des services de paiement, en ouvrant notamment l’accès aux comptes bancaires via des API et en renforçant la sécurité des transactions. DORA étend ces principes de sécurité aux prestataires de services de paiement en y ajoutant des exigences de gouvernance TIC, de classification et de rapport d’incidents majeurs, ainsi que des obligations de tests de résilience opérationnelle similaires à ceux imposés aux banques.
  5. BRRD (Directive 2014/59/EU)
    La BRRD établit les mécanismes de prévention, de redressement et de résolution des banques et des entreprises d’investissement en difficulté. DORA vient enrichir la BRRD en exigeant que les plans de redressement et de résolution intègrent la continuité des fonctions critiques face aux cyber-incidents, garantissant qu’un choc numérique puisse être traité aussi sérieusement qu’une détérioration financière.
  6. Solvabilité II (Directive 2009/138/EC)
    Solvabilité II définit le régime prudentiel des assureurs, avec trois piliers portant sur les exigences quantitatives, la gouvernance et la transparence. DORA impose aux compagnies d’assurance d’englober les risques TIC dans leur système de gouvernance et leurs processus de gestion des risques, de soumettre ces risques à des tests de continuité et de reporter tout incident impactant la fourniture de leurs garanties.
  7. IORP II (Directive EU 2016/2341)
    IORP II encadre les institutions de retraite professionnelle, en renforçant leurs exigences de gouvernance et de gestion des risques pour protéger les droits à pension. DORA introduit dans IORP II des obligations de gestion des risques liés aux technologies, de notification des incidents significatifs et de réalisation de tests de résilience adaptés aux spécificités des régimes de retraite professionnelle.
  8. MiFID II (Directive 2014/65/EU)
    MiFID II régule les marchés d’instruments financiers, la conduite des entreprises d’investissement et la protection des investisseurs via des obligations de transparence et de reporting. DORA étend MiFID II en y ajoutant des prescriptions de gestion opérationnelle des risques TIC, en imposant des scénarios de tests de résilience pour les plateformes de négociation et en instituant un reporting d’incidents numériques majeurs.
  9. AIFM (Directive 2011/61/EU)
    La directive AIFM régit les gestionnaires de fonds d’investissement alternatifs (fonds de private equity, hedge funds, fonds immobiliers, etc.), en fixant des normes de gouvernance, de transparence et de reporting. DORA vient compléter l’AIFM en y insérant des exigences de gouvernance TIC, de classification et de déclaration des incidents majeurs, ainsi que des obligations régulières de tests de résilience opérationnelle pour garantir la continuité des services de gestion de fonds.

État d’avancement en France au 24 avril 2025

En France, la transposition de la directive DORA n’a pas été finalisée dans les délais impartis. Le 27 mars 2025, la Commission européenne a adressé une lettre de mise en demeure à la France, ainsi qu’à douze autres États membres, pour non-transposition complète de la directive. Ces pays disposent de deux mois pour répondre et finaliser la transposition, faute de quoi la Commission pourrait émettre un avis motivé, étape suivante de la procédure d’infraction.

Un projet de loi visant à transposer la directive DORA, ainsi que les directives NIS 2 et CER, a été introduit au Sénat en mars 2025. Ce projet est actuellement en cours d’examen par l’Assemblée nationale.

Brefff

La réglementation DORA impose des obligations directement applicables aux entités financières depuis janvier 2025, tandis que la directive DORA vise à harmoniser les législations sectorielles en intégrant les principes de résilience opérationnelle numérique. En France, bien que la réglementation soit en vigueur, la transposition de la directive est en cours, créant une situation où les entités doivent se conformer à un cadre juridique encore inexistant.

Champ d’application

21 types d’entités identifiées :

  1. Les établissements de crédit (banques)
  2. Les établissements de paiement
  3. Les prestataires de services d’information sur les comptes
  4. Les établissements de monnaie électronique
  5. Les entreprises d’investissement
  6. Les prestataires de services sur crypto-actifs (relevant du règlement MiCA)
  7. Les dépositaires centraux de titres (CSD)
  8. Les contreparties centrales (CCP)
  9. Les plates-formes de négociation (marchés réglementés, MTF, OTF)
  10. Les référentiels centraux
  11. Les gestionnaires de fonds d’investissement alternatifs (AIFM)
  12. Les sociétés de gestion (UCITS)
  13. Les prestataires de services de communication de données (DRSP)
  14. Les entreprises d’assurance et de réassurance
  15. Les intermédiaires d’assurance, de réassurance et auxiliaires
  16. Les institutions de retraite professionnelle (IORP)
  17. Les agences de notation de crédit
  18. Les administrateurs d’indices de référence critiques
  19. Les prestataires de services de financement participatif (Crowdfunding)
  20. Les référentiels des titrisations
  21. Les prestataires tiers de services TIC

Remarque : Vous remarquerez que le règlement s’applique également aux prestataires tiers de services TIC qui fournissent des services aux entités financières susmentionnées. Un régime de surveillance spécifique est prévu pour les prestataires tiers de services TIC jugés critiques pour le secteur financier européen.

ITS et RTS ?

Les ITS (normes techniques de mise en œuvre) et les RTS (normes techniques réglementaires) sont des documents techniques déclarés dans le règlement (2554, avant les premiers articles) et qui ont été publiés par les autorités européennes de supervision : l’EBA (Autorité Bancaire Européenne), l’ESMA (Autorité Européenne des Marchés Financiers) et l’EIOPA (Autorité Européenne des Assurances et Pensions Professionnelles).

Leur mission : Traduire les principes généraux de DORA en consignes ultra-précises et applicables directement sur le terrain, donc : traduire DORA en exigences (RTS) et en contrôle opérationnels (ITS).

De ce que j’ai pu comprendre, un premier lot a été publié avec l’entrée en vigueur de DORA en janvier 2024 et un second lot en juin 2024.

Pourquoi ces détails techniques ne sont-ils pas directement dans le texte initial de DORA ? À mon humble avis, c’est une façon intelligente pour le législateur de garder de la souplesse : les RTS et ITS peuvent évoluer rapidement, être mises à jour régulièrement en fonction des évolutions technologiques et des retours d’expérience. Si tout était figé dès le départ, la réglementation serait probablement dépassée avant même d’être en vigueur.

En pratique, les RTS et ITS sont donc bien plus que de simples annexes techniques : elles deviennent des feuilles de route opérationnelle. C’est là qu’on ira chercher nos checklists concrètes, nos procédures de gestion des incidents et nos critères pour auditer nos prestataires. Autrement dit, c’est le cœur battant de notre conformité à DORA.

Un autre article spécifiquement dédié aux ITS et RTS sera publié sur mon blog dans les prochaines semaines, il y a énormément à dire là dessus.

Les fameux 5 piliers de DORA expliqués concrètement

Le Règlement DORA (donc le 2022/2554), repose sur cinq piliers fondamentaux visant à renforcer la résilience opérationnelle numérique des entités financières.

Ces piliers, qui sont littéralement les 5 chapitres de la règlementation qui concerne les acteurs financiers, sont détaillés dans les articles correspondants, voici pour chaque article son titre et une petite phrase détaillant son contenu.

Attention, c’est SUPER long, vous pouvez vous amuser à tout lire mais l’idée était surtout de proposer un guide qui sert d’aide à la lecture pour la réglementation si vous aviez besoin de quelque chose de spécifique.

Exemple : Je suis une petite structure, de quoi suis-je exonéré ? Bah en lisant ça, je verrais que je rentre peut-être dans les clous de l’article 16 et de là j’irai lire l’article en question pour vérifier.

1. Gestion du risque lié aux TIC (Articles 5 à 16)

Article 5 – Gouvernance et organisation :
Les entités financières doivent mettre en place une gouvernance et un contrôle interne robustes pour gérer les risques TIC. L’organe de direction est responsable de l’approbation, de la supervision et de la surveillance des stratégies de résilience numérique. Le budget, la gestion des prestataires externes, et la formation du personnel doivent être assurés pour maintenir un haut niveau de sécurité TIC.

Article 6 – Cadre de gestion du risque lié aux TIC :
Les entités doivent disposer d’un cadre solide de gestion du risque TIC intégré à leur système global de gestion des risques. Ce cadre comprend stratégies, politiques, procédures et outils pour protéger les actifs informationnels et physiques. Il doit être mis à jour annuellement ou après un incident majeur, et être soumis à des audits réguliers.

Article 7 – Systèmes, protocoles et outils de TIC :
Les systèmes de TIC doivent être fiables, adaptés à la taille des opérations, capables de traiter les données en toute sécurité et de résister à des pics d’activité. Les entités doivent maintenir une capacité suffisante pour traiter les données sans interruption, même en cas de crise. Ces systèmes doivent aussi garantir l’intégrité, l’authenticité et la confidentialité des données.

Article 8 – Identification :
Les entités doivent identifier, classer et documenter tous les rôles et fonctions liés aux TIC ainsi que leurs dépendances. Un inventaire de tous les actifs TIC critiques doit être tenu et mis à jour régulièrement. Elles doivent aussi évaluer les risques à chaque modification majeure des infrastructures.

Article 9 – Protection et prévention :
Pour minimiser les risques, les entités doivent assurer une protection constante des systèmes TIC à travers des politiques de sécurité rigoureuses. Cela comprend la gestion des accès, des mises à jour, l’authentification forte, et des mesures pour prévenir la perte de données. L’infrastructure réseau doit être conçue pour isoler rapidement les actifs en cas d’attaque.

Article 10 – Détection :
Des mécanismes doivent être mis en place pour détecter rapidement toute activité anormale ou incident lié aux TIC. Cela comprend des seuils d’alerte, la surveillance des utilisateurs et la capacité de repérer les points de défaillance critique. Ces systèmes de détection doivent être régulièrement testés pour garantir leur efficacité.

Article 11 – Réponse et rétablissement :
Les entités doivent élaborer une politique de continuité d’activités TIC et des plans de réponse adaptés aux incidents. Ces plans doivent assurer la reprise rapide des fonctions critiques, intégrer une analyse des impacts, et inclure des communications de crise. Des tests réguliers et des audits doivent garantir leur efficacité.

Article 12 – Politiques et procédures de sauvegarde, procédures et méthodes de restauration et de rétablissement:
Les entités doivent documenter des politiques de sauvegarde des données et de restauration des systèmes pour limiter l’impact des interruptions. Des systèmes de sauvegarde sécurisés doivent être mis en place et testés régulièrement. En cas de restauration, l’intégrité et la confidentialité des données doivent être garanties.

Article 13 – Apprentissage et évolution :
Les entités doivent collecter et analyser les informations sur les cybermenaces et incidents pour améliorer leur résilience numérique. Elles doivent réaliser des examens post-incidents pour tirer des leçons et améliorer leur sécurité. La formation continue du personnel et le suivi des évolutions technologiques sont également exigés.

Article 14 – Communication :
Les entités doivent élaborer des plans de communication pour gérer l’information en cas d’incident majeur lié aux TIC. Il faut informer sans délai les clients et contreparties concernés. Une personne spécifique est désignée pour gérer la communication avec le public et les médias.

Article 15 – Harmonisation accrue des outils, méthodes, processus et politiques de gestion du risque lié aux TIC :
Les autorités de surveillance élaborent des normes techniques communes pour détailler les politiques de sécurité TIC, les mécanismes d’accès, les procédures de détection des incidents, et les plans de continuité. L’objectif est d’assurer une application cohérente des exigences de résilience opérationnelle numérique à l’échelle de l’Union.

Article 16 – Cadre simplifié de gestion du risque lié aux TIC :
Certaines petites entités bénéficient d’un cadre simplifié, mais doivent néanmoins maintenir une gestion solide du risque TIC. Elles doivent surveiller la sécurité de leurs systèmes, assurer la continuité de leurs fonctions critiques, tester régulièrement leurs mesures de sécurité, et adapter leurs plans aux incidents.

2. Gestion, classification et notification des incidents liés aux TIC (Articles 17 à 23)

Article 17 – Processus de gestion des incidents liés aux TIC :
Les entités financières doivent définir, établir et mettre en œuvre un processus clair pour détecter, gérer et notifier les incidents liés aux TIC. Ce processus inclut l’enregistrement systématique des incidents et la mise en place d’indicateurs d’alerte précoce. Il organise aussi les rôles, responsabilités et plans de communication internes et externes lors d’incidents.

Article 18 – Classification des incidents liés aux TIC et des cybermenaces :
Les incidents et cybermenaces doivent être classés selon leur impact, en tenant compte du nombre d’utilisateurs affectés, de la durée, des pertes de données, de l’impact géographique et financier. Cette classification sert à prioriser la réponse aux incidents. Les critères sont harmonisés pour garantir une gestion cohérente à l’échelle européenne.

Article 19 – Déclaration des incidents majeurs liés aux TIC et notification volontaire des cybermenaces importantes :
Les entités financières doivent notifier aux autorités compétentes tout incident majeur lié aux TIC, via des notifications initiales, des rapports intermédiaires et finaux. Elles peuvent aussi signaler volontairement des cybermenaces importantes. Les informations sont transmises aux différentes autorités européennes et nationales pour une réaction coordonnée.

Article 20 – Harmonisation du contenu et des modèles des rapports de notification :
Les autorités européennes élaborent des normes techniques pour uniformiser le contenu des notifications d’incidents majeurs liés aux TIC. Cela inclut des modèles de rapport et des délais standardisés pour les notifications initiales, intermédiaires et finales. L’objectif est d’assurer une communication efficace et harmonisée entre tous les acteurs concernés.

Article 21 – Centralisation des notifications d’incidents majeurs liés aux TIC :
Une étude sera menée pour évaluer la création d’une plateforme européenne unique de notification des incidents TIC. Cette plateforme vise à simplifier et centraliser les notifications pour améliorer l’efficacité de la surveillance et la convergence des pratiques au sein de l’UE. Le rapport d’évaluation est attendu pour janvier 2025.

Article 22 – Retour d’information en matière de surveillance :
Après chaque notification d’incident, les autorités compétentes fournissent un retour d’information aux entités financières pour améliorer leur gestion des incidents. Ce retour peut inclure des conseils ou des informations sur des menaces similaires. Un rapport annuel agrégé sur les incidents est également publié pour soutenir l’analyse des risques sectoriels.

Article 23 – Incidents opérationnels ou de sécurité liés au paiement concernant les établissements de crédit, les établissements de paiement, les prestataires de services d’information sur les comptes et les établissements de monnaie électronique (c’est super long comme titre…) :
Les obligations de gestion, de classification et de notification des incidents TIC s’appliquent aussi aux incidents opérationnels ou de sécurité dans les établissements de crédit, de paiement, les prestataires d’information sur les comptes et les établissements de monnaie électronique. Cela garantit une approche cohérente pour tous les services financiers critiques.

3. Tests de résilience opérationnelle numérique (Articles 24 à 27)

Article 24 – Exigences générales applicables à la réalisation de tests de résilience opérationnelle numérique :
Les entités financières (sauf microentreprises) doivent établir un programme complet de tests pour évaluer leur préparation face aux incidents TIC. Ce programme comprend divers tests réguliers adaptés aux risques identifiés et garantit que les faiblesses découvertes soient corrigées rapidement. Les tests doivent être réalisés de manière indépendante et couvrir annuellement les fonctions critiques ou importantes.

Article 25 – Test des outils et systèmes de TIC :
Les entités financières doivent réaliser des tests spécifiques tels que les analyses de vulnérabilité, de sécurité réseau, de compatibilité et de performance pour leurs systèmes TIC. Ces tests visent à identifier les failles avant toute mise en production. Une approche basée sur les risques est adoptée, avec des méthodes variées incluant des audits physiques et logiciels.

Article 26 – Tests avancés d’outils, de systèmes et de processus de TIC sur la base de tests de pénétration fondés sur la menace :
Certaines entités (liste confidentielle et définie par les autorités) doivent, au moins tous les trois ans, réaliser un test de pénétration fondé sur la menace pour vérifier la robustesse de leurs systèmes critiques en environnement réel. Ces tests peuvent inclure les prestataires de services TIC et doivent être validés par l’autorité compétente. Après les tests, un rapport et des plans correctifs sont exigés pour assurer la reconnaissance mutuelle au sein de l’UE.

Article 27 – Exigences applicables aux testeurs afin de réaliser des tests de pénétration fondés sur la menace :
Les testeurs externes doivent répondre à des critères stricts d’indépendance, de compétence, de confidentialité et de sécurité. Ils doivent être certifiés, respecter la confidentialité des données, et s’assurer de la non divulgation d’informations sensibles. Leur sélection est rigoureusement encadrée pour garantir la fiabilité des tests réalisés.

4. Gestion des risques liés aux prestataires tiers de services TIC (Articles 28 à 44)

Article 28 – Principes généraux :
Les entités financières doivent gérer les risques liés aux prestataires tiers de services TIC comme faisant partie intégrante de leur cadre global de gestion du risque TIC. Elles restent pleinement responsables du respect de leurs obligations réglementaires, même en cas d’externalisation de services. La gestion des risques doit être proportionnée à la nature, l’ampleur, la complexité et l’importance des services externalisés. Les entités doivent également prévoir des stratégies de sortie et des plans de transition pour limiter tout impact négatif en cas de défaillance du prestataire​.

Article 29 – Évaluation préliminaire du risque de concentration de TIC au niveau de l’entité :
Avant de conclure un contrat important pour des services TIC, les entités financières doivent évaluer les risques de concentration. Elles doivent vérifier si le prestataire est difficilement substituable ou s’il existe une dépendance excessive à un même fournisseur. Cette analyse vise à éviter une exposition critique à des risques systémiques.

Article 30 – Principales dispositions contractuelles :
Les contrats avec les prestataires TIC doivent être clairs, complets et écrits dans un format durable. Ils doivent spécifier les services fournis, les localisations de traitement des données, les niveaux de service, et les obligations de sécurité. Des clauses spécifiques concernant la coopération avec les autorités de supervision et la restitution des données doivent être incluses.

Article 31 – Désignation des prestataires tiers critiques de services TIC :
Certains prestataires sont désignés critiques s’ils soutiennent des fonctions importantes du secteur financier européen. Cette désignation implique des obligations spécifiques de supervision renforcée. Les prestataires désignés doivent établir une filiale dans l’UE s’ils sont situés hors Union.

Article 32 – Structure du cadre de supervision :
Un forum de supervision est institué pour coordonner les activités de contrôle sur les prestataires critiques TIC. Ce forum facilite l’échange d’informations et promeut des approches cohérentes au sein de l’UE. Il évalue également chaque année les risques et propose des mesures d’amélioration.

Article 33 – Tâches du superviseur principal :
Le superviseur principal est chargé d’évaluer les dispositifs de gestion du risque TIC des prestataires tiers critiques. Il vérifie notamment la sécurité, la continuité et la résilience des services fournis. Il peut aussi recommander des mesures correctives si nécessaire.

Article 34 – Coordination opérationnelle entre superviseurs principaux :
Les superviseurs principaux doivent collaborer via un réseau commun pour harmoniser leur approche. Ce réseau élabore un protocole commun de supervision, partage les meilleures pratiques, et coordonne les inspections et évaluations.

Article 35 – Pouvoirs du superviseur principal :
Le superviseur dispose de pouvoirs étendus : demande d’informations, inspections générales, audits, et formulation de recommandations. Il peut imposer des mesures spécifiques pour renforcer la sécurité TIC et réduire les risques de concentration.

Article 36 – Exercice des pouvoirs du superviseur principal en dehors de l’Union :
Le superviseur peut exercer ses pouvoirs sur des sites situés dans des pays tiers si cela est nécessaire pour superviser correctement les prestataires critiques. Ce contrôle reste soumis à l’accord du prestataire et à la coopération des autorités locales.

Article 37 – Demande d’informations :
Le superviseur peut exiger toute information utile à l’évaluation du risque, y compris accès aux systèmes, données, audits internes et contrats. Les prestataires doivent coopérer pleinement et transmettre les informations dans des délais définis.

Article 38 – Enquêtes générales :
Le superviseur peut mener des enquêtes générales sur les prestataires tiers critiques pour évaluer leur conformité aux obligations de DORA. Ces enquêtes portent sur tous les aspects de la gestion des risques TIC et de la sécurité opérationnelle.

Article 39 – Inspections :
Les superviseurs peuvent réaliser des inspections physiques sur les sites des prestataires critiques, en Europe ou ailleurs, pour vérifier directement les dispositifs de sécurité et de résilience. Ces inspections peuvent être annoncées ou inopinées.

Article 40 – Supervision continue :
Un suivi permanent est exercé par une équipe d’examen conjoint, composée d’experts des autorités de supervision et coordonnée par le superviseur principal. Cette équipe valide les mesures correctives prises après inspections ou incidents.

Article 41 – Harmonisation des conditions permettant l’exercice des activités de supervision :
Des normes techniques communes sont élaborées pour uniformiser les informations transmises par les prestataires critiques et les modalités de supervision. L’objectif est d’assurer une approche coordonnée et transparente dans toute l’UE.

Article 42 – Suivi par les autorités compétentes :
Les prestataires doivent notifier s’ils acceptent ou rejettent les recommandations du superviseur. En cas de refus injustifié, cette décision peut être rendue publique pour informer le marché et les entités financières concernées.

Article 43 – Redevances de supervision :
Le superviseur principal perçoit des redevances auprès des prestataires tiers critiques de services TIC pour couvrir l’intégralité des dépenses liées à leurs tâches de supervision. Ces redevances englobent aussi les coûts des travaux réalisés par l’équipe d’examen conjoint et des conseils d’experts indépendants. Le montant des redevances est proportionnel au chiffre d’affaires du prestataire et sera précisé par un acte délégué de la Commission européenne attendu pour le 17 juillet 2024.

Article 44 – Coopération internationale :
Les autorités européennes (ABE, AEMF, AEAPP) peuvent conclure des accords administratifs avec les autorités de pays tiers pour améliorer la coopération sur la gestion des risques liés aux prestataires TIC. Cette collaboration vise à partager de bonnes pratiques, examiner les dispositifs de sécurité, et harmoniser les réponses aux incidents. Tous les cinq ans, un rapport confidentiel est remis aux institutions européennes pour analyser l’évolution de ces risques et leur impact sur la stabilité financière et le marché intérieur.

5. Dispositifs de partage d’informations (Article 45)

Article 45 – Dispositifs de partage d’informations et de renseignements sur les cybermenaces :
Les entités financières peuvent partager entre elles des informations et des renseignements sur les cybermenaces, tels que des indicateurs de compromission, des tactiques, techniques, procédures, alertes de cybersécurité et outils de configuration. Ce partage doit viser à améliorer la résilience numérique, limiter la propagation des menaces et soutenir la détection et la réponse aux incidents. Il doit se faire dans des communautés de confiance, dans le respect de la confidentialité, de la protection des données et de la concurrence. Les entités doivent notifier aux autorités compétentes leur participation à ces dispositifs de partage​

L’écosystème bancaire : pourquoi DORA SE DOIT de changer selon les acteurs

DORA identifie 21 types d’entités cible pour l’application de cette réglementation (voir le chapitre I, article 2.1). Il serait donc complétement fou de s’attendre à un même niveau de rigueur pour une caisse de retraite délaissée que pour nos amis traders qui jouent avec l’économie 🙂

Heureusement, ce n’est pas le cas, le chapitre I, article 4 détaille le principe de proportionnalité (il est court, je vais directement le mettre ici) :

1.   Les entités financières mettent en œuvre les règles énoncées au chapitre II conformément au principe de proportionnalité, en tenant compte de leur taille et de leur profil de risque global ainsi que de la nature, de l’ampleur et de la complexité de leurs services, activités et opérations.

2.   En outre, l’application par les entités financières des chapitres III et IV et du chapitre V, section I, est proportionnée à leur taille et à leur profil de risque global, ainsi qu’à la nature, à l’ampleur et à la complexité de leurs services, activités et opérations, comme le prévoient expressément les règles pertinentes desdits chapitres.

3.   Les autorités compétentes tiennent compte de l’application du principe de proportionnalité par les entités financières lorsqu’elles examinent la cohérence du cadre de gestion du risque lié aux TIC sur la base des rapports présentés à la demande des autorités compétentes conformément à l’article 6, paragraphe 5, et à l’article 16, paragraphe 2.

Banques de détail, banques d’investissement, banques publiques : des réalités SSI très différentes

La banque de détail (celle de monsieur tout-le-monde) est avant tout une banque de flux, avec des enjeux énormes en matière :

  • De confidentialité des services (une fuite de données aurait un effet sociétal désastreux avec des familles ou des collègues qui se regarderaient mal),
  • De contrôle d’identité (les triple A) (pensez risque de phishing, virement non désiré),

La banque d’investissement, elle, n’a pas les mêmes besoins : les enjeux sont plus concentrés sur la disponibilité des plateformes de marché et la résilience des infrastructures de marché. Ici, un arrêt de service n’est pas seulement un désagrément : c’est potentiellement des millions d’euros de pertes en quelques secondes (trading quant).

Enfin, les banques publiques (ou parapubliques), souvent plus lentes dans leur transformation numérique, sont confrontées à un problème spécifique : des systèmes vieillissants (ou « systèmes de TIC hérités » selon DORA), souvent plus vulnérables, et une pression croissante pour moderniser sans déstabiliser les services essentiels qu’elles offrent.

DORA ne demande pas la même intensité de tests ou d’audits à tous ces acteurs, mais impose une logique commune : chacun doit connaître, maîtriser et protéger ce qui est critique pour ses propres missions.

Infrastructures de marché : le VRAI risque systémique immédiat

Quand on parle d’Euroclear, d’Euronext, des chambres de compensation ou des dépositaires centraux, on ne parle pas simplement de sociétés financières : on parle d’infrastructures critiques.

Leur rôle est central :

  • Ils garantissent le règlement-livraison des transactions financières,
  • Ils assurent la liquidité des marchés,
  • Ils soutiennent la stabilité de tout l’édifice bancaire et financier européen.

Si l’un de ces acteurs tombait, même quelques minutes, les effets domino seraient catastrophiques, bien au-delà des marchés financiers : impact immédiat sur les banques, les assurances, les entreprises, les épargnants, et donc sur l’économie réelle.

Pour eux, DORA impose :

  • Des tests de résilience beaucoup plus poussés (tests d’adversaire simulé, les fameux TLTP),
  • Des obligations de notification accélérées,
  • Une vigilance extrême sur les prestataires critiques (fournisseurs cloud, infrastructures réseaux).

En clair : zéro tolérance pour les défaillances non maîtrisées.

Prestataires TIC : indirectement sous pression

Enfin, même s’ils ne sont pas directement « financiers », les prestataires de services TIC deviennent des cibles indirectes de DORA.

  • Les hébergeurs cloud,
  • Les opérateurs de datacenter,
  • Les éditeurs SaaS,
  • Les fournisseurs de services de cybersécurité externalisée (SOC, etc.)

Tous sont aujourd’hui engagés par ricochet.

Parce que DORA oblige leurs clients financiers à exiger un niveau de sécurité, de disponibilité et de transparence qu’ils n’avaient pas toujours l’habitude de fournir.

Certaines obligations vont très loin :

  • Droit d’audit obligatoire sur site,
  • Reporting spécifique en cas d’incident affectant un client financier,
  • Clauses de sortie en cas de défaillance,
  • Supervision directe possible par les autorités européennes pour les prestataires critiques (selon les articles 32 à 43 du Règlement DORA).

DORA est donc aussi, en creux, une réglementation de la chaîne d’approvisionnement numérique du secteur financier.

Dernier mot

Félicitations si vous êtes arrivé jusqu’ici ! (l’article fait quand même 6000 mots pour 30 minutes de lecture)

Si vous avez tout lu, vous venez de parcourir un bon morceau de DORA, avec ses exigences, ses subtilités et ses impacts profonds sur le secteur financier européen.

C’est un investissement de temps, certes, mais c’est surtout une porte ouverte sur une nouvelle vision de la résilience numérique.

Mais ne nous arrêtons pas là. Ce qu’on vient de voir, c’est l’architecture générale.

Reste encore à plonger dans les détails les plus techniques, ceux qui transforment les grandes lignes de DORA en exigences concrètes et contrôlables : les fameux RTS et ITS.

Ces standards sont les véritables feuilles de route pour implémenter les exigences réglementaires dans le quotidien d’une organisation.

Et puis, il y a LA question : « Comment attaquer la conformité DORA, dans la pratique ? »
C’est bien beau de comprendre les articles, mais construire un plan d’actions, structurer un audit, former les équipes, choisir les bons outils… c’est un tout autre challenge.

Je vous remercie sincèrement d’avoir pris le temps de lire cet article jusqu’au bout.

Je vous donne rendez-vous dans le prochain article pour démystifier les RTS/ITS et détailler pas à pas les étapes pour réussir votre mise en conformité DORA.

À très bientôt.

Tarek

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.