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 jusqu'à la gestion des incidents et au reporting vers l'ACPR/AMF, avec des livrables vérifiables à chaque étape.
Nos clients types
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 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 : l'outillage. Les outils GRC (Gouvernance, Risque, Conformité) génériques couvrent souvent mal 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 vérifiables à chaque étape. Nous ne garantissons pas l'issue d'un contrôle : elle dépend aussi de ce que vous mettez en œuvre. Nous nous engageons sur la qualité et la traçabilité des livrables. Phase 1 : gap analysis DORA. La première intervention mesure 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 des fournisseurs tiers ICT (y compris SaaS, cloud, prestataires de maintenance), revue des politiques de gestion du risque ICT existantes, évaluation de la maturité en gestion des incidents (classification, notification, délais). À l'issue, un rapport structuré identifie les chantiers prioritaires, leur complexité technique et une feuille de route chiffrée. Le registre des tiers ICT révèle souvent des fournisseurs SaaS oubliés. Phase 2 : registre des tiers ICT et gestion des incidents. Mise en place des deux piliers les plus contrôlés. Registre des fournisseurs tiers ICT conforme à l'article 28 : structure de données imposée par les normes techniques de réglementation (RTS) publiées par les autorités européennes de surveillance, informations contractuelles, due diligence documentée pour chaque fournisseur, alertes sur les échéances de révision contractuelle. Gestion et reporting des incidents ICT (articles 17-23) : workflow de classification (mineur, majeur), génération des rapports de notification aux autorités au format des RTS, délais de notification paramétrés (4 h / 72 h / 1 mois), traçabilité complète pour les audits. Ces outils s'intègrent aux outils SIEM et ITSM existants (Splunk, Elastic, ServiceNow, Jira) via des API. Phase 3 : tests de résilience et TLPT. Organisation du programme de tests de résilience opérationnelle numérique : scénarios de défaillance ICT, simulations de basculement, tests de continuité 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 qualifié, prépare le rapport de renseignement sur la menace, assure le suivi des observations et la documentation des mesures correctives. Les résultats des tests alimentent le reporting. Phase 4 : cadre de gestion du risque ICT et tableaux de bord. Finalisation de la documentation réglementaire : politiques de gestion du risque ICT (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 de conformité pour deux audiences : la direction générale (incidents en cours, prochaines échéances) et les autorités de supervision (reporting structuré, exportable pour les contrôles). Formation des équipes IT et conformité aux procédures : classification des incidents, activation du plan de continuité, mise à jour du registre. Nous pouvons héberger les outils chez un hébergeur français, y compris qualifié SecNumCloud pour les clients financiers les plus exigeants. La conformité RGPD est traitée dès la conception. Pour les fintechs qui traitent des données de paiement, DSP2 et DORA sont traitées ensemble, pour éviter les doublons de processus.
5 piliers
Gestion du risque ICT, incidents, tests de résilience, risque tiers ICT, partage d'informations : le périmètre couvert par le programme
Article 28
Registre des fournisseurs tiers ICT conforme aux normes techniques de réglementation
4 h / 72 h / 1 mois
Délais de notification des incidents majeurs paramétrés dans le workflow (notification initiale, rapport intermédiaire, rapport final)
#Le problème : pourquoi la conformité DORA est un enjeu critique pour une fintech
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 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 : l'outillage. Les outils GRC (Gouvernance, Risque, Conformité) génériques couvrent souvent mal 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
Cartographier les systèmes et services ICT critiques, identifier les fournisseurs tiers ICT (article 28), évaluer les politiques de gestion du risque ICT existantes et mesurer l'écart avec les exigences DORA. À l'issue, un rapport structuré identifie les chantiers prioritaires, leur complexité technique et une feuille de route chiffrée.
Voir notre expertise : service Conformité Réglementaire Nehos.
#Phase 2 : Registre ICT et gestion des incidents
Mettre en place le registre des fournisseurs tiers conforme à l'article 28, configurer la gestion et le reporting des incidents ICT selon les articles 17-23 de DORA : classification, notification aux autorités aux délais prévus (4 h / 72 h / 1 mois), traçabilité pour les audits, intégration aux outils SIEM et ITSM existants.
Voir notre expertise : cas d'usage KYC / AML automatisé.
#Phase 3 : Tests de résilience et TLPT
Organiser les tests de résilience opérationnelle numérique, préparer les Threat-Led Penetration Tests (TLPT) pour les entités désignées par les autorités, et documenter les résultats pour la supervision.
Voir notre expertise : analyse DORA vs NIS2.
#Phase 4 : Tableaux de bord de conformité et documentation
Finaliser le cadre de gestion du risque ICT, déployer les tableaux de bord de conformité pour la direction et les autorités, former les équipes IT et mettre en place un plan de continuité opérationnel.
Voir notre expertise : définition DORA — Digital Operational Resilience Act.
#Ce que nous livrons et ce que nous mesurons
Nous ne promettons pas de résultat chiffré à l'avance. À chaque phase, nous remettons des livrables que vous pouvez montrer à un contrôleur : rapport de gap analysis, registre des tiers ICT, procédures et workflow de notification des incidents, comptes rendus de tests, tableaux de bord.
Ce que nous mesurons avec vous, c'est la couverture : part des fournisseurs et des systèmes critiques documentés dans le registre, délai de préparation d'une notification d'incident, et exercices de continuité réalisés et documentés.
#Exemple de situation : une fintech de paiement agréée
Exemple de situation, pas un client réel. Une fintech de paiement agréée par l'ACPR, avec une infrastructure hybride et une douzaine de SaaS métier, n'a ni registre ICT formalisé, ni procédure de gestion des incidents au format DORA, ni test de résilience récent. Un contrôle de l'autorité est annoncé.
Nous proposerions : une gap analysis qui recense les fournisseurs réellement utilisés et identifie les critiques ; la construction du registre de l'article 28 et des annexes contractuelles DORA ; le workflow de notification des incidents intégré à l'outil de ticketing ; la rédaction du cadre de gestion du risque ICT et un premier exercice de continuité documenté ; des tableaux de bord pour la direction et la préparation du dossier de réponse à l'autorité.
#Pourquoi Nehos pour la conformité DORA
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 cadrage qui pose les limites avant les promesses.
Notre méthode ROI-First impose un cadrage chiffré dès la phase d'audit : coût actuel documenté, gains attendus avec hypothèses prudentes, critères de go/no-go factuels. Nos expertises connexes : analyse DORA vs NIS2, définition DORA — Digital Operational Resilience Act.
Stack technique souverain : hébergement possible chez un hébergeur français, modèles IA open source (Mistral) quand la performance le permet, code intégralement détenu par le client à la livraison. Pas de dépendance à un fournisseur cloud américain pour vos données critiques.
#Pour aller plus loin
Cas d'usage connexes :
Questions & réponses
Questions fréquentes sur la conformité DORA pour les fintechs et établissements financiers
Le périmètre de DORA (Article 2 du règlement UE 2022/2554) couvre l'ensemble des entités financières réglementées dans l'Union européenne : établissements de crédit, établissements de paiement (EP), établissements de monnaie électronique (EME), entreprises d'investissement, compagnies d'assurance et de réassurance, institutions de retraite professionnelle, gestionnaires de fonds d'investissement alternatifs (GFIA), chambres de compensation, dépositaires centraux de titres, et prestataires de services sur crypto-actifs (PSCA) dès lors qu'ils sont agréés sous MiCA. Sont également couverts les prestataires tiers de services ICT jugés critiques par les Autorités européennes de surveillance (AES). Les fintechs détenant un agrément ACPR — établissement de paiement, de monnaie électronique, ou agrément CIF — sont pleinement dans le champ de DORA, sans exception de taille. Une fintech de 30 collaborateurs agréée EP est soumise aux mêmes obligations qu'une banque de réseau. Voir la liste des entités DORA sur EUR-Lex.
DORA est applicable depuis le 17 janvier 2025, sans délai supplémentaire. Il n'existe pas de période de tolérance officielle. Les sanctions et mesures de supervision sont fixées par les autorités compétentes de chaque État membre (en France, l'ACPR et l'AMF) et peuvent aller d'injonctions de mise en conformité à des restrictions d'activité, avec publication possible de la décision. Au-delà des sanctions, le vrai risque est de découvrir lors d'un contrôle que le registre ICT est incomplet ou que les incidents ne sont pas notifiés dans les délais. Pour le texte exact des sanctions applicables à votre entité, référez-vous au règlement et à votre autorité de supervision : règlement (UE) 2022/2554 sur EUR-Lex.
DORA et NIS2 (directive NIS 2) s'adressent à des périmètres qui se chevauchent partiellement, mais avec des logiques distinctes. NIS2 s'applique aux entités essentielles et importantes dans des secteurs critiques — dont les établissements financiers font partie. DORA est un règlement sectoriel financier qui, par le principe de lex specialis, prime sur NIS2 pour les entités financières : les établissements de crédit, les établissements de paiement, les compagnies d'assurance et autres entités DORA répondent à DORA pour les obligations qui y sont couvertes, et non à NIS2. En pratique, les exigences DORA sont généralement plus détaillées et plus contraignantes que NIS2 sur les domaines qu'il couvre. Une entité financière conforme DORA sera mécaniquement conforme NIS2 sur les domaines couverts. En revanche, certaines fintechs appartenant à des groupes opérant dans plusieurs secteurs peuvent avoir des filiales soumises à NIS2 en dehors du périmètre financier. Nehos traite la conformité DORA et NIS2 conjointement pour éviter les doublons de processus et les lacunes de couverture. Voir notre analyse DORA vs NIS2.
Non — les TLPT ne sont pas obligatoires pour toutes les entités financières soumises à DORA. Selon l'Article 26 de DORA, les TLPT sont imposés aux entités désignées par les autorités nationales compétentes (ACPR et AMF pour la France) sur la base de critères de proportionnalité : taille, profil de risque systémique, nature des activités. En pratique, les TLPT obligatoires concernent principalement les grandes banques systémiques (SIFI), les grandes compagnies d'assurance et les chambres de compensation. Pour les fintechs de taille intermédiaire, les TLPT ne sont généralement pas imposés d'emblée, mais les entités doivent néanmoins mettre en place un programme de tests de résilience opérationnelle (tests de pénétration classiques, simulations de scénarios de défaillance, tests de continuité) documenté et auditable. Si votre entité est contactée par l'ACPR pour des TLPT, Nehos coordonne l'engagement avec un prestataire TIBER-EU qualifié. Voir le framework TIBER-EU de la Banque de France.
C'est l'un des chantiers les plus sous-estimés de DORA. Le pilier 'risque tiers ICT' (Articles 28-44) impose des obligations substantielles vis-à-vis de tous vos fournisseurs de services ICT — pas seulement les plus critiques. (1) Registre complet (Article 28) : vous devez tenir et mettre à jour un registre de l'ensemble de vos arrangements contractuels avec des fournisseurs tiers ICT, avec les informations spécifiées dans les RTS publiés par les AES (nature du service, criticité, localisation des données, etc.). Ce registre doit être communiqué annuellement à votre autorité compétente. (2) Due diligence renforcée pour les fournisseurs critiques : évaluation de leur propre résilience opérationnelle, droit d'audit contractuellement prévu, clauses de résiliation et de sortie documentées. (3) Clauses contractuelles obligatoires : les contrats avec les fournisseurs ICT doivent inclure des dispositions spécifiques listées à l'Article 30 (niveaux de service, coopération en cas d'incident, audit, sous-traitance, localisation des données). En pratique, pour une fintech utilisant AWS, Azure, Stripe, des éditeurs SaaS KYC ou monitoring fraude, le travail contractuel représente plusieurs semaines de chantier. Nehos intègre ce volet dès la phase 2 du programme DORA.
Un programme DORA démarre à 15 000 € HT. Le budget total dépend de la complexité de votre écosystème ICT : nombre de fournisseurs tiers, maturité des pratiques existantes, périmètre des tests. Nous établissons un devis sur mesure, chiffré en 48 h après un premier échange, à partir des résultats de la gap analysis. Si vous voulez d'abord savoir où vous en êtes, notre audit approfondi (5 jours) coûte 2 125 € HT. Il est utile de comparer ces montants avec le coût d'une non-conformité constatée lors d'un contrôle.