DORA Act : 5 obligations IT en vigueur depuis janvier 2025 (et comment s'y conformer)

#Qu'est-ce que DORA ? Contexte réglementaire et périmètre UE

Le Digital Operational Resilience Act (DORA) est le Règlement (UE) 2022/2554 du Parlement européen et du Conseil, adopté le 14 décembre 2022, publié au Journal officiel de l'UE le 27 décembre 2022 et pleinement applicable depuis le 17 janvier 2025. Avec lui, l'UE crée pour la première fois un cadre harmonisé de résilience opérationnelle numérique spécifiquement conçu pour le secteur financier.

Avant DORA, la résilience IT du secteur financier était encadrée par une mosaïque de textes nationaux, de guidelines sectorielles (orientations EBA, guidelines BCE pour les institutions importantes) et de bonnes pratiques non contraignantes. Le résultat : des niveaux d'exigence hétérogènes d'un État membre à l'autre, des failles dans la surveillance des sous-traitants TIC et une gestion des incidents très variable.

DORA y répond en posant cinq piliers uniformes, directement applicables dans les 27 États membres, sans besoin de transposition. En France, l'ACPR (Autorité de contrôle prudentiel et de résolution) est l'autorité compétente principale pour la supervision DORA des établissements de crédit, des compagnies d'assurance et des établissements de paiement. La BCE intervient pour la supervision directe des établissements importants dans le cadre du MSU.

#Un règlement né des leçons des grandes pannes et cyberattaques

Les incidents systémiques ont convaincu les régulateurs de la nécessité d'un cadre uniforme. Les pannes IT majeures dans des établissements financiers européens (paralysie de services bancaires pendant plusieurs jours, incidents de paiement affectant des millions de clients), conjuguées à la montée en puissance des cyberattaques ciblant les infrastructures financières, ont mis en lumière la dépendance critique envers des fournisseurs cloud et SaaS parfois concentrés sur quelques acteurs mondiaux.

DORA tire les conséquences de cette réalité : la résilience numérique d'une banque ou d'une fintech ne peut plus être évaluée uniquement sur la base de ses systèmes internes. Elle doit intégrer l'ensemble de sa chaîne de dépendances technologiques.

#Qui est concerné par DORA ?

L'article 2 de DORA définit un périmètre d'application très large. Sont directement soumises au règlement :

• Les établissements de crédit (banques, caisses d'épargne, banques mutualistes)
• Les établissements de paiement (dont les établissements de paiement électronique)
• Les établissements de monnaie électronique
• Les entreprises d'investissement
• Les organismes de placement collectif (OPCVM, FIA) et leurs gestionnaires (SGP)
• Les entreprises d'assurance et de réassurance
• Les intermédiaires d'assurance de grande taille
• Les infrastructures de marché (dépositaires centraux, contreparties centrales, plateformes de négociation)
• Les fintechs dont les services relèvent d'une des catégories ci-dessus
• Les prestataires de services sur crypto-actifs (MiCA)
• Les agences de notation de crédit, référentiels centraux, fournisseurs de services de communication de données

Un régime proportionné est prévu pour les « microentreprises » (moins de 10 salariés et CA < 32 M€) et pour certaines petites entités : elles bénéficient d'un cadre allégé sur les tests de résilience et la documentation, mais restent soumises aux obligations fondamentales de gouvernance et de notification d'incidents.

#Les fournisseurs TIC tiers : une nouveauté structurante

DORA introduit une supervision directe des prestataires TIC critiques par les Autorités européennes de surveillance (ABE, AEAPP, AEMF) via un mécanisme de désignation. Les grands fournisseurs cloud (hyperscalers), les éditeurs de solutions bancaires cœur et les fournisseurs d'infrastructures critiques désignés comme «critiques» sont soumis à des examens et audits menés par les autorités européennes — une rupture majeure avec le principe selon lequel seule l'entité financière cliente était responsable devant le régulateur.

#Les 5 piliers DORA détaillés

#Pilier 1 — Gouvernance et gestion du risque ICT

Le premier pilier impose une gouvernance de haut niveau du risque TIC. L'organe de direction (conseil d'administration, directoire) doit assumer la responsabilité ultime de la gestion du risque ICT. Cela se traduit par des exigences concrètes :

Cadre de gestion du risque ICT (articles 5 à 16)

Chaque entité doit disposer d'un cadre de gestion du risque ICT documenté, révisé annuellement (ou après chaque incident majeur), couvrant :

• L'identification et la classification des actifs ICT (cartographie des systèmes critiques et non critiques)
• La protection et la prévention (politiques de sécurité, contrôles d'accès, chiffrement)
• La détection (monitoring en temps réel, alertes)
• La réponse et le rétablissement (plans de continuité d'activité, RTO/RPO documentés)
• La communication (procédures de notification interne et externe)

Rôle du RSSI et du DSI

Le RSSI (Responsable de la Sécurité des Systèmes d'Information) est au premier plan sur le pilier 1 : il pilote la cartographie des risques ICT, supervise la politique de sécurité et coordonne les tests. Le DSI assure l'implémentation technique et la continuité des systèmes. Le Compliance Officer veille à l'alignement des politiques DORA avec les autres obligations réglementaires (RGPD, NIS2, exigences prudentielles) et gère les relations avec les superviseurs.

Points d'attention pratiques

• La politique de gestion du risque ICT doit être approuvée formellement par l'organe de direction — un simple visa opérationnel ne suffit pas.
• La cartographie des actifs doit couvrir les dépendances tiers : un système critique hébergé chez un fournisseur cloud doit apparaître dans la cartographie avec le niveau de criticité associé.
• Les RTO (Recovery Time Objective) et RPO (Recovery Point Objective) doivent être définis et testés, pas seulement documentés.

#Pilier 2 — Gestion des incidents TIC : classification, notification et délais

Le pilier 2 établit un processus harmonisé de détection, classification, gestion et notification des incidents TIC. C'est probablement le pilier avec les contraintes opérationnelles les plus immédiates.

Classification des incidents

DORA distingue les incidents TIC des incidents TIC «majeurs». Un incident est qualifié de «majeur» selon des critères définis dans les normes techniques de réglementation (RTS) publiées par les AES, qui prennent en compte :

• Le nombre de clients affectés
• La durée de l'incident
• L'impact géographique
• L'impact sur les transactions (volume, montants)
• L'impact sur la réputation ou les données

Délais de notification obligatoires (article 19)

Pour les incidents majeurs, le calendrier de notification est strict :

L'autorité compétente transmet ensuite les informations pertinentes à la BCE (pour les établissements importants), à l'ABE, à l'AEAPP ou à l'AEMF selon le type d'entité, ainsi qu'à l'ENISA et au CERT-UE.

Cybermenaces significatives

DORA impose également de notifier les cybermenaces significatives — c'est-à-dire les tentatives d'attaque sérieuses n'ayant pas encore donné lieu à un incident — aux autorités compétentes. Cette obligation préventive est nouvelle et nécessite une capacité de détection et de triage en temps réel.

Points d'attention pratiques

• Constituez une équipe de réponse aux incidents TIC avec des rôles définis et un canal de communication sécurisé avec l'ACPR.
• Le délai de 4 heures pour le rapport initial est très court : la procédure de classification doit être automatisée au maximum.
• Conservez les preuves techniques (logs, captures) dès la détection — elles alimenteront les rapports intermédiaire et final.

#Pilier 3 — Tests de résilience opérationnelle numérique : TLPT et pentests

Le pilier 3 impose des tests réguliers et structurés de la résilience des systèmes ICT. Il distingue deux niveaux de tests selon la taille et la criticité de l'entité.

Tests de base (toutes entités)

Toutes les entités dans le périmètre DORA doivent réaliser au minimum :

• Des tests de vulnérabilité (scans automatisés et manuels)
• Des tests de réseau (analyse de segmentation, de robustesse)
• Des tests de pénétration (pentests) basés sur les scénarios de menaces identifiés
• Des tests de continuité d'activité et de reprise après sinistre (DR tests)
• Des exercices de simulation de crise ICT (tabletop exercises)

Ces tests doivent être documentés, leurs résultats analysés et les corrections apportées traçées.

TLPT — Threat-Led Penetration Testing (articles 26-27)

Les entités d'importance systémique sont soumises à des TLPT (tests de pénétration guidés par la menace), une forme avancée de Red Team menée selon le cadre TIBER-EU défini par la BCE. Les TLPT doivent être réalisés tous les 3 ans par des testeurs externes certifiés, sur la base d'un renseignement sur la menace (Threat Intelligence) produit par un fournisseur accrédité.

Le processus TLPT implique :

1. Une phase de renseignement sur la menace : identification des acteurs de la menace les plus susceptibles de cibler l'entité
2. Une phase de planification validée par le superviseur
3. Une phase de Red Team : attaque contrôlée des systèmes de production, sans que les équipes Blue Team soient prévenues
4. Un rapport de clôture partagé avec l'autorité compétente

Reconnaissance mutuelle des TLPT

Une entité ayant passé un TLPT dans un État membre peut faire reconnaître ses résultats dans d'autres États membres où elle est présente — évitant la duplication coûteuse des tests pour les groupes transfrontaliers.

Points d'attention pratiques

• Établissez dès maintenant un calendrier pluriannuel de tests : le TLPT de 3 ans doit être planifié 12 à 18 mois à l'avance pour trouver des prestataires accrédités disponibles.
• Les pentests «de base» doivent couvrir les systèmes liés aux tiers fournisseurs, pas seulement les systèmes internes.
• Documentez les remédiations : un test non suivi d'actions correctives traçables aggrave votre situation réglementaire.

#Pilier 4 — Gestion du risque lié aux tiers fournisseurs TIC

C'est le pilier le plus structurellement nouveau de DORA. L'article 28 impose aux entités financières une gestion formalisée du risque de concentration et de dépendance envers leurs fournisseurs TIC.

Le registre des tiers (Register of Information)

Chaque entité doit constituer et maintenir un registre complet de tous ses prestataires TIC, avec pour chaque prestataire :

• La description des services fournis
• La criticité du service (critique / non critique)
• Les données traitées
• Les sous-traitants du prestataire (sous-traitance en chaîne)
• Les pays d'hébergement des données
• Les mécanismes de sortie contractuels

Les autorités compétentes peuvent demander communication de ce registre à tout moment. L'ABE a publié des normes techniques de mise en œuvre (ITS) définissant le format standardisé du registre.

Exigences contractuelles avec les fournisseurs TIC (article 30)

Les contrats avec les prestataires TIC fournissant des services critiques ou importants doivent obligatoirement inclure :

• Les niveaux de service (SLA) avec des indicateurs mesurables
• Les droits d'audit et d'accès aux locaux du prestataire
• Les obligations de coopération en cas d'incident
• Les conditions de résiliation et de stratégie de sortie
• Les dispositions relatives à la portabilité des données
• Les droits à l'information sur les sous-traitants

Concentration et risque systémique

DORA impose d'évaluer et de documenter le risque de concentration : si plusieurs entités financières dépendent du même fournisseur cloud pour des services critiques, la défaillance de ce fournisseur pourrait déstabiliser le système financier. Les entités doivent documenter leurs stratégies de sortie et de substitution — y compris des plans de migration réalistes testés périodiquement.

Supervision directe des prestataires TIC critiques désignés

L'ABE, l'AEAPP et l'AEMF désignent les prestataires TIC «critiques» au niveau européen. Ces prestataires sont soumis à des inspections, des demandes d'information et, en dernier ressort, à des recommandations contraignantes des autorités européennes. Pour les entités financières, cela signifie que leurs fournisseurs cloud stratégiques sont désormais eux-mêmes dans le périmètre de la supervision prudentielle.

Points d'attention pratiques

• Commencez par auditer vos contrats existants avec les fournisseurs SaaS, cloud et PSP : la plupart des contrats signés avant 2025 ne contiennent pas les clauses DORA requises.
• Le registre des tiers au format ITS-ABE doit être opérationnel dès maintenant — les superviseurs l'ont demandé lors des premiers exercices de collecte de données.
• Identifiez vos fournisseurs «single point of failure» et documentez des alternatives crédibles.

→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.

#Pilier 5 — Partage d'informations sur les cybermenaces

Le cinquième pilier crée un cadre volontaire mais structuré de partage d'informations sur les cybermenaces entre entités financières. Les articles 45-46 de DORA encouragent la participation à des arrangements de partage d'informations sur les menaces et vulnérabilités (similaires aux ISACs — Information Sharing and Analysis Centers).

→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.

Ce que couvre le partage d'informations

Les informations échangeables dans ce cadre incluent :

• Les indicateurs de compromission (IoC)
• Les tactiques, techniques et procédures (TTP) d'acteurs malveillants
• Les vulnérabilités découvertes (avant divulgation publique)
• Les leçons tirées des incidents TIC majeurs subis par les membres

Garanties légales et conformité RGPD

DORA précise que le partage d'informations doit respecter le secret des affaires et ne pas créer de responsabilité accrue pour les entités participantes. Les informations partagées sur des personnes physiques doivent respecter le RGPD. Ce cadre légal était l'une des réticences historiques à la participation aux ISACs dans le secteur financier français.

#Calendrier et dates clés DORA

#Sanctions pour non-conformité

DORA ne fixe pas lui-même le montant des sanctions administratives — il renvoie aux États membres pour transposer les dispositions pénales — mais il fixe des seuils maximaux que les autorités nationales doivent respecter.

En France, l'ACPR peut prononcer :

• Des sanctions pécuniaires jusqu'à 2 % du chiffre d'affaires annuel total de l'établissement (et jusqu'à 1 % pour les entités moins importantes)
• Des astreintes journalières jusqu'à 1 % du chiffre d'affaires journalier moyen pour chaque jour de non-conformité persistante
• Des mesures administratives : mise en garde, mise en demeure, restriction ou suspension d'activité, retrait d'agrément dans les cas les plus graves

Pour les prestataires TIC critiques désignés, les AES peuvent recommander des mesures contraignantes assorties d'astreintes pouvant atteindre 1 % du chiffre d'affaires journalier mondial.

Ces niveaux de sanctions sont significatifs pour les fintechs et les petits établissements de paiement : 2 % du CA annuel peut représenter plusieurs mois de résultat opérationnel.

#Rôle du RSSI, du DSI et du Compliance Officer dans DORA

DORA implique une collaboration étroite entre trois fonctions qui, dans de nombreuses structures financières françaises, opèrent encore en silos.

Le RSSI (Responsable de la Sécurité des Systèmes d'Information)

• Propriétaire du cadre de gestion du risque ICT (pilier 1)
• Responsable du programme de tests (pilier 3 : pentests, TLPT)
• Superviseur de la détection et réponse aux incidents (pilier 2)
• Contributeur à l'évaluation du risque tiers sur les aspects sécurité (pilier 4)

Le DSI (Directeur des Systèmes d'Information)

• Responsable de la cartographie des actifs ICT et de leur classification
• Garant des RTO/RPO et de leur test effectif
• Responsable de la mise à jour contractuelle avec les fournisseurs TIC (en lien avec les achats et le juridique)
• Pilote des plans de continuité et de reprise d'activité

Le Compliance Officer (Responsable Conformité)

• Interlocuteur principal de l'ACPR sur les dossiers DORA
• Gestionnaire des notifications d'incidents aux autorités
• Garant de l'alignement de la politique DORA avec les autres obligations réglementaires (RGPD, NIS2, exigences prudentielles CRR/CRD)
• Coordinateur des audits internes DORA et des revues annuelles du cadre de gestion ICT

Dans les organisations qui n'ont pas encore clarifié ces responsabilités, DORA est l'occasion de constituer une cellule de gouvernance DORA réunissant ces trois fonctions sous le sponsorship direct de la Direction Générale.

#Checklist conformité DORA en 8 points

• 1. Inventaire ICT complet : cartographier tous les systèmes, actifs numériques et fournisseurs TIC avec leur niveau de criticité
• 2. Registre des tiers au format ITS-ABE : constituer le Register of Information standardisé, le valider et le tenir à jour en continu
• 3. Audit contractuel fournisseurs : vérifier que tous les contrats avec des prestataires TIC critiques incluent les clauses obligatoires DORA (droits d'audit, SLA, stratégie de sortie)
• 4. Procédure de classification et notification d'incidents : documenter le processus de triage, définir les seuils de qualification «incident majeur», établir les templates de rapports initial/intermédiaire/final pour l'ACPR
• 5. Programme de tests de résilience : planifier les pentests annuels, les DR tests et (si applicable) le prochain TLPT triennal avec prestataire accrédité TIBER-EU
• 6. Plan de continuité d'activité ICT : documenter et tester les plans BCP/DRP avec des RTO/RPO validés par l'organe de direction
• 7. Gouvernance formalisée : faire approuver la politique de gestion du risque ICT par le conseil d'administration ou le directoire, désigner les responsables DORA (RSSI, DSI, Compliance)
• 8. Stratégies de sortie fournisseurs : documenter des alternatives crédibles pour chaque fournisseur en situation de «single point of failure» et tester les procédures de migration

#Outils GRC recommandés pour la mise en conformité DORA

La mise en conformité DORA mobilise un volume important de documentation, de preuves et de suivi d'actions correctives. Les outils de GRC (Gouvernance, Risque, Conformité) permettent d'industrialiser cette gestion.

Solutions GRC spécialisées secteur financier

• ServiceNow GRC : module de gestion des risques TIC avec intégration native des frameworks réglementaires, adapté aux grandes banques et assurances
• OneTrust : gestion intégrée des risques tiers et des obligations réglementaires, avec des modules DORA préconfigurés
• Riskonnect : gestion des risques opérationnels et des tiers, adopté par plusieurs assureurs européens
• Archer (RSA) : solution historique de GRC financier, avec des templates DORA disponibles

Outils spécifiques pour le registre des tiers

• ProcessUnity / Prevalent : gestion du cycle de vie des tiers fournisseurs, questionnaires de due diligence, scoring de risque
• Coupa Risk Assess : gestion du risque fournisseur avec alertes en temps réel

Outils de gestion des incidents TIC

• PagerDuty / OpsGenie : orchestration des réponses aux incidents avec workflows de notification
• Splunk SOAR : automatisation de la détection, triage et réponse aux incidents cybersécurité

Points d'attention sur la sélection d'outils

• Vérifiez que l'outil supporte le format standardisé du registre des tiers défini par l'ITS-ABE (fichier structuré avec champs obligatoires spécifiques)
• Assurez-vous que les données GRC restent souveraines : l'hébergement dans un cloud non-UE de données de conformité réglementaire peut créer des tensions avec DORA lui-même
• Préférez des solutions dont les fournisseurs peuvent démontrer leur propre conformité DORA (registre des tiers, documentation de sécurité)

#Position Nehos : audit DORA et feuille de route technique

Nehos accompagne les entités financières — établissements de paiement, fintechs, assurtechs, sociétés de gestion — dans leur mise en conformité DORA selon une approche structurée en quatre phases.

Phase 1 — Audit DORA et cartographie des écarts

Nous réalisons un audit initial de votre maturité DORA en 15 jours : entretiens avec le RSSI, le DSI et le Compliance Officer, revue des politiques ICT existantes, inventaire des systèmes critiques et des fournisseurs TIC, analyse des contrats en vigueur. Le livrable est un rapport d'écarts (gap analysis) priorisé selon les 5 piliers DORA.

Phase 2 — Documentation et politiques

Nous rédigeons ou mettons à jour les documents requis par DORA : politique de gestion du risque ICT, procédure de classification et notification d'incidents, politique de tests de résilience, cartographie des tiers. Ces documents sont calibrés pour répondre aux attentes documentaires de l'ACPR.

Phase 3 — Implémentation technique

Nous accompagnons vos équipes dans la mise en place des contrôles techniques : activation des logs pour les systèmes critiques, configuration des outils de monitoring, mise à jour des contrats fournisseurs, constitution du registre des tiers au format ITS-ABE.

Phase 4 — Préparation aux contrôles superviseurs

Nous préparons votre dossier de conformité DORA et vous entraînons aux questionnaires de supervision de l'ACPR. Nehos travaille avec des avocats partenaires spécialisés en droit financier pour les volets contractuels et les interactions avec les autorités.