Un incident majeur signalé une fois ne suffit pas. C’est la phrase qui résume le mieux les instructions opérationnelles publiées le 16 septembre 2026 par les autorités européennes de supervision (ESAs) sur le reporting d’incidents dans le cadre de DORA : la déclaration initiale n’ouvre qu’un cycle, pas un dossier clos.

Le texte fixe 14 lignes directrices à destination des autorités compétentes, mais leur portée descend directement jusqu’aux entités financières régulées. Trois obligations changent la manière de tenir un dossier d’incident. D’abord, deux champs d’identification (1.3a/1.3b, puis 2.1) doivent rester rigoureusement inchangés du premier signalement jusqu’à la clôture ; un simple renommage de ticket en cours de traitement casse la traçabilité attendue par le superviseur. Ensuite, des rapports intermédiaires mensuels sont exigés tant que l’incident n’est pas résolu, et non plus un point final unique. Enfin, un rapport final est dû au plus tard un mois après le dernier rapport intermédiaire, avec un champ « services critiques affectés » qui doit systématiquement être renseigné, y compris quand la réponse est négative.

Cycle de reporting d'un incident majeur DORA selon les instructions opérationnelles des ESAs du 16 septembre 2026. Première étape : signalement initial, dès que l'incident franchit le seuil de majeur. Deuxième étape : rapport intermédiaire mensuel, qui revient en boucle chaque mois tant que l'incident n'est pas clos, cohérent avec le précédent. Troisième étape, une fois l'incident clos : rapport final au plus tard un mois après le dernier rapport intermédiaire, avec le champ services critiques affectés toujours renseigné. Sous les trois étapes, une même bande : identifiants 1.3a, 1.3b et 2.1 inchangés du début à la fin. Schéma ITAIA.
Le rapport intermédiaire tourne en boucle tant que l'incident dure ; les identifiants, eux, ne bougent jamais.

Qui est concerné, et à partir de quand ?

Toute entité financière entrant dans le périmètre DORA (sociétés de gestion, entreprises d’investissement, établissements de paiement, et leurs prestataires TIC critiques par ricochet) applique ces instructions dès qu’un incident franchit le seuil de majeur, selon les critères déjà fixés par le RTS 2025/301. Rien de nouveau sur le déclenchement. Ce qui change, c’est l’exigence de forme : modèles en anglais obligatoires pour la notification structurée aux ESAs (le texte libre en langue nationale reste toléré en complément), montants monétaires à convertir en milliers d’unités plutôt qu’en euros bruts. Un détail administratif en apparence. En pratique, c’est ce genre de détail qui fait rejeter un rapport et déclenche une relance de l’autorité, avec le temps perdu que cela suppose en pleine gestion de crise.

On nous objecte parfois que c’est le rôle du prestataire technique de gérer cette mécanique. Faux, ou plutôt incomplet : le prestataire fournit la matière première (logs, chronologie, périmètre technique touché), mais la responsabilité du dépôt et de sa conformité formelle reste celle de l’entité régulée. Un MSSP sérieux prépare le dossier ; il ne le signe jamais à la place du client.

Le tableur partagé ne survivra pas au premier rapport intermédiaire

Nous voyons encore, chez des sociétés de gestion de taille moyenne, des tableaux Excel partagés par mail pour suivre un incident en cours entre le RSSI, le DSI et le prestataire. Cette méthode tient pour une déclaration ponctuelle. Elle s’effondre dès le deuxième mois, quand il faut produire un rapport intermédiaire cohérent avec le précédent, sur des champs identifiants qui n’ont pas le droit de bouger.

Ce que le texte ne tranche pas encore : le canal exact d’échange entre le RSSI et l’ACPR pour les incidents mineurs (non soumis à ces instructions) reste à l’appréciation de chaque autorité nationale, et les entités feraient bien de ne pas attendre une clarification ultérieure pour structurer leur propre registre interne. C’est très exactement l’esprit de la deuxième opposition qui structure notre métier : une sécurité qui se prouve, avec des journaux et des tickets horodatés, vaut mieux qu’une sécurité qui se déclare a posteriori dans un document reconstitué. Pour objectiver le niveau de maturité de votre organisation sur ce point précis, notre simulateur d’analyse de risques selon la méthode de l’ANSSI permet de tester en une vingtaine de minutes où se situent vos zones de fragilité documentaire, bien avant qu’un incident ne les révèle en conditions réelles.

Le registre d’information sur les prestataires TIC que nous détaillions dans notre article précédent répond à une logique voisine : documenter avant d’être interrogé, pas après.

Reste une question ouverte pour les prochains mois : combien de sociétés de gestion découvriront ces exigences de continuité documentaire à l’occasion de leur premier incident réel, plutôt qu’en amont ?

Sources : Instructions opérationnelles ESAs, 16 septembre 2026 · FAQ ACPR sur DORA · AMF, DORA – Incident and cyberthreat notification