# DORA Risque TIC lié aux tiers & Register of Information > Constituer le registre d'informations DORA : base légale, tableaux du modèle des AES, fonctions critiques ou importantes et erreurs fréquentes. - Source: https://www.sidd.swiss/fr/perspectives/dora-risque-tic-lie-aux-tiers-et-register-of-information/ - Langue: fr-CH - Publié: 2026-05-24 - Mise à jour: 2026-05-24 - Auteur·e: Marc Grob - Éditeur: SIDD Institut pour la protection des données et la sécurité des données, une marque de Priverion GmbH, Zugerstrasse 32, 6340 Baar (ZG), Suisse ## Introduction Le Register of Information (RoI) est probablement l'artefact le plus concret – et en même temps le plus exigeant – de DORA. L'art. 28, par. 3 du règlement (UE) 2022/2554 oblige chaque *entité financière* concernée à tenir, mettre à jour et transmettre annuellement à l'autorité compétente un registre complet de tous les arrangements contractuels relatifs à l'utilisation de services TIC par des tiers. Le règlement d'exécution de la Commission (UE) 2024/2956 du 29 novembre 2024 standardise le format avec 15 tableaux de données. **Cet article couvre :** - L'ancrage juridique du RoI dans l'art. 28 DORA et les RTS/ITS complémentaires. - Les 15 tableaux de données du modèle des AES – sur le fond et sur le processus. - La classification des fonctions critiques et importantes (art. 3, par. 1, n° 22 DORA). - La construction étape par étape d'un RoI en 90 jours. - Les erreurs d'implémentation fréquentes et comment les éviter. Les ancrages juridiques sont les art. 28-30 du règlement principal DORA, le règlement d'exécution de la Commission (UE) 2024/2956, les lignes directrices conjointes des AES sur le Register of Information ainsi que, à titre complémentaire, les RTS sur la sous-externalisation (règlement délégué de la Commission (UE) 2024/1773) et les RTS sur les fonctions critiques (art. 3, par. 1, n° 22). Pour la désignation des CTPPs, le règlement délégué de la Commission (UE) 2024/1502 s'applique en outre. ## Pourquoi le RoI est au cœur du Pilier 4 de DORA Le RoI remplit plusieurs fonctions parallèles, ce qui explique sa complexité : - **Instrument de surveillance :** L'autorité compétente (en DE BaFin/Bundesbank, en LU CSSF, en AT FMA, en IT Banca d'Italia/Consob/IVASS) reçoit le RoI annuellement par voie électronique et l'utilise pour les analyses de risques, la désignation des CTPPs et les analyses de concentration sectorielle. - **Instrument de pilotage interne :** Le RoI oblige les entités financières à établir une correspondance rigoureuse entre fonctions et fournisseurs. De nombreux établissements découvrent seulement lors de la construction du RoI qu'ils n'avaient jamais clairement identifié leurs propres fonctions critiques. - **Base contractuelle :** Le RoI documente quels contrats couvrent quelles fonctions – condition préalable à la vérification de la conformité avec l'art. 30 DORA et à la discipline de sous-externalisation. - **Risque de concentration :** L'autorité compétente agrège les RoIs à l'échelle sectorielle pour identifier les risques de concentration (p. ex. que 80 % des gestionnaires d'actifs de l'UE utilisent le même fournisseur cloud). - **Désignation des CTPPs :** Les AES utilisent les données des RoI comme donnée d'entrée pour la désignation des prestataires tiers critiques selon l'art. 31 DORA. La complexité du RoI n'est pas une fin en soi, mais reflète ses fonctions multiples. Une architecture RoI bien gérée constitue donc simultanément la gestion des fournisseurs, la gestion des risques, la gestion des contrats et le reporting de surveillance en un seul outil. ## Les 15 tableaux de données du modèle des AES Le règlement d'exécution de la Commission (UE) 2024/2956 structure le RoI en 15 tableaux, regroupés en trois blocs thématiques : - **Informations générales (tableaux B_01 à B_03) :** identification de l'entité financière déclarante (LEI, siège, structure des filiales), vue d'ensemble de tous les arrangements, nombre total de prestataires TIC tiers. - **Arrangements contractuels (tableaux B_04 à B_07) :** ID du contrat, type de contrat, fonctions d'application, durée, délais de résiliation, droit applicable, juridictions compétentes, rémunération, logique de renouvellement. - **Services TIC et fonctions (tableaux B_08 à B_15) :** classification des services TIC selon l'annexe III, fonctions concernées (critiques/importantes vs autres), substituabilité, chaîne de sous-externalisation, lieux de traitement et de stockage des données, États membres de l'UE et pays tiers concernés, délais de rétablissement en cas d'urgence, exigences de cybersécurité. Au total, une description complète d'un contrat dans le RoI comprend environ 90 à 100 points de données. Pour un établissement de taille moyenne avec 50 à 200 contrats TIC, cela donne un RoI avec 4 500 à 20 000 points de données individuels. La maintenance nécessite une gouvernance des données claire, des propriétaires de données définis et idéalement un référentiel soutenu par un outil plutôt qu'une solution Excel pure. ## Classification des fonctions critiques et importantes L'art. 3, par. 1, n° 22 DORA définit une *fonction critique ou importante* comme une fonction dont la défaillance nuirait considérablement à la performance financière, la viabilité ou la résilience opérationnelle d'une entité – ou à la fourniture de services dont l'interruption aurait des effets sur le respect des obligations d'autorisation ou des exigences réglementaires. La classification est le paramètre décisif pour le champ d'application DORA, car de nombreuses obligations (art. 28, par. 4, art. 29, art. 30, par. 3) ne s'appliquent qu'aux services TIC soutenant des fonctions critiques ou importantes. Une méthodologie de classification éprouvée : 1. **Inventaire des fonctions :** recueil de toutes les fonctions métier et de support (typiquement 50-150 fonctions selon la taille de l'établissement). 2. **Analyse d'impact :** évaluation des effets d'une interruption de plusieurs jours sur les clients, le marché, la surveillance, la réputation et la situation financière. Seuils quantitatifs (p. ex. EUR 1 million de perte journalière = critique). 3. **Perspective réglementaire :** les fonctions qui servent à remplir les obligations d'autorisation sont automatiquement critiques. 4. **Mapping fonction-contrat :** quels services TIC soutiennent quelle fonction ? Un seul contrat peut soutenir plusieurs fonctions. 5. **Logique d'héritage :** si une fonction est critique, tous les services TIC qui la soutiennent tendent à être critiques. Une classification trop restrictive réduit l'effort DORA à court terme, mais crée un risque de surveillance (l'autorité constate ultérieurement que d'autres fonctions étaient critiques). Une classification trop large gonfle l'effort d'implémentation. Recommandation : méthodologie documentée et traçable avec révision annuelle. ## Construire un RoI en 90 jours Un plan en 90 jours éprouvé pour un établissement de taille moyenne : 1. **Jours 1-15 – Méthodologie et outils :** définir la structure des données, décision sur les outils (Excel, outil GRC, outil RoI dédié), nommer les propriétaires de données par tableau, établir les règles de mapping. 2. **Jours 16-30 – Inventaire des fonctions et classification :** série d'ateliers avec toutes les lignes métier, création de l'inventaire des fonctions, classification critique/importante vs autres, approbation par le comité des risques. 3. **Jours 31-50 – Inventaire des contrats :** collecte de tous les contrats TIC (typiquement répartis entre achats, informatique, conformité, lignes métier individuelles), saisie structurée des 90-100 points de données par contrat. 4. **Jours 51-70 – Mapping fonction-contrat :** quelle fonction est soutenue par quels services TIC ? Identification des lacunes (fonction sans contrat visible) et des redondances. 5. **Jours 71-85 – Assurance qualité :** contrôles de cohérence des données, validation par rapport aux spécifications du modèle des AES, audit par sondage avec les lignes métier. 6. **Jours 86-90 – Approbation et mise en place du reporting :** approbation par la direction, préparation du reporting de surveillance, documentation du cycle de maintenance (révision annuelle au minimum). Effort réaliste : 1,5 à 3 mois-ETP pour la phase de construction, puis 0,3 à 0,5 ETP pour la maintenance. Les investissements en outils s'élèvent selon la solution à CHF 15 000 à CHF 80 000 par an. ## Sous-externalisation et exigences contractuelles L'art. 29 DORA et le règlement délégué de la Commission (UE) 2024/1773 complémentaire (RTS on Sub-Outsourcing) exigent une discipline particulière dans la gestion de la sous-externalisation. Obligations essentielles : - **Autorisation préalable :** la sous-externalisation de fonctions critiques ou importantes nécessite l'accord écrit préalable de l'entité financière. - **Transmission contractuelle :** le prestataire TIC tiers doit transmettre intégralement les conditions contractuelles conformes à DORA aux sous-traitants (flow-down). - **Analyse de concentration :** si plusieurs fonctions critiques dépendent du même sous-sous-traitant, cela doit être documenté dans le RoI et évalué dans le registre des risques. - **Spécificités des pays tiers :** la sous-externalisation vers des pays tiers (en particulier sans décision d'adéquation en matière de protection des données) exige une évaluation juridique supplémentaire – incluant une évaluation d'impact sur le transfert conforme à Schrems II. L'art. 30 DORA avec ses huit clauses obligatoires est l'ancre contractuelle. Les établissements suisses qui examinent les contrats TIC de leur filiale dans l'UE constatent généralement des lacunes dans au moins trois domaines : droit d'audit de la surveillance de l'UE, niveaux de service avec KPI mesurables, et clauses de sortie avec des obligations de migration concrètes. Les renégociations avec les grands fournisseurs cloud et les éditeurs SaaS sont souvent laborieuses, mais généralement couronnées de succès – les clauses standard DORA des hyperscalers (AWS, Microsoft, Google, Oracle) se sont établies depuis le T2 2024. ## Erreurs d'implémentation fréquentes Pièges récurrents observés dans de réels projets d'implémentation 2024-2025 : - **Inventaire des fonctions en tant qu'afterthought :** quiconque commence l'inventaire des contrats sans un inventaire clair des fonctions se perd dans des points de données sans logique de pilotage. Fonctions d'abord, contrats ensuite. - **RoI comme île Excel :** Excel fonctionne pour la saisie initiale, mais échoue à la gestion des versions, l'édition multi-utilisateurs, la validation et la piste d'audit. Un outil devient nécessaire au plus tard lors du deuxième reporting de surveillance. - **Sous-externalisation en boîte noire :** de nombreux prestataires TIC tiers fournissent des listes de sous-traitants incomplètes. Recommandation : le contrat oblige à une liste de sous-traitants mise à jour trimestriellement avec les données de localisation. - **Classification unique :** les fonctions changent leur degré de criticité – un nouveau produit, une ligne métier fermée, un nouvel ancrage réglementaire. La révision annuelle de la classification est obligatoire. - **Propriétaires de données non définis :** qui dans l'organisation est responsable de chacun des 15 tableaux ? Sans RACI clair, le RoI reste un exercice de conformité plutôt qu'un pilotage opérationnel. - **Société mère suisse exclue :** si la filiale dans l'UE reçoit des services TIC de la société mère suisse, cet « arrangement » intragroupe doit être saisi dans le RoI. C'est souvent oublié. La plupart des erreurs peuvent être corrigées après coup – mais chaque cycle de correction coûte des efforts et potentiellement de l'attention de la surveillance. Une méthodologie propre dès le départ est rentable. ## Comment SIDD vous accompagne SIDD accompagne les établissements suisses et leurs filiales dans l'UE dans la construction du RoI et la gestion continue des fournisseurs selon DORA. Nous démarrons par un sprint méthodologique de 2 semaines dans lequel nous définissons l'inventaire des fonctions, la classification et la structure des données. Nous effectuons ensuite l'inventaire des contrats et le mapping fonction-contrat et fournissons un RoI de qualité garantie dans le modèle des AES. Pour l'adaptation des contrats à l'art. 30 DORA, nous fournissons des modèles de clauses, des guides de négociation et un soutien juridique pour la renégociation avec les grands fournisseurs. Sur demande, nous assumons la gestion continue des fournisseurs dans le cadre d'un mandat, intégré à notre [service RSSI externe](https://www.sidd.swiss/fr/services/ciso-externe). Pour l'évaluation technique de la résilience des principaux prestataires TIC tiers, nous fournissons des [tests de pénétration](https://www.sidd.swiss/fr/services/test-intrusion) et des [scans de vulnérabilités](https://www.sidd.swiss/fr/services/analyse-vulnerabilites) qui mesurent objectivement la sécurité des fournisseurs. Prenez rendez-vous pour un premier entretien via [/kontakt](https://www.sidd.swiss/fr/contact) ou demandez une offre à prix fixe pour la construction du RoI en 90 jours via [/offerte](https://www.sidd.swiss/fr/devis). --- Ce document est la version Markdown de la page liée ci-dessus. Merci de citer l'URL HTML.