DORA : comment optimiser la gestion des accords contractuels ?

Face à l'entrée en application du règlement DORA le 17 janvier 2025 et à l'échéance du 15 avril 2025 pour la remise des registres à l'Autorité de Contrôle Prudentiel et de Résolution (ACPR), la gestion documentaire des prestataires TIC devient un enjeu majeur pour les établissements financiers. Cette exigence se révèle d'autant plus critique que, comme le relève France Assureurs, certaines normes d'application restent encore à clarifier.

En tant que Tiers de Collecte Probatoire (TCP) et expert en solutions de gestion de la conformité depuis 2009, Provigis accompagne les établissements financiers dans l'automatisation de leur conformité documentaire DORA. Notre plateforme digitale simplifie la collecte et l'authentification des documents de conformité des prestataires TIC pour permettre aux équipes de se concentrer sur l'analyse des risques plutôt que sur des tâches administratives chronophages.

Dans cet article, la rédaction vous propose d'explorer en détail le registre DORA : son contenu et sa structure, son intégration dans le dispositif de gestion des risques et les meilleures pratiques pour assurer sa conformité en permanence.

Rappel : qu'est-ce que le règlement DORA ?

Le Digital Operational Resilience Act (DORA) est un règlement européen (UE) 2022/2554, adopté le 14 décembre 2022 et publié au Journal officiel de l'Union européenne le 27 décembre 2022.

Son objectif est d’harmoniser et de renforcer la résilience opérationnelle numérique des acteurs du secteur financier face aux cybermenaces et aux risques liés aux technologies de l’information.

💡 À savoir

Selon une étude réalisée par IBM en 2022, le secteur financier est la deuxième cible des cyberattaques (22 % d’entités touchées chaque année), derrière l’industrie.

DORA : qui est concerné ?

Défini par l’article 2, le périmètre du règlement DORA couvre l’ensemble des institutions financières régulées dans l’Union européenne :

• Établissements de crédit ;
• Entreprises d’investissement ;
• Fournisseurs de services de paiement et d’émission de monnaie électronique ;
• Sociétés de gestion de fonds d’investissement ;
• Dépositaires centraux de titres et contreparties centrales ;
• Chambres de compensation ;
• Intermédiaires d’assurance et de réassurance ;
• Institutions de retraite professionnelle ;
• Fournisseurs de services sur cryptoactifs (MiCA) ;
• Agences de notation de crédit ;
• Registres de transactions (Trade Repositories).

Le périmètre du règlement couvre également les prestataires tiers de services de Technologies de l’Information et de la Communication (TIC) jugés « critiques » selon les critères définis à l’article 31 de DORA, dont notamment :

• L’importance systémique du prestataire pour le secteur financier (ex. un fournisseur de Cloud utilisé par la majorité des banques européennes, comme AWS ou Microsoft Azure) ;
• Le nombre d’entités financières dépendantes de ses services (ex. un prestataire de cybersécurité qui assure la protection des données pour plusieurs grandes banques et compagnies d’assurance) ;
• Le caractère essentiel des services fournis, en particulier pour des fonctions critiques (ex. un prestataire qui fournit des infrastructures de paiement ou des services d’authentification forte, comme Visa Secure ou Thales) ;
• L’impact potentiel d’une interruption de service sur la stabilité financière ou l’ordre public (ex. une panne massive chez un prestataire de services de transactions financières comme SWIFT paralyserait les paiements internationaux).

La désignation officielle des prestataires critiques est réalisée par l’Autorité européenne de surveillance compétente (EBA, ESMA, EIOPA).

💡 À savoir

Même s’il s’agit essentiellement d’un règlement sectoriel, DORA dépasse les établissements de crédit et les assureurs pour englober leurs prestataires de services informatiques critiques. En clair, les acteurs du secteur financier ne pourront pas « rejeter » leur responsabilité sur un prestataire externe.

Quelles sont les obligations du règlement DORA ?

Le règlement DORA encadre la gestion des risques numériques pour garantir la continuité des services financiers face aux menaces technologiques. Il s’articule autour de cinq grands axes :

• Un cadre de gestion des risques TIC avec l’identification, la prévention et la remédiation aux incidents cybernétiques (attaque par rançongiciel, fuite massive de données personnelles, déni de service, panne majeure, etc.) ;
• Une obligation de déclaration des incidents auprès des régulateurs selon les critères de gravité définis par l’article 19 du règlement (nombre d’utilisateurs affectés, durée, portée géographique, impact financier direct, etc.). En France, il s’agit de l’Autorité de contrôle prudentiel et de résolution (ACPR) et de l’Autorité des marchés financiers (AMF) ;
• Des tests réguliers de résilience opérationnelle, avec des audits internes et des simulations de crises ;
• Une surveillance renforcée des prestataires tiers critiques, avec des obligations de contractualisation et de suivi des risques liés à l’externalisation ;
• L’obligation de tenir un registre des accords contractuels avec ces prestataires afin de garantir la traçabilité et la conformité des relations commerciales.

Date d’entrée en vigueur de DORA

Le règlement DORA est applicable depuis le 17 janvier 2025 en France et dans l’ensemble des pays de l’UE. Adopté le 14 décembre 2022 et entré en vigueur le 16 janvier 2023, il a laissé aux entités financières et aux prestataires TIC un délai de deux ans pour se conformer aux nouvelles exigences.

Quelles sanctions en cas de non-conformité à DORA ?

En cas de non-conformité à DORA, les entités financières s'exposent à des sanctions financières et réglementaires proportionnelles à la gravité de l’infraction et à son impact sur la stabilité du système financier :

• Amendes administratives : les institutions financières peuvent se voir infliger des amendes pouvant atteindre 10 millions d'euros ou 5 % de leur chiffre d'affaires annuel total, selon le montant le plus élevé ;
• Mesures correctives : les autorités de surveillance peuvent exiger des institutions financières qu'elles prennent des mesures correctives pour remédier aux faiblesses ou aux défaillances de leur résilience opérationnelle ;
• Sanction rendue publique : ****les autorités peuvent publier officiellement les sanctions prononcées contre les entités non conformes, ce qui peut nuire à leur réputation ;
• Retrait de l'agrément : en cas de non-conformité répétée ou grave, les autorités de surveillance peuvent retirer l'agrément des institutions financières.

📰 Le point actu

Fin janvier 2025, dans une prise de position publiée via la fédération européenne de l’assurance, France Assureurs a appelé les superviseurs financiers européens à clarifier certaines dispositions du texte du règlement DORA.

Extrait **de la prise de parole de Florence Lustman, présidente de France Assureurs : « La mise en conformité à Dora au 17 janvier 2025 représentait un défi pour les entités financières, d’autant que de nombreuses mesures de niveau 2 du texte n'ont été finalisées que tardivement dans le processus, y compris le texte final de la norme sur le registre d'informations, finalisée fin décembre 2024. Deux normes restent encore à publier à ce jour, ce qui complique la mise en œuvre pour les entreprises […] ».

Et de poursuivre :  « Afin de soutenir davantage les entreprises, le secteur exhorte les autorités européennes de surveillance ainsi que la Commission européenne à adopter rapidement les mesures restantes et à fournir la clarté et les réponses nécessaires aux questions soulevées. »

Le registre des contrats DORA, une obligation réglementaire

Qu'est-ce que le registre des contrats sous DORA ?

Le registre des contrats, ou « registre d’information des accords contractuels » selon la terminologie exacte du texte du règlement dans son article 28, est un document obligatoire qui recense tous les accords contractuels entre une entité financière et ses prestataires TIC. Il couvre l’ensemble des services externalisés et identifie ceux qui concernent des fonctions critiques ou importantes pour l’activité.

Chaque contrat doit faire l’objet d’une fiche détaillée mentionnant :

• L’identité du prestataire (raison sociale, localisation, immatriculation juridique) ;
• Les services fournis, en précisant leur rôle dans le fonctionnement de l’entité ;
• Les obligations contractuelles, notamment les conditions de durée, de renouvellement et de résiliation ;
• Les engagements en matière de sécurité et de continuité, comme les certifications, les SLA et les obligations de reporting.

Le registre doit être mis à jour en permanence pour refléter l’état réel des relations contractuelles. Toute modification significative d’un accord, qu’elle concerne la portée des services, les conditions de sécurité ou la gouvernance contractuelle, doit être immédiatement intégrée au document.

Ce registre ne se limite pas à un inventaire statique. Il s’agit d’un outil de gestion des risques qui doit permettre aux autorités de supervision d’évaluer la dépendance d’une entité à ses prestataires TIC et de vérifier qu’elle respecte ses obligations en matière de continuité et de cybersécurité.

Registre des contrats : quelles sont les exigences de DORA ?

Le règlement DORA impose aux entités financières plusieurs obligations concernant la gestion de leurs accords contractuels avec des prestataires de services TIC.

• Tenue d'un registre détaillé : les entités doivent maintenir un registre à jour de tous les contrats conclus avec des prestataires TIC, en identifiant spécifiquement ceux qui concernent des fonctions critiques ou importantes. Ce registre doit être communiqué à l'autorité compétente au moins une fois par an ;
• Clauses contractuelles minimales : les contrats avec les prestataires TIC doivent au moins intégrer des clauses sur la résiliation, la gestion des incidents, la continuité des services et les obligations de conformité du prestataire ;
• Diligence préalable : avant de conclure un accord, les entités doivent évaluer les risques associés au prestataire, y compris le risque de concentration, pour s'assurer de sa capacité à fournir les services conformément aux exigences de DORA ;
• Surveillance continue : les entités doivent surveiller en permanence les relations avec les prestataires TIC pour s'assurer du respect des obligations contractuelles et de la gestion efficace des risques liés aux TIC ;
• Notification des nouveaux accords : les entités doivent informer l'autorité compétente de tout nouvel accord contractuel relatif à l'utilisation de services TIC soutenant des fonctions critiques ou importantes. Elles doivent également les notifier lorsqu'une fonction devient critique ou importante.

⚠️ Première échéance au 15 avril 2025

Les entreprises assujetties à DORA doivent remettre à l’ACPR leur registre d’information au plus tard le 15 avril 2025. L’ACPR se chargera ensuite de le faire parvenir aux différentes autorités européennes de surveillance (EBA, EIOPA, ESMA).

Contenu et structure des informations des accords contractuels du registre

La structure du registre d’informations repose sur plusieurs modèles types organisés en tableaux. Chaque modèle correspond à une section du règlement et suit un format structuré selon les normes définies par le document 32024R2956.

La structure du registre d’informations sous DORA, tel que défini dans le Règlement d’exécution (UE) 2024/2956, repose sur 15 modèles types (tableaux) organisés en 7 grandes catégories. Chaque modèle correspond à une section spécifique et suit un format structuré avec des colonnes prédéfinies.

#1 B_01 – Identification des entités responsables du registre d’informations

B_01.01 – Entité tenant le registre d’informations

Ce modèle identifie l’entité responsable de la tenue et de la mise à jour du registre d’informations. Il précise si cette responsabilité est exercée au niveau individuel (entité financière seule), sous-consolidé (ensemble de filiales sous un même périmètre) ou consolidé (groupe complet). L’objectif est de garantir la qualité de la gouvernance claire et la traçabilité des mises à jour du registre DORA.

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

Ce modèle recense toutes les entités appartenant au périmètre de consolidation. Si l’entité financière concernée n’appartient à aucun groupe, seule cette entité est déclarée. Cette information est essentielle pour identifier l’étendue de l’organisation concernée par les obligations de tenue du registre.

B_01.03 – Liste des succursales

Ce modèle dresse la liste des succursales des entités mentionnées dans le modèle B_01.02. Il permet de distinguer les différentes structures géographiques d’une organisation et de s’assurer que toutes les implantations sont bien couvertes par le registre d’informations.

#2 B_02 – Accords contractuels avec les prestataires de services TIC

B_02.01 – Accords contractuels – Informations générales

Ce modèle recense tous les accords contractuels conclus avec des prestataires tiers directs de services TIC. Chaque accord est associé à un numéro de référence unique pour l’identifier de manière précise dans le registre.

Cette centralisation permet de gérer les engagements contractuels et de superviser les relations avec les fournisseurs.

B_02.02 – Accords contractuels – Informations spécifiques

Ce modèle détaille chaque accord contractuel répertorié dans le modèle B_02.01. Il précise notamment :

• Les services TIC concernés par l’accord ;
• Les fonctions de l’entité financière soutenues par ces services ;
• Les éléments contractuels les plus importants comme la durée, le droit applicable et les clauses de résiliation.

L’objectif est d’assurer une transparence totale sur les prestations souscrites et les obligations associées.

B_02.03 – Liste des accords contractuels intra-groupe

Ce modèle identifie les accords contractuels internes au groupe, qui relient donc les contrats intra-groupe aux contrats signés avec des prestataires tiers. Chaque lien est établi à l’aide des numéros de référence des accords contractuels. Objectif : cartographier la chaîne d’approvisionnement des services TIC et évaluer les risques liés aux sous-traitants.

#3 B_03 – Identification des entités signataires des accords TIC

B_03.01 – Entités signataires des accords pour la réception de services TIC

Ce modèle identifie les entités qui signent les contrats avec les prestataires de services TIC, soit en leur propre nom, soit pour le compte d’autres entités du groupe. Lorsqu’une structure est consolidée, il permet de distinguer les entités financières qui bénéficient des services TIC de celles qui sont en charge des négociations contractuelles.

B_03.02 – Prestataires tiers de services TIC signataires des accords

Ce modèle recense les prestataires TIC qui ont signé les accords contractuels mentionnés dans le modèle B_02.01. Il permet de différencier les fournisseurs directs des sous-traitants éventuels et d’assurer une traçabilité complète des engagements pris par chaque acteur impliqué dans la chaîne de services numériques.

B_03.03 – Entités signataires des accords pour la fourniture de services TIC à d’autres entités du groupe

Ce modèle identifie les entités internes au groupe qui fournissent des services TIC aux autres entités consolidées. Il met en évidence les flux de services intra-groupe et les responsabilités contractuelles associées pour assurer la visibilité sur l’organisation interne et les dépendances technologiques entre filiales.

#4 B_04 – Identification des entités utilisatrices des services TIC

Cette catégorie contient un seul modèle, le « B_04.01 », intitulé « Entités ayant recours aux services TIC ».

Ce modèle recense toutes les entités qui utilisent les services TIC fournis par des prestataires tiers ou intra-groupe. Il permet de distinguer les entités financières qui dépendent de ces services, qu’il s’agisse d’entités individuelles ou de filiales consolidées. Ce modèle permet de cartographier la consommation des services TIC au sein du périmètre déclaré et assure une gestion efficace des risques liés à la dépendance technologique.

#5 B_05 – Identification des prestataires tiers de services TIC et de la chaîne d’approvisionnement

B_05.01 – Prestataires tiers de services TIC

Ce modèle dresse la liste des prestataires tiers de services TIC, qu’ils soient externes ou intra-groupe, et fournit des informations générales pour les identifier. Il intègre les fournisseurs directs de services TIC, ainsi que les sous-traitants qui interviennent dans la chaîne d’approvisionnement.

Ce modèle précise également « l’entreprise mère ultime » des prestataires concernés, ce qui permet de mieux évaluer la concentration des risques et les éventuelles dépendances stratégiques.

B_05.02 – Chaîne d’approvisionnement des services TIC

Ce modèle identifie et structure les liens entre les prestataires de services TIC au sein d’une même chaîne d’approvisionnement. Il établit une hiérarchie entre les fournisseurs directs et leurs sous-traitants pour permettre aux entités financières de déployer une vision claire des dépendances et des risques liés aux services externalisés.

En catégorisant chaque prestataire selon son niveau d’intervention dans la chaîne, ce modèle facilite l’analyse des risques de continuité et de sécurité des services TIC.

#6 B_06 – Identification des fonctions

Cette catégorie ne contient qu’un seul modèle, le « B_06.01 », intitulé « Identification des fonctions utilisant les services TIC ».

Il répertorie les fonctions de l’entité financière qui utilisent les services TIC et fournit des informations détaillées sur chacune d’elles. Chaque fonction est associée à un identifiant unique qui combine plusieurs éléments :

• Le LEI de l’entité financière ;
• L’activité autorisée concernée ;
• La fonction spécifique utilisant les services TIC.

L’objectif est de permettre une cartographie précise des services TIC en lien avec les activités essentielles de l’entité. Cette partie du registre DORA facilite l’évaluation des risques liés à l’externalisation des services numériques et permet une meilleure traçabilité des impacts en cas de défaillance.

#7 B_07 – Évaluation des services TIC

Cette catégorie se limite également à un seul modèle, le « B_07.01 », intitulé « Évaluations des services TIC ». Ce modèle centralise l’évaluation des risques liés aux services TIC utilisés par l’entité financière, en particulier ceux qui soutiennent des fonctions critiques. Plusieurs paramètres d’évaluation sont listés par DORA :

• Substituabilité : possibilité de remplacer rapidement le service en cas de défaillance ;
• Importance du service : impact direct sur les opérations et la continuité d’activité ;
• Niveau de dépendance : mesure de l’exposition aux risques en cas d’indisponibilité ;
• Incidents passés : fréquence et durée des interruptions sur les dernières périodes ;
• Risque de concentration : exposition due à la dépendance envers un prestataire unique ;
• Localisation des infrastructures : risques liés aux data centers utilisés ;
• Conformité réglementaire : respect des normes et obligations en vigueur ;
• Dernier audit ou contrôle : date et conclusions des évaluations précédentes ;
• Impact potentiel d’une interruption : conséquences financières, opérationnelles et juridiques.

L’objectif est d’identifier les points critiques, de mesurer le niveau de risque réel et d’anticiper les mesures à mettre en place pour garantir la continuité d’activité.

#8 B_99 – Définitions et référentiels internes

Cette catégorie ne contient qu’un seul modèle, le « B_99.01 », intitulé « Définitions des entités ayant recours aux services TIC ». Il centralise les référentiels internes utilisés par l’entité pour structurer et interpréter les données du registre d’informations DORA. Il garantit une cohérence sémantique et une uniformité des déclarations, notamment lorsque plusieurs entités du même groupe contribuent au registre.

Ce modèle fournit plusieurs éléments :

• Définitions internes des entités : critères permettant d’identifier une entité financière, un prestataire de services TIC ou une filiale ;
• Classification des services TIC : catégorisation normalisée des services utilisés (ex. : infrastructure, logiciels, stockage de données) ;
• Grille d’évaluation des risques : méthodologie propre à l’entité pour évaluer la criticité et l’impact des services TIC (ex. : échelle de risque faible, moyen, élevé) ;
• Indicateurs de performance et de résilience : KPIs internes qui permettent de suivre la stabilité et la disponibilité des services TIC.

Ce modèle garantit la traçabilité des informations et l’alignement des évaluations entre les différentes parties prenantes du registre DORA. Il permet d’éviter toute interprétation floue ou incohérente des données en imposant un cadre clair et structuré à l’ensemble des reportings liés aux services TIC.

Registre DORA : quelles règles et quelle fréquence pour la mise à jour ?

Le registre d’informations DORA doit être maintenu à jour selon deux principes : une mise à jour immédiate en cas de modification, et une révision annuelle même en l'absence de changements.

Mise à jour immédiate en cas de modification

Toute modification des informations enregistrées doit être reportée sans délai :

• L'ajout ou la suppression d'un prestataire tiers de services TIC ;
• Une modification dans un contrat (renouvellement, ajout/suppression de services couverts, changement de conditions) ;
• Un changement de statut d’une entité relevant du périmètre (acquisition, fusion, cession, fermeture) ;
• Une réorganisation interne affectant la gestion des services TIC (changement de responsabilité dans la signature des contrats, modification de la structure de gouvernance) ;
• Une évolution des risques identifiés dans le cadre des services TIC critiques.

Cette mise à jour immédiate garantit que les données du registre d’informations DORA restent conformes à la réalité opérationnelle.

Révision annuelle obligatoire

Même en l'absence de modification, le règlement DORA impose une révision annuelle du registre d’informations :

• Vérifier que toutes les informations inscrites sont toujours exactes et complètes ;
• Confirmer que les prestataires et accords recensés sont toujours actifs et conformes aux exigences de DORA ;
• S'assurer que les évaluations des risques restent pertinentes ;
• Identifier d'éventuels écarts avec les évolutions réglementaires ou les nouvelles exigences internes.

L’objectif est d’éviter qu’au fil du temps, certaines informations deviennent obsolètes, incomplètes ou incohérentes avec la réalité opérationnelle, ce qui pourrait compromettre l’exactitude du registre et la conformité aux exigences de DORA.

Cas particulier : mise à jour après audit ou incident majeur

En plus des mises à jour immédiates et de la révision annuelle, certaines situations imposent l’actualisation du registre :

• À la suite d’un audit interne ou externe : si l’audit révèle une incohérence, une information manquante ou un risque sous-estimé, le registre doit être mis à jour en conséquence ;
• Après un incident affectant un service TIC critique : un cyber-incident, une défaillance majeure ou une indisponibilité prolongée peuvent révéler un risque qui n’a pas suffisamment été pris en compte. Dans ce cas, le registre devra être amendé pour refléter la nouvelle évaluation des risques et intégrer les mesures correctives mises en place.

Intégration du registre DORA dans le cadre de gestion des risques TIC

#1 La place du registre DORA dans la gestion des risques TIC

Les évaluations standardisées du modèle B_07.01 du registre DORA modifient la cotation des risques liés aux prestataires de services TIC. Il faudra donc adapter les processus d'évaluation existants, particulièrement sur deux axes :

1. L'enrichissement de la cartographie des risques IT : les identifiants uniques du registre tracent l'impact des services TIC sur chaque processus métier critique. La granularité des données du registre DORA permet une vue détaillée des dépendances technologiques que la cartographie classique ne capture pas toujours ;
2. Les référentiels de contrôle permanents s'appuient désormais sur la classification DORA. Les contrôles de premier et second niveau doivent être alignés avec les exigences du registre, notamment sur la surveillance des KPI définis dans le modèle B_99, le suivi des plans de remédiation post-incidents et la vérification des engagements contractuels listés dans le B_02.

Au vu de la fréquence des mises à jour et du volume des données du registre DORA, l’automatisation est indispensable :

• La mise à jour en temps réel des 15 modèles standardisés implique des centaines de champs à synchroniser ;
• Les modifications des contrats prestataires (B_02) doivent être immédiatement reflétées dans les évaluations de risques (B_07) ;
• Les contrôles permanents requièrent un accès constant aux dernières versions des données. Sans interfaces automatisées entre le registre et les outils GRC, le risque d'incohérences et d'erreurs devient significatif.

#2 Surveillance des prestataires critiques via le registre

Le registre DORA impose une surveillance renforcée des prestataires critiques à travers un processus structuré de suivi et d'alerte. Les modèles B_05.01 et B_05.02 établissent la cartographie de la chaîne d'approvisionnement des services TIC pour identifier les dépendances directes et indirectes. Cette surveillance s'appuie sur trois niveaux d'analyse :

Le monitoring des services critiques

• Suivi des indicateurs de performance définis dans le B_99 ;
• Détection des déviations par rapport aux seuils contractuels ;
• Alertes automatiques en cas de dégradation des services.

L'évaluation continue des prestataires

• Analyse des incidents et de leur impact sur les fonctions critiques ;
• Vérification du respect des engagements contractuels ;
• Revue périodique des évaluations de risques B_07.

La gestion des interdépendances

• Identification des concentrations de risques entre prestataires ;
• Évaluation des effets cascade en cas de défaillance ;
• Surveillance particulière des sous-traitants critiques.

💡 À savoir

Le déclenchement des alertes s'appuie sur des seuils prédéfinis dans le registre, alignés avec les tolérances aux risques de l’entreprise. Chaque alerte génère un workflow d'escalade qui implique les équipes opérationnelles, le risk management et la conformité selon la gravité de la situation.

#3 La contribution du registre au plan de continuité d'activité

Le registre DORA enrichit le plan de continuité d'activité par sa cartographie détaillée des dépendances technologiques. Les modèles B_06.01 et B_07.01 identifient précisément quels services TIC sont indispensables à quels processus métier, avec leurs délais maximaux d'interruption acceptables et les alternatives disponibles.

Cette connaissance détaillée des dépendances impose naturellement une révision des plans de continuité. Les procédures de bascule doivent désormais s'appuyer sur les informations contractuelles du modèle B_02, notamment les engagements de reprise négociés avec les prestataires critiques. Les prérequis techniques pour chaque solution de repli sont documentés et alignés avec les capacités réelles des prestataires.

En situation de crise, l'accès au registre devient lui-même un élément critique du dispositif. Les procédures d'urgence intègrent donc :

• Les modalités d'accès aux données du registre en mode dégradé ;
• Les circuits d'escalade basés sur la criticité des services impactés ;
• Les obligations de notification DORA.

💡 À savoir

Les exercices de continuité d'activité doivent désormais prévoir un volet dédié à la disponibilité et à l'exactitude des données du registre DORA, dans la mesure où ce document est considéré comme un prérequis à l'efficacité des procédures de secours.

#4 Le registre DORA dans le reporting et la gouvernance

Le registre DORA s'intègre dans le dispositif de contrôle interne via des reportings aux instances de gouvernance. Les comités des risques et de sécurité reçoivent désormais des synthèses régulières basées sur les données du registre, notamment :

• Les évolutions significatives dans l'évaluation des risques prestataires (B_07.01) ;
• Les incidents majeurs et leurs impacts sur les services critiques ;
• L'état des plans de remédiation en cours.

La gouvernance du registre lui-même nécessite une organisation dédiée :

• Un responsable désigné pour la tenue et la mise à jour du registre ;
• Des processus de validation des modifications qui impliquent les différentes lignes de défense ;
• Un reporting trimestriel au comité des risques sur la qualité et l'exhaustivité des données.

La complexité du registre et son caractère réglementaire imposent également un contrôle permanent renforcé. Les équipes de contrôle interne doivent donc vérifier la cohérence entre les données du registre et la réalité opérationnelle, le respect des délais de mise à jour et des processus de validation ainsi que l'efficacité des interfaces avec les autres outils de gestion des risques.

💡 À savoir

La responsabilité de la tenue du registre doit être formellement attribuée dans l'organigramme de gouvernance, avec une équipe dédiée. Il s’agit typiquement du département des risques opérationnels ou de la sécurité des systèmes d'information, en coordination avec les équipes achats et juridique.

Meilleures pratiques pour assurer la conformité continue au règlement DORA

#1 Automatisation de la conformité documentaire avec Provigis

Le modèle « B_07.01 » du registre DORA exige une évaluation continue des prestataires TIC, et cela passe notamment par la vérification de leur conformité au sens large.

Concrètement, cette exigence impose aux établissements financiers de maintenir une vue actualisée des documents de conformité et des certifications de leurs prestataires TIC : attestations sociales et fiscales, K-bis, certifications ISO, attestations d'assurance, etc.

Prenons l’exemple d’une banque de taille moyenne. L’organisation devra gérer simultanément AWS pour le Cloud, IBM pour le Core Banking, SAS pour l'analytics, Splunk pour le SIEM, Thales pour la sécurité, etc. Lorsqu’elle est réalisée manuellement, la collecte et la vérification des documents de conformité devient vite ingérable : multiplicité des sources, vérifications d'authenticité chronophages, suivi des dates d'expiration, relances des prestataires, etc.

En tant que tiers de collecte probatoire (TCP), nous avons développé une plateforme digitale qui simplifie la gestion de ces documents de conformité :

• La collecte automatisée auprès des prestataires TIC via une interface dédiée ;
• La vérification systématique d'authenticité par connexion aux sources primaires (registre du commerce, URSSAF, etc.) ;
• Le suivi en temps réel des dates d'expiration avec relances automatiques ;
• La centralisation des preuves dans un espace sécurisé et auditable.

Ces données de conformité et de certification alimentent directement plusieurs champs du registre DORA :

• Les certifications et accréditations des prestataires ;
• Les preuves de conformité réglementaire ;
• Les attestations d'assurance en cours de validité.

Les équipes sont ainsi libérées des tâches chronophages de collecte et vérification manuelle (qui peuvent représenter jusqu'à 70 % du temps consacré au suivi de la conformité des prestataires). Les ressources pourront être réaffectées aux tâches d'analyse des risques. Demandez votre démo.

💡 À savoir

Provigis fournit des API REST avec authentification OAuth1 pour intégrer automatiquement les données de conformité dans vos outils GRC et systèmes internes. Les données sont disponibles en JSON ou XML et peuvent donc être injectées dans les modèles standardisés du registre DORA.

#2 Contrôles qualité du registre DORA

La complexité des liens entre les 15 modèles du registre DORA rend les incohérences particulièrement difficiles à détecter manuellement. Notre expérience montre qu'une erreur dans un champ peut facilement se propager et créer des écarts significatifs entre les différents modèles.

Contrôle Description Validation de la cohérence entre modèles DORA Chaque prestataire critique recensé dans le « B_05.01 » doit avoir des contrats associés dans le « B_02 » et une évaluation dans le « B_07.01 ». Par exemple, un prestataire Cloud ne peut pas être considéré comme étant « critique » dans un modèle et « standard » dans un autre. Contrôles de mises à jour des données Vérification mensuelle de l'actualisation des évaluations de risques et des changements contractuels. Un changement de périmètre chez un prestataire critique doit déclencher une mise à jour immédiate du registre. Surveillance des changements de criticité Tout changement dans l'évaluation d'un prestataire doit être documenté et justifié. Par exemple, le passage de « standard » à « critique » pour AWS suite à la migration de nouveaux services doit être tracé. Vérification des liens de dépendance Identification et contrôle des chaînes de sous-traitance critiques. Un prestataire qui utilise lui-même des services Cloud critiques doit être identifié pour évaluer le risque de concentration.

💡 À savoir

L'ACPR et l'AMF peuvent demander la justification de toute modification significative dans l'évaluation des prestataires critiques. La traçabilité des décisions devient alors une preuve réglementaire.

#4 Intégration au dispositif de contrôle permanent

Le registre ne doit pas être perçu comme une obligation réglementaire isolée, car l’approche en silo présente un risque majeur : le décalage progressif entre les contrôles quotidiens et les informations du registre. Voici 4 bonnes pratiques à adopter :

• L'intégration des points de contrôle DORA dans le plan existant : chaque contrôle permanent sur les prestataires critiques doit vérifier la cohérence avec les données du registre. Par exemple, un incident de sécurité chez un prestataire doit déclencher une réévaluation de sa criticité dans le B_07.01 ;
• La mise en place d'indicateurs de surveillance dédiés : les KPIs existants sont enrichis avec les seuils DORA. Un taux d'incident anormalement élevé chez un prestataire doit ainsi être visible à la fois dans le tableau de bord opérationnel et dans le registre ;
• L'adaptation des reportings mensuels : les comités risques opérationnels intègrent une section dédiée à la revue des modifications significatives du registre. Les évolutions de criticité des prestataires y sont systématiquement challengées ;
• Le renforcement des contrôles de second niveau : les équipes conformité et risques opérationnels testent régulièrement la fiabilité des données du registre via des contrôles thématiques. Leur périmètre doit s’élargir à la validation des évaluations DORA.

#4 Formation et montée en compétence des équipes

La complexité du registre nécessite une expertise technique, à la croisée de la conformité réglementaire et de la gestion des risques IT.

⚠️ Une mauvaise compréhension des critères d’évaluation d’un prestataire TIC ou des conditions qui doivent déclencher une mise à jour peut aboutir à des déclarations erronées et exposer l’entité à des sanctions.

De nombreux établissements peinent à identifier quels profils doivent être formés et sur quels aspects. La première étape sera donc d’identifier les populations clés : les équipes risques opérationnels qui cotent les risques TIC, les équipes achats qui évaluent les prestataires critiques, et les correspondants IT qui qualifient techniquement les services. Chaque population doit maîtriser les modèles DORA qu'elle manipule au quotidien.

L'expérience montre que sans cas pratiques concrets, les équipes développent des interprétations divergentes du registre. Il faut donc exercer les équipes sur des situations réelles, par exemple :

• Cotation sur le B_07.01 ;
• Simulation de changement de criticité d'un prestataire Cloud ;
• Analyse d'impact d'un incident majeur…

Pour maintenir cette expertise dans la durée, les établissements les plus matures peuvent désigner un référent DORA par département concerné. Il pourra animer des sessions mensuelles de questions/réponses et partager les retours d'expérience suite aux contrôles ACPR. Il sera également chargé de la disponibilité/mise à jour de la documentation opérationnelle (guides de cotation, procédures de mise à jour, logigrammes de décision…).

Provigis : automatisez votre conformité documentaire DORA

Les premiers mois d'application du règlement DORA mettront probablement à défi la capacité des établissements financiers à maintenir dans la durée un registre conforme, fiable et actualisé. Au-delà des aspects techniques, c'est surtout la gouvernance de l'information qui pose question. Entre les mises à jour quotidiennes, les contrôles de cohérence et les reportings réglementaires, la gestion documentaire est un point critique.

Cette complexité est particulièrement visible dans la gestion des preuves de conformité des prestataires TIC. Les établissements qui tentent de gérer manuellement la collecte et la vérification des documents (K-bis, attestations, certifications) se retrouvent rapidement submergés et prennent le risque de compromettre la fiabilité de leur registre DORA.

En assurant la collecte automatisée et la vérification systématique des documents de conformité, Provigis permet aux équipes de se concentrer sur leur véritable valeur ajoutée : l'analyse des risques et le pilotage de la résilience opérationnelle. Demandez votre démo.