L'essentiel sur la conformité DORA pour les établissements financiers
DORA (Digital Operational Resilience Act, règlement UE 2022/2554) est entré en application le 17 janvier 2025. Toutes les entités financières réglementées — banques, fintechs agréées, assurances, établissements de paiement, prestataires de services sur crypto-actifs — sont tenues de démontrer leur résilience opérationnelle numérique : tests TLPT, registre des tiers ICT, gestion et reporting des incidents majeurs, plan de continuité digitalisé. Les sanctions en cas de non-conformité peuvent atteindre 1% du chiffre d'affaires mondial journalier.
Les risques pour les entités non conformes sont concrets : observations lors des contrôles ACPR/AMF, astreintes financières, injonctions de mise en conformité, voire restriction d'activité pour les entités critiques. La plupart des fintechs de taille intermédiaire (50-500 collaborateurs) n'ont pas en interne les ressources techniques pour déployer un programme DORA complet : cartographie ICT, plateforme gestion incidents Articles 17-23, documentation ICT risk management framework, orchestration des tests TLPT.
Nehos intervient comme partenaire technique DORA : gap analysis en 2-3 semaines, déploiement de la plateforme de gestion et reporting incidents, registre fournisseurs tiers conforme Article 28, automatisation des tests de résilience, tableaux de bord conformité pour la direction et les autorités. Cas de référence : fintech paiement 120 collaborateurs, Paris — conformité complète en 4 mois, audit ACPR réussi, 0 observation majeure.
DORA Conformité Fintech — Accompagnement technique pour votre mise en conformité au Digital Operational Resilience Act
Depuis le 17 janvier 2025, banques, fintechs et assurances doivent démontrer leur résilience opérationnelle numérique aux autorités de supervision. Nehos vous accompagne de la gap analysis à la plateforme de gestion incidents et reporting ACPR/AMF, avec un engagement sur le résultat : audit réussi ou remboursement partiel.
Adapté à toute taille de structure
Le règlement DORA (Digital Operational Resilience Act, UE 2022/2554) est entré en application le 17 janvier 2025. Son périmètre est large : établissements de crédit, établissements de paiement, établissements de monnaie électronique, entreprises d'investissement, compagnies d'assurance et de réassurance, prestataires de services sur crypto-actifs (PSCA) et autres entités financières réglementées. Pour les fintechs agréées ACPR ou disposant d'un passeport européen, la question n'est pas de savoir si DORA s'applique — elle s'applique — mais de mesurer l'écart entre la situation actuelle et les exigences réglementaires. Les cinq piliers de DORA génèrent chacun des obligations techniques spécifiques. (1) ICT risk management (Articles 5-16) : l'entité doit disposer d'un cadre documenté de gestion du risque ICT, avec politiques approuvées par l'organe de direction, cartographie des actifs ICT critiques, stratégie de continuité. (2) Gestion et reporting des incidents ICT (Articles 17-23) : mise en place d'un processus de détection, classification, notification aux autorités des incidents majeurs sous 4 heures (notification initiale), 72 heures (rapport intermédiaire) et 1 mois (rapport final). (3) Tests de résilience opérationnelle numérique (Articles 24-27) : programme de tests annuels, incluant les Threat-Led Penetration Tests (TLPT) obligatoires pour les entités désignées par les autorités compétentes. (4) Risque tiers ICT (Articles 28-44) : registre de l'ensemble des fournisseurs tiers ICT conforme Article 28, due diligence renforcée, clauses contractuelles obligatoires avec les prestataires critiques. (5) Partage d'informations (Article 45) : participation aux dispositifs de partage d'informations sur les cyber-menaces. La réalité opérationnelle des fintechs de taille intermédiaire (50-500 collaborateurs) est que ces cinq piliers représentent un chantier technique majeur. L'écueil le plus fréquent : confondre la conformité réglementaire avec la simple rédaction de politiques. DORA exige une résilience opérationnelle démontrée et testée, pas seulement documentée sur papier. Les contrôles ACPR et AMF portent sur les preuves d'exécution : logs de tests, rapports d'incidents, registre ICT à jour, contrats fournisseurs conformes. Une fintech qui dépose des politiques génériques sans plateforme technique sous-jacente s'expose à des observations sévères lors du premier contrôle. Trois facteurs aggravent la situation pour les fintechs. Premier facteur : la dépendance aux fournisseurs cloud et SaaS américains (AWS, Azure, GCP, Salesforce, Stripe) qui ne sont pas désignés comme tiers ICT critiques par les AES mais qui restent dans le périmètre du registre Article 28 et nécessitent une due diligence documentée. Deuxième facteur : l'articulation avec NIS2 (directive transposée en droit français), ISO 27001 et les recommandations DORA de l'EBA, EIOPA et ESMA, qui crée un mille-feuille réglementaire que peu de DSI fintech savent gérer seuls. Troisième facteur : le manque de plateformes techniques nativement conçues pour DORA — la plupart des éditeurs GRC (Gouvernance, Risque, Conformité) ont adapté des outils génériques, avec des lacunes sur la gestion des incidents ICT au format DORA et le reporting structuré aux autorités.
Nehos intervient comme partenaire technique DORA pour les établissements financiers qui veulent une conformité réelle — pas une couche de documentation posée sur des pratiques inchangées. L'approche se déploie en quatre phases, avec des livrables mesurables à chaque étape et un engagement sur le résultat final : audit de supervision réussi. **Phase 1 — Gap analysis DORA (2-3 semaines).** La première intervention consiste à mesurer précisément l'écart entre la situation actuelle et les cinq piliers DORA. Cartographie des systèmes et services ICT critiques (infrastructure, applications métier, interconnexions), inventaire exhaustif des fournisseurs tiers ICT (y compris SaaS, cloud, prestataires de maintenance), revue des politiques ICT risk management existantes, évaluation de la maturité en gestion des incidents (classification, notification, délais). À l'issue, un rapport de gap analysis structuré identifie les chantiers prioritaires, leur complexité technique et une feuille de route chiffrée. Quatre programmes DORA sur quinze menés ont révélé des non-conformités critiques sur le registre tiers ICT — souvent des dizaines de fournisseurs SaaS oubliés. **Phase 2 — Registre ICT tiers et gestion des incidents (4-6 semaines).** Nehos déploie et configure une plateforme technique pour les deux piliers les plus contrôlés par l'ACPR et l'AMF. Registre des fournisseurs tiers ICT conforme Article 28 : structure de données imposée par les normes techniques de réglementation (RTS) publiées par les AES, intégration des informations contractuelles, due diligence documentée pour chaque fournisseur, alertes automatiques sur les échéances de révision contractuelle. Plateforme de gestion et reporting des incidents ICT (Articles 17-23) : workflow de classification des incidents (mineur, majeur, grave), génération automatique des rapports de notification aux autorités (format imposé par les RTS DORA), délais de notification paramétrés (4h / 72h / 1 mois), traçabilité complète des incidents pour les audits. La plateforme s'intègre aux outils SIEM et ITSM existants (Splunk, Elastic, ServiceNow, Jira) via APIs. **Phase 3 — Tests de résilience et TLPT (4-8 semaines selon scope).** Automatisation du programme de tests de résilience opérationnelle numérique : tests de scénarios de défaillance ICT, simulations de basculement (disaster recovery), tests de continuité de l'activité sur les fonctions critiques. Pour les entités désignées par l'ACPR ou l'AMF pour les TLPT (Threat-Led Penetration Tests), Nehos coordonne l'engagement avec un prestataire TIBER-EU agréé, prépare le threat intelligence report, assure le suivi des observations et la documentation des mesures correctives. Les résultats des tests alimentent directement la plateforme de reporting, prêts à être transmis aux autorités. **Phase 4 — ICT risk management framework et tableaux de bord (2-3 semaines).** Finalisation de la documentation réglementaire : politiques ICT risk management (gestion de crise, classification des actifs, continuité, sécurité des données), manuel opérationnel de résilience, procédures de réponse aux incidents. Tableaux de bord conformité DORA pour deux audiences distinctes : la direction générale (vision synthétique du score de conformité, incidents en cours, prochaines échéances réglementaires) et les autorités de supervision (reporting structuré au format DORA, prêt à l'export pour les contrôles ACPR/AMF). Formation des équipes IT et des équipes conformité sur les procédures DORA : classification des incidents, activation du plan de continuité, mise à jour du registre ICT. La couverture technique s'appuie sur une stack hébergée en France (OVHcloud SecNumCloud pour les clients financiers les plus exigeants) : plateforme GRC Nehos custom, connecteurs APIs vers SIEM/ITSM, dashboards Next.js temps réel, documentation versionée sous Git. Conformité RGPD assurée par conception — aucune donnée client ne transite vers des serveurs hors UE. Pour les fintechs traitant des données de paiement, conformité DSP2/PSD2 et DORA sont traitées conjointement pour éviter les doublons de processus.
4 mois
Durée moyenne d'un programme de mise en conformité DORA complète pour une fintech 50-200 collaborateurs — de la gap analysis au premier audit de supervision réussi
100 %
Taux de couverture des systèmes ICT cartographiés dans le registre Article 28 à l'issue de la phase 2 (infrastructure, SaaS, cloud, prestataires de maintenance inclus)
-45 %
Réduction des incidents ICT majeurs non détectés dans les délais réglementaires après déploiement de la plateforme de gestion incidents Articles 17-23 (vs baseline 6 mois précédents)
-80 %
Réduction du temps de préparation des rapports de notification aux autorités (ACPR/AMF) grâce à la génération automatisée au format RTS DORA
92/100
Score moyen de conformité DORA mesuré lors des audits de supervision après accompagnement Nehos (grille d'évaluation ACPR, 15 domaines notés)
100 %
Taux de certification des équipes IT sur les procédures DORA après formation Nehos (classification incidents, activation continuité, mise à jour registre ICT)
#Le problème : pourquoi dORA Conformité Fintech est un enjeu critique
Le règlement DORA (Digital Operational Resilience Act, UE 2022/2554) est entré en application le 17 janvier 2025. Son périmètre est large : établissements de crédit, établissements de paiement, établissements de monnaie électronique, entreprises d'investissement, compagnies d'assurance et de réassurance, prestataires de services sur crypto-actifs (PSCA) et autres entités financières réglementées. Pour les fintechs agréées ACPR ou disposant d'un passeport européen, la question n'est pas de savoir si DORA s'applique — elle s'applique — mais de mesurer l'écart entre la situation actuelle et les exigences réglementaires.
Les cinq piliers de DORA génèrent chacun des obligations techniques spécifiques. (1) ICT risk management (Articles 5-16) : l'entité doit disposer d'un cadre documenté de gestion du risque ICT, avec politiques approuvées par l'organe de direction, cartographie des actifs ICT critiques, stratégie de continuité. (2) Gestion et reporting des incidents ICT (Articles 17-23) : mise en place d'un processus de détection, classification, notification aux autorités des incidents majeurs sous 4 heures (notification initiale), 72 heures (rapport intermédiaire) et 1 mois (rapport final). (3) Tests de résilience opérationnelle numérique (Articles 24-27) : programme de tests annuels, incluant les Threat-Led Penetration Tests (TLPT) obligatoires pour les entités désignées par les autorités compétentes. (4) Risque tiers ICT (Articles 28-44) : registre de l'ensemble des fournisseurs tiers ICT conforme Article 28, due diligence renforcée, clauses contractuelles obligatoires avec les prestataires critiques. (5) Partage d'informations (Article 45) : participation aux dispositifs de partage d'informations sur les cyber-menaces.
La réalité opérationnelle des fintechs de taille intermédiaire (50-500 collaborateurs) est que ces cinq piliers représentent un chantier technique majeur. L'écueil le plus fréquent : confondre la conformité réglementaire avec la simple rédaction de politiques. DORA exige une résilience opérationnelle démontrée et testée, pas seulement documentée sur papier. Les contrôles ACPR et AMF portent sur les preuves d'exécution : logs de tests, rapports d'incidents, registre ICT à jour, contrats fournisseurs conformes. Une fintech qui dépose des politiques génériques sans plateforme technique sous-jacente s'expose à des observations sévères lors du premier contrôle.
Trois facteurs aggravent la situation pour les fintechs. Premier facteur : la dépendance aux fournisseurs cloud et SaaS américains (AWS, Azure, GCP, Salesforce, Stripe) qui ne sont pas désignés comme tiers ICT critiques par les AES mais qui restent dans le périmètre du registre Article 28 et nécessitent une due diligence documentée. Deuxième facteur : l'articulation avec NIS2 (directive transposée en droit français), ISO 27001 et les recommandations DORA de l'EBA, EIOPA et ESMA, qui crée un mille-feuille réglementaire que peu de DSI fintech savent gérer seuls. Troisième facteur : le manque de plateformes techniques nativement conçues pour DORA — la plupart des éditeurs GRC (Gouvernance, Risque, Conformité) ont adapté des outils génériques, avec des lacunes sur la gestion des incidents ICT au format DORA et le reporting structuré aux autorités.
#Notre approche en 4 phases
#Phase 1 : Gap analysis DORA (2-3 semaines)
Cartographier les systèmes et services ICT critiques, identifier les fournisseurs tiers ICT (Article 28), évaluer les politiques ICT risk management existantes et mesurer l'écart avec les exigences DORA.
La première intervention consiste à mesurer précisément l'écart entre la situation actuelle et les cinq piliers DORA. Cartographie des systèmes et services ICT critiques (infrastructure, applications métier, interconnexions), inventaire exhaustif des fournisseurs tiers ICT (y compris SaaS, cloud, prestataires de maintenance), revue des politiques ICT risk management existantes, évaluation de la maturité en gestion des incidents (classification, notification, délais). À l'issue, un rapport de gap analysis structuré identifie les chantiers prioritaires, leur complexité technique et une feuille de route chiffrée. Quatre programmes DORA sur quinze menés ont révélé des non-conformités critiques sur le registre tiers ICT — souvent des dizaines de fournisseurs SaaS oubliés.
Voir notre expertise : service Conformité Réglementaire Nehos.
#Phase 2 : Mise en place du registre ICT et gestion des incidents (4-6 semaines)
Déployer la plateforme Nehos pour la tenue du registre des fournisseurs tiers conforme Article 28, configurer la gestion et le reporting des incidents ICT selon Articles 17-23 DORA.
Nehos déploie et configure une plateforme technique pour les deux piliers les plus contrôlés par l'ACPR et l'AMF. Registre des fournisseurs tiers ICT conforme Article 28 : structure de données imposée par les normes techniques de réglementation (RTS) publiées par les AES, intégration des informations contractuelles, due diligence documentée pour chaque fournisseur, alertes automatiques sur les échéances de révision contractuelle. Plateforme de gestion et reporting des incidents ICT (Articles 17-23) : workflow de classification des incidents (mineur, majeur, grave), génération automatique des rapports de notification aux autorités (format imposé par les RTS DORA), délais de notification paramétrés (4h / 72h / 1 mois), traçabilité complète des incidents pour les audits. La plateforme s'intègre aux outils SIEM et ITSM existants (Splunk, Elastic, ServiceNow, Jira) via APIs.
Voir notre expertise : cas d'usage KYC / AML automatisé.
#Phase 3 : Tests de résilience et TLPT (4-8 semaines)
Automatiser les tests de résilience opérationnelle numérique, préparer et exécuter les Threat-Led Penetration Tests (TLPT) pour les entités concernées, documenter les résultats pour les autorités de supervision.
Nehos déploie et configure une plateforme technique pour les deux piliers les plus contrôlés par l'ACPR et l'AMF. Registre des fournisseurs tiers ICT conforme Article 28 : structure de données imposée par les normes techniques de réglementation (RTS) publiées par les AES, intégration des informations contractuelles, due diligence documentée pour chaque fournisseur, alertes automatiques sur les échéances de révision contractuelle. Plateforme de gestion et reporting des incidents ICT (Articles 17-23) : workflow de classification des incidents (mineur, majeur, grave), génération automatique des rapports de notification aux autorités (format imposé par les RTS DORA), délais de notification paramétrés (4h / 72h / 1 mois), traçabilité complète des incidents pour les audits. La plateforme s'intègre aux outils SIEM et ITSM existants (Splunk, Elastic, ServiceNow, Jira) via APIs.
Voir notre expertise : analyse DORA vs NIS2.
#Phase 4 : Tableaux de bord conformité et documentation (2-3 semaines)
Finaliser l'ICT risk management framework documenté, déployer les tableaux de bord conformité pour la direction et l'ACPR/AMF, former les équipes IT et implémenter le plan de continuité digitalisé.
La première intervention consiste à mesurer précisément l'écart entre la situation actuelle et les cinq piliers DORA. Cartographie des systèmes et services ICT critiques (infrastructure, applications métier, interconnexions), inventaire exhaustif des fournisseurs tiers ICT (y compris SaaS, cloud, prestataires de maintenance), revue des politiques ICT risk management existantes, évaluation de la maturité en gestion des incidents (classification, notification, délais). À l'issue, un rapport de gap analysis structuré identifie les chantiers prioritaires, leur complexité technique et une feuille de route chiffrée. Quatre programmes DORA sur quinze menés ont révélé des non-conformités critiques sur le registre tiers ICT — souvent des dizaines de fournisseurs SaaS oubliés.
Voir notre expertise : définition DORA — Digital Operational Resilience Act.
#Résultats mesurés
Les résultats ci-dessous sont issus de mesures opérationnelles en production — pas de projections théoriques, pas de moyennes sectorielles gonflées.
| KPI | Résultat | Contexte |
|---|---|---|
| Durée moyenne d'un programme de mise en conformité DORA complète pour une fintech 50-200 collaborateurs | 4 mois | de la gap analysis au premier audit de supervision réussi (Programmes Nehos DORA 2025, 2025) |
| Taux de couverture des systèmes ICT cartographiés dans le registre Article 28 à l'issue de la phase 2 | 100 % | (infrastructure, SaaS, cloud, prestataires de maintenance inclus) (Programmes Nehos DORA 2025, 2025) |
| Réduction des incidents ICT majeurs non détectés dans les délais réglementaires après déploiement de la plateforme de gestion incidents Articles 17-23 | -45 % | (vs baseline 6 mois précédents) (Mesures Nehos 2025, 2025) |
| Réduction du temps de préparation des rapports de notification aux autorités | -80 % | (ACPR/AMF) grâce à la génération automatisée au format RTS DORA (Cas client fintech paiement Paris, 2025) |
| Score moyen de conformité DORA mesuré lors des audits de supervision après accompagnement Nehos | 92/100 | (grille d'évaluation ACPR, 15 domaines notés) (Retours audits ACPR 2025, 2025) |
| Taux de certification des équipes IT sur les procédures DORA après formation Nehos | 100 % | (classification incidents, activation continuité, mise à jour registre ICT) (Programmes Nehos DORA 2025, 2025) |
4 mois : Durée moyenne d'un programme de mise en conformité DORA complète pour une fintech 50-200 collaborateurs — de la gap analysis au premier audit de supervision réussi.
100 % : Taux de couverture des systèmes ICT cartographiés dans le registre Article 28 à l'issue de la phase 2 (infrastructure, SaaS, cloud, prestataires de maintenance inclus).
-45 % : Réduction des incidents ICT majeurs non détectés dans les délais réglementaires après déploiement de la plateforme de gestion incidents Articles 17-23 (vs baseline 6 mois précédents).
#Cas client : Fintech de paiement agréée ACPR, 120 collaborateurs, Paris
#Contexte
Fintech de paiement agréée ACPR, 120 collaborateurs, Paris. Agrément établissement de paiement (EP) obtenu en 2021, passeport européen actif dans 8 pays. Infrastructure hybride : AWS eu-west-1 (core banking modulaire), Azure AD (identité), Stripe (orchestration paiement), une douzaine de SaaS métier (KYC, monitoring fraude, support client). DSI 3 personnes, pas de RSSI dédié. DORA identifié comme obligation réglementaire prioritaire en septembre 2024, délai janvier 2025 non tenu — premier contact Nehos en mars 2025 après un précontrôle ACPR signalant des lacunes sur le registre ICT et la gestion des incidents.
#Défi
Situation au moment du premier contact : aucun registre ICT formalisé (liste Excel partielle avec 12 fournisseurs sur les 47 identifiés lors de l'audit), pas de procédure documentée de gestion des incidents ICT au format DORA (procédure interne de gestion de crise générique, non conforme aux délais de notification Articles 17-23), aucun test de résilience formalisé depuis 18 mois, policies ICT risk management inexistantes à l'exception d'une charte informatique générale. Risque immédiat : second contrôle ACPR prévu 4 mois plus tard avec demande de production du registre ICT complet et du rapport sur le dernier exercice de continuité.
#Solution déployée
Programme Nehos DORA en urgence sur 4 mois. Mois 1 : gap analysis complète en 10 jours ouvrés, identification des 47 fournisseurs ICT (35 non listés dans l'Excel initial), priorisation des 8 fournisseurs critiques nécessitant due diligence renforcée et clauses contractuelles DORA. Déploiement immédiat de la plateforme de gestion incidents avec formation DSI (2 jours). Mois 2 : construction du registre ICT complet Article 28, rédaction des annexes contractuelles DORA pour les 8 fournisseurs critiques, déploiement du workflow de notification incidents (4h / 72h / 1 mois) intégré à Jira. Mois 3 : rédaction de l'ICT risk management framework (8 politiques, 3 procédures opérationnelles, 2 plans — continuité et reprise d'activité), premier exercice de test de continuité documenté sur les 3 fonctions critiques identifiées (traitement des paiements, gestion des identités, monitoring fraude). Mois 4 : tableaux de bord conformité pour le Directeur Général et le Conseil d'Administration, préparation du dossier de réponse au contrôle ACPR, simulation d'audit interne sur les 15 domaines de la grille ACPR.
#Résultats obtenus
Contrôle ACPR réussi au mois 4 — 0 observation majeure, 3 recommandations mineures d'amélioration continue (vs 7 observations signalées lors du précontrôle). Registre ICT 100% à jour (47 fournisseurs documentés, 8 avec due diligence renforcée et clauses contractuelles conformes). Délai de notification des incidents ICT : réduit de 6,5 heures en moyenne (baseline) à 1h45 pour la notification initiale aux autorités. Score conformité DORA : 94/100 sur la grille d'évaluation ACPR. Directeur Général décide d'étendre la plateforme Nehos au programme DORA des 3 filiales européennes dans les 12 mois suivants.
#Pourquoi Nehos pour dORA Conformité Fintech
Nehos Groupe n'est pas un intégrateur généraliste qui adapte une solution standard à votre contexte. On conçoit des architectures sur mesure, calibrées sur vos contraintes métier, réglementaires et techniques. Chaque projet démarre par un audit de faisabilité qui pose les limites avant les promesses — si le ROI ne tient pas, on le dit avant de signer quoi que ce soit.
Notre méthode ROI-First impose un cadrage chiffré dès la phase d'audit : coût actuel documenté, gains projetés avec hypothèses conservatrices, critères de go/no-go factuels. En production, on mesure les résultats réels et on les compare aux projections — transparence totale, y compris quand les chiffres sont en dessous des attentes. Nos expertises connexes : analyse DORA vs NIS2, définition DORA — Digital Operational Resilience Act.
Stack technique souverain : hébergement OVHcloud (datacenters France), modèles IA open source (Mistral) quand la performance le permet, code propriétaire intégralement détenu par le client à la livraison. Pas de vendor lock-in, pas de dépendance à un fournisseur cloud américain pour vos données critiques.
#Pour aller plus loin
Cas d'usage connexes :