Registre d’information DORA : comment le construire et le maintenir avec votre plateforme SASE

Chaque entité financière réglementée par la loi DORA doit soumettre un registre d’informations à son autorité de surveillance nationale. Les premiers cycles de soumission au début de l’année 2026 ont révélé une réalité douloureuse : environ 235 000 erreurs de validation dans plus de 1 000 institutions participantes au cours de la phase d’essai du SEC. La plupart des erreurs provenaient de champs manquants, d’identifiants incorrects et de données contractuelles incomplètes. Si votre équipe travaille encore à partir de feuilles de calcul, les chances ne sont pas en votre faveur.

Ce guide explique ce que le registre exige, comment le construire à partir de zéro, quelles sont les erreurs qui entraînent le rejet des soumissions et comment votre architecture de sécurité détermine directement le degré de complexité du registre. Pour un aperçu plus large de la manière dont SASE s’articule avec les cinq piliers de DORA, consultez notre guide de SASE pour les services financiers sous DORA.

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

Le registre d’informations DORA est un ensemble de données structurées que les entités financières doivent conserver en vertu de l’article 28, paragraphe 3, de la loi sur la résilience opérationnelle numérique. Il documente chaque accord contractuel avec des fournisseurs de services TIC tiers, y compris les conditions contractuelles, les lieux de stockage des données, les évaluations de la criticité, les chaînes de sous-traitance et les stratégies de sortie. Les autorités de surveillance nationales utilisent le registre pour surveiller le risque de concentration dans le système financier. Les autorités européennes de surveillance peuvent s’appuyer sur les données agrégées du registre pour désigner les fournisseurs de TIC critiques devant faire l’objet d’une surveillance directe.

Ce que l’article 28 de la loi DORA exige dans le registre

L’article 28, paragraphe 3, impose aux entités financières de tenir un registre complet au niveau de l’entité, au niveau sous-consolidé et au niveau consolidé. Il ne s’agit pas d’une simple liste de fournisseurs. Il s’agit d’un ensemble de données relationnelles couvrant 15 modèles interconnectés définis par les normes techniques de mise en œuvre (ITS) de l’ABE, publiées dans le cadre du Reporting Framework 4.0.

Chaque modèle aborde une dimension différente de la relation entre les TIC et les tiers. Les principaux modèles et leurs domaines d’intérêt :

Les modèles forment une structure relationnelle. L’identifiant d’un contrat dans RT.02.01 est lié au fournisseur dans RT.05.01, aux fonctions qu’il prend en charge dans RT.06.01 et à l’évaluation des risques dans RT.07.01. Un champ erroné peut entraîner des erreurs en cascade dans plusieurs modèles.

Le format de soumission final est xBRL-CSV. Bien que certains superviseurs aient proposé une conversion temporaire sur Excel pour le premier cycle, il est prévu qu’à partir de 2026, les institutions soumettent leurs données directement dans le format prescrit.

Quelles sont les entités qui doivent tenir un registre (et dans quel délai) ?

La loi DORA s’applique largement. Les établissements de crédit, les prestataires de services de paiement, les compagnies d’assurance, les entreprises d’investissement et les prestataires de services de crypto-actifs entrent tous dans son champ d’application. La définition de « prestataire de services TIC » est tout aussi large : il s’agit de toute entreprise qui fournit des services numériques, des services de données ou une assistance matérielle de manière continue. Cela inclut votre fournisseur d’hébergement en nuage, votre système de RH SaaS, votre fournisseur de pare-feu géré et votre fournisseur de télécommunications.

Les micro-entreprises bénéficient d’exemptions limitées à certaines exigences en matière de gestion des risques liés aux TIC, mais l’obligation de tenir un registre s’applique à la quasi-totalité des entités réglementées.

Les échéances du Benelux pour 2026

Les délais de soumission varient d’un superviseur à l’autre. Tous utilisent le 31 décembre 2025 comme date de référence pour les contrats actifs.

La BNB recommande vivement de tester les soumissions dans l’environnement OneGate TEST avant la date limite de production. Compte tenu des taux d’erreurs constatés lors de l’essai à blanc, cette recommandation mérite d’être prise au sérieux.

En Belgique, on estime à plus de 200 le nombre d’entités financières qui doivent s’inscrire chaque année au registre, qu’il s’agisse d’établissements de crédit, d’assureurs, d’entreprises d’investissement ou de prestataires de services de paiement. Pour les institutions dotées de petites équipes de conformité, le registre est en concurrence avec les rapports NIS2, la vérification CyFun et les opérations quotidiennes.

Étape par étape : création d’un registre à partir de zéro

Étape 1 : Inventaire de tous les fournisseurs de services TIC

Commencez par les contrats, pas par la technologie. Consultez vos dossiers d’achats, les données relatives aux comptes fournisseurs et les listes de fournisseurs existantes. Tout fournisseur qui fournit un service numérique, gère des données, livre des logiciels ou assure une assistance matérielle permanente doit figurer dans le registre.

Les catégories souvent négligées comprennent les outils de cybersécurité (fournisseurs de VPN, vendeurs de pare-feu, services de filtrage web, protection des points d’extrémité), les plateformes SaaS pour les processus non essentiels (RH, CRM, billetterie), les fournisseurs de télécommunications et de connectivité, et les vendeurs de matériel avec des accords de maintenance continue ou de mise à jour des microprogrammes.

C’est ici que votre architecture de sécurité a son premier impact sur la complexité du registre. Une organisation qui utilise des produits distincts pour l’accès VPN, le filtrage web, la gestion des pare-feux et la connectivité SD-WAN a quatre fournisseurs de sécurité à documenter. Une organisation utilisant la plateforme SASE unifiée de Jimber, qui combine ZTNA, SWG, FWaaS et SD-WAN en un seul service, n’en documente qu’un seul. L’étape de l’inventaire à elle seule s’en trouve considérablement allégée.

Étape 2 : Collecte des données contractuelles et attribution des identifiants

Pour chaque fournisseur, recueillez les dates de début et de fin du contrat, les périodes de préavis, les conditions de renouvellement et l’identifiant de l’entité juridique (LEI). Le LEI est un code alphanumérique de 20 caractères qui sert d’identifiant global pour les personnes morales. Votre superviseur l’utilise pour agréger le risque de concentration sur l’ensemble du marché.

De nombreux fournisseurs de TIC du marché intermédiaire n’ont pas de LEI. Dans ce cas, DORA autorise l’utilisation d’un identifiant unique européen (EUID), composé du code ISO du pays suivi d’un point et du numéro d’enregistrement national. Veillez à ce que ce format soit correct. Un EUID mal structuré entraîne un rejet automatique.

Avec une pile de sécurité consolidée, cette étape se réduit proportionnellement. Un seul fournisseur signifie un seul LEI à vérifier, un seul contrat à documenter, un seul ensemble de conditions de renouvellement à suivre. Avec cinq fournisseurs de sécurité distincts, vous répétez ce processus cinq fois, chacun avec son propre risque d’erreurs de saisie de données.

Étape 3 : Associer les services aux fonctions de l’entreprise

Le modèle RT.06.01 vous demande de relier chaque service TIC aux activités sous licence qu’il soutient. C’est ici que les responsables de la conformité et les responsables informatiques doivent collaborer. Le responsable de la conformité sait quelles sont les activités soumises à licence. Le responsable informatique sait quels systèmes les soutiennent.

Pour une société de gestion de patrimoine, le système de gestion de portefeuille correspond aux services d’investissement. La plateforme de courrier électronique correspond à la communication avec les clients. Une plateforme SASE comme Jimber correspond aux contrôles d’accès au réseau, à la sécurité du web et à la surveillance de la sécurité, tous ces éléments étant documentés comme des fonctions d’un seul service plutôt que comme trois ou quatre entrées distinctes dans le modèle.

Étape 4 : Évaluer la criticité et documenter l’emplacement des données

Le modèle RT.02.02 demande si chaque service TIC soutient une « fonction critique ou importante ». Cette classification déclenche des exigences supplémentaires : des stratégies de sortie documentées, des droits d’audit et des évaluations des risques plus détaillées dans RT.07.01.

Pour chaque service, indiquez où les données sont stockées et traitées. Une granularité au niveau du pays est attendue. Si votre fournisseur de sécurité web traite le trafic via des nœuds situés dans l’UE mais stocke les métadonnées aux États-Unis, c’est important. Cela déclenche des exigences supplémentaires en matière de documentation sur les garanties de transfert des données.

Jimber traite toutes les données au sein de l’EEE, ce qui simplifie le champ de localisation des données dans RT.02.02 : une entrée, une juridiction, aucune documentation de transfert transfrontalier n’est requise. Comparez cette situation à celle d’un fournisseur de sécurité basé aux États-Unis, pour lequel vous devez documenter l’exposition au CLOUD Act, les clauses contractuelles types et les évaluations des risques résiduels pour chaque composant du service.

Étape 5 : Documenter la sous-traitance et les chaînes d’approvisionnement

Le modèle RT.05.02 couvre les sous-traitants. Si votre fournisseur de sécurité informatique utilise un fournisseur d’infrastructure basé aux États-Unis, cette relation doit être documentée. Demandez à chaque fournisseur de vous communiquer par écrit les accords de sous-traitance qu’il a conclus. Nombre d’entre eux n’accepteront pas de communiquer ces informations sans en avoir fait directement la demande.

Moins de fournisseurs signifie moins de chaînes de sous-traitance à tracer. Un fournisseur SASE unique doté d’une architecture transparente vous permet de documenter une seule chaîne d’approvisionnement au lieu de cinq.

Étape 6 : Évaluer les risques et élaborer des stratégies de sortie

Pour les services classés comme critiques ou importants, RT.07.01 exige une évaluation documentée des risques et la confirmation de l’existence de stratégies de sortie. La stratégie de sortie doit être plus qu’une simple clause dans un contrat. Elle doit décrire les modalités de transition vers un autre fournisseur ou de reprise de la fonction en interne, y compris les délais, les mécanismes de portabilité des données et les évaluations d’impact.

Les plateformes cloud-natives comme Jimber simplifient la planification de la sortie parce qu’il n’y a pas de dépendance à l’égard d’un matériel propriétaire. La configuration peut être exportée via une API, les journaux suivent des formats standardisés et les politiques d’accès sont documentées de manière centralisée. Comparez cette situation à celle d’un fournisseur de pare-feu traditionnel pour lequel la sortie signifie la mise hors service d’appareils physiques sur chaque site.

Cinq erreurs qui entraînent le rejet des registres

L’essai à blanc du SEC a produit environ 235 000 erreurs de validation. Ces modèles représentent la majorité d’entre elles.

Champs obligatoires manquants. Il s’agit de la catégorie d’erreurs la plus importante, représentant plus de 86 % de tous les échecs de validation. Les dossiers contractuels incomplets, les correspondances de fonctions manquantes et les évaluations de criticité vierges sont les coupables les plus fréquents. La solution est systématique : il s’agit de vérifier l’exhaustivité de chaque champ obligatoire de la spécification STI avant de la soumettre.

Codes LEI invalides ou expirés. Les codes LEI doivent être à jour et correctement formatés. Un LEI expiré ou une faute de frappe dans la chaîne de 20 caractères entraîne un rejet automatique. Vérifiez chaque LEI dans la base de données de la Global LEI Foundation avant de le soumettre. Cela représente environ 6,5 % des erreurs.

Valeurs non standard dans les champs déroulants. Les modèles ITS utilisent des listes de codes prescrits pour des champs tels que le type de service, le niveau de criticité et les codes pays. La saisie d’un texte libre là où une valeur de liste déroulante est attendue, ou l’utilisation d’une terminologie interne au lieu de la taxonomie de l’ABE, entraînent le rejet de la demande. Environ 4,3 % des erreurs relevaient de cette catégorie.

Négliger les fournisseurs secondaires de TIC. Les organisations ont tendance à enregistrer leur fournisseur de services bancaires centraux et leur hébergeur en nuage, mais oublient le service de filtrage web, le fournisseur de VPN, l’outil de protection des points d’extrémité et le système de billetterie SaaS. Chacun de ces éléments est un fournisseur de services TIC au sens de la définition large de DORA. C’est l’un des arguments pratiques les plus forts en faveur de la consolidation des fournisseurs : lorsque votre VPN, votre pare-feu, votre filtre web et votre SD-WAN font tous partie d’un seul abonnement Jimber SASE, il n’y a rien à oublier.

Traiter le registre comme un exercice unique. L’article 28, paragraphe 3, exige des mises à jour continues. Lorsque vous changez de fournisseur, que vous ajoutez un nouvel outil SaaS ou que vous reclassez un service comme critique, le registre doit refléter ce changement. La soumission d’un instantané statique qui était exact il y a six mois, mais qui a dérivé depuis, constitue une lacune en matière de conformité.

Comment une plateforme SASE simplifie votre registre

Le nombre de lignes de votre registre est directement déterminé par votre architecture de sécurité. Une institution financière de taille moyenne qui utilise une pile fragmentée typique, avec des fournisseurs distincts pour le VPN, le pare-feu, le filtrage web, la connectivité SD-WAN et la gestion des points finaux, doit documenter chacun de ces fournisseurs individuellement. Cela signifie cinq entrées distinctes dans RT.05.01, cinq contrats dans RT.02.01, cinq évaluations de la criticité, cinq stratégies de sortie et cinq ensembles de documentation sur la sous-traitance.

Jimber consolide ZTNA, SWG, FWaaS et SD-WAN en une seule plateforme gérée dans le nuage. L’impact sur le registre est immédiat.

Moins d’entrées signifie moins de possibilités d’erreurs de validation, moins d’administration de contrats et un cycle de mise à jour annuelle plus facile à gérer.

La souveraineté des données et la question de la loi CLOUD

Le modèle RT.02.02 exige que vous déclariez où les données sont stockées et traitées. Si votre fournisseur de sécurité a son siège aux États-Unis, le US CLOUD Act donne aux autorités américaines le pouvoir d’exiger la divulgation des données, quel que soit l’endroit où les serveurs sont physiquement situés. Pour les institutions financières européennes, cela crée une couche supplémentaire de documentation : vous devez expliquer les mesures de protection en place, généralement des clauses contractuelles types, et évaluer le risque résiduel.

Jimber a son siège en Europe et tous les traitements de données sont effectués au sein de l’EEE. Cela signifie que le champ de localisation des données dans RT.02.02 est simple à remplir et que l’évaluation des risques dans RT.07.01 n’a pas besoin d’aborder les questions de transfert de données transfrontalier. Pour en savoir plus sur les raisons pour lesquelles les organisations européennes réévaluent leurs dépendances vis-à-vis des fournisseurs américains, consultez notre analyse des alternatives européennes au SASE.

Enregistrement centralisé comme preuve d’audit

Le registre vous demande de démontrer qu’il existe des contrôles pour chaque service TIC. Avec cinq outils de sécurité distincts, cela signifie que vous devez compiler des preuves à partir de cinq tableaux de bord, cinq formats de journal et cinq interfaces de rapport.

La console de gestion unique de Jimber fournit une piste d’audit unifiée couvrant les contrôles d’accès (ZTNA), la sécurité web (SWG), la politique réseau (FWaaS) et la connectivité (SD-WAN). Lorsque votre superviseur vous demande comment vous contrôlez les services TIC documentés dans le registre, vous indiquez une plateforme et un flux de données. Il s’agit d’une conversation fondamentalement différente de celle qui consiste à expliquer comment cinq tableaux de bord distincts fonctionnent ensemble.

Les stratégies de sortie rendues pratiques

L’article 28, paragraphe 8, exige des stratégies de sortie documentées pour les services TIC soutenant des fonctions critiques. Avec une plateforme native, il est plus facile de démontrer la portabilité qu’avec des solutions dépendantes du matériel. L’exportation de la configuration basée sur l’API de Jimber, les formats de journaux standardisés et l’absence d’appareils propriétaires sur site signifient que votre plan de transition peut être concret plutôt que théorique. Vous pouvez effectuer un test de migration documenté et enregistrer les résultats comme preuve pour le modèle RT.07.01.

Un gestionnaire de patrimoine belge a réduit ses coûts de sécurité de 58% après avoir consolidé ses multiples produits de pointage vers la plateforme SASE de Jimber. L’avantage de la conformité a été un effet secondaire de la simplification opérationnelle : moins de fournisseurs à gérer, moins de contrats à suivre et un seul fournisseur à documenter dans le registre.

Contexte belge et Benelux

La loi DORA s’applique en tant que lex specialis pour le secteur financier et prévaut sur la loi NIS2 pour les entités qui entrent dans son champ d’application. Dans la pratique, de nombreuses organisations belges sont confrontées simultanément aux deux réglementations. Une banque classée comme entité essentielle sous NIS2 doit se conformer à la fois au cadre de vérification de la CyFun (date limite : 18 avril 2026) et à la soumission du registre DORA à la BNB.

Le Centre pour la cybersécurité en Belgique (CCB) gère CyFun, tandis que la BNB et la FSMA s’occupent de la supervision de DORA. Ce chevauchement crée à la fois une charge et une opportunité. Les organisations qui ont terminé leur inventaire des actifs et leur évaluation de la chaîne d’approvisionnement CyFun disposent déjà d’une grande partie des données de base nécessaires pour le registre DORA. La gestion des actifs et les contrôles des fournisseurs dans les fonctions Identify et Protect de CyFun se traduisent directement par les inventaires des fournisseurs et les évaluations de la criticité dans les modèles ITS.

Pour les obligations de conformité NIS2 et la liste de contrôle pratique de la conformité NIS2, nous avons des guides dédiés qui couvrent le cadre CyFun en détail.

Un défi pratique pour les institutions belges est la langue. Les modèles de l’ABE sont en anglais, mais les communications de la BNB et de la FSMA concernant les erreurs de validation peuvent arriver en néerlandais ou en français. Les équipes internationales doivent s’assurer que les personnes qui remplissent les modèles et celles qui traitent les commentaires des superviseurs peuvent travailler dans plusieurs langues sans introduire d’erreurs de traduction dans les données.

Les Pays-Bas ont activé leur Cyberbeveiligingswet au premier trimestre 2026, soumettant les institutions financières néerlandaises à des obligations parallèles NIS2 et DORA. La DNB prévoit le format xBRL-CSV pour les soumissions de 2026, avec une tolérance limitée pour les solutions de contournement basées sur Excel. Les institutions néerlandaises qui se sont appuyées sur un support de conversion temporaire au cours du premier cycle doivent prévoir une soumission directe en xBRL-CSV.

Questions fréquemment posées

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

Le registre d’information est un ensemble de données structuré requis par l’article 28(3) de la loi sur la résilience opérationnelle numérique. Il documente tous les accords contractuels entre une entité financière et ses fournisseurs de services TIC tiers. Le registre utilise 15 modèles interconnectés définis par les normes techniques de mise en œuvre de l’ABE et doit être soumis chaque année à l’autorité de surveillance nationale compétente.

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

Le registre n’est pas un rapport annuel statique. Le DORA doit être tenu à jour en permanence. Tout changement dans les accords contractuels, les nouveaux fournisseurs de services TIC, la reclassification d’un service comme critique, ou les modifications des chaînes de sous-traitance doivent être reflétés rapidement. La soumission annuelle à votre superviseur est un instantané, mais le registre sous-jacent doit être à jour à tout moment.

La loi DORA s’applique-t-elle aux fournisseurs de services TIC eux-mêmes ?

La loi DORA réglemente directement les entités financières, et non leurs fournisseurs de TIC. Toutefois, les fournisseurs de services TIC désignés comme « critiques » par les autorités européennes de surveillance sont soumis à un cadre de surveillance directe. Même les fournisseurs non critiques sont soumis à une pression indirecte : leurs clients du secteur financier exigeront des dispositions contractuelles couvrant les droits d’audit, la notification des incidents, les stratégies de sortie et la transparence de l’emplacement des données.

Que se passe-t-il si nous ne respectons pas la date limite de soumission ?

La loi DORA donne aux autorités de surveillance nationales le pouvoir d’imposer des sanctions administratives et des mesures correctives. Les sanctions spécifiques varient selon le pays et le type d’entité. Au-delà des sanctions réglementaires, une soumission manquée ou incomplète signale à votre autorité de surveillance une mauvaise gouvernance des TIC, ce qui peut déclencher une surveillance accrue et des exigences plus fréquentes en matière de rapports.

Faut-il inclure dans le registre les fournisseurs d’infrastructure en nuage comme AWS ?

Oui. Tout prestataire fournissant des services TIC de manière continue entre dans le champ d’application de la DORA. Cela inclut les fournisseurs d’infrastructure en tant que service, les fournisseurs de plateforme en tant que service, les applications SaaS et les fournisseurs de services gérés. Si AWS héberge votre application bancaire principale, il doit figurer dans le registre avec tous les détails du contrat, les informations sur l’emplacement des données et une évaluation de la criticité.

Comment la consolidation des outils de sécurité affecte-t-elle le registre ?

Directement. Chaque fournisseur de services TIC nécessite ses propres entrées dans plusieurs modèles : détails du fournisseur, informations sur le contrat, évaluation de la criticité, évaluation des risques et documentation de la stratégie de sortie. La consolidation de cinq produits de points de sécurité vers la plateforme unifiée SASE de Jimber réduit le nombre d’entrées de fournisseurs de cinq à une. Cela signifie un seul LEI à vérifier, un seul contrat à documenter, une seule évaluation des risques à réaliser et une seule stratégie de sortie à maintenir. Pour une institution de taille moyenne, cela peut réduire de 80 % la partie du registre liée à la sécurité.

Construire un registre DORA qui survive à la validation relève à la fois de la gestion des données et d’une décision d’architecture. Moins vous avez de fournisseurs de TIC à documenter, plus le registre est simple et moins vous risquez d’erreurs lors de la soumission annuelle. Si votre équipe se prépare pour le prochain cycle de reporting, réservez une démonstration pour voir comment la consolidation de votre pile de sécurité avec Jimber change l’équation.