Le Digital Operational Resilience Act, règlement (UE) 2022/2554, s'applique depuis le 17 janvier 2025. Contrairement à NIS2, c'est un règlement et non une directive : il s'applique donc directement dans chaque État membre sans attendre de transposition nationale, et il est supervisé par les régulateurs financiers plutôt que par les agences de cybersécurité.
Son postulat est simple : une banque, un assureur ou une plateforme de négociation peuvent être mis à terre par une défaillance TIC aussi sûrement que par une perte de crédit, donc la résilience opérationnelle face aux risques TIC relève de la supervision prudentielle. La conséquence pour l'industrie technologique est moins évidente et plus lourde de portée : DORA régit la relation entre les entités financières et les fournisseurs dont elles dépendent, ce qui veut dire que les obligations descendent dans les contrats avec les fournisseurs cloud, les éditeurs de logiciels et les prestataires de services managés qui ne sont pas eux-mêmes régulés.
Qui est concerné
Vingt types d'entités financières sont listés à l'article 2 : établissements de crédit, établissements de paiement et de monnaie électronique, entreprises d'investissement, prestataires de services sur crypto-actifs, dépositaires centraux de titres, plateformes de négociation, entreprises d'assurance et de réassurance, intermédiaires d'assurance, institutions de retraite, agences de notation de crédit, prestataires de financement participatif, et d'autres. Un principe de proportionnalité adapte les obligations à la taille et au profil de risque de l'entité, et certaines microentreprises bénéficient d'un régime simplifié.
Les prestataires tiers de services TIC sont concernés de deux façons. Tous le sont indirectement, par les exigences contractuelles que leurs clients financiers doivent leur imposer. Un petit nombre, désignés comme critiques par les autorités européennes de surveillance, le sont directement par un cadre de surveillance avec un superviseur principal, des pouvoirs d'inspection et des astreintes. Les premières désignations ont eu lieu fin 2025 et couvrent les plus grands fournisseurs de cloud et d'infrastructure.
Les cinq piliers
Gestion des risques TIC (chapitre II). L'organe de direction est responsable des risques TIC et doit approuver et revoir périodiquement un cadre couvrant l'identification, la protection, la détection, la réponse, la reprise, l'apprentissage et la communication. Le cadre doit être documenté, testé et audité en interne. Les objectifs de reprise, les politiques de sauvegarde et un plan de communication de crise sont des exigences explicites, pas implicites.
Gestion et notification des incidents liés aux TIC (chapitre III). Les entités doivent classer les incidents selon des seuils fixés par des normes techniques de réglementation, et notifier les incidents majeurs à leur autorité compétente : une notification initiale dans les quatre heures suivant la classification et au plus tard 24 heures après la détection, un rapport intermédiaire dans les 72 heures, et un rapport final dans le mois. Les cybermenaces importantes peuvent être notifiées volontairement.
Tests de résilience opérationnelle numérique (chapitre IV). Chaque entité mène un programme de tests : évaluations de vulnérabilités, tests fondés sur des scénarios, revues de code source et autres, selon les risques, au moins une fois par an pour les systèmes critiques. Les entités identifiées comme significatives doivent aussi réaliser des tests de pénétration fondés sur la menace (TLPT) tous les trois ans, dans l'esprit du cadre TIBER-EU, sur les systèmes de production réels, avec partage des résultats à l'autorité.
Risque lié aux prestataires tiers de services TIC (chapitre V). C'est le pilier qui atteint les fournisseurs. Les entités doivent tenir un registre d'informations listant chaque accord contractuel de services TIC, en distinguant ceux qui soutiennent des fonctions critiques ou importantes. Avant de contracter, elles doivent évaluer le risque de concentration et l'adéquation du fournisseur. Les contrats doivent contenir les clauses de l'article 30 : description et localisation des services, protection des données, engagements de disponibilité et d'intégrité, assistance en cas d'incident, droits d'audit et d'accès pour l'entité et l'autorité, stratégies de sortie avec périodes de transition et, pour les fonctions critiques, niveaux de service, participation aux tests et dispositions de contingence.
Partage d'informations (chapitre VI). Les entités peuvent échanger des renseignements sur les cybermenaces au sein de communautés de confiance, sous réserve de garanties. Ce pilier est permissif et non obligatoire.
Ce qu'un auditeur demande
Une mission DORA, qu'il s'agisse d'un audit interne, d'une revue de préparation ou d'un exercice d'assurance fournisseur, tend à suivre les piliers dans l'ordre et à demander l'élément que chacun implique :
- Le cadre de gestion des risques TIC et les comptes rendus du conseil qui l'approuvent, plus la preuve de la revue périodique et de la formation propre de l'organe de direction aux risques TIC, que l'article 5 exige.
- L'inventaire des actifs avec la correspondance des actifs TIC aux fonctions métier et l'identification des fonctions critiques ou importantes.
- La procédure de classification des incidents, le journal des incidents, et des copies des rapports déposés auprès de l'autorité, avec des horodatages qui montrent que les délais ont été tenus.
- Le programme de tests, les résultats des derniers tests annuels sur les systèmes critiques, le suivi des corrections et, pour les entités significatives, le périmètre et l'attestation du TLPT.
- Le registre d'informations au format prescrit par les AES, et un échantillon de contrats vérifiés clause par clause face à l'article 30.
- Les stratégies de sortie pour les fonctions critiques, et la preuve qu'elles ont été testées ou au moins parcourues.
- L'analyse du risque de concentration : combien de fonctions critiques dépendent d'un seul prestataire, et quel est le plan si ce prestataire défaille.
Pour les fournisseurs TIC
Si vous vendez des logiciels ou des services à une banque ou un assureur de l'UE, vous avez probablement déjà reçu un contrat révisé, un questionnaire, ou les deux. Ce que fait votre client, c'est remplir son registre d'informations et satisfaire à l'article 30. Ce qui fait de vous un fournisseur facile à garder :
- Pouvoir indiquer, par écrit, où les données sont traitées et stockées, et notifier les changements.
- Accepter les droits d'audit et d'accès, y compris pour le régulateur de votre client, et avoir un moyen de les honorer sans perturber vos autres clients, généralement en proposant un rapport d'assurance indépendant en première réponse.
- Soutenir la notification des incidents avec le niveau de détail et la rapidité que les propres délais de votre client exigent.
- Avoir un plan de sortie que vous pouvez décrire : formats de restitution des données, assistance à la transition, confirmation de suppression.
- Participer aux tests de résilience de votre client lorsque vous soutenez une fonction critique.
Un certificat ISO 27001 ou un rapport SOC 2 n'est pas une conformité DORA, mais un fournisseur qui en détient un a déjà répondu à la plupart des questions du registre. L'écart tient généralement aux clauses contractuelles et aux engagements de sortie et de tests, qu'aucun certificat ne couvre.
L'erreur à éviter
La défaillance la plus fréquente de la première année d'application a été de traiter DORA comme un projet de sécurité piloté par le RSSI. C'est un règlement de gouvernance. L'organe de direction est nommément responsable, le registre est une déclaration réglementaire, les délais d'incident sont des délais légaux, et les clauses contractuelles sont une exigence légale. Les entités qui étaient prêtes avaient réuni le juridique, les achats, les risques et la technologie dans la même pièce dès le départ.