Registre d'information DORA

L'article 28, paragraphe 3, du règlement DORA (UE) 2022/2554 impose à chaque entité financière de tenir à jour un registre d'information sur tous les accords contractuels portant sur des services TIC fournis par des prestataires tiers de services TIC, au niveau de l'entité et, le cas échéant, aux niveaux sous-consolidé et consolidé.

Le format n'est pas laissé au choix de l'établissement. Le règlement d'exécution (UE) 2024/2956 de la Commission fixe 15 modèles normalisés, chacun avec un code, par exemple B_01.01 pour l'entité qui tient le registre, B_02.01 pour les accords contractuels et B_05.01 pour les prestataires. Ces modèles sont relationnels: un contrat renvoie à un prestataire par son identifiant et à une fonction par sa propre clé, si bien qu'un identifiant manquant casse chaque ligne qui y renvoie.

Au-delà des noms et des dates, quatre groupes de champs portent le contenu prudentiel. Les champs relatifs aux fonctions indiquent quelle fonction métier le service soutient et si cette fonction est critique ou importante. Les champs relatifs aux services désignent le type de service TIC selon une taxonomie fixe, ainsi que les pays de stockage et de traitement des données. Les champs contractuels contiennent les dates de début et de fin, le préavis, le droit applicable et la dépense annuelle ou le coût estimé.

Le quatrième groupe porte sur l'évaluation. Le registre indique si le prestataire est substituable et avec quelle difficulté, s'il existe un plan de sortie, la date du dernier audit et si des prestataires alternatifs ont été identifiés. L'établissement doit pouvoir défendre ces jugements, et un examinateur les compare avec ce que les métiers disent réellement du prestataire.

Le registre couvre chaque accord contractuel portant sur l'utilisation de services TIC, pas seulement ceux qui soutiennent une fonction critique ou importante.

L'évaluation de la criticité change la profondeur de l'inscription. Pour un service qui soutient une fonction critique ou importante, le registre exige la chaîne de sous-traitance, l'évaluation de la substituabilité et les modalités de sortie; pour les autres services, l'entrée est plus courte. Selon l'article 28, l'établissement évalue lui-même la criticité, et selon l'article 30 de DORA, le contrat d'une fonction critique ou importante comporte des clauses obligatoires, que précise la gestion du risque lié aux prestataires tiers de services TIC.

Pour les services qui soutiennent des fonctions critiques ou importantes, inscrivez les sous-traitants qui portent effectivement ces services ou des parties significatives de ceux-ci. Cela inclut les sous-traitants dont la perturbation nuirait à la sécurité ou à la continuité du service. Les règles du registre attribuent un rang à chaque prestataire: le prestataire direct est au rang 1, les sous-traitants suivent plus bas dans la chaîne.

Le prestataire direct doit fournir ces informations, car les dossiers d'achat seuls ne décrivent pas toujours son hébergement et son support. Demandez tôt la chaîne concernée et des identifiants stables, puis vérifiez que les entrées des prestataires concordent avec les services et les contrats enregistrés.

Les prestataires établis dans l'UE qui sont des personnes morales peuvent être identifiés par un LEI ou un EUID, et les personnes morales hors UE utilisent un LEI. Les autres types d'identifiants sont réservés aux personnes physiques agissant à titre professionnel, et non aux sociétés dépourvues de LEI. Le guide de l'ABE sur les identifiants explique ces distinctions.

Contrôlez le type et la valeur de l'identifiant avant de rattacher un prestataire aux contrats. Un numéro de TVA ne remplace pas en général le LEI ou l'EUID d'une société.

En Allemagne, le registre est remis à la BaFin. La BaFin le collecte une fois par an via sa plateforme de déclaration MVP, avec les données contractuelles au 31 décembre de l'année précédente, et le fichier doit passer sans erreur les contrôles de validation de la BaFin avant l'échéance fixée. Un fichier rejeté revient avec un journal d'erreurs et doit être soumis à nouveau, c'est pourquoi les établissements traitent les règles de validation comme une partie du modèle de données et non comme une formalité.

La BaFin transmet les registres aux autorités européennes de surveillance (AES), qui s'en servent pour désigner les prestataires tiers critiques de services TIC pour tout le secteur financier de l'UE. Le registre d'un établissement produit donc un effet au-delà de sa propre supervision: il compte parmi les données qui décident quels prestataires relèvent d'un régime européen de surveillance propre.

Plusieurs contrats peuvent tout de même dépendre d'un seul prestataire. Avant de contracter des services TIC pour une fonction critique ou importante, l'article 29 de DORA exige une évaluation de la concentration et de la substituabilité, y compris des risques de sous-traitance pertinents.

Le registre rend ces relations visibles, et les autorités utilisent aussi les registres collectés pour identifier les prestataires TIC critiques. La cybersécurité de la finance allemande et la présentation de DORA expliquent les exigences de risque plus larges.

Le registre d'information DORA est un relevé structuré de tous les accords contractuels qu'une entité financière a conclus pour l'utilisation de services TIC, tenu au titre de l'article 28, paragraphe 3, du règlement (UE) 2022/2554 et remis une fois par an au superviseur national. Son format est fixé par le règlement d'exécution (UE) 2024/2956 de la Commission, en 15 modèles relationnels qui couvrent l'entité, ses prestataires, les contrats, les fonctions soutenues et les chaînes de sous-traitance.

Non. Le registre couvre les contrats de services TIC, y compris des accords qui ne relèvent pas de l'externalisation. L'externalisation hors TIC sort de son champ. L'explication du registre par la BaFin distingue ces catégories. Un établissement devrait déterminer ses obligations pour chaque accord au lieu de traiter un seul registre comme s'il remplaçait toutes les exigences d'externalisation. Les règles voisines sont présentées sous externalisation et cloud dans les banques allemandes.

Une remise peut échouer aux contrôles techniques ou de qualité des données. Vérifiez les identifiants, les renvois entre modèles et les valeurs autorisées des champs avant le dépôt. Les ressources de déclaration de l'ABE contiennent les règles de validation et des exemples de retours. Utilisez les constats renvoyés pour distinguer un fichier rejeté d'un fichier accepté avec des problèmes à corriger.

Une fonction porte le fichier et l'échéance, en général le risque TIC ou le responsable de l'externalisation, tandis que le contenu vient des achats pour les contrats, de l'informatique pour les services et du juridique pour le droit applicable et les préavis. L'organe de direction porte la responsabilité du risque TIC selon DORA, donc aussi celle du registre. Un registre assemblé une fois par an à partir de quatre sources qui ne concordent pas est la version qui produit un journal d'erreurs.