Modèle de registre d'informations DORA (NTE 2024/2956)

Pour constituer le registre d'informations DORA sur les prestataires TIC, il faut remplir les 15 modèles du règlement d'exécution (UE) 2024/2956, de B_01.01 à B_99.01, reliés par des clés communes. Cette page reprend leurs codes de colonnes officiels, un exemple fictif complet et les contrôles qui font échouer une remise. Base légale : l'article 28, paragraphe 3, de DORA.

Le registre d'informations est un ensemble de 15 tableaux liés qui décrit chaque accord contractuel portant sur des services TIC conclu par une entité financière, ou par son groupe, avec des prestataires tiers de services TIC, prestataires intragroupe compris. Les tableaux sont reliés par quatre clés : le numéro de référence de l'accord contractuel, l'identifiant des entités et des prestataires (LEI ou EUID), l'identifiant de la fonction et le type de services TIC (considérant 8 du règlement d'exécution).

Cette page est le modèle lui-même. Le périmètre, la gouvernance, la méthode de construction et la remise sont expliqués dans le guide du registre d'informations DORA ; le cadre d'ensemble est résumé sur la page DORA.

À télécharger, gratuitement et sans inscription : classeur Excel (.xlsx).

Quels modèles composent le registre d'informations ?

Les clés primaires proviennent du Data Model for DORA RoI publié par les autorités européennes de surveillance (AES) avec le dossier technique de déclaration. Une colonne clé ne peut jamais être vide dans un fichier remis.

Quelles colonnes contient chaque modèle ?

Les tableaux reprennent les codes et intitulés de l'annexe I du règlement d'exécution (normes techniques d'exécution, NTE). La colonne « Obligation » résume l'option de remplissage ; les listes fermées figurent à l'annexe I (types d'entités, rang hiérarchique, motifs de résiliation), à l'annexe II (activités autorisées) et à l'annexe III (types de services TIC S01 à S19).

B_01.01 — Entité tenant le registre d'informations

B_01.02 — Liste des entités comprises dans le périmètre de consolidation

B_01.03 — Liste des succursales

B_02.01 — Accords contractuels, informations générales

B_02.02 — Accords contractuels, informations spécifiques

B_02.03 — Liste des accords contractuels intra-groupe

B_03.01, B_03.02 et B_03.03 — Signataires

B_04.01 — Entités ayant recours aux services TIC

B_05.01 — Prestataires tiers de services TIC

B_05.02 — Chaîne d'approvisionnement des services TIC

B_06.01 — Identification des fonctions

L'annexe des NTE saute le code 0050 dans ce modèle, alors que la présentation annotée et le modèle de données des AES numérotent ces mêmes colonnes de c0010 à c0100, sans trou. La colonne « CSV » donne l'en-tête attendu dans le fichier de déclaration.

B_07.01 — Évaluations des services TIC

B_99.01 — Définitions des entités ayant recours aux services TIC

B_99.01 contient une définition interne pour chaque option de six listes fermées : type d'accord contractuel (B_02.01.0020), caractère sensible des données (B_02.02.0170), incidence de l'interruption de la fonction (B_06.01.0110), substituabilité (B_07.01.0050), possibilité de réintégration (B_07.01.0090) et incidence de la cessation des services TIC (B_07.01.0100). Les NTE le présentent en lignes R0010 à R0190 et colonnes C0010 à C0040 ; la présentation de déclaration des AES le transforme en une seule ligne de 19 colonnes (0010 à 0190), une par option.

À quoi ressemble un registre rempli ?

L'exemple ci-dessous est fictif. Example Bank SA est un établissement de crédit belge qui tient un registre consolidé pour elle-même et pour sa filiale Example Tech Services SRL, prestataire intragroupe de services TIC. Elle recourt à deux prestataires TIC : Example Tech Services SRL, qui exploite la plateforme bancaire centrale, et Nimbus Cloud Europe BV, prestataire d'infrastructure externe engagé par Example Tech Services SRL pour héberger cette plateforme.

Les LEI sont inventés pour l'exemple : ils passent le contrôle de format (18 caractères puis deux chiffres de contrôle) mais n'existent pas dans la base GLEIF et ne doivent jamais être déclarés.

B_01.01 (entité qui tient le registre)

B_01.02 (entités du périmètre)

L'entreprise mère répète son propre LEI en 0060 : la FAQ de déclaration des AES le demande quand une entité n'a pas d'entreprise mère directe (Q&A DORA 2024_7278). Le total des actifs reste vide pour l'entité non financière.

B_02.01 (accords) et B_02.03 (lien intragroupe)

CA-2023-001 est le contrat intragroupe entre la banque et Example Tech Services SRL ; CA-2023-002 est le contrat entre Example Tech Services SRL et Nimbus Cloud Europe BV. Les deux figurent dans B_02.01, et B_02.03 les relie.

B_02.02 (une ligne par accord, entité, prestataire, fonction et service ; colonnes principales)

La plateforme soutient deux fonctions : chaque accord prend donc deux lignes (article 4, paragraphe 2, des NTE : une seule valeur par champ, une ligne de plus par valeur supplémentaire). « Sans objet » (Not applicable) remplit la colonne clé 0150 quand aucune donnée n'est stockée (Q&A DORA 2024_7280). Les autres colonnes (préavis, droit applicable, sensibilité des données) figurent dans le fichier téléchargeable.

B_03.01, B_03.02, B_03.03 et B_04.01 (qui signe, qui fournit, qui utilise)

B_05.01 (prestataires et entreprises mères ultimes) et B_05.02 (chaîne d'approvisionnement)

Example Bank SA figure dans B_05.01 parce qu'elle est l'entreprise mère ultime d'un prestataire TIC : le code de l'entreprise mère ultime indiqué en 0110 doit exister comme ligne de prestataire (règle 807). Nimbus Cloud Europe BV a signé avec une entité du groupe pour servir la banque : c'est donc un prestataire direct (article 1er, point 1 b), des NTE), au rang 1. Pour le rang 1, les AES demandent de répéter le code du prestataire en 0060 plutôt que de laisser la clé vide (Q&A DORA 2024_7284).

B_06.01 (fonctions, codes des NTE) et B_07.01 (évaluation, colonnes principales)

Le RTO et le RPO s'expriment en heures : 1 en dessous d'une heure, 0 s'ils ne sont pas définis. Chaque combinaison de LEI, d'activité autorisée et de fonction reçoit son propre identifiant (F1, F2…).

Dans un fichier de déclaration, les valeurs des listes fermées et les pays sont remplacés par les codes des AES (par exemple eba_GA:BE pour la Belgique, eba_GA:qx2007 pour « Sans objet »).

Quels contrôles de cohérence font échouer une remise ?

Les AES appliquent trois niveaux de contrôle à chaque fichier : contrôles techniques, règles de validation du modèle de points de données (DPM) et contrôles métier sur les données de référence. Une erreur technique entraîne le rejet du fichier ; les autres anomalies sont des avertissements, mais les autorités attendent une nouvelle remise corrigée. Les codes de règle ci-dessous sont ceux publiés par les AES et expliqués par la CSSF.

Quelles clés doivent correspondre d'un modèle à l'autre ?

Qu'ont appris l'exercice à blanc et les premières remises ?

• Lors de l'exercice à blanc des AES en 2024, 6,5 % des 947 registres analysés ont passé les 116 contrôles de qualité ; l'absence d'informations obligatoires expliquait 86 % des anomalies, surtout dans B_02.02 et B_07.01.
• Près de 9 000 LEI invalides ont été déclarés pour les entités financières elles-mêmes, souvent des numéros nationaux saisis dans un champ LEI.
• Dans leurs constats de mai 2025 sur la première déclaration officielle, les AES relevaient 58 170 EUID au format invalide, contre 2 717 trouvés dans BRIS et 258 introuvables.
• L'ACPR a constaté des règles de validation modifiées pendant la période de remise 2025 ; en 2026, les rejets venaient d'une date d'arrêté erronée (2025-12-31 attendu, pas la date limite de remise), d'une arborescence d'archive incomplète et de fichiers qui n'étaient pas en UTF-8.
• Pour 2026, la CSSF indiquait que les contrôles des AES n'avaient pas changé depuis avril 2025 mais s'appliqueraient à davantage de champs.

Comment tenir le registre au niveau du groupe (consolidé) ?

• Périmètre. L'entreprise mère fixe le périmètre selon les règles de consolidation sectorielles ; un registre sous-consolidé ou consolidé inclut toutes les entités financières et tous les prestataires TIC intragroupe du groupe (article 6 des NTE).
• Un registre, trois niveaux. Un groupe peut tenir un registre unique valable aux niveaux individuel, sous-consolidé et consolidé, à condition que chaque entité puisse en extraire et déclarer sa partie (considérant 2 des NTE).
• Ce qui part vers les AES. Les registres sont déclarés au niveau individuel pour une entité hors groupe, ou dont l'entreprise mère est hors de l'Union sans mère dans l'Union, et sinon au plus haut niveau de consolidation dans l'Union (FAQ de déclaration des AES).
• Rang hiérarchique. B_01.02.0050 situe chaque entité : mère ultime, mère d'une partie sous-consolidée, filiale, entité hors groupe, ou prestataire auquel toutes les activités opérationnelles sont sous-traitées ; on retient le niveau le plus élevé applicable.
• Identifiants partagés. Un seul numéro de contrat, un seul code prestataire et un seul identifiant de fonction par objet, pour toutes les entités ; la cohérence entre niveau individuel et consolidé est une obligation explicite (article 3, paragraphe 3, des NTE).
• Chaînes intragroupe. Déclarer le contrat intragroupe et le contrat externe dans B_02.01, puis les relier dans B_02.03. Les entités du groupe établies hors de l'Union qui servent des entités de l'Union sont des prestataires intragroupe.

Pour les autres piliers de DORA, la liste de contrôle de préparation à DORA (Excel, 45 exigences) complète ce modèle.

Questions fréquentes

Existe-t-il un modèle Excel officiel ?

Les modèles juridiques figurent à l'annexe des NTE. Pour la déclaration, les AES publient un dossier au format CSV simple (taxonomie, modèle de données, règles de validation) ; le classeur Excel et l'outil de conversion diffusés pour l'exercice à blanc de 2024 étaient des outils de préparation.

Faut-il inscrire les services TIC qui ne soutiennent pas de fonction critique ?

Oui. L'article 28, paragraphe 3, vise tous les accords contractuels portant sur des services TIC. Plusieurs colonnes, et le modèle B_07.01, ne concernent que les services qui soutiennent une fonction critique ou importante.

Quels sous-traitants faut-il déclarer ?

Seulement ceux qui sous-tendent effectivement des services TIC soutenant des fonctions critiques ou importantes (article 3, paragraphe 2, point b), des NTE).

Que faire si un prestataire n'a pas de LEI ?

Une personne morale de l'Union s'identifie par un LEI ou un EUID ; une personne morale hors de l'Union, par un LEI uniquement ; les codes alternatifs (numéro d'entreprise, TVA, passeport, numéro national) sont réservés aux personnes physiques agissant à titre professionnel. Les AES acceptent un autre identifiant pour un prestataire de pays tiers sans LEI : il est signalé comme anomalie de qualité, sans rejet.

À quelle fréquence le mettre à jour et le déclarer ?

Il est tenu à jour en continu, déclaré au moins une fois par an et transmis en entier sur demande (article 28, paragraphe 3, de DORA). La prochaine date d'arrêté est le 31 décembre 2026.

Sources

• Règlement (UE) 2022/2554 (DORA), article 28, paragraphe 3
• Règlement d'exécution (UE) 2024/2956 de la Commission, modèles du registre d'informations
• ABE – Préparation de la déclaration des registres d'informations DORA (modèle de données, taxonomie, règles de validation)
• AES – FAQ sur la déclaration du registre, version du 28 mars 2025 (en anglais)
• AES – Constats sur les remises du registre : problèmes fréquents (mis à jour le 16 mai 2025, en anglais)
• AES – Résultats de l'exercice à blanc 2024 (17 décembre 2024)
• Q&A ABE 2024_7278 (entreprise mère directe), 2024_7280 (lieu de stockage), 2024_7284 (destinataire au rang 1)
• CSSF – Guide d'interprétation des messages d'erreur des AES (15 mai 2025, en anglais)
• CSSF – Délai de soumission du registre d'information 2026
• BNB – Domaine OneGate DOR (DORA_ROI)
• ACPR – Webinaire DORA du 23 janvier 2026