Programme de tests DORA : cartographier les tests avec ISO 27001

Nous sommes en février 2026. Le RSSI d’un établissement de paiement de taille intermédiaire a une réunion du conseil d’administration dans deux jours, un audit de surveillance ISO/IEC 27001:2022 dans six semaines et une demande de l’autorité de contrôle DORA dans la boîte de réception de l’équipe conformité.

Le régulateur ne demande pas une stratégie cyber brillante sur papier glacé. Sa demande est opérationnelle :

• Fournir le programme de tests de résilience opérationnelle numérique 2026.
• Montrer quels tests couvrent les fonctions critiques ou importantes.
• Démontrer comment les constats sont corrigés puis soumis à retest.
• Fournir les éléments probants de la supervision par l’organe de direction.
• Expliquer comment les prestataires tiers de services TIC sont intégrés.
• Fournir les enregistrements relatifs aux évaluations de vulnérabilités, aux tests fondés sur des scénarios, aux tests de performance et de capacité, ainsi qu’aux tests d’intrusion.

Le RSSI ouvre quatre dossiers. Les scans de vulnérabilités sont dans l’outil de tickets du SOC. Les notes des exercices sur table sont sur un lecteur partagé. Les résultats des tests de charge sont détenus par l’ingénierie. Les rapports de tests d’intrusion sont dans le référentiel restreint du service juridique. Le suivi des remédiations est réparti entre Jira, des courriels et un tableur créé pour l’audit ISO de l’année précédente.

Rien n’est fictif. Une grande partie du travail est de qualité. Mais ce n’est pas encore un programme de tests de résilience opérationnelle numérique DORA gouverné. C’est une collection de tests.

Cette différence compte en 2026. DORA s’applique depuis le 17 janvier 2025 et établit un cadre uniforme de l’UE pour la résilience opérationnelle numérique couvrant la gestion des risques liés aux TIC, la notification des incidents, les tests de résilience, le partage d’informations sur les cybermenaces et les vulnérabilités, la gestion des risques liés aux prestataires tiers de services TIC, les exigences contractuelles et la supervision des prestataires tiers critiques de services TIC. Il couvre un large éventail d’entités financières, notamment les établissements de crédit, les établissements de paiement, les entreprises d’investissement, les prestataires de services sur crypto-actifs, les entreprises d’assurance et d’autres entités réglementées. DORA constitue également l’acte juridique sectoriel de l’Union applicable aux entités financières qui relèveraient autrement d’obligations équivalentes de cybersécurité au titre de NIS2.

La question pratique pour les conseils d’administration, les RSSI, les responsables conformité et les prestataires de services TIC n’est plus de savoir si des tests ont lieu. La question est de savoir si les tests sont planifiés, fondés sur les risques, documentés par des éléments probants, corrigés, revus et réutilisables entre DORA et ISO/IEC 27001:2022.

Le modèle opérationnel de Clarysec répond précisément à cette difficulté. Avec le Zenith Blueprint : feuille de route d’auditeur en 30 étapes, la suite de politiques Clarysec alignée sur ISO et Zenith Controls : le guide de conformité multi-référentiels, les organisations peuvent transformer des activités de résilience dispersées en un catalogue annuel de tests maîtrisé, exploitable par les superviseurs, les auditeurs, les clients et les conseils d’administration.

Pourquoi DORA transforme les tests en enjeu de gouvernance

DORA est explicite sur la responsabilité de la direction. L’Article 5 attribue à l’organe de direction la responsabilité de la gestion des risques liés aux TIC. L’Article 6 exige un cadre de gestion des risques liés aux TIC solide, complet et bien documenté, intégré au système global de gestion des risques de l’organisation. L’Article 4 introduit le principe de proportionnalité, selon lequel les exigences doivent être appliquées en fonction de la taille, du profil de risque global ainsi que de la nature, de l’échelle et de la complexité des services, activités et opérations.

Les tests de résilience opérationnelle numérique ne sont donc plus une simple tâche technique. Ils deviennent des éléments probants montrant que l’organe de direction comprend les risques, a approuvé une stratégie, reçoit un reporting pertinent et pilote la remédiation.

ISO/IEC 27001:2022 repose sur une logique similaire de système de management. Les clauses 4.1 à 4.4 exigent que l’organisation comprenne son contexte, les parties intéressées, les obligations légales et contractuelles, le périmètre, les interfaces et les dépendances. Les clauses 5.1 à 5.3 exigent le leadership, l’alignement de la politique, les ressources, la communication, l’attribution des responsabilités et le reporting à la direction. La clause 6.1 exige l’appréciation des risques de sécurité de l’information et le traitement des risques.

Un programme de tests DORA doit donc relier :

• Les services métier et les fonctions critiques ou importantes
• Les actifs TIC, les données et les dépendances vis-à-vis de tiers
• L’appréciation des risques, les propriétaires du risque et les plans de traitement des risques
• Les types de tests, leur fréquence et leurs déclencheurs
• L’autorisation, l’indépendance et les règles d’engagement
• Les constats, les échéances de remédiation et les retests
• La conservation des éléments probants et le contrôle d’accès
• Le reporting de direction et l’amélioration continue

Pour les entités financières plus petites ou présentant un risque plus faible, l’Article 16 prévoit un cadre simplifié de gestion des risques liés aux TIC, mais simplifié ne signifie pas informel. Même les programmes proportionnés doivent encore prévoir une gestion documentée des risques liés aux TIC, une surveillance, des systèmes résilients, l’identification des sources de risque TIC et des anomalies, les principales dépendances vis-à-vis de prestataires tiers de services TIC, des mesures de continuité et de reprise, des tests réguliers et le retour d’expérience.

Autrement dit, DORA ne récompense pas le volume de tests. Il valorise des tests gouvernés et fondés sur les risques, capables de démontrer la résilience des services les plus importants.

Que doit contenir un programme de tests DORA 2026 ?

Un programme de tests DORA mature doit fonctionner comme un catalogue annuel de tests. Il ne doit pas se limiter à un test d’intrusion annuel ni à une pile d’exports de scans de vulnérabilités. Il doit inclure des tests de base et avancés, planifiés selon les risques, la criticité des services, les obligations réglementaires, les dépendances fournisseurs, les changements majeurs et les constats antérieurs.

L’Article 24 de DORA établit le programme de tests de résilience opérationnelle numérique. L’Article 25 décrit un ensemble de tests, notamment les évaluations et scans de vulnérabilités, les analyses open source, les évaluations de sécurité réseau, les analyses d’écarts, les revues de sécurité physique, les questionnaires, les solutions logicielles de scan, les revues de code source lorsque cela est possible, les tests fondés sur des scénarios, les tests de compatibilité, les tests de performance, les tests de bout en bout et les tests d’intrusion. L’Article 26 ajoute les tests d’intrusion fondés sur la menace pour les entités financières désignées par les autorités compétentes.

Pour la plupart des organisations, le catalogue opérationnel repose sur quatre familles de tests.

La Politique de tests de sécurité et de red teaming de Clarysec fournit un point d’ancrage solide pour ce catalogue :

“Types de tests : le programme de tests de sécurité doit inclure, au minimum : (a) des scans de vulnérabilités, consistant en des scans automatisés hebdomadaires ou mensuels des réseaux et applications afin d’identifier les vulnérabilités connues ; (b) des tests d’intrusion, consistant en des tests manuels approfondis de systèmes ou applications spécifiques par des testeurs qualifiés afin d’identifier des faiblesses complexes ; et (c) des exercices de red teaming, consistant en des simulations fondées sur des scénarios d’attaques réelles, y compris l’ingénierie sociale et d’autres tactiques, afin de tester les capacités globales de détection et de réponse de l’organisation.”

La même politique impose une planification régulière :

“Calendrier des tests : l’organisation doit réaliser des tests de sécurité selon un calendrier régulier. Les principaux systèmes exposés à Internet et les applications internes critiques doivent faire l’objet de tests d’intrusion au moins une fois par an. Les changements à haut risque, tels que le déploiement d’un nouveau système critique ou des mises à niveau majeures, nécessitent des tests ad hoc avant et/ou peu après la mise en production.”

C’est essentiel pour DORA. Un plan annuel statique ne suffit pas si l’entité déploie une nouvelle passerelle de paiement, migre un système cœur vers le cloud, change de prestataire de services managés ou publie un nouveau parcours d’authentification client. Tout changement à haut risque doit déclencher des tests complémentaires.

Construire le catalogue annuel de tests comme source unique de vérité

La méthode la plus efficace pour satisfaire DORA et ISO/IEC 27001:2022 consiste à créer un catalogue annuel de tests unique et maîtrisé. Il peut résider dans une plateforme GRC, un workflow de tickets ou un tableur contrôlé. Le format importe moins que la traçabilité.

Chaque test doit répondre à cinq questions d’audit :

1. Quel service, actif, fournisseur, application ou processus a été testé ?
2. Quel risque, obligation ou exigence de contrôle a déclenché le test ?
3. Qui a autorisé et réalisé le test ?
4. Quels constats ont été identifiés, acceptés, corrigés ou différés ?
5. Quels éléments probants démontrent que le test a eu lieu et que le résultat a été revu ?

Un catalogue pratique dans l’esprit Clarysec comprend les champs suivants.

La Politique d’audit et de surveillance de la conformité - PME de Clarysec fournit une règle de gouvernance concise adaptée à cette structure :

“Chaque audit doit comprendre un périmètre défini, des objectifs, des personnes responsables et les éléments probants requis.”

Bien qu’elle soit rédigée pour les audits, la même règle doit s’appliquer aux tests de résilience. Si un scan de vulnérabilités, un exercice sur table, une simulation de basculement ou un test d’intrusion n’a pas de périmètre, d’objectif, de responsable et d’éléments probants requis définis, il sera faible au regard des exigences d’audit DORA comme ISO.

La même politique précise :

“Les éléments probants doivent être conservés pendant au moins deux ans, ou plus longtemps lorsque la certification ou les accords clients l’exigent.”

Pour les entités financières et prestataires de services TIC soumis à DORA, deux ans doivent être considérés comme un minimum. Les obligations contractuelles, les attentes prudentielles, les cycles de certification et les investigations d’incident peuvent imposer une conservation plus longue.

Cartographier les types de tests DORA avec les éléments probants ISO 27001

La force d’un programme intégré tient au fait qu’un même test peut satisfaire plusieurs obligations. L’essentiel est de baliser correctement les éléments probants et de les relier au SMSI.

Le Zenith Blueprint l’explique dans la phase Audit, revue et amélioration, étape 24 :

“Votre SoA doit être cohérente avec votre registre des risques et votre plan de traitement des risques. Vérifiez que chaque contrôle choisi comme traitement du risque est marqué comme « Applicable » dans la SoA.”

Pour un programme de tests DORA, le catalogue de tests devient le pont entre le traitement des risques et les éléments probants opérationnels. La Déclaration d’applicabilité ne doit pas indiquer qu’un contrôle s’applique alors que les éléments probants de test se trouvent ailleurs, sans cartographie ni maîtrise.

Ce tableau aide un RSSI à répondre à une question fréquente du Directeur général : « Nos tests d’intrusion et scans de vulnérabilités ISO suffisent-ils pour DORA ? »

La réponse est : ils peuvent faire partie de la conformité DORA, mais seulement s’ils sont fondés sur les risques, reliés aux fonctions critiques ou importantes, encadrés par une politique, suivis jusqu’à la remédiation et reportés à la direction.

Évaluations de vulnérabilités : des éléments probants continus, pas seulement des résultats de scans

L’évaluation de vulnérabilités est souvent l’activité de test la plus facile à exécuter et la plus facile à mal gérer. Beaucoup d’organisations peuvent produire des rapports de scan. Moins nombreuses sont celles capables de démontrer que les scans couvrent les bons actifs, priorisent les services critiques, déclenchent une remédiation dans les délais et alimentent les décisions de traitement des risques.

La Politique de gestion des vulnérabilités et des correctifs - PME de Clarysec commence par le bon objectif :

“Identifier et évaluer les vulnérabilités connues sur l’ensemble des actifs informatiques, de manière rapide et cohérente”

Pour DORA, cela soutient l’identification des sources de risque TIC, la résilience et l’actualisation des systèmes, la surveillance, la détection d’anomalies et l’amélioration continue. Pour ISO/IEC 27001:2022, cela se rattache directement à 8.8 Gestion des vulnérabilités techniques et s’appuie également sur 5.9 Inventaire de l’information et des autres actifs associés, 8.16 Activités de surveillance et 8.32 Gestion des changements.

Un enregistrement robuste d’évaluation de vulnérabilités doit inclure :

• L’instantané de l’inventaire des actifs utilisé pour définir le périmètre
• La date du scan, l’outil utilisé et la méthode authentifiée ou non authentifiée
• Les exclusions et leur justification métier
• Les constats par gravité, exploitabilité et service métier
• La cartographie avec les fonctions critiques ou importantes et les types de données
• Les références de tickets et le propriétaire du risque
• Le SLA de remédiation et la date d’échéance
• Le résultat du retest
• Les exceptions avec approbation du risque résiduel

Zenith Controls positionne 8.8 Gestion des vulnérabilités techniques comme un domaine central d’éléments probants pour l’identification, l’évaluation, la priorisation et le suivi de la remédiation. Il montre aussi pourquoi les auditeurs testeront les processus adjacents. Si l’inventaire des actifs est incomplet, la couverture des vulnérabilités l’est aussi. Si la gestion des changements est contournée, le déploiement des correctifs peut créer un nouveau risque opérationnel. Si la surveillance est faible, les tentatives d’exploitation peuvent ne pas être détectées.

Tests de scénarios : démontrer la prise de décision avant le véritable incident

Les tests de scénarios rendent la résilience opérationnelle visible pour les dirigeants. Un exercice sur table de rançongiciel, une simulation d’indisponibilité d’une région cloud, un exercice de compromission d’accès à privilèges ou un scénario de défaillance d’un prestataire critique de services TIC révélera des faiblesses qu’un scan ne peut pas détecter.

Les Articles 17 à 20 de DORA exigent un cycle de vie formel des incidents liés aux TIC : détecter, gérer, notifier, enregistrer, surveiller, traiter, assurer le suivi, documenter la cause racine, remédier, classifier la gravité, attribuer les rôles, escalader les incidents majeurs et effectuer les notifications aux étapes requises. Lorsque les intérêts financiers des clients sont affectés, ceux-ci doivent être informés sans retard indu.

NIS2 impose une urgence comparable aux entités relevant de son champ d’application, notamment l’alerte précoce, la notification, le rapport intermédiaire et le rapport final. Pour les entités financières concernées, DORA est l’acte juridique sectoriel applicable aux obligations équivalentes de gestion des risques de cybersécurité et de notification. Les prestataires de services TIC, plateformes SaaS, MSP et MSSP doivent toutefois vérifier s’ils relèvent directement du champ de NIS2 ou s’ils sont contractuellement intégrés aux exigences d’assurance DORA de leurs clients réglementés.

Le Zenith Blueprint, dans la phase Contrôles en action, étape 23, fournit le modèle pratique des éléments probants :

“Sélectionnez un événement récent ou réalisez un exercice sur table pour valider votre plan. Capturez et journalisez toutes les décisions, les rôles et les communications (5.26), puis mettez le plan à jour avec les enseignements tirés (5.27).”

Un test de scénario DORA doit produire des enregistrements auditables, pas seulement des notes de réunion :

• Brief de scénario et objectifs
• Participants et rôles, notamment Juridique, Communications, IT, SOC, responsable métier et contacts fournisseurs
• Chronologie des injects et des décisions
• Décision de classification et analyse des seuils de notification
• Projets de communications internes et externes
• Actions de préservation des éléments probants
• Retours d’expérience
• Responsables d’action et dates d’échéance
• Procédures d’incident, de continuité ou de communication mises à jour

La Politique de continuité d’activité et de reprise après sinistre - PME de Clarysec renforce l’exigence de tests annuels :

“L’organisation doit tester au moins une fois par an ses capacités de PCA et de PRA. Les tests doivent inclure :”

Le catalogue de tests doit traduire cette obligation en exercices précis, tels qu’un exercice sur table de gestion de crise, un test de restauration de sauvegarde, un test de basculement cloud, un test de l’arbre d’appel et une simulation de perturbation fournisseur.

Tests de performance, de capacité et de reprise : les éléments probants de résilience trop souvent négligés

Les tests de performance sont souvent considérés comme une préoccupation d’ingénierie. Dans le cadre de DORA, ils deviennent des éléments probants de résilience.

Une plateforme de négociation, un service de paiement, un système de gestion des sinistres, une plateforme d’identité ou un portail client n’a pas besoin d’une cyberattaque pour mettre les clients en échec. L’épuisement de capacité, la saturation de files d’attente, les goulets d’étranglement de bases de données, une autoscaling mal configurée ou un basculement défaillant peuvent produire la même perturbation opérationnelle qu’un incident de sécurité.

L’Annexe A 8.6 d’ISO/IEC 27001:2022, Gestion de la capacité, constitue l’ancrage principal. Les éléments probants peuvent inclure des tests de charge, des tests de stress, des tests de dégradation de service, la validation des seuils d’infrastructure, des tests de restauration de sauvegarde et des simulations de basculement.

Un bon enregistrement de test de performance et de capacité doit consigner :

• Les hypothèses de charge normale de référence et de pic de charge
• Les parcours transactionnels critiques testés
• Les limites d’infrastructure et de cloud testées
• Les tableaux de bord de surveillance et les seuils d’alerte
• Les modes de défaillance, tels que la saturation de files d’attente ou les goulets d’étranglement de bases de données
• La pertinence du RTO et du RPO lorsque le basculement ou la reprise est testé
• L’impact métier en cas de dépassement des seuils
• Les actions de remédiation, décisions de mise à l’échelle ou changements d’architecture
• L’acceptation par la direction du risque résiduel de capacité

Le Zenith Blueprint, étape 23, relie les attentes de reprise aux éléments probants :

“Vérifiez que les objectifs de temps de reprise (RTO) et les objectifs de point de reprise (RPO) des systèmes critiques sont alignés sur les attentes de continuité d’activité (5.30). Réalisez au moins un test technique de reprise ou une simulation de basculement et documentez les résultats.”

C’est toute la différence entre dire « nous avons des sauvegardes » et prouver qu’un service critique a été restauré dans la tolérance convenue, avec des résultats documentés et une visibilité pour la direction.

Tests d’intrusion et red teaming : des éléments probants solides exigent une gouvernance solide

Les tests d’intrusion constituent des éléments probants de grande valeur, mais comportent aussi un risque opérationnel. Des tests mal gouvernés peuvent affecter les systèmes de production, exposer des données sensibles, déclencher des alertes non maîtrisées, créer des enjeux juridiques ou perturber les clients.

La Politique relative aux exigences de sécurité des applications - PME fixe un point de contrôle clair avant mise en production :

“Avant le déploiement, toutes les applications doivent faire l’objet de tests de sécurité afin de vérifier les fonctionnalités de référence listées ci-dessus.”

Pour les applications critiques, cela doit alimenter le catalogue DORA sous forme de tests de sécurité en environnement de pré-production, de validation post-mise en production pour les changements à haut risque et de tests d’intrusion périodiques fondés sur l’exposition et la criticité.

La Politique de tests de sécurité et de red teaming renforce la chaîne de remédiation :

“Remédiation des constats : toutes les vulnérabilités ou faiblesses identifiées doivent être documentées dans un rapport de constats avec des niveaux de gravité. À réception du rapport, les propriétaires de systèmes sont responsables de l’établissement d’un plan de remédiation avec des dates d’échéance ; par exemple, les constats critiques doivent être corrigés sous 30 jours et les constats de gravité élevée sous 60 jours, conformément à la Politique de gestion des vulnérabilités et des correctifs de l’organisation. Le STC doit suivre l’avancement de la remédiation. Des retests doivent être réalisés afin de confirmer que les problèmes critiques ont été résolus ou suffisamment atténués.”

La même politique définit les attentes de reporting :

“Reporting : un rapport formel doit être émis à la clôture de chaque test. Pour les tests d’intrusion, le rapport doit inclure un résumé à l’attention de la direction, la méthodologie et les constats détaillés accompagnés des éléments probants et recommandations.”

Le Zenith Blueprint, étape 21, souligne également la protection pendant les audits et les tests :

“Aucun test ou audit ne doit commencer sans approbation documentée des propriétaires de systèmes ou des parties prenantes concernées.”

Les règles d’engagement, les fenêtres de test, les contacts d’urgence, les accès temporaires, les règles de traitement des données, la journalisation, les procédures de retour arrière et les approbations juridiques ne sont pas de la bureaucratie. Ce sont des mesures de protection de la résilience.

Inclure les prestataires tiers de services TIC avant que le test n’échoue

DORA fait du risque lié aux prestataires tiers de services TIC un enjeu central de résilience. L’Article 28 exige des entités financières qu’elles gèrent le risque lié aux prestataires tiers de services TIC dans le cadre de gestion des risques liés aux TIC, qu’elles restent responsables lorsqu’elles utilisent des services TIC, qu’elles tiennent un registre d’informations, qu’elles déclarent certains accords, qu’elles réalisent des évaluations précontractuelles et qu’elles recourent à des prestataires respectant des normes appropriées de sécurité de l’information. Les Articles 29 et 30 traitent du risque de concentration, de la sous-traitance, de la restauration des données, des protections contractuelles, des niveaux de service, de l’assistance en cas d’incident, des droits d’audit, des tests de continuité des prestataires, de leur participation aux tests lorsque cela est pertinent et des dispositifs de sortie.

L’Annexe A d’ISO/IEC 27001:2022 fournit des contrôles fournisseurs complémentaires, notamment 5.19 Sécurité de l’information dans les relations avec les fournisseurs, 5.20 Prise en compte de la sécurité de l’information dans les accords fournisseurs, 5.21 Gestion de la sécurité de l’information dans la chaîne d’approvisionnement TIC, 5.22 Surveillance, revue et gestion des changements des services fournisseurs et 5.23 Sécurité de l’information pour l’utilisation de services cloud.

Un catalogue de tests DORA doit identifier les tests qui exigent la participation d’un fournisseur ou des éléments probants fournisseurs. Exemples :

• Hypothèses de basculement du fournisseur cloud
• Escalade du SOC managé et préservation des éléments probants
• Communication d’incident de la plateforme bancaire cœur
• Scénario d’indisponibilité du processeur de paiement
• Test de reprise du fournisseur d’identité
• Attestations de tests d’intrusion du fournisseur SaaS
• Évaluation d’impact de la chaîne de sous-traitance critique

Un programme qui exclut les prestataires critiques de services TIC échouera au test de réalité. Le service exposé au client peut vous appartenir, mais la dépendance de résilience peut se situer dans une région cloud, un SOC externalisé, un fournisseur d’identité, un éditeur logiciel, un processeur de paiement ou un centre de données.

Cartographie multi-référentiels : un jeu d’éléments probants, plusieurs obligations

Un programme de tests DORA bien conçu réduit la fatigue d’audit. Les mêmes éléments probants peuvent soutenir DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 et les revues de gouvernance COBIT 2019 s’ils sont correctement balisés, conservés et reportés.

GDPR ne doit pas être oublié. Si les tests de résilience impliquent des données à caractère personnel, des journaux, des dossiers clients, des données d’identité, des données RH, des données biométriques ou des catégories particulières de données, l’organisation doit respecter les principes GDPR, notamment la licéité, la loyauté, la transparence, la minimisation des données, la limitation de la conservation, l’intégrité, la confidentialité et la responsabilité. Les copies de données de test, les journaux exportés et les éléments probants de tests d’intrusion peuvent devenir des réservoirs de données réglementées. Le programme de tests doit définir qui peut y accéder, pendant combien de temps ils sont conservés et comment ils sont éliminés de manière sécurisée.

Comment les auditeurs testeront le même programme

Un superviseur DORA, un auditeur ISO, un évaluateur fondé sur NIST, un réviseur COBIT et un auditeur client peuvent examiner les mêmes éléments probants sous des angles différents.

Zenith Controls est ici utile comme boussole multi-référentiels. Pour les tests DORA, Clarysec met en avant 5.35 Revue indépendante de la sécurité de l’information, 8.8 Gestion des vulnérabilités techniques et 8.6 Gestion de la capacité comme ancrages particulièrement importants de l’Annexe A ISO/IEC 27001:2022. Ils aident les responsables de contrôle à relier les tests à l’assurance indépendante, au traitement des vulnérabilités et à la capacité opérationnelle.

La Politique de sécurité de l’information de Clarysec soutient également la piste d’audit :

“Les responsables de contrôle doivent conserver les résultats de test, les journaux et les enregistrements de revue afin de soutenir les audits périodiques.”

Cette phrase doit devenir une règle opérationnelle. Chaque responsable de test doit savoir quoi conserver, où le conserver, comment le protéger et comment le relier aux éléments probants de risque et de contrôle.

Construire un dossier d’éléments probants DORA vers ISO en une semaine

Une entité financière ou un prestataire de services TIC peut réaliser des progrès significatifs en cinq jours ouvrés.

Jour 1 : définir le périmètre et la criticité

Utilisez la logique des clauses 4.1 à 4.4 d’ISO/IEC 27001:2022. Identifiez les parties intéressées, les obligations réglementaires, les obligations contractuelles, les interfaces et les dépendances. Listez les services métier, les fonctions critiques ou importantes, les actifs clés, les types de données et les prestataires de services TIC.

Livrable : registre du périmètre des tests DORA.

Jour 2 : créer le catalogue annuel de tests

Utilisez les quatre familles de tests : vulnérabilité, scénario, performance et intrusion. Pour chaque service, définissez les tests applicables, la fréquence, le responsable, le niveau d’indépendance et le déclencheur. Incluez les déclencheurs liés aux changements à haut risque.

Livrable : catalogue 2026 de tests de résilience opérationnelle numérique.

Jour 3 : cartographier les contrôles et les obligations

Cartographiez chaque test avec l’Annexe A ISO/IEC 27001:2022, le registre des risques, la SoA, les articles DORA, les obligations fournisseurs et les entrées pertinentes de Zenith Controls. Par exemple, les scans mensuels de vulnérabilités externes se rattachent à 8.8 Gestion des vulnérabilités techniques, au traitement des risques, à la surveillance, à la gestion des risques TIC DORA et aux résultats NIST CSF relatifs aux vulnérabilités.

Livrable : matrice de cartographie des contrôles.

Jour 4 : standardiser les dossiers d’éléments probants

Créez une structure maîtrisée d’éléments probants :

• 01 Plan et autorisation
• 02 Périmètre et règles d’engagement
• 03 Résultats bruts
• 04 Rapport final
• 05 Registre des constats
• 06 Tickets de remédiation
• 07 Éléments probants de retest
• 08 Reporting de direction
• 09 Retours d’expérience et mises à jour de politiques

Livrable : référentiel d’éléments probants avec règles de conservation.

Jour 5 : revoir les constats et le reporting

Consolidez les constats ouverts par gravité, service, propriétaire du risque et date d’échéance. Identifiez les remédiations en retard, les risques acceptés et les écarts de retest. Préparez un tableau de bord destiné à l’organe de direction indiquant la couverture des tests, les constats majeurs, les actions en retard, les problèmes liés aux tiers et le risque résiduel.

Livrable : tableau de bord DORA et ISO prêt pour le conseil.

Pièges courants d’un programme de tests DORA

L’échec le plus fréquent n’est pas l’absence de tests. C’est l’absence de gouvernance.

Surveillez les points suivants :

• Tests d’intrusion réalisés chaque année, mais constats non suivis jusqu’à la clôture
• Scans de vulnérabilités fréquents, mais actifs critiques absents du périmètre
• Exercices sur table organisés, mais absence de journal de décisions ou de plan d’action fondé sur les retours d’expérience
• Tests de restauration de sauvegarde réalisés, mais non cartographiés avec le RTO et le RPO
• Tests de charge réalisés par l’ingénierie, mais non reportés aux fonctions risques ou conformité
• Prestataires de services TIC exclus des tests de scénarios et de reprise
• Éléments probants stockés dans des dossiers personnels, fils de discussion ou lecteurs non maîtrisés
• Rapports au conseil centrés sur des volumes d’activité plutôt que sur les risques de résilience non résolus
• SoA indiquant qu’un contrôle s’applique, mais absence d’éléments probants de test
• Tests créant un risque de production parce que les autorisations et les limites ne sont pas claires

Chaque écart peut être corrigé. La réponse n’est pas davantage de tests aléatoires. La réponse est un programme maîtrisé unique qui relie les risques, les activités de test, la remédiation, les éléments probants et la supervision de direction.

Ce que le conseil doit réellement voir

DORA fait de la résilience TIC une responsabilité de l’organe de direction. Un rapport utile au conseil ne doit pas inclure chaque constat technique. Il doit répondre à la question suivante : l’organisation est-elle suffisamment résiliente au regard de son appétence au risque et de sa tolérance aux perturbations ?

Un rapport trimestriel ou semestriel solide comprend :

• La couverture des tests par rapport aux fonctions critiques ou importantes
• Les tests réalisés par rapport aux tests planifiés
• Les constats critiques et élevés par service
• Les remédiations en retard par responsable
• Le taux de réussite des retests
• Les constats liés aux fournisseurs et les préoccupations de concentration
• Les enseignements des tests de scénarios affectant les plans de crise ou d’incident
• Les risques de capacité au regard de la croissance métier et des périodes de pic
• Les risques résiduels nécessitant une acceptation par la direction
• Les contraintes de budget, de ressources ou d’outillage

Ce rapport devient une entrée de revue de direction ISO, un élément probant de gouvernance DORA et un outil de décision opérationnel.

Des tests dispersés à la résilience stratégique

Le problème initial du RSSI n’était pas l’absence de tests. L’organisation disposait de scans, d’exercices sur table, de rapports de charge et de PDF de tests d’intrusion. Le problème était que ces activités ne racontaient pas encore une histoire probante cohérente.

Un programme unifié de tests DORA et ISO/IEC 27001:2022 change la donne. L’appréciation des risques pilote le catalogue. Le catalogue pilote les tests autorisés. Les tests produisent des constats. Les constats pilotent la remédiation et les retests. Les résultats alimentent le reporting de direction. Les retours d’expérience mettent à jour les politiques, procédures, contrats et contrôles.

C’est ainsi qu’une charge de conformité devient une capacité stratégique.

Clarysec aide les organisations à éviter les programmes de conformité parallèles. DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 et COBIT 2019 n’ont pas besoin d’univers d’éléments probants séparés. Ils nécessitent un modèle opérationnel unique et gouverné, pouvant être présenté selon différents angles d’audit.

Notre approche combine :

• Le Zenith Blueprint pour une mise en œuvre ISO par phases et la préparation à l’audit
• Zenith Controls pour la cartographie multi-référentiels entre contrôles, cadres de référence et attentes d’audit
• Des politiques entreprise et PME pour les tests de sécurité, la surveillance des audits, la gestion des vulnérabilités, la sécurité des applications, la continuité et la sécurité de l’information
• Des registres pratiques, des structures d’éléments probants et des modèles de reporting de direction

Si vos éléments probants de tests DORA 2026 sont dispersés entre des outils de scan, des dossiers d’ingénierie, des notes d’exercice sur table et des PDF de tests d’intrusion, le moment est venu de les consolider.

Commencez par un catalogue annuel de tests cartographié avec le traitement des risques ISO/IEC 27001:2022, votre SoA, les fonctions critiques ou importantes, les prestataires tiers de services TIC et le reporting de direction. Utilisez ensuite le Zenith Blueprint, Zenith Controls et la boîte à outils de politiques de Clarysec pour transformer ce catalogue en éléments probants d’audit défendables.

Clarysec peut vous aider à concevoir le programme, cartographier les contrôles, structurer le dossier d’éléments probants et préparer le rapport de résilience au niveau du conseil avant la prochaine demande de l’autorité de contrôle.