Le registre d’information est l’inventaire de tous les accords avec des prestataires tiers de services TIC sur lesquels une entité financière s’appuie, tenu dans les 15 modèles du règlement d’exécution (UE) 2024/2956 et remis au moins une fois par an à l’autorité compétente — en France l’ACPR (OneGate) ou l’AMF (ROSA). Sa clé primaire est le numéro de référence de l’accord contractuel ; sa partie la plus difficile est l’inventaire des prestataires et des services, parce que les outils SaaS et IA que personne n’a déclarés comptent aussi.
Cette page liste les modèles et leurs champs, le calendrier de remise, ce qu’un inventaire SaaS en lecture seule peut préremplir, et une checklist avant remise. Pour la couverture DORA plus large, voir SSPM pour DORA et le rattachement des contrôles DORA (en anglais).
Qui remet, à qui, et quand
L’article 28, § 3 de DORA impose à chaque entité financière de tenir le registre au niveau individuel et, le cas échéant, sous-consolidé et consolidé, d’y distinguer les accords qui soutiennent des fonctions critiques ou importantes, et de le mettre à disposition de son autorité compétente sur demande et au moins une fois par an sous forme de remise. L’autorité transmet les registres aux autorités européennes de surveillance, qui s’en servent pour désigner les prestataires tiers critiques.
- Date de référence. À partir de 2026, le 31 décembre de l’année civile précédant la date de remise (Q&A EIOPA DORA-253).
- France, ACPR. Cycle 2026 : date de référence 31 décembre 2025, échéance 31 mars 2026, fichiers plain-CSV dans une seule archive .zip déposée depuis la page d’accueil OneGate (domaines DRB pour la banque, DRA pour l’assurance ; niveaux LEI.IND / LEI.CON ; français ou anglais ; sans signature électronique). Le cycle 2025 portait sur le 31 décembre 2024 avec une échéance au 15 avril 2025. Le cycle 2027 est attendu selon la règle affichée — référence 31 décembre 2026, échéance 31 mars 2027 — mais l’avis ACPR n’était pas publié au moment de la rédaction.
- Établissements importants : remise à la BCE via CASPER, pas OneGate.
- France, AMF. Les sociétés de gestion et autres entités supervisées par l’AMF remettent via l’interface ROSA au format des AES ; vérifiez l’avis AMF pour les dates du cycle en cours.
Les 15 modèles
| Modèle | Intitulé officiel | Ce qu’il recense | Champs clés |
|---|---|---|---|
| B_01.01 | Entity maintaining the register of information | L’entité qui remet le registre | LEI (0010), nom, pays, type d’entité, autorité compétente, date de reporting (0060) |
| B_01.02 | List of entities within the scope of consolidation | Les entités du groupe couvertes | LEI, nom, pays, type, position dans le groupe, LEI de la mère directe, dates de mise à jour / intégration / suppression, devise, total de bilan (0110) |
| B_01.03 | List of branches | Les succursales | Code d’identification de la succursale, LEI du siège, nom, pays |
| B_02.01 | Contractual arrangements – general information | Une ligne par contrat avec un prestataire direct | Numéro de référence de l’accord contractuel (0010, attribué par l’entité, stable), type (0020), accord-cadre (0030), devise (0040), dépense annuelle ou coût estimé (0050) |
| B_02.02 | Contractual arrangements – specific information | Contrat × entité × prestataire × fonction × service | Référence, LEI de l’entité utilisatrice, identifiant et type de code du prestataire, identifiant de fonction, type de service TIC (S01–S19), dates de début / fin, préavis, pays du droit applicable, pays de fourniture, stockage de données O/N, pays de stockage et de traitement, sensibilité des données, niveau de dépendance |
| B_02.03 | List of intra-group contractual arrangements | Les liens entre contrats intra-groupe | Référence ↔ référence liée |
| B_03.01 | Entities signing the contractual arrangements for receiving ICT service(s) | Signataires, côté entité | Référence, LEI de l’entité financière signataire |
| B_03.02 | ICT third-party service providers signing the contractual arrangements | Signataires, côté prestataire | Référence, identifiant et type de code du prestataire |
| B_03.03 | Entities signing the contractual arrangements for providing ICT service(s) | Prestataires intra-groupe | Référence, LEI de l’entité du groupe qui fournit le service |
| B_04.01 | Entities making use of the ICT services | Qui utilise chaque service | Référence, LEI, nature succursale / non-succursale, code de succursale |
| B_05.01 | ICT third-party service providers | Une ligne par prestataire | Code d’identification et type (LEI / EUID / CRN / VAT / PNR / NIN), raison sociale, nom en alphabet latin, type de personne, pays du siège, devise, dépense annuelle totale (0100), identifiant de la maison mère ultime |
| B_05.02 | ICT service supply chain | La chaîne de sous-traitance | Référence, type de service, identifiant du prestataire, rang (prestataire direct = 1), bénéficiaire du service sous-traité |
| B_06.01 | Functions identification | Le référentiel des fonctions de l’entité | Identifiant de fonction (0010), activité agréée (annexe II), nom, LEI, évaluation critique ou importante (Oui / Non / non réalisée), motifs, date de la dernière évaluation, RTO, RPO, impact d’une interruption |
| B_07.01 | Assessments of the ICT services | La vue risque des services soutenant des fonctions critiques ou importantes | Référence, identifiant du prestataire, type de service, substituabilité (quatre niveaux), motif, date du dernier audit, plan de sortie O/N, possibilité de réinternalisation, impact d’une interruption, alternatives identifiées, prestataire alternatif |
| B_99.01 | Definitions from entities making use of the ICT Services | Les définitions propres à l’entité | Code de colonne, nom de colonne, option, description |
Identifiants et types de services
Les entités financières sont identifiées par leur LEI uniquement. Les prestataires utilisent l’un de six types de code — LEI, EUID, CRN (numéro d’immatriculation), VAT (TVA), PNR (passeport) ou NIN (identifiant national) — avec la règle suivante : les personnes morales utilisent le LEI ou l’EUID, les personnes morales établies hors de l’Union le LEI seulement, et les autres codes sont réservés aux personnes physiques agissant à titre professionnel.
Chaque ligne de service porte l’un des 19 types de services TIC de l’annexe III (seul le code est déclaré) :
- S01 Gestion de projet TIC
- S02 Développement TIC
- S03 Assistance TIC et support de premier niveau
- S04 Services de gestion de la sécurité TIC
- S05 Fourniture de données
- S06 Analyse de données
- S07 Services TIC, installations et hébergement (hors cloud)
- S08 Calcul
- S09 Stockage de données hors cloud
- S10 Opérateur télécom
- S11 Infrastructure réseau
- S12 Matériel et équipements physiques
- S13 Licences logicielles (hors SaaS)
- S14 Gestion des opérations TIC (maintenance comprise)
- S15 Conseil TIC
- S16 Gestion du risque TIC
- S17 Services cloud : IaaS
- S18 Services cloud : PaaS
- S19 Services cloud : SaaS
Ce qu’un inventaire SaaS en lecture seule peut préremplir
Le registre est centré sur les contrats et un inventaire est centré sur les applications : chaque ligne préremplie doit donc encore être rattachée à une référence d’accord contractuel. Avec cette réserve, un scan en lecture seule des éditeurs SaaS, cloud et IA réellement connectés à vos tenants peut ébaucher :
- B_05.01, identité du prestataire : raison sociale et nom en alphabet latin, type de personne, pays du siège ; LEI ou EUID et maison mère ultime via une recherche GLEIF — mais la filiale contractante (quelle entité Microsoft ou Google) vient du contrat.
- B_02.02, type de service TIC : S19 pour le SaaS, S17 / S18 pour l’infrastructure cloud ; les API d’IA demandent un arbitrage entre S19 et S05 / S06.
- B_02.02, stockage de données (Oui pour presque tout SaaS) et pays de stockage / de traitement lorsque l’API de l’éditeur expose la région du tenant — partiel.
- B_04.01 et B_01.02, rattachement entité ↔ application, lorsque les tenants correspondent à des entités juridiques — partiel.
- B_05.02, sous-traitants de rang 2 et plus, seulement quand l’hébergeur est public ou que la liste des sous-traitants est lisible par machine — partiel.
- B_02.02, date de début, approchée par la date de première apparition de l’intégration — indicative seulement.
Ce qui reste du ressort d’un humain
- Numéros de référence des accords contractuels, type de contrat, liens avec l’accord-cadre et dépense annuelle (B_02.01, B_05.01).
- Dates de début et de fin, préavis, droit applicable, pays de fourniture, identifiant de fonction, sensibilité des données et niveau de dépendance (B_02.02).
- Signataires des deux côtés (B_03.01 à B_03.03).
- Le référentiel des fonctions, l’évaluation du caractère critique ou important, RTO et RPO (B_06.01).
- Substituabilité, plans de sortie, dates d’audit, alternatives et possibilités de réinternalisation (B_07.01).
- Structure du groupe, succursales et total de bilan (B_01.01 à B_01.03) ; vos propres définitions (B_99.01).
- Les applications utilisées sans contrat — offres gratuites, shadow IT — sortent de la notion d’« accord contractuel » ; la façon dont les autorités attendent qu’elles soient traitées n’est pas tranchée dans les textes publiés.
Checklist avant remise
- Confirmer le niveau de remise (individuel, sous-consolidé, consolidé) et la date de référence fixée par votre autorité pour ce cycle.
- Obtenir ou renouveler le LEI de chaque entité du périmètre ; collecter le LEI ou l’EUID de chaque prestataire personne morale (les autres codes sont réservés aux personnes physiques).
- Figer le référentiel des fonctions (B_06.01) avec, pour chacune, une décision sur son caractère critique ou important et une date ; un registre ne se remet pas avec des évaluations « non réalisées » sur des fonctions critiques.
- Exporter l’inventaire des éditeurs SaaS, cloud et IA réellement utilisés — y compris les outils que personne n’a déclarés — et le rapprocher de la liste des contrats.
- Attribuer un numéro de référence stable à chaque accord contractuel : c’est la clé de tous les autres modèles.
- Classer chaque service avec un code S01–S19 et renseigner les pays de stockage et de traitement ligne par ligne.
- Remplir le bloc prestataires (B_05.01) : raison sociale en alphabet latin, pays du siège, dépense annuelle dans la devise de reporting.
- Cartographier la chaîne de sous-traitance (B_05.02) au moins pour les services soutenant des fonctions critiques ou importantes, prestataire direct au rang 1.
- Compléter B_07.01 pour chaque service soutenant une fonction critique ou importante : substituabilité, plan de sortie, dernier audit, alternatives.
- Valider le paquet CSV selon les règles de votre autorité (pour l’ACPR : fichiers plain-CSV dans une seule archive .zip, déposée depuis la page d’accueil OneGate) et conserver l’accusé de réception avec le registre.
Questions fréquentes
Qui doit remettre le registre d’information DORA ?
Toute entité financière dans le champ de DORA (règlement (UE) 2022/2554, art. 28, § 3) : elle tient le registre aux niveaux individuel, sous-consolidé et consolidé, distingue les accords qui soutiennent des fonctions critiques ou importantes, et le remet au moins une fois par an à son autorité compétente, qui le transmet aux autorités européennes de surveillance.
Quelles sont les dates de remise en France ?
Pour le cycle 2026, l’ACPR a fixé la date de référence au 31 décembre 2025 et l’échéance au 31 mars 2026, au format plain-CSV via OneGate. La règle affichée sur les pages DORA de l’ACPR est : date de référence 31 décembre de l’année N, échéance 31 mars de l’année N+1 ; le cycle 2027 est donc attendu au 31 mars 2027, à confirmer à la publication de l’avis ACPR. Les établissements importants remettent à la BCE via CASPER ; les entités supervisées par l’AMF passent par ROSA.
Quel format de fichier est accepté ?
Les autorités européennes publient une taxonomie xBRL-CSV et un paquet « plain CSV » (un CSV par modèle plus un fichier report-package.json, le tout zippé). L’ACPR n’accepte que le plain-CSV en archive .zip ; Excel sert à la préparation et doit être converti. Les autres autorités diffèrent : la CSSF accepte aussi les archives plain-CSV, la DNB accepte le xBRL-CSV converti depuis son modèle Excel.
Quelle part du registre un inventaire SaaS peut-il remplir ?
Le bloc prestataires et les colonnes type de service, stockage de données et, en partie, localisation des données — c’est-à-dire ce qui décrit ce qui est utilisé. Les références de contrat, les coûts, les préavis, le caractère critique des fonctions, les RTO/RPO, la substituabilité et les plans de sortie sont des décisions et des faits contractuels que seules vos équipes juridique, achats et risques peuvent fournir. Black Cat SSPM génère la section prestataires TIC à partir d’un scan en lecture seule des éditeurs SaaS et IA connectés ; voir SSPM pour DORA.
Pages liées
- SSPM pour DORA : automatiser le registre des prestataires TIC
- Rattachement des contrôles DORA dans le catalogue Black Cat (en anglais)
- SSPM pour NIS2 & ReCyF — le référentiel ReCyF n’est pas encore publié ; cette page explique ce qui est rattaché aujourd’hui.
Sources (consultées le 05/09/2026)
- Règlement d’exécution (UE) 2024/2956 (ITS sur le registre d’information), JO L du 2 déc. 2024 — https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj/fra
- Règlement (UE) 2022/2554 (DORA), art. 28 — https://eur-lex.europa.eu/eli/reg/2022/2554/oj/fra
- Calendrier des AES pour la collecte des registres (15/11/2024) — https://www.eiopa.europa.eu/esas-announce-timeline-collect-information-designation-critical-ict-third-party-service-providers-2024-11-15_hr
- EIOPA, Q&A DORA-253 (date de référence à partir de 2026) — https://www.eiopa.europa.eu/qa-regulation/questions-and-answers-database/dora-253-3393_en
- ACPR — FAQ DORA et « Remise des registres d’information » (11/04/2025) — https://acpr.banque-france.fr/fr/actualites/remise-des-registres-dinformation
- ACPR / eSurfi — Modalités de remise de la collecte DORA (banque, 23/06/2026 ; assurance, 16/12/2025) — https://esurfi.banque-france.fr/
- AMF — page DORA (26/02/2025) — https://www.amf-france.org/fr/actualites-publications/dossiers-thematiques/dora
- EBA — Preparation for DORA application : DPM, xBRL-CSV et paquets plain-CSV — https://eba.europa.eu/activities/direct-supervision-and-oversight/digital-operational-resilience-act/preparation-dora-application