Règlement et normes techniques : où trouver quoi
Le règlement lui-même fixe les principes. Les détails figurent dans des normes techniques de réglementation et d’exécution, élaborées par les autorités européennes de surveillance et adoptées par la Commission européenne. Mettre en œuvre DORA, c’est donc toujours travailler avec plusieurs textes en parallèle. Les plus importants portent sur le cadre de gestion du risque lié aux TIC et sa variante simplifiée, la classification des incidents et des cybermenaces, le contenu, les formats et les délais des notifications d’incidents, les tests de pénétration fondés sur la menace, les modèles du registre d’informations, la politique relative aux services TIC soutenant des fonctions critiques ou importantes et la sous-traitance.
En pratique, cela signifie : le règlement dit que vous devez classer un incident. C’est la norme qui fixe les critères, par exemple les clients touchés, la durée, l’étendue géographique, les pertes de données et l’impact économique, et qui détermine à partir de quand un incident est considéré comme majeur. Il en va de même pour le registre : ses champs et sa structure découlent des modèles de la norme technique d’exécution.
S’y ajoutent les orientations et les questions-réponses des autorités européennes de surveillance ainsi que les publications de la BaFin, par exemple sur les canaux de notification et les fenêtres de dépôt. Ces textes changent plus souvent que le règlement. Dans Sightadel, chaque contrôle est lié à l’article auquel il se rapporte. Lorsqu’une norme impose des détails, le contrôle indique la preuve attendue. En cas de doute, vérifiez la version applicable auprès de l’autorité de contrôle.
Le registre d’informations en pratique
Le registre est la partie de DORA que la plupart des entreprises ont sous-estimée. Il ne s’agit pas d’une simple liste de contrats, mais d’un répertoire structuré : quel service TIC l’entreprise obtient de qui, sur la base de quel contrat, pour quelle fonction, cette fonction est-elle critique ou importante, où les données sont-elles traitées, le prestataire serait-il facile à remplacer, et quels sous-traitants se trouvent derrière lui dans la chaîne. Le registre est tenu au niveau de l’entité individuelle et, pour les groupes, au niveau consolidé.
La BaFin demande le registre une fois par an, arrêté à une date de référence. Le dépôt s’effectue via sa plateforme de déclaration et de publication, dans une fenêtre de temps définie. Pour la déclaration 2026, cette fenêtre se situait en mars. Un registre n’est considéré comme déposé que s’il satisfait aux règles de validation des autorités européennes de surveillance. Des identifiants de prestataires manquants ou des informations contradictoires sur les fonctions entraînent des rejets. Les autorités européennes de surveillance utilisent aussi les registres pour désigner les prestataires tiers critiques de services TIC soumis à la supervision directe de l’UE.
Le vrai travail ne réside pas dans le remplissage, mais dans la collecte. Les informations sont dispersées entre les contrats, les achats, l’informatique et les métiers. Qui ne met à jour le registre qu’à la date de référence recommence ses recherches chaque année. Sightadel part donc du module Fournisseurs : chaque prestataire est renseigné avec son contrat, les fonctions soutenues, sa criticité, ses sites et ses preuves dès qu’il est mandaté. Nouveaux contrats, résiliations et changements de sous-traitants y sont enregistrés au quotidien, et non au printemps.
Coûts et charge interne
DORA coûte surtout du temps à des personnes déjà très sollicitées : sécurité de l’information, gestion de crise, achats, juridique, audit interne et direction. La licence Sightadel pour DORA est facturée mensuellement selon l’édition, avec des remises pour plusieurs frameworks et pour le paiement anticipé. Vous trouverez tous les prix et un simulateur sur notre page Plans et tarifs.
Les coûts externes apparaissent ailleurs et sont facturés directement par les prestataires concernés. L’expérience montre que trois postes pèsent le plus. Premièrement, les avenants aux contrats avec les prestataires, souvent avec un accompagnement juridique. Deuxièmement, le programme de tests, en particulier si vous êtes désigné pour un TLPT : un test fondé sur la menace, avec analyse de la menace, Red Team et travaux de clôture, est un projet de plusieurs mois. Troisièmement, la collecte des données pour le registre lorsque les dossiers contractuels sont incomplets.
Où économiser : avec un SMSI selon ISO 27001, inutile de réinventer la gestion des risques, la gestion des accès, la sauvegarde et le traitement des incidents. Dans Sightadel, les preuves existantes sont rattachées aux deux frameworks. Nous ne donnons volontairement aucun chiffre sur le recoupement, car il dépend du périmètre. Pour les points difficiles, comme la détermination des fonctions critiques ou importantes, vous ajoutez si besoin un forfait de conseil dans l’application.
Responsabilité de la direction, sanctions et responsabilité civile
DORA place expressément la responsabilité du risque lié aux TIC entre les mains de l’organe de direction. Celui-ci définit et approuve le cadre, fixe les rôles, détermine l’appétence au risque lié aux TIC, approuve les politiques de continuité d’activité et de gestion des tiers, fournit le budget et se forme régulièrement. Le travail peut être délégué, pas la responsabilité. Lors des contrôles, on demande donc ce que la direction a décidé, comment elle est informée et quelles formations ses membres ont suivies de manière attestée.
En Allemagne, la BaFin sanctionne les manquements en vertu du droit national de la supervision, adapté pour transposer les dispositions de DORA en matière de sanctions. Injonctions, amendes et, en cas de défaillances graves, d’autres mesures prudentielles sont possibles. Les prestataires tiers critiques de services TIC relèvent de la supervision directe d’un superviseur principal européen, qui émet des recommandations et peut imposer des astreintes calculées sur la base du chiffre d’affaires quotidien mondial.
Outre la supervision, le volet civil compte. Une défaillance de prestataire non maîtrisée, une notification tardive ou une sauvegarde non testée peut soulever des questions de dommages-intérêts envers les clients et de responsabilité des dirigeants. L’appréciation au cas par cas relève de votre conseil juridique. Sightadel ne fournit pas de conseil juridique, mais veille à ce que les décisions, les formations et les arbitrages soient attestés avec une date et un responsable.
Quelle documentation l’autorité de contrôle attend
Le règlement ne fournit pas de liste exhaustive, mais le règlement et les normes en dessinent un noyau clair. Il comprend le cadre de gestion du risque lié aux TIC documenté, y compris la stratégie de résilience opérationnelle numérique, les politiques de sécurité de l’information, de gestion des accès et des changements et de gestion des vulnérabilités, une politique de continuité des activités TIC avec des plans de réponse et de rétablissement, des politiques de sauvegarde avec des preuves de restaurations testées, un processus de gestion des incidents avec critères de classification et registre des incidents, le programme de tests avec ses résultats, la stratégie relative au risque lié aux prestataires tiers de services TIC, le registre d’informations et des stratégies de sortie pour les prestataires qui soutiennent des fonctions critiques ou importantes.
Le cadre doit être réexaminé au moins une fois par an, ainsi qu’après des incidents majeurs et à la suite des enseignements tirés de tests ou de contrôles. Ce réexamen donne lieu à un rapport que l’autorité de contrôle peut demander. Tout aussi importantes sont les preuves que les documents sont réellement appliqués : approbations, attestations de formation, procès-verbaux de tests de restauration, constats de tests et d’audit interne traités.
Dans Sightadel, chacun de ces documents est rattaché à un contrôle, avec sa version, son approbation et sa date d’expiration. Lorsqu’une preuve expire, par exemple un test de restauration annuel, elle apparaît dans le tableau de bord comme point ouvert. Ainsi, le dossier n’est pas complet uniquement à la date du contrôle.
Bien planifier le programme de tests et le TLPT
Toute entité financière qui ne relève pas du cadre simplifié a besoin d’un programme fondé sur les risques pour tester sa résilience opérationnelle numérique. Selon le contexte, il comprend des évaluations et analyses de vulnérabilités, des revues de code source, des tests fondés sur des scénarios, des tests de compatibilité et de performance, des tests de bout en bout et des tests de pénétration. Les systèmes qui soutiennent des fonctions critiques ou importantes sont testés de manière appropriée au moins une fois par an. Les testeurs doivent être indépendants, qu’ils soient internes ou externes.
Les tests de pénétration fondés sur la menace, ou TLPT, ne concernent que les entités désignées à cet effet par l’autorité de contrôle et ont alors lieu en règle générale tous les trois ans. Ils suivent une norme technique propre, inspirée du cadre européen TIBER. Un TLPT se déroule sur les systèmes de production et comprend une analyse de la menace, une attaque dissimulée menée par une Red Team et un retour d’expérience commun. L’autorité accompagne le test et en atteste la réalisation à la fin.
On sous-estime souvent la période qui suit le test. Les constats doivent être évalués, priorisés et traités dans les délais, et l’autorité veut voir les progrès. Dans Sightadel, chaque constat devient un problème avec responsable et échéance. Le test lui-même est réalisé par des testeurs spécialisés ; Sightadel consigne la planification, les résultats et leur traitement.
Articulation avec NIS2, ISO 27001 et les anciennes exigences de la BaFin
Pour les entités financières, DORA constitue la réglementation spécifique par rapport à NIS2. Elles remplissent leurs obligations de cybersécurité au titre de DORA, pas deux fois. Dans les groupes comprenant des sociétés hors du secteur financier, les deux régimes peuvent s’appliquer côte à côte. Il est alors utile de ne tenir les mesures et les preuves qu’une seule fois et de les rattacher aux deux.
Pour les entités relevant du champ d’application de DORA, les anciennes circulaires informatiques de la BaFin destinées aux banques, aux assureurs, aux sociétés de gestion et aux établissements de paiement ont été remplacées par le règlement. La BaFin a publié des indications sur l’articulation entre les exigences existantes, par exemple en matière d’externalisation hors TIC, et DORA. Il convient de clarifier avant l’analyse des écarts quelles parties restent applicables dans votre organisation.
ISO 27001 n’est pas une obligation, mais une ossature éprouvée. Un certificat montre qu’un système de management fonctionne et qu’il couvre une grande partie de DORA. Ce que DORA exige en plus, ce sont surtout le registre, les délais de notification, le contenu des contrats et le programme de tests. Les attestations BSI C5 ou SOC 2 de vos prestataires sont des preuves précieuses pour les évaluer, mais ne remplacent pas votre propre appréciation des risques.
