Registre d’information DORA : contenu, remise à l’autorité et qualité des données

Qu’est-ce que le registre d’information DORA ?

Le règlement (UE) 2022/2554, dit DORA, s’applique depuis le 17 janvier 2025 (article 64). Son article 28 fait de la gestion des prestataires tiers de services TIC une partie intégrante du cadre de gestion du risque lié aux TIC. Le paragraphe 3 en tire une obligation documentaire précise : les entités financières « tiennent et mettent à jour, au niveau de l’entité et aux niveaux sous-consolidé et consolidé, un registre d’informations en rapport avec tous les accords contractuels portant sur l’utilisation de services TIC fournis par des prestataires tiers de services TIC ».

L’article 3 fixe le périmètre. Un prestataire tiers de services TIC est simplement « une entreprise qui fournit des services TIC » (point 19) : éditeur SaaS, hébergeur, infogérant, opérateur réseau. Les prestataires intra-groupe entrent aussi dans le registre (point 20). Une fonction critique ou importante est une fonction dont la perturbation est susceptible de nuire sérieusement à la performance financière de l’entité, à la continuité de ses services ou au respect des conditions de son agrément (point 22).

Le registre distingue les accords qui couvrent des services soutenant des fonctions critiques ou importantes de ceux qui ne le font pas. Cette distinction commande le niveau de détail, la sous-traitance à documenter et l’évaluation à conduire.

Le registre sert trois usages, que les autorités européennes de surveillance (AES) rappellent dans leur rapport sur l’exercice à blanc de 2024 : un outil interne de suivi du risque lié aux tiers TIC, une source pour les autorités compétentes, et la base de la désignation des prestataires tiers critiques (article 31). Le 18 novembre 2025, les AES ont publié la première liste de ces prestataires critiques, établie à partir des données des registres (ESMA).

Qui tient le registre, et à quel niveau ?

L’obligation pèse sur l’entité financière. Dans un groupe, le règlement d’exécution (UE) 2024/2956 du 29 novembre 2024, adopté en application de l’article 28, paragraphe 9, de DORA, précise que le registre consolidé comprend toutes les entités financières et tous les prestataires TIC intra-groupe (article 6), et que l’entité qui le tient veille à la cohérence entre les niveaux (article 3, paragraphe 3).

L’article 3 impose aussi six principes de qualité des données : exactitude, exhaustivité, cohérence, intégrité, uniformité et validité.

Le texte ne dit pas quelle équipe tient le registre. Ses données viennent de sources qui se parlent rarement : achats et juridique pour les contrats, métiers pour les fonctions, DSI pour les services, RSSI et contrôle des risques pour l’évaluation. Dans nos missions, nous constatons que les registres les plus fiables ont un propriétaire unique et des contributeurs identifiés par bloc de données.

Ce que contient le registre : les modèles du règlement 2024/2956

Le règlement d’exécution fixe quinze modèles, chacun sous forme de tableau à colonnes prédéfinies et à nombre de lignes libre (article 4). Ils sont reliés entre eux par des clés, au premier rang desquelles le numéro de référence de l’accord contractuel : une référence interne, attribuée par l’entité, qui doit rester unique et stable dans le temps.

La chaîne de sous-traitance

L’article 1 du règlement définit la chaîne d’approvisionnement des services TIC comme la séquence d’accords qui part du prestataire direct et passe par ses sous-traitants. L’article 2 attribue à chaque prestataire un rang : le prestataire direct a toujours le rang 1, un sous-traitant un rang supérieur.

L’étendue de cette obligation est souvent mal comprise. L’article 3, paragraphe 2, exige les informations utiles sur tous les services fournis par des prestataires directs, mais les sous-traitants qui sous-tendent de fait le service uniquement pour les services qui soutiennent des fonctions critiques ou importantes. Pour un outil de notes de frais, le rang 1 suffit ; pour la plateforme de gestion des contrats d’assurance, il faut l’hébergeur, et le fournisseur de sauvegarde de cet hébergeur s’il sous-tend réellement le service.

L’identification des prestataires

L’article 3, paragraphe 5, impose un identifiant d’entité juridique (LEI) valide et actif, ou l’identifiant unique européen (EUID) des registres du commerce, et les deux lorsqu’ils existent, pour tous les prestataires personnes morales. Les instructions de l’annexe I précisent que seul le LEI est admis pour une personne morale établie hors de l’Union. Pour les sous-traitants des services qui soutiennent des fonctions critiques ou importantes, l’entité obtient ces identifiants par l’intermédiaire du prestataire direct (article 3, paragraphe 6).

Ce n’est pas un formalisme : pour désigner les prestataires critiques, les AES agrègent les registres de nombreuses entités. Sans identifiant commun, trois graphies d’une même raison sociale restent trois prestataires distincts.

À quelle fréquence le registre est-il communiqué à l’autorité ?

Le texte de DORA prévoit trois flux distincts (article 28, paragraphe 3) :

• sur demande : l’entité met à disposition de l’autorité compétente le registre complet ou des sections de celui-ci ;
• au moins une fois par an : elle communique le nombre de nouveaux accords, les catégories de prestataires, le type d’accords et les services et fonctions fournis ;
• en temps utile : elle informe l’autorité de tout projet d’accord portant sur des services qui soutiennent des fonctions critiques ou importantes, et lorsqu’une fonction devient critique ou importante.

L’article 31, paragraphe 10, demande en outre aux autorités compétentes de transmettre chaque année ces informations au forum de supervision, pour la désignation des prestataires critiques.

En pratique, les autorités françaises ont organisé une remise annuelle. Lors de son webinaire du 23 janvier 2026, l’ACPR indique qu’elle « demande actuellement une transmission annuelle de ces registres pour ses besoins de supervision » : cadre de gestion des risques de tiers, interdépendances, risque de concentration, incidents survenus par un tiers. Pour la campagne 2026, la plateforme a ouvert le 1er janvier, la date limite de remise était le 31 mars 2026 et la date d’arrêté des données le 31 décembre 2025. La remise passe par le portail OneGate (domaine DRA pour l’assurance, DRB pour la banque), au format xBRL-CSV dit « plain CSV », dans une enveloppe XML.

La collecte ACPR couvre notamment les établissements de crédit non classés comme importants, les établissements de paiement et de monnaie électronique, les entreprises d’investissement, les organismes d’assurance et de réassurance relevant de Solvabilité II. Les établissements de crédit importants n’y figurent pas : leur canal est à confirmer auprès de leur superviseur. Les sociétés de gestion relèvent de l’AMF, qui collecte le registre par son extranet ROSA, au moins une fois par an à date fixe. Le calendrier des campagnes suivantes se vérifie chaque année auprès de chaque autorité.

Les erreurs de qualité de données les plus fréquentes

L’exercice à blanc de 2024 donne la mesure du sujet. Sur 947 registres analysés par les AES, 6,5 % ont passé l’ensemble des 116 contrôles de qualité. L’information obligatoire manquante représentait 86 % des erreurs, les codes LEI invalides 6,5 %. L’ACPR attend de la collecte 2026 qu’elle permette d’« améliorer la qualité des données transmises ». Voici les erreurs documentées par ces deux sources.

1. Identifiants de prestataires absents. C’est l’information obligatoire la plus souvent manquante dans l’exercice à blanc : type de code et code d’identification du prestataire non renseignés dans les accords (B_02.02) et dans l’évaluation (B_07.01). Contrôle : aucune ligne de prestataire sans LEI ou EUID.
2. Mère ultime non identifiée. Le pays du siège et l’identifiant de l’entreprise mère ultime manquaient souvent dans B_05.01. C’est pourtant ce qui permet de regrouper les filiales d’un même prestataire et de mesurer une concentration.
3. Code national à la place du LEI de l’entité financière. Les AES ont relevé plus de LEI invalides pour les entités financières (près de 9 000) que pour les prestataires (près de 6 000), souvent parce qu’un code national avait été saisi.
4. LEI non renouvelé. Le règlement exige un LEI « valide et actif ». Dans la base de la GLEIF, un LEI non renouvelé à sa date d’échéance prend le statut LAPSED (GLEIF) : à repérer avant la remise.
5. Noms hétérogènes. Les AES notent une forte variabilité des raisons sociales saisies. Le nom ne doit jamais servir de clé.
6. Chaîne de sous-traitance incomplète ou mal classée. Sous-traitant rattaché au mauvais destinataire, rang 1 attribué à un sous-traitant, sous-traitants omis pour un service qui soutient une fonction critique ou importante.
7. Fonctions incohérentes. Un identifiant de fonction cité dans les accords mais absent de B_06.01, ou une criticité sans date de dernière évaluation.
8. Évaluation B_07.01 lacunaire. C’est le modèle où les valeurs manquantes étaient les plus concentrées : substituabilité, réintégration, alternatives. Faute d’audit du prestataire, les instructions demandent d’indiquer « 9999-12-31 », ce qui rend l’absence d’audit visible.
9. Erreurs techniques de remise. L’ACPR cite trois causes de rejet : date limite saisie à la place de la date d’arrêté, arborescence de fichiers différente de l’exemple de l’Autorité bancaire européenne, encodage ANSI au lieu d’UTF-8.

Relier le registre au risque cyber réel des prestataires

Le registre décrit des contrats, des fonctions et des dépendances, pas l’état de sécurité d’un prestataire. Le modèle B_07.01 contient la date du dernier audit et l’existence d’un plan de sortie, mais aucun champ sur l’exposition technique.

Pourtant, DORA demande plus qu’un inventaire. Avant de contracter, l’entité évalue les risques et fait preuve de diligence (article 28, paragraphe 4). Elle ne contracte qu’avec des prestataires qui respectent des normes adéquates de sécurité de l’information (paragraphe 5), et doit pouvoir résilier si le suivi révèle des faiblesses avérées dans leur gestion du risque TIC (paragraphe 7).

Le registre devient utile au RSSI quand il sert de colonne vertébrale à cette évaluation. Quatre principes permettent de le relier au risque réel :

• Une même clé partout. Le LEI ou l’EUID du prestataire sert d’identifiant commun au registre, au dossier d’évaluation et aux outils de suivi. Sans clé commune, conformité et sécurité tiennent deux listes qui divergent vite.
• Une évaluation proportionnée à la criticité. Le registre dit quels prestataires soutiennent une fonction critique ou importante, avec quelle dépendance et quelle substituabilité. Il fixe la profondeur de l’évaluation : questionnaire simple pour un service secondaire, preuves, rapports d’audit et suivi continu pour un prestataire difficile à remplacer.
• Un signal d’exposition externe. Pour les prestataires critiques, l’observation non intrusive de ce qu’ils exposent sur Internet (services accessibles, certificats, configuration de messagerie) complète les réponses déclaratives. Tout test actif suppose l’accord écrit du prestataire.
• Une mise à jour sur événement. Un incident chez un prestataire, un changement de sous-traitant ou de localisation des données, une fonction qui devient critique : chacun déclenche la révision de la ligne, sans attendre la campagne annuelle.

Pour la logique d’ensemble du suivi des tiers, voir notre page sur la gestion des risques tiers et, pour le cadre réglementaire complet, notre page DORA. Pour une entité financière, DORA s’applique à la place des mesures de l’article 21 de NIS2 détaillées dans notre checklist chaîne d’approvisionnement.

Bearlink, seul TPRM intégré à une plateforme complète de Red Team automatisée (Beareye), rattache la notation cyber de chaque prestataire au suivi documentaire et contractuel.

Exemple : rapprocher le registre et l’exposition d’un prestataire

Exemple type, fictif. Un assureur de taille intermédiaire prépare sa remise annuelle. Son registre compte quelques centaines d’accords TIC, dont une trentaine soutiennent des fonctions critiques ou importantes.

Première passe : les identifiants. Une dizaine de prestataires n’ont ni LEI ni EUID, et deux LEI apparaissent au statut LAPSED. Les achats relancent les prestataires ; le registre est corrigé avant la remise.

Seconde passe : l’exposition externe des prestataires critiques. Pour l’éditeur de la plateforme de gestion des sinistres, le registre indique un hébergeur en France au rang 2. L’observation des services exposés par l’éditeur montre un hébergement chez un autre fournisseur, hors de l’Union. Interrogé, l’éditeur confirme une migration partielle non notifiée.

Trois suites sont consignées : la chaîne de sous-traitance et la localisation des données sont mises à jour ; l’écart est traité au regard de la clause sur le changement de lieux de traitement (article 30, paragraphe 2, point b, de DORA) ; un audit est planifié, la date du dernier audit portant la valeur « 9999-12-31 ».

Ce scénario est construit à partir de situations courantes en mission, pas à partir d’un client identifiable.

Limites de ce guide

Un registre exact n’est pas un prestataire sûr. Il prouve que l’entité connaît ses dépendances, pas que ses prestataires sont protégés. Un registre qui passe tous les contrôles peut décrire avec précision un prestataire compromis.

Les modalités de remise évoluent. Règles de validation, format et calendrier sont fixés par les AES et par chaque autorité, et ont changé entre les campagnes. Les dates citées sont celles de la campagne 2026 de l’ACPR ; elles ne préjugent pas des suivantes.

La sous-traitance dépend du prestataire direct. Sans clause qui l’oblige à transmettre les informations et identifiants de ses sous-traitants, le registre restera incomplet là où il compte le plus.

L’observation externe a ses angles morts. Elle voit ce qu’un prestataire expose, pas l’intérieur de son système d’information. Elle complète questionnaires, certifications et audits ; elle ne les remplace pas.