Guide DORA fintech 2026 : la checklist conformité ACPR en 25 points actionables

#Chapitre 1 — DORA : cadre réglementaire et calendrier

Le Règlement (UE) 2022/2554, dit DORA pour Digital Operational Resilience Act, a été publié au Journal officiel de l'Union européenne le 27 décembre 2022 et est entré en application le 17 janvier 2025. C'est le premier corpus européen uniforme et directement applicable consacré à la résilience opérationnelle numérique du secteur financier. Là où la directive NIS2 organise la cybersécurité de manière sectoriellement transverse, DORA s'impose comme lex specialis pour la finance : si une obligation se chevauche, c'est DORA qui prévaut pour les entités financières.

#Cible et périmètre d'application

L'article 2 du Règlement liste 20 catégories d'entités concernées. En pratique, le périmètre englobe : les établissements de crédit (banques), les établissements de paiement et de monnaie électronique (dont les fintechs AISP, PISP, EMI), les entreprises d'investissement, les contreparties centrales, les dépositaires centraux de titres, les plateformes de négociation, les référentiels centraux de transactions, les agences de notation, les administrateurs d'indices de référence critiques, les prestataires de services sur crypto-actifs (depuis MiCA), les fonds de pension professionnels, les entreprises d'assurance et de réassurance, les intermédiaires d'assurance, les sociétés de gestion d'OPCVM et de FIA. L'EBA, l'EIOPA et l'ESMA estiment ensemble à 22 000+ le nombre d'entités directement concernées dans l'Union européenne. S'y ajoutent les fournisseurs IT tiers critiques qui, depuis 2025, peuvent être désignés CTPP (Critical Third-Party Provider) et placés sous supervision directe européenne.

#Articulation avec NIS2, RGPD, AI Act et FIDA

DORA s'inscrit dans une mosaïque réglementaire dense. Quatre points clés. Premier : NIS2 (Directive UE 2022/2555, transposée en France octobre 2024) couvre la cybersécurité des entités essentielles et importantes — pour le secteur financier, DORA prime en tant que lex specialis sur les sujets résilience IT, gestion des incidents et tests, mais les exigences de gouvernance NIS2 restent applicables sur les volets non couverts par DORA. Deuxième : RGPD reste pleinement applicable sur la protection des données personnelles, complémentairement à DORA — un incident DORA touchant des données personnelles cumule notification CNIL 72h et notification ACPR 24h. Troisième : AI Act articule avec DORA via les fournisseurs IA tiers critiques d'une banque, qui relèvent simultanément du registre Article 28 DORA et du registre AI Act article 9 quand le système IA est haut risque. Quatrième : FIDA (Financial Data Access Regulation, finalisée 2026) ajoute des obligations sur l'utilisation et le partage des données financières, partiellement adossées au socle gouvernance DORA.

#Calendrier d'application et Regulatory Technical Standards

DORA est en application pleine depuis le 17 janvier 2025. Trois ensembles de Regulatory Technical Standards (RTS) ont été publiés par les autorités européennes EBA, EIOPA et ESMA entre 2023 et 2025, totalisant plus de 50 standards techniques détaillant les modalités d'application. Premier paquet (juillet 2024) : politique de gestion des risques IT, modèle de registre des tiers, classification des incidents. Deuxième paquet (novembre 2024) : conditions de sous-traitance fournisseurs IT critiques, contenu détaillé de la notification d'incident majeur, accord coordonné de notification entre autorités. Troisième paquet (mars 2025) : harmonisation TLPT (Threat-Led Penetration Testing), exigences supervisorientielles CTPP, formats de reporting standardisés.

Pour aller plus loin sur le périmètre et les définitions, voir la définition DORA complète dans le glossaire Nehos et le service Audit DORA dédié.

#Chapitre 2 — Les 5 piliers DORA

Le Règlement structure les obligations en cinq piliers techniques et organisationnels qui couvrent l'intégralité du cycle de vie de la résilience opérationnelle numérique d'une entité financière.

#Pilier 1 — Gouvernance et gestion des risques IT (articles 5 à 16)

C'est le socle. L'article 5 place la responsabilité formelle sur l'organe de direction (management body) de l'entité : conseil d'administration ou équivalent. La gouvernance ne peut pas être déléguée intégralement à la DSI ou au RSSI. Concrètement, le board doit approuver et réviser au moins une fois par an la stratégie de résilience opérationnelle numérique, le cadre de gestion des risques IT, le plan de continuité d'activité (BCP) et le plan de reprise après sinistre (DRP). L'article 6 impose un cadre de gestion des risques IT documenté, intégré au cadre global de gestion des risques de l'entité, proportionné à sa taille et à son profil. Pour une fintech série B avec 100-200 collaborateurs, cela signifie typiquement : politique de sécurité IT formelle (15-25 pages), cartographie des actifs informationnels, analyse des risques annuelle, plan d'investissement résilience, comité IT mensuel, reporting trimestriel au board.

#Pilier 2 — Gestion des incidents IT (articles 17 à 23)

DORA impose une chaîne complète de traitement des incidents IT et de gestion des cyberattaques. L'article 17 demande un processus de gestion des incidents IT formel : détection, classification, réponse, escalade, communication interne et externe, capitalisation post-mortem. L'article 18 détaille les critères de classification d'un incident comme « majeur », qui déclenche l'obligation de notification : nombre d'utilisateurs impactés (> 25 % de la base ou > 10 % en B2B critique), durée d'indisponibilité (> 2 heures pour services critiques), impact géographique multi-juridiction, perte économique (> 10 % du budget IT annuel), impact réputationnel. Les articles 19 à 23 fixent les modalités précises de notification aux autorités compétentes : initial 24h, intérim 72h, final 1 mois (détail au chapitre 6).

#Pilier 3 — Tests de résilience opérationnelle (articles 24 à 27)

DORA impose un programme de tests régulier, proportionné. L'article 24 demande un programme annuel : tests de vulnérabilité, analyse open source, scans réseau, tests de continuité, tests basés sur des scénarios, revues de sécurité physique, end-to-end tests. L'article 25 introduit les tests TLPT (Threat-Led Penetration Testing) obligatoires pour les entités significatives, méthodologie inspirée du framework TIBER-EU. Fréquence : au moins une fois tous les trois ans. Pour une fintech série A ou B early-stage, le TLPT n'est généralement pas obligatoire — les seuils combinent typiquement chiffre d'affaires > 30 M€, effectif > 150 collaborateurs en activité financière, et importance systémique évaluée par l'ACPR. Mais la conduite de tests pen-testing et red team annuels reste obligatoire dans tous les cas.

#Pilier 4 — Gestion des risques tiers critiques (articles 28 à 44)

C'est probablement le pilier le plus structurant — et le plus chronophage. L'article 28 impose un registre exhaustif de tous les contrats de prestation de services TIC : identification de chaque fournisseur, nature des services, fonctions critiques ou importantes supportées, localisation des données, dépendances en cascade (sous-traitants des sous-traitants), substituabilité, plan d'exit. L'article 30 fixe le contenu obligatoire des contrats : description claire des services, niveaux de service mesurables, localisation et traitement des données, accès aux données et systèmes en cas d'audit, droits de résiliation, plans d'exit, clauses de continuité. Pour les fournisseurs supportant des fonctions critiques, des clauses additionnelles renforcées s'appliquent : audit on-site par l'entité financière et l'autorité compétente, cooperation incident response, droit de résiliation élargi.

#Pilier 5 — Partage d'informations sur les cybermenaces (article 45)

C'est le pilier le plus souple. L'article 45 encourage — sans obliger — les entités financières à participer à des dispositifs de partage d'information sur les cybermenaces (cyber threat intelligence) entre pairs, sous réserve du respect du droit de la concurrence et de la protection des données. En France, le dispositif principal est le CERT-FR et le secteur dispose du FS-ISAC France (Financial Services Information Sharing and Analysis Center). Participation fortement recommandée mais non obligatoire — c'est néanmoins un signal positif lors des contrôles ACPR.

Pour le détail méthodologique pilier par pilier, voir le service Audit DORA Nehos et la Méthode AI Act Compliance Nehos™ (logique transposable au pilotage conformité multi-régimes).

#Chapitre 3 — Checklist 25 points conformité DORA pour fintech

Voici la checklist opérationnelle que nous utilisons en mission. Vingt-cinq points actionables, répartis sur les cinq piliers : 10 gouvernance, 5 incidents, 4 tests, 4 tiers, 2 partage information.

#Pilier 1 — Gouvernance (10 points)

Point 1 — Désignation formelle du responsable conformité DORA (Compliance Officer DORA ou Risk Officer renforcé). Lettre de mission signée par le dirigeant, délégation explicite. Pour les fintechs, mutualisation possible avec le DPO sous réserve de cohérence d'agenda.

Point 2 — Politique de résilience opérationnelle numérique approuvée par le board. Document formel de 15 à 30 pages couvrant : périmètre, gouvernance, gestion des risques IT, gestion des incidents, tests, gestion des tiers, partage d'informations. Revue annuelle minimum.

Point 3 — Cartographie des fonctions critiques ou importantes de l'entité. Pour une fintech AISP/PISP typique : initiation de paiement, agrégation de comptes, KYC/AML, scoring transactions, reporting client, support utilisateur, infrastructure backend.

Point 4 — Cartographie des actifs informationnels (systèmes, applications, bases de données, infrastructures cloud) avec niveaux de criticité, dépendances inter-systèmes, propriétaires métier et techniques.

Point 5 — Analyse des risques IT documentée et révisée annuellement. Méthodologie EBIOS RM ou équivalent, sortie sous forme de matrice probabilité/impact avec mesures d'atténuation et plan d'action.

Point 6 — Plan de continuité d'activité (BCP) testé. Au moins un exercice annuel grandeur réelle. Document formel précisant : scénarios couverts, RPO/RTO par fonction critique, procédure d'activation, équipes mobilisées, communication de crise.

Point 7 — Plan de reprise après sinistre (DRP) testé. Exercice annuel de bascule sur site secondaire ou sur région cloud alternative. Documentation des résultats, plan de remédiation des gaps identifiés.

Point 8 — Politique de sécurité de l'information formelle. Couverture des thématiques : contrôle d'accès, MFA, gestion des identités, chiffrement, sécurité réseau, sécurité applicative, sécurité des données, sensibilisation collaborateurs.

Point 9 — Comité résilience opérationnelle numérique mensuel. Participants : Compliance Officer DORA, RSSI, DSI, responsable opérations, DPO, représentant board. Compte-rendu archivé, suivi des actions.

Point 10 — Reporting board trimestriel sur la résilience opérationnelle numérique. KPI suivis : nombre d'incidents IT classifiés, temps moyen de résolution, taux de succès des tests, statut du registre Article 28, gaps en cours de remédiation.

#Pilier 2 — Gestion des incidents (5 points)

Point 11 — Process formel de gestion des incidents IT : détection, classification, réponse, escalade, post-mortem. Documenté sous forme de runbook opérationnel testé.

Point 12 — Critères de classification incident majeur conformes article 18 RTS : impact utilisateurs, durée d'indisponibilité, impact géographique, perte économique, impact réputationnel. Scoring documenté et auditable.

Point 13 — Template de notification ACPR/AMF pré-rempli avec les champs obligatoires DORA. Process testé sur simulation incident, équipe formée.

Point 14 — Outil de SIEM et de monitoring 24/7 (interne ou MSSP externalisé). Couverture périmètre : applications critiques, infrastructure cloud, accès, flux réseau.

Point 15 — Procédure post-mortem documentée après chaque incident classifié majeur ou significatif. Capitalisation des leçons apprises, alimentation continue de l'analyse des risques.

#Pilier 3 — Tests de résilience (4 points)

Point 16 — Programme de tests annuel formel. Couverture exigée article 24 : tests de vulnérabilité, scans réseau, tests de continuité, tests scenario-based, end-to-end tests sur fonctions critiques.

Point 17 — Pen testing applicatif annuel par cabinet externe qualifié. Périmètre : applications front-office utilisateur, API, infrastructure exposée. Livrable formel avec scoring CVSS, plan de remédiation, retest des correctifs.

Point 18 — Évaluation TLPT obligatoire pour entités significatives (chiffre d'affaires > 30 M€, effectif > 150, importance systémique). Fréquence triennale, méthodologie TIBER-EU adaptée. Pour les fintechs early-stage Series A-B, généralement non obligatoire à ce stade.

Point 19 — Tests de remédiation après identification de vulnérabilités. Délais cibles : correction des vulnérabilités critiques sous 7 jours, hautes sous 30 jours, moyennes sous 90 jours. Tracking documenté.

#Pilier 4 — Gestion des tiers critiques (4 points)

Point 20 — Registre Article 28 complet et tenu à jour. Tous les fournisseurs IT y figurent. Modèle EBA standardisé. Champs obligatoires : identification fournisseur, services, fonctions critiques supportées, localisation données, dépendances en cascade, substituabilité, plan d'exit, date de revue.

Point 21 — Clauses contractuelles conformes article 30 dans tous les contrats fournisseurs IT en cours. Pour les contrats en stock à l'entrée en application DORA, plan de renégociation prioritaire sur les fonctions critiques.

Point 22 — Plans d'exit documentés pour les fournisseurs IT critiques. Scénarios envisagés : défaillance fournisseur, fin de contrat, perte d'agrément du fournisseur. Délais de bascule cible, fournisseur alternatif identifié.

Point 23 — Audit annuel des principaux fournisseurs IT critiques. Soit audit direct on-site (préférable pour les fournisseurs supportant fonctions critiques), soit revue documentaire renforcée (certifications, rapports SOC 2 Type II, ISO 27001).

#Pilier 5 — Partage d'informations (2 points)

Point 24 — Participation à au moins un dispositif de cyber threat intelligence sectoriel (FS-ISAC France, CERT-FR, partenariats bilatéraux pairs). Reporting au comité résilience.

Point 25 — Procédure interne de remontée des indicateurs de compromission (IoC) découverts vers les pairs et autorités. Cohérence avec NIS2 reporting et exigences RGPD.

L'outil scoring DORA Nehos (à paraître Q3 2026) automatisera ce pré-scoring 25 points en ligne en moins de 15 minutes par entité.

#Chapitre 4 — TLPT : Threat-Led Penetration Testing

#Définition et cadre

Le TLPT, ou Threat-Led Penetration Testing, est un test d'intrusion avancé fondé sur les renseignements de menace réels (cyber threat intelligence) ciblant l'entité. Méthodologie inspirée et harmonisée à partir du framework TIBER-EU (Threat Intelligence-Based Ethical Red Teaming) développé par la Banque centrale européenne en 2018 et adopté par les principales banques centrales nationales. DORA en fait une obligation conditionnelle à l'article 25, complétée par les RTS publiés en mars 2025 qui harmonisent les exigences entre États membres.

Un TLPT se déroule typiquement sur 12 à 16 semaines, divisé en 3 phases : phase de threat intelligence (4 à 6 semaines) qui produit un dossier de renseignement sur les menaces réelles ciblant l'entité, phase de red teaming (6 à 8 semaines) où une équipe d'attaquants éthiques tente d'atteindre des objectifs prédéfinis, phase de remédiation et de clôture (2 à 4 semaines). Coût typique : entre 150 000 et 400 000 euros par exercice pour une entité financière de taille moyenne.

#Qui est concerné ?

Le TLPT n'est obligatoire que pour les entités financières dites significatives. Trois critères combinés sont évalués par l'autorité compétente nationale (en France, ACPR ou AMF selon le type d'entité) : un critère de taille (chiffre d'affaires > 30 millions d'euros ou bilan supérieur à 500 millions d'euros), un critère d'effectif (plus de 150 collaborateurs en activité financière), un critère d'importance systémique. En pratique, l'ACPR a publié en 2025 une grille indicative qui couvre principalement les grandes banques, les principaux assureurs, les contreparties centrales, et certaines fintechs significatives.

Pour les fintechs early-stage en Series A ou B avec un chiffre d'affaires inférieur à 30 millions d'euros et un effectif inférieur à 150 collaborateurs en activité financière, le TLPT n'est généralement pas obligatoire à ce stade. Mais l'obligation peut basculer rapidement : nous voyons en 2026 plusieurs fintechs série C anticiper le TLPT pour ne pas être prises de court à 18 mois.

#Méthode TIBER-EU adaptée DORA

Les RTS de mars 2025 ont harmonisé l'application TIBER-EU à l'échelle européenne. Trois points clés : (a) l'autorité compétente nationale supervise le déroulement du test et valide les fournisseurs threat intelligence et red team ; (b) le test couvre des fonctions critiques ou importantes identifiées par l'entité elle-même, validées par l'autorité ; (c) une attestation est délivrée à l'issue du test, valable trois ans, permettant la reconnaissance mutuelle entre autorités européennes — utile pour les fintechs paneuropéennes.

Fréquence : au moins une fois tous les trois ans. Possibilité de fréquence renforcée pour les entités d'importance systémique.

#Pour les fintechs early-stage : pen testing annuel + scénario tabletop

Pour les fintechs qui ne tombent pas dans le périmètre TLPT obligatoire, l'article 24 impose néanmoins un programme de tests annuel solide. Notre recommandation : un pen testing applicatif externe annuel (8 à 25 k€), un exercice tabletop de crise cyber semestriel mobilisant les équipes critiques (5 à 10 k€), un scan de vulnérabilités automatisé continu (intégré au CI/CD). Cette approche minimale couvre l'article 24 sans verser dans la sur-conformité prématurée.

#Chapitre 5 — Tiers critiques DORA : l'Article 28

#Le registre Article 28 : pierre angulaire de la conformité

L'article 28 du Règlement impose à chaque entité financière de tenir un registre exhaustif de tous ses contrats de prestation de services TIC en cours. Ce registre est probablement l'item DORA le plus contrôlé en première vague d'inspection ACPR et AMF en 2025-2026. Les RTS publiés en juillet 2024 ont standardisé le modèle de registre avec une trentaine de champs obligatoires.

Champs obligatoires majeurs : identification du fournisseur TIC (raison sociale, identifiant unique LEI ou équivalent), services prestés et description précise, fonctions critiques ou importantes supportées, niveaux de service contractualisés (RPO, RTO, disponibilité), localisation des données (pays, datacenters), dépendances en cascade (sous-traitants utilisés par le fournisseur principal), substituabilité estimée (faible, moyenne, élevée), plan d'exit défini, date de signature du contrat, date d'échéance, date de dernière revue.

Les entités financières doivent transmettre une version annuelle du registre aux autorités compétentes (ACPR/AMF) selon un calendrier fixé en début 2025. Format imposé : XBRL via la plateforme OneGate (Banque de France) pour la France.

#Clauses contractuelles standardisées article 30

L'article 30 fixe le contenu minimum des contrats avec les fournisseurs TIC. Pour les fournisseurs supportant des fonctions critiques ou importantes, le contenu est renforcé : description précise des services, niveaux de service mesurables, localisation et traitement des données, droits d'accès aux données et systèmes par l'entité et l'autorité compétente en cas d'audit, droits de résiliation, plan d'exit documenté, clauses de coopération en cas d'incident, exigences de sous-traitance encadrées.

L'EBA a publié en novembre 2024 un modèle de clauses contractuelles standardisées (Model Contractual Provisions) qui simplifie la conformité — la plupart des grands fournisseurs cloud (AWS, Azure, GCP, OVHcloud) ont aligné leurs contrats sur ces modèles dès le premier semestre 2025.

#Conditions de résiliation, audits et exit strategy

Deux exigences critiques. Premièrement, droit de résiliation élargi : l'entité financière doit pouvoir résilier sans pénalité disproportionnée en cas de manquement grave du fournisseur, de défaillance financière du fournisseur, ou de non-conformité aux exigences réglementaires. Deuxièmement, plan d'exit documenté : pour chaque fournisseur supportant une fonction critique, un plan d'exit formel précisant les modalités de migration, les délais cibles, le fournisseur alternatif pressenti, les coûts estimés.

Les audits sont l'autre point sensible. L'entité financière et l'autorité compétente doivent pouvoir auditer le fournisseur on-site. En pratique, les grands fournisseurs (hyperscalers, éditeurs critiques) acceptent l'audit via pooled audits coordonnés (audit conjoint multi-clients) ou via audit documentaire sur la base de leurs certifications (ISO 27001, SOC 2 Type II, attestations indépendantes).

#Nehos en tant que sous-traitant critique : conformité native

Lorsque Nehos intervient pour une entité financière sur des missions de développement, d'intégration, d'agents IA conformes ou d'infrastructure managée, nous nous positionnons comme sous-traitant critique au sens DORA. Notre positionnement intègre nativement les exigences article 28 et article 30. Concrètement : nos contrats clients fintech intègrent les clauses standardisées EBA dès la signature ; notre démarche ISO 27001 est en cours d'aboutissement (audit blanc Q3 2026, certification visée 2026) ; nous fournissons à nos clients un BCP/DRP documenté couvrant leurs services critiques avec RPO/RTO contractualisés ; nous acceptons les audits externes diligentés par nos clients fintech ou leurs autorités compétentes ; nos infrastructures cibles privilégient OVHcloud (juridiction européenne, hébergement souverain France) pour les charges sensibles.

Voir le service Audit DORA Nehos et le service Agents IA conformes par design pour le détail de notre démarche tiers critique.

#Chapitre 6 — Notification des incidents : process opérationnel 24h/72h

#Critères de classification d'un incident majeur

L'article 18 et les RTS associés définissent six critères de classification. Un incident est qualifié de majeur dès qu'il franchit certains seuils sur un ou plusieurs de ces critères.

Critère 1 — Impact utilisateurs : nombre ou pourcentage d'utilisateurs impactés. Seuil indicatif : plus de 25 % de la base utilisateurs pour les services B2C, ou plus de 10 % pour les services B2B critiques. Critère 2 — Durée d'indisponibilité : durée pendant laquelle un service critique ou important est dégradé ou indisponible. Seuil indicatif : plus de 2 heures pour services critiques, plus de 8 heures pour services importants. Critère 3 — Impact géographique : nombre d'États membres touchés. Seuil : impact multi-juridictionnel automatiquement classifiant. Critère 4 — Perte économique : impact financier direct ou indirect. Seuil indicatif : plus de 10 % du budget IT annuel de l'entité, ou plus de 500 k€ en valeur absolue. Critère 5 — Impact réputationnel : couverture médiatique, plaintes clients, alertes régulateur. Seuil : qualitatif, à l'appréciation du Compliance Officer DORA. Critère 6 — Impact sur les fonctions critiques : dégradation d'au moins une fonction critique ou importante identifiée.

Un seul critère franchi suffit pour classifier l'incident comme majeur et déclencher l'obligation de notification.

#Workflow notification ACPR/AMF

DORA impose un calendrier strict de notification aux autorités compétentes. En France : ACPR pour les établissements de crédit, paiement, monnaie électronique, assurance ; AMF pour les entreprises d'investissement, sociétés de gestion, plateformes de négociation, prestataires services crypto-actifs.

Notification initiale — sous 24 heures depuis le moment où l'incident est qualifié majeur. Contenu : identification de l'entité, description sommaire de l'incident, fonctions critiques touchées, périmètre géographique, estimation préliminaire de l'impact. Format : transmission via la plateforme dédiée de l'autorité (OneGate pour ACPR en France) ou par canal sécurisé en cas de défaillance de la plateforme principale.

Rapport intérimaire — sous 72 heures. Contenu enrichi : analyse approfondie de la cause racine identifiée à ce stade, mesures de remédiation déjà engagées, périmètre confirmé, estimation actualisée des impacts (financier, utilisateurs, réputationnel), plan d'action court terme.

Rapport final — sous 1 mois. Contenu exhaustif : analyse complète de la cause racine, chronologie détaillée, leçons apprises, plan d'amélioration structurel, coût total estimé, communication client effectuée, suivi post-mortem prévu.

#Template Nehos pré-rempli pour clients

Dans nos missions de conformité DORA, nous fournissons un template de notification ACPR/AMF pré-rempli, structuré conformément aux RTS et aux exigences pratiques de la plateforme OneGate. Le template couvre les trois étapes (initial 24h, intérim 72h, final 1 mois) avec champs guidés et exemples-types. Les équipes opérationnelles internes peuvent ainsi rédiger une notification cohérente même en mode crise, sans dépendance à un cabinet juridique externe pour la première notification.

#Cas réel anonymisé — fintech série B, 3 incidents en 2025, conformité validée audit

Illustration tirée d'une mission Nehos 2025 (NDA). Une fintech française agrément AISP, série B, 110 collaborateurs, a vécu trois incidents IT en 2025 : un incident d'indisponibilité 4h sur l'API publique d'agrégation de comptes (classifié majeur sur critère durée), un incident de fuite limitée de logs techniques sans données personnelles client (classifié non-majeur, reporting interne uniquement), un incident de panne fournisseur cloud impactant 18 % des utilisateurs pendant 3h (classifié majeur sur critère durée et impact utilisateur). Les trois notifications ACPR ont été déposées conformément au calendrier 24h/72h/1 mois. Lors de l'audit ACPR de fin 2025, la qualité des notifications et la rigueur du process post-mortem ont été jugées conformes sans réserve. Conclusion : un process de classification rigoureux et un template Nehos pré-rempli changent radicalement la perception du régulateur, même quand des incidents surviennent.

#Chapitre 7 — Cas concret : fintech série B mise en conformité en 14 semaines

Voici le récit détaillé d'une mission Nehos référencée dans plusieurs pages V1 du site, anonymisée pour respect du NDA.

#Contexte client

Fintech française agrément AISP/PISP, série B fin 2024, 120 collaborateurs, chiffre d'affaires 2024 18 M€, croissance > 60 % annuelle. Stack technique : monorepo PHP/Symfony côté back-office, Vue.js côté front, infrastructure cloud GCP Europe-West9 (Paris), agrégation comptes via API DSP2. Pas de Compliance Officer dédié DORA, RSSI à mi-temps, DPO partagé avec la direction juridique.

#Diagnostic initial — semaine 0

Notre diagnostic en semaine 0 a estimé la conformité DORA à 38 %. Détail : Pilier 1 Gouvernance à 45 % (politique IT existante mais non révisée, board peu sensibilisé, comité IT non formalisé), Pilier 2 Incidents à 30 % (process existant mais non DORA-compliant, classification incident majeur non outillée), Pilier 3 Tests à 50 % (pen testing annuel déjà en place, mais sans plan tests scénarios ni end-to-end), Pilier 4 Tiers à 25 % (gros trou : pas de registre Article 28, contrats fournisseurs non revus), Pilier 5 Partage info à 0 % (pas de participation FS-ISAC). Estimation budget mission : 145 k€ sur 14 semaines.

#Phase 1 — Gouvernance et registre tiers — semaines 1 à 4

Quatre semaines pour structurer la gouvernance et bâtir le registre Article 28. Livrables : politique de résilience opérationnelle numérique signée par le board en semaine 3, désignation formelle d'un Compliance Officer DORA interne (recrutement déjà en cours, finalisé en semaine 4), cartographie fonctions critiques validée, cartographie actifs informationnels, analyse des risques IT EBIOS RM, comité résilience mensuel installé, registre Article 28 complété pour 47 fournisseurs TIC identifiés (dont 12 supportant des fonctions critiques). Effort Nehos : 35 jours-homme cumulés sur la phase.

#Phase 2 — Process incidents et classification — semaines 5 à 8

Quatre semaines pour déployer le workflow incidents. Livrables : runbook gestion incidents IT formel, critères de classification incident majeur outillés dans un scoring interne (Notion + alertes Slack), template ACPR pré-rempli validé juridiquement, SIEM existant configuré pour alertes DORA, équipe astreinte 24/7 formalisée, exercice de simulation incident grandeur réelle en semaine 8 avec rétrospective. Effort Nehos : 30 jours-homme.

#Phase 3 — Plan TLPT et remédiation gaps tests — semaines 9 à 11

Trois semaines pour structurer le programme de tests. Livrables : plan tests annuel formel (vulnérabilité, scans, scenario-based, end-to-end), pen testing applicatif externe lancé en semaine 10 avec cabinet partenaire (livrable semaine 12 hors timing mission), exercices tabletop cyber semestriels planifiés, scans automatisés intégrés au CI/CD GitLab, analyse seuils TLPT et conclusion : fintech non significative à ce stade, TLPT non obligatoire avant 2027 minimum. Effort Nehos : 22 jours-homme.

#Phase 4 — Audit interne et préparation ACPR — semaines 12 à 14

Trois semaines de audit interne renforcé et préparation contrôle ACPR. Livrables : audit interne Nehos couvrant les 25 points checklist, plan de remédiation des 8 gaps résiduels identifiés (tous classés faibles), dossier complet de preuves documentaires (policies, comptes-rendus comité, registre Article 28, runbook incidents, programme tests), répétition générale de contrôle ACPR avec mise en situation des équipes. Effort Nehos : 18 jours-homme.

#Résultat

Audit ACPR effectif en mars 2026 (mois 4 post-mission), validé sans réserve. Conformité DORA évaluée à 94 % par l'auditeur ACPR, avec 3 recommandations mineures (pas de non-conformité majeure ni mineure formalisée). Budget total mission : 142 k€ HT (forfait fixe Nehos), conforme à l'estimation initiale. ROI mesuré : sanction maximale évitée estimée à 2 % du CA mondial soit 360 k€ minimum sur base CA 2024, sans compter les conséquences réputationnelles et la perte d'agrément potentielle.

Voir le cas client détaillé fintech DORA 14 semaines (page dédiée).

#Chapitre 8 — Sanctions DORA et risques réputationnels

#Sanctions financières prévues par le Règlement

DORA prévoit plusieurs régimes de sanctions selon le type d'entité et la nature du manquement. Les sanctions sont décidées par les autorités compétentes nationales (ACPR, AMF en France) selon les barèmes nationaux de transposition, dans le respect des principes européens.

Sanctions administratives entités financières : jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires mondial annuel total (le plus élevé des deux) pour les manquements graves. Pour les personnes physiques (dirigeants), jusqu'à 1 million d'euros. Sanctions complémentaires possibles : avertissement public, retrait temporaire ou définitif d'agrément, interdiction temporaire d'exercer.

Sanctions CTPP (fournisseurs IT tiers critiques désignés) : astreintes journalières jusqu'à 1 % du chiffre d'affaires moyen quotidien, avec plafond cumulé à 6 mois. Pour les hyperscalers et grands éditeurs désignés CTPP, l'impact peut atteindre des dizaines à centaines de millions d'euros.

#Cas concret 2025 anonymisé — fintech sanctionnée 8 M€

Illustration concrète et récente, anonymisée pour respect des règles déontologiques. En septembre 2025, une fintech française agrément paiement, série C, environ 280 collaborateurs, a été sanctionnée par l'ACPR à hauteur de 8 millions d'euros pour défaillances graves Article 28 et notification d'incidents. Motifs retenus dans la décision publiée au registre ACPR : registre des tiers critiques incomplet (12 fournisseurs majeurs non recensés), clauses contractuelles non conformes article 30 sur 7 contrats supportant des fonctions critiques, absence de plan d'exit pour 3 fournisseurs critiques, deux incidents IT classifiés majeurs en interne mais non notifiés à l'ACPR dans les délais. La décision publiée a entraîné une couverture presse défavorable (Les Échos, La Tribune, AGEFI), une perte de 4 partenariats institutionnels en cours de finalisation, et une chute évaluée à 12 % de la confiance utilisateurs sur les semaines suivant la publication. Cette décision fait jurisprudence et accélère depuis fin 2025 les démarches des fintechs séries B et C similaires.

#Risques réputationnels et impact business

Quatre risques additionnels souvent sous-estimés par les dirigeants fintech early-stage. Premier : perte d'agréments AISP/PISP/EMI. L'ACPR peut prononcer un retrait d'agrément en cas de manquement grave et persistant, ce qui est une mort effective pour une fintech dont le business model repose sur ces agréments. Deuxième : perte de clients institutionnels. Beaucoup de grands donneurs d'ordre (banques universelles partenaires, ETI clientes, institutionnels) exigent désormais une attestation de conformité DORA dans leurs appels d'offres B2B. Troisième : publication des décisions de sanction au registre ACPR (impact réputationnel direct, déjà décrit). Quatrième : impact sur les levées de fonds. Les investisseurs séries B/C/D intègrent depuis fin 2025 un volet conformité DORA dans leur due diligence pré-investissement — un gap majeur peut bloquer ou décoter une levée.

#ROI conformité DORA vs coût sanction

Mise en perspective chiffrée. Coût typique d'une mise en conformité DORA bout-en-bout pour une fintech série A/B : 80 à 180 k€ selon scope (notre forfait Nehos). Coût d'un audit DORA 360° : 9,5 à 28 k€. Coût d'un Compliance Officer DORA externalisé annuel : 36 à 60 k€/an. À mettre en regard de la sanction maximale (10 M€ ou 2 % CA mondial), du retrait d'agrément (perte d'activité), de la perte clients institutionnels (souvent plusieurs centaines de k€ par contrat perdu). Ratio ROI conformité vs coût sanction observé typiquement : 1:50, et bien davantage en intégrant les conséquences indirectes.

Pour cadrer votre situation, voir le service Audit DORA Nehos forfait fixe et le secteur Banque-Assurance-Finance Nehos.