Le logiciel DORA qui pilote votre résilience opérationnelle

DORA vise les entités financières de l'Union au sens large : établissements de crédit, entreprises d'investissement, établissements de paiement et de monnaie électronique, assureurs, réassureurs et intermédiaires d'assurance, gestionnaires de fonds, prestataires de services sur crypto-actifs, infrastructures de marché, agences de notation. Les prestataires tiers de services TIC sont concernés à deux titres : par les exigences contractuelles imposées à leurs clients financiers, et, pour ceux que les autorités européennes de surveillance désignent comme critiques, par une surveillance européenne directe. Un cadre simplifié de gestion du risque TIC reste ouvert aux plus petites entités.

Non. DORA est un règlement européen, pas un référentiel de certification : aucun organisme ne délivre de certificat DORA et personne ne peut se déclarer « certifié DORA ». La conformité se démontre devant l'autorité compétente qui vous supervise, en France l'ACPR pour les banques et les assurances, l'AMF pour la gestion d'actifs et les acteurs de marché. Ce qu'elle regarde, ce sont vos documents : cadre de gestion du risque TIC, registre d'informations, rapports d'incidents, résultats de tests.

NIS2 est une directive transposée par chaque État membre et couvre de nombreux secteurs ; DORA est un règlement directement applicable qui vise le seul secteur financier. Là où les deux pourraient se recouvrir, DORA prime en tant que texte sectoriel spécifique : une entité financière dans son champ applique DORA pour ses mesures de gestion du risque cyber et sa notification d'incidents. Les deux textes partagent assez de logique pour qu'une bonne part des contrôles serve aux deux.

C'est une fonction dont l'interruption nuirait sensiblement aux performances financières de l'entité, à la solidité ou à la continuité de ses services et activités, ou à sa capacité à continuer de respecter les conditions de son agrément et ses autres obligations réglementaires. La qualification n'a rien de cosmétique : elle déclenche des exigences renforcées sur les clauses contractuelles conclues avec le prestataire TIC concerné, sur les tests et sur le contenu du registre d'informations. C'est l'une des premières décisions à documenter, et à réexaminer quand le périmètre bouge.

DORA demande un programme de tests proportionné au risque, avec au minimum des tests annuels des systèmes qui soutiennent des fonctions critiques ou importantes : évaluations de vulnérabilités, tests de continuité, analyses de sécurité. S'y ajoutent, pour les entités désignées par leur autorité compétente au regard de leur profil de risque et de leur impact sur le secteur financier, des tests de pénétration fondés sur la menace (TLPT), à conduire au moins tous les trois ans et alignés sur le cadre TIBER-EU.

Le règlement fixe un socle valable pour tout accord de services TIC : description complète des services, lieux de fourniture et de traitement ou de stockage des données, protection et restitution des données, niveaux de service, assistance en cas d'incident, coopération avec les autorités, conditions et préavis de résiliation. Quand le prestataire soutient une fonction critique ou importante, les exigences se renforcent : objectifs de performance précis, droits d'accès, d'inspection et d'audit sans restriction, participation aux tests, stratégies de sortie documentées et testées. Cela suppose de reprendre le stock de contrats existants, pas seulement les nouveaux.

Le registre suit un format défini au niveau européen : plusieurs tables reliées par des identifiants, où un accord contractuel renvoie à l'entité signataire, au prestataire, à ses sous-traitants et aux fonctions soutenues. Dans un tableur, ces liens se défont dès la première mise à jour, et une référence incohérente suffit à faire échouer les contrôles de qualité au moment de la transmission. Un outil dédié tient ces relations, vérifie la cohérence avant l'envoi et évite de reconstituer le registre à chaque campagne de collecte.