DORA et NIS2 : Pourquoi les audits bancaires entrent en collision

11 Min. de lecture

Depuis janvier 2025, DORA est applicable, depuis novembre 2025, AWS, Azure, Google Cloud, Bloomberg, LSEG et IBM figurent sur la liste CTPP des ESAs. Au premier trimestre 2026, les équipes d’audit conjoint effectueront leurs premières inspections. Parallèlement, NIS2 progresse en vague deux. En 2026, il devient clair : les deux réglementations s’entrecroisent, leurs parcours d’audit se déroulent en parallèle.

Les points clés en bref

Une double application ne signifie pas un double audit, mais un audit imbriqué. DORA vérifie chez les institutions financières le risque ICT, les incidents, les tests et la chaîne d’approvisionnement tierce. NIS2 examine, quant à lui, chez les entités jugées essentielles ou importantes la gestion des risques, les obligations de notification et les responsabilités. Là où les banques sont des destinataires de NIS2, les obligations s’additionnent, elles ne se substituent pas.
2026 est l’année de la charge de preuve, pas celle de la politique. Les ESAs déplacent l’attente du papier vers la preuve concrète. Tests de résilience, exercices TLPT, classification des incidents avec des seuils stricts et inventaires des fournisseurs tiers sous forme machine-lisible. Celui qui a mis en place les politiques en 2025, mais n’apporte pas les preuves nécessaires en 2026, sera sanctionné lors de l’audit.
Le goulot d’étranglement critique n’est pas dans les outils, mais dans les auditeurs. Dans les douze derniers mois, les flux ICT-Risque, NIS2 et DORA ont été généralement couverts par des équipes d’audit partiellement recouvrantes. Qui tente de gérer les deux programmes avec une même équipe d’audit de 30 personnes, connaîtra un point de tension au troisième trimestre, qu’aucun outil ne pourra résoudre.

ReliéConformité NIS2 dans le milieu des PME / Exigences techniques minimales NIS2 pour les PME

Ce qui distingue DORA et NIS2 en 2026, année de leur coexistence

DORA et NIS2 semblent, à première vue, être les deux faces d’un même programme de conformité. Les deux réglementent la gestion des risques ICT, la notification des incidents et les relations avec les fournisseurs tiers ; les deux proviennent de la vague cyber de l’UE ; les deux prévoient des amendes. En pratique, en 2026, ils divergent nettement selon trois critères : cercle des destinataires, structure de supervision et profondeur des exigences.

DORA s’applique à 20 types d’entités financières, allant des banques et des assureurs jusqu’aux prestataires de services crypto et aux contreparties centrales. La supervision est assurée par les autorités nationales de surveillance financière, clairement rattachées aux ESAs, soit en Allemagne BaFin avec interface vers EBA, EIOPA et ESMA. NIS2, quant à lui, s’adresse aux entités essentielles et importantes traversant 18 secteurs différents, avec le BSI comme autorité centrale de supervision en Allemagne. Une grande banque est à la fois concernée par DORA et par NIS2, un gestionnaire d’actifs ne l’est que par DORA selon sa taille, un fournisseur cloud principalement par NIS2.

Les métriques classiques de conformité ne sont pas fausses, elles ne constituent toutefois plus qu’une partie du tableau. Ce qui distingue un audit DORA d’un audit NIS2, c’est la profondeur des preuves attendues dans le domaine ICT : DORA exige des rapports solides sur les tests de pénétration, la documentation des tests de résilience, un registre contractuel des fournisseurs tiers sous format machine-lisible. NIS2 demande des mesures de gestion des risques axées sur la gouvernance et les obligations de notification. Les deux relèvent de la cybersécurité, mais les artefacts requis ne se chevauchent qu’en partie.

Réalité 1 : Le programme commun qui ne tient pas la route

De nombreuses banques ont lancé en 2025 un programme de conformité consolidé réunissant DORA et NIS2 sous un même toit. La logique semblait bonne : un seul management des risques, un seul système de déclaration d’incident, un seul inventaire des fournisseurs tiers, une seule équipe d’audit. En pratique, deux logiques s’affrontent. Les audits DORA plongent dans le détail des composants ICT et des tests, tandis que les audits NIS2 couvrent l’ensemble du dispositif de gouvernance et des voies de déclaration. Un responsable programme unique se partage entre ces deux univers et perd le niveau de précision exigé par DORA.

Exemple concret tiré d’une grande banque anonymisée des pays germanophones : un programme avec 32 spécialistes des risques ICT et un PMO centralisé. Au premier trimestre 2026, 14 tests TLPT ont été préparés tout en programmant simultanément 22 revues du management des risques NIS2. En avril, le PMO du programme a priorisé la préparation des tests TLPT, puis en mai les revues NIS2. Dans les deux phases, l’équipe d’audit n’a pas atteint le niveau de détail accepté par aucune autorité de contrôle. Les deux axes sont maintenant confrontés à des constats qu’on aurait pu éviter avec deux programmes distincts.

Réalité 2 : Les deux programmes séparés qui ne partagent pas leur base de données

L’autre extrême consiste à créer deux lignes de programme distinctes : une équipe DORA axée sur les risques ICT, une équipe NIS2 centrée sur la gouvernance, chacune disposant de ses propres outils et de ses propres voies de reporting. Une approche méthodologiquement propre, mais inefficace en matière de gestion des données. Les deux programmes utilisent le même inventaire d’actifs, la même liste de fournisseurs, les mêmes données d’incidents. Sans une base de données commune, ils doivent gérer ces sources en double, entraînant inévitablement des divergences.

Conséquence typique : dans l’inventaire des fournisseurs tiers DORA figure AWS avec 47 composants de service, alors qu’il n’en est comptabilisé que 39 dans le registre des fournisseurs NIS2. Aucune des deux valeurs n’est fausse, elles mesurent simplement des granularités différentes. Si la régulation souhaite voir les deux listes lors de l’audit JET et constate des écarts, cela déclenche une série d’explications qui allongent l’audit de deux semaines. Une base de données commune offrant deux points de vue résoudrait ce problème. Deux bases de données mises à jour une fois par an ne suffisent pas.

Réalité 3 : L’équipe d’audit qui bascule au troisième trimestre

Le point critique en 2026 n’est ni l’outil, ni la méthode, ni le sponsor. C’est la capacité humaine au sein de l’équipe d’audit. Les experts en risques ICT expérimentés en DORA manquent cruellement, tout comme les auditeurs de conformité NIS2 dotés d’une expertise approfondie en cadres de gestion des risques. Les banques ont généralement recouvert les postes dans les douze derniers mois : trois quarts de l’équipe travaillent sur les deux axes, un quart reste fixe dans une seule ligne.

Cela fonctionne jusqu’à l’intensification des audits. Nous observons en 2026 un schéma clair : la phase TLPT et la préparation JET au deuxième trimestre, parallèlement aux dates limites de reporting NIS2 au troisième. L’équipe d’audit donne le maximum dans les deux phases, mais six personnes clés sont épuisées ou remplacées au troisième trimestre. La livraison planifiée pour le quatrième trimestre est repoussée, et la prochaine session de contrôle débute avec une équipe moitié plus petite.

La limite cruciale est la cohérence sur plusieurs années. Qui applique DORA et NIS2 avec une mentalité de sprint de six mois gagne les jalons trimestriels, mais rate l’organisation sur une période de douze mois. Celui qui pense en termes de responsabilités clairement séparées dans les deux programmes et adopte un plan de capacités sur 18 mois évite le crash du troisième trimestre.

Trois leviers concrets pour les prochains 90 jours

Planifier la capacité de l’équipe d’audit sur 18 mois, pas six. Établir une liste des pénuries humaines trimestrielles jusqu’au T4 2027. Où les préparations DORA-TLPT coïncident-elles avec les dates limites de reporting NIS2 ? Quelles sont les six personnes critiques jouant des rôles centraux dans les deux axes ? Prévoir leur soutien avant qu’il ne devienne une urgence.
Créer une base de données unique avec deux vues, pas deux bases à concilier. L’inventaire des actifs, le registre des fournisseurs tiers et les données d’incidents ne peuvent être dupliqués dans deux outils distincts. Une source centrale, équipée de vues spécifiques DORA et NIS2, est l’investissement qui paiera ses dividendes dès le premier audit JET.
Séparer clairement les responsabilités des programmes, partager la base de données et les outils. Un chef de programme DORA spécialisé dans les risques ICT, un chef de programme NIS2 expert en gouvernance, tous deux reposant sur une base de données commune. Qui combine les deux rôles en une seule personne obtiendra des audits dont aucune des deux autorités de contrôle ne reconnaîtra la profondeur.

Foire aux questions

Toutes les banques ciblées par DORA sont-elles aussi destinataires de NIS2 ?

En pratique oui, en forme différentiée. La plupart des banques sont couvertes sous NIS2 en tant qu’entités essentielles en raison de leur taille. Des gestionnaires d’actifs plus petits et des prestataires de services financiers spécialisés peuvent être ciblés par DORA sans devenir pour autant destinataires de NIS2. Dans la pratique de la conformité en 2026, la double cible est la règle, pas l’exception.

Quelle différence y a-t-il entre un test TLPT DORA et un test classique de type Red Team ?

DORA-TLPT exige un test de pénétration mené selon des standards harmonisés et avec une participation claire des autorités de surveillance. Le red teaming classique est méthodiquement similaire, mais il n’est pas encadré par le cadre réglementaire qui accompagne DORA-TLPT. Qui possède un programme Red Team en 2026 et le présente comme un TLPT tombera à la première vérification JET. Les artefacts requis et le workflow de supervision ne sont pas identiques.

Quel rôle joue la BaFin pour les banques allemandes lors de l’audit DORA ?

La BaFin est l’autorité nationale compétente et collabore avec les ESAs au sein des équipes d’examen conjoint (JET). Cela signifie pour les banques allemandes : l’interface directe reste la BaFin, mais les ESAs participent aux inspections JET et peuvent demander directement des constats. L’idée que les audits DORA restent exclusivement nationaux n’est plus soutenable en 2026.

Comment réagissent les fournisseurs cloud désignés CTPP face à la surveillance ?

AWS, Microsoft Azure et Google Cloud ont mis en place ces derniers mois des équipes dédiées à DORA et proposent à leurs clients du secteur financier des kits de conformité structurés. En 2026, la qualité de ces kits varie. Une banque qui adopte ces kits sans vérification interne risque de voir apparaître des constats liés à la profondeur de l’hébergement, qui n’est pas couverte dans les paquets fournis par les fournisseurs.

À quel moment faut-il envisager de découpler un programme consolidé ?

Lorsque les constats d’audit des deux autorités tombent dans la même division organisationnelle et que l’escalade vers la direction du programme prend plus de trois semaines. C’est un indicateur que la structure commune n’est plus viable. Un découplage au milieu du programme est coûteux, mais un découplage à la fin du programme est encore plus onéreux.