Tests de résilience DORA : éprouvez réellement votre système d’information

Passer des procédures à la preuve

Pourquoi DORA impose-t-il de tester la résilience opérationnelle numérique ?

La « loi DORA » désigne couramment le règlement DORA, officiellement le règlement européen (UE) 2022/2554, ou Digital Operational Resilience Act. Applicable depuis le 17 janvier 2025, ce texte impose aux entités financières de l’Union européenne de maintenir un programme de tests de résilience opérationnelle numérique intégré à leur cadre de gestion des risques TIC. Parmi les objectifs DORA figure la démonstration que les mesures de protection, de détection, de réponse et de reprise restent efficaces dans des conditions réalistes.

Les articles 24 et 25 encadrent les exigences de DORA en matière de tests, les catégories de contrôles et le traitement des faiblesses découvertes. Une banque, un organisme d’assurance ou une société de gestion doit donc relier ses vérifications aux services financiers réellement délivrés.

La protection contre les cybermenaces suppose des exercices adaptés à la taille de l’organisation, à son profil de risque et à la criticité de ses services. Ils portent sur les systèmes, applications, réseaux, procédures et dépendances technologiques qui soutiennent les fonctions critiques ou importantes. Les résultats doivent permettre d’identifier les faiblesses, de les corriger rapidement et de renforcer la résilience opérationnelle numérique dans la durée.

• Éprouver : vérifier le comportement réel des outils, procédures et équipes face à un scénario défini.
• Mesurer : comparer le résultat obtenu aux objectifs de sécurité, de disponibilité et de reprise.
• Prouver : conserver le périmètre, les conditions, les observations, les décisions et les éléments de contrôle.
• Améliorer : transformer chaque écart en action suivie, puis vérifier son efficacité par un nouveau test.

DORA distingue les tests réguliers prévus pour l’ensemble des entités concernées et les exercices avancés fondés sur la menace, ou TLPT, réservés aux entités désignées par leur autorité compétente. Un test d’intrusion classique ne devient donc pas automatiquement un TLPT DORA.

Tester ce qui soutient réellement l’activité

Construire un programme de tests DORA proportionné aux risques

Un programme de tests DORA efficace part des services financiers et non d’une liste générique d’outils. Il relie chaque fonction critique ou importante aux actifs TIC, aux données, aux flux, aux sites et aux prestataires tiers dont elle dépend. Cette cartographie nourrit l’analyse de risque, permet de choisir les scénarios utiles et concentre les moyens sur les points capables d’interrompre l’activité.

Le programme précise le périmètre, le niveau de profondeur, les responsables, les conditions d’exécution et les critères de succès. Il tient compte des changements d’architecture, des incidents, des nouvelles vulnérabilités et des résultats précédents. Parmi les obligations DORA, les entités autres que les microentreprises doivent réaliser au moins chaque année des tests appropriés sur les systèmes et applications TIC qui soutiennent des fonctions critiques ou importantes. Ce principe de proportionnalité signifie que toutes les vérifications ne doivent être ni identiques ni exécutées au même moment.

Le calendrier forme ainsi une trajectoire de résilience opérationnelle numérique : les contrôles fréquents surveillent les changements courants, tandis que les exercices plus profonds éprouvent périodiquement l’infrastructure informatique et l’organisation.

Le choix des scénarios doit découler de la cartographie et de la gestion des risques TIC afin que la profondeur des contrôles reste cohérente avec l’exposition réelle de l’entité.

Besoin de relier votre programme de tests aux services critiques et aux risques déjà identifiés ?

Identifier les faiblesses avant l’incident

Tester les vulnérabilités et l’efficacité des défenses

Les contrôles techniques servent à identifier les vulnérabilités et à vérifier si les mesures déployées réduisent réellement les risques. Selon le périmètre et les autorisations, ils peuvent associer scans, revue de configuration, analyse des correctifs, contrôle des droits, vérification de la sécurité des réseaux, tests de pénétration ou tests d’intrusion. Une analyse de code source peut également être pertinente lorsqu’elle est possible et justifiée par la criticité de l’application.

Les scénarios d’attaque doivent rester maîtrisés. Avant toute intervention, l’entité définit les actifs autorisés, les horaires, les personnes informées, les données à protéger et les critères d’arrêt. Une simulation crédible n’a pas besoin de reproduire chaque technique d’un attaquant réel pour être utile : elle doit mettre à l’épreuve une hypothèse de risque, sans créer une perturbation disproportionnée.

• Exposition : services publiés, accès distants, interfaces cloud et équipements accessibles.
• Durcissement : configurations, ports, comptes, privilèges et politiques de sécurité appliquées.
• Vulnérabilités : failles connues, correctifs manquants, composants obsolètes et erreurs de configuration.
• Détection : capacité des outils et des équipes à repérer puis qualifier une activité anormale.
• Résistance : efficacité des contrôles face à un scénario de cyberattaque ou d’intrusion autorisé.

Le résultat ne se résume pas au nombre de vulnérabilités découvertes. Il doit préciser leur contexte, leur effet possible sur les services, les mesures compensatoires déjà en place et la priorité de correction. Cette lecture évite de confondre une faiblesse théorique avec un risque critique pour la résilience opérationnelle numérique du secteur financier.

Pour approfondir ce volet : identifier et vérifier les vulnérabilités de votre système d’information.

Une sauvegarde doit pouvoir être restaurée

Tester les sauvegardes et la restauration des systèmes

Une sauvegarde disponible dans une console ne garantit ni l’intégrité des données ni la reprise du service. Les tests de restauration DORA vérifient qu’une copie exploitable peut être retrouvée, restaurée et utilisée dans les conditions attendues. L’exercice contrôle la chaîne complète : sélection du point de reprise, disponibilité des accès, reconstruction du système, cohérence des données et validation par le métier. Il apporte une preuve concrète de résilience opérationnelle numérique.

Le scénario doit intégrer les dépendances souvent oubliées : identités, clés de chiffrement, configurations réseau, licences, documentation, accès cloud ou composants tiers. Il mesure aussi la perte de données maximale tolérée et le temps nécessaire pour revenir à un état opérationnel. Un résultat partiel est documenté comme un écart ; il ne doit pas être présenté comme une restauration réussie.

• Disponibilité : localiser une copie conforme, y accéder avec les habilitations prévues et vérifier sa conservation.
• Intégrité : contrôler que les données et configurations restaurées sont lisibles, cohérentes et complètes.
• Objectifs : comparer le point de reprise obtenu au RPO et la durée de restauration au délai métier attendu.
• Validation : faire confirmer le fonctionnement du service par les équipes techniques et le responsable métier.
• Traçabilité : conserver le procès-verbal, les horodatages, les écarts et les actions décidées.

Ces contrôles complètent la stratégie de sauvegarde des données et permettent de vérifier les objectifs de point de reprise sans recréer une page consacrée au PRA ou au RPO.

Mesurer la capacité à maintenir les services critiques

Exercer la continuité, la reprise et le retour à la normale

Pour évaluer la résilience, les exercices de résilience opérationnelle numérique mesurent la capacité de l’organisation à maintenir ou reprendre ses activités face à une perturbation grave. Le scénario peut simuler la perte d’un site, une panne réseau, l’indisponibilité d’une application, une corruption de données, une cyberattaque ou la défaillance d’un prestataire cloud. Il doit rester plausible au regard du profil de risque et assez exigeant pour révéler les dépendances cachées.

L’exercice ne concerne pas uniquement l’équipe informatique. Les métiers valident les priorités et le niveau de service réellement disponible ; la direction arbitre les décisions sensibles ; les fonctions risques et conformité observent les écarts ; la communication prépare les messages internes, clients ou partenaires. Cette capacité organisationnelle est aussi importante que la remise en service technique.

1. Continuer : identifier les opérations pouvant être maintenues en mode dégradé et leurs conditions de sécurité.
2. Basculer : activer les solutions de secours et vérifier les accès, les flux et les données indispensables.
3. Reprendre : restaurer les composants dans un ordre cohérent avec les priorités métier.
4. Communiquer : partager une information validée avec les équipes et parties prenantes concernées.
5. Normaliser : contrôler le service, fermer les solutions temporaires et sécuriser le retour à la normale.

La campagne s’articule avec les contenus ACI consacrés aux plans de continuité et de reprise ainsi qu’au maintien en condition opérationnelle.

Mettre la chaîne de décision à l’épreuve

Tester la gestion des incidents TIC DORA

Une procédure d’incident peut sembler complète sur le papier et échouer dès la première alerte. Un exercice sur table ou une simulation technique vérifie la détection, la qualification, l’escalade, le confinement, le rétablissement et la conservation des preuves. Il mesure également la capacité des équipes informatiques à relier l’événement au service financier concerné et à fournir rapidement les informations utiles à une éventuelle notification. Cette coordination contribue directement à la résilience opérationnelle numérique.

Le scénario fixe une chronologie, distribue progressivement les informations et observe les décisions. Les participants doivent savoir qui pilote, qui autorise une action technique, qui informe la direction et qui échange avec l’autorité compétente. Les prestataires de services TIC impliqués dans une fonction critique ou importante peuvent être associés afin de tester les contacts, les clauses de coopération et les canaux de communication.

• Alerte : détection du signal, ouverture du ticket et identification des premiers impacts.
• Escalade : mobilisation des bons interlocuteurs selon la gravité et les services touchés.
• Réponse : décisions de confinement, investigation, correction et continuité de service.
• Preuves : horodatage des faits, actions, validations et informations disponibles.
• Retour d’expérience : causes, points de friction, mesures correctives et mise à jour de la procédure.

Votre procédure résiste-t-elle à une alerte réelle, avec les délais et les intervenants prévus ?

Faire de chaque résultat un levier d’amélioration

Transformer les résultats en plan de remédiation

La campagne n’est terminée ni lorsque le scénario s’arrête ni lorsque le service revient. Les observations doivent être consolidées dans un rapport qui distingue les faits, les écarts, leurs effets possibles et les mesures proposées. Chaque action reçoit une priorité, un responsable, une échéance et un mode de vérification. Les risques acceptés ou différés restent explicitement tracés par l’entité financière.

Un résultat négatif n’est pas, à lui seul, un échec de conformité : il révèle une faiblesse avant qu’un incident réel ne l’exploite. En revanche, un écart sans décision ni suivi fragilise le cadre de gestion. Les vulnérabilités critiques appellent une correction rapide ou une mesure compensatoire ; les autres rejoignent un plan d’action cohérent avec la criticité et les ressources disponibles.

Le rapport alimente le registre des risques TIC, le programme suivant et le reporting à l’organe de direction. Cette boucle d’amélioration renforce la résilience opérationnelle numérique sans répéter les mêmes scénarios.

Des tests avancés encadrés par l’autorité compétente

Tests TLPT DORA : quelles entités sont concernées ?

Le threat led penetration testing, ou TLPT, est un exercice avancé fondé sur la menace. Il simule les tactiques, techniques et procédures d’attaquants réels pour éprouver des fonctions critiques ou importantes, leurs systèmes sous-jacents et, lorsque cela est nécessaire, les tiers de services TIC concernés. Il ne s’agit ni d’un simple scan ni d’un test d’intrusion standard rebaptisé pour DORA.

Toutes les entités financières ne sont pas soumises au TLPT. L’autorité compétente désigne les organisations concernées en tenant compte de leur impact systémique, de leurs activités, de leur profil de risque TIC, de leur maturité et des caractéristiques technologiques utilisées. Les entités désignées réalisent en principe un TLPT au moins tous les trois ans ; l’autorité peut adapter cette fréquence aux circonstances et au risque.

Le périmètre est validé avec l’autorité TLPT et couvre les systèmes de production qui soutiennent les fonctions retenues. L’exercice exige une gouvernance particulière, des équipes de contrôle, des renseignements sur la menace, des intervenants répondant à des critères précis, une gestion stricte des risques et un plan de remédiation. Le règlement délégué (UE) 2025/1190 précise la méthode, les différentes phases et la coopération attendue. En France, l’entité doit suivre les instructions de l’autorité compétente désignée pour son secteur.

ACI Technology ne revendique pas la réalisation autonome d’un TLPT complet. Selon les capacités et partenaires validés, ACI peut contribuer à la préparation du périmètre, fournir les informations techniques, coordonner les actifs qu’il administre, participer à la remédiation et documenter les actions. La qualification du test, sa conduite réglementaire et les échanges avec l’autorité restent encadrés par le dispositif TLPT applicable.

Un accompagnement coordonné, du cadrage au retest

Comment ACI Technology intervient avant, pendant et après les tests

ACI Technology intervient sur le périmètre technique et opérationnel confié. La mission peut porter sur une campagne ciblée — restauration, configuration, vulnérabilités, incident — ou contribuer à un programme annuel plus large. Le niveau d’intervention dépend des services administrés par ACI, des autorisations du client, des outils disponibles et des expertises ou partenaires nécessaires.

• Avant la campagne : identifier les services et actifs concernés, collecter les prérequis, définir le scénario, les critères de succès, les responsabilités et les conditions d’arrêt.
• Pendant l’exercice : exécuter ou coordonner les opérations techniques autorisées, suivre la chronologie, préserver les preuves et limiter les effets sur les utilisateurs.
• Après l’exercice : restituer les résultats, relier les constats aux risques, proposer des corrections et formaliser un plan de traitement.
• Lors de la vérification : contrôler l’application des mesures et confirmer que l’écart initial est effectivement réduit.

ACI ne délivre pas de certification DORA et ne remplace ni l’organe de direction, ni les fonctions risques et conformité, ni un conseil juridique. L’entité financière reste responsable du programme, du niveau de risque accepté, du choix des systèmes critiques et des relations avec l’autorité compétente. Cette répartition protège la valeur des tests : les équipes techniques produisent les faits, tandis que la gouvernance prend les décisions qui engagent l’organisation.

Vous souhaitez transformer vos exigences DORA en programme de tests proportionné, documenté et suivi ?