Les deux à la fois : DORA permet de tenir le registre d'information aux niveaux individuel, sous-consolidé et consolidé, mais chaque entité financière régulée doit pouvoir produire sa propre vue — identifiée par son LEI — et la remettre à son autorité nationale. Un registre groupe bien structuré, filtrable par entité, satisfait les deux exigences ; un registre groupe monolithique dont on ne peut extraire le périmètre de chaque entité ne satisfait ni l'une ni l'autre.
L'article 28 de DORA impose aux entités financières de tenir un registre d'information relatif à tous leurs accords contractuels portant sur des services TIC, « aux niveaux individuel, sous-consolidé et consolidé ». Le format n'est pas libre : les autorités européennes de surveillance ont publié des normes techniques (ITS) définissant des modèles normalisés — des tables reliées entre elles, où chaque entité est identifiée par son LEI, chaque contrat par une référence unique, chaque fonction par son caractère critique ou important.
La logique est assumée : permettre aux régulateurs d'agréger les registres de toutes les entités européennes pour cartographier les dépendances du secteur financier envers les grands prestataires TIC. Votre registre n'est pas qu'un document interne — il alimente une supervision européenne.
Pour un groupe dont les entités relèvent de régulateurs différents — ACPR ou AMF en France, CSSF au Luxembourg, IVASS en Italie — la tentation est de tenir « le registre du groupe » comme un document unique. Le piège : chaque autorité nationale peut demander le registre de l'entité qu'elle supervise, dans le calendrier et selon les modalités de remise de son pays. Si votre registre consolidé ne permet pas d'extraire proprement le périmètre italien pour l'IVASS ou luxembourgeois pour la CSSF, chaque demande devient un projet.
La bonne architecture est une base unique, structurée entité par entité : chaque accord TIC est rattaché au LEI de l'entité contractante, les services intragroupe sont tracés des deux côtés (l'entité qui fournit, celles qui consomment), et la vue par entité s'extrait en un filtre.
Quand la DSI d'une entité du groupe fournit des services aux autres — cas de la quasi-totalité des groupes — ces services sont des prestations TIC intragroupe au sens de DORA : elles doivent figurer au registre de chaque entité consommatrice, avec un accord écrit conforme. Le registre qui ne recense que les prestataires externes est incomplet ; celui qui oublie que la maison-mère est elle-même un prestataire de ses filiales l'est plus encore. La chaîne de sous-traitance doit aussi apparaître : si la DSI groupe s'appuie sur un infogéreur, les entités consommatrices en héritent dans leur registre.
DORA laisse le groupe s'organiser, mais l'expérience plaide pour un modèle : une tenue centralisée (un propriétaire du registre, un outil, un référentiel de prestataires commun) avec une validation décentralisée (chaque entité confirme périodiquement son périmètre et ses criticités). Le prestataire TIC lui-même a un rôle à jouer : un infogéreur sérieux fournit à chaque entité cliente sa fiche registre pré-remplie et signale tout changement de sous-traitance — c'est un critère de sélection à part entière.
Les modalités de remise varient selon les autorités : des collectes périodiques sont organisées via les autorités nationales, et le registre doit par ailleurs être transmissible sur demande. Le point stable : il se tient à jour en permanence, il ne se reconstitue pas la veille d'une collecte.
Non, l'obligation pèse sur les entités financières dans le champ de DORA. Mais si une entité non régulée fournit des services TIC aux entités régulées — cas fréquent d'une holding portant la DSI — elle apparaît dans leurs registres comme prestataire intragroupe.
Pour un petit groupe, un classeur structuré selon les modèles européens peut suffire au démarrage, à condition de respecter strictement le format des tables et des identifiants (LEI, références de contrats). Dès que le périmètre croît, un outil dédié — ou une base tenue par le prestataire — évite les incohérences.
DIGICAB structure et alimente des registres d'information multi-entités, et fournit à ses clients régulés leur fiche registre tenue à jour. 30 minutes avec un ingénieur, sans démarchage ni engagement.
Prendre rendez-vous