Le registre d'informations DORA, sans la dérive du tableur

Le règlement sur la résilience opérationnelle numérique (DORA) s'applique aux entités financières de l'UE depuis le 17 janvier 2025. De tout ce qu'il exige, le registre d'informations est l'un des éléments les plus concrets : un relevé structuré de chaque accord contractuel conclu avec des prestataires tiers de services TIC. Cela ressemble à un exercice d'inventaire. En pratique, il vérifie si vos équipes achats, IT, risques et métiers partagent une même vision de qui soutient quoi.

Ce qu'est le registre

L'article 28 de DORA impose aux entités financières de tenir et de mettre à jour un registre d'informations sur tous les accords contractuels portant sur l'utilisation de services TIC fournis par des prestataires tiers de services TIC. Le registre est tenu au niveau de l'entité et, pour les groupes, aux niveaux sous-consolidé et consolidé.

Le registre s'adresse à plusieurs publics. En interne, il constitue l'épine dorsale de la gestion du risque lié aux prestataires tiers de services TIC : vous ne pouvez pas gérer le risque de concentration, de sortie ou de sous-traitance pour des accords que vous n'avez pas recensés. En externe, les autorités compétentes peuvent demander le registre complet, et les entités font régulièrement rapport sur les nouveaux accords. Les autorités de surveillance utilisent aussi les données des registres à l'échelle du secteur, notamment pour éclairer la désignation des prestataires tiers critiques de services TIC au niveau de l'UE.

Le contenu et le format sont fixés dans des normes techniques d'exécution, sous la forme d'une série de modèles liés entre eux. La logique est relationnelle plutôt qu'une simple liste à plat.

Ce qu'il contient, dans les grandes lignes

Considérez le registre comme un ensemble de faits connectés :

• Les entités relevant du périmètre, y compris quelles entités du groupe utilisent quels services TIC.
• Les accords contractuels : chaque contrat avec un prestataire tiers de services TIC, sa référence, ses dates, le droit applicable, les délais de préavis et le type d'accord.
• Les prestataires, identifiés de manière cohérente, avec des informations sur leur lieu d'établissement et leur lien avec un groupe.
• Les services TIC fournis au titre de chaque accord, décrits par type.
• Les fonctions de l'entité financière que ces services soutiennent, et si chaque fonction est critique ou importante.
• La chaîne d'approvisionnement : les sous-traitants qui sous-tendent effectivement les services TIC soutenant des fonctions critiques ou importantes.
• Les évaluations de ces services, telles que la substituabilité, l'impact de leur interruption et la faisabilité d'une sortie.

Le mot clé est lié. Un seul contrat peut couvrir plusieurs services ; un seul service peut soutenir plusieurs fonctions ; la criticité d'une fonction détermine la quantité d'informations que vous devez détenir sur les prestataires qui se trouvent derrière elle.

Où les registres dérapent

La plupart des premiers registres ont été constitués sous la pression du temps dans un tableur, alimenté par des exports du service achats et des e-mails aux responsables métiers. Les problèmes apparaissent ensuite.

Le tableur s'écarte des contrats

Les contrats sont renouvelés, modifiés et résiliés tout au long de l'année. Si le registre est un fichier distinct tenu par une équipe distincte, chaque changement doit être repéré et ressaisi. En quelques mois, délais de préavis, dates de fin et données des prestataires ne correspondent plus aux documents signés.

Les sous-traitants manquent ou sont obsolètes

Les informations sur la chaîne d'approvisionnement se trouvent chez le prestataire. Elles arrivent tard, dans des formats hétérogènes, et changent lorsque le prestataire change ses propres fournisseurs. Les registres détaillent souvent le prestataire direct, mais pas du tout les sous-traitants, alors que c'est précisément là que se cache le risque de concentration.

La correspondance avec les fonctions reste floue

Relier les services TIC aux fonctions qu'ils soutiennent requiert l'apport de personnes qui comprennent le processus métier, et pas seulement le contrat. Sans liste commune des fonctions, chaque contributeur les décrit différemment, et « critique ou importante » devient une étiquette appliquée à l'instinct plutôt que selon des critères. Cela fragilise la hiérarchisation, la planification de la sortie et les priorités de test.

La responsabilité n'est pas claire

Les achats sont responsables du contrat, l'IT du service, le métier de la fonction et la gestion des risques de l'évaluation. Un registre qui appartient à tout le monde n'est tenu par personne. Lorsque la responsabilité n'est pas explicite pour chaque champ, les lacunes persistent.

Le registre vit à part de tout le reste

Les mêmes faits figurent dans votre analyse d'impact sur l'activité, vos plans de continuité et votre politique d'externalisation. Lorsque chacun détient sa propre copie, ils se contredisent.

Un modèle connecté des fournisseurs, contrats, services et fonctions

La solution durable consiste à cesser de traiter le registre comme un document et à le considérer comme une vue sur des données que vous devez de toute façon gérer. Cela signifie modéliser une seule fois les objets sous-jacents et les relier :

1. Les fournisseurs en tant qu'enregistrements, avec leurs identifiants, leur hiérarchisation et l'historique de leur filtrage.
2. Les contrats en tant qu'enregistrements rattachés aux fournisseurs, avec dates de cycle de vie, clauses, obligations et niveaux de service tenus à jour dans le cadre de la gestion normale des contrats.
3. Les services fournis au titre de ces contrats, liés aux actifs sur lesquels ils reposent.
4. Les fonctions ou processus, chacun avec son analyse d'impact et ses objectifs de reprise, liés aux services et fournisseurs dont ils dépendent.
5. Les sous-traitants en tant que fournisseurs à part entière, liés aux services qu'ils sous-tendent.

Avec cette structure, la criticité se propage de la fonction vers les services et fournisseurs qui se trouvent derrière elle, au lieu d'être saisie dans une colonne. Une modification de contrat met à jour le registre, car le registre lit les données du contrat. Les lacunes apparaissent comme des liens manquants plutôt que comme des cellules vides, et la responsabilité peut être attribuée par type d'enregistrement.

Quelques habitudes pratiques utiles, quel que soit l'outil :

• Arrêtez d'abord la liste des fonctions. Une correspondance ne vaut que par le vocabulaire auquel elle se rapporte.
• Formalisez vos critères de criticité et appliquez-les dans l'analyse d'impact, et non dans le registre.
• Demandez aux prestataires les informations sur la sous-traitance lors de l'intégration et du renouvellement, et consignez la date de leur dernière réception.
• Rapprochez le registre du contrat signé, et non du système d'achats, au moins pour les accords soutenant des fonctions critiques ou importantes.
• Effectuez un contrôle qualité avant chaque transmission : identifiants manquants, contrats expirés encore repris, fonctions sans décision de criticité.

La place d'ILSERIS

ILSERIS gère les tiers, contrats, actifs, l'analyse d'impact sur l'activité et les plans de reprise comme des enregistrements liés au sein d'un modèle de données unique. Les contrats portent leur cycle de vie, leurs obligations et leurs niveaux de service ; les fournisseurs portent leur hiérarchisation, leurs questionnaires et leur filtrage périodique ; l'analyse d'impact porte les objectifs de reprise et une cartographie des dépendances. Le registre d'informations devient alors une question posée à des données tenues à jour de toute façon, plutôt qu'un tableur tenu à côté.

Cet article constitue une information générale et non un avis juridique.