DORA et NIS2 simultanément : comment les prestataires de services financiers gèrent la double pression de conformité

⏱ 14 min de lecture

DORA est depuis janvier 2025 applicable, NIS2 depuis décembre 2025 transposé en droit allemand. Pour les prestataires de services financiers, cela signifie : deux régulations avec des échéances, des définitions et des systèmes de déclaration différents – mais des chevauchements massifs sur le fond. Ceux qui traitent les deux cadres réglementaires de manière isolée doublent les efforts sans valeur ajoutée. Ceux qui comprennent les synergies économisent des millions et construisent un système de conformité intégré qui crée réellement de la sécurité. Cet article montre où DORA et NIS2 se chevauchent, où ils diffèrent et ce que les entreprises financières peuvent faire une fois au lieu de deux.

L’essentiel

• DORA (Digital Operational Resilience Act) est applicable depuis le 17 janvier 2025, NIS2 depuis décembre 2025 en droit allemand – les prestataires de services financiers doivent se conformer aux deux simultanément
• DORA est lex specialis pour le secteur financier et prime en cas de chevauchements, mais NIS2 s’applique en complément lorsque DORA ne couvre pas un domaine
• La plus grande efficacité réside dans une gestion intégrée des risques ICT qui répond aux deux cadres – au lieu de deux projets de conformité parallèles
• La gestion des risques liés aux tiers informatiques (TPRM) est le point faible commun : DORA exige un Register of Information, NIS2 demande la sécurité de la chaîne d’approvisionnement – les deux peuvent être fusionnés
• Les obligations de déclaration diffèrent considérablement : DORA exige une déclaration initiale sous 24 heures à la BaFin, NIS2 demande une déclaration « sans délai » au BSI (Office fédéral de la sécurité informatique) – deux systèmes différents qui doivent être gérés en parallèle

Deux régulations, un objectif – mais des voies différentes

DORA comme NIS2 poursuivent le même objectif supérieur : renforcer la résilience cyber en Europe. Les deux exigent une gestion des risques, la déclaration des incidents, des tests d’intrusion et la sécurisation des chaînes d’approvisionnement. La différence fondamentale réside dans le champ d’application et la spécificité.

DORA est un règlement de l’UE, directement applicable – sans transposition nationale. Il s’adresse exclusivement au secteur financier : banques, assurances, entreprises d’investissement, prestataires de services de paiement, prestataires de services sur actifs cryptographiques et leurs prestataires tiers ICT critiques. DORA définit des exigences granulaires pour la résilience opérationnelle numérique, de la gestion des risques ICT à la déclaration des incidents en passant par les Threat-Led Penetration Testing (TLPT).

NIS2 est une directive de l’UE qui a dû être transposée en droit national. En Allemagne, cela a été fait par la loi de transposition de NIS2 et de renforcement de la cybersécurité, entrée en vigueur en décembre 2025. NIS2 s’applique de manière intersectorielle aux entités « essentielles » et « importantes » dans 18 secteurs – y compris le secteur financier. Les exigences sont moins granulaires que celles de DORA, mais couvrent un spectre plus large.

Lex specialis : que signifie la primauté de DORA ?

DORA est considéré comme lex specialis par rapport à NIS2 dans le secteur financier. Cela signifie : lorsque DORA définit des exigences spécifiques, celles-ci priment sur les dispositions plus générales de NIS2. La directive NIS2 elle-même le confirme à l’article 4, paragraphe 2, et renvoie explicitement à DORA en tant que réglementation sectorielle spécifique.

En pratique, c’est cependant plus compliqué que cela n’y paraît. Le principe lex specialis ne signifie pas que NIS2 est sans importance pour les entreprises financières. Il signifie seulement que DORA prime là où il réglemente les mêmes sujets de manière plus détaillée. Dans les domaines que DORA ne couvre pas – comme la sécurité de la chaîne d’approvisionnement au-delà des prestataires de services ICT ou la sécurité des systèmes OT – NIS2 continue de s’appliquer.

Pour un aperçu détaillé de la manière dont la BaFin vérifie la mise en œuvre de DORA, consultez notre article sur MyBusinessFuture : DORA : la BaFin vérifie les instituts financiers.

Chevauchements : ce qui suffit une fois

La bonne nouvelle : environ 60 à 70 % des exigences de DORA et NIS2 se chevauchent sur le fond. Ceux qui exploitent ces synergies évitent un travail en double massif. Voici les principaux domaines dans lesquels une seule mise en œuvre répond aux deux cadres :

Gestion des risques ICT

DORA (chapitre II, articles 5-16) exige un cadre complet de gestion des risques ICT. NIS2 demande à l’article 21 des « mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées » pour la gestion des risques. En pratique : un cadre de gestion des risques ICT construit selon DORA remplit automatiquement les exigences de NIS2 en matière de gestion des risques – DORA est ici plus détaillé et plus strict.

● Mettre en œuvre une fois : cadre de gestion des risques ICT selon la norme DORA. Ce cadre couvre toutes les exigences de gestion des risques pertinentes pour NIS2.

● Adapter la documentation : compléter la documentation DORA avec des références spécifiques à NIS2, afin que la preuve soit établie lors des vérifications des deux régulations.

Réponse aux incidents et gestion

Les deux cadres réglementaires exigent une gestion structurée des incidents. DORA définit au chapitre III (articles 17-23) des exigences détaillées pour la classification, la déclaration et le suivi des incidents ICT. NIS2 exige à l’article 23 un « système d’alerte précoce » et des déclarations structurées.

Le processus de gestion des incidents peut être construit de manière unifiée. La différence critique réside dans les voies et les délais de déclaration – nous y reviendrons dans la section sur les obligations de déclaration.

Tests d’intrusion et gestion des vulnérabilités

DORA exige aux articles 26-27 des tests d’intrusion réguliers et, pour les instituts d’importance systémique, des Threat-Led Penetration Testing (TLPT) selon le cadre TIBER-EU. NIS2 demande de manière générale des « politiques et procédures pour évaluer l’efficacité » des mesures de sécurité.

Un programme de tests conforme à DORA avec TLPT dépasse largement les exigences de NIS2. Ici, la mise en œuvre de DORA suffit donc entièrement.

Gestion de la continuité d’activité

DORA exige des plans complets de continuité d’activité ICT (article 11). NIS2 demande le « maintien des opérations » et la gestion de crise (article 21, paragraphe 2c). Ici aussi : un programme BCM conforme à DORA couvre les exigences de NIS2 – DORA est plus spécifique et plus strict.

Les différences critiques : ce qui doit être fait deux fois

Malgré les synergies, il existe des domaines dans lesquels DORA et NIS2 diffèrent substantiellement et nécessitent des mesures séparées :

Obligations de déclaration : deux systèmes, deux autorités, des délais différents

C’est ici que réside le plus grand surcoût opérationnel pour les prestataires de services financiers. DORA et NIS2 exigent la déclaration des incidents – mais à des autorités différentes, avec des délais et des formats différents :

● DORA : déclaration à l’autorité de surveillance financière compétente (en Allemagne : BaFin). Déclaration initiale dans les 24 heures suivant la classification comme « incident ICT grave ». Rapport intermédiaire dans les 72 heures. Rapport final dans un délai d’un mois. Format : formulaires de déclaration EBA/ESMA.

● NIS2 : déclaration à l’autorité nationale compétente (en Allemagne : BSI). « Avertissement précoce » sans délai dans les 24 heures. Déclaration détaillée dans les 72 heures. Rapport final dans un délai d’un mois. Format : portail de déclaration du BSI.

Bien que les délais semblent similaires, les systèmes de déclaration, les formulaires et les interlocuteurs sont différents. Les entreprises financières doivent maîtriser opérationnellement les deux voies de déclaration. Le conseil pratique : créer un rapport d’incident interne unifié et l’adapter ensuite aux exigences de formulaire respectives de la BaFin et du BSI – au lieu de construire deux processus complètement séparés.

Gestion des risques liés aux tiers informatiques : DORA va beaucoup plus loin

La gestion des prestataires tiers ICT est le domaine dans lequel DORA impose les exigences les plus strictes et les plus détaillées de toutes les régulations européennes. DORA exige :

● Register of Information (RoI) : une documentation complète de tous les accords contractuels avec les prestataires tiers ICT. Ce registre doit contenir des détails granulaires : objet du contrat, lieux de stockage des données, sous-traitants, stratégies de sortie et analyses de dépendance. La date limite pour le premier RoI complet était le T1 2026.

● Évaluation de la criticité : chaque prestataire de services ICT doit être évalué en fonction de sa criticité pour les fonctions commerciales. Pour les prestataires « critiques », des exigences renforcées s’appliquent en matière de rédaction des contrats, de droits d’audit et de scénarios de sortie.

● Analyse des risques de concentration : les entreprises financières doivent analyser si elles dépendent trop fortement de certains prestataires de services ICT – un sujet particulièrement pertinent avec les hyperscalers (AWS, Azure, GCP).

NIS2 exige également la « sécurité de la chaîne d’approvisionnement » (article 21, paragraphe 2d), mais avec beaucoup moins de détails. Pour les entreprises financières, cela signifie : le cadre TPRM de DORA est la norme qui doit être mise en œuvre. Les exigences de NIS2 y sont incluses.

Cadre de surveillance pour les prestataires tiers ICT critiques

DORA introduit au chapitre V un cadre de surveillance entièrement nouveau : les prestataires tiers ICT critiques (comme les grands fournisseurs de cloud) seront désormais directement supervisés par une « autorité de surveillance chef de file » des AES (ABE, AEMF, AEAPP). Cet élément n’a pas d’équivalent dans NIS2 et concerne indirectement les entreprises financières – elles doivent s’assurer que leurs prestataires ICT critiques répondent aux nouvelles exigences de surveillance.

L’approche intégrée de conformité : un cadre pour les deux

Au lieu de traiter DORA et NIS2 comme deux projets de conformité séparés, les entreprises financières devraient adopter une approche intégrée. L’idée de base : construire un seul cadre de gouvernance qui répond aux deux régulations et prendre les exigences de DORA comme base (car elles sont plus détaillées).

Voici à quoi ressemble une approche intégrée en pratique :

● Étape 1 – Mapping : créez une matrice de référence croisée qui associe chaque exigence de DORA à l’exigence correspondante de NIS2. Les AES et le BSI proposent des documents de mapping comme point de départ. Identifiez les trois catégories : « couvert par DORA », « couvert par NIS2 », « les deux nécessitent des mesures séparées ».

● Étape 2 – Gestion unifiée des risques : mettez en œuvre un cadre de gestion des risques ICT selon la norme DORA (articles 5-16). Complétez-le avec des éléments spécifiques à NIS2 comme la sécurité OT et la sécurité de la chaîne d’approvisionnement non liée aux ICT.

● Étape 3 – Voies de déclaration parallèles : construisez un processus interne unifié de gestion des incidents. Implémentez à la fin de la chaîne de déclaration deux sorties parallèles : une vers le système de déclaration de la BaFin (DORA) et une vers le portail de déclaration du BSI (NIS2). Le processus interne est identique, seules les dernières étapes diffèrent.

● Étape 4 – TPRM intégré : utilisez le Register of Information de DORA comme base de données centrale pour l’ensemble de la gestion des risques liés aux tiers. Étendez-le aux fournisseurs non ICT pertinents sous NIS2.

● Étape 5 – Gouvernance : établissez une structure de gouvernance unique (par exemple, un « Comité de résilience numérique »), responsable à la fois de la conformité DORA et NIS2. Pas d’équipes de conformité parallèles pour différentes régulations.

Register of Information : le défi pratique

Le Register of Information (RoI) de DORA mérite une attention particulière, car il représente pour de nombreux instituts l’exigence individuelle la plus exigeante. Le RoI doit documenter tous les accords contractuels avec les prestataires tiers ICT – y compris des détails qui, dans de nombreuses entreprises, n’ont jusqu’à présent été enregistrés nulle part de manière centralisée :

● Détails du contrat : objet, durée, délais de résiliation, SLA, clauses de responsabilité

● Lieux de stockage des données : où les données sont-elles traitées et stockées ? Quelles juridictions sont concernées ?

● Chaînes de sous-traitants : quels sous-prestataires le fournisseur ICT utilise-t-il ? Où sont-ils situés ?

● Analyse des dépendances : quelles fonctions commerciales dépendent de ce prestataire ? Que se passe-t-il en cas de défaillance ?

● Stratégie de sortie : comment changer de prestataire ? Quelles données doivent être migrées ?

Les instituts qui n’ont pas encore finalisé le RoI devraient prioriser de manière pragmatique : commencer par les prestataires les plus critiques (fournisseurs de cloud, systèmes bancaires centraux, infrastructure de paiement) et étendre progressivement. La BaFin a indiqué qu’elle évaluerait lors du premier contrôle les progrès et la méthodologie – et non seulement le résultat.

Direction en responsabilité : responsabilité sous DORA et NIS2

DORA comme NIS2 soulignent la responsabilité de la direction en matière de cybersécurité. DORA rend explicitement l’organe de direction responsable de l’approbation et de la supervision du cadre de gestion des risques ICT (article 5, paragraphe 2). NIS2 prévoit que les organes de direction doivent approuver les mesures de gestion des risques, surveiller leur mise en œuvre et participer à des formations en cybersécurité (article 20).

Dans la transposition allemande, les gérants et membres du directoire peuvent être tenus personnellement responsables s’ils ne remplissent pas leurs obligations de surveillance. Les amendes sont considérables : jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial selon NIS2, des montants comparables sous DORA.

La conséquence pratique : la cybersécurité n’est plus un sujet informatique qui peut être délégué au RSSI. Les membres du directoire et les gérants doivent être impliqués de manière démontrable – dans les décisions, les approbations et les revues régulières.

« Évaluation des écarts par rapport aux deux cadres : ne pas vérifier DORA et NIS2 séparément, mais effectuer une analyse intégrée des écarts. »

Checklist pratique : gérer la double pression DORA + NIS2

Pour les entreprises financières qui souhaitent gérer efficacement la double pression de conformité, voici les prochaines étapes concrètes :

● Évaluation des écarts par rapport aux deux cadres : ne pas vérifier DORA et NIS2 séparément, mais effectuer une analyse intégrée des écarts. Résultat : un plan d’action consolidé au lieu de deux.

● Finaliser le Register of Information : si ce n’est pas encore fait, commencer maintenant avec les 20 principaux prestataires ICT. Ne pas attendre la perfection – un RoI à 80 % qui existe vaut mieux qu’un RoI à 100 % qui sera prêt dans six mois.

● Mettre en place des processus de déclaration doubles : implémenter un processus interne unifié de gestion des incidents avec deux sorties (BaFin + BSI). Effectuer des déclarations tests avant que le cas réel ne se présente.

● Planifier le programme TLPT : pour les instituts d’importance systémique, les Threat-Led Penetration Testing sont obligatoires sous DORA. L’effort est considérable (6-12 mois par cycle TLPT) – commencer tôt avec un fournisseur TLPT qualifié.

● Formation de la direction : le directoire et la direction doivent être formés de manière démontrable aux deux cadres. Mettre en place un programme de formation commun qui traite DORA et NIS2 de manière intégrée.

● Évaluer le risque de concentration : analyser la dépendance vis-à-vis de certains fournisseurs de cloud et prestataires ICT. Documenter les stratégies multi-cloud et de sortie.

● Réviser les contrats : vérifier tous les contrats ICT par rapport aux exigences de DORA (droits d’audit, clauses de sous-traitance, règles de sortie). Initier les renégociations rapidement.

Perspectives : la densité réglementaire continue d’augmenter

DORA et NIS2 ne sont pas les dernières régulations qui toucheront les entreprises financières en matière de cybersécurité. Avec l’EU AI Act, le Cyber Resilience Act et le Data Act, d’autres cadres réglementaires s’ajoutent, présentant des chevauchements et devant être considérés de manière intégrée.

Les instituts financiers qui construisent maintenant un cadre de conformité flexible et intégré absorberont plus facilement ces régulations supplémentaires que les entreprises qui traitent chaque nouvelle loi comme un projet isolé. L’approche intégrée ne porte pas seulement ses fruits à court terme – c’est la seule stratégie évolutive face à l’augmentation de la densité réglementaire en Europe.

Les autorités de surveillance – BaFin et BSI – sont conscientes de la double charge et travaillent sur des approches de contrôle coordonnées. Néanmoins, la responsabilité de la mise en œuvre efficace incombe aux entreprises elles-mêmes. Ceux qui exploitent maintenant les synergies n’économisent pas seulement des coûts de conformité, mais construisent une résilience numérique qui protège réellement. Un aperçu détaillé des exigences de NIS2 est disponible dans notre article NIS2 en Allemagne : ce que les entreprises doivent savoir et mettre en œuvre maintenant.

Questions fréquentes

Les entreprises financières doivent-elles se conformer à la fois à DORA et à NIS2 ?

Oui. DORA s’applique en tant que lex specialis et prime en cas de chevauchements, mais NIS2 s’applique en complément dans les domaines que DORA ne couvre pas. Les entreprises financières doivent connaître les deux cadres réglementaires et remplir les exigences respectives. Une approche intégrée de conformité permet d’éviter les doubles emplois.

À qui les incidents de sécurité doivent-ils être déclarés ?

Sous DORA à l’autorité de surveillance financière compétente (BaFin) dans les 24 heures. Sous NIS2 au BSI, également « sans délai » (en pratique dans les 24 heures). Les deux déclarations doivent être effectuées en parallèle – il s’agit de systèmes et de formulaires de déclaration différents.

Qu’est-ce que le Register of Information et quand doit-il être prêt ?

Le Register of Information est une documentation complète de tous les accords contractuels avec les prestataires tiers ICT selon DORA. Il doit contenir des détails sur l’objet du contrat, les lieux de stockage des données, les sous-traitants, les dépendances et les stratégies de sortie. La date limite pour le premier registre complet était le T1 2026. Les instituts qui ne l’ont pas encore finalisé devraient commencer immédiatement avec les 20 principaux prestataires ICT.

La direction est-elle personnellement responsable ?

Oui, sous les deux cadres réglementaires. DORA rend l’organe de direction responsable de l’approbation et de la supervision du cadre de gestion des risques ICT. NIS2 prévoit une responsabilité personnelle si les organes de direction ne remplissent pas leurs obligations de surveillance. Les gérants et membres du directoire doivent être impliqués de manière démontrable dans les décisions de cybersécurité.

Comment réduire les coûts de conformité pour DORA et NIS2 ?

Par une approche intégrée de conformité : construire un seul cadre de gouvernance qui répond aux deux régulations. Prendre les exigences de DORA comme base (car plus détaillées), combler de manière ciblée les lacunes de NIS2. Effectuer une analyse unifiée des écarts au lieu de deux séparées. Exploiter systématiquement les synergies en matière de gestion des risques, BCM et tests. Éviter les équipes de conformité parallèles.

Lectures complémentaires

• NIS2 en Allemagne : ce que les entreprises doivent savoir et mettre en œuvre maintenant
• DORA : la BaFin vérifie les instituts financiers – MyBusinessFuture
• Assurance cyber 2026 : ce que les entreprises doivent savoir

Plus dans le réseau MBF Media

• FinOps : comment les entreprises maîtrisent les coûts du cloud – cloudmagazin
• Tendances en cybersécurité 2026 : sept évolutions – SecurityToday
• Sécurité de la chaîne d’approvisionnement 2026 – SecurityToday

Source de l’image : Pexels / Sora Shimazaki

À propos de l'auteur: Tobias Massow

Plus d'articles de Tobias Massow