DORA : construire le registre des prestataires TIC à partir du SI réel

Le registre d’informations DORA ne devrait pas être conçu comme un fichier réglementaire à remplir une fois par an. Le texte impose de tenir et mettre à jour un registre portant sur les accords contractuels d’utilisation de services TIC fournis par des prestataires tiers, au niveau de l’entité et, lorsque c’est pertinent, aux niveaux sous-consolidé et consolidé.1 Le règlement d’exécution 2024/2956 transforme cette obligation en un ensemble de modèles reliés entre eux : contrats, entités utilisatrices, prestataires, services TIC, fonctions, chaîne de sous-traitance et évaluations.2

La conséquence opérationnelle est importante : un registre fiable se construit mieux comme une vue réglementaire de données déjà gouvernées dans le SI que comme un tableur autonome. C’est une analyse Cybercoria, pas une exigence littérale de DORA. Le règlement ne prescrit pas de moyen technique particulier pour tenir ce registre.

Objet	Question à résoudre	Zone du registre concernée
Fonction	Quelle activité dépend du service TIC ?	B_06.01
Service TIC	Quel service est réellement consommé ?	B_02.02 / B_05.02
Contrat	Quel accord encadre ce service ?	B_02.01 / B_02.02
Prestataire	Quelle entité juridique fournit le service ?	B_05.01
Sous-traitant	Qui sous-tend la fourniture du service ?	B_05.02
Évaluation	Quel risque porte un service critique ou important ?	B_07.01

Le registre DORA couvre plus que les fournisseurs critiques

L’article 28, paragraphe 3, de DORA demande un registre relatif à tous les accords contractuels portant sur l’utilisation de services TIC fournis par des prestataires tiers.1 Le même article demande ensuite de distinguer les accords qui couvrent des services TIC soutenant des fonctions critiques ou importantes de ceux qui n’en couvrent pas.1

Cette distinction évite une erreur fréquente : limiter le registre aux seuls fournisseurs jugés critiques. La FAQ publiée par l’EBA rappelle explicitement que les prestataires qui ne fournissent pas de service soutenant une fonction critique ou importante doivent quand même être identifiés dans le registre lorsque leurs accords entrent dans le périmètre de l’article 28.5

Les modèles B_02, B_05 et B_06 doivent se rejoindre

Le règlement d’exécution 2024/2956 décrit le registre comme une série de modèles structurés.2 Le point le plus utile pour l’architecture des données est la manière dont ces modèles se référencent.

B_02.01 donne une référence unique à chaque accord contractuel avec un prestataire TIC direct. B_02.02 détaille ensuite l’accord au niveau le plus granulaire possible, en reliant notamment le service TIC et la fonction qu’il soutient.2 Lorsqu’un contrat couvre plusieurs services et plusieurs fonctions, l’instruction prévoit d’utiliser autant de lignes que nécessaire pour représenter ces combinaisons.2

B_05.01 identifie les prestataires tiers de services TIC, y compris les prestataires directs, les prestataires intragroupe, les sous-traitants présents dans la chaîne de services et les entreprises mères ultimes concernées.2 B_06.01 identifie les fonctions et leur criticité ou importance.2

Le registre n’est donc pas modélisé sur la relation simpliste « un fournisseur = un contrat = une fonction ». Un même fournisseur peut porter plusieurs accords ; un accord peut couvrir plusieurs services ; un service peut soutenir plusieurs fonctions ; plusieurs entités d’un groupe peuvent utiliser le même service.

La bonne clé de jointure est plus importante que le beau fichier final

Un contrat doit disposer d’une référence durable. Une entité financière est identifiée selon les règles du modèle, notamment par son LEI lorsqu’il est requis. Un prestataire doit utiliser l’identifiant attendu par le règlement. Une fonction doit conserver son identifiant même si son libellé évolue. Le type de service TIC doit s’aligner sur les listes fermées prévues par le modèle.2

À partir de là, Cybercoria recommande de traiter le registre comme un modèle de correspondance entre sources de vérité :

• les contrats, dates, coûts et lois applicables viennent du référentiel contractuel ou achats ;
• l’identité juridique du prestataire vient du référentiel fournisseurs ;
• les fonctions et leur criticité viennent du référentiel métier ou de continuité ;
• les services TIC consommés viennent du catalogue de services ou de l’architecture ;
• les entités utilisatrices viennent de l’organisation et du périmètre de consolidation ;
• les évaluations de risque tiers viennent du dispositif de gestion des risques ;
• les informations de sous-traitance viennent des contrats, annexes, notifications du prestataire et revues de risque.

Ce découpage n’est pas imposé par DORA. Il sert à éviter qu’une même information soit ressaisie et diverge dans plusieurs fichiers.

À lire aussi
Cartographie SI : les 5 étapes de l’ANSSI transformées en plan opérationnel →

B_05.02 change la question : qui fournit réellement le service ?

Le modèle B_05.02 identifie la chaîne de services TIC et classe les prestataires qui y participent par rang.2 Pour les services soutenant une fonction critique ou importante, cette chaîne doit inclure les sous-traitants qui sous-tendent effectivement la fourniture, c’est-à-dire ceux dont la perturbation pourrait affecter la sécurité ou la continuité du service.2

La FAQ EBA confirme cette logique et précise qu’il n’existe pas de limite théorique au rang d’un prestataire dans une chaîne.5 Cela ne signifie pas qu’il faut cartographier indistinctement tous les fournisseurs de chaque fournisseur. Le critère est lié au service concerné et, pour les fonctions critiques ou importantes, aux sous-traitants qui le sous-tendent effectivement.

Le règlement délégué 2025/532 renforce ensuite la dimension de gestion du risque : avant certaines sous-traitances et pendant leur cycle de vie, l’entité financière doit apprécier notamment la longueur et la complexité de la chaîne, la nature des données, la localisation des sous-traitants et les lieux de traitement ou de stockage.4 Il rappelle aussi que s’appuyer sur l’évaluation réalisée par le prestataire ne retire pas à l’entité financière sa responsabilité finale.4

Pour une DSI ou un RSSI, le sujet devient donc concret : peut-on partir d’une fonction importante et retrouver les services, contrats, fournisseurs directs et dépendances de sous-traitance qui peuvent interrompre cette fonction ?

Une fonction critique doit rester un objet métier, pas une étiquette fournisseur

B_06.01 identifie les fonctions de l’entité financière et leur caractère critique ou important ; B_02.02 relie ces fonctions aux services TIC concernés.2 Cette séparation est essentielle.

Écrire « fournisseur critique » dans une base achats ne suffit pas. La criticité vient de la fonction soutenue et du contexte de l’entité. Un même prestataire peut fournir un service qui soutient une fonction critique et un autre service sans ce niveau d’importance.

La modélisation la plus robuste conserve donc la chaîne fonction → service TIC → accord contractuel → prestataire, au lieu de faire porter toute l’information par l’objet « fournisseur ». Cette logique rejoint un principe déjà utile en cartographie SI : la valeur vient des dépendances rendues visibles, pas seulement de la liste des actifs.

Contexte
NIS2, article 21 : ce que la cartographie SI aide réellement à démontrer →

B_07.01 n’est pas une preuve que le risque tiers est maîtrisé

Le modèle B_07.01 concerne l’évaluation des services TIC fournis par des prestataires tiers lorsqu’ils soutiennent une fonction critique ou importante ou une partie importante de celle-ci.2 Il contient des éléments de risque et de substituabilité.

Mais le registre ne remplace pas le dispositif de gestion du risque tiers.

Le règlement délégué 2024/1773 demande une politique couvrant le cycle de vie des accords contractuels relatifs aux services soutenant des fonctions critiques ou importantes : responsabilités, planification, évaluation des risques, diligence raisonnable, approbation, suivi, audit et stratégies de sortie.3 Un champ rempli dans B_07.01 ne démontre donc ni qu’une diligence raisonnable a été correctement réalisée, ni qu’un plan de sortie fonctionne, ni qu’un droit d’audit est opérationnel.

Le registre est un référentiel structuré pour connaître et relier. Les preuves restent dans les contrats, rapports d’audit, décisions de risque, tests de continuité, dossiers de due diligence et autres systèmes concernés.

Le registre doit être maintenu par les événements du SI

DORA emploie les verbes « tenir » et « mettre à jour ».1 Une production annuelle à partir de questionnaires envoyés en urgence peut satisfaire un exercice ponctuel, mais elle fragilise la qualité de la donnée entre deux campagnes.

Une approche plus durable consiste à définir les événements qui doivent déclencher une revue du registre :

1. nouveau contrat ou avenant TIC ;
2. nouveau service consommé sous un contrat existant ;
3. changement de prestataire juridique ou d’identifiant ;
4. changement de fonction soutenue ou de criticité ;
5. nouveau sous-traitant pertinent dans une chaîne critique ;
6. changement de pays de fourniture, traitement ou stockage ;
7. nouvelle évaluation de risque, audit ou décision de substituabilité ;
8. fin de contrat ou remplacement d’un service.

L’objectif n’est pas de transformer chaque événement technique en mise à jour réglementaire. Il est de définir quels changements du SI rendent un champ DORA potentiellement faux.

Construire un contrôle de cohérence avant le contrôle réglementaire

Le caractère relationnel du registre permet des contrôles simples avant toute soumission : un identifiant de fournisseur utilisé dans B_02.02 existe-t-il dans B_05.01 ? Une fonction référencée existe-t-elle dans B_06.01 ? La chaîne B_05.02 est-elle rattachée au bon contrat et au bon type de service ? Une évaluation B_07.01 existe-t-elle lorsque le cas l’exige ? Les références de contrat sont-elles uniques et stables ?2

L’EBA a d’ailleurs publié des FAQ spécifiques au remplissage et aux validations du registre, signe que la qualité du modèle et la cohérence des données sont des sujets opérationnels à part entière.5

Ces contrôles ne prouvent pas la conformité globale à DORA. Ils montrent seulement que le registre est plus cohérent.

Le test décisif : partir d’une fonction et remonter toute la chaîne

Pour savoir si le registre est adossé au SI réel, prendre une fonction critique ou importante et tenter de répondre sans reconstruire l’information manuellement :

Quelle entité utilise le service ? Quel service TIC soutient la fonction ? Quel contrat l’encadre ? Quelle entité juridique le fournit ? Quels sous-traitants sous-tendent réellement ce service ? Où les données sont-elles traitées ou stockées lorsque l’information est requise ? Quelle évaluation de risque et de substituabilité est associée ?

Si ces réponses existent mais vivent dans six référentiels non reliés, le premier chantier n’est pas « remplir le registre ». Il est d’établir des identifiants stables, des propriétaires de données et des règles de synchronisation.

C’est là que le registre DORA devient utile au-delà du reporting : non pas parce qu’il prouve la résilience, mais parce qu’il oblige l’organisation à rendre explicite la chaîne fonction → service → contrat → tiers → dépendances. La prochaine action consiste à tester cette chaîne sur une seule fonction critique, identifier chaque source de vérité et noter les ruptures de jointure. Elles indiquent précisément où le registre risque de devenir faux au prochain changement.