DORA et NIS2 : articulation, tableau et guide 2026

L’essentiel. Pour le secteur financier, DORA est lex specialis par rapport à NIS2 : ses exigences de gestion des risques TIC et de notification d’incidents se substituent à celles de NIS2. Mais NIS2 continue de s’appliquer pour ce qu’elle ajoute et que DORA ne couvre pas (formation des dirigeants, coopération avec les CSIRT nationaux). La bonne stratégie n’est pas deux projets séparés, mais une conformité intégrée : une cartographie des obligations, un cadre de gouvernance unique et un processus de notification harmonisé. Le tableau de correspondance ci-dessous indique, pour chaque domaine, quel texte prévaut.

Les entités du secteur financier européen font face à une superposition réglementaire en cybersécurité et résilience opérationnelle. Deux textes se chevauchent : le règlement DORA (Digital Operational Resilience Act, règlement (UE) 2022/2554) et la directive NIS2 (directive (UE) 2022/2555). Adoptés le même jour — le 14 décembre 2022 — ils sont entrés en application respectivement le 17 janvier 2025 pour DORA et à compter du 18 octobre 2024 pour NIS2 (échéance de transposition fixée au 17 octobre 2024).

La question centrale des acteurs financiers : comment éviter une double conformité inutile tout en respectant chaque texte ? Le législateur européen a prévu un mécanisme fondé sur le principe de lex specialis, mais sa mise en œuvre pratique soulève des questions concrètes. Consultez notre guide DORA pour le cadre général et notre analyse de la directive NIS2 pour le contexte de cette seconde réglementation.

Le principe de lex specialis

Fondement juridique

Le considérant 16 de DORA et l’article 4 de NIS2 posent explicitement le principe : DORA est lex specialis par rapport à NIS2 pour le secteur financier. Lorsque DORA traite d’un sujet également couvert par NIS2, ce sont les dispositions de DORA qui s’appliquent en priorité aux entités financières. NIS2 ne joue que pour les aspects qu’elle couvre et que DORA ne couvre pas.

L’article 4, paragraphe 2, de NIS2 est précis : lorsqu’un acte juridique sectoriel de l’Union impose des exigences au moins aussi strictes que celles de NIS2 en matière de gestion des risques ou de notification d’incidents, les dispositions correspondantes de NIS2 ne s’appliquent pas.

Conséquences pratiques

Pour les entités financières soumises à DORA :

• les exigences de gestion des risques TIC de DORA (articles 5 à 16) se substituent à l’article 21 de NIS2 ;
• les obligations de notification d’incidents de DORA (articles 17 à 23) se substituent à l’article 23 de NIS2 ;
• les obligations propres à DORA en matière de tests de résilience (articles 24 à 27), de gestion du risque lié aux prestataires TIC (articles 28 à 44) et de partage d’informations (article 45) n’ont pas d’équivalent direct dans NIS2 et s’appliquent de manière autonome.

En revanche, certaines dispositions de NIS2 sans équivalent dans DORA continuent de s’appliquer aux entités financières.

Ce que NIS2 ajoute à DORA

Gouvernance et responsabilité des dirigeants

NIS2 impose que les organes de direction approuvent les mesures de gestion des risques, en supervisent la mise en œuvre et puissent être tenus responsables (article 20). DORA contient des dispositions similaires à son article 5, qui confie à l’organe de direction la responsabilité ultime de la gestion des risques TIC. Sur ce point, les deux textes convergent : l’entité qui satisfait la gouvernance de DORA satisfait, en principe, l’exigence équivalente de NIS2.

Formation des dirigeants

L’article 20, paragraphe 2, de NIS2 impose aux membres des organes de direction de suivre une formation en cybersécurité. DORA ne contient pas d’obligation explicite équivalente. C’est un ajout de NIS2 que les entités financières ont intérêt à intégrer dans leur programme de conformité.

Coopération et partage d’informations à l’échelle nationale

NIS2 instaure un cadre de coopération via les CSIRT nationaux, le réseau des CSIRT et le groupe de coopération NIS. DORA prévoit son propre mécanisme de partage d’informations sur les cybermenaces (article 45) et un cadre de coordination entre autorités financières. Les deux mécanismes coexistent et se complètent.

Sécurité de la chaîne d’approvisionnement

NIS2 impose de prendre en compte la sécurité de la chaîne d’approvisionnement (article 21, paragraphe 2, point d). DORA traite cette question de façon beaucoup plus détaillée via son cadre de gestion du risque lié aux prestataires tiers de services TIC (articles 28 à 44), incluant la surveillance des prestataires critiques. Sur ce point, DORA va plus loin : l’entité conforme à DORA satisfait l’exigence de NIS2.

Notification des incidents : deux régimes distincts

Le régime de DORA

DORA impose de notifier les incidents majeurs liés aux TIC à l’autorité de surveillance compétente (article 19), en trois temps :

• une notification initiale peu après la classification de l’incident ;
• un rapport intermédiaire sur l’évolution ;
• un rapport final analysant les causes profondes et les mesures correctives.

Les critères de classification (impact sur les services, nombre de clients affectés, durée, propagation géographique) sont précisés par les normes techniques de réglementation (RTS) adoptées par les autorités européennes de surveillance.

Le régime de NIS2

NIS2 impose de notifier les incidents significatifs au CSIRT ou à l’autorité compétente (article 23) selon des délais fixes :

• une alerte précoce dans les 24 heures ;
• une notification dans les 72 heures ;
• un rapport final dans un délai d’un mois.

Ce triptyque des 72 heures rappelle le régime de notification des violations de données du RGPD, dont il faut le distinguer : une même cyberattaque peut déclencher simultanément une notification NIS2/DORA (incident) et une notification RGPD à la CNIL si des données personnelles sont touchées, à documenter avec notre modèle de notification 72 h.

Articulation entre les deux régimes

Pour les entités soumises à DORA, le régime de notification de DORA prévaut : elles ne notifient pas le même incident aux autorités NIS2. Restent des zones de friction :

• les délais diffèrent (cadre à trois étapes de DORA précisé par les RTS ; délais fixes de NIS2) ;
• les autorités destinataires diffèrent (autorité de surveillance financière pour DORA, CSIRT/autorité NIS pour NIS2) ;
• les critères de classification ne coïncident pas : un incident « majeur » au sens de DORA n’est pas nécessairement « significatif » au sens de NIS2, et inversement.

En pratique, le processus interne de gestion des incidents doit couvrir les deux cadres, même si la notification formelle se fait au titre de DORA. Les autorités financières et NIS coopèrent et s’échangent les informations (article 19, paragraphe 8, de DORA).

Périmètre d’application : zones de chevauchement

La plupart des entités financières soumises à DORA sont aussi des entités essentielles ou importantes au sens de NIS2. L’annexe I de NIS2 inclut le secteur bancaire et les infrastructures de marchés financiers parmi les secteurs hautement critiques.

Catégorie	Couvert par DORA	Couvert par NIS2	Régime applicable
Établissements de crédit	Oui	Oui (Annexe I)	DORA (lex specialis)
Infrastructures de marché	Oui	Oui (Annexe I)	DORA (lex specialis)
Entreprises d’assurance	Oui	Selon transposition	DORA (lex specialis)
Prestataires TIC critiques	Oui (surveillance DORA)	Possible selon activité	DORA pour la surveillance, NIS2 en complément
Fournisseurs cloud génériques	Non (sauf contrats DORA)	Oui (Annexe I)	NIS2

Prestataires TIC : une double casquette

Un fournisseur cloud désigné prestataire TIC critique au sens de DORA relève du régime de surveillance de DORA. Mais ce même fournisseur est aussi, en tant que prestataire de services d’informatique en nuage, une entité essentielle au sens de NIS2. Les deux régimes coexistent : la surveillance DORA pour les services fournis aux entités financières ; NIS2 pour l’ensemble de son activité. Ce prestataire est par ailleurs, pour ce qui concerne les données personnelles qu’il héberge, votre sous-traitant au sens du RGPD — d’où un empilement contractuel à maîtriser.

Stratégie de mise en conformité intégrée

Plutôt que deux projets séparés, adoptez une approche intégrée en cinq étapes.

Étape 1 — Cartographie des obligations. Identifiez, dans une matrice, les obligations de chaque texte applicables à votre organisation et repérez chevauchements et spécificités. Un audit transversal cybersécurité/données personnelles est un bon point de départ.

Étape 2 — Identification des écarts. Déterminez les obligations de NIS2 non couvertes par DORA (formation des dirigeants, coopération avec les CSIRT nationaux). Ces écarts sont limités mais non négligeables.

Étape 3 — Cadre de gouvernance unique. Mettez en place une gouvernance des risques TIC répondant simultanément aux deux textes. La politique de gestion des risques TIC de DORA sert de socle, complétée par les éléments propres à NIS2. La certification ISO 27001 fournit un référentiel commun facilitant la démarche. La responsabilité ultime revient à l’organe de direction, qui joue ici un rôle comparable à celui du responsable de traitement en matière de données personnelles.

Étape 4 — Processus de notification harmonisé. Concevez un processus de gestion des incidents couvrant les deux cadres. Même si la notification formelle se fait au titre de DORA, intégrez les critères de classification de NIS2 pour détecter les cas nécessitant une action NIS2 complémentaire.

Étape 5 — Gestion des prestataires. Unifiez, dans un cadre contractuel unique, les exigences de DORA (article 30), celles de la sous-traitance de l’article 28 du RGPD et l’exigence de sécurité de la chaîne d’approvisionnement de NIS2 (article 21.2.d). Un logiciel de conformité permet d’industrialiser la tenue du registre des prestataires et le suivi des clauses, échéances et évaluations de sécurité sur ces différents cadres.

Tableau de correspondance des obligations

Domaine	DORA	NIS2	Prévaut
Gestion des risques TIC	Articles 5-16	Article 21	DORA
Notification d’incidents	Articles 17-23	Article 23	DORA
Tests de résilience	Articles 24-27	—	DORA (pas d’équivalent)
Gestion des prestataires TIC	Articles 28-44	Article 21.2.d	DORA (plus détaillé)
Partage d’informations	Article 45	Article 29	Complémentaires
Gouvernance / responsabilité	Article 5	Article 20	Convergents
Formation des dirigeants	—	Article 20.2	NIS2 (ajout)
Coopération avec CSIRT	—	Articles 10-14	NIS2 (ajout)
Sanctions	Autorités financières	Autorités NIS nationales	Parallèles

Points de vigilance et erreurs fréquentes

Trois écueils reviennent systématiquement dans les projets de conformité DORA-NIS2.

Croire que DORA « efface » NIS2. C’est l’erreur la plus courante. Le principe de lex specialis neutralise les dispositions redondantes de NIS2, pas l’ensemble du texte. Les obligations propres à NIS2 (formation des dirigeants, participation aux mécanismes nationaux de coopération) subsistent et sont parfois oubliées, faute d’avoir été explicitement cartographiées.

Sous-estimer la chaîne des prestataires. DORA impose un cadre contractuel exigeant vis-à-vis des prestataires TIC (article 30), qui se superpose aux clauses de sous-traitance RGPD et aux exigences de chaîne d’approvisionnement de NIS2. Renégocier les contrats fournisseurs prend du temps ; c’est souvent le chemin critique du projet. Le registre des prestataires TIC de DORA et le registre des sous-traitants du RGPD gagnent à être tenus dans un référentiel unique.

Séparer cybersécurité et données personnelles. Un même incident peut relever de DORA (incident TIC majeur), de NIS2 (incident significatif) et du RGPD (violation de données personnelles). Un processus de notification qui ne penserait qu’à l’un des trois cadres exposerait l’entité à un manquement sur les autres. La cellule de crise doit disposer d’un arbre de décision unique orientant, dès la qualification de l’incident, vers les bonnes autorités et les bons délais.

Sur le plan du calendrier, DORA est pleinement applicable depuis janvier 2025 ; la transposition française de NIS2 s’est finalisée sur 2025-2026, avec une montée en charge progressive des obligations et des contrôles. Les entités concernées ont intérêt à figer dès maintenant leur cartographie et leur gouvernance, sans attendre les premiers contrôles.

Le régime de sanctions

Sanctions DORA

DORA confie aux autorités de surveillance financière nationales le pouvoir de sanctionner. Les sanctions applicables sont celles des législations sectorielles existantes (CRD, MiFID II, Solvabilité II…) : DORA n’instaure pas de régime de sanctions autonome mais renforce les pouvoirs de supervision. Pour les prestataires TIC critiques, les autorités européennes de surveillance peuvent imposer des astreintes en cas de non-conformité persistante.

Sanctions NIS2

NIS2 prévoit des sanctions administratives pouvant atteindre :

• 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial pour les entités essentielles ;
• 7 millions d’euros ou 1,4 % du chiffre d’affaires annuel mondial pour les entités importantes.

Pour les entités financières, la question de savoir si les sanctions NIS2 s’appliquent en complément ou en substitution de celles de DORA dépend de la transposition nationale. La transposition française de NIS2, en cours de finalisation sur 2025-2026, précise les autorités compétentes et les modalités de sanction applicables au secteur financier.

Risque de double sanction

Le principe de lex specialis devrait, en théorie, éviter la double sanction pour un même manquement. Mais si un manquement relève d’une obligation NIS2 non couverte par DORA, l’entité pourrait être sanctionnée au titre de NIS2 par l’autorité NIS, en complément d’une sanction financière au titre de DORA pour d’autres manquements. D’où l’intérêt d’une conformité qui n’ignore aucun des deux cadres.

FAQ

DORA remplace-t-il NIS2 pour les banques ?

Non. DORA prime en tant que lex specialis sur les sujets qu’il couvre (gestion des risques TIC, notification d’incidents), mais NIS2 continue de s’appliquer pour ce qu’il ajoute — notamment la formation des dirigeants et la coopération avec les CSIRT nationaux. Il faut donc lire les deux textes ensemble.

Une entité financière doit-elle notifier ses incidents deux fois ?

En principe non : elle notifie ses incidents majeurs au titre de DORA, à son autorité de surveillance financière. Son processus interne doit toutefois intégrer les critères de NIS2 pour identifier les rares cas où une action complémentaire serait requise. Et si des données personnelles sont compromises, une notification à la CNIL au titre du RGPD s’ajoute (voir notre modèle 72 h).

Quelle est la date d’application de DORA et de NIS2 ?

DORA s’applique depuis le 17 janvier 2025. NIS2 devait être transposée par les États membres au plus tard le 17 octobre 2024, pour une application à compter du 18 octobre 2024 ; la transposition française s’est finalisée sur 2025-2026.

Un prestataire cloud est-il soumis à DORA ou à NIS2 ?

Potentiellement aux deux. S’il est désigné prestataire TIC critique, il relève de la surveillance DORA pour les services rendus aux entités financières, et de NIS2 pour l’ensemble de son activité. Pour les données personnelles qu’il héberge, il est aussi votre sous-traitant au sens du RGPD.

Quelles sanctions en cas de non-conformité à NIS2 ?

Jusqu’à 10 M€ ou 2 % du chiffre d’affaires mondial pour une entité essentielle, et 7 M€ ou 1,4 % pour une entité importante. Les modalités précises applicables au secteur financier dépendent de la transposition nationale.

Par où commencer une conformité DORA-NIS2 intégrée ?

Par une cartographie des obligations dans une matrice de correspondance, puis l’identification des écarts NIS2 non couverts par DORA, la mise en place d’un cadre de gouvernance unique (idéalement adossé à l’ISO 27001) et un processus de notification harmonisé. Consultez notre guide DORA et notre analyse de la directive NIS2 pour approfondir chaque cadre.