Feuille de route DORA 2026 pour les risques liés aux TIC, les fournisseurs et le TLPT

La panique des recherches DORA 2026 ne porte pas vraiment sur la réglementation, mais sur les éléments probants

Il est 08 h 15 un lundi matin et le RSSI d’un établissement de paiement de taille intermédiaire a trois onglets de navigateur ouverts : « liste de contrôle DORA RTS/ITS », « modèle de registre des tiers TIC DORA » et « exigences TLPT entités financières ».

Le responsable conformité a déjà demandé si le dossier destiné au conseil d’administration devait inclure le dernier processus de classification des incidents. La direction des achats veut intégrer une nouvelle plateforme d’analyse cloud. Le COO veut avoir l’assurance que le fournisseur SaaS du système bancaire central ne présente pas d’exposition cachée à des sous-traitants hors de l’UE. L’audit interne demande un calendrier de tests. Le service juridique veut savoir si les délais de notification des violations au titre de GDPR ont été alignés avec le signalement des incidents DORA.

Personne ne pose une question théorique. La vraie question est : « Pouvons-nous le prouver d’ici vendredi ? »

C’est le véritable enjeu DORA 2026. La plupart des entités financières comprennent les obligations principales : gestion des risques liés aux TIC, signalement des incidents liés aux TIC, tests de résilience opérationnelle numérique, gestion des risques liés aux tiers TIC et supervision renforcée des prestataires TIC critiques. La difficulté consiste à transformer les normes techniques de réglementation, les normes techniques d’exécution et les obligations par article en pratiques contrôlées, répétables et auditables.

Le Digital Operational Resilience Act impose aux entités financières de maintenir des capacités robustes de gestion des risques liés aux TIC, des politiques de gestion et de signalement des incidents liés aux TIC, des tests des systèmes, contrôles et processus TIC, ainsi qu’une supervision structurée des prestataires tiers TIC. Il exige également la proportionnalité. Une petite entreprise d’investissement et un grand groupe bancaire n’ont pas besoin de modèles d’éléments probants identiques, mais tous deux doivent démontrer que leur approche est adaptée à leur taille, à leur profil de risque, à leur complexité et à leurs fonctions critiques.

Les projets DORA échouent généralement pour l’une de ces trois raisons. Premièrement, l’organisation traite DORA comme un exercice de cartographie juridique plutôt que comme un modèle opérationnel. Deuxièmement, le risque fournisseur est documenté comme une simple liste de prestataires, au lieu d’être traité sous l’angle des dépendances, de la substituabilité et du risque de concentration. Troisièmement, les tests sont assimilés à un test d’intrusion annuel, au lieu d’être intégrés à un programme de résilience comprenant des analyses de vulnérabilités, des tests fondés sur des scénarios, des exercices de gestion des incidents et, le cas échéant, des tests d’intrusion fondés sur la menace, souvent recherchés sous le terme TLPT.

Une meilleure approche consiste à construire un système unique d’éléments probants reliant politiques, registres, responsables, risques, incidents, fournisseurs, tests, rétablissement et revue de direction. C’est là que le Zenith Blueprint, les politiques prêtes à l’emploi de Clarysec et Zenith Controls aident les entités financières à transformer DORA d’une échéance réglementaire en un rythme de fonctionnement maîtrisé.

Commencer par le modèle opérationnel DORA, pas par le tableur RTS/ITS

De nombreuses équipes commencent par un tableur listant les articles DORA et les exigences RTS/ITS. C’est utile, mais insuffisant. Un tableur peut indiquer ce qui doit exister. Il n’attribue pas de responsables, ne définit pas la fréquence de revue, ne conserve pas les éléments probants et ne démontre pas qu’un contrôle fonctionne réellement.

Dans le Zenith Blueprint : feuille de route en 30 étapes pour l’auditeur, Clarysec traite ce sujet dans la phase de gestion des risques, étape 14, politiques de traitement des risques et renvois réglementaires :

« DORA : pour les entreprises du secteur financier, DORA exige un cadre de gestion des risques liés aux TIC très aligné avec ce que nous avons réalisé : identifier les risques, mettre en place des contrôles et des politiques, puis les tester. DORA insiste également sur la réponse aux incidents et le signalement, ainsi que sur la supervision des prestataires tiers de services TIC. »

Le message pratique est simple : ne construisez pas la « conformité DORA » comme une bureaucratie parallèle. Mettez en place une couche de gouvernance TIC fondée sur les risques, qui relie les exigences DORA aux politiques, registres, responsables de contrôle, enregistrements de tests, éléments probants fournisseurs et revues de direction.

Un modèle opérationnel DORA pragmatique doit reposer sur cinq piliers d’éléments probants :

Pour les entités financières réglementées, cette structure transforme la mise en œuvre RTS/ITS en un système d’éléments probants auditable. Pour les entités relevant d’une gestion simplifiée des risques liés aux TIC, le même modèle peut être réduit à un nombre plus limité de documents et à des registres plus simples. Les disciplines fondamentales restent les mêmes : identifier, protéger, détecter, répondre, rétablir, tester et gouverner les fournisseurs.

Gestion des risques liés aux TIC : le registre est la salle de contrôle

Les attentes de DORA en matière de gestion des risques liés aux TIC exigent des entités financières qu’elles identifient, classifient et gèrent les risques TIC couvrant les systèmes, les données, les processus, les fonctions critiques ou importantes et les dépendances vis-à-vis de tiers.

La défaillance la plus fréquente n’est pas l’absence d’un registre des risques. C’est le fait que ce registre soit déconnecté des fournisseurs, des actifs, des incidents et des tests. DORA ne valorise pas un beau tableur s’il ne permet pas d’expliquer pourquoi un fournisseur à haut risque n’a pas de plan de sortie, ou pourquoi une plateforme critique de paiement client n’a pas été testée.

La Politique de gestion des risques SME de Clarysec fournit aux petites entités financières un référentiel d’éléments probants concis :

« Chaque entrée de risque doit inclure : description, vraisemblance, impact, score, propriétaire et plan de traitement des risques. »
Extrait de la section « Exigences de gouvernance », clause de politique 5.1.2.

Pour les entités financières plus grandes, la Politique de gestion des risques Enterprise de Clarysec impose un processus plus formel :

« Un processus formel de gestion des risques doit être maintenu conformément à ISO/IEC 27005 et ISO 31000, couvrant l’identification, l’analyse, l’évaluation, le traitement, la surveillance et la communication des risques. »
Extrait de la section « Exigences de gouvernance », clause de politique 5.1.

Cette distinction est importante. DORA est proportionné, mais la proportionnalité ne signifie pas l’informel. Une petite entreprise de paiement peut utiliser un registre simplifié, tandis qu’un groupe bancaire peut s’appuyer sur des outils GRC intégrés. Dans les deux cas, l’auditeur posera les mêmes questions : quels sont vos risques TIC ? Qui en est propriétaire ? Quel est le plan de traitement des risques ? Quels éléments probants montrent les progrès réalisés ? Comment les fournisseurs et les fonctions critiques influencent-ils le score ?

Un registre des risques TIC DORA robuste doit inclure les champs suivants :

Un exercice pratique consiste à prendre un service TIC critique, par exemple une plateforme de surveillance des transactions hébergée dans le cloud, et à créer une entrée de risque en 20 minutes. Décrivez le scénario de défaillance ou de compromission, notez la vraisemblance et l’impact, attribuez un propriétaire, identifiez les fournisseurs associés, définissez un plan de traitement des risques et reliez l’entrée aux éléments probants tels que les diligences préalables relatives aux fournisseurs, le SLA, les clauses d’incident, la BIA, les résultats des tests de DR, les tableaux de bord de supervision et les revues des accès.

Cette entrée unique devient le fil conducteur reliant la gestion des risques liés aux TIC DORA, la supervision des tiers, la détection des incidents, la continuité et les tests. C’est ainsi qu’un registre des risques devient une salle de contrôle, et non une armoire de classement.

Préparation RTS/ITS : cartographier les obligations avec les politiques, pas avec des promesses

Le terme de recherche pratique « liste de contrôle DORA RTS/ITS » signifie généralement : « Quels documents les superviseurs attendront-ils ? » Les entités financières doivent éviter de promettre la conformité au moyen d’énoncés génériques. Elles ont besoin d’une cartographie qui relie chaque obligation à une politique, à un contrôle, à un responsable et à un élément probant.

La Politique de conformité juridique et réglementaire SME de Clarysec établit un point d’ancrage simple de gouvernance :

« Le directeur général doit maintenir un registre de conformité simple et structuré listant : »
Extrait de la section « Exigences de gouvernance », clause de politique 5.1.1.

Pour DORA 2026, votre registre de conformité doit inclure :

• Obligation DORA ou domaine d’exigence RTS/ITS.
• Applicabilité, y compris la justification de proportionnalité.
• Référence de politique ou de procédure.
• Responsable de contrôle.
• Emplacement des éléments probants.
• Fréquence de revue.
• Lacunes ouvertes et échéance de remédiation.
• Statut de reporting au conseil d’administration ou à la direction.

Cette approche est alignée avec l’étape 14 du Zenith Blueprint : cartographier les exigences réglementaires avec les contrôles et politiques du SMSI afin que rien ne passe entre les mailles du filet. Au lieu de demander « Sommes-nous conformes à DORA ? », la direction peut demander : « Quels éléments probants DORA sont en retard, quels fournisseurs critiques n’ont pas de plan de sortie et quelles activités de test n’ont pas encore produit d’éléments probants de remédiation ? »

Risque lié aux tiers TIC : concentration, substituabilité et sous-traitants

DORA a modifié la discussion sur les fournisseurs dans les services financiers. Il ne suffit plus de demander si un prestataire dispose d’une certification de sécurité, d’une assurance ou d’un accord de traitement des données. Les entités financières doivent évaluer si un prestataire crée un risque de concentration, s’il peut réellement être remplacé, si plusieurs services critiques dépendent d’un seul fournisseur ou de fournisseurs liés, et si la sous-traitance introduit une exposition juridique ou de résilience supplémentaire.

C’est le sujet qui empêche de nombreux RSSI de dormir. Une entreprise peut dépendre d’un fournisseur de services cloud majeur pour le traitement des transactions, l’analyse des données, les portails clients et la collaboration interne. Si ce fournisseur subit une indisponibilité prolongée, un différend réglementaire ou une défaillance de sous-traitant, la question n’est pas seulement : « Avons-nous un contrat ? » La question est : « Pouvons-nous maintenir les services critiques, communiquer avec les clients et prouver que nous avions compris la dépendance avant qu’elle ne se matérialise ? »

La Politique de sécurité des tiers et des fournisseurs SME de Clarysec pose le socle :

« Un registre des fournisseurs doit être maintenu et mis à jour par le contact administratif ou achats. Il doit inclure : »
Extrait de la section « Exigences de gouvernance », clause de politique 5.4.

Pour les programmes d’entreprise, la Politique de gestion des risques de dépendance vis-à-vis des fournisseurs de Clarysec va plus loin sur les dépendances et la substituabilité propres à DORA :

« Registre des dépendances fournisseurs : la fonction de gestion des fournisseurs (VMO) doit maintenir un registre à jour de tous les fournisseurs critiques, comprenant des informations telles que les services/produits fournis ; le caractère de fournisseur unique ; les fournisseurs alternatifs disponibles ou la substituabilité ; les conditions contractuelles en vigueur ; et une évaluation de l’impact en cas de défaillance ou de compromission du fournisseur. Le registre doit identifier clairement les fournisseurs à forte dépendance, par exemple ceux pour lesquels aucune alternative rapide n’existe. »
Extrait de la section « Exigences de mise en œuvre », clause de politique 6.1.

C’est l’élément probant fournisseur que les projets DORA omettent souvent. Un registre des fournisseurs indique qui est le fournisseur. Un registre des dépendances indique ce qui se passe si ce fournisseur échoue.

Le Zenith Blueprint, phase Contrôles en action, étape 23, Contrôles organisationnels, fournit un processus pratique de supervision des fournisseurs. Il recommande de constituer une liste complète des fournisseurs, de les classifier selon leur accès aux systèmes, aux données ou au contrôle opérationnel, de vérifier que les exigences de sécurité sont intégrées aux contrats, de gérer les sous-traitants et les risques en aval, de définir des procédures de changement et de surveillance, et de créer un processus d’évaluation des services cloud.

Dans Zenith Controls : le guide de conformité croisée, le contrôle ISO/IEC 27002:2022 5.21, gestion de la sécurité de l’information dans la chaîne d’approvisionnement TIC, est cartographié comme un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité. Il est associé à la sécurité de la relation fournisseur et à la fonction Identifier du cadre de cybersécurité. Il se rattache à l’ingénierie sécurisée, au développement sécurisé, au contrôle d’accès, aux tests de sécurité, à la collecte des éléments probants, au cycle de vie de développement sécurisé et au développement externalisé.

C’est exactement la réalité de la supervision des tiers DORA. Le risque fournisseur ne relève pas seulement des achats. Il touche l’architecture, le développement, la réponse aux incidents, le contrôle d’accès, la continuité d’activité et le juridique.

Dans une perspective de conformité croisée, Zenith Controls cartographie la sécurité de la chaîne d’approvisionnement TIC avec GDPR Articles 28 et 32, car les sous-traitants de traitement et les sous-traitants ultérieurs doivent être sélectionnés et supervisés au moyen de mesures techniques et organisationnelles appropriées. Il soutient les attentes NIS2 en matière de sécurité de la chaîne d’approvisionnement, notamment les mesures de gestion des risques de cybersécurité de l’Article 21 et les évaluations coordonnées des risques de la chaîne d’approvisionnement de l’Article 22. Il se cartographie fortement avec DORA Articles 28, 29 et 30, où les risques liés aux tiers TIC, le risque de concentration, la sous-traitance en chaîne et les dispositions contractuelles sont centraux.

Les normes d’appui renforcent les éléments probants. ISO/IEC 27036-3:2021 soutient la sécurité de l’approvisionnement TIC et de la sélection des fournisseurs. ISO/IEC 20243:2018 soutient l’intégrité des produits technologiques de confiance et la sécurité de la chaîne d’approvisionnement. ISO/IEC 27001:2022 relie ces éléments au traitement des risques et aux contrôles fournisseurs de l’Annexe A.

Signalement des incidents : construire la chaîne d’escalade avant l’incident

Le signalement des incidents DORA ne se limite pas à transmettre une notification. Il s’agit de détecter, classifier, escalader, communiquer et tirer les enseignements des incidents liés aux TIC. Les entités financières doivent maintenir des processus de gestion et de signalement des incidents TIC, avec des rôles définis, des critères de classification, des circuits de notification et une analyse post-incident.

La Politique de réponse aux incidents SME de Clarysec relie les délais de réponse aux exigences légales :

« Les délais de réponse, y compris les obligations de restauration des données et de notification, doivent être documentés et alignés avec les exigences légales, telles que l’exigence GDPR de notification des violations de données à caractère personnel dans un délai de 72 heures. »
Extrait de la section « Exigences de gouvernance », clause de politique 5.3.2.

Pour les environnements d’entreprise, la Politique de réponse aux incidents de Clarysec ajoute l’angle d’escalade lié aux données réglementées :

« Si un incident entraîne une exposition confirmée ou probable de données à caractère personnel ou d’autres données réglementées, le juridique et le DPO doivent évaluer l’applicabilité de : »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.4.1.

La citation s’arrête au point de déclenchement, précisément là où de nombreux processus d’incident échouent. Si le déclencheur n’est pas clair, les équipes débattent des obligations de notification alors que le chronomètre tourne déjà.

Le Zenith Blueprint, phase Contrôles en action, étape 16, Contrôles relatifs aux personnes II, met l’accent sur le signalement des incidents par le personnel. Les employés, les prestataires et les parties prenantes doivent savoir reconnaître et signaler les incidents de sécurité potentiels au moyen de canaux simples, tels qu’une boîte de messagerie dédiée, un portail ou une ligne d’assistance. Le Blueprint relie ce point à GDPR Article 33, NIS2 Article 23 et DORA Article 17, car le reporting réglementaire commence par la sensibilisation interne et l’escalade.

Dans Zenith Controls, le contrôle ISO/IEC 27002:2022 5.24, planification et préparation de la gestion des incidents de sécurité de l’information, est cartographié comme un contrôle correctif soutenant la confidentialité, l’intégrité et la disponibilité, aligné avec les fonctions Répondre et Rétablir. Il se rattache directement à l’évaluation des événements, aux enseignements tirés des incidents, à la journalisation et à la surveillance, à la sécurité en situation de perturbation, à la continuité de la sécurité de l’information et aux contacts avec les autorités. Le guide cartographie ce contrôle avec DORA Articles 17 à 23 pour la gestion, la classification et le signalement des incidents liés aux TIC ainsi que la notification volontaire des cybermenaces, avec GDPR Articles 33 et 34 pour la notification des violations, et avec NIS2 Article 23 pour la notification des incidents.

Un processus d’incident prêt pour DORA doit inclure :

• Des canaux clairs de réception des incidents.
• Des critères de triage des événements et de classification.
• Un processus d’escalade des incidents majeurs liés aux TIC.
• Des points de décision pour le juridique, le DPO et les notifications réglementaires.
• Des déclencheurs de notification d’incident fournisseur.
• Des exigences de conservation des éléments probants.
• Des règles de communication à la direction exécutive et au conseil d’administration.
• Une revue post-incident et des enseignements tirés.
• Une articulation avec les mises à jour du registre des risques et la remédiation des contrôles.

Les normes d’appui apportent de la structure. ISO/IEC 27035-1:2023 fournit les principes de planification et de préparation pour la gestion des incidents. ISO/IEC 27035-2:2023 détaille les étapes de gestion des incidents. ISO/IEC 22320:2018 soutient le commandement, le contrôle et la communication de crise structurée. Cela devient essentiel lorsqu’une indisponibilité TIC se transforme en crise affectant les clients et que l’entité doit montrer que ses décisions ont été rapides, coordonnées et fondées sur des éléments probants.

Tests de résilience opérationnelle numérique et TLPT : ne laissez pas le test devenir l’incident

Les tests font partie des sujets DORA 2026 les plus recherchés, car ils sont à la fois techniques et fortement liés à la gouvernance. Les entités financières doivent tester les systèmes, contrôles et processus TIC. Pour les entités désignées, les tests avancés tels que le TLPT deviennent une exigence centrale au titre de DORA Article 26.

La question d’audit n’est pas seulement : « Avez-vous testé ? » Elle est : « Le test était-il fondé sur les risques, autorisé, sûr, indépendant lorsque requis, remédié et relié aux objectifs de résilience ? »

La Politique de tests de sécurité et de red teaming Enterprise de Clarysec définit clairement le programme minimal de tests :

« Types de tests : le programme de tests de sécurité doit inclure, au minimum : (a) des analyses de vulnérabilités, consistant en des analyses automatisées hebdomadaires ou mensuelles 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 d’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, incluant l’ingénierie sociale et d’autres tactiques, afin de tester les capacités de détection et de réponse de l’organisation dans son ensemble. »
Extrait de la section « Exigences de mise en œuvre », clause de politique 6.1.

C’est le pont entre les tests de routine et la maturité TLPT. Les analyses de vulnérabilités identifient les faiblesses connues. Les tests d’intrusion valident l’exploitabilité. Le red teaming teste la détection et la réponse comme un système. Le TLPT, lorsqu’il s’applique, doit s’inscrire dans un programme de tests gouverné, avec maîtrise du périmètre, règles de sécurité, gestion du risque en production, collecte des éléments probants et suivi de la remédiation.

Le Zenith Blueprint, phase Contrôles en action, étape 21, traite de la protection des systèmes d’information pendant les audits et les tests. Il rappelle que les audits, les tests d’intrusion, les revues forensiques et les évaluations opérationnelles peuvent introduire un risque, car ils peuvent impliquer un accès élevé, des outils intrusifs ou des modifications temporaires du comportement des systèmes. Le Blueprint cartographie cette préoccupation avec GDPR Article 32, les attentes DORA en matière de tests de résilience opérationnelle numérique, les préoccupations NIS2 relatives à la continuité et les pratiques COBIT 2019 d’exécution sûre des audits et évaluations.

Dans Zenith Controls, le contrôle ISO/IEC 27002:2022 5.35, revue indépendante de la sécurité de l’information, est cartographié comme préventif et correctif, soutenant la confidentialité, l’intégrité et la disponibilité. Il se rattache à la conformité avec les politiques, aux responsabilités de management, aux enseignements tirés des incidents, à la protection des enregistrements, à la suppression des informations, à la journalisation et à la surveillance. Pour DORA, les obligations de test pertinentes sont principalement les Articles 24 à 27, y compris l’Article 26 pour le TLPT. Cela soutient également GDPR Article 32(1)(d), qui impose des tests et évaluations réguliers des mesures techniques et organisationnelles, ainsi que NIS2 Article 21, qui impose des mesures de gestion des risques de cybersécurité.

Un dossier de préparation TLPT DORA doit inclure :

La leçon clé de DORA est que les éléments probants de test ne doivent pas s’arrêter au rapport. Les auditeurs demanderont si les constats ont été cotés par risque, attribués, remédiés et retestés. Ils peuvent également vérifier si les tests ont couvert les fonctions critiques ou importantes, et pas seulement les actifs exposés à Internet.

Continuité d’activité et reprise après sinistre : la résilience doit être opérationnelle

DORA est une réglementation de résilience opérationnelle numérique. Le rétablissement compte autant que la prévention. Un cadre documenté de gestion des risques TIC ne servira à rien si une indisponibilité de plateforme de paiement révèle que les objectifs de délai de reprise n’ont jamais été testés, que les arbres de contacts fournisseurs sont obsolètes et que l’équipe de crise ne sait pas qui communique avec les clients.

La Politique de continuité d’activité et de reprise après sinistre SME de Clarysec définit un référentiel clair :

« L’organisation doit tester à la fois ses capacités de PCA et de DR au moins une fois par an. Les tests doivent inclure : »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.4.1.

La Politique de continuité d’activité et de reprise après sinistre Enterprise commence par l’impact métier :

« Une analyse d’impact sur l’activité (BIA) doit être réalisée au moins une fois par an pour toutes les unités métier critiques et revue en cas de changements significatifs des systèmes, processus ou dépendances. Les livrables de la BIA doivent définir : »
Extrait de la section « Exigences de gouvernance », clause de politique 5.2.

Pour DORA, la BIA doit être reliée aux actifs TIC, aux fournisseurs, à la réponse aux incidents et aux tests. Si la BIA identifie les « paiements clients » comme une fonction critique, le registre des dépendances fournisseurs doit identifier les processeurs, les services cloud et les fournisseurs réseau qui la soutiennent. Le registre des risques doit inclure des scénarios de défaillance. Le plan de test doit inclure une validation de résilience. Le plan de réponse aux incidents doit inclure l’escalade et la communication. Le test de DR doit produire des éléments probants, et pas seulement un compte rendu de réunion.

Cette traçabilité transforme la conformité DORA en système de résilience opérationnelle.

Conformité croisée : un seul jeu d’éléments probants, plusieurs questions d’audit

Les entités financières sont rarement confrontées à DORA seul. Elles ont souvent des obligations GDPR, une exposition NIS2, des engagements contractuels de sécurité, des objectifs ISO/IEC 27001:2022, des exigences d’audit interne, des diligences raisonnables clients, des attentes SOC et du reporting des risques au conseil d’administration. La réponse n’est pas de créer des silos d’éléments probants distincts. La réponse consiste à construire un modèle d’éléments probants de conformité croisée.

Zenith Controls est la boussole de conformité croisée de Clarysec. Il n’invente pas de nouvelles obligations. Il cartographie les normes et référentiels officiels afin que les organisations comprennent comment un domaine de contrôle soutient plusieurs résultats de conformité.

Cela compte pour les budgets et la gouvernance. Un RSSI peut expliquer au conseil d’administration que l’amélioration de la classification des incidents soutient le reporting DORA, la notification des violations GDPR, la gestion des incidents NIS2 et la résilience interne. Un responsable achats peut justifier la cartographie des dépendances fournisseurs parce qu’elle soutient le risque de concentration DORA, les diligences préalables relatives aux sous-traitants GDPR et la sécurité de la chaîne d’approvisionnement NIS2. Un responsable des tests peut démontrer que les exercices de red teaming et les revues indépendantes soutiennent les tests DORA, l’évaluation des contrôles GDPR et l’assurance au sens large.

Angle d’audit : comment les évaluateurs testeront vos éléments probants DORA

La préparation à DORA devient concrète lorsqu’une personne demande des éléments probants. Les auditeurs et évaluateurs aborderont le même sujet sous des angles différents.

Un auditeur orienté ISO/IEC 27001:2022 commencera par la logique du SMSI : domaine d’application, appréciation des risques, traitement des risques, applicabilité des contrôles de l’Annexe A, audit interne, revue de direction et éléments probants démontrant que les contrôles sont mis en œuvre. Pour la sécurité de la chaîne d’approvisionnement TIC, il examinera les politiques, la classification des fournisseurs, les clauses contractuelles, les diligences préalables et la surveillance continue. Pour la gestion des incidents, il inspectera le plan, les rôles, les circuits d’escalade, les outils et les enregistrements. Pour les tests, il attendra des intervalles planifiés, l’indépendance lorsque pertinente, la remédiation et l’alimentation de la revue de direction.

Une approche d’audit fondée sur ISO/IEC 19011:2018 se concentre sur l’exécution de l’audit. Dans Zenith Controls, la méthodologie d’audit de la sécurité de la chaîne d’approvisionnement TIC précise que les auditeurs examinent les politiques d’achats, les modèles d’appels d’offres et les processus de gestion des fournisseurs afin de vérifier que les exigences de sécurité propres aux TIC sont intégrées de l’acquisition jusqu’à l’élimination. Pour la gestion des incidents, les auditeurs examinent l’exhaustivité du plan de réponse aux incidents et son alignement avec les bonnes pratiques. Pour la revue indépendante, les auditeurs recherchent les éléments probants que des audits ou revues indépendants ont été réalisés.

Une approche ISO/IEC 27007:2020 est plus spécifique à l’audit du SMSI. Zenith Controls indique que les auditeurs peuvent interroger les responsables achats, le personnel de sécurité informatique et les responsables des fournisseurs afin d’évaluer la compréhension et l’exécution des contrôles de chaîne d’approvisionnement TIC. Pour la préparation aux incidents, ils confirment qu’une équipe de réponse aux incidents existe et est opérationnelle. Pour la revue indépendante, ils vérifient que le programme d’audit interne couvre l’ensemble du domaine d’application du SMSI et dispose des ressources appropriées.

Un évaluateur de tests s’appuyant sur NIST SP 800-115 se concentrera sur la méthodologie d’évaluation des vulnérabilités et de tests d’intrusion. Il pourra examiner si le périmètre de test, les règles d’engagement, les constats, les niveaux de gravité, la remédiation et les retests sont documentés. Pour le TLPT DORA, cela signifie que l’évaluateur ne se satisfera pas d’un jeu de diapositives red team. Il voudra une preuve de gouvernance, de sécurité d’exécution, de profondeur technique et de clôture.

Un auditeur de type COBIT 2019 ou ISACA demandera si les objectifs de gouvernance sont atteints : qui possède le processus, comment la performance est mesurée, comment les exceptions sont approuvées et comment la direction reçoit l’assurance.

La liste de contrôle pratique de préparation DORA 2026

Utilisez cette liste de contrôle comme référentiel de travail pour convertir les recherches DORA en actions.

Gouvernance et cartographie RTS/ITS

• Maintenir un registre de conformité DORA indiquant le domaine d’obligation, l’applicabilité, le propriétaire, les éléments probants, la fréquence de revue et le statut des lacunes.
• Cartographier les exigences DORA avec les politiques, registres, contrôles et reportings de direction.
• Définir la justification de proportionnalité pour la gestion simplifiée ou adaptée des risques liés aux TIC lorsque cela s’applique.
• Attribuer la responsabilité exécutive du risque TIC, du signalement des incidents, de la supervision des tiers et des tests.
• Inclure le statut DORA dans la revue de direction et le reporting des risques au conseil d’administration.

Gestion des risques liés aux TIC

• Maintenir un registre des risques TIC incluant description, vraisemblance, impact, score, propriétaire et plan de traitement des risques.
• Relier les risques aux fonctions critiques ou importantes.
• Relier les risques aux actifs TIC, aux fournisseurs et aux processus.
• Revoir les risques après des incidents majeurs, des changements fournisseurs, des changements technologiques ou des constats de test.
• Suivre les actions de traitement jusqu’à leur clôture ou jusqu’à une acceptation formelle du risque.

Supervision des tiers TIC

• Maintenir un registre des fournisseurs et un registre des dépendances fournisseurs.
• Identifier les fournisseurs soutenant des fonctions critiques ou importantes.
• Évaluer les fournisseurs uniques et la substituabilité.
• Revoir les sous-traitants et les dispositifs de sous-traitance en chaîne.
• Intégrer dans les contrats les clauses de sécurité, d’accès, de signalement des incidents, d’audit et de sortie.
• Surveiller les fournisseurs critiques au moins une fois par an ou après tout changement significatif.
• Maintenir des plans de sortie et de contingence pour les prestataires à forte dépendance.

Gestion et signalement des incidents

• Maintenir des procédures de réponse aux incidents avec des rôles et circuits d’escalade clairs.
• Définir les critères de classification des incidents TIC.
• Aligner les déclencheurs de reporting DORA avec GDPR, NIS2 et les obligations de notification contractuelles.
• Former les employés et prestataires aux canaux de signalement des incidents.
• Maintenir les journaux d’incident, les enregistrements de décision et les éléments probants.
• Réaliser des revues post-incident et mettre à jour les risques et contrôles.

Tests, red teaming et TLPT

• Maintenir un calendrier de tests fondé sur les risques.
• Réaliser des analyses de vulnérabilités et des tests d’intrusion à des intervalles définis.
• Utiliser des exercices de red teaming fondés sur des scénarios pour tester la détection et la réponse.
• Pour la préparation TLPT, définir le périmètre, les règles d’engagement, les contrôles de sécurité et la coordination fournisseurs.
• Protéger les systèmes de production pendant les tests.
• Suivre les constats, la remédiation, les retests et les enseignements tirés.
• Communiquer les résultats des tests à la direction.

Continuité et reprise

• Réaliser une BIA annuelle pour les unités métier critiques et la mettre à jour après des changements significatifs.
• Définir les objectifs de reprise pour les fonctions critiques et les services TIC de support.
• Tester les capacités de PCA et de DR au moins une fois par an.
• Inclure des scénarios d’indisponibilité fournisseur et d’incident cyber.
• Conserver les éléments probants de test, les lacunes, les actions de remédiation et les résultats de retest.
• Aligner les plans de continuité avec la réponse aux incidents et les communications de crise.

Comment Clarysec aide les entités financières à passer des résultats de recherche aux éléments probants auditables

La préparation DORA 2026 ne s’obtient pas en téléchargeant une liste de contrôle en espérant que l’organisation comblera les écarts plus tard. Elle exige un modèle opérationnel structuré qui relie risques, fournisseurs, incidents, tests, continuité et éléments probants d’audit.

L’approche de Clarysec combine trois couches.

Premièrement, le Zenith Blueprint fournit la feuille de route de mise en œuvre. L’étape 14 aide les organisations à établir des renvois entre les exigences réglementaires, le traitement des risques et les politiques. L’étape 16 renforce le signalement des incidents par le personnel. L’étape 21 veille à ce que les audits et tests ne mettent pas en danger les systèmes de production. L’étape 23 transforme la supervision des fournisseurs en processus pratique couvrant classification, contrats, sous-traitants, surveillance et évaluation cloud.

Deuxièmement, les politiques Clarysec fournissent une gouvernance prête à être opérationnalisée. La Politique de gestion des risques, la Politique de conformité juridique et réglementaire, la Politique de sécurité des tiers et des fournisseurs, la Politique de gestion des risques de dépendance vis-à-vis des fournisseurs, la Politique de réponse aux incidents, la Politique de tests de sécurité et de red teaming et la Politique de continuité d’activité et de reprise après sinistre apportent aux équipes des clauses concrètes, des modèles de responsabilité et des attentes en matière d’éléments probants.

Troisièmement, Zenith Controls fournit la cartographie de conformité croisée. Il montre comment la sécurité de la chaîne d’approvisionnement TIC, la planification de la gestion des incidents et la revue indépendante se rattachent à DORA, GDPR, NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO/IEC 27035, ISO/IEC 27036, ISO/IEC 22320, ISO/IEC 20243, COBIT 2019 et aux pratiques de test NIST.

Le résultat est un programme de conformité DORA défendable en audit et utile lors d’un incident réel, d’une défaillance fournisseur ou d’un test de résilience.

Prochaine étape : constituer votre dossier d’éléments probants DORA avant la prochaine demande d’audit

Si votre équipe recherche encore « liste de contrôle DORA RTS/ITS », « modèle de gestion des risques TIC DORA », « supervision des tiers DORA » ou « exigences TLPT DORA », l’étape suivante consiste à transformer ces recherches en éléments probants contrôlés.

Commencez par quatre actions cette semaine :

1. Créez ou mettez à jour votre registre de conformité DORA selon le modèle de politique Clarysec.
2. Sélectionnez une fonction critique et suivez-la dans le registre des risques, le registre des dépendances fournisseurs, le processus d’incident, la BIA et le plan de test.
3. Examinez vos cinq principaux fournisseurs TIC sous l’angle de la substituabilité, des sous-traitants, des clauses d’incident et des options de sortie.
4. Constituez un dossier d’éléments probants de test comprenant périmètre, autorisation, résultats, remédiation et retests.

Clarysec peut vous aider à le mettre en œuvre avec le Zenith Blueprint, les modèles de politiques et Zenith Controls, afin que votre programme DORA 2026 soit pratique, proportionné et auditable.