Registre d'information DORA : ce que votre plateforme Azure doit pouvoir prouver
Dans cet article
DORA s’applique aux entités financières depuis le 17 janvier 2025. Au Luxembourg, la CSSF a rendu le sujet très concret en avril 2025 : la circulaire CSSF 25/882 encadre désormais le recours aux services TIC de tiers pour les entités DORA, et la circulaire 25/883 a amendé la 22/806 pour en retirer les chapitres d’externalisation TIC, désormais couverts par DORA. La 22/806 continue de s’appliquer à l’externalisation de processus métier et aux entités hors périmètre DORA.
Au milieu de tout cela, une obligation attire moins l’attention qu’elle ne le mérite : le registre d’information. Chaque entité financière doit maintenir et mettre à jour un registre de ses accords contractuels relatifs aux services TIC fournis par des prestataires tiers, avec un niveau de détail nettement supérieur pour ceux qui soutiennent des fonctions critiques ou importantes. Ce registre est soumis annuellement à la CSSF, selon le calendrier communiqué par celle-ci.
Sur le papier, un tableur. En pratique, nous n’avons encore jamais vu une équipe le remplir honnêtement sans découvrir des trous dans sa propre plateforme. Le registre est un test d’architecture déguisé en formulaire.
Ce que le registre demande vraiment
Pour chaque service TIC soutenant une fonction critique ou importante, le registre exige, entre autres, l’identification du prestataire, le type de service, la fonction métier soutenue, la localisation du stockage et du traitement des données, la chaîne de sous-traitance, l’évaluation de la substituabilité et la stratégie de sortie.
Prenez ces champs un par un et posez la question : d’où vient la réponse dans votre environnement Azure ?
Quelle fonction s’appuie sur quoi
Le registre part des fonctions métier. Il faut donc pouvoir tracer chaque fonction critique jusqu’aux subscriptions, resource groups et services Azure qui la portent. Si vos tags de criticité et de propriétaire sont décoratifs, remplis un jour de migration et jamais maintenus, cette traçabilité n’existe pas. Un inventaire Azure Resource Graph filtré par tags devrait produire la colonne « services concernés » en quelques minutes. Quand il faut trois semaines et quatre ateliers, le problème n’est pas le registre.
Où sont les données, vraiment
La localisation du stockage et du traitement paraît simple : « West Europe ». Puis viennent les questions qui fâchent. Où partent les logs ? Dans quelle région tourne votre Log Analytics workspace ? Vos sauvegardes géo-redondantes répliquent vers quelle paire de régions ? Votre WAF ou votre CDN traite-t-il des requêtes en dehors de l’EEE ? Une Azure Policy « allowed locations » appliquée en mode deny donne une réponse défendable pour les ressources. Pour les flux annexes, il faut les avoir cartographiés.
La chaîne de sous-traitance
Microsoft publie sa liste de sous-traitants et ses engagements contractuels. Ce travail de documentation peut être fait une fois et réutilisé pour chaque ligne du registre. Le point délicat se situe au-dessus : les SaaS que vous consommez et qui tournent eux-mêmes sur un cloud. Pour une fonction critique, le registre attend la chaîne au-delà du prestataire direct, dès lors que les sous-traitants sont pertinents pour le service.
La stratégie de sortie
Le champ le plus inconfortable. « Voir contrat » risque de ne pas suffire face à une question de la CSSF. Une stratégie de sortie crédible côté plateforme se résume à trois éléments vérifiables : une couverture Infrastructure as Code suffisante pour redéployer ailleurs, des chemins d’export de données documentés et testés, et une estimation réaliste du délai de reconstruction. Personne ne quitte un hyperscaler en un week-end, et la CSSF le sait. Elle veut voir que vous avez fait l’exercice.
Le calendrier change la façon de travailler
La 25/882 impose de notifier la CSSF avant la mise en place d’un accord TIC soutenant une fonction critique ou importante : le plus tôt possible, et au plus tard trois mois avant la date prévue (un mois quand le prestataire est un PFS de support luxembourgeois).
Trois mois, cela veut dire que l’architecture doit être arrêtée bien avant le go-live. Le modèle d’accès, la localisation, les flux réseau, le plan de réversibilité : tout cela doit exister au moment de la notification, pas être régularisé après coup. Pour les équipes habituées à décider l’architecture pendant le sprint de mise en production, c’est un changement de discipline plus qu’un changement de formulaire.
La circulaire maintient aussi des exigences propres au cloud, dont la désignation d’un cloud officer. Cette personne devient souvent l’un des premiers consommateurs internes des preuves décrites plus haut. Autant les produire dans un format qu’elle peut réutiliser.
Par où commencer côté Azure
L’exercice complet dépasse un article de blog, mais quatre chantiers couvrent l’essentiel du chemin.
- Un inventaire Resource Graph piloté par les tags, avec une taxonomie de criticité alignée sur votre liste de fonctions critiques. C’est la colonne vertébrale du registre.
- Des Azure Policies de localisation en deny, avec export des évaluations de conformité comme preuve datée.
- Les diagnostic settings vérifiés sur tout ce qui porte une fonction critique. Affirmer dans le registre qu’une fonction est supervisée se prouve avec des logs qui existent.
- Un runbook de sortie par workload critique : quoi redéployer, quoi exporter, en combien de temps, testé au moins une fois.
Fait sérieusement, le registre cesse d’être une corvée annuelle. Il devient la carte de vos dépendances réelles, celle que l’équipe sécurité, la gestion des risques et l’architecte consultent pour la même raison : savoir ce qui casse quoi.
Une précision d’honnêteté : nous intervenons sur l’architecture technique et les preuves, l’interprétation juridique du règlement et des circulaires reste l’affaire de vos équipes conformité et juridiques.
À lire ensuite : Audit de landing zone Azure : ce que nous trouvons détaille les écarts récurrents entre l’architecture déclarée et l’architecture réelle.
Besoin de preuves Azure exploitables pour DORA et la CSSF ?
Nous aidons les équipes Azure à transformer leur architecture réelle en preuves utilisables : inventaire, localisation, diagnostic settings, dépendances, exposition API et trajectoire de remédiation.
Plus sur le blog
Pourquoi chaque entreprise Azure a besoin d'une méthodologie d'analyse WAF
Ce que révèle un audit Azure Landing Zone
