Accueil / Ressources / Guide Registre DORA

Guide du Registre d'Informations DORA (2026)

Un guide pratique pour les entités financières qui doivent se conformer à l'exigence de registre d'informations DORA. Découvrez ce que c'est, qui en a besoin, quelles données il doit contenir, comment le construire et quelles erreurs courantes éviter avant votre prochaine soumission prudentielle.

S'applique à

Entités financières réglementées

Couvre

Arrangements TIC avec des tiers

Objectif

Registre prêt à la soumission en XBRL/CSV

Le règlement sur la résilience opérationnelle numérique (DORA) est entré pleinement en vigueur le 17 janvier 2025. Parmi ses obligations fondamentales figure l'exigence pour les entités financières de maintenir un registre d'informations structuré — un inventaire exhaustif de tous les arrangements de services TIC avec des tiers, y compris les sous-traitants et les services intragroupe.

Ce guide explique ce qu'est le registre d'informations DORA, quelles organisations sont tenues de le maintenir, quels champs de données sont imposés et comment structurer un modèle opérationnel durable. Que vous soyez un responsable de la conformité préparant votre première soumission, un gestionnaire des risques examinant la qualité des données, ou un gestionnaire de fournisseurs naviguant entre les responsabilités transversales, ce guide vous accompagne à chaque étape.

Vous apprendrez : ce qu'attendent les régulateurs, quelles entités sont concernées, quelles sont les catégories de données obligatoires, qui doit être responsable de chaque champ, les sept étapes pour construire votre registre, les erreurs les plus fréquentes qui causent des échecs de soumission, et comment des outils dédiés peuvent simplifier la maintenance continue.

Qu'est-ce que le registre d'informations DORA ?

Le registre d'informations DORA (RdI) est un ensemble de données structuré que les entités financières doivent compiler et maintenir en vertu de l'article 28(3) du règlement (UE) 2022/2554. Il répertorie chaque arrangement de service TIC avec un tiers — des fournisseurs d'infrastructure cloud aux plateformes SaaS, services de sécurité gérés, prestataires de paiement et relations TIC intragroupe.

L'objectif du registre est prudentiel. Les autorités compétentes nationales (ACN) et les autorités de surveillance européennes (ABE, AEAPP, AEMF) utilisent le registre pour évaluer le paysage de dépendances TIC d'une entité, identifier les risques de concentration et surveiller la posture de résilience opérationnelle du secteur financier dans son ensemble.

Objectif réglementaire

DORA va au-delà des registres de sous-traitance traditionnels. Les exigences relatives au registre d'informations sont définies dans les normes techniques réglementaires (NTR) communes sur le registre d'informations au titre des articles 28(9) et 30(5) DORA (JC 2023 84). Les NTR spécifient les champs de données exacts, la cardinalité et les règles de validation, et imposent que le registre soit maintenu continuellement à jour.

Reporting prudentiel

Les entités financières sont tenues de fournir leur registre à leur ACN chaque année et sur demande à tout moment. L'ACN peut transmettre les données à l'ASE compétente. Les soumissions doivent être conformes aux modèles de données prescrits (généralement au format CSV ou XBRL), et la validation signalera les champs manquants, les identifiants incohérents et les erreurs d'intégrité référentielle.

Surveillance des risques TIC liés aux tiers

Le registre alimente plusieurs autres obligations DORA. Les évaluations de criticité, les stratégies de sortie et les révisions contractuelles font toutes référence au même inventaire de tiers. Bien construire le registre n'est donc pas un exercice isolé — il ancre l'ensemble de votre cadre de gestion des risques TIC liés aux tiers.

Résilience opérationnelle

Au fond, le registre d'informations DORA est un instrument de résilience opérationnelle. En obligeant les entités à cartographier et documenter chaque dépendance TIC — y compris les quatrièmes parties — il crée une visibilité que la direction et les régulateurs peuvent utiliser pour évaluer si la défaillance d'un seul fournisseur pourrait provoquer une perturbation systémique.

Qui doit maintenir un registre DORA ?

DORA s'applique à un large éventail d'entités financières opérant dans l'Union européenne. L'article 2 du règlement définit le champ d'application, qui couvre la plupart des établissements financiers réglementés.

Établissements de crédit

Banques et prêteurs hypothécaires agréés au titre de la CRD.

Entreprises d'investissement

Entreprises d'investissement agréées MiFID II fournissant des services financiers.

Établissements de paiement

Établissements de paiement et de monnaie électronique agréés PSD2.

Entreprises d'assurance

Assureurs et réassureurs agréés Solvabilité II.

Prestataires de services sur crypto-actifs

PSCA agréés MiCA dès leur intégration supervisée.

CCP, CSD & Référentiels de transactions

Contreparties centrales, dépositaires centraux de titres et prestataires de services de déclaration de données.

Le principe de proportionnalité

DORA reconnaît qu'un petit établissement de paiement ne peut pas être tenu de maintenir la même infrastructure de résilience opérationnelle qu'une banque d'importance systémique. L'article 4 introduit la proportionnalité : les micro-entreprises et les petites entités bénéficient d'un régime simplifié qui réduit certaines exigences de documentation et de gouvernance tout en préservant l'obligation fondamentale de tenue de registre.

Exemptions

Les micro-entreprises (moins de 10 employés et chiffre d'affaires annuel ou bilan inférieur à 2 millions d'euros) bénéficient d'un régime DORA simplifié. Elles sont toujours tenues de maintenir un registre, mais les exigences en matière de gouvernance, de tests et de reporting sont allégées.

Quelles informations doivent être incluses ?

Les NTR communes spécifient un modèle de données détaillé pour le registre d'informations. Le tableau suivant résume les principales catégories de données et des exemples de ce que chacune requiert.

Catégorie Exemples
Informations sur le prestataireDénomination sociale, LEI, pays d'immatriculation, appartenance au groupe
Services TICHébergement, SaaS, MSP, support informatique, services cloud, traitement des paiements
Classification de criticitéCritique / Non critique, fonction ou processus supporté
Détails contractuelsDate de début, date de fin, conditions de renouvellement, préavis de résiliation
Sous-traitantsPrestataires TIC quatrièmes parties, chaînes de sous-traitance, pays d'exploitation
Stratégie de sortieStatut du plan de sortie, prestataires alternatifs identifiés, calendrier de migration
Évaluation des risquesÉvaluations des risques liées, note de risque, date de la dernière évaluation

Informations sur le prestataire

Chaque tiers TIC doit être identifié par un identifiant d'entité juridique (LEI) lorsqu'il est disponible. La dénomination sociale, le pays et la structure du groupe du prestataire doivent être enregistrés. L'utilisation d'identifiants d'entité cohérents et validés est essentielle — les superviseurs les utilisent pour agréger les données entre entreprises et identifier les risques de concentration.

Services TIC

Pour chaque arrangement, vous devez décrire les services TIC fournis. Les NTR utilisent un vocabulaire contrôlé pour les types de services. Les catégories courantes comprennent : les services d'informatique en nuage, l'analyse de données, la colocalisation en centre de données, la maintenance et le support logiciels, les services informatiques gérés, les services de cybersécurité et les services de paiement.

Classification de criticité

Déterminer si un service TIC supporte une fonction critique ou importante (FCI) est l'une des décisions les plus déterminantes dans le registre. Les services critiques attirent une surveillance renforcée, des exigences contractuelles plus strictes et une documentation obligatoire de la stratégie de sortie.

Détails contractuels

Les dates de début et de fin de contrat, les conditions de renouvellement et les préavis de résiliation doivent être exacts et correspondre à vos enregistrements de gestion contractuelle. Les contrats expirés ou reconduits tacitement sans révision sont un défaut de qualité fréquent.

Sous-traitants

DORA étend l'obligation de registre aux sous-traitants — souvent appelés quatrièmes parties — qui participent à la fourniture d'un service TIC critique ou important. Vous devez identifier ces sous-traitants, leur pays d'exploitation et noter les dépendances matérielles.

Stratégie de sortie

Pour chaque arrangement supportant une fonction critique ou importante, le registre doit indiquer si une stratégie de sortie documentée existe, l'état d'avancement de l'identification de prestataires alternatifs et si le plan de sortie a été testé.

Évaluation des risques

Le registre doit relier chaque arrangement à une évaluation des risques. Cela comprend la note de risque globale, la date de la dernière évaluation et les actions correctives ouvertes.

Modèle de propriété du registre DORA

L'une des causes les plus fréquentes de la mauvaise qualité du registre est l'absence d'un modèle de propriété clair. Le registre d'informations DORA est transversal par nature : les données qu'il requiert couvrent les fonctions juridiques, d'approvisionnement, de gestion des risques, de sécurité de l'information et opérationnelles.

Juridique

Propriété des contrats, droit applicable, clauses de résiliation et droits contractuels d'accès et d'audit. Le département juridique doit valider les dates de contrat, les préavis et confirmer si les dispositions requises par DORA sont présentes dans chaque arrangement.

Achats & Gestion des fournisseurs

Identification des fournisseurs, vérification des LEI, demandes de divulgation des sous-traitants et suivi des renouvellements. Les achats détiennent généralement la liste principale des fournisseurs et sont les mieux placés pour identifier les nouveaux arrangements avant qu'ils n'apparaissent dans le registre.

Sécurité de l'information

Notes de risque, évaluations de sécurité, liens avec les incidents et posture de sécurité des sous-traitants. Les équipes de sécurité de l'information détiennent les résultats les plus récents de la diligence raisonnable des fournisseurs et sont responsables de la validation des données de risque technique.

Responsables métier

Criticité des services, fonctions supportées et dépendances opérationnelles. Les responsables métier sont les mieux placés pour évaluer si un service supporte une fonction critique ou importante — ce jugement ne peut pas être porté de manière centralisée sans leur contribution.

Conformité & Supervision réglementaire

Complétude globale du registre, préparation des soumissions et liaison avec l'ACN. La conformité doit posséder le cadre de gouvernance — les règles de qualité, les cadences de révision et les voies d'escalade — même si elle ne possède pas les champs de données individuels.

Un modèle de propriété efficace définit, pour chaque champ de données, quel département fournit les données, quel département les valide, et à quelle fréquence. Cela est généralement documenté dans une matrice RACI.

Erreurs fréquentes dans le registre DORA

Voici les causes les plus fréquentes d'échecs de qualité du registre et de rejets de soumissions, basées sur l'expérience de mise en œuvre auprès des entités financières.

1. Sous-traitants manquants

La plupart des entreprises ont une vision claire de leurs prestataires TIC directs, mais une vision lacunaire des quatrièmes parties. Si votre fournisseur cloud externalise le traitement des données à un sous-traitant, cette relation doit apparaître dans votre registre pour les services critiques.

2. Entrées de fournisseurs en double

Le même fournisseur apparaissant sous différents noms, identifiants ou entités juridiques est un problème de qualité des données qui se propage dans tout le registre. Les calculs de risque de concentration deviennent peu fiables. Utilisez des codes LEI validés et une liste maîtresse canonique des fournisseurs.

3. Classifications de criticité incorrectes

Sur-classer des services comme non critiques réduit la charge de surveillance mais crée un risque réglementaire. Sous-classer des services critiques constitue un manquement substantiel à la conformité. Les classifications doivent être étayées par des évaluations d'impact documentées.

4. Données contractuelles obsolètes

Des dates d'expiration de contrat dépassées, des conditions de renouvellement qui ne reflètent plus l'accord actuel et des préavis de résiliation manquants indiquent un registre qui n'est pas maintenu.

5. Absence de modèle de propriété clair

Sans propriété documentée des données, le registre ne devient la responsabilité de personne. Lorsque des champs sont erronés ou manquants, il n'y a pas de voie claire vers la remédiation.

6. Plans de sortie manquants

La documentation de la stratégie de sortie est requise pour les services critiques, mais de nombreuses organisations ne disposent que d'une politique de sortie générique plutôt que de plans spécifiques à chaque service. DORA exige que vous puissiez démontrer une voie de transition plausible pour chaque arrangement critique.

Comment construire un registre DORA étape par étape

La construction d'un registre d'informations DORA prêt à la soumission est un projet comportant sept phases distinctes. Chaque phase a des livrables et des dépendances clairs.

Étape 1

Définir le périmètre

Identifiez quelles entités juridiques de votre groupe sont dans le champ d'application DORA et si un reporting consolidé ou au niveau de l'entité est requis. Confirmez avec votre ACN le format de soumission requis. Documentez les services dans le périmètre, y compris les arrangements intragroupe.

Étape 2

Inventorier les prestataires TIC

Compilez une liste complète de tous les arrangements de services TIC avec des tiers. Les sources comprennent : les registres de contrats, les systèmes comptables fournisseurs, les inventaires d'actifs informatiques, les listes de fournisseurs de sécurité et les entretiens avec les responsables métier. Validez les dénominations sociales auprès des registres LEI.

Étape 3

Classifier les services

Pour chaque arrangement, déterminez s'il supporte une fonction critique ou importante. Travaillez avec les responsables métier pour évaluer l'impact d'une interruption du service. Documentez la justification. Appliquez le vocabulaire contrôlé des types de services issu des NTR.

Étape 4

Attribuer la propriété

Créez une matrice RACI qui associe chaque champ de données à un propriétaire responsable. Confirmez la propriété avec chaque département. Établissez la cadence de révision pour chaque champ. Intégrez les mises à jour du registre dans les processus existants : signature de contrat, approbation des achats, cycles de révision des fournisseurs.

Étape 5

Valider la qualité des données

Effectuez des contrôles de qualité systématiques sur tous les champs de données avant de considérer le registre comme prêt à la soumission. Les contrôles doivent couvrir : la complétude des champs obligatoires, la validité des valeurs de vocabulaire contrôlé, la logique des dates, l'intégrité référentielle, la détection des doublons et la complétude des sous-traitants pour les services critiques.

Étape 6

Établir la gouvernance

Définissez le modèle de gouvernance continu. Cela comprend : une revue de qualité mensuelle ou trimestrielle avec tous les propriétaires de données ; une voie d'escalade pour les problèmes de qualité non résolus ; un processus de gestion des changements pour les arrangements nouveaux, modifiés ou résiliés ; et une révision annuelle complète des classifications de criticité.

Étape 7

Préparer les soumissions réglementaires

Exportez le registre dans le format requis par votre ACN (généralement CSV aligné sur les modèles de données JTS ou XBRL). Exécutez l'ensemble de règles de validation de l'ASE sur votre export avant soumission — les erreurs détectées en interne sont bien moins coûteuses que celles signalées par votre superviseur.

Exemple de modèle de registre DORA

La structure suivante présente une ligne représentative d'un registre d'informations DORA. Chaque ligne représente un arrangement de service TIC unique. Un même fournisseur peut apparaître dans plusieurs lignes s'il fournit plusieurs services distincts.

Champ Valeur exemple
PrestataireAcme Cloud Services B.V.
LEI5493001KJTIIGC8Y1R12
ServiceInfrastructure cloud (IaaS)
CriticitéCritique
Responsable métierDirecteur des opérations informatiques
Début du contrat2022-01-01
Fin du contrat2027-12-31
Sous-traitantsDataStore GmbH (DE), NetOps Ltd (IE)
Stratégie de sortieDocumentée — alternative identifiée, plan testé en 2024-11
Note de risqueÉlevé
Date de dernière révision2025-03-15

Registre DORA vs registres de sous-traitance traditionnels

De nombreuses entités financières maintiennent déjà une forme de registre d'externalisation ou de fournisseurs — souvent construit pour répondre aux orientations d'externalisation de l'ABE ou aux exigences d'approvisionnement internes. Le registre d'informations DORA est nettement plus exigeant.

Dimension Registre traditionnel Registre DORA
Objectif principalSuivi des fournisseurs & gestion des dépensesRésilience opérationnelle & reporting prudentiel
PérimètreTous les fournisseurs ou services externalisésTous les arrangements TIC, y compris intragroupe
Profondeur des donnéesFocus contrat et coûtDonnées risque, dépendance, sous-traitants & sortie
ReportingUniquement interneSoumission prudentielle annuelle obligatoire
FormatForme libre (Word, Excel)Modèles prescrits avec règles de validation
Quatrièmes partiesGénéralement non capturéesRequises pour les services critiques
CriticitéLimitée ou informelleFormellement évaluée et documentée
Fréquence de mise à jourAnnuelle ou par projetContinue, événementielle plus révision périodique

Si votre organisation maintient déjà un registre d'externalisation ABE, il constitue un point de départ utile — mais il couvrira généralement seulement 60 à 70 % de ce que DORA exige. Les lacunes se situent habituellement dans les données sur les sous-traitants, le lien avec la stratégie de sortie, la formalité de la criticité et le format de soumission réglementaire.

Comment RiskNow aide à maintenir un registre DORA

RiskNow est une plateforme GRC créée par des praticiens ayant déployé des programmes DORA dans des entités financières. La plateforme propose un module dédié au registre d'informations qui vous aide à maintenir un inventaire complet de tiers, à retracer les dépendances de la chaîne d'approvisionnement et à préparer des sorties réglementaires prêtes à la soumission.

Registre des tiers

Maintenez un registre structuré des tiers TIC avec les données des entités juridiques, les LEI, les correspondances de services, la classification de criticité, les détails du cycle de vie des contrats et les propriétaires de champs responsables.

Visibilité de la chaîne d'approvisionnement

Cartographiez les sous-traitants et les quatrièmes parties dans votre chaîne d'approvisionnement TIC, reliez les dépendances aux services critiques et conservez un enregistrement auditable des risques de concentration et de résilience.

Reporting qualité des données (100+ contrôles)

Exécutez des rapports de qualité des données avec plus de 100 contrôles automatisés couvrant la complétude, les valeurs contrôlées, la détection des doublons, la logique des dates et l'intégrité référentielle avant soumission.

Exports réglementaires (XBRL / CSV)

Exportez les données du registre vers des formats XBRL et CSV prêts à la réglementation, alignés sur les modèles de supervision, avec une validation pré-export pour détecter les problèmes avant le dépôt.

Contrôles de qualité des données DORA RiskNow — validation automatisée sur les champs obligatoires, la logique des dates et l'intégrité référentielle

En connectant les tiers, les relations de la chaîne d'approvisionnement, les contrats, les évaluations des risques et les incidents dans un seul modèle, RiskNow réduit les rapprochements manuels et aide les équipes à maintenir le registre précis entre les cycles de soumission annuels.

Questions fréquentes

Qu'est-ce qu'un registre d'informations DORA ?

Le registre d'informations DORA est un inventaire structuré de tous les arrangements de services TIC avec des tiers maintenus par une entité financière en vertu de l'article 28(3) du règlement (UE) 2022/2554. Il couvre les prestataires, les services, la criticité, les contrats, les sous-traitants et les évaluations des risques.

Le registre DORA est-il obligatoire ?

Oui. Toutes les entités financières dans le champ d'application doivent maintenir un registre d'informations et le fournir à leur autorité compétente nationale annuellement ou sur demande. Le non-respect peut entraîner des mesures de supervision incluant la divulgation publique, des amendes et des ordres de remédiation.

À quelle fréquence le registre DORA doit-il être mis à jour ?

Le registre doit être maintenu continuellement à jour. En pratique, cela signifie des mises à jour événementielles pour les nouveaux arrangements, les modifications matérielles de contrats et les services résiliés — complétées par une révision de qualité périodique (mensuelle ou trimestrielle) et une actualisation annuelle complète avant la fenêtre de reporting prudentiel.

Que sont les services TIC critiques ?

Les services TIC critiques sont ceux qui supportent une fonction critique ou importante (FCI) — une fonction dont la défaillance ou la dégradation altérerait substantiellement la conformité réglementaire, la solidité financière ou la prestation de services de l'entité. La criticité doit être évaluée par une analyse d'impact documentée et révisée au moins annuellement.

Les sous-traitants doivent-ils être inclus dans le registre ?

Oui, pour les services critiques et importants. Vous devez identifier les sous-traitants (quatrièmes parties) qui font partie de la chaîne de fourniture d'un service critique et les inclure dans le registre. Cela nécessite un engagement proactif avec les prestataires primaires pour obtenir la divulgation de leurs chaînes d'approvisionnement.

Comment DORA diffère-t-il des orientations d'externalisation de l'ABE ?

Les orientations d'externalisation de l'ABE se concentrent principalement sur la gouvernance, les exigences contractuelles et les obligations de notification pour l'externalisation matérielle. DORA va plus loin : il couvre tous les arrangements TIC (pas seulement l'externalisation matérielle), impose la divulgation des sous-traitants pour les services critiques, exige des stratégies de sortie formellement documentées et introduit un registre de reporting prudentiel standardisé avec des champs de données prescrits.

Excel peut-il être utilisé pour maintenir le registre DORA ?

Techniquement oui, mais en pratique cela crée des risques opérationnels significatifs. Les registres Excel peinent avec le contrôle d'accès, la gestion des versions, l'intégrité référentielle entre tables et les pistes d'audit. Pour les grandes entités, une plateforme dédiée est fortement recommandée.

Quels champs de données sont requis par le registre DORA ?

Les NTR communes spécifient des champs obligatoires comprenant : dénomination sociale et LEI du prestataire, type de service TIC, fonction supportée, classification de criticité, dates de début et de fin de contrat, préavis de résiliation, détails des sous-traitants (pour les services critiques), statut de la stratégie de sortie et lien avec l'évaluation des risques.

Que se passe-t-il si le registre DORA est incomplet à la soumission ?

Un registre incomplet ou inexact peut entraîner : le renvoi de la soumission pour correction par l'ACN, un dialogue prudentiel formel sur les faiblesses de gouvernance des données, ou — en cas de manquements persistants — des mesures de supervision renforcées. Les défaillances répétées sont considérées comme la preuve de déficiences plus larges en matière de résilience opérationnelle.

Speak with an expert

Talk to an experienced consultant about your objectives. We'll help you understand what it takes and how RiskNow can accelerate your path to compliance.