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, 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 de clients ou d'utilisateurs impactés, durée d'indisponibilité, impact géographique multi-juridiction, perte économique, impact réputationnel (les seuils chiffrés sont fixés par les RTS sur la classification des incidents).

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 : il vise les entités que l'autorité identifie comme significatives, selon leur taille, leur importance systémique et leur maturité informatique. 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 les entités identifiées comme significatives par l'autorité (taille, importance systémique, maturité IT). 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) automatisera ce pré-scoring 25 points en ligne.

#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). Le coût d'un exercice TLPT est élevé et varie fortement selon le périmètre.

#Qui est concerné ?

Le TLPT n'est obligatoire que pour les entités financières dites significatives. Les entités concernées sont identifiées par l'autorité compétente nationale (en France, ACPR ou AMF selon le type d'entité), selon des critères de taille, d'importance systémique et de maturité informatique. En pratique, cela vise principalement les grandes banques, les principaux assureurs, les contreparties centrales, et certaines fintechs significatives.

Pour les fintechs early-stage en Series A ou B, de taille modeste, le TLPT n'est généralement pas obligatoire à ce stade. Mais l'obligation peut basculer avec la croissance : mieux vaut anticiper le TLPT dès que l'activité prend de l'ampleur.

#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, un exercice tabletop de crise cyber semestriel mobilisant les équipes critiques, 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 : nous pouvons intégrer à nos contrats les clauses standardisées EBA dès la signature ; nous pouvons documenter un plan de continuité et de reprise avec des objectifs de reprise contractualisés ; nous acceptons les audits externes diligentés par nos clients fintech ou leurs autorités compétentes ; pour les charges sensibles, nous pouvons héberger les projets chez un hébergeur européen qualifié SecNumCloud.

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. Les RTS fixent les seuils chiffrés. Critère 2 — Durée d'indisponibilité : durée pendant laquelle un service critique ou important est dégradé ou indisponible. Les RTS fixent les seuils de durée.

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. Les RTS fixent les seuils de montant. 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 pouvons fournir 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.

#Exemple de situation — des incidents bien gérés

Situation type, construite pour illustrer. Une fintech agréée AISP connaît plusieurs incidents IT dans l'année : une indisponibilité prolongée de l'API d'agrégation de comptes (incident majeur sur le critère de durée), une fuite limitée de logs techniques sans données personnelles (incident non majeur, traité en interne), une panne d'un fournisseur cloud qui touche une partie des utilisateurs (incident majeur).

Les notifications suivent le calendrier 24h/72h/1 mois, le post-mortem est documenté. Face au contrôleur, un processus de classification rigoureux et un modèle de notification prêt à l'emploi changent la perception de l'entité, même quand des incidents surviennent.

#Chapitre 7 — Exemple de situation : une fintech série B vers la conformité en quatre phases

Cet exemple est une situation type construite pour illustrer la méthode. Il ne décrit pas un client réel et ne comporte aucun résultat chiffré.

#Le contexte type

Une fintech agréée AISP/PISP, en série B, a grandi vite. Son back-office est un monorepo PHP/Symfony, son front est en Vue.js, son infrastructure est hébergée en Europe et l'agrégation de comptes passe par les API DSP2. Elle n'a pas de Compliance Officer dédié à DORA, un RSSI à temps partiel et un DPO partagé avec la direction juridique.

#Diagnostic initial

Le diagnostic de départ évalue chaque pilier. Gouvernance : politique IT existante mais non révisée, comité IT non formalisé. Incidents : processus existant mais non conforme à DORA, classification des incidents majeurs non outillée. Tests : pen testing annuel déjà en place, mais sans plan de tests par scénarios. Tiers : gros trou, pas de registre Article 28 et contrats fournisseurs non revus. Partage d'information : aucune participation à un dispositif sectoriel.

#Phase 1 — Gouvernance et registre tiers

Structurer la gouvernance et bâtir le registre Article 28. Livrables : politique de résilience opérationnelle numérique validée par le conseil, désignation d'un responsable DORA, cartographie des fonctions critiques et des actifs informationnels, analyse des risques IT (EBIOS RM), comité résilience régulier, registre des fournisseurs TIC avec identification de ceux qui supportent des fonctions critiques.

#Phase 2 — Processus incidents et classification

Déployer le workflow incidents. Livrables : runbook de gestion des incidents IT, critères de classification des incidents majeurs outillés, modèle de notification ACPR prérempli et relu par un juriste, SIEM configuré pour les alertes DORA, astreinte formalisée, exercice de simulation avec rétrospective.

#Phase 3 — Plan de tests et remédiation

Structurer le programme de tests. Livrables : plan de tests annuel (vulnérabilités, scans, scénarios, bout en bout), pen testing applicatif externe lancé, exercices tabletop cyber planifiés, scans automatisés intégrés à la CI/CD, analyse des critères TLPT pour savoir si l'entité est concernée.

#Phase 4 — Audit interne et préparation au contrôle

Audit interne couvrant les 25 points de la checklist, plan de remédiation des écarts résiduels, dossier de preuves documentaires (politiques, comptes rendus de comité, registre Article 28, runbook incidents, programme de tests), répétition générale du contrôle avec les équipes.

#Ce que l'on vise

Arriver au contrôle avec un dossier de preuves complet, des équipes qui savent répondre et des écarts résiduels connus et planifiés. La durée dépend du niveau de départ : elle est cadrée lors de l'audit initial.

Voir le service Audit DORA pour le détail de l'accompagnement.

#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.

#Exemple de situation — les manquements les plus souvent reprochés

Situation type, construite pour illustrer : une fintech dont le registre des tiers critiques est incomplet, dont certains contrats supportant des fonctions critiques ne respectent pas l'article 30, qui n'a pas de plan de sortie pour ses fournisseurs critiques et qui n'a pas notifié dans les délais des incidents qu'elle avait pourtant classés majeurs en interne.

Ce sont les points les plus faciles à vérifier pour un contrôleur, donc ceux sur lesquels une sanction est la plus probable. Une décision publiée a en outre un coût réputationnel : couverture presse défavorable, partenaires institutionnels plus prudents, confiance des utilisateurs entamée.

#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.

#Conformité DORA et coût d'une sanction

Mise en perspective. Le coût d'une mise en conformité dépend du scope : nombre de fournisseurs critiques, taille du parc applicatif, niveau de départ. Pour un programme DORA, nos tarifs démarrent à 15 000 € HT ; un audit DORA complet ou un Compliance Officer DORA externalisé se chiffrent sur devis, en 48 h après un premier échange.

À mettre en regard de la sanction maximale, du retrait d'agrément (perte d'activité) et de la perte de clients institutionnels, qui exigent de plus en plus une attestation de conformité DORA dans leurs appels d'offres.

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

Photos : Brett Sayles, Kampus Production, Thirdman sur Pexels.