DORA : Digital Operational Resilience Act
Sécurité
DORA : Digital Operational Resilience Act. « Le règlement européen qui oblige le secteur financier à prouver qu'il tient debout quand son informatique tombe », par analogie avec l'exercice d'évacuation, qui ne vérifie pas que l'immeuble ne brûlera jamais, mais que chacun sait par où sortir, ce que la finance, rompue aux sorties de crise, croyait savoir depuis longtemps.
Texte et champ : Règlement (UE) 2022/2554, applicable depuis le 17 janvier 2025. Il vise les entités financières (banques, assurances, entreprises d'investissement, établissements de paiement, prestataires de services sur crypto-actifs, entre autres) et, indirectement, leurs prestataires de services informatiques. Pour ces entités, il prime sur les règles générales de NIS2.
Cinq piliers : Gestion des risques liés aux technologies de l'information et de la communication (TIC), notification des incidents majeurs liés aux TIC, tests de résilience opérationnelle numérique, maîtrise du risque lié aux prestataires tiers de TIC, partage d'informations sur les menaces.
Prestataires tiers : Registre de tous les contrats de services TIC, clauses contractuelles minimales (accès, audit, sortie), stratégie de sortie pour les fonctions critiques. Les prestataires jugés critiques pour le secteur, comme les grands fournisseurs de cloud, passent sous la surveillance directe des autorités européennes de supervision.
Tests : Tests réguliers des systèmes et, pour les entités les plus importantes, tests de pénétration fondés sur la menace menés sur les systèmes de production. Un plan de continuité qui n'a jamais été joué n'est qu'un document de plus, dont la principale qualité est de n'avoir encore déçu personne.
Ce qui arrive si on s'en passe
Sans le cadre que DORA impose, une entité financière découvre sa dépendance à un prestataire informatique le jour où celui-ci tombe, ce qui est une manière coûteuse de dresser un inventaire : aucun registre ne dit quelles fonctions critiques en dépendent, aucune clause ne garantit l'accès aux données ni la sortie, et aucun plan de reprise n'a été testé en conditions réelles. Un incident majeur non qualifié à temps échappe à la notification attendue par l'autorité. La panne d'un seul fournisseur partagé par plusieurs établissements se propage alors d'un acteur à l'autre, précisément le risque systémique que le règlement cherche à contenir.
Explication de la marmotte
Les banques, les assurances et les autres entreprises de la finance dépendent entièrement de leurs ordinateurs et de ceux de leurs fournisseurs. Une loi européenne leur demande de se préparer aux pannes et aux attaques : savoir quels services informatiques sont vitaux, prévenir les autorités rapidement quand un incident grave arrive, s'entraîner régulièrement à y faire face, et garder le contrôle sur les entreprises extérieures qui font tourner une partie de leur informatique. Le but est qu'une panne chez un grand fournisseur ne bloque pas les paiements de tout un pays.
Où ce terme est utilisé
- DORA et résilience opérationnelle numérique financière (12 occurrences)
- Délais de notification d’incident NIS2 RGPD DORA (7 occurrences)
- Partager le renseignement sur la menace avec ISAC, MISP et STIX (5 occurrences)
- Sécurité des systèmes bancaires et financiers (4 occurrences)
- AI Act : articuler les obligations de sécurité avec NIS 2, le CRA et le RGPD (3 occurrences)
- Normes (3 occurrences)
- AI Act : obligations du déployeur d'une IA à haut risque (article 26) (2 occurrences)
- Cloud IaaS, PaaS, SaaS et modèles de déploiement, qui sécurise quoi (2 occurrences)
- Continuité, sauvegardes, PRA/PCA et haute disponibilité (2 occurrences)
- Test d'intrusion : commander, cadrer et exploiter un pentest (2 occurrences)