DORA en pratique : risque informatique, incidents, tests et prestataires
Le règlement sur la résilience opérationnelle numérique (règlement (UE) 2022/2554, « DORA ») s'applique aux entités financières de l'UE depuis le 17 janvier 2025. Contrairement à NIS2, c'est un règlement : le même texte s'applique partout, sans transposition. Le détail figure dans une série de normes techniques de réglementation et d'exécution (RTS et ITS). Près de deux ans après, la plupart des entités ont un dispositif sur le papier ; les superviseurs vérifient désormais qu'il fonctionne. Ce guide parcourt les cinq piliers et se termine par une liste de contrôle opérationnelle.
Qui est concerné
DORA vise une vingtaine de catégories d'entités financières : établissements de crédit, de paiement et de monnaie électronique, entreprises d'investissement, prestataires de services sur crypto-actifs, infrastructures de marché, sociétés de gestion, assureurs et réassureurs, intermédiaires d'assurance, institutions de retraite professionnelle, agences de notation, plateformes de financement participatif, entre autres. En France, la supervision relève de l'ACPR et de l'AMF, sous l'égide des autorités européennes de surveillance (ABE, AEAPP, AEMF).
Les prestataires informatiques sont touchés de deux façons : par les contrats que leurs clients financiers doivent signer (article 30) et, pour les plus importants, par une supervision européenne directe en tant que prestataires critiques.
DORA est une lex specialis par rapport à NIS2 : pour les entités financières, il remplace les mesures de gestion des risques et la notification d'incidents de NIS2 (voir notre guide NIS2). La proportionnalité est prévue : les petites structures non interconnectées appliquent un cadre simplifié (article 16), et les microentreprises sont exemptées de plusieurs exigences, dont les tests fondés sur la menace.
Les cinq piliers
| Pilier | Articles | Obligation centrale | Texte de niveau 2 |
|---|---|---|---|
| Gestion du risque informatique | 5-16 | Cadre documenté porté par l'organe de direction | RTS 2024/1774 |
| Gestion et notification des incidents | 17-23 | Classer les incidents, déclarer les incidents majeurs en 4 h / 72 h / 1 mois | RTS 2024/1772 (classification), RTS 2025/301 et ITS 2025/302 (notification) |
| Tests de résilience | 24-27 | Programme annuel ; TLPT tous les 3 ans pour les entités désignées | RTS 2025/1190 (TLPT) |
| Risque lié aux prestataires TIC | 28-44 | Registre d'informations, clauses contractuelles obligatoires, supervision des prestataires critiques | ITS 2024/2956 (registre), RTS 2025/532 (sous-traitance) |
| Partage d'informations | 45 | Échange volontaire de renseignement sur la menace | aucun |
Pilier 1 : le cadre de gestion du risque informatique
L'article 5 place l'organe de direction aux commandes : il définit, approuve et supervise le cadre, fixe la tolérance au risque, approuve les politiques de continuité et de recours aux prestataires, et entretient ses propres connaissances par la formation. Le cadre est revu au moins une fois par an et après tout incident majeur, et audité en interne.
Il suit un cycle familier :
| Fonction | Article | Ce que vérifie le superviseur |
|---|---|---|
| Identifier | 8 | Inventaire des fonctions métier, actifs TIC, dépendances, systèmes anciens |
| Protéger | 9 | Correctifs, segmentation, chiffrement, gestion des accès et des changements |
| Détecter | 10 | Détection multicouche avec seuils d'alerte définis |
| Répondre et rétablir | 11 | Politique de continuité, plans testés chaque année, RTO/RPO par fonction |
| Sauvegarder | 12 | Sauvegardes séparées physiquement et logiquement, restaurations testées |
| Apprendre | 13 | Retours d'expérience, sensibilisation |
| Communiquer | 14 | Plans de communication de crise |
L'écart le plus fréquent n'est pas technique : c'est l'absence de lien fiable entre les fonctions critiques ou importantes (vue métier) et les actifs, prestataires et objectifs de reprise qui les portent. Construisez cette cartographie en premier : tout le reste de DORA s'appuie dessus.
Pilier 2 : classer et déclarer les incidents
Tout incident lié aux TIC est enregistré et classé. Il est majeur s'il touche des services supportant des fonctions critiques et soit implique un accès malveillant non autorisé susceptible d'entraîner une perte de données, soit franchit au moins deux autres seuils de matérialité. Résumé du RTS 2024/1772 (vérifier le texte avant de s'appuyer sur un chiffre) :
| Critère | Seuil de matérialité |
|---|---|
| Clients et opérations | Plus de 10 % des clients ou plus de 100 000 clients, ou plus de 10 % des opérations |
| Durée et indisponibilité | Incident de plus de 24 h, ou indisponibilité d'un service critique de plus de 2 h |
| Étendue géographique | Impact dans au moins 2 États membres |
| Pertes de données | Atteinte significative à la disponibilité, l'authenticité, l'intégrité ou la confidentialité |
| Impact économique | Coûts directs et indirects supérieurs à 100 000 EUR |
| Réputation | Couverture médiatique, réclamations, impact réglementaire, perte de clients |
Délais pour un incident majeur :
| Rapport | Délai |
|---|---|
| Notification initiale | 4 h après la classification comme majeur, et au plus tard 24 h après la prise de connaissance |
| Rapport intermédiaire | 72 h après la notification initiale |
| Rapport final | 1 mois après le rapport intermédiaire |
Exemple : prise de connaissance mardi 9 h, classement en majeur à 13 h. La notification initiale est due au plus tôt de 13 h + 4 h et 9 h + 24 h, soit mardi 17 h ; le rapport intermédiaire au plus tard vendredi 17 h. Retarder la classification ne suspend rien, puisque le plafond de 24 h après la prise de connaissance s'applique. Une panne de paiement touchant des données personnelles déclenche en plus le délai RGPD de 72 h vers la CNIL.
- ICT-related incident logged
- → Affects services supporting critical or important functions, or licensed / authorised services?
- No: Not major: record, classify, learn (Art. 17)
- Yes: Malicious unauthorised access to network and information systems that may cause data losses?
- Yes: MAJOR: initial notification ≤ 4 h after classification, ≤ 24 h after awareness
- No: Two or more other criteria above their materiality thresholds?
- Yes: MAJOR: initial notification ≤ 4 h after classification, ≤ 24 h after awareness (see above)
- No: Not major: record, classify, learn (Art. 17) (see above)
- → Affects services supporting critical or important functions, or licensed / authorised services?
Extrait de la fiche « DORA: Digital Operational Resilience (part 2) » · Demander la fiche complète
Pilier 3 : tests de résilience et TLPT
Toutes les entités mènent un programme de tests annuel, proportionné au risque : scans de vulnérabilités, revues réseau et de configuration, revues de code, tests de scénarios et de performance, tests d'intrusion.
Les entités désignées par leur autorité doivent en plus conduire tous les trois ans au moins un test de pénétration fondé sur la menace (TLPT) : un exercice red team piloté par le renseignement, sur les systèmes de production, selon la méthode TIBER-EU (TIBER-FR en France).
| Phase | Contenu |
|---|---|
| Préparation | Périmètre sur les fonctions critiques ou importantes, équipe de contrôle restreinte et secrète, choix des testeurs selon l'article 27 |
| Renseignement | Rapport de menace ciblé et scénarios réalistes |
| Red team | Tests actifs en production (durée minimale fixée par le RTS), équipe de défense non informée |
| Clôture | Rejeu et purple teaming, plan de remédiation, attestation de l'autorité |
Les prestataires qui supportent des fonctions critiques doivent y participer. L'échec classique est la fuite : si le SOC sait qu'un test est en cours, le résultat de détection n'a plus de valeur.
Qui fait quoi dans un TLPT (rôles TIBER-EU selon les art. 26-27 de DORA)
tadataQui fait quoi dans un TLPT (rôles TIBER-EU selon les art. 26-27 de DORA)
| Task | Control team | Authority | TI provider | Red team | Blue team | Mgmt body |
|---|---|---|---|---|---|---|
| Scope: critical or important functions, flags (objectives) to capture; authority validates | R | C | A | |||
| Select testers and check Art. 27 criteria (skills, insurance, references) | A/R | I | I | |||
| Targeted threat intelligence report and threat scenarios | A | C | R | C | ||
| Red team test plan: scenarios, rules of engagement | A | C | C | R | ||
| Active red teaming on live production (at least 12 weeks, verify in the TLPT RTS) | A | I | R | |||
| Leg-up (control team hands testers a foothold) or stop for operational risk | A/R | C | C | I | ||
| Red team report, blue team report, replay and purple teaming | A | I | R | R | ||
| Test summary and remediation plan sent to the authority | R | I | C | C | A | |
| Attestation that the TLPT was performed | I | A/R | I |
R = responsible, A = accountable, C = consulted, I = informed
Extrait de la fiche « DORA: Digital Operational Resilience » · Demander la fiche complète
Pilier 4 : risque lié aux prestataires TIC
C'est là que l'essentiel de l'effort s'est porté depuis 2025.
Registre d'informations (article 28(3)). Tous les accords contractuels avec des prestataires TIC, les fonctions qu'ils soutiennent, leur chaîne de sous-traitance et leur identifiant d'entité juridique (LEI), au format de l'ITS 2024/2956, transmis chaque année à l'autorité. La qualité des données est le problème récurrent : LEI manquants, fonctions non rattachées, sous-traitants inconnus.
Clauses contractuelles obligatoires (article 30). Pour tous les services TIC :
- description complète des services et des lieux de traitement des données ;
- disponibilité, intégrité, confidentialité, restitution des données en sortie ou en cas d'insolvabilité ;
- niveaux de service, assistance en cas d'incident, coopération avec les autorités ;
- droits de résiliation et préavis ; participation aux programmes de sensibilisation.
Pour les services qui supportent des fonctions critiques ou importantes, s'ajoutent : SLA complets avec suivi, information sur les changements significatifs, plans de continuité testés, participation au TLPT, droits d'audit et d'inspection sans restriction, stratégies de sortie avec périodes de transition.
Concentration et sortie (articles 28-29). Évaluez la substituabilité et la dépendance à un seul prestataire ; rédigez un plan de sortie par service critique et testez-le. Sortir un système cœur d'un fournisseur cloud prend des mois, pas des jours.
Prestataires tiers critiques (CTPP). Les autorités européennes ont publié le 18 novembre 2025 une première liste de 19 prestataires critiques, dont les principaux hyperscalers. Chacun relève d'un superviseur principal qui peut inspecter, émettre des recommandations et infliger des astreintes jusqu'à 1 % du chiffre d'affaires mondial quotidien moyen pendant six mois au plus. Cette supervision ne transfère pas la responsabilité propre de l'entité financière.
Extrait de la fiche « DORA: Digital Operational Resilience (part 2) » · Demander la fiche complète
Liste de contrôle
| # | Point | Terminé quand |
|---|---|---|
| 1 | Fonctions critiques ou importantes reliées aux actifs et prestataires | Un responsable, un RTO et un RPO par fonction |
| 2 | Cadre approuvé par l'organe de direction | PV, date de revue annuelle, traces de formation |
| 3 | Classification intégrée au processus de réponse | Décision horodatée et signée ; formulaires préremplis |
| 4 | Notification répétée | Exercice sur table avec les délais 4 h / 72 h et le RGPD en parallèle |
| 5 | Programme de tests annuel | Plan, résultats et remédiation suivis |
| 6 | Préparation au TLPT (si désigné) | Équipe de contrôle nommée, participation des prestataires prévue au contrat |
| 7 | Registre d'informations | LEI, fonctions et chaînes de sous-traitance complets |
| 8 | Clauses de l'article 30 | Contrats critiques amendés ; liste d'écarts pour les autres |
| 9 | Plans de sortie | Rédigés et testés pour chaque prestataire critique |
| 10 | Sauvegardes séparées | Restauration testée dans le RTO |
La configuration cloud fait aussi partie de la réponse : comptes durcis, journalisation et sauvegardes isolées sur AWS, Azure ou GCP concentrent une bonne part des constats sur les articles 9 à 12 (voir l'architecture de sécurité cloud et la reprise après sinistre).
Notre accompagnement
Tadata accompagne les entités financières et leurs prestataires en audit de sécurité et conformité (analyse d'écarts DORA, analyse de risques, alignement ISO 27001) et en sécurité cloud et DevSecOps (durcissement et conception des sauvegardes sur AWS, Azure, GCP et Kubernetes). Voir notre page cybersécurité ; la bibliothèque de fiches contient deux fiches DORA avec les seuils et les textes de niveau 2.