DORA : construire le registre d’information

À quoi sert le registre

Le registre a trois lecteurs, et chacun façonne une exigence. L’entité financière elle-même s’en sert comme colonne vertébrale de sa stratégie de risque lié aux tiers TIC : de quels services elle dépend, par quels contrats, pour quelles fonctions, avec quel repli. L’autorité compétente s’en sert pour la supervision : l’article 28, paragraphe 3, oblige l’entité à mettre le registre complet à disposition sur demande et à déclarer, au moins une fois par an, le nombre de nouveaux accords, les catégories de prestataires, les types de contrats et les services et fonctions qu’ils soutiennent. Les autorités européennes de surveillance se servent des registres consolidés pour désigner les prestataires tiers critiques de services TIC qui relèvent de leur surveillance directe (article 31).

Parce que le troisième lecteur agrège les registres à l’échelle de l’Union, le format n’est pas au choix de l’entité. Le règlement d’exécution (UE) 2024/2956 de la Commission du 29 novembre 2024 fixe les modèles, les identifiants et les listes fermées que chaque registre emploie, pour qu’un fournisseur de cloud nommé par deux cents entités soit compté une fois. C’est pourquoi les identifiants, et non les narratifs, sont le cœur de l’exercice.

Ce qu’il contient : les modèles

La norme organise le registre en tables liées plutôt qu’en une feuille unique, chacune portée par un identifiant que les autres tables référencent. Lues ensemble, elles répondent à une question : quelle entité juridique dépend de quel service TIC, sous quel contrat, auprès de quel prestataire et de ses sous-traitants, pour quelle fonction, avec quelle criticité et quelle sortie. Les familles de modèles sont les suivantes.

• Les entités : l’entité qui tient le registre, chaque entité financière couverte (au niveau consolidé, tout le groupe), et les succursales.
• Les accords contractuels : un numéro de référence unique par accord, son type (autonome, accord-cadre, accord subséquent ou associé), les accords liés, les dates de début et de fin, les préavis pour l’entité et pour le prestataire, la loi applicable, le pays de fourniture, les lieux de stockage et de traitement, la sensibilité des données et le niveau de dépendance au service.
• Les parties : les entités signataires de chaque accord, les prestataires tiers TIC signataires, et les entités qui utilisent le service, qui ne sont pas toujours les signataires.
• Les prestataires : chaque prestataire tiers TIC avec son identifiant (un identifiant d’entité juridique, LEI, ou un identifiant unique européen pour les sociétés de l’UE), son pays, son type de personne, sa maison mère ultime, et la devise de la dépense annuelle.
• La chaîne d’approvisionnement : pour chaque service, le prestataire de rang 1 et les sous-traitants de rang 2 et au-delà qui soutiennent effectivement le service, là où les fonctions critiques ou importantes exigent de la profondeur.
• Les fonctions : l’identifiant de chaque fonction, l’activité agréée dont elle relève, son caractère critique ou important, les raisons, l’impact d’une interruption, et les objectifs de délai et de point de reprise.
• L’évaluation des services : substituabilité du prestataire, possibilité de réintégration, existence d’un plan de sortie, date du dernier audit, et prestataires alternatifs identifiés.

Les identifiants : ce qui casse en premier

Un registre est rejeté par la validation de l’autorité bien avant que quelqu’un en lise le contenu. Les causes habituelles : un prestataire sans LEI ou avec un LEI expiré, une référence de contrat réutilisée pour deux accords, un identifiant de fonction qui diffère entre le modèle des fonctions et celui des accords, un type de service hors de la liste fermée de la norme, un pays dans le mauvais système de codes, une devise absente sur une dépense. Les listes fermées de la norme (types de services TIC, types d’accords, motifs de criticité, niveaux de sensibilité) ne laissent aucune place au vocabulaire local, et les contrôles de qualité des autorités européennes sur les registres collectés traitent un écart comme une erreur, pas comme une nuance.

Le remède est de décider les identifiants avant de commencer l’inventaire. Une règle de nommage des références d’accords qui survive aux renouvellements, une table des fonctions validée par le responsable de la continuité d’activité, le LEI de chaque prestataire demandé à l’entrée en relation et renouvelé chaque année, et une table de correspondance entre le catalogue de services de l’entité et les types de services de la norme. L’inventaire remplit alors une structure qui valide déjà.

Six étapes pour le construire

Le registre se construit depuis les fonctions vers le bas, pas depuis les contrats vers le haut : un contrat ne compte que pour les fonctions qu’il soutient, et la criticité est une propriété de la fonction.

• Fixer le périmètre des entités. Lister les entités financières et succursales couvertes, décider le niveau (entité, sous-consolidé, consolidé) de chaque remise, et nommer l’entité qui tient le registre. Un groupe construit un registre et le découpe par autorité.
• Lister les fonctions et les grader. Partir de l’analyse d’impact métier : chaque fonction, son activité agréée, son caractère critique ou important au sens de l’article 3, point 22 (une fonction dont la perturbation nuirait sensiblement aux performances financières, à la solidité ou à la continuité des services, ou au respect des conditions de l’agrément), ses objectifs de reprise. Cette table est l’épine dorsale du registre et demande la signature d’un responsable métier.
• Inventorier tous les contrats de services TIC. Pas seulement les critiques, tous : cloud, logiciel en tant que service, flux de données, services gérés, opérations externalisées, services intragroupe. L’article 3, point 21, définit largement les services TIC, comme des services numériques et de données fournis de manière continue par des systèmes TIC, et le registre les couvre tous, en signalant ceux qui soutiennent une fonction critique ou importante.
• Résoudre les prestataires et leur chaîne. Pour chaque contrat, le prestataire signataire avec son identifiant et sa maison mère ultime, puis les sous-traitants qui soutiennent effectivement le service, au rang 2 et au-delà, avec les mêmes identifiants. Pour les fonctions critiques ou importantes, la chaîne doit être connue ; pour les autres, le prestataire de rang 1 est le minimum.
• Remplir les champs d’évaluation. Substituabilité, réintégration, plan de sortie, dernier audit, prestataires alternatifs : ce sont des jugements de risque, pas de la saisie, et ils appartiennent à la fonction risque tiers avec le propriétaire du contrat. Un champ laissé vide est un constat que le superviseur lira comme tel.
• Consolider, valider, remettre. Assembler les modèles au niveau de remise, exécuter les validations de la norme (des clés qui se résolvent, des listes fermées, des dates qui s’ordonnent), puis déposer auprès de l’autorité compétente dans le format qu’elle prescrit, en France l’ACPR ou l’AMF selon l’entité, et conserver la version déposée.

Le tenir vivant

Le registre est un document vivant, et DORA le lit ainsi : un nouvel accord, un renouvellement, un changement de sous-traitant ou une résiliation modifient le registre le jour où ils surviennent, et la déclaration annuelle compte les changements de l’année. Pour les accords qui soutiennent des fonctions critiques ou importantes, l’article 28, paragraphe 8, demande aussi à l’entité d’informer l’autorité en temps utile des accords envisagés et de tout changement significatif, ce qui suppose que le registre connaisse le contrat avant sa signature. La conséquence pratique est que le registre ne peut pas être une campagne annuelle de tableur ; il doit siéger là où contrats, fournisseurs et fonctions sont gérés, et être alimenté par les événements qui les changent.

C’est aussi là qu’il devient utile au-delà de la conformité. Un registre qui connaît la chaîne des sous-traitants est la première entrée du risque de concentration (article 29) : combien de fonctions critiques dépendent d’un prestataire, d’une région, d’un hyperscaler de rang 2. Un registre qui connaît les plans de sortie est le test de la stratégie de sortie que DORA exige pour les fonctions critiques. Et un registre qui porte la date du dernier audit est le calendrier du programme d’assurance.

Où le registre rencontre NIS2

Les entités financières appliquent DORA plutôt que les mesures de NIS2 : le registre n’a pas de jumeau NIS2. Sa logique voyage pourtant : la mesure de sécurité de la chaîne d’approvisionnement de NIS2 demande aux entités essentielles et importantes des autres secteurs de connaître leurs fournisseurs directs et les risques qu’ils portent, et la structure du registre, les fonctions d’abord, puis les contrats, les prestataires et la chaîne, est la bonne manière de le faire. Les groupes qui détiennent à la fois une banque et une filiale industrielle tendent à tenir un seul inventaire fournisseurs et à en produire les modèles DORA.

Ce que Mindlapse fait du registre

Sur la plateforme, le registre est le Supplier Hub lu à travers les modèles DORA : les fournisseurs avec leurs identifiants et leur chaîne, les contrats avec leurs dates et leurs clauses, les fonctions avec leur criticité, et les champs d’évaluation tenus à jour par le workflow de risque tiers plutôt que par une campagne. Chaque fournisseur porte un Trust Grade qui bouge avec ses signaux, et l’export produit les modèles que l’autorité attend. La page du cas d’usage DORA et le module de risque tiers le déroulent pilier par pilier.