DORA pour les établissements de paiement et les EME en 2026
Ce que le règlement sur la résilience opérationnelle numérique exige des établissements de paiement et de monnaie électronique en 2026 : champ d'application et cadre simplifié pour les petits établissements, risque lié aux TIC, notification des incidents, tests, registre d'informations, contrats TIC et questions à poser à votre fournisseur de core banking.
DORA en un paragraphe
Le règlement sur la résilience opérationnelle numérique, règlement (UE) 2022/2554, s'applique depuis le 17 janvier 2025. Comme il s'agit d'un règlement, il est directement applicable dans chaque État membre, sans transposition nationale. Pour un établissement de paiement ou de monnaie électronique, il couvre cinq domaines : la gestion du risque lié aux TIC, la notification des incidents liés aux TIC, les tests de résilience, la gestion du risque lié aux prestataires tiers de services TIC et le partage d'informations sur les cybermenaces.
Les règles détaillées figurent dans des normes techniques adoptées par la Commission sur proposition des trois Autorités européennes de surveillance (ABE, AEMF et AEAPP). Celles qu'un EP ou un EME rencontre le plus souvent sont les RTS sur le cadre de gestion du risque lié aux TIC (règlement délégué (UE) 2024/1774), les RTS sur la politique contractuelle relative aux services TIC (2024/1773), les ITS sur le registre d'informations (règlement d'exécution (UE) 2024/2956) et les RTS sur la notification des incidents (règlement délégué (UE) 2025/301).
DORA relève du droit de l'Union. Une entreprise britannique agréée par la FCA n'y est pas soumise et applique à la place les règles de résilience opérationnelle de la FCA. En revanche, un groupe britannique doté d'une filiale dans l'UE doit appliquer DORA dans cette filiale.
Vous bâtissez une activité sur cet agrément ?
Découvrez ce que la plateforme couvre : les questions IT du régulateur, les rails de paiement, les prestataires et la partie technique de votre dossier.
- Core banking pour les EME lituaniens
- Banque digitale pour EME luxembourgeois
- Banque digitale pour EME portugais
Qui est concerné, et qui bénéficie du régime allégé
L'article 2, paragraphe 1, vise les établissements de paiement et les établissements de monnaie électronique, y compris ceux qui bénéficient d'une exemption au titre de la DSP2 et de la directive sur la monnaie électronique. Les prestataires de services d'information sur les comptes sont mentionnés séparément. Autrement dit, être petit ne vous fait pas sortir de DORA. La taille change seulement la part du texte qui s'applique.
| Type d'établissement | Cadre de gestion du risque lié aux TIC | Tests | Risque lié aux tiers |
|---|---|---|---|
| EP ou EME agréé | Cadre complet au titre des articles 5 à 15. | Un programme de tests, avec des tests annuels des systèmes qui soutiennent des fonctions critiques ou importantes. | Stratégie en matière de risque lié aux tiers, registre d'informations, contrats conformes à l'article 30, plans de sortie. |
| EP exempté (petit) au titre de l'art. 32 DSP2 ou petit EME au titre de l'art. 9 DME | Cadre simplifié au titre de l'article 16, précisé au titre III des RTS 2024/1774. | Tests réguliers des plans de continuité et des contrôles au titre de l'article 16. | Pas de stratégie formelle en matière de risque lié aux tiers, mais le registre d'informations et les règles contractuelles s'appliquent toujours. |
| Microentreprise (moins de 10 salariés et chiffre d'affaires ou total de bilan jusqu'à EUR 2 millions) | Cadre complet, appliqué de manière proportionnée, avec plusieurs règles spécifiques allégées. | Plan de tests fondé sur les risques, sans exigence de testeur indépendant. | Mêmes obligations essentielles. Les droits d'audit peuvent être délégués à un tiers désigné par le prestataire. |
Un point est souvent mal compris. Le cadre simplifié de l'article 16 concerne les établissements exemptés, c'est-à-dire les petits EP et petits EME enregistrés au titre des dérogations nationales. Un EME pleinement agréé de cinq salariés est une microentreprise, pas une entité relevant de l'article 16, et reste soumis au cadre complet, appliqué de manière proportionnée.
Gestion du risque lié aux TIC : ce que le cadre doit contenir
L'organe de direction est responsable du risque lié aux TIC et approuve le cadre. En pratique, le régulateur cherchera les documents suivants et la preuve qu'ils sont réellement utilisés :
- Cadre de gestion du risque lié aux TIC et stratégie de résilience opérationnelle numérique, réexaminés au moins une fois par an et après tout incident majeur.
- Inventaire des actifs. Systèmes, données, ressources réseau et fonctions métier qu'ils soutiennent, avec les fonctions critiques ou importantes identifiées.
- Politiques de sécurité. Contrôle d'accès, chiffrement et gestion des clés, gestion des changements, correctifs, journalisation, sécurité réseau.
- Détection et réponse. Comment les anomalies sont repérées, qui est alerté, comment un incident est classé.
- Plans de continuité d'activité et de rétablissement des TIC, avec sauvegardes, restauration et objectifs de délai de rétablissement, testés selon un calendrier.
- Formation. Sensibilisation du personnel à la sécurité et formation de la direction à la résilience numérique.
Si vous fonctionnez sur la plateforme d'un fournisseur, une grande partie des preuves concernant l'inventaire des actifs, les contrôles de sécurité et le rétablissement vient de ce fournisseur. La responsabilité, elle, ne se transfère pas : l'article 28, paragraphe 1, laisse l'entité financière pleinement responsable du respect de ses obligations à tout moment.
Notification des incidents majeurs : le compte à rebours
Un incident lié aux TIC doit être notifié lorsqu'il remplit les critères d'incident majeur fixés par les RTS de classification : clients touchés, durée, pertes de données, services critiques affectés, impact économique et étendue géographique. Pour les acteurs du paiement, ce dispositif a remplacé le régime de notification des incidents majeurs de la DSP2 : l'ABE a abrogé ses orientations DSP2 sur les incidents le 17 janvier 2025.
| Rapport | Délai au titre du règlement délégué (UE) 2025/301 |
|---|---|
| Notification initiale | Dans les 4 heures suivant la classification de l'incident comme majeur, et au plus tard 24 heures après en avoir eu connaissance. |
| Rapport intermédiaire | Dans les 72 heures suivant la notification initiale, même si rien n'a changé, puis à chaque évolution significative de la situation. |
| Rapport final | Au plus tard un mois après le dernier rapport intermédiaire, une fois l'analyse des causes profondes terminée. |
L'article 19 prévoit deux obligations supplémentaires. Si un incident majeur affecte les intérêts financiers des clients, vous devez les en informer sans retard injustifié, en précisant les mesures que vous prenez. Vous pouvez par ailleurs confier la notification à un prestataire, mais vous en restez pleinement responsable. Pour un établissement qui s'appuie sur la plateforme d'un fournisseur, cela signifie que le contrat doit obliger ce fournisseur à vous signaler les incidents assez vite pour que vous teniez les délais de 4 et 24 heures.
Tests de résilience
Tout EP ou EME qui n'est pas une microentreprise doit disposer d'un programme de tests de résilience opérationnelle numérique (article 24). L'article 25 énumère les outils : analyses de vulnérabilité, évaluations de la sécurité des réseaux, revues du code source lorsque c'est faisable, tests fondés sur des scénarios, tests de performance et de bout en bout, et tests de pénétration. Les systèmes qui soutiennent des fonctions critiques ou importantes doivent être testés au moins une fois par an, par des testeurs indépendants des équipes qui les ont conçus.
Les tests de pénétration fondés sur la menace (TLPT) de l'article 26 sont une autre affaire. Ils ne sont exigés que des entités désignées par les autorités compétentes, environ tous les trois ans, et les entités relevant de l'article 16 ainsi que les microentreprises en sont exclues. La plupart des établissements de paiement et de monnaie électronique ne seront pas sélectionnés. Si vous l'êtes, le test doit porter sur les systèmes de production réels, y compris ceux exploités par vos prestataires TIC. C'est pourquoi les contrats conformes à l'article 30 prévoient une obligation d'y participer.
Le registre d'informations
L'article 28, paragraphe 3, impose à toute entité financière, petites structures comprises, de tenir un registre d'informations sur tous les accords contractuels portant sur des services TIC, en signalant ceux qui soutiennent des fonctions critiques ou importantes. Le format est fixé par le règlement d'exécution (UE) 2024/2956 : un ensemble de tableaux liés qui couvrent l'entité, chaque contrat, chaque prestataire et ses sous-traitants, les fonctions soutenues et l'évaluation de chaque service.
Date de référence
À partir de 2026, le registre reflète les contrats en vigueur au 31 décembre de l'année précédente.
Votre échéance
Fixée par votre autorité nationale, avant l'échéance des AES. La CSSF luxembourgeoise, par exemple, a collecté les registres 2026 entre le 11 février et le 31 mars.
Échéance des AES
Les autorités nationales transmettent les registres aux AES au plus tard le 31 mars de chaque année.
Le registre n'est pas qu'un fichier annuel. Votre autorité peut le demander à tout moment, et vous devez l'informer en temps utile de tout projet de contrat portant sur des services TIC qui soutiennent une fonction critique ou importante. Les AES se sont aussi appuyées sur les registres pour choisir les prestataires qu'elles supervisent désormais directement. Sources : les AES sur le calendrier du registre, fenêtre de dépôt 2026 de la CSSF.
Contrats avec les prestataires TIC et stratégies de sortie
L'article 30, paragraphe 2, fixe le contenu minimal de tout contrat TIC : une description complète des services et la possibilité ou non de sous-traiter, les lieux où les services sont fournis et où les données sont stockées, la protection des données, l'accès aux données et leur restitution en cas d'insolvabilité ou de résiliation, les niveaux de service, l'assistance en cas d'incident lié aux TIC sans coût supplémentaire ou à un prix convenu à l'avance, la coopération avec vos autorités, les droits de résiliation et la participation à vos formations à la sécurité.
Pour les services qui soutiennent des fonctions critiques ou importantes, l'article 30, paragraphe 3, ajoute des niveaux de service précis avec des objectifs quantitatifs, des obligations de préavis et de reporting, les plans de continuité et les mesures de sécurité propres au prestataire, la participation aux TLPT, des droits illimités d'accès, d'inspection et d'audit pour vous et votre régulateur, et une stratégie de sortie assortie d'une période de transition obligatoire.
La stratégie de sortie est votre document, pas celui du fournisseur. L'article 28, paragraphe 8, vous demande de pouvoir quitter un prestataire sans perturber l'activité, sans manquer à vos obligations réglementaires et sans léser les clients, de disposer d'un plan de sortie documenté et testé, et de savoir comment les données et les services seraient transférés vers un autre prestataire ou réinternalisés. Pour une plateforme de core banking, cela suppose des formats d'export convenus pour les fiches clients, les soldes et l'historique des transactions, ainsi qu'une période de transition assez longue pour mener une migration.
Prestataires tiers critiques de services TIC
Le 18 novembre 2025, les AES ont publié la première liste des prestataires tiers critiques de services TIC (CTPP) au titre de l'article 31. Selon Morgan Lewis, elle compte 19 prestataires, pour l'essentiel de grands acteurs du cloud, des centres de données, des réseaux et des logiciels d'entreprise. Chacun dispose désormais d'un superviseur principal parmi les AES, doté de pouvoirs d'inspection directs.
Cette supervision ne remplace pas votre propre travail. Si votre plateforme tourne chez un hyperscaler désigné comme CTPP, vous devez toujours évaluer le risque, maintenir les clauses contractuelles et inscrire le fournisseur cloud comme sous-traitant dans votre registre. La plupart des fournisseurs de core banking ne sont pas désignés, et les obligations des articles 28 à 30 s'appliquent pleinement à eux par l'intermédiaire de votre contrat.
Les questions à poser à votre fournisseur de core banking
Une plateforme de core banking soutient presque toutes les fonctions critiques d'un EP ou d'un EME : comptes, paiements, données clients. Avant de signer, ou avant votre prochain cycle de registre, obtenez des réponses claires à ces questions.
| Question | Pourquoi c'est important au titre de DORA |
|---|---|
| Où la plateforme est-elle hébergée, où les données sont-elles stockées et qui sont les sous-traitants ? | Les lieux et la sous-traitance doivent figurer dans le contrat (art. 30, par. 2) et dans votre registre. |
| En combien de temps serons-nous informés d'un incident, et par quel canal ? | Vous disposez de 4 heures après la classification et de 24 heures après en avoir eu connaissance pour envoyer la notification initiale. |
| Quels sont les niveaux de service, chiffrés ? | L'article 30, paragraphe 3, exige des objectifs quantitatifs que vous pouvez suivre. |
| Pouvons-nous vous auditer, nous, notre auditeur et notre régulateur ? | Des droits illimités d'accès, d'inspection et d'audit sont obligatoires pour les services critiques. |
| Quels objectifs de rétablissement testez-vous, et pouvons-nous voir les résultats ? | Vos plans de continuité dépendent des sauvegardes et de la restauration du fournisseur. |
| Dans quel format récupérons-nous nos données, et quelle est la durée de la période de transition ? | Les stratégies de sortie et la restitution des données sont exigées par les articles 28, paragraphe 8, et 30. |
| Participerez-vous à nos tests de résilience ? | Les tests, et les TLPT si vous êtes sélectionné, couvrent aussi les systèmes externalisés. |
Le lien entre DORA et votre dossier d'agrément
DORA s'accompagne d'une directive modificative, la directive (UE) 2022/2556, qui a réécrit une partie de l'article 5, paragraphe 1, de la DSP2 sur le contenu d'un dossier d'agrément. La partie gouvernance doit désormais décrire vos dispositifs de recours aux services TIC au titre de DORA, la procédure de gestion des incidents doit refléter les obligations de notification de DORA, et les mesures de sécurité doivent démontrer un niveau élevé de résilience opérationnelle numérique au titre du chapitre de DORA sur le risque lié aux TIC. La directive sur la monnaie électronique applique également ces règles d'agrément de la DSP2 aux EME. Un candidat devient une entité financière au sens de DORA le jour de son agrément : le dossier doit donc décrire un cadre opérationnel dès le premier jour.
- Cartographiez vos fonctions. Déterminez quelles fonctions sont critiques ou importantes et quels services TIC les soutiennent.
- Préparez le registre tôt. Votre plateforme principale, votre cloud, votre prestataire KYC, votre processeur de cartes et votre partenaire bancaire doivent tous y figurer.
- Négociez les clauses de l'article 30 avant de signer. Modifier des contrats après l'agrément prend plus de temps et affaiblit le dossier.
- Construisez la procédure d'incident autour des délais réels. Intégrez-y l'engagement de notification du fournisseur.
- Préparez le plan de sortie. Montrez au régulateur comment vous quitteriez chaque prestataire critique.
Crassula est un prestataire technologique, pas un établissement régulé, et dans la plupart des configurations clients il soutient des fonctions critiques. Pour le dossier d'agrément, nous fournissons une description de l'architecture de la plateforme, de l'hébergement, des contrôles de sécurité (accès par rôles, authentification à deux facteurs, piste d'audit) et de notre processus de gestion des incidents, que vous adaptez dans vos propres sections TIC et externalisation. Le back-office et les endpoints de reporting de la plateforme vous donnent des exports de données, mais la classification des incidents, l'envoi des notifications et la tenue du registre restent de votre ressort. Pour l'agrément lui-même, consultez notre guide de l'établissement de paiement et notre guide de l'EME, ou demandez une démo.
FAQ
Oui. L'article 2 inclut les EP et EME exemptés au titre de la DSP2 et de la directive sur la monnaie électronique. Ils appliquent le cadre simplifié de gestion du risque lié aux TIC de l'article 16 au lieu des articles 5 à 15, mais doivent toujours tenir un registre d'informations et respecter les règles sur la notification des incidents et les contrats TIC.
C'est un relevé structuré de tous vos contrats de services TIC, selon le modèle fixé par le règlement d'exécution (UE) 2024/2956. À partir de 2026, la date de référence est le 31 décembre de l'année précédente et les autorités nationales transmettent les registres aux AES au plus tard le 31 mars. Votre propre échéance est fixée par votre autorité nationale et tombe plus tôt.
La notification initiale doit être envoyée dans les 4 heures suivant la classification de l'incident comme majeur, et au plus tard 24 heures après en avoir eu connaissance. Un rapport intermédiaire suit dans les 72 heures, puis un rapport final dans le mois qui suit le dernier rapport intermédiaire.
Seulement si leur autorité compétente les désigne. Les petits établissements exemptés et les microentreprises en sont totalement exclus. Tous les autres EP et EME doivent néanmoins disposer d'un programme de tests, avec au minimum des tests annuels des systèmes qui soutiennent des fonctions critiques ou importantes.
Probablement pas. La liste publiée par les AES en novembre 2025 vise surtout de grands acteurs du cloud et de la technologie. Cela ne change rien pour vous : un fournisseur qui exploite vos fonctions critiques doit quand même être lié par un contrat comportant les clauses de l'article 30, paragraphe 3, faire l'objet d'une stratégie de sortie et figurer dans votre registre.
Non. DORA relève du droit de l'Union. Un EME ou un EP britannique applique les règles de résilience opérationnelle de la FCA. Si vous détenez aussi un agrément européen via une filiale, cette filiale est soumise à DORA.
Vous informez votre autorité en temps utile du nouveau contrat portant sur une fonction critique, vous mettez à jour le registre et vous suivez votre plan de sortie pour l'ancien fournisseur. C'est pour cela que DORA demande des plans de sortie et des clauses de restitution des données avant que vous en ayez besoin.
Non. Crassula fournit la technologie et la documentation pour vos sections TIC et externalisation, ainsi que des exports de données depuis la plateforme. La classification des incidents, les notifications à votre autorité et le registre d'informations restent à la charge de votre établissement.
