Votre certificat ISO 27001 ne déclenche pas les échéances de DORA

Une façon courante de démarrer un programme DORA consiste à utiliser une feuille de calcul. Une colonne liste les exigences du règlement (UE) 2022/2554, une autre les contrôles de l’annexe A de l’ISO/IEC 27001:2022 déjà mis en œuvre par l’entreprise dans son SMSI certifié, et une troisième enregistre les chevauchements. Une fois la cartographie terminée, le chevauchement est important : gestion des risques ICT, contrôle d’accès, gestion des fournisseurs, continuité d’activité, gestion des incidents. Le reste peut sembler se résumer à un exercice de rédaction s’appuyant sur un certificat existant.

Cette approche est un piège. Elle n’est pas fausse sur le chevauchement, qui est réel. En revanche, elle se trompe sur la nature du reste. Les parties de DORA qu’une entreprise certifiée ISO 27001 n’a pas encore mises en œuvre ne se limitent pas à de la documentation à rédiger. Plusieurs d’entre elles sont des obligations qui doivent être exécutées, selon une spécification et dans des délais précis, et un certificat est un instrument inadapté pour les prouver.

Un certificat atteste un système défini ; un règlement impose des obligations

L’ISO/IEC 27001:2022 certifie qu’un système de management de la sécurité de l’information (SMSI), défini par son périmètre, répond aux exigences de la norme. La certification n’est pas un événement ponctuel : un organisme certificateur délivre le certificat après un audit, et il est généralement maintenu sur un cycle de trois ans incluant des audits de surveillance et un renouvellement. Deux éléments l’accompagnent qui importent ici. L’objet certifié est un système de management, délimité par la déclaration de périmètre, et la question posée par la certification est celle de la conformité : le SMSI répond-il aux exigences ?

DORA n’est pas construit de cette manière. Il s’applique directement aux entités financières à partir du 17 janvier 2025 (règlement (UE) 2022/2554), et ses dispositions ne définissent pas un système de management auquel se conformer, mais des obligations à exécuter, dont plusieurs sont soumises à des échéances et des spécifications précises. Vous pouvez détenir un certificat ISO 27001 valide, couvrant le bon périmètre et à jour, et enfreindre DORA, car le certificat répond à une question que DORA ne pose pas. Trois des obligations de DORA reposent sur des échéances ou des spécifications qu’un certificat n’a jamais testées ; une quatrième transfère la responsabilité vers un domaine qu’un certificat n’a jamais vérifié.

Le registre

L’article 28(3) exige qu’une entité financière maintienne un registre des informations relatives à ses accords contractuels pour l’utilisation de services ICT fournis par des prestataires tiers, et qu’elle transmette des informations sur ces accords à son autorité compétente au moins une fois par an. Le registre est un artefact structuré, et non un document libre : le règlement d’exécution (UE) 2024/2956, publié au Journal officiel le 2 décembre 2024, établit les modèles standard et les champs de données. Selon les dispositions de reporting des Autorités européennes de surveillance (AES), les autorités compétentes collectent ensuite ces registres auprès des entités supervisées et les soumettent aux AES, la première collecte devant avoir lieu en 2025.

Une entreprise certifiée gère déjà ses fournisseurs ICT via les contrôles de l’annexe A, tels que A.5.19 à A.5.23, sélectionnés dans le cadre de son traitement des risques et consignés dans sa Déclaration d’applicabilité. Ce qui n’est pas produit en soi, c’est un registre conforme au schéma prescrit, rempli avec les champs de données DORA, aligné sur les contrats réels de l’entreprise, et transmissible à un superviseur selon le cycle de collecte. Gérer les fournisseurs et produire un artefact structuré spécifique à destination d’un régulateur sont des obligations distinctes, et la seconde n’est pas prouvée par la première.

L’échéance des incidents

L’article 19 oblige les entités financières à signaler les incidents ICT majeurs à l’autorité compétente, et la norme technique fixe les délais. Le règlement délégué (UE) 2025/301 du 23 octobre 2024 impose :

• une notification initiale dans les 4 heures suivant la classification de l’incident comme majeur,
• et, en règle générale, pas plus tard que 24 heures après que l’entité en a eu connaissance ;
• un rapport intermédiaire dans les 72 heures suivant cette notification initiale ;
• et un rapport final dans le mois suivant le rapport intermédiaire (ou le dernier rapport intermédiaire mis à jour).

La classification de l’incident comme « majeur » est déterminée par les critères du règlement délégué (UE) 2024/1772.

Le point de référence mérite d’être relu attentivement. L’échéance de 4 heures de DORA court à partir du moment où un incident est classé comme majeur, ce qui fait de la classification rapide et précise une partie intégrante de l’obligation, et non une étape préliminaire. Cette structure diffère des obligations de notification d’incidents que les équipes financières connaissent déjà : l’avertissement précoce de NIS2 doit être transmis dans les 24 heures suivant la prise de conscience d’un incident significatif (directive (UE) 2022/2555, article 23), et le RGPD exige qu’un responsable de traitement notifie une violation de données personnelles susceptible de porter atteinte aux droits des personnes sans retard injustifié, et si possible dans les 72 heures suivant sa prise de conscience (article 33). Ces échéances ne sont pas interchangeables. Dans le cadre des contrôles de l’annexe A A.5.24 à A.5.27, une entreprise certifiée planifie, évalue, répond et tire les leçons des incidents de sécurité de l’information via le processus qu’elle a mis en place, et un auditeur a accepté ce processus comme conforme. Le fait qu’un auditeur accepte que le processus soit conforme ne revient pas à dire que ce processus produit une notification réglementaire correctement classée dans les 4 heures suivant la classification.

L’obligation de test

L’article 26 exige que les entités financières identifiées par leur autorité compétente, sur la base de leur taille, de leur profil de risque et de leur importance systémique, réalisent des tests d’intrusion basés sur des menaces (TLPT) au moins tous les trois ans, sur des systèmes de production en direct supportant des fonctions critiques ou importantes. Les trois ans constituent un plancher que l’autorité compétente peut ajuster, et la méthodologie détaillée ainsi que les critères d’identification sont définis dans le règlement délégué (UE) 2025/1190, applicable à partir du 8 juillet 2025. Cette obligation ne concerne pas toutes les entités financières, et l’identification relève du régulateur. Mais pour une entreprise concernée, il s’agit d’une obligation récurrente, spécifique et devant être prouvée.

L’ISO/IEC 27001 demande à une entreprise de surveiller, mesurer et évaluer les performances de son SMSI (article 9.1) et de réaliser des audits internes (article 9.2), et le contrôle A.8.29 de l’annexe A couvre les tests de sécurité dans le développement et l’acceptation. Aucun de ces éléments, à lui seul, ne prouve qu’un exercice de red team basé sur le renseignement, mené contre des systèmes de production, répété selon la cadence DORA et exécuté selon la méthodologie de supervision, a été réalisé. Une entreprise peut être pleinement certifiée sans en avoir jamais effectué.

La responsabilité que le certificat n’atteint pas

L’article 5(2) place sur l’organe de direction l’obligation de définir, approuver, superviser et être responsable du cadre de gestion des risques ICT, et le point (a) lui impose d’« assumer la responsabilité ultime de la gestion des risques ICT de l’entité financière ». L’article 5(4) ajoute une obligation personnelle : les membres de l’organe de direction doivent maintenir leurs connaissances et compétences à jour pour comprendre et évaluer les risques ICT. Il s’agit de la seule des quatre obligations qui n’est pas soumise à une échéance. C’est une obligation continue de gouvernance.

L’ISO/IEC 27001 (article 5.1) exige déjà un leadership et un engagement de la direction, ce qui en fait la zone de chevauchement la plus étroite. L’écart est plus étroit et plus spécifique que l’idée selon laquelle « ISO ignore le conseil d’administration ». DORA fixe la responsabilité ultime sur l’« organe de direction », un terme juridiquement défini, et impose une obligation de compétence personnelle à ses membres. Le « top management » de l’ISO et l’« organe de direction » de DORA ne sont pas nécessairement les mêmes personnes, et la certification démontre un engagement du leadership envers le SMSI, mais pas la conformité avec l’article 5(2)(a) ou l’article 5(4). Un certificat peut être obtenu sans que la responsabilité spécifique nommée par DORA n’ait jamais été testée.

Pourquoi la cartographie masque ces quatre obligations

La feuille de calcul échoue de manière constante : elle compare le texte d’un contrôle à celui d’un autre, et le poids supplémentaire de DORA ne réside pas uniquement dans le texte. Un contrôle énonce « l’organisation doit gérer les incidents de sécurité de l’information », et les preuves ISO de l’entreprise le confirment également, donc les cellules correspondent. Ce que la cellule ne montre pas, c’est que DORA a attaché :

• une échéance de référence à 4 heures,
• un schéma de registre prescrit,
• une obligation de test au moins tous les trois ans,
• et un organe responsable juridiquement désigné, à des activités que l’ISO décrit comme des capacités. Deux exigences peuvent utiliser des termes presque identiques et pourtant être satisfaites par des actes différents, car l’une demande si un système conforme existe dans un périmètre, et l’autre si une obligation spécifique a été exécutée.

C’est cette objection qu’il faut prendre au sérieux, et c’est elle qui maintient de nombreux programmes sur la voie de la simple documentation. Selon l’argument, l’annexe A couvre déjà la gestion des incidents, la gestion des fournisseurs et les tests, donc DORA n’est qu’une substance identique avec un emballage de conformité. La réponse est qu’une spécification et une échéance ne sont pas un emballage autour d’un contrôle. Un point de référence, un format de soumission, une cadence de test ajustable et une responsabilité légale nommée sont de nouvelles obligations que l’existence d’un contrôle ne dispense pas, et ce sont précisément celles que la cartographie contrôle-à-contrôle rend invisibles.

La règle à conserver

Lorsque vous cartographiez une certification sur un règlement, cartographiez les obligations opérationnelles, et non le texte des contrôles. Un certificat atteste qu’un système de management répond à une norme, dans un périmètre, sur un cycle d’audit. Un règlement énonce ce que ce système doit faire, selon quelle spécification et dans quel délai. Lorsque les deux décrivent la même activité, vérifiez si le règlement a attaché :

• un point de référence avec une échéance,
• un format,
• une cadence,
• ou une responsabilité nommée, car ce sont ces éléments que la cartographie contrôle-à-contrôle rend invisibles et que le superviseur est susceptible de tester.

Cette discipline de lecture s’applique au-delà de DORA, bien que les détails diffèrent selon le régime. NIS2 exige que les États membres imposent aux entités concernées des obligations de gouvernance de l’organe de direction (directive (UE) 2022/2555, article 20) et une obligation d’avertissement précoce sous 24 heures (article 23), pour des activités déjà couvertes par des contrôles existants. Le règlement sur la cybersécurité (CRA) attache des obligations de signalement dans des délais précis des vulnérabilités exploitées activement et des incidents graves aux fabricants de produits avec éléments numériques, ces obligations s’appliquant à partir du 11 septembre 2026 (règlement (UE) 2024/2847, article 14). Les modèles de responsabilité ne sont pas identiques, mais la discipline de lecture est la même : trouvez le verbe, trouvez l’échéance ou la spécification, et traitez chaque obligation avec une échéance ou un destinataire défini comme une obligation opérationnelle plutôt que comme un document à rédiger.

Si votre tâche immédiate consiste à séparer le véritable chevauchement entre ISO 27001 et DORA des obligations soumises à des échéances et des spécifications qu’un certificat ne prouve pas, cette corrélation croisée avec les articles et normes techniques réels est le type de travail que ISMS Copilot est conçu pour soutenir. Un large chevauchement dans la cartographie est réel. Il constitue également des preuves réutilisables qui nécessitent toujours une validation spécifique à DORA, et non une conformité que vous pourriez appliquer telle quelle – c’est pourquoi ce n’est pas la partie qui doit façonner le plan.

Il s’agit d’une analyse pratique de conformité, et non de conseils juridiques. Confirmez le périmètre et les obligations de votre entité en vous référant au règlement et à ses normes techniques, et, le cas échéant, à votre autorité compétente ou à un conseiller juridique.