DORA : résilience opérationnelle dans le cloud

Depuis le 17 janvier 2025, le règlement DORA impose au secteur financier une résilience opérationnelle numérique testée, documentée et opposable. Pour une banque, un assureur ou une société de gestion qui exploite tout ou partie de son système d'information sur Azure ou AWS, la question n'est plus « sommes-nous dans le cloud ? » mais « notre usage du cloud tient-il devant l'ACPR, l'AMF et un contrôle de continuité ? ». Cette page traite la conformité DORA cloud sous un angle opérationnel : les cinq piliers de DORA projetés sur une infrastructure cloud, et surtout le régime des prestataires tiers de TIC, là où votre fournisseur cloud devient un maillon réglementé de votre chaîne de résilience.

• Règlement (UE) 2022/2554
• Applicable depuis le 17/01/2025
• 5 piliers
• Clauses art. 30
• Stratégie de sortie

Qu'est-ce que le règlement DORA et qui est concerné ?

DORA (Digital Operational Resilience Act), formellement le règlement (UE) 2022/2554, est un texte européen d'application directe. À la différence d'une directive, il ne se transpose pas dans chaque droit national : il s'applique tel quel, sans marge d'interprétation. Son objectif est simple à énoncer, exigeant à mettre en œuvre : garantir que le secteur financier peut résister, réagir et se rétablir face à toute perturbation grave liée aux technologies de l'information et de la communication (TIC), qu'il s'agisse d'une cyberattaque, d'une panne majeure d'un fournisseur ou d'une défaillance interne.

Le périmètre est large. Sont concernées près d'une vingtaine de catégories d'entités financières : établissements de crédit (banques), établissements de paiement et de monnaie électronique, entreprises d'investissement, sociétés de gestion et gestionnaires de fonds, entreprises d'assurance et de réassurance, intermédiaires d'assurance, prestataires de services sur crypto-actifs, dépositaires centraux, contreparties centrales, plateformes de négociation, agences de notation, et d'autres encore. En France, la supervision relève de l'ACPR pour la banque et l'assurance, et de l'AMF pour les marchés.

DORA applique un principe de proportionnalité : les obligations sont modulées selon la taille, le profil de risque et la nature de l'activité. Les microentreprises relèvent d'un régime allégé. Mais l'esprit reste identique pour tous : la résilience opérationnelle n'est plus un sujet purement technique délégué à la DSI, c'est une responsabilité de l'organe de direction, qui doit approuver le cadre, comprendre le risque TIC et rendre des comptes.

DORA, NIS2 et RGPD : trois textes, trois logiques

Ces trois réglementations se croisent sur le cloud, sans se confondre. DORA est un règlement sectoriel (finance et assurance) centré sur la résilience opérationnelle. NIS2 est une directive transverse de cybersécurité qui vise un très large éventail de secteurs (énergie, santé, transport, infrastructures numériques). Le RGPD protège les données personnelles. Pour une entité financière, les trois peuvent s'appliquer simultanément. Le panorama complet de ces référentiels est traité sur notre page conformité cloud (RGPD, ISO 27001, HDS, DORA) ; le détail des obligations transverses de cybersécurité relève de la mise en conformité NIS2 dans le cloud. Ici, nous restons sur l'angle propre à DORA.

Les 5 piliers de DORA appliqués à une infrastructure cloud

DORA structure ses exigences en cinq piliers. Chacun se projette concrètement sur un environnement Azure ou AWS. Les comprendre dans cet ordre évite de traiter le sujet comme une simple checklist documentaire.

• 1. Gestion du risque TIC

  Un cadre gouverné et documenté qui identifie, protège, détecte, répond et se rétablit. C'est le socle, sous la responsabilité de l'organe de direction.

• 2. Gestion des incidents

  Détecter, classifier et notifier les incidents liés aux TIC selon des critères et des délais harmonisés, jusqu'à la déclaration des incidents majeurs à l'autorité.

• 3. Tests de résilience

  Un programme de tests régulier, du scan de vulnérabilités au test de pénétration fondé sur la menace (TLPT) pour les entités les plus significatives.

• 4. Risque lié aux tiers TIC

  Encadrer les prestataires (dont le cloud) : clauses contractuelles, registre d'information, droit d'audit et stratégie de sortie. Le cœur du sujet cloud.

• 5. Partage d'informations

  Des accords volontaires d'échange de renseignements sur les cybermenaces entre entités financières, pour élever la défense collective.

Pilier 1 : la gestion du risque lié aux TIC

Le premier pilier exige un cadre de gestion du risque TIC complet, documenté et revu périodiquement. Il doit couvrir l'ensemble du cycle : identifier les actifs et les dépendances, protéger les systèmes, détecter les anomalies, répondre aux incidents et se rétablir. Sur le cloud, cela se traduit par un inventaire à jour de vos ressources Azure ou AWS, une cartographie des fonctions critiques et de leurs dépendances (bases de données, annuaire Entra ID, DNS, files de messages), et des mesures de sécurité alignées sur cette criticité. La construction technique de ce socle (identités, chiffrement, journalisation, segmentation) est détaillée sur notre pilier sécurisation d'infrastructure cloud.

Le point spécifique à DORA est la gouvernance : l'organe de direction approuve la stratégie de résilience, alloue les moyens et se tient informé. Le risque TIC cesse d'être un angle mort technique pour devenir une ligne du tableau de bord des dirigeants.

Pilier 2 : la gestion, la classification et la notification des incidents

DORA harmonise la façon dont les incidents liés aux TIC sont détectés, classifiés et signalés. Vous devez disposer d'un processus qui enregistre les incidents, mesure leur gravité selon des critères communs (nombre de clients touchés, durée, pertes de données, portée géographique, impact économique) et remonte les incidents majeurs à l'autorité compétente selon un calendrier précis. Ce pilier fait l'objet d'une section dédiée plus bas, car il impose une mécanique de notification chronométrée que votre exploitation cloud doit être capable d'alimenter en preuves.

Pilier 3 : les tests de résilience opérationnelle numérique

DORA impose un programme de tests proportionné au risque. Pour toutes les entités, cela inclut des tests réguliers : évaluations de vulnérabilité, scans, tests de sécurité réseau, revues de code, tests de continuité et de sauvegarde. Pour les entités les plus significatives, s'ajoute le TLPT (Threat-Led Penetration Testing), un test de pénétration fondé sur des scénarios de menace réels, détaillé plus loin. Ces tests portent aussi sur les systèmes hébergés dans le cloud, ce qui suppose de cadrer les règles d'engagement avec le fournisseur.

Pilier 4 : la gestion du risque lié aux prestataires tiers de TIC

C'est le pilier décisif pour toute organisation qui utilise le cloud, et le cœur de cette page. DORA encadre la relation avec les prestataires tiers de services TIC : le fournisseur cloud, mais aussi l'éditeur SaaS, l'infogérant ou l'opérateur de sécurité managée. Il impose des clauses contractuelles précises, un registre d'information, un droit d'audit effectif et une stratégie de sortie. Les sections suivantes le détaillent brique par brique.

Pilier 5 : le partage d'informations sur les cybermenaces

Le cinquième pilier encourage, sur une base volontaire, les accords d'échange de renseignements sur les cybermenaces (indicateurs de compromission, tactiques d'attaquants, alertes) entre entités financières, dans le respect de la protection des données. C'est le pilier le plus léger en obligations, mais il traduit l'esprit de DORA : la résilience d'un acteur profite à tout l'écosystème.

Le cloud, prestataire tiers de TIC au sens de DORA

Dès qu'une fonction est portée par Azure, AWS ou un service tiers, votre fournisseur devient, au sens de DORA, un prestataire tiers de services TIC. Cette qualification n'est pas anodine : elle enclenche des obligations concrètes de votre côté, indépendamment de la taille du fournisseur. Le modèle de responsabilité partagée ne disparaît pas avec DORA, il se double d'une couche réglementaire : le fournisseur sécurise son infrastructure, vous restez responsable de la maîtrise du risque qu'il fait peser sur vos fonctions critiques ou importantes.

DORA distingue les prestations selon qu'elles soutiennent ou non une fonction critique ou importante. Une fonction est critique ou importante lorsque sa défaillance compromettrait sérieusement la performance financière, la solidité ou la continuité des services de l'entité. Cette qualification déclenche le régime le plus exigeant : clauses renforcées, droit d'audit approfondi, exigences de plans de secours et stratégie de sortie. La première tâche d'un chantier DORA cloud consiste donc à cartographier quelles charges hébergées soutiennent des fonctions critiques ou importantes, car tout le reste en découle.

Les prestataires tiers critiques sous supervision européenne

DORA crée un régime inédit : les prestataires tiers de TIC jugés critiques pour le système financier européen (les CTPP, Critical ICT Third-Party Providers) peuvent être désignés par les autorités européennes de surveillance (EBA, EIOPA, ESMA) et placés sous un cadre de supervision directe, piloté par un superviseur principal (Lead Overseer). Les grands fournisseurs cloud figurent parmi les candidats naturels à cette désignation, en raison de leur concentration systémique.

Ce régime a une conséquence stratégique : DORA se méfie de la concentration. Confier l'ensemble de ses fonctions critiques à un unique fournisseur, sans alternative crédible, devient un risque à documenter et, parfois, à réduire. C'est l'un des arguments qui alimentent la réflexion sur la souveraineté numérique et le cloud souverain, sans pour autant l'imposer.

Les clauses contractuelles obligatoires (article 30)

L'article 30 de DORA fixe le contenu minimal des contrats conclus avec un prestataire tiers de TIC. Un contrat cloud « standard » signé avant 2025 est rarement conforme en l'état : il faut souvent l'amender ou négocier un addendum DORA. Les exigences se renforcent lorsque la prestation soutient une fonction critique ou importante.

Un point souvent négligé : la chaîne de sous-traitance. DORA vous demande de garder une visibilité sur les sous-traitants du prestataire qui interviennent dans une fonction critique. Le contrat doit encadrer le recours à la sous-traitance et vos droits en la matière. Concrètement, il ne suffit pas de connaître votre fournisseur cloud direct : vous devez comprendre à qui il délègue les briques qui soutiennent vos fonctions sensibles.

Le registre d'information : recenser vos prestataires TIC

DORA impose de tenir un registre d'information recensant l'ensemble de vos accords contractuels avec des prestataires tiers de TIC. Ce n'est pas un tableur informel : son format est normalisé, et les autorités compétentes peuvent le demander. Les autorités européennes de surveillance collectent ces registres pour identifier les concentrations et désigner les prestataires critiques.

Le registre doit distinguer les prestataires qui soutiennent des fonctions critiques ou importantes des autres, préciser la nature des services, la localisation des données, les liens de sous-traitance et la criticité associée. Tenir ce registre à jour suppose une gouvernance : chaque nouveau service cloud souscrit, chaque nouvelle région activée, chaque SaaS ajouté doit y être reflété. C'est aussi un excellent outil de pilotage interne, qui rejoint le registre des traitements du RGPD sans s'y substituer.

La stratégie de sortie et la réversibilité exigées par DORA

C'est l'exigence qui distingue le plus DORA des autres textes, et celle qui touche directement l'architecture. Pour toute prestation TIC soutenant une fonction critique ou importante, DORA impose une stratégie de sortie documentée : la capacité de quitter le prestataire, de récupérer ses données et de reprendre l'activité ailleurs sans interruption préjudiciable, sans dégradation de la conformité et sans perte de continuité.

Une stratégie de sortie crédible répond à plusieurs questions concrètes. Comment récupérer l'intégralité des données, dans un format exploitable, et dans quel délai ? Combien de temps pour reconstruire l'environnement chez un autre fournisseur ou en interne ? Les dépendances propriétaires (services managés spécifiques, formats fermés) rendent-elles la sortie impraticable ? Existe-t-il un plan de transition testé, ou seulement une clause théorique dans le contrat ?

C'est précisément là que notre principe d'autonomie du client rejoint l'exigence réglementaire. Une architecture décrite en Infrastructure as Code (Terraform, Bicep) versionnée dans vos propres dépôts, des comptes cloud à votre nom, une documentation remise et une limitation raisonnée des services propriétaires transforment la stratégie de sortie en capacité réelle plutôt qu'en promesse contractuelle. La réversibilité cesse d'être une ligne dans les conditions générales : elle devient un artefact que vous pouvez exécuter et tester. Cette logique d'anti-enfermement irrigue toute notre approche, du conseil en architecture à la construction de la landing zone.

Tester la résilience opérationnelle : du test de base au TLPT

DORA fait des tests le juge de paix de la résilience. Un cadre écrit ne vaut que s'il est éprouvé. Le programme de tests se construit par paliers, proportionnés au profil de l'entité.

1. Tests de base, réguliers Analyses de vulnérabilité, scans automatisés, tests de sécurité réseau, revues de configuration face aux référentiels (CIS Benchmarks), tests de sauvegarde et de restauration. Ils s'appliquent à toutes les entités concernées.
2. Tests de continuité et de reprise Exercices de bascule et de restauration validant les objectifs de temps (RTO) et de perte de données (RPO). La mécanique opérationnelle de ces tests, stratégies de reprise et campagnes de bascule, est détaillée sur notre page [PRA cloud (plan de reprise d'activité)](/pra-cloud).
3. TLPT, pour les entités significatives Un test de pénétration fondé sur la menace, mené sur les systèmes réels de production qui soutiennent les fonctions critiques, selon des scénarios inspirés d'attaquants réalistes.

Le TLPT (Threat-Led Penetration Testing)

Le TLPT est le test le plus avancé prévu par DORA. Inspiré du cadre européen TIBER-EU, il simule des attaques ciblées, fondées sur du renseignement sur les menaces, contre les systèmes de production qui soutiennent vos fonctions critiques. Il ne concerne que les entités désignées comme significatives par les autorités, à une fréquence de l'ordre d'une fois tous les trois ans, sous supervision d'une autorité et avec l'implication de testeurs qualifiés.

Point structurant pour le cloud : dès lors qu'une fonction critique s'exécute sur Azure ou AWS, le périmètre d'un TLPT peut inclure ces environnements. Cela suppose d'obtenir l'accord et de cadrer les règles d'engagement du fournisseur (les hyperscalers encadrent strictement les tests d'intrusion sur leurs plateformes), et d'associer le prestataire critique au dispositif. Le contrat, via l'article 30, doit d'ailleurs prévoir cette participation aux tests.

Gérer et notifier les incidents majeurs liés aux TIC

DORA transforme la gestion d'incident en processus réglementé et chronométré. Vous devez classifier chaque incident lié aux TIC et, lorsqu'il atteint le seuil d'incident majeur, le notifier à votre autorité compétente selon un calendrier en trois temps, défini par les normes techniques (RTS/ITS).

1. Notification initiale Dès qu'un incident est classé majeur, une première alerte est transmise à l'autorité dans un délai court (de l'ordre de 24 heures après la prise de connaissance, ou quelques heures après la classification). Elle signale l'événement sans attendre l'analyse complète.
2. Rapport intermédiaire Un point d'étape (de l'ordre de 72 heures) précise l'évolution, les impacts constatés et les mesures prises. Il peut être actualisé si la situation change.
3. Rapport final Une analyse complète (de l'ordre d'un mois) expose la cause racine, l'impact réel et les mesures correctives pérennes.

La faisabilité de ce calendrier repose entièrement sur votre capacité de détection et de preuve. Sans journalisation centralisée, inaltérable et correctement conservée, il est impossible de qualifier un incident en quelques heures ni de produire un rapport final étayé. C'est le lien direct entre DORA et l'ingénierie : la conformité au pilier « incidents » se prépare en amont, dans la supervision. Les mécanismes concrets (SIEM, détection managée, runbooks de réponse à incident, journalisation) relèvent de notre page sécurisation d'infrastructure cloud et d'une supervision cloud 24/7.

Projeter DORA sur Azure et AWS : la résilience concrète

DORA ne prescrit aucune technologie. Mais ses exigences se traduisent en choix d'architecture précis sur les deux principales plateformes. Voici comment les grandes obligations se projettent, sans réécrire la mécanique de reprise déjà couverte sur notre page PRA cloud.

Trois principes guident la projection. D'abord, la résilience multi-région est le pivot des fonctions critiques : une architecture cantonnée à une seule région ne résiste pas à un sinistre régional, or DORA attend justement une continuité éprouvée. Ensuite, les sauvegardes immuables répondent au scénario qui inquiète le plus les régulateurs et les assureurs, le rançongiciel : une réplication seule propage fidèlement des données chiffrées par un attaquant, seules des copies immuables et antérieures à l'infection permettent une restauration propre. Enfin, la traçabilité (journalisation inaltérable, inventaire vivant) est ce qui rend la conformité démontrable plutôt que déclarative. Le détail des stratégies de reprise (Backup & Restore, Pilot Light, Warm Standby, Actif/Actif) et des tests de bascule figure sur notre page dédiée au PRA cloud, qui reste le compagnon opérationnel de cette page.

DORA, NIS2 et RGPD : comment les textes s'articulent

Pour une entité financière, la bonne nouvelle est que ces textes se recoupent largement. Un socle de sécurité et de résilience bien conçu sert les trois à la fois. La mauvaise nouvelle est qu'ils ne s'excluent pas : il faut satisfaire chacun sur son terrain propre.

Le principe d'articulation est la spécialité : pour les entités financières, DORA prévaut comme lex specialis sur les obligations générales de cybersécurité, tout en s'inscrivant dans le même esprit que NIS2. Le RGPD reste applicable en parallèle dès qu'il y a des données personnelles, avec sa propre logique de notification (violation de données à la CNIL sous 72 heures), distincte de la notification d'incident DORA. Pour les prestataires de paiement, les exigences de sécurité de la DSP2 appliquée au cloud se cumulent. Le tableau de bord de conformité d'un acteur financier combine donc plusieurs registres et plusieurs canaux de notification, qu'il est rentable d'outiller de façon unifiée. Le panorama d'ensemble est cartographié sur notre page conformité cloud.

La démarche de mise en conformité DORA sur le cloud, étape par étape

Une mise en conformité DORA ne se traite pas en un grand soir. Voici la trajectoire que cadrent les prestataires de notre réseau pour le volet cloud, en s'appuyant sur ce qui existe déjà dans votre organisation.

1. Cartographie des fonctions critiques ou importantes Identifier les fonctions dont la défaillance compromettrait l'activité, puis tracer les charges cloud qui les soutiennent. C'est le point d'entrée qui conditionne le niveau d'exigence appliqué à chaque prestation.
2. Diagnostic d'écart TIC et tiers Confronter votre cadre de gestion du risque TIC, vos contrats et votre supervision aux exigences DORA. Produire une matrice d'écarts priorisée. C'est l'objet d'un [audit de conformité cloud](/audit-conformite-cloud) ciblé.
3. Registre d'information Constituer et alimenter le registre normalisé des prestataires tiers de TIC, en distinguant ceux qui soutiennent des fonctions critiques.
4. Revue et amendement contractuel Vérifier la présence des clauses de l'article 30, négocier les addenda DORA (droit d'audit, notification, sortie, sous-traitance) avec les fournisseurs cloud et SaaS.
5. Renforcement de l'architecture de résilience Multi-région pour les fonctions critiques, sauvegardes immuables, journalisation inaltérable, le tout décrit en Infrastructure as Code pour la traçabilité et la réversibilité.
6. Stratégie de sortie testée Formaliser et, idéalement, éprouver la capacité de réversibilité : restitution des données, environnement cible, délais de transition.
7. Programme de tests et gouvernance d'incident Planifier les tests de résilience (jusqu'au TLPT si vous êtes une entité significative), outiller la détection et le circuit de notification en trois temps.

Budget, durée et livrables

Le coût de la préparation du volet cloud dépend surtout du nombre de fonctions critiques, du nombre de prestataires TIC à encadrer et de la maturité de départ. Les repères ci-dessous concernent l'accompagnement de cadrage et d'outillage du périmètre cloud, hors coûts récurrents d'exploitation et hors honoraires d'un éventuel testeur TLPT externe.

• 3 à 12 jpréparation du volet cloud (selon périmètre et maturité)
• 8 à 20 k€budget indicatif, sur devis selon le périmètre
• 5piliers à couvrir, du risque TIC au partage d'informations
• Registred'information des prestataires, alimenté par l'inventaire réel

Les livrables types d'un accompagnement DORA cloud : la cartographie des fonctions critiques et des charges cloud associées, la matrice d'écarts priorisée face aux cinq piliers, le registre d'information au format attendu, une trame d'addendum contractuel article 30, l'architecture de résilience cible documentée et versionnée en IaC, la stratégie de sortie formalisée, et le plan de tests avec le circuit de notification d'incident.

Notre rôle : intermédiaire indépendant

Pour aller plus loin, voyez nos services de cybersécurité cloud et de conseil en architecture, notre approche du secteur finance, le guide du cloud et l'ensemble de nos services.

FAQ : DORA dans le cloud

Qu'est-ce que le règlement DORA et depuis quand s'applique-t-il ?

DORA (Digital Operational Resilience Act), le règlement (UE) 2022/2554, est un texte européen d'application directe entré en vigueur le 17 janvier 2025. Il vise la résilience opérationnelle numérique du secteur financier et assurantiel : la capacité à résister, réagir et se rétablir face à toute perturbation grave liée aux technologies de l'information. Il repose sur cinq piliers et s'applique proportionnellement selon la taille et le profil de risque de l'entité.

Qui est concerné par DORA ?

Près d'une vingtaine de catégories d'entités financières : banques, établissements de paiement et de monnaie électronique, entreprises d'investissement, sociétés de gestion, assurances et réassurances, intermédiaires d'assurance, prestataires de services sur crypto-actifs, dépositaires centraux, plateformes de négociation, agences de notation, entre autres. Les prestataires tiers de TIC, dont les fournisseurs cloud, sont également concernés à travers le régime du risque tiers. En France, la supervision relève de l'ACPR et de l'AMF.

Quels sont les 5 piliers de DORA ?

Ils sont au nombre de cinq : la gestion du risque lié aux TIC (cadre gouverné et documenté) ; la gestion, la classification et la notification des incidents ; les tests de résilience opérationnelle numérique (jusqu'au TLPT) ; la gestion du risque lié aux prestataires tiers de TIC (clauses, registre, audit, sortie) ; et le partage d'informations sur les cybermenaces, sur base volontaire. Le pilier des tiers TIC est le plus structurant pour un usage du cloud.

Mon fournisseur cloud est-il concerné par DORA ?

Oui, en tant que prestataire tiers de services TIC. Dès qu'une fonction est portée par Azure, AWS ou un service tiers, votre fournisseur entre dans le champ du pilier « risque tiers ». Cela vous oblige à encadrer contractuellement la relation (clauses de l'article 30), à l'inscrire dans votre registre d'information, à disposer d'un droit d'audit et, pour les fonctions critiques, d'une stratégie de sortie. La responsabilité de conformité reste la vôtre, pas celle du fournisseur.

Qu'est-ce qu'un prestataire tiers de TIC critique au sens de DORA ?

C'est un prestataire jugé critique pour le système financier européen, désigné par les autorités européennes de surveillance (EBA, EIOPA, ESMA) et placé sous un cadre de supervision directe piloté par un superviseur principal. Les grands fournisseurs cloud sont des candidats naturels à cette désignation en raison de leur concentration systémique. Cette supervision porte sur le prestataire, elle ne vous décharge d'aucune de vos obligations individuelles.

Quelles clauses contractuelles DORA impose-t-il (article 30) ?

L'article 30 fixe un contenu minimal : description des services, localisation des données et notification de tout changement, protection des données, accès et restitution des données en fin de contrat, assistance en cas d'incident, coopération avec les autorités, droits de résiliation et préavis. Pour les fonctions critiques ou importantes s'ajoutent des niveaux de service détaillés, un droit d'audit sans restriction, la participation aux tests, les plans de secours et une stratégie de sortie. Un contrat cloud antérieur à 2025 doit souvent être amendé.

Qu'est-ce que le registre d'information DORA ?

C'est un recensement normalisé de tous vos accords contractuels avec des prestataires tiers de TIC. Il distingue les prestataires soutenant des fonctions critiques ou importantes, précise la nature des services, la localisation des données et les liens de sous-traitance. Les autorités peuvent le demander, et les autorités européennes l'exploitent pour identifier les concentrations et désigner les prestataires critiques. Il gagne à être alimenté depuis l'inventaire réel de vos ressources cloud plutôt que par un recensement manuel.

DORA impose-t-il une stratégie de sortie du cloud ?

Oui, pour toute prestation TIC soutenant une fonction critique ou importante. La stratégie de sortie doit garantir la capacité de quitter le prestataire, de récupérer ses données dans un format exploitable et de reprendre l'activité ailleurs sans interruption préjudiciable ni perte de conformité. Une clause théorique de restitution ne suffit pas : le régulateur attend une démarche démontrable, idéalement testée. Une architecture en Infrastructure as Code, des comptes à votre nom et une limitation des services propriétaires rendent cette sortie réelle.

Qu'est-ce que le TLPT et qui doit le réaliser ?

Le TLPT (Threat-Led Penetration Testing) est un test de pénétration fondé sur la menace, inspiré du cadre européen TIBER-EU, mené sur les systèmes réels de production qui soutiennent les fonctions critiques. Il ne concerne que les entités désignées comme significatives, à une fréquence de l'ordre d'une fois tous les trois ans, sous supervision d'une autorité. Lorsque des fonctions critiques s'exécutent sur le cloud, le périmètre peut inclure ces environnements, ce qui suppose de cadrer les règles d'engagement avec le fournisseur.

Comment notifier un incident majeur lié aux TIC sous DORA ?

Selon un calendrier en trois temps défini par les normes techniques : une notification initiale dans un délai court après la classification en incident majeur (de l'ordre de 24 heures après la prise de connaissance), un rapport intermédiaire (de l'ordre de 72 heures) et un rapport final (de l'ordre d'un mois) exposant la cause racine et les mesures correctives. Tenir ces délais suppose une journalisation centralisée et inaltérable ainsi qu'un runbook de réponse à incident prêt à l'emploi.

Quelle différence entre DORA et NIS2 ?

DORA est un règlement sectoriel (finance et assurance) d'application directe, centré sur la résilience opérationnelle numérique et le risque lié aux prestataires TIC. NIS2 est une directive transverse de cybersécurité, transposée en droit national, qui vise un large éventail de secteurs. Pour les entités financières, DORA prévaut comme texte spécial sur les obligations générales, tout en partageant l'esprit de NIS2. Les deux peuvent coexister dans un même groupe selon les activités.

DORA remplace-t-il le RGPD ?

Non. DORA traite la résilience opérationnelle, le RGPD protège les données personnelles ; ils s'appliquent en parallèle et ont des logiques de notification distinctes (violation de données personnelles à la CNIL sous 72 heures d'un côté, notification d'incident TIC à l'autorité financière de l'autre). Un bon socle de sécurité sert les deux, mais aucun ne dispense de l'autre. Le registre d'information DORA et le registre des traitements RGPD sont également distincts, même s'ils se recoupent.

Combien coûte une mise en conformité DORA sur le cloud ?

Pour la préparation du volet cloud (cartographie des fonctions critiques, matrice d'écarts, registre, trame contractuelle, architecture de résilience et plan de tests), le budget indicatif se situe généralement entre 8 000 et 20 000 €, pour une durée de 3 à 12 jours selon le périmètre et la maturité, sur devis après cadrage. S'y ajoutent les coûts récurrents d'exploitation cloud (réplication multi-région, stockage immuable) et les éventuels honoraires d'un testeur TLPT externe.

Faut-il un cloud souverain ou SecNumCloud pour être conforme DORA ?

Non, DORA n'impose pas de cloud souverain ni de qualification SecNumCloud. Il impose la maîtrise du risque tiers, une stratégie de sortie et une attention à la concentration. Pour la plupart des charges, Azure ou AWS bien configurés, encadrés par les clauses de l'article 30 et une réversibilité réelle, répondent aux exigences. Pour des fonctions particulièrement sensibles ou en cas de dépendance jugée excessive à un unique fournisseur, l'orientation vers une offre souveraine peut devenir un arbitrage par les risques, pas une obligation.

Vous êtes une entité financière et vous devez sécuriser votre conformité DORA sur Azure ou AWS ? Faites le point en quelques minutes avec notre diagnostic en ligne, ou échangez avec notre équipe : nous cadrons votre besoin et vous orientons vers des prestataires qualifiés. Réponse sous 48 h ouvrées.