DORA et gestion des risques tiers : le guide opérationnel pour les fonctions Conformité et Risques

La plupart des contenus disponibles sur DORA se rangent dans deux catégories : des guides très techniques pensés pour le RSSI et les équipes IT, ou des présentations généralistes qui déroulent les cinq piliers du règlement sans jamais descendre au niveau opérationnel. Entre les deux, un angle mort persiste : celui du Compliance Officer ou du Risk Manager dont le rôle n’est pas de sécuriser les systèmes, mais de gouverner le programme de gestion des risques tiers dans sa globalité — tenir à jour le Registre d’Informations, arbitrer la classification des prestataires, faire respecter les clauses contractuelles, et rendre compte à l’organe de direction. C’est ce gap précis que cet article comble.

Ce que DORA impose à la direction des risques et ce que l’IT ne peut pas gérer seul

Le règlement (UE) 2022/2554 (DORA), en application depuis le 17 janvier 2025, est explicite sur ce point à son article 5 : l’organe de direction porte la responsabilité ultime de la gestion des risques liés aux TIC, et cette responsabilité n’est pas délégable. Le conseil d’administration ou la direction générale doit définir, approuver et superviser le cadre de gestion des risques TIC, la stratégie de résilience opérationnelle numérique, la politique relative aux prestataires tiers, et le plan d’audit qui s’y rattache.

Ce cadrage change la donne pour beaucoup d’organisations qui ont, par réflexe, confié DORA à la DSI ou au RSSI. Ces fonctions sont indispensables pour les contrôles techniques — chiffrement, tests de résilience, gestion des incidents — mais elles ne peuvent pas porter seules la gouvernance du dispositif : la tenue du Registre d’Informations, l’arbitrage sur la classification des prestataires critiques, la vérification des clauses contractuelles ou la construction du reporting destiné au Board relèvent d’une gouvernance des risques et de la conformité, pas d’une compétence technique. Un dispositif DORA piloté uniquement par l’IT produit généralement un registre technique incomplet et un reporting au Board illisible pour des administrateurs non spécialistes — exactement l’inverse de ce que le règlement attend.

Que doit contenir le Registre d’Informations DORA ?

Le Registre d’Informations est la pièce centrale du dispositif : une base structurée de tous les accords contractuels avec les prestataires tiers de services TIC, que l’entité financière doit tenir à jour et transmettre aux autorités de supervision. La première échéance officielle de remise, fixée au 31 mars 2026, a marqué le passage d’un exercice de préparation à une obligation de maintenance continue — le registre doit désormais rester accessible aux superviseurs sur demande, pas seulement produit une fois par an.

Le registre doit documenter, pour chaque prestataire : sa dénomination sociale et son identifiant, son pays d’établissement, le type de service fourni (hébergement cloud, éditeur logiciel, infrastructure réseau, etc.), et le cas échéant sa désignation comme prestataire critique au sens du règlement. Pour chaque accord contractuel, il faut consigner la référence du contrat, ses dates de début et de fin ou son caractère à durée indéterminée, une description précise des services couverts, les modalités tarifaires, et les conditions de renouvellement et de résiliation. Le registre doit également établir le lien entre chaque service TIC et la ou les fonctions de l’entité qu’il supporte — un exercice de cartographie qui ne peut être fait correctement sans la connaissance métier que porte la fonction Risques. Enfin, lorsque le prestataire recourt lui-même à des sous-traitants, le registre doit documenter cette chaîne : identité, pays d’établissement, nature des services sous-traités, et sous-traitants de rang supérieur le cas échéant.

Comment classifier les prestataires TIC critiques sous DORA ?

DORA emploie le mot « critique » dans deux sens qu’il est indispensable de distinguer, et c’est précisément là que la fonction Conformité doit poser une méthode claire plutôt que de s’en remettre à des intuitions.

Le premier sens qualifie la fonction de l’entité financière elle-même : une fonction est dite critique ou importante lorsque sa défaillance est susceptible de nuire sérieusement à la performance financière, à la solidité ou à la continuité des activités de l’entité. C’est une approche par les conséquences, propre à chaque entité — un même service d’hébergement cloud peut soutenir une fonction critique chez un assureur et une fonction courante chez un autre acteur de taille différente. Le second sens qualifie des prestataires désignés directement par la Commission européenne, indépendamment de l’usage qui en est fait par telle ou telle entité, sur la base de critères d’importance systémique : nombre et type d’entités financières dépendantes, substituabilité du prestataire, nature des services fournis. En novembre 2025, la Commission a publié sa première liste de dix-neuf prestataires ainsi désignés comme critiques, parmi lesquels Amazon Web Services, Microsoft, Google Cloud, SAP, Oracle, IBM, Accenture, Capgemini, Orange ou Deutsche Telekom.

Le piège méthodologique à éviter : la désignation d’un prestataire comme critique par la Commission n’implique pas automatiquement que les services qu’il fournit à votre entité supportent une fonction critique ou importante — et inversement, un prestataire non désigné peut très bien soutenir une fonction critique chez vous. La fonction Conformité doit donc analyser, pour chaque relation contractuelle, trois éléments distincts : la fonction réellement soutenue par le service, l’impact potentiel d’une perturbation de cette fonction, et les obligations qui en découlent. C’est cette analyse au cas par cas, et non la simple consultation de la liste européenne, qui détermine le niveau d’exigence contractuelle à appliquer.

Sur un périmètre de quelques dizaines de prestataires TIC, cette classification peut encore se tenir dans un tableur. Au-delà, elle devient difficile à maintenir sans une solution de gestion des risques tiers (TPRM) qui centralise l’évaluation initiale à l’entrée en relation, la ré-évaluation périodique, et le suivi continu des signaux d’alerte propres à un prestataire TIC : dégradation de sa santé financière, expiration d’une certification de sécurité (ISO 27001, SOC 2), changement de sous-traitant en amont, ou concentration excessive de fonctions critiques chez un même acteur. Une solution TPRM ne se substitue pas à la décision de classification elle-même — celle-ci reste un arbitrage de la fonction Conformité, qui doit rester en mesure de justifier pourquoi tel prestataire a été classé critique ou non — mais elle industrialise la collecte des données probantes et maintient le Registre d’Informations à jour en continu plutôt qu’au prix d’une reconstitution manuelle avant chaque échéance de remise aux autorités.

Quelles clauses contractuelles la Conformité doit-elle exiger sous l’Article 30 ?

L’article 30 de DORA impose un socle de clauses contractuelles pour l’ensemble des accords TIC, renforcé pour ceux qui soutiennent une fonction critique ou importante. Pour tout contrat, la Conformité doit s’assurer que sont présentes : une description claire et complète des services fournis et des conditions applicables à la sous-traitance, la localisation des données avec notification préalable de tout changement, des garanties de disponibilité, d’authenticité, d’intégrité et de confidentialité des données, des modalités d’accès et de récupération des données en cas d’insolvabilité ou de résiliation du prestataire, une description des niveaux de service, une obligation d’assistance du prestataire en cas d’incident TIC, une clause de coopération avec les autorités compétentes, des droits de résiliation assortis de délais de préavis minimums, et une participation aux programmes de sensibilisation à la sécurité TIC de l’entité.

Pour les contrats qui soutiennent une fonction critique ou importante, ce socle ne suffit pas : il faut y ajouter des objectifs de performance quantitatifs et qualitatifs précis, des droits d’audit renforcés au bénéfice de l’entité, de ses auditeurs et des autorités, des plans de continuité d’activité testés par le prestataire, une obligation de participation aux tests d’intrusion, et une stratégie de sortie assortie d’une période de transition définie. Faire respecter ce niveau d’exigence relève typiquement d’un arbitrage Conformité au moment de la négociation contractuelle, en amont de la signature — un contrôle a posteriori, une fois le contrat signé, coûte nettement plus cher à corriger.

Le plan de sortie : l’obligation la plus souvent négligée

L’article 28 impose la mise en place de stratégies de sortie pour tous les services TIC qui soutiennent une fonction critique ou importante, en tenant compte des risques susceptibles d’émerger au niveau du prestataire : défaillance, dégradation de la qualité du service, interruption d’activité liée à une prestation défaillante, ou tout risque matériel affectant le déploiement continu et approprié du service. Le texte est également précis sur la forme : ces plans doivent être complets, documentés, et suffisamment testés et révisés périodiquement.

C’est sur ce dernier point que la plupart des dispositifs échouent. De nombreuses équipes Conformité savent citer l’article 28 comme une obligation existante, mais ne produisent jamais de document décrivant concrètement le contenu d’un plan de sortie conforme : quels risques sont couverts, quelle est la durée de la période de transition envisagée, quels prestataires alternatifs ont été identifiés en amont, comment la portabilité des données serait assurée, et surtout — le plan a-t-il été testé, ou existe-t-il seulement sur le papier ? Un plan de sortie qui n’a jamais été exercé n’apporte aucune garantie réelle en cas de défaillance effective du prestataire, et c’est précisément ce que les autorités de supervision viennent vérifier.

Que doit voir le Board dans le reporting DORA ?

Puisque l’organe de direction porte la responsabilité ultime et ne peut pas la déléguer, il a besoin d’un reporting à la hauteur de cette responsabilité — pas d’un tableau de bord à indicateurs verts qui masque la réalité du dispositif. Concrètement, le Board doit pouvoir examiner des indicateurs précis, des scénarios de risque quantifiés et des plans de remédiation datés, et non une synthèse qualitative sans données sous-jacentes.

Pour la fonction Conformité, cela signifie construire un reporting qui couvre : l’état de complétude et de mise à jour du Registre d’Informations, la liste des fonctions critiques ou importantes identifiées et des prestataires qui les soutiennent, les écarts constatés entre les clauses contractuelles exigées par l’article 30 et celles réellement présentes dans les contrats en vigueur, le statut de test des plans de sortie, l’exposition au risque de concentration lorsque plusieurs fonctions critiques reposent sur un même prestataire, et le suivi des incidents notifiés aux autorités. Cette exigence de traçabilité rejoint un constat que l’on retrouve dans d’autres cadres de conformité fondés sur la cartographie des tiers. Marie-Soisick Floc’h, cheffe de mission Conformité et Contrôle Interne à la Société des grands projets, décrit un gain comparable obtenu sur son propre périmètre de tiers : « La solution nous a permis de structurer nos processus, d’éliminer les doubles saisies et de centraliser toutes les informations documentaires. On a gagné en traçabilité, en réactivité lors des évaluations […] ainsi qu’en efficacité au quotidien. » C’est cette même discipline — un référentiel unique, centralisé et à jour — qui permet à une fonction Conformité de produire un reporting DORA que le Board peut réellement exploiter, plutôt qu’un document reconstitué à la main avant chaque réunion.

Articuler DORA et NIS2 : éviter la double gouvernance

DORA et la directive NIS2 ont été adoptés le même jour, le 14 décembre 2022, mais avec des calendriers d’application différents : DORA s’applique depuis le 17 janvier 2025, tandis que la transposition de NIS2 était attendue pour le 18 octobre 2024. Les deux textes se chevauchent largement sur le fond — gestion des risques cyber, notification d’incidents, supervision des prestataires — ce qui crée un risque réel de double gouvernance si les fonctions Conformité, Risques et Sécurité ne s’accordent pas en amont sur qui pilote quoi.

Le principe qui résout ce chevauchement est celui de la lex specialis : DORA est un texte sectoriel qui prime sur NIS2 pour le secteur financier. Les entités couvertes par DORA n’appliquent pas les dispositions de NIS2 relatives à la gestion des risques cyber, aux obligations de notification et à la supervision — elles appliquent celles de DORA. Dans la pratique, une même entité peut néanmoins se retrouver sous double supervision lorsqu’elle exerce des activités qui dépassent le strict périmètre financier couvert par DORA : supervision sectorielle européenne d’un côté, supervision nationale de l’ANSSI de l’autre pour les activités non couvertes. Un point opérationnel à ne pas négliger : les délais de notification d’incidents diffèrent — DORA impose une notification initiale sous quatre heures, quand NIS2 prévoit une alerte précoce sous vingt-quatre heures suivie d’un rapport détaillé sous soixante-douze heures. Sans un processus d’escalade interne unique et clairement documenté, une organisation soumise aux deux textes risque de produire deux chaînes de décision distinctes pour un même incident — exactement la duplication de gouvernance que la fonction Conformité doit éviter en structurant, en amont, un seul processus de qualification et de notification, décliné ensuite selon le texte applicable.