Analyse des premiers RTS du règlement DORA

Les autorités de supervision européennes (ESAs) ont publié début juillet le premier lot de projets de normes techniques venant en complément du Règlement sur la résilience opérationnelle numérique du secteur financier (DORA).

L’exercice de constituer des textes techniques précis capables de couvrir des institutions aussi différentes que des banques, des assureurs, des établissements de paiement ou des dépositaires centraux n’était pas évident. Force est de constater que, malgré leur caractère généraliste, les premiers règlements techniques (RTS) de DORA couvrent leur périmètre de façon plutôt exhaustive et pertinente. Ce n’est que lorsque les textes descendent dans un niveau de détail plus précis que l’on commence à voir apparaître des principes non uniformément applicables à certains types d’établissements, structures juridiques, voire réglementations nationales.

Le RTS sur la gestion des risques

Le RTS sur la gestion des risques est probablement le plus complexe qui ait été confié aux ESAs, principalement à cause du large périmètre couvert, soit la majeure partie du chapitre II de DORA. Il regroupe également deux mandats, puisque les ESAs ont décidé de le fusionner avec le RTS sur le cadre simplifié de gestion des risques.

En termes de structure, le RTS ressemble beaucoup à son texte de premier niveau. C’est-à-dire qu’il s’efforce de présenter chaque thématique séparément afin de fournir un contenu rationnel et compréhensible pour le lecteur, mais bute sur le fait que les notions de base en matière de maîtrise des risques TIC sont transverses et reviennent sous plusieurs thématiques. Il remplit néanmoins sa fonction, en couvrant des sujets aussi divers que la gouvernance, la gestion des accès, la cryptographie ou la gestion de projets.

En termes de périmètre, on remarquera que les ESAs se sont efforcées d’étoffer des sujets peu détaillés dans le règlement initial, comme la cryptographie ou la conduite du changement, sans trop sortir du mandat fourni par les articles 15 et 16.

La seule exception notable concerne le rapport sur le réexamen du cadre de gestion des risques de l’article 6(5) de DORA. En effet, si le mandat des ESAs concerne le contenu et le format du rapport que les entités doivent présenter aux autorités à la demande de ces dernières, ce mandat ne couvre en aucune façon l’obligation de produire un rapport hors de la demande des autorités. Le fait que le cadre de gestion des risques soit revu « au moins annuellement » ne signifie pas que cette revue doive être réalisée ponctuellement sur l’ensemble du périmètre, bien au contraire. Les établissements les plus sérieux l’« améliorent en permanence », comme indiqué dans l’article 6(5).

De même, en matière de gestion des risques, le terme « documenté » signifie rarement « dans un document », mais bien plus souvent dans un logiciel dédié comprenant les règles, procédures, cartographies, évaluations, retours d’expériences et plans d’actions. Les termes « date de début et fin de revue », « changements depuis la revue précédente » exigés par les ESAs vont à l’encontre de toute notion d’amélioration continue, ainsi que de la réalité de gestion d’un système complexe, où la charge de travail est répartie au mieux et non concentrée sur une période donnée.

Notre principale crainte dans ce domaine est que le RTS influence négativement des pratiques efficientes déjà en place, que les établissements pourraient dégrader en s’efforçant de coller à la lettre du texte.

En termes d’exigences spécifiques pour les acteurs centraux de marchés, le RTS est étonnamment léger, se limitant à des extensions de tests et de stress tests sur la partie gestion de projets. Si l’on prend en compte le fait que DORA ait accru les exigences des acteurs centraux sur les thématiques de continuité, le RTS était l’occasion d’accentuer la partie organisationnelle et prévention pour ces acteurs clés. Une occasion non saisie.

Néanmoins, au global, le RTS sur la gestion du risque remplit son contrat et fournit un complément utile et étoffé au chapitre II de DORA.

L’ITS sur le registre des prestataires tiers

L’ITS sur le registre des prestataires tiers est assez déroutant, dans la mesure où il descend dans le niveau de détail d’un modèle de données, sans en présenter les caractéristiques.

Les concepts abordés par les ESAs sont clairs (identification de la supply chain, lien entre les services, les fonctions et les contrats, intégration des notions budgétaires, consolidation). En revanche, la constitution d’identifiants plus ou moins uniques par adjonction de champs multiples, ainsi que l’absence de hiérarchie entre les tables, rendent la structure du registre et son opérabilité complexes et peu efficaces.

La principale surprise de l’ITS vient du fait que les ESAs ont écarté leur traditionnel modèle XML pour un modèle de tables plates, exigeant une répétition de certains champs autant de fois que nécessaire pour couvrir tous les attributs. Par exemple, si un contrat de service couvre 10 fonctions dans 10 entités, il sera répété 100 fois dans la table de destination. Si ce choix permet aux petits établissements de gérer leur modèle facilement sous Excel, la gestion du registre dans les grands groups bancaires ou assurantiels, mêlant contrats groupe, intragroupe et spécifiques sur un périmètre complexe, risque de devenir un véritable cauchemar.

Encore plus surprenant est le fait que l’ITS impose ce format sans attendre les spécifications de reporting que devront émettre les autorités de tutelle. Pour peu que ces derniers soient incompatibles avec le modèle proposé, les établissements vont se trouver devant des exigences de conversion complexes qui n’était pas nécessaire au départ.

La principale conclusion que l’on peut tirer de l’analyse de l’ITS est que, sauf modifications substantielles avant la publication du texte final, les établissements devront retravailler le modèle de données proposé, afin de combiner au mieux leurs spécificités internes avec les exigences du document.

Les autres RTS, classification des incidents et règles sur les prestataires de fonctions clés

Les deux derniers RTS de ce premier lot sont assez courts, ciblés sur leurs besoins et ne soulèvent pas de problèmes majeurs. On y relèvera tout au plus quelques détails incompatibles avec leur objectif ou leur mandat.

Dans certains paragraphes du RTS sur la classification des incidents, les ESAs utilisent pour seuils d’alerte des montants fixes, appropriés pour certaines activités financières mais inopérables pour d’autres. La nécessité de produire des textes applicables à l’ensemble du monde financier impose de forcer le recours à des critères de seuils relatifs plutôt qu’absolus.

Le RTS sur les prestataires de fonctions clés, quant à lui, soulève plutôt des détails d’applicabilité légale, comme la possibilité de s’imposer à une entité tête de groupe non régulée, ou la capacité à fixer des prix de services.

Conclusion

La principale question qui reste en suspens est : dans quelle mesure les ESAs sont-elles prêtes à intégrer les réponses à ces consultations et souhaitent-elles retravailler leurs projets de textes ?

Les consultations publiques des ESAs sont une obligation réglementaire, au même titre que l’analyse d’impact ou l’analyse des réponses. Néanmoins, un long historique du processus a montré que certaines ESAs sont plus enclines que d’autres à prendre en compte les opinions extérieures, ou que la charge de travail réglementaire à un moment donné influe significativement sur la volonté de réécriture.

Dans le cas présent, l’ensemble du monde financier est impacté, ce qui signifie un nombre de réponses très élevé, potentiellement hétérogènes, dans un délai de publication très court pour des textes d’une telle portée. Dans ce contexte, se focaliser sur les points relevés comme présentant une incompatibilité avec les mandats donnés, une impossibilité de mise en place ou une charge excessive et injustifiée pour les établissements, devrait permettre aux ESAs de prioriser leurs travaux et de répondre aux inquiétudes de la place sans dépasser leurs délais de publication.

En effet, il ne faut pas oublier qu’une fois les règlements délégués publiés, les établissements auront moins d’un an pour les mettre en place, ce qui dans le monde informatique correspond au lendemain. Au-delà des détails et des arguments, l’exercice consiste donc à trouver le juste équilibre entre la pertinence du contenu et le respect du calendrier.