Contexte : Le défi de la double réglementation
Depuis janvier 2025, de nombreuses entités du secteur financier à travers l’Union européenne se trouvent soumises simultanément à deux textes majeurs de législation en cybersécurité : la directive NIS2 (Directive 2022/2555) et le Digital Operational Resilience Act (Règlement 2022/2554, connu sous le nom de DORA). Ce scénario de double réglementation soulève des questions légitimes sur les exigences qui se chevauchent, les conflits potentiels et la manière de construire un programme de conformité qui satisfait les deux cadres de manière efficiente.
Cette analyse est rédigée pour les responsables conformité, les auditeurs et les gestionnaires de risques qui doivent comprendre où ces cadres convergent, où ils divergent et comment éviter à la fois la duplication des efforts et les lacunes de conformité.
Le principe Lex Specialis : Article 4 de NIS2
L’article 4 de la directive NIS2 établit un principe juridique essentiel : lorsqu’un acte juridique sectoriel de l’Union exige que les entités essentielles ou importantes adoptent des mesures de gestion des risques en matière de cybersécurité ou notifient des incidents significatifs, et lorsque ces exigences sont au moins équivalentes en effet aux obligations de NIS2, alors l’acte sectoriel prévaut.
DORA est explicitement reconnu comme un tel acte sectoriel pour le secteur financier. En termes pratiques, cela signifie :
- Pour les domaines où DORA fournit des exigences équivalentes ou plus strictes, DORA prévaut pour les entités financières.
- Pour les domaines où NIS2 couvre des sujets non traités par DORA, les obligations NIS2 s’appliquent toujours.
- Le principe lex specialis ne crée pas une exemption globale de NIS2 — il crée une hiérarchie qui doit être évaluée exigence par exigence.
Cette nuance est fréquemment mal comprise. Les responsables conformité doivent effectuer une cartographie exigence par exigence, et non supposer que la conformité DORA satisfait automatiquement toutes les obligations NIS2.
Comparaison complète : Exigences NIS2 vs DORA
Le tableau suivant fournit une cartographie détaillée des principaux domaines d’exigences à travers les deux cadres, identifiant les chevauchements, les lacunes et quel cadre prévaut pour les entités financières.
| Domaine d’exigence | Exigence NIS2 | Équivalent DORA | Analyse chevauchement / lacune |
|---|---|---|---|
| Gestion des risques | Art. 21(1) : Mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées basées sur une approche tous risques | Art. 6-16 : Cadre détaillé de gestion des risques ICT avec exigences spécifiques pour l’identification, la protection, la détection, la réponse, la récupération et l’apprentissage | DORA prévaut. DORA est significativement plus prescriptif sur la gestion des risques ICT. Les entités financières devraient utiliser le cadre DORA comme base principale de conformité. |
| Signalement d’incidents | Art. 23 : Alerte précoce dans les 24 heures, notification d’incident dans les 72 heures, rapport final dans un mois | Art. 19 : Notification initiale, rapports intermédiaires et rapport final à l’autorité compétente. Critères de classification spécifiques pour les incidents majeurs liés aux ICT. | DORA prévaut pour les incidents ICT. Les délais de signalement et critères de classification diffèrent. NIS2 peut encore s’appliquer pour les incidents de sécurité non-ICT affectant les réseaux et systèmes d’information. |
| Sécurité de la chaîne d’approvisionnement | Art. 21(2)(d) : Sécurité de la chaîne d’approvisionnement incluant les aspects liés à la sécurité des relations entre les entités et leurs fournisseurs ou prestataires directs | Art. 28-44 : Cadre étendu de gestion des risques liés aux tiers ICT, incluant les exigences contractuelles, la surveillance des prestataires ICT tiers critiques et le risque de concentration | DORA va significativement plus loin. DORA crée un cadre de surveillance pour les prestataires ICT tiers critiques qui n’a pas d’équivalent dans NIS2. Les entités financières bénéficient des exigences plus détaillées de DORA en matière de chaîne d’approvisionnement. |
| Tests | Art. 21(2)(f) : Politiques et procédures pour évaluer l’efficacité des mesures de gestion des risques de cybersécurité | Art. 24-27 : Tests de résilience opérationnelle numérique incluant les tests de pénétration basés sur les menaces (TLPT) pour les entités significatives, tests proportionnés pour les autres | DORA va plus loin. DORA impose des méthodologies de test spécifiques incluant le TLPT (basé sur le cadre TIBER-EU). NIS2 est moins prescriptif sur les approches de test. |
| Gouvernance | Art. 20 : Les organes de direction doivent approuver les mesures de gestion des risques de cybersécurité, superviser leur mise en œuvre et peuvent être tenus responsables. Les membres doivent suivre une formation. | Art. 5 : L’organe de direction a la responsabilité ultime de la gestion des risques ICT. Il doit définir, approuver et superviser la mise en œuvre du cadre de gestion des risques ICT et de la stratégie de résilience opérationnelle numérique. | Chevauchement substantiel. Les deux exigent la responsabilité de l’organe de direction. DORA est plus spécifique sur le cadre de gestion des risques ICT que l’organe de direction doit approuver. La conformité à l’article 5 de DORA devrait satisfaire substantiellement l’article 20 de NIS2 pour les questions ICT. |
| Partage d’informations | Art. 29 : Arrangements volontaires de partage de renseignements sur les cybermenaces entre entités essentielles et importantes | Art. 45 : Échange volontaire d’informations et de renseignements sur les cybermenaces entre entités financières, incluant les indicateurs de compromission, les tactiques et les alertes | Dispositions parallèles. Les deux encouragent le partage volontaire d’informations. DORA est sectoriel. Les entités financières peuvent participer à la fois aux arrangements généraux (NIS2) et sectoriels financiers (DORA). |
| Continuité d’activité | Art. 21(2)(c) : Continuité d’activité, incluant la gestion des sauvegardes, la reprise après sinistre et la gestion de crise | Art. 11-12 : Politique de continuité d’activité ICT, plans de réponse et de récupération ICT, politiques de sauvegarde, procédures de restauration et de récupération | DORA prévaut. DORA fournit des exigences plus détaillées pour la continuité et la récupération ICT. Les exigences NIS2 pour la continuité d’activité plus large (non-ICT) peuvent encore s’appliquer. |
| Gestion des vulnérabilités | Art. 21(2)(e) : Gestion et divulgation des vulnérabilités | Art. 7-8 (dans la gestion des risques) : Identification et évaluation des vulnérabilités ICT dans le cadre de la protection et de la prévention | NIS2 est plus large. NIS2 traite explicitement la divulgation coordonnée des vulnérabilités. DORA traite la gestion des vulnérabilités dans le cadre de gestion des risques ICT mais ne traite pas les processus de divulgation publique aussi directement. |
| Cryptographie et chiffrement | Art. 21(2)(h) : Politiques et procédures relatives à l’utilisation de la cryptographie et, le cas échéant, du chiffrement | Art. 9(4)(d) : Mesures de sécurité des données incluant les techniques cryptographiques dans le cadre de la gestion des risques ICT | Portée comparable. Les deux exigent des contrôles cryptographiques appropriés. DORA intègre cela dans le cadre plus large de gestion des risques ICT. NIS2 en fait un domaine d’exigence distinct. |
| Contrôle d’accès et authentification | Art. 21(2)(i-j) : Politiques de contrôle d’accès ; utilisation de l’authentification multifacteur ou de solutions d’authentification continue | Art. 9(4)(c) : Politiques de contrôle d’accès incluant des mécanismes d’authentification forte | Portée comparable. Les deux exigent des contrôles d’accès robustes et une authentification forte. DORA est moins spécifique sur le MFA mais exige une authentification forte dans le cadre basé sur les risques. |
Où NIS2 va au-delà de DORA
Les responsables conformité doivent porter une attention particulière aux domaines où les obligations NIS2 peuvent ne pas être entièrement couvertes par la conformité DORA :
- Portée plus large des réseaux et systèmes d’information : NIS2 s’applique à tous les réseaux et systèmes d’information utilisés dans la fourniture de services, pas seulement aux systèmes ICT au sens de DORA. Les systèmes de technologie opérationnelle (OT), les systèmes de sécurité physique connectés au réseau et les systèmes de gestion des bâtiments peuvent relever de NIS2 mais être hors du périmètre ICT de DORA.
- Divulgation coordonnée des vulnérabilités : NIS2 traite spécifiquement les processus de divulgation des vulnérabilités. Les entités financières qui découvrent des vulnérabilités dans des logiciels largement utilisés peuvent avoir des obligations sous NIS2 que DORA ne couvre pas.
- Chaîne d’approvisionnement au-delà des ICT : L’article 21(2)(d) de NIS2 couvre la sécurité de la chaîne d’approvisionnement de manière large, incluant les fournisseurs non-ICT dont les services affectent la sécurité des réseaux et systèmes d’information. DORA se concentre spécifiquement sur les prestataires de services ICT tiers.
- Mécanismes de coopération entre États membres : NIS2 établit les CSIRT, le groupe de coopération et EU-CyCLONe pour la coopération transfrontalière. Les entités financières peuvent devoir s’engager dans ces mécanismes pour les aspects non financiers de leurs opérations.
Où DORA va au-delà de NIS2
DORA fournit des exigences significativement plus détaillées dans plusieurs domaines :
- Gestion des risques liés aux tiers ICT : Les articles 28-44 de DORA créent un cadre complet de gestion des risques liés aux tiers ICT, incluant des dispositions contractuelles obligatoires (Article 30), l’évaluation du risque de concentration et un cadre de surveillance pour les prestataires ICT tiers critiques (Articles 31-44) avec une supervision directe par les Autorités européennes de surveillance. NIS2 n’a rien de comparable.
- Tests de résilience opérationnelle numérique : DORA impose des tests de pénétration basés sur les menaces (TLPT) pour les entités financières significatives, avec des exigences spécifiques pour le périmètre, la méthodologie et le reporting des tests. NIS2 exige des tests d’efficacité mais est bien moins prescriptif.
- Classification des incidents ICT : DORA fournit des critères détaillés pour classifier les incidents majeurs liés aux ICT, incluant des seuils d’impact transfrontalier. La classification des incidents de NIS2 est plus générale.
- Stratégie de résilience opérationnelle numérique : DORA exige une stratégie formelle de résilience opérationnelle numérique approuvée par l’organe de direction, avec des exigences de contenu spécifiques. NIS2 ne mandate pas un document de stratégie comparable.
Comparaison des architectures : comment les deux régimes façonnent le CI/CD
La cartographie exigence par exigence ci-dessus montre où les deux régimes se chevauchent et divergent sur le papier. Il est tout aussi important de comprendre comment ces objectifs se traduisent en architecture — la manière dont la gouvernance, les pipelines CI/CD, les preuves et les contrôles opérationnels sont réellement structurés sous chaque cadre. La comparaison ci-dessous examine NIS2 et DORA sous cet angle architectural, là où les entités à double réglementation découvrent le plus souvent des différences pratiques.
Portée et intention réglementaires
NIS2 : un socle de cybersécurité large
NIS2 établit un socle de cybersécurité horizontal couvrant un large éventail d’entités essentielles et importantes, notamment les organisations du secteur public, l’énergie, les transports, la santé, l’infrastructure numérique et les grandes entreprises.
Implication architecturale :
- accent sur la gestion des risques et la préparation
- flexibilité dans la mise en œuvre technique
- importance de la proportionnalité
NIS2 pose la question :
« Les risques de cybersécurité sont-ils identifiés, gérés et traités à l’échelle de l’organisation ? »
DORA : résilience opérationnelle du secteur financier
DORA est un règlement sectoriel ciblant les entités financières et leurs prestataires de services ICT. Il se concentre sur la résilience opérationnelle, la gestion des risques ICT et la surveillance prudentielle.
Implication architecturale :
- CI/CD et systèmes ICT traités comme des actifs réglementés
- attentes plus fortes en matière d’application et de traçabilité
- surveillance prudentielle plus stricte
DORA pose la question :
« Pouvez-vous démontrer en continu la maîtrise des risques ICT et la résilience ? »
Positionnement architectural des pipelines CI/CD
Perspective architecturale NIS2
Sous NIS2, les pipelines CI/CD font partie de l’écosystème de développement sécurisé et de chaîne d’approvisionnement.
Caractéristiques architecturales :
- le CI/CD applique des pratiques de SDLC sécurisé
- les risques liés aux dépendances et à la chaîne d’approvisionnement sont traités
- la gouvernance se concentre sur la propriété et la supervision
Les pipelines CI/CD soutiennent la conformité mais ne sont pas toujours explicitement classés comme systèmes réglementés.
Perspective architecturale DORA
Sous DORA, les pipelines CI/CD sont traités comme des systèmes ICT réglementés.
Caractéristiques architecturales :
- le CI/CD applique la gestion des changements et la séparation des tâches
- tous les changements en production doivent transiter par les pipelines
- les pipelines génèrent des preuves d’audit continues
Le CI/CD devient une couche d’application des contrôles, et pas seulement un mécanisme de livraison.
Couche de gouvernance et de gestion des risques
Modèle de gouvernance NIS2
- gestion des risques de cybersécurité
- mesures organisationnelles et techniques
- responsabilité de la direction
- gestion des risques fournisseurs
L’architecture soutient les décisions de gouvernance, mais l’application technique peut varier.
Modèle de gouvernance DORA
- cadre formel de gestion des risques ICT
- inclusion explicite du CI/CD dans le périmètre des risques
- propriété et responsabilité strictes
- lien fort entre la gouvernance et les contrôles techniques
L’architecture garantit que la gouvernance est appliquée techniquement.
Preuves et auditabilité
Attentes de NIS2 en matière de preuves
NIS2 exige des organisations qu’elles démontrent :
- des évaluations des risques
- des mesures de sécurité mises en œuvre
- une capacité de traitement des incidents
Les preuves peuvent inclure :
- des politiques et procédures
- des journaux et enregistrements de surveillance
- des rapports d’incidents
Les preuves sont souvent contextuelles et proportionnées.
Attentes de DORA en matière de preuves
DORA exige :
- des preuves continues, générées par les systèmes
- une traçabilité sur l’ensemble du cycle de vie ICT
- des pistes d’audit reproductibles
Les preuves sont censées être :
- centralisées
- conservées
- démontrables sur demande
L’architecture doit soutenir une conformité continue, et non des audits ponctuels.
Chaîne d’approvisionnement et risque lié aux tiers
Architecture de la chaîne d’approvisionnement NIS2
- gouvernance des fournisseurs et évaluation des risques
- contrôles proportionnés selon la criticité
- accent sur la préparation et la coordination
Le CI/CD soutient :
- la visibilité sur les dépendances
- l’atténuation des risques fournisseurs
Architecture de la chaîne d’approvisionnement DORA
- gestion des risques liés aux tiers ICT intégrée à la gouvernance ICT
- accent fort sur les prestataires ICT critiques
- alignement sur les attentes de la surveillance prudentielle financière
Le CI/CD soutient :
- l’intégrité des artefacts
- la provenance
- l’accès fournisseur contrôlé
Réponse aux incidents et résilience opérationnelle
Architecture NIS2
- détection et réponse aux incidents
- coordination avec les autorités
- accent sur la continuité de service
L’architecture soutient la préparation et la réactivité.
Architecture DORA
- la résilience opérationnelle comme objectif central
- gestion des incidents ICT étroitement intégrée à la gouvernance
- capacités de test et de récupération mises en avant
L’architecture soutient la résilience dès la conception.
Comparaison architecturale côte à côte
| Dimension | NIS2 | DORA |
|---|---|---|
| Portée réglementaire | Multisectorielle | Secteur financier |
| Rôle du CI/CD | Soutien à la livraison sécurisée | Système ICT réglementé |
| Application de la gouvernance | Organisationnelle et technique | Fortement technique |
| Modèle de preuves | Proportionnel, contextuel | Continu, basé sur les systèmes |
| Intensité de l’audit | Modérée à élevée | Très élevée |
| Focus chaîne d’approvisionnement | Large | Prestataires ICT critiques |
| Résilience opérationnelle | Requise | Objectif central |
Enseignements pratiques pour les architectes et les RSSI
- Les architectures NIS2 privilégient la gestion des risques et la préparation
- Les architectures DORA privilégient le contrôle continu et les preuves
- Les pipelines CI/CD sont en soutien sous NIS2, centraux sous DORA
- Les organisations soumises aux deux doivent concevoir des architectures de niveau DORA
Une architecture alignée sur DORA satisfait généralement les attentes de NIS2, mais l’inverse n’est pas toujours vrai.
L’enseignement architectural renforce l’analyse exigence par exigence : NIS2 et DORA partagent des principes communs mais divergent nettement en rigueur et en application. Là où NIS2 traite le pipeline CI/CD comme un système qui soutient la livraison sécurisée, DORA le traite comme un actif ICT réglementé qui doit générer des preuves continues et démontrables. Les architectures qui construisent le pipeline comme une couche d’application et de génération de preuves — plutôt que comme une commodité de livraison — sont les mieux placées pour satisfaire les deux cadres avec un minimum de duplication, ce qui est précisément l’objectif des recommandations pratiques qui suivent.
Recommandations pratiques pour les entités à double réglementation
Sur la base de l’analyse des chevauchements ci-dessus, les responsables conformité des entités à double réglementation devraient considérer l’approche suivante :
1. Construire sur DORA comme cadre principal
Étant donné que DORA est plus prescriptif pour la plupart des exigences liées aux ICT, utilisez la conformité DORA comme fondation. Cartographiez les exigences NIS2 par rapport à votre programme de conformité DORA pour identifier les lacunes plutôt que de construire deux programmes séparés.
2. Effectuer une analyse formelle des écarts
Documentez une cartographie exigence par exigence entre NIS2 et DORA pour votre organisation. Identifiez où la conformité DORA satisfait NIS2 (en tirant parti du principe lex specialis), où NIS2 ajoute des exigences au-delà de DORA et où les deux cadres nécessitent des preuves ou une documentation différentes.
3. Combler les lacunes spécifiques à NIS2
Pour les domaines où NIS2 va au-delà de DORA, mettez en œuvre des contrôles et une documentation supplémentaires. Les domaines clés susceptibles de nécessiter des mesures complémentaires incluent la sécurité de la chaîne d’approvisionnement non-ICT, la portée plus large des réseaux et systèmes d’information et les processus de divulgation des vulnérabilités.
4. Harmoniser les processus de signalement
Les obligations de signalement d’incidents diffèrent entre les cadres en termes de délais, d’autorités et de critères de classification. Établissez un processus unique de gestion des incidents qui peut satisfaire les deux ensembles d’exigences de signalement, avec des arbres de décision clairs pour savoir quelle autorité notifier et quand.
5. Maintenir un registre des risques unique
Ne maintenez pas de registres des risques séparés pour NIS2 et DORA. Utilisez un seul registre intégré des risques ICT et cyber qui étiquette les risques par réglementation applicable. Cela évite la duplication et assure un traitement cohérent des risques.
Ce que les auditeurs doivent vérifier pour la double conformité
Les auditeurs évaluant les entités à double réglementation doivent examiner :
- Documentation de cartographie : L’entité a-t-elle produit une cartographie formelle NIS2-DORA identifiant quel cadre s’applique à chaque domaine d’exigence ?
- Analyse des écarts : Y a-t-il des preuves d’une analyse structurée des écarts identifiant où les obligations NIS2 ne sont pas couvertes par la conformité DORA ?
- Justification lex specialis : Lorsque l’entité s’appuie sur le principe lex specialis, la justification est-elle documentée et défendable pour chaque exigence ?
- Évaluation du périmètre : L’entité a-t-elle évalué si certains de ses réseaux et systèmes d’information tombent en dehors du périmètre ICT de DORA mais dans le périmètre plus large de NIS2 ?
- Procédures de signalement d’incidents : L’entité a-t-elle des procédures claires pour déterminer quelles obligations de signalement s’appliquent aux différents types d’incidents ?
- Structure de gouvernance : L’organe de direction reçoit-il des rapports couvrant les obligations NIS2 et DORA, ou y a-t-il des angles morts de gouvernance ?
- Preuves de contrôles supplémentaires : Pour les exigences spécifiques à NIS2 non couvertes par DORA, des contrôles sont-ils en place et documentés ?
Ressources connexes
Pour une analyse plus approfondie des chevauchements réglementaires et de l’architecture de conformité, consultez :
- Architecture de double conformité expliquée
- Aperçu de la conformité DORA
- Aperçu de la conformité NIS2
Ressources connexes pour les auditeurs
- Glossaire — Définitions en langage clair des termes techniques
- DORA Article 21 — Analyse approfondie
- DORA Article 28 expliqué
- Checklist de préparation à l’audit
Nouveau dans l’audit CI/CD ? Commencez par notre Guide de l’auditeur.
