Définition
DORA (Digital Operational Resilience Act) est un règlement européen entré en application le 17 janvier 2025.
Il impose à tous les acteurs financiers de l'UE — banques, fintechs, assurances, CASP, gestionnaires d'actifs, plateformes de crowdfunding — un cadre strict de résilience opérationnelle IT : gestion des risques, gestion des incidents, tests de pénétration, encadrement des fournisseurs IT critiques.
Pourquoi DORA existe
Avant DORA, la résilience IT était fragmentée : chaque secteur avait ses règles, et les fournisseurs IT critiques (cloud, SaaS, processeurs de paiement) échappaient à toute supervision — alors qu'une panne chez eux pouvait paralyser le système financier. DORA harmonise tout cela dans un cadre paneuropéen unique.
Les 5 piliers
- Gestion des risques IT : gouvernance, cartographie des actifs et processus critiques, sauvegarde, restauration, plan de continuité.
- Gestion des incidents : classification et reporting obligatoire à la NCA dans des délais courts (notification initiale sous 4h, rapport intermédiaire sous 72h).
- Tests de résilience : scans, audits, et pour les acteurs significatifs un TLPT (Threat-Led Penetration Testing) tous les 3 ans.
- Risque tiers IT : registre obligatoire des fournisseurs critiques, contrats encadrés, due diligence, droit d'audit.
- Partage d'informations : participation au partage de Cyber Threat Intelligence entre acteurs.
La nouveauté majeure : superviser les fournisseurs IT critiques
C'est l'innovation la plus disruptive. Les fournisseurs jugés critiques pour le système financier — AWS, Azure, Google Cloud, OVH, mais aussi des éditeurs SaaS spécialisés — sont désignés par les ESAs (EBA, ESMA, EIOPA) et placés sous supervision directe européenne : audits, sanctions, voire obligation de modifier leurs pratiques. C'est la première fois qu'un cloud provider américain est directement supervisé par un régulateur européen.
Ce que DORA ne fait pas
- Ne crée pas de nouveau statut : il s'applique par-dessus les statuts existants (banque, EP, EME, CASP, assureur).
- Ne couvre pas les données personnelles : c'est le RGPD.
- Ne remplace pas NIS 2 (cybersécurité générale UE) mais s'y articule.
- Ne dispense pas des règles sectorielles (DSP2, MiCA, Solvency II) : il s'y ajoute.
Calendrier
- Décembre 2022 — adoption du règlement.
- Janvier 2023 → janvier 2025 — 24 mois de mise en conformité.
- 17 janvier 2025 — application effective, sans dérogation.
- 2025-2026 — premiers contrôles renforcés et premières désignations de fournisseurs IT critiques.
Dans l'écosystème PSD2
DORA n'est pas spécifique à la DSP2, mais toute fintech opérant un service de paiement est concernée. C'est désormais une brique de conformité incontournable, au même titre que la SCA ou la lutte anti-blanchiment.
Exemples concrets
- Reporting d'incident : une API qui tombe 2 heures en pleine production déclenche 4h pour notifier l'ACPR et 72h pour un rapport intermédiaire — à câbler dans le runbook avant l'incident.
- TLPT : un PSP comme Worldline, Adyen ou Stripe Europe organise un Threat-Led Penetration Testing tous les 3 ans, conduit par un prestataire agréé (100 à 500 K€ par exercice).
- Encadrement cloud : héberger son infra critique chez AWS impose un contrat DORA-compliant (réversibilité, droit d'audit, plan de sortie), d'où les contrats fintech UE proposés par AWS, Azure et GCP depuis 2024.
- Registre des fournisseurs IT : tenu à jour avec criticité et plan de sortie, souvent via OneTrust, MetricStream ou des tableurs internes.
- Plan de continuité : pouvoir basculer sur un site ou un cloud secondaire en cas d'incident majeur — une exigence concrète, à tester régulièrement.
- Veille : suivre les RTS et guidelines des ESAs et le calendrier de désignation des fournisseurs IT critiques.