DORA pour les non-banquiers : qui est concerné et que faire

Quand on évoque le règlement DORA (Digital Operational Resilience Act), la réaction la plus fréquente dans les PME du secteur financier tient en une phrase : « C’est pour les banques, pas pour nous. » Cette réaction est compréhensible. Elle est aussi fausse.

Le règlement européen 2022/2554, applicable depuis le 17 janvier 2025, couvre plus de vingt catégories d’entités financières. Les banques en font partie. Mais aussi les courtiers en assurance, les conseillers en gestion de patrimoine (CGP), les fintechs, les sociétés de gestion, les intermédiaires en financement participatif, les prestataires de services sur crypto-actifs — et, indirectement, tous les prestataires informatiques qui travaillent pour ces entités.

Ce guide s’adresse aux structures qui n’ont pas de département conformité de 50 personnes. Si vous êtes un courtier en assurance de 20 collaborateurs, un CGP indépendant, une fintech en série A ou un éditeur de logiciel qui fournit le secteur financier, cet article vous concerne. Il explique ce que DORA exige, pourquoi vous êtes dans le périmètre, et surtout quelles actions concrètes mettre en place sans mobiliser un budget de grande banque.

DORA en 90 secondes : ce qu’il faut retenir

DORA est un règlement européen, pas une directive. La distinction compte : un règlement est directement applicable dans tous les États membres sans transposition nationale. Il n’y a pas de marge d’interprétation locale. Ce que DORA prescrit en Allemagne s’applique de la même manière en France.

L’objectif du règlement est d’harmoniser la résilience opérationnelle numérique du secteur financier européen. Avant DORA, chaque pays et chaque secteur (banque, assurance, marchés financiers) avait ses propres exigences en matière de risques informatiques. Le résultat : un patchwork de normes disparates et des niveaux de protection très inégaux.

DORA remplace ce patchwork par un cadre unifié qui s’articule autour de cinq axes :

Gestion des risques TIC (articles 5 à 16)
Notification des incidents TIC (articles 17 à 23)
Tests de résilience opérationnelle numérique (articles 24 à 27)
Gestion du risque lié aux prestataires tiers TIC (articles 28 à 44)
Partage d’informations (article 45)

Pour une analyse approfondie de DORA et de ses implications sur la formation des équipes, consultez notre page conformité DORA.

Chacun de ces axes génère des obligations concrètes que nous détaillerons plus bas. Mais avant d’entrer dans le « que faire », il faut répondre à la question qui préoccupe la plupart des lecteurs de cet article : « Est-ce que ça me concerne ? »

Qui est vraiment concerné : la liste qui surprend

L’article 2 du règlement DORA dresse la liste des entités couvertes. Cette liste est longue, et c’est volontaire : le législateur européen a voulu couvrir l’ensemble de la chaîne de valeur financière, pas seulement les acteurs les plus visibles.

Les entités évidentes

Commençons par les catégories que personne ne conteste :

Établissements de crédit (banques)
Entreprises d’investissement
Compagnies d’assurance et de réassurance
Établissements de paiement
Établissements de monnaie électronique

Pour ces entités, DORA s’ajoute aux exigences prudentielles existantes. Elles ont généralement les moyens et les équipes pour gérer la mise en conformité. Ce n’est pas à elles que cet article est destiné.

Les entités que beaucoup oublient

Voici les catégories de l’article 2 qui prennent de court la plupart des structures concernées.

Courtiers et intermédiaires d’assurance — L’article 2.1(e) inclut les intermédiaires d’assurance dans le périmètre de DORA. Un cabinet de courtage de 10, 20 ou 50 personnes est une entité financière au sens du règlement. La distinction entre courtier personne physique et société de courtage ne change rien : l’obligation porte sur l’activité, pas sur la forme juridique.

Pour un courtier en assurance, cela signifie concrètement : documenter la gestion de ses risques informatiques, former ses collaborateurs aux menaces numériques, gérer le risque lié à ses prestataires IT (son éditeur de CRM, son hébergeur, son fournisseur de logiciel de gestion de contrats). Des obligations qui n’existaient pas sous cette forme avant DORA.

Conseillers en gestion de patrimoine (CGP) — Les CGP qui détiennent un statut de CIF (Conseiller en Investissement Financier) entrent dans le périmètre de DORA via la catégorie des entreprises d’investissement et des intermédiaires financiers. Un CGP indépendant qui gère des portefeuilles ou distribue des produits financiers est soumis aux mêmes obligations de résilience numérique qu’un établissement de taille nettement supérieure, avec le principe de proportionnalité en atténuation.

Fintechs et néobanques — Toute fintech agréée (établissement de paiement, établissement de monnaie électronique, prestataire de services sur crypto-actifs) entre dans le périmètre de DORA. Le fait d’être une startup de 25 personnes ne constitue pas une exemption. Le régulateur ne regarde pas la taille de l’équipe, mais l’agrément.

C’est un sujet sensible pour les fintechs en phase de croissance : les ressources sont mobilisées sur le produit et la croissance commerciale, pas sur la conformité réglementaire. Mais l’ACPR ne fait pas de distinction entre une néobanque de 30 employés et une banque de réseau sur l’existence des obligations. Seule l’intensité des mesures est proportionnée.

Sociétés de gestion d’actifs — Les sociétés de gestion de portefeuille et les gestionnaires de fonds d’investissement alternatifs sont couverts, quelle que soit leur taille. Un gérant de fonds avec une équipe de 15 personnes a les mêmes obligations structurelles qu’un grand asset manager.

Plateformes de financement participatif — Les prestataires de services de financement participatif agréés entrent dans le périmètre depuis le règlement 2020/1503 et sont désormais soumis aux exigences de résilience de DORA. Le marché du crowdfunding financier en France, bien qu’en croissance, est composé en grande partie de PME.

Prestataires de services sur crypto-actifs (PSCA) — Les PSCA agréés au titre de MiCA sont explicitement listés à l’article 2 de DORA. Pour une plateforme d’échange de crypto-actifs de 40 personnes, DORA représente une couche réglementaire supplémentaire qui s’ajoute aux exigences de MiCA.

Le cas particulier des prestataires IT du secteur financier

La cinquième catégorie de DORA concerne les prestataires tiers critiques de services TIC. Cette notion mérite une explication.

DORA ne s’applique pas directement à tous les prestataires informatiques. Mais il crée deux mécanismes qui les affectent :

Le cadre de surveillance directe (articles 31 à 44) : les autorités européennes de surveillance (ABE, AEAPP, AEMF) peuvent désigner certains prestataires TIC comme « critiques ». Ces prestataires sont alors soumis à une surveillance directe : inspections, recommandations, et potentiellement des pénalités d’astreinte allant jusqu’à 1 % du chiffre d’affaires mondial journalier. Ce cadre vise surtout les grands fournisseurs cloud (AWS, Azure, Google Cloud) et les éditeurs de logiciels bancaires systémiques.

Les obligations contractuelles (article 28) : chaque entité financière soumise à DORA doit gérer le risque lié à ses prestataires tiers TIC. Cela passe par des clauses contractuelles spécifiques (article 30) couvrant la sécurité des données, les droits d’audit, la notification d’incidents et les plans de sortie. En pratique, même un éditeur de logiciel SaaS de 20 personnes qui fournit un cabinet de courtage va recevoir des avenants contractuels imposant des exigences DORA.

Si vous êtes un prestataire IT travaillant pour des entités financières, vous n’êtes pas directement « entité financière » au sens de DORA. Mais vos clients le sont, et ils vont vous imposer des obligations par ricochet. C’est le mécanisme de cascade contractuelle de DORA, et il touche des milliers de PME technologiques en France.

Les cinq axes de DORA : ce que chacun implique pour une PME

Le règlement s’articule autour de cinq axes. Pour une grande banque, chacun mobilise des équipes spécialisées. Pour une PME financière, il s’agit de comprendre ce qui est attendu et de le calibrer à sa réalité.

Axe 1 — Gestion des risques TIC (articles 5 à 16)

C’est le socle du règlement. Chaque entité financière doit mettre en place un cadre de gestion des risques liés aux technologies de l’information et de la communication.

Ce que cela signifie pour une PME :

Identifier et inventorier tous les actifs informatiques : serveurs, postes de travail, logiciels, comptes cloud, données critiques.
Évaluer les risques : quelles menaces pèsent sur ces actifs ? Quels scénarios de compromission sont plausibles ?
Mettre en place des mesures de protection : contrôle d’accès, chiffrement, sauvegardes, mises à jour.
Former le personnel : l’article 13.6 impose des programmes de sensibilisation pour tous les collaborateurs et dirigeants.

L’article 5.4 impose une obligation spécifique aux dirigeants : ils doivent eux-mêmes suivre une formation leur permettant de « comprendre et évaluer les risques liés aux TIC ». Le PDG d’un cabinet de courtage qui valide la politique de sécurité informatique sans jamais avoir été formé aux risques numériques ne satisfait pas cette exigence.

La rédaction d’une politique de sécurité des systèmes d’information (PSSI) documentée est le point de départ naturel de cet axe. Pour les PME, une PSSI de 10 à 15 pages couvrant les points listés ci-dessus suffit dans un premier temps.

Axe 2 — Notification des incidents TIC (articles 17 à 23)

DORA impose un cadre de classification et de notification des incidents TIC. Les entités financières doivent :

Classifier les incidents selon une taxonomie harmonisée (criticité, impact, périmètre)
Notifier les incidents majeurs à leur autorité compétente (l’ACPR en France pour les banques et assureurs)
Respecter des délais précis : notification initiale dans les 4 heures suivant la classification de l’incident comme majeur, rapport intermédiaire sous 72 heures, rapport final sous un mois

Pour une PME, le défi n’est pas la notification elle-même (un formulaire à remplir), mais la détection et la classification. Il faut être capable de repérer qu’un incident s’est produit, d’évaluer sa gravité et de déclencher le processus. Sans procédure documentée, la plupart des PME découvrent les incidents trop tard pour respecter les délais.

La mise en place d’un plan de réponse aux incidents est une étape préparatoire directe à cet axe. Ce plan n’a pas besoin d’être un document de 100 pages ; il doit identifier qui fait quoi quand un incident survient, et comment l’information remonte.

Axe 3 — Tests de résilience opérationnelle numérique (articles 24 à 27)

DORA exige que les entités financières testent régulièrement leur résilience. Deux niveaux de tests :

Tests de base (obligatoires pour toutes les entités) : tests de vulnérabilité, analyses de code source, tests de sécurité des réseaux, tests basés sur des scénarios. C’est ici que les simulations de phishing prennent tout leur sens : elles constituent un test basé sur un scénario réel (l’hameçonnage) qui évalue la résilience humaine de l’organisation.

Tests de pénétration avancés (TLPT — Threat-Led Penetration Testing) : obligatoires uniquement pour les entités « importantes ». Les PME financières n’entrent généralement pas dans cette catégorie, mais l’ACPR peut décider au cas par cas.

Pour une PME financière, le minimum attendu : des tests de vulnérabilité annuels sur les systèmes critiques et des simulations de phishing régulières pour tester la résilience des collaborateurs. Ces deux types de tests couvrent les aspects techniques et humains exigés par l’article 25.

Axe 4 — Gestion du risque lié aux prestataires tiers TIC (articles 28 à 44)

C’est l’axe qui génère le plus de travail opérationnel pour les PME. Chaque entité financière doit :

Tenir un registre de tous ses prestataires TIC (article 28.3) : hébergeur, éditeur de logiciel métier, fournisseur de messagerie, prestataire de sauvegarde, etc.
Évaluer le risque de concentration : si vos emails, votre CRM et votre logiciel de gestion sont tous hébergés chez le même fournisseur cloud, vous avez un risque de concentration.
Intégrer des clauses contractuelles obligatoires (article 30) : droits d’audit, exigences de sécurité, notification d’incidents, plans de sortie.
Surveiller en continu la performance et les risques liés à ces prestataires.

Pour un cabinet de courtage de 20 personnes, cela commence par un exercice simple : lister tous les logiciels et services en ligne utilisés, identifier lesquels traitent des données clients ou permettent l’accès à des systèmes critiques, et vérifier les contrats en place. Beaucoup de PME financières découvrent à cette occasion qu’elles n’ont aucun contrat écrit avec certains de leurs prestataires IT.

Axe 5 — Partage d’informations (article 45)

DORA encourage (sans l’imposer strictement) le partage d’informations sur les menaces entre entités financières. Cet axe est le moins contraignant pour les PME. Il ouvre la possibilité de participer à des dispositifs de partage de renseignements sur les cybermenaces (threat intelligence), mais ne crée pas d’obligation formelle de le faire.

En pratique, les PME financières bénéficient indirectement de cet axe via les alertes et les publications de l’ACPR et de l’ANSSI (cyber.gouv.fr), qui diffusent des informations sur les menaces sectorielles.

L’ACPR : votre interlocuteur en France

En France, l’autorité compétente pour la supervision DORA des banques, assureurs et intermédiaires financiers est l’Autorité de Contrôle Prudentiel et de Résolution (ACPR), adossée à la Banque de France. Pour les marchés financiers (sociétés de gestion, entreprises d’investissement), l’AMF (Autorité des Marchés Financiers) intervient également.

L’ACPR dispose de plusieurs leviers :

Contrôles sur place : des inspecteurs se déplacent dans vos locaux, examinent votre documentation, interrogent vos équipes.
Contrôles sur pièces : l’ACPR demande la transmission de documents (politique de sécurité, registre des prestataires, preuves de formation, rapports d’incidents).
Sanctions : injonctions de mise en conformité, astreintes journalières, avertissements, blâmes, sanctions pécuniaires.

Ce que l’ACPR vérifie en priorité dans le cadre de DORA :

L’existence d’un cadre de gestion des risques TIC documenté — pas sa perfection, mais son existence et sa cohérence.
Les preuves de formation du personnel et des dirigeants — calendrier, participation, contenu, résultats mesurés.
Le registre des prestataires tiers TIC — exhaustivité et clauses contractuelles.
Les procédures de notification d’incidents — existence et tests.

L’absence de documentation est traitée comme une non-conformité, même si les pratiques existent « dans les faits ». Un courtier qui forme verbalement ses collaborateurs aux risques de phishing mais ne documente rien est en situation de non-conformité au même titre qu’un courtier qui ne forme personne.

DORA et NIS2 : comment s’y retrouver

La question revient systématiquement : « Faut-il se conformer à DORA et à NIS2 ? »

La réponse est dans le règlement lui-même. L’article 1.2 de DORA précise que le règlement est lex specialis par rapport à NIS2. En droit européen, cela signifie que la loi spéciale (DORA, qui s’applique spécifiquement au secteur financier) prévaut sur la loi générale (NIS2, qui s’applique à tous les secteurs) dans les domaines qu’elle couvre.

En pratique :

Si vous êtes une entité financière soumise à DORA, les obligations de DORA prévalent sur les obligations équivalentes de NIS2 en matière de gestion des risques, de notification d’incidents et de tests de résilience.
Si NIS2 impose des obligations que DORA ne couvre pas, ces obligations restent applicables.
Un programme de conformité DORA bien structuré satisfait la grande majorité des exigences de NIS2 pour les mêmes sujets.

Pour les prestataires IT du secteur financier, la situation est différente : si vous n’êtes pas vous-même une entité financière, vous relevez potentiellement de NIS2 (selon votre taille et votre secteur) et recevez des exigences DORA par cascade contractuelle. Dans ce cas, les deux cadres peuvent s’appliquer simultanément.

Le plan d’action en 8 étapes pour les PME financières

Passer de « je découvre DORA » à « je suis en conformité » ne nécessite pas un programme de transformation de 18 mois ni un cabinet de conseil à 2 000 € la journée. Voici un plan d’action séquencé, calibré pour une PME de 15 à 100 personnes.

Étape 1 — Confirmez votre statut (semaine 1)

Relisez l’article 2 du règlement et identifiez formellement dans quelle catégorie vous entrez. Si vous avez un doute, votre agrément ou votre enregistrement auprès de l’ACPR ou de l’AMF détermine votre statut. Documentez cette identification dans une note interne.

Étape 2 — Inventoriez vos actifs TIC (semaines 1-2)

Listez tous les équipements informatiques, logiciels, services cloud et bases de données utilisés par votre organisation. Pour chaque actif, identifiez :

Sa fonction (messagerie, CRM, logiciel métier, sauvegarde, etc.)
Les données qu’il traite (données clients, données financières, données personnelles)
Son criticité (que se passe-t-il si cet outil est indisponible pendant 24 heures ?)

Un tableur structuré suffit. L’objectif n’est pas l’exhaustivité parfaite dès le premier passage, mais d’avoir une vue claire de votre périmètre numérique.

Étape 3 — Cartographiez vos prestataires TIC (semaine 2)

C’est le corollaire de l’étape 2. Pour chaque prestataire identifié :

Vérifiez l’existence d’un contrat écrit
Évaluez le risque de concentration (combien de services critiques dépendent du même prestataire ?)
Identifiez les clauses manquantes au regard de l’article 30 de DORA (notification d’incidents, droits d’audit, plan de sortie)

Ce registre des prestataires est l’un des premiers documents que l’ACPR demandera lors d’un contrôle.

Étape 4 — Rédigez votre politique de gestion des risques TIC (semaines 2-4)

Ce document formalise votre approche de la sécurité informatique. Pour une PME, il couvre :

Les rôles et responsabilités (qui est responsable de la sécurité IT ?)
Les mesures de protection en place (contrôle d’accès, chiffrement, sauvegardes)
La politique de mots de passe et d’authentification
Les procédures de mise à jour et de correction des vulnérabilités

Notre guide pour rédiger une PSSI fournit un cadre directement applicable. Pour les PME soumises à DORA, ajoutez une section spécifique « résilience opérationnelle numérique » faisant référence aux exigences des articles 5 à 16.

Étape 5 — Mettez en place un programme de sensibilisation (semaines 3-5)

L’article 13.6 de DORA impose des programmes de formation « obligatoires pour l’ensemble du personnel et des dirigeants ». Ce n’est pas une recommandation.

Un programme conforme à DORA comprend :

Des simulations de phishing régulières (mensuelles ou bimensuelles) adaptées aux menaces du secteur financier : fraude au virement, usurpation d’identité de l’ACPR ou de clients, compromission de messagerie professionnelle
Des micro-formations déclenchées après chaque simulation pour renforcer les réflexes de détection
Une formation spécifique des dirigeants couvrant leur capacité à évaluer les risques TIC (article 5.4)
Une documentation des résultats : taux de participation, taux de clic, évolution dans le temps, actions correctives

Testez la sécurité email de votre organisation pour évaluer votre niveau de protection technique avant de lancer votre programme de sensibilisation humaine.

Pour savoir si votre programme produit des résultats, consultez notre guide pour mesurer l’efficacité de la sensibilisation.

Étape 6 — Documentez vos procédures d’incident (semaines 4-6)

DORA exige une capacité de détection, de classification et de notification des incidents. Votre plan de réponse aux incidents doit couvrir :

Les critères de classification (qu’est-ce qui constitue un incident « majeur » ?)
La chaîne d’alerte interne (qui prévient qui ?)
Les délais de notification à l’ACPR (4 heures pour la notification initiale, 72 heures pour le rapport intermédiaire)
Les responsabilités de chaque intervenant

Testez cette procédure au moins une fois par an avec un exercice de simulation.

Étape 7 — Planifiez vos tests de résilience (semaines 5-8)

L’article 25 exige des tests réguliers. Pour une PME financière :

Tests de vulnérabilité annuels sur les systèmes exposés (serveurs, applications web, accès distants)
Simulations de phishing continues (couvertes par l’étape 5)
Tests de restauration de sauvegardes : vérifiez au moins deux fois par an que vos sauvegardes fonctionnent réellement

Les tests de pénétration avancés (TLPT) ne sont obligatoires que pour les entités jugées « importantes » par le régulateur. Les PME financières en sont généralement exemptées, sauf décision spécifique de l’ACPR.

Étape 8 — Négociez vos contrats prestataires (semaines 6-12)

Reprenez le registre de l’étape 3 et engagez les discussions avec vos prestataires TIC pour intégrer les clauses de l’article 30 :

Obligation de notification en cas d’incident affectant vos données ou services
Droit d’audit (vous ou un tiers mandaté pouvez vérifier les mesures de sécurité)
Plan de sortie documenté (comment récupérer vos données si vous changez de prestataire)
Niveaux de service formalisés pour la disponibilité et la sécurité

Certains grands prestataires cloud ont déjà mis à jour leurs conditions générales pour intégrer les exigences de DORA. Vérifiez les mises à jour contractuelles de vos fournisseurs avant de négocier des avenants individuels.

Ce que DORA change concrètement pour chaque type de structure

Pour un courtier en assurance

Avant DORA, un courtier en assurance n’avait pas d’obligation formelle de documenter sa sécurité informatique, de tester la résilience de ses systèmes ni de former ses collaborateurs aux cybermenaces. Les exigences se limitaient aux obligations générales du RGPD et aux recommandations de bonnes pratiques.

Avec DORA, le courtier doit :

Documenter sa gestion des risques informatiques
Former tous ses collaborateurs (y compris les commerciaux et l’assistanat) et ses dirigeants
Tenir un registre de ses prestataires IT avec des contrats conformes
Être capable de détecter, classifier et signaler un incident à l’ACPR

Le phishing ciblant le secteur financier est un risque direct pour les courtiers : leurs bases clients contiennent des informations personnelles et financières à forte valeur pour les attaquants.

Pour un CGP ou un CIF

Un conseiller en gestion de patrimoine indépendant, avec un ou deux collaborateurs, peut sembler loin des préoccupations de résilience numérique d’une grande institution financière. Pourtant, un CGP traite des données patrimoniales sensibles, utilise des plateformes de passation d’ordres et communique par email des informations confidentielles.

DORA impose au CGP de proportionner ses mesures à sa taille, mais pas de s’en exonérer. En pratique : une PSSI simplifiée, des mots de passe forts et une authentification multifacteur sur les accès critiques, une sensibilisation au phishing documentée, et des contrats à jour avec ses prestataires numériques.

Pour une fintech ou une startup agréée

Les fintechs font face à un paradoxe : elles sont souvent plus matures technologiquement que les acteurs traditionnels (infrastructure cloud native, CI/CD, monitoring avancé), mais moins structurées sur le plan de la gouvernance et de la documentation.

DORA ne sanctionne pas l’absence de technologies avancées ; il sanctionne l’absence de documentation, de processus et de preuves. Une fintech qui a une infrastructure sécurisée mais ne documente pas ses pratiques, ne forme pas ses équipes de manière traçable et n’a pas de registre de ses prestataires TIC est en non-conformité.

L’enjeu pour les fintechs est d’intégrer les exigences de DORA dans leur culture existante d’agilité sans créer une bureaucratie disproportionnée. Les programmes automatisés de simulation de phishing et de formation adaptative sont particulièrement adaptés à ce profil : ils produisent de la conformité documentée sans mobiliser une équipe conformité à temps plein.

Pour un prestataire IT du secteur financier

Même si vous n’êtes pas directement soumis à DORA, vos clients financiers vont vous transmettre des exigences contractuelles. Anticiper ces demandes est un avantage commercial.

Les prestataires IT proactifs sur DORA :

Préparent un « pack conformité DORA » pour leurs clients (documentation de sécurité, engagement de notification, plan de sortie)
Réalisent un audit de sécurité de leurs propres systèmes
Obtiennent des certifications reconnues (ISO 27001, SOC 2) qui simplifient la réponse aux questionnaires de leurs clients financiers
Intègrent les clauses de l’article 30 dans leurs conditions générales de vente

Les erreurs les plus fréquentes

Croire que la proportionnalité signifie exemption. L’article 4 de DORA prévoit que les mesures sont proportionnées à la taille, au profil de risque et à la nature des activités de l’entité. Proportionné signifie adapté en intensité. Cela ne signifie pas « optionnel pour les petites structures ». Un courtier de 10 personnes a des obligations allégées par rapport à BNP Paribas, mais il a des obligations.

Confondre formation et sensibilisation. DORA exige les deux. La formation transmet des connaissances. La sensibilisation change des comportements. Un module e-learning passé une fois par an ne constitue pas un programme de sensibilisation au sens de DORA. Les simulations de phishing régulières, avec analyse des résultats et micro-formations correctives, répondent à l’exigence de programmes « adaptés aux menaces réelles ».

Négliger la documentation. C’est l’erreur la plus courante et la plus coûteuse. L’ACPR vérifie des preuves, pas des intentions. Une politique de sécurité qui existe dans la tête du dirigeant mais pas sur papier ne vaut rien lors d’un contrôle. Un programme de formation dont on ne peut pas prouver les résultats est traité comme inexistant.

Ignorer les prestataires TIC. Beaucoup de PME financières se concentrent sur leurs propres systèmes et oublient que leur messagerie, leur CRM, leur logiciel métier et leurs sauvegardes dépendent de prestataires tiers. L’article 28 de DORA fait de la gestion de ces prestataires une obligation à part entière.

Attendre un contrôle pour agir. DORA est applicable depuis le 17 janvier 2025. Les entités qui démarrent leur mise en conformité en 2026 sont déjà en retard. L’ACPR a commencé ses vérifications et ne fera pas de différence entre une entité qui « n’était pas au courant » et une entité qui a choisi de ne pas agir.

Conclusion : DORA est une opportunité, pas seulement une contrainte

DORA impose des efforts réels aux PME du secteur financier. Mais il offre aussi un cadre structurant que beaucoup de ces structures n’auraient jamais mis en place spontanément. Un courtier en assurance qui documente sa gestion des risques informatiques, forme ses équipes au phishing et sécurise ses contrats prestataires améliore concrètement sa posture de sécurité, pas seulement sa conformité réglementaire.

Les cyberattaques ciblant le secteur financier ne font pas de distinction entre les grandes banques et les petits courtiers. Un email de phishing qui vole les identifiants d’accès à une plateforme de gestion de contrats d’assurance ne demande pas la taille de l’entreprise avant de s’exécuter. Les mesures que DORA impose protègent l’entité autant qu’elles satisfont le régulateur.

La mise en conformité DORA pour une PME financière n’est pas un projet de 18 mois ni un budget de 500 000 €. C’est un programme structuré, proportionné, qui commence par les fondamentaux : documenter, former, tester, contractualiser. Et la formation des équipes à reconnaître les menaces est le point de départ le plus immédiat et le plus mesurable.

Testez gratuitement la sécurité email de votre organisation pour évaluer votre niveau de protection technique actuel — c’est le premier diagnostic avant de structurer votre programme de conformité DORA.