Seulement 6,5% des Entreprises Ont Réussi le Test Blanc DORA de l’ESA

Sommaire

• Un Chiffre qui Devrait Alarmer Tout Directeur des Risques
• Qu’est-ce que DORA, Concrètement
• Les Cinq Piliers de DORA, en Détail
• Le Coût Réel d’un Manquement DORA
• Le Cas Particulier des Tests d’Intrusion Ciblés (TLPT)
• Le Test Blanc 2024 : Ce Qui a Vraiment Été Mesuré
• Les 116 Contrôles Qualité, Décortiqués
• Pourquoi Autant d’Entreprises Ont Échoué
• Le Registre d’Information, Racine du Problème
• Pourquoi 2026 Change Tout
• Qui Est Concerné, Précisément
• Le Calendrier Complet 2025-2026
• Comment Se Préparer Maintenant
• Étude de Cas : une Banque Régionale
• Les Erreurs qui Font Échouer un Programme DORA
• Checklist de Premier Diagnostic
• FAQ
• Regard d’Expert
• Références

Un Chiffre qui Devrait Alarmer Tout Directeur des Risques

En 2024, les autorités européennes de supervision ont organisé un exercice à blanc pour tester la préparation des institutions financières face aux exigences du Digital Operational Resilience Act (DORA). Le résultat a de quoi surprendre jusqu’aux organisations les mieux préparées : seulement 6,5% des entreprises ont réussi l’intégralité des 116 contrôles qualité appliqués à leurs données. Autrement dit, plus de 93% des institutions testées ont présenté au moins une non-conformité sur un exercice qui n’était pourtant qu’une répétition, sans conséquence réglementaire directe.

Ce chiffre mérite d’être pris au sérieux pour une raison simple : DORA n’est plus, en 2026, un texte en phase de tolérance. Le règlement est pleinement applicable depuis le 17 janvier 2025, et 2026 marque le passage à une phase de contrôle actif de la part des autorités compétentes nationales. Les entreprises qui échouaient encore sur ce test blanc en 2024 n’ont plus la même marge de manœuvre aujourd’hui — les mêmes lacunes, si elles persistent, s’exposent désormais à un contrôle réel, pas à un simple exercice pédagogique.

Qu’est-ce que DORA, Concrètement

Le Digital Operational Resilience Act est un règlement européen — pas une directive — qui impose aux institutions financières de démontrer leur capacité à résister, répondre et se rétablir face aux perturbations et menaces liées aux technologies de l’information et de la communication (TIC). Contrairement à une directive qui nécessite une transposition dans le droit national de chaque État membre, un règlement européen s’applique directement et uniformément dans les 27 pays, sans marge d’interprétation nationale sur le fond du texte.

Cette distinction juridique n’est pas un détail technique : elle explique pourquoi DORA a pu entrer en application aussi rapidement et uniformément par rapport à d’autres textes européens récents comme la CSRD ou l’EAA, qui ont connu des calendriers de transposition nationale inégaux. Pour DORA, il n’y a pas d’attente possible d’un pays à l’autre — l’obligation est la même partout, depuis le 17 janvier 2025.

DORA s’applique aux banques, compagnies d’assurance, entreprises d’investissement, établissements de paiement, prestataires de services sur crypto-actifs, et à leurs prestataires informatiques tiers critiques — y compris les entreprises non-européennes dès lors qu’elles opèrent en Europe ou fournissent des services à des clients européens. Cette extension aux prestataires tiers est l’une des innovations majeures du texte, et l’une des plus mal anticipées par les organisations concernées.

Les Cinq Piliers de DORA, en Détail

DORA structure ses exigences autour de cinq piliers qui, ensemble, couvrent l’intégralité du cycle de vie de la résilience opérationnelle numérique. Comprendre ces cinq piliers est indispensable avant d’aborder pourquoi le test blanc de 2024 a révélé autant de lacunes.

Premier pilier, la gouvernance et la gestion des risques TIC. DORA exige explicitement que l’organe de direction de l’entité financière soit responsable de la gestion des risques informatiques — ce n’est plus un sujet délégable entièrement à la DSI. Le conseil d’administration doit approuver le cadre de gestion des risques TIC, en superviser la mise en œuvre, et rendre des comptes en cas de défaillance.

Deuxième pilier, la gestion, classification et notification des incidents. Les entités doivent détecter, classifier et notifier les incidents TIC majeurs selon des délais stricts et des formats standardisés définis par les autorités de supervision. Ce pilier exige des processus internes capables de qualifier rapidement la gravité d’un incident et de produire une notification conforme dans des délais souvent comptés en heures, pas en jours.

Troisième pilier, les tests de résilience opérationnelle numérique. DORA impose des tests réguliers, incluant pour les entités les plus significatives des tests d’intrusion ciblés par la menace (TLPT), une forme de test de pénétration particulièrement exigeante simulant des attaques réalistes sur les systèmes critiques.

Quatrième pilier, la gestion des risques liés aux prestataires TIC tiers. C’est le pilier qui introduit le Registre d’Information, une cartographie exhaustive et structurée de tous les prestataires informatiques tiers et de leurs contrats, avec une attention particulière portée aux prestataires jugés critiques par les autorités.

Cinquième pilier, le partage d’informations sur les menaces. DORA encourage — et dans certains cas structure — le partage d’informations et de renseignements sur les cybermenaces entre entités financières, pour renforcer collectivement la résilience du secteur.

Les cinq piliers de DORA couvrent l’intégralité du cycle de vie de la résilience numérique.

Ces cinq piliers ne fonctionnent pas de manière indépendante. Une entité qui néglige la gouvernance (premier pilier) produira mécaniquement une gestion des incidents plus lente et moins structurée (deuxième pilier), des tests de résilience moins rigoureux (troisième pilier), et un Registre d’Information moins fiable (quatrième pilier) — ce qui explique en grande partie pourquoi le taux d’échec du test blanc de 2024 s’est révélé aussi massif : la faiblesse constatée sur le Registre d’Information n’était souvent que le symptôme visible d’une gouvernance des risques TIC insuffisamment mature en amont.

Il est également utile de noter que DORA introduit une notion de proportionnalité entre ces cinq piliers : toutes les entités ne sont pas soumises au même niveau d’exigence sur chacun d’eux. Les tests d’intrusion ciblés par la menace (TLPT), par exemple, ne concernent que les entités les plus significatives désignées par les autorités compétentes — mais le Registre d’Information, lui, s’applique à la quasi-totalité du périmètre couvert par le règlement, ce qui explique pourquoi le test blanc de 2024 a pu produire un échantillon aussi large et représentatif de la maturité réelle du secteur.

Le Coût Réel d’un Manquement DORA

Les sanctions prévues par DORA varient selon les États membres et la nature de l’entité concernée, mais elles partagent une caractéristique commune : elles ne se limitent jamais à une simple amende administrative. Les autorités compétentes disposent de pouvoirs étendus incluant la possibilité d’exiger des mesures correctives sous astreinte, de suspendre temporairement certaines activités, et dans les cas les plus graves, de retirer un agrément — une sanction existentielle pour une institution financière régulée.

Au-delà des sanctions directes, le coût indirect d’un manquement DORA découvert lors d’un contrôle réel dépasse largement celui d’une remédiation proactive. Une entité qui découvre ses lacunes lors d’une inspection de supervision doit produire un plan de remédiation sous la pression d’un calendrier imposé par le régulateur, avec un niveau de scrutin renforcé sur les cycles suivants — une situation structurellement moins favorable qu’un audit interne mené en amont, à son propre rythme, avec la possibilité de corriger discrètement avant toute soumission officielle.

Le Cas Particulier des Tests d’Intrusion Ciblés (TLPT)

Pour les entités désignées comme significatives par les autorités compétentes, DORA impose des tests d’intrusion ciblés par la menace — communément désignés par leur acronyme anglais TLPT (Threat-Led Penetration Testing). Ces tests se distinguent nettement d’un test de pénétration classique : ils simulent des scénarios d’attaque réalistes construits à partir de renseignements sur les menaces effectivement observées contre le secteur financier, exécutés par des équipes d’attaquants spécialisés et supervisés par un contrôleur indépendant tout au long de l’exercice.

La préparation à un TLPT ne se limite pas à un exercice technique ponctuel. Elle exige une cartographie précise des systèmes critiques concernés, une coordination avec les prestataires TIC tiers potentiellement impliqués dans le périmètre testé, et une gouvernance capable de tirer des enseignements structurés des résultats — pas seulement de corriger les vulnérabilités découvertes de façon isolée. Les entités qui abordent le TLPT comme un simple exercice de conformité, sans intégrer ses résultats dans une démarche d’amélioration continue de leur posture de sécurité, en tirent une valeur significativement moindre que celles qui le traitent comme un véritable outil de pilotage du risque.

Le Test Blanc 2024 : Ce Qui a Vraiment Été Mesuré

L’exercice à blanc conduit par les autorités européennes de supervision (ESA) en 2024 portait spécifiquement sur la qualité et la complétude des données que les entités devraient soumettre dans le cadre du Registre d’Information — l’un des livrables les plus structurants et les plus techniques de DORA. Ce test n’évaluait pas la résilience opérationnelle elle-même, mais la capacité des entités à produire, de manière fiable et cohérente, les données structurées exigées par le règlement.

Ce choix méthodologique est révélateur : les autorités ont anticipé, à juste titre, que la difficulté principale ne serait pas conceptuelle mais opérationnelle — la capacité réelle des systèmes d’information des entités financières à produire une cartographie fiable de leurs prestataires TIC, structurée selon un format standardisé, sans erreurs ni incohérences.

Les 116 Contrôles Qualité, Décortiqués

Les 116 contrôles qualité appliqués lors du test blanc couvrent plusieurs dimensions : la cohérence interne des données soumises (un même prestataire identifié de façon cohérente à travers tous les contrats déclarés), la complétude des champs obligatoires, la conformité aux taxonomies et référentiels définis par les ESA, et la cohérence entre les données déclarées au niveau de l’entité et celles déclarées au niveau du groupe consolidé pour les organisations multi-entités.

Un taux de réussite de 6,5% sur un ensemble de contrôles aussi vaste suggère que la difficulté ne se situe pas sur un point isolé, mais sur la combinaison de multiples exigences simultanées — exactement le type de défi que pose une cartographie de données dispersées dans des systèmes hétérogènes, sans gouvernance centralisée préalable.

Pourquoi Autant d’Entreprises Ont Échoué

Plusieurs causes structurelles expliquent ce taux d’échec massif, et elles se recoupent largement avec les difficultés observées sur d’autres chantiers de conformité data-intensifs comme la CSRD.

Des données de contrats dispersées entre plusieurs fonctions. Les informations nécessaires au Registre d’Information — identité du prestataire, nature du service, criticité, clauses contractuelles de résiliation et de portabilité — vivent typiquement dans des systèmes juridiques, des systèmes d’achat, et des inventaires techniques gérés par des équipes différentes, rarement connectés entre eux.

L’absence de référentiel unique de prestataires. Beaucoup d’organisations, en particulier les groupes multi-entités, découvrent en construisant leur Registre d’Information qu’elles n’ont jamais eu de vue consolidée et fiable de l’ensemble de leurs prestataires TIC à l’échelle du groupe — chaque filiale gérant ses propres contrats sans visibilité centrale.

Une sous-estimation de la complexité de classification de la criticité. Déterminer si un prestataire est « critique » au sens de DORA demande une méthodologie rigoureuse et documentée, pas une appréciation informelle — et beaucoup d’organisations n’avaient tout simplement pas cette méthodologie en place au moment du test.

Un manque de compétence en gouvernance data appliquée à ce périmètre spécifique. Comme pour la CSRD, la complexité réelle de DORA sur ce pilier est une complexité de structuration et de gouvernance des données, pas seulement une complexité juridique ou de sécurité informatique.

Le Registre d’Information, Racine du Problème

Le Registre d’Information mérite une attention particulière car c’est précisément ce livrable qui a été testé, et c’est aussi celui qui structure la relation de l’entité avec l’ensemble de son écosystème de prestataires TIC. Ce registre doit couvrir, pour 2026, l’ensemble des accords contractuels avec des prestataires tiers TIC en vigueur au 31 décembre 2025 — une photographie à une date donnée qui exige une collecte rétrospective si elle n’a pas été anticipée.

Les échéances nationales de soumission de ce registre varient d’un pays à l’autre malgré le caractère de règlement de DORA — une nuance importante : si les EXIGENCES de fond sont harmonisées, les modalités pratiques de soumission (portails, dates limites précises) restent parfois gérées au niveau national. Aux Pays-Bas, l’autorité de supervision (AFM) a fixé une échéance de soumission au 31 mars 2026. Au Luxembourg, le portail de la CSSF a ouvert le 11 février 2026. Au niveau consolidé européen, les ESA ont fixé une échéance au 30 avril 2026.

Pourquoi 2026 Change Tout

Le règlement DORA est en vigueur depuis janvier 2025, mais la période initiale a été marquée par ce que plusieurs experts juridiques qualifient de tolérance implicite — les autorités laissant le temps aux entités de structurer leurs dispositifs sans engager immédiatement des actions coercitives lourdes. Cette période touche à sa fin. Les autorités compétentes nationales, aux côtés des autorités européennes de supervision, mènent désormais des revues de supervision actives, et les actions d’application sont réelles.

Un expert juridique de PwC résume bien ce changement de nature : les conseils d’administration doivent désormais se préparer à une nouvelle cadence d’engagement de supervision centrée sur la résilience opérationnelle, distincte des métriques prudentielles traditionnelles auxquelles les institutions financières sont habituées. Ce n’est plus un sujet IT secondaire dans une réunion de conseil — c’est devenu un sujet de gouvernance à part entière.

Qui Est Concerné, Précisément

DORA s’applique à un périmètre volontairement large : banques, compagnies d’assurance et de réassurance, entreprises d’investissement, établissements de paiement, établissements de monnaie électronique, prestataires de services sur crypto-actifs, gestionnaires de fonds, et bien d’autres catégories d’entités financières régulées. Les exigences sont appliquées de manière proportionnée — les petites entités ne sont pas soumises exactement au même niveau d’exigence que les grandes institutions systémiques — mais la proportionnalité ne signifie pas exemption.

Un point souvent sous-estimé : les prestataires TIC tiers eux-mêmes, y compris ceux basés hors de l’Union européenne, entrent dans le périmètre de supervision dès lors qu’ils sont désignés comme critiques pour le secteur financier européen. De nombreuses entreprises de services informatiques et d’externalisation basées en Inde ou ailleurs, servant des clients financiers européens, doivent désormais elles-mêmes se préparer à des obligations de conformité DORA directes.

Cette extension du périmètre aux prestataires tiers non-européens mérite d’être prise au sérieux par les entreprises de services numériques hors UE, y compris nord-américaines, dont une part significative du chiffre d’affaires provient de clients financiers européens. La désignation comme prestataire critique ne dépend pas de la localisation du siège social, mais de l’importance réelle du service fourni pour la stabilité opérationnelle du secteur financier européen — un critère fonctionnel, pas géographique.

Le Calendrier Complet 2025-2026, Repère par Repère

Suivre les échéances DORA exige de distinguer les obligations de fond, harmonisées au niveau européen, des modalités pratiques de soumission, parfois gérées au niveau national. Le 17 janvier 2025 marque l’entrée en application effective du règlement dans son intégralité — pas une date de début de transition, mais le point à partir duquel les obligations de fond sont pleinement exigibles.

Le 31 décembre 2025 constitue la date de référence pour la photographie des accords contractuels avec les prestataires TIC tiers devant figurer dans le Registre d’Information de 2026 — toute organisation doit donc être en mesure de reconstituer une vue fiable de sa situation contractuelle à cette date précise, même rétrospectivement si la collecte n’a pas été menée en continu.

Le 11 février 2026 correspond à l’ouverture du portail de soumission de la CSSF au Luxembourg, l’un des premiers calendriers nationaux à s’activer concrètement. Le 31 mars 2026 est l’échéance fixée par l’autorité néerlandaise AFM pour la soumission du Registre d’Information. Le 30 avril 2026 constitue l’échéance consolidée fixée par les autorités européennes de supervision elles-mêmes, une date qui sert de référence pour l’ensemble du secteur même lorsque des échéances nationales antérieures existent.

Au-delà de ces échéances documentaires, 2026 voit également s’intensifier les campagnes de tests d’intrusion ciblés par la menace pour les entités désignées comme significatives, ainsi que les premières revues de supervision approfondies portant sur la robustesse réelle des dispositifs de gestion des incidents TIC — deux chantiers qui, contrairement au Registre d’Information, ne se limitent pas à une soumission documentaire ponctuelle mais engagent une démonstration continue de capacité opérationnelle.

Comment Se Préparer Maintenant

Face à ce constat, la priorité immédiate pour toute institution financière n’ayant pas encore validé la robustesse de son Registre d’Information est de conduire un audit interne calqué sur la méthodologie des 116 contrôles qualité utilisés par les ESA — pas d’attendre un contrôle réel pour découvrir les mêmes lacunes que 93% des entités testées en 2024.

Cet audit doit couvrir la cartographie exhaustive des prestataires TIC à l’échelle du groupe consolidé, la vérification de la cohérence des identifiants utilisés pour chaque prestataire à travers tous les contrats déclarés, la validation de la méthodologie de classification de criticité, et un test de complétude des champs obligatoires sur un échantillon représentatif de contrats avant la soumission complète.

Concrètement, cette démarche se structure utilement en quatre phases. La première consiste à nommer un responsable unique du programme DORA au sein de l’organisation, avec un mandat clair couvrant à la fois la gouvernance des risques TIC et la coordination du Registre d’Information — un rôle qui, dans beaucoup d’organisations, n’existe tout simplement pas encore de façon formalisée. La deuxième phase construit l’inventaire exhaustif des prestataires TIC à l’échelle du groupe, en interrogeant systématiquement chaque filiale, chaque fonction achats, et chaque système de gestion contractuelle existant, plutôt que de se fier à une liste supposée déjà complète.

La troisième phase applique la méthodologie de classification de criticité à cet inventaire consolidé, en documentant explicitement les critères retenus pour chaque décision — un prestataire hébergeant des données clients sensibles n’est pas classé de la même manière qu’un prestataire fournissant un outil de gestion des notes de frais, et cette différenciation doit être traçable et justifiable face à un contrôle. La quatrième phase, enfin, met en place le rythme de mise à jour continue du registre, avec un processus déclenché automatiquement à chaque nouveau contrat signé ou résilié, plutôt qu’une reconstruction complète à chaque échéance de soumission.

Étude de Cas : une Banque Régionale Face au Test Blanc

Une banque régionale européenne, comptant environ 1 800 salariés et opérant dans trois pays, participe au test blanc de 2024 avec une confiance initiale raisonnable : l’établissement dispose déjà d’un inventaire de prestataires informatiques tenu par la DSI, mis à jour de façon semi-régulière depuis plusieurs années. Le résultat du test blanc révèle pourtant un taux de réussite de seulement 22% sur les 116 contrôles qualité — nettement supérieur à la moyenne du secteur, mais très loin d’une conformité complète.

Le diagnostic post-test révèle que l’inventaire de la DSI, bien que réel, ne couvrait que les prestataires directement contractualisés par cette fonction — il manquait systématiquement les prestataires engagés directement par les filiales locales, ainsi que plusieurs contrats de sous-traitance en cascade où un prestataire principal désigné faisait lui-même appel à des sous-traitants TIC non identifiés dans le registre initial. Cette lacune, très commune, illustre pourquoi un inventaire piloté par une seule fonction, aussi rigoureuse soit-elle, ne suffit presque jamais à couvrir la réalité complète d’un groupe multi-entités.

La reconstruction d’un registre fiable exige une coordination réelle entre fonctions, pas un simple effort de collecte.

La banque engage alors un programme de six mois combinant une fonction de gouvernance data nouvellement créée, une revue contractuelle systématique associant les équipes juridiques de chaque filiale, et une clarification méthodologique de la classification de criticité validée par le comité des risques. Le registre reconstruit atteint un taux de conformité interne de 94% lors d’un second audit blanc mené en interne avant la soumission réelle de 2026 — un résultat qui n’aurait pas été atteint sans la refonte structurelle de la gouvernance data sous-jacente, pas seulement un effort de collecte supplémentaire.

Les Erreurs qui Font Échouer un Programme DORA

Traiter le Registre d’Information comme un exercice ponctuel de collecte plutôt qu’un chantier de gouvernance data continue. Un registre construit une fois puis jamais mis à jour se périme rapidement à mesure que de nouveaux contrats sont signés et d’anciens résiliés.

Laisser chaque filiale ou fonction gérer sa propre liste de prestataires sans référentiel central. C’est précisément la lacune qui a fait chuter le taux de réussite du test blanc de 2024, et celle observée dans l’étude de cas présentée plus haut.

Sous-estimer la complexité de la méthodologie de classification de criticité des prestataires. Une classification informelle, non documentée, ne résiste pas à l’examen d’un régulateur qui demande de justifier chaque décision de classement.

Découvrir les incohérences de données au moment de la soumission plutôt que lors d’un audit interne préalable. Un audit interne calqué sur les 116 contrôles ESA, mené plusieurs mois avant l’échéance réelle, laisse le temps de corriger sans pression réglementaire directe.

Confier ce chantier à la seule fonction juridique ou à la seule DSI, sans compétence de gouvernance data transverse. Ni l’une ni l’autre de ces fonctions ne couvre seule l’ensemble des compétences nécessaires à la construction d’un registre fiable et durable.

Checklist de Premier Diagnostic

Cette checklist reprend les points de vigilance identifiés tout au long de cet article, à utiliser comme base d’un premier diagnostic interne avant tout audit plus formel.

• Un référentiel central et unique de tous les prestataires TIC du groupe existe-t-il, couvrant chaque filiale sans exception ?
• Une méthodologie documentée de classification de criticité des prestataires est-elle en place et appliquée de façon cohérente ?
• Un audit interne calqué sur les 116 contrôles qualité ESA a-t-il été mené sur un échantillon représentatif de contrats ?
• Les échéances nationales de soumission pertinentes pour chaque pays d’opération sont-elles connues et suivies dans un calendrier partagé ?
• Une fonction de gouvernance data est-elle formellement associée au chantier, aux côtés du juridique et de la DSI ?
• Un processus de mise à jour continue du registre est-il déclenché automatiquement à chaque nouveau contrat ou résiliation ?

FAQ

DORA s’applique-t-il aux entreprises non-financières ?
Non directement, mais les prestataires TIC servant des clients financiers européens peuvent être désignés critiques et se retrouver soumis à des obligations directes, même sans être eux-mêmes une entité financière régulée.

Le test blanc de 2024 a-t-il des conséquences réglementaires directes ?
Non, c’était un exercice pédagogique sans sanction associée — mais les mêmes contrôles s’appliquent désormais lors des soumissions réelles de 2026, où les conséquences d’un échec ne sont plus symboliques.

Combien de temps faut-il pour construire un Registre d’Information fiable ?
Variable selon la dispersion des systèmes existants, mais la construction d’un référentiel central fiable prend généralement plusieurs mois pour un groupe multi-entités, pas quelques semaines.

DORA et NIS2 sont-ils liés ?
Oui — DORA est explicitement considéré comme la loi sectorielle spécifique pour le secteur financier par rapport à la directive NIS2 plus généraliste, ce qui évite une double exigence contradictoire pour les entités financières.

Une entreprise conforme à DORA peut-elle quand même échouer un contrôle futur ?
Oui — la conformité DORA n’est pas un état figé validé une fois pour toutes, elle exige une mise à jour continue du Registre d’Information à mesure que les contrats et prestataires évoluent.

Faut-il un outil logiciel dédié pour gérer le Registre d’Information ?
Pas nécessairement dès le premier cycle — une gouvernance rigoureuse avec des définitions claires et un processus de mise à jour continue peut fonctionner sur des outils existants correctement structurés, à condition que la discipline organisationnelle soit réelle et pas seulement documentée sur le papier.

Une petite structure financière doit-elle s’inquiéter autant qu’une grande banque ?
Le principe de proportionnalité de DORA réduit certaines exigences pour les petites entités, notamment sur les tests d’intrusion ciblés, mais le Registre d’Information reste attendu de la quasi-totalité du périmètre couvert, sans exemption significative liée à la seule taille.

Regard d’Expert

Ayant coordonné des audits de conformité et structuré des dictionnaires de données dans des contextes multi-pays, je reconnais dans ce taux d’échec de 93,5% un schéma que j’observe systématiquement sur ce type de chantier réglementaire : la difficulté n’est presque jamais la compréhension du texte réglementaire lui-même, elle est dans l’absence de gouvernance data préalable capable de produire une donnée fiable, cohérente et auditable à l’échelle d’un groupe entier — un défi organisationnel, bien plus qu’un défi purement technique ou juridique, qui demande une coordination réelle entre fonctions juridiques, achats, DSI et gestion des risques.

Écrit par Steeve Vignissy, consultant senior en transformation digitale chez Notoriti.

👉 Contactez Notoriti pour auditer votre Registre d’Information DORA avant la prochaine échéance.

Références

• Orbiq, DORA Compliance Guide 2026: Requirements & Deadlines, mars 2026
• Mitratech, What Is DORA? What Financial Institutions Need to Know in 2026, juin 2026
• IBM, What Is the Digital Operational Resilience Act (DORA)?, juin 2026
• PwC Legal, cité par IBM, analyse de la phase de maturité DORA 2026