Conformité DORA : la checklist des entités financières en 2026

Sommaire

• Qu'est-ce que la conformité DORA ?
• Ce que dit le texte : les articles et normes à connaître
• Qui est concerné par DORA
• Ce qui a changé en 2026
• La checklist de conformité DORA, pilier par pilier
• Là où les entités financières échouent vraiment : les identités et le parc SaaS
• Exigences DORA et couche identités et SaaS
• DORA, NIS2 et ISO 27001
• Séquence de priorisation à 90 jours
• Comment Corma aide à la conformité DORA
• FAQ

La plupart des programmes de conformité DORA ont été montés dans l'urgence avant janvier 2025. Ils ont produit des politiques, un registre d'information et une validation par le conseil. Ce qu'ils n'ont presque jamais produit, c'est une image fidèle des logiciels réellement utilisés dans l'entreprise.

Cet écart est devenu le vrai problème. Selon PwC, DORA s'applique à plus de 22 000 entités financières et prestataires de services TIC dans l'Union européenne, et 2026 est l'année où les superviseurs passent de la collecte de documents à la vérification que ces documents correspondent à la réalité. Un registre qui liste 40 fournisseurs alors que la direction financière en paie 90 n'est pas un problème de documentation. C'est un constat.

Cette checklist couvre les cinq piliers DORA avec leurs articles et leurs normes techniques, puis va plus loin que les listes habituelles : elle isole les exigences de gestion des identités, des accès et de visibilité SaaS que les entités financières de taille intermédiaire échouent systématiquement à tenir, et dit clairement lesquelles une plateforme de SaaS Management et d'IAM peut couvrir, et lesquelles non.

Qu'est-ce que la conformité DORA ?

La conformité DORA est l'état démontrable dans lequel une entité financière européenne satisfait à toutes les exigences du règlement DORA (Digital Operational Resilience Act), règlement (UE) 2022/2554, sur la gestion du risque lié aux technologies de l'information et de la communication (TIC), la notification des incidents, les tests de résilience, le risque lié aux tiers et le partage d'informations.

Le règlement s'applique depuis le 17 janvier 2025. Comme il s'agit d'un règlement et non d'une directive, il est entré en application directement, sans transposition en droit français. En France, la supervision est assurée par l'ACPR pour le secteur bancaire et assurantiel et par l'AMF pour les acteurs des marchés financiers.

La conformité se prouve par des éléments de preuve, pas par une intention. Chaque point de la checklist ci-dessous doit correspondre à un document, un journal ou un export que vous pouvez remettre à un superviseur.

Ce que dit le texte : les articles et normes à connaître

Le règlement DORA compte 64 articles. Le détail opérationnel se trouve dans les normes techniques adoptées en dessous, et c'est là que se joue l'essentiel du travail de mise en conformité.

• Règlement délégué (UE) 2024/1774 : outils, méthodes, processus et politiques de gestion du risque TIC, et cadre simplifié. C'est le texte qui contient les exigences sur la gestion des identités et le contrôle des accès.
• Règlements délégués (UE) 2024/1772 et (UE) 2025/301 : classification des incidents, contenu et délais de la notification initiale.
• Règlement d'exécution (UE) 2025/302 : modèles de notification d'incidents.
• Règlement d'exécution (UE) 2024/2956 : modèles standard du registre d'information.
• Règlements délégués (UE) 2024/1773 et (UE) 2025/532 : politique relative aux prestataires tiers TIC et sous-traitance.
• Règlement délégué (UE) 2025/1190 : tests de pénétration fondés sur la menace, applicable depuis le 8 juillet 2025.
• Règlement délégué (UE) 2024/1502 : critères de désignation d'un prestataire tiers TIC comme critique.

Structure du règlement à retenir : les articles 5 à 15 portent la gestion du risque TIC, les articles 17 à 23 les incidents, les articles 24 à 27 les tests, les articles 28 à 44 le risque tiers, et l'article 45 le partage d'informations.

Qui est concerné par DORA

DORA couvre 20 catégories d'entités financières européennes ainsi que leurs prestataires tiers de services TIC. Le périmètre est plus large que « banques et assureurs », et les exemptions plus étroites que la plupart des équipes ne le supposent.

Deux points qui piègent régulièrement :

• Le cadre simplifié de l'article 16 est réellement étroit. Il est ouvert aux entités remplissant les critères de microentreprise (moins de 10 salariés et chiffre d'affaires ou bilan inférieur à 2 millions d'euros) et à un petit nombre d'autres entités. Un établissement de paiement de 120 personnes n'y a pas droit.
• La proportionnalité de l'article 4 réduit la profondeur du cadre, pas la liste des obligations. Une entité plus petite peut mettre en place des contrôles plus légers. Elle ne peut pas se passer du registre d'information ni de la notification d'incidents.

Si vous vendez du logiciel à des entités financières, DORA vous atteint aussi. Un éditeur SaaS qui soutient une fonction critique ou importante est un prestataire tiers de services TIC, avec des obligations contractuelles, des droits d'audit à accorder et des devoirs de notification, voire une supervision européenne directe s'il est désigné critique.

Ce qui a changé en 2026

Le texte juridique n'a pas changé. La posture de supervision, oui.

• Les registres d'information ont été collectés et recoupés. Les autorités disposent désormais d'une vue sectorielle de qui dépend de quel prestataire, ce qui rend un registre incomplet facile à repérer.
• La norme TLPT est en vigueur. Le règlement délégué (UE) 2025/1190 s'applique depuis juillet 2025, et la première vague de notifications de tests de pénétration fondés sur la menace arrive en 2026.
• Les échéances de remise à niveau contractuelle sont passées. Les clauses de l'article 30 qui étaient « en cours » en 2025 sont désormais attendues signées.
• La question a changé. En 2025, les superviseurs demandaient si vous aviez un cadre. En 2026, ils demandent s'il fonctionne, et réclament la piste de preuve qui le démontre.

C'est pourquoi une checklist fondée sur les seuls documents ne suffit plus. Ce qui compte maintenant, c'est de savoir si les documents décrivent ce que les systèmes font réellement.

La checklist de conformité DORA, pilier par pilier

Pilier 1 : gestion du risque TIC et gouvernance (articles 5 à 15)

• L'organe de direction a formellement approuvé le cadre de gestion du risque TIC et en conserve la responsabilité au titre de l'article 5
• Une fonction de gestion du risque TIC existe, avec une indépendance suffisante par rapport aux opérations TIC
• Un inventaire complet des actifs TIC et de leurs interdépendances existe au titre de l'article 8, et il est maintenu plutôt que reconstruit chaque année
• Les fonctions métier sont classifiées, avec identification explicite des fonctions critiques ou importantes
• Les politiques de gestion des identités et de contrôle des accès existent dans la forme exigée par le règlement délégué (UE) 2024/1774
• Les politiques de journalisation, de chiffrement, de sécurité réseau, de gestion des changements et de sécurité RH sont documentées
• Le cadre a été revu au moins une fois au cours des 12 derniers mois, et cette revue est consignée

Pilier 2 : gestion et notification des incidents (articles 17 à 23)

• Un processus unique couvre la détection, la classification, l'escalade et l'analyse des causes racines
• La classification selon les critères du règlement délégué (UE) 2024/1772 est documentée, et non improvisée en pleine crise
• Les délais de notification sont répétés : rapport initial, rapport intermédiaire, puis rapport final aux modèles du règlement d'exécution (UE) 2025/302
• Le canal de notification vers l'ACPR ou l'AMF est testé, avec des suppléants nommés
• Un registre des incidents existe, y compris pour les incidents évalués puis classés comme non majeurs

Pilier 3 : tests de résilience opérationnelle numérique (articles 24 à 27)

• Un programme de tests fondé sur les risques s'exécute au moins une fois par an, avec évaluations de vulnérabilités, tests de scénarios et, le cas échéant, revue de code source
• Les constats alimentent un backlog de remédiation suivi, avec responsables et échéances
• Les entités dans le périmètre des tests de pénétration fondés sur la menace en ont défini le cadrage au titre du règlement délégué (UE) 2025/1190 et notifié leur autorité
• Les testeurs remplissent les conditions d'indépendance et de compétence fixées par la norme

Pilier 4 : gestion du risque lié aux tiers TIC (articles 28 à 44)

• Une stratégie documentée de gestion du risque tiers TIC couvre la sélection, l'entrée en relation, la surveillance et la sortie
• Le registre d'information est tenu au modèle officiel du règlement d'exécution (UE) 2024/2956, et il est mis à disposition de l'autorité compétente chaque année et sur demande
• Les contrats portant sur des fonctions critiques ou importantes contiennent les clauses obligatoires de l'article 30 : droits d'audit et d'accès, exigences de sécurité, encadrement de la sous-traitance, droits de résiliation
• Le risque de concentration est évalué, y compris le cas où plusieurs fournisseurs apparemment distincts tournent sur le même cloud sous-jacent
• Des plans de sortie existent pour les fonctions critiques ou importantes, et ils ont été testés plutôt que rédigés

Pilier 5 : partage d'informations et de renseignement (article 45)

• La décision d'adhérer ou non à un dispositif de partage de renseignement sur les menaces est documentée, dans un sens comme dans l'autre
• En cas d'adhésion, le dispositif respecte la confidentialité et les règles du RGPD
• Le renseignement reçu alimente le processus de gestion du risque TIC plutôt qu'une boîte mail que personne ne lit

Là où les entités financières échouent vraiment : les identités et le parc SaaS

Tout ce qui précède existe dans une dizaine d'autres articles. Cette section est celle sur laquelle les constats de supervision se jouent réellement.

Pourquoi un registre d'information incomplet commence par du shadow IT

L'article 28 exige un registre de toutes les dispositions contractuelles portant sur des services TIC. L'article 8 exige un inventaire des actifs TIC et de leurs dépendances. Les deux supposent que vous savez ce qui tourne.

En pratique, le registre est assemblé à partir des données achats et de l'outil comptable. Cette méthode capte tout ce qui a été acheté via un bon de commande et rate tout le reste : l'outil d'analyse qu'une équipe a démarré sur une carte bancaire, l'assistant IA que quelqu'un a connecté au CRM par une autorisation OAuth, le compte de partage de fichiers hérité d'une acquisition. C'est la prolifération SaaS, et sous DORA elle cesse d'être un problème de coûts pour devenir un problème réglementaire.

Le mode de défaillance est précis. Votre registre est complet et exact sur les fournisseurs que vous connaissez. La question du superviseur porte sur ceux que vous ne connaissez pas. Une découverte SaaS continue est le seul moyen d'y répondre honnêtement, car un audit ponctuel est déjà périmé la semaine suivant sa clôture.

Ce que DORA exige réellement sur la gestion des identités et des accès

C'est l'exigence que la plupart des checklists compressent en une ligne, alors qu'elle est bien plus prescriptive.

Le règlement délégué (UE) 2024/1774 impose aux entités financières d'élaborer, de documenter et de mettre en œuvre des politiques de gestion des identités garantissant l'identification et l'authentification uniques de chaque personne et de chaque système accédant à leurs informations, afin d'attribuer correctement les droits d'accès. Il exige que les enregistrements de toutes les attributions d'identité soient conservés après une réorganisation ou après la fin d'une relation contractuelle. Et il indique que les entités devraient déployer des solutions automatisées pour le processus de cycle de vie des identités lorsque cela est réalisable et approprié.

Relisez ce dernier point. La norme ne se contente pas d'autoriser l'automatisation de la gouvernance des identités. Elle l'attend là où elle est raisonnablement disponible. Pour une entité de taille intermédiaire qui exploite 80 à 200 applications SaaS avec deux personnes à la DSI, un tableur trimestriel est difficile à défendre comme méthode appropriée.

Comptes orphelins et trous dans l'offboarding

Un compte orphelin est un compte actif appartenant à une personne qui a quitté l'organisation ou changé de poste. Sous DORA, il heurte trois exigences à la fois : le moindre privilège de l'article 9, l'exactitude de l'inventaire de l'article 8, et le contrôle démontrable des droits d'accès exigé par le RTS.

Ces comptes s'accumulent pour une raison banale. L'offboarding est généralement fiable dans le fournisseur d'identité, et peu fiable partout où le fournisseur d'identité ne va pas : outils sans SCIM, applications à identifiants locaux, consoles d'administration configurées avant la mise en place du SSO. Le déprovisionnement automatisé sur l'ensemble du parc, et pas seulement sur le sous-ensemble fédéré, est ce qui ferme cet écart.

Une piste d'audit que vous ne pouvez pas produire à la demande

L'article 10 et le RTS sur la gestion du risque TIC exigent une journalisation suffisante pour détecter et reconstituer les événements. Dans un contexte de revue des accès, cela veut dire pouvoir montrer qui a accordé une habilitation précise, quand, sur quelle approbation, et quand elle a été retirée.

La plupart des équipes savent reconstituer cela. Peu savent l'exporter en une après-midi. La nuance compte, car un contrôle dont vous ne pouvez pas apporter la preuve rapidement est traité, en pratique, comme un contrôle qui ne fonctionnait pas. Des revues d'accès automatisées avec export par campagne transforment un exercice de reconstitution en un simple rapport.

Exigences DORA et couche identités et SaaS

Les contenus éditeurs sur DORA laissent souvent entendre qu'une seule plateforme couvre les cinq piliers. Aucune ne le fait. Voici la version honnête, qui est aussi la plus utile quand il s'agit de décider où affecter un budget.

Le constat est net. Une plateforme convergée SaaS Management et IAM fait un vrai travail sur le pilier 1 et le pilier 4, apporte des éléments de preuve sur le pilier 2, et ne fait rien du tout sur les piliers 3 et 5. Tout éditeur qui affirme le contraire est en train de vendre, pas de conseiller.

DORA, NIS2 et ISO 27001

Les entités financières affrontent rarement DORA seul. Beaucoup entrent aussi dans le périmètre de NIS2, et beaucoup détiennent ou visent une certification ISO/IEC 27001. DORA étant le régime sectoriel spécifique, il prévaut sur NIS2 pour les entités financières là où les deux se recouvrent.

L'enseignement pratique : la couche de contrôles est largement commune. Inventaire des actifs, gestion des identités, revues d'accès et journalisation satisfont l'article 9 de DORA, les exigences NIS2 équivalentes, et les contrôles 5.15 à 5.18 et 8.2 à 8.5 de l'annexe A d'ISO/IEC 27001:2022. Construisez le contrôle une fois, puis présentez la preuve dans trois habillages différents. Notre guide d'implémentation ISO 27001 et IAM détaille le parcours de certification, et notre feuille de route sur les revues d'accès utilisateurs détaille le cycle de revue lui-même.

Séquence de priorisation à 90 jours

Si votre programme DORA est documenté mais pauvre en preuves, l'ordre des opérations compte plus que l'effort fourni.

Comment Corma aide à la conformité DORA

Corma est une plateforme européenne qui réunit SaaS Management et gestion des identités et des accès dans un seul produit, ce qui correspond exactement à la combinaison que la couche de contrôles DORA réclame. La découverte et la gouvernance des accès vivent dans le même système, si bien que l'inventaire d'actifs qui alimente l'article 8 et le registre qui alimente l'article 28 sont construits à partir des mêmes données vivantes, au lieu d'être rapprochés à la main.

Ce que cela change pour un programme DORA :

• La découverte SaaS continue fait apparaître les applications qui manquent à votre registre d'information, y compris les outils achetés hors DSI
• Les flux automatisés d'arrivée, de mobilité et de départ délivrent l'automatisation du cycle de vie des identités que le RTS attend
• Des campagnes de revue des accès planifiées avec validation par le propriétaire de l'application et preuve exportable par cycle
• Une piste d'audit complète des octrois, approbations et révocations d'accès, prête à exporter
• La visibilité sur les contrats et les renouvellements, pour que la remise à niveau au titre de l'article 30 ne soit pas découverte le jour du renouvellement
• Un hébergement européen conforme au RGPD et la certification ISO/IEC 27001:2022, ce qui compte puisque sous DORA votre propre prestataire fait partie de votre risque tiers

Ce dernier point mérite d'être souligné. Ajouter un outil hébergé aux États-Unis pour résoudre un problème DORA ajoute une question de transfert de données et une entrée de plus à défendre dans votre registre d'information. Corma est conçu et hébergé en Europe, et a été reconnu dans le Gartner® Magic Quadrant™ 2025 des SaaS Management Platforms.

Corma pour les équipes sécurité montre comment conformité et gouvernance des accès fonctionnent ensemble. Pour un exemple en secteur régulé, voyez comment Satelia pilote sa gouvernance des identités dans la santé, et notre page sécurité documente l'hébergement, les certifications et les sous-traitants que votre propre évaluation fournisseur va demander.

Envie de savoir ce qui manque à votre registre d'information ? Demandez une démo et nous lançons une découverte sur votre parc.

FAQ

Quels sont les 5 piliers de la conformité DORA ?

Les cinq piliers sont la gestion du risque TIC et la gouvernance (articles 5 à 15), la gestion, la classification et la notification des incidents liés aux TIC (articles 17 à 23), les tests de résilience opérationnelle numérique (articles 24 à 27), la gestion du risque lié aux tiers TIC (articles 28 à 44), et le partage d'informations et de renseignement (article 45). Les quatre premiers sont obligatoires. Le partage d'informations est volontaire, mais la décision doit être documentée.

La conformité DORA est-elle obligatoire ?

Oui. DORA est juridiquement contraignant pour les entités financières européennes concernées depuis le 17 janvier 2025. Étant un règlement européen, il s'applique directement, sans étape de transposition nationale, ce qui explique l'absence de période de grâce propre à la France.

Quelles sont les sanctions en cas de non-conformité à DORA ?

Les entités financières sont sanctionnées par leur autorité nationale compétente, en France l'ACPR ou l'AMF, qui peut prononcer des mesures administratives et des sanctions pécuniaires, imposer une remédiation et, dans les cas graves, restreindre l'activité. Les prestataires tiers de services TIC désignés critiques relèvent de la supervision européenne et peuvent se voir infliger des astreintes fixées à 1 % de leur chiffre d'affaires mondial journalier moyen de l'exercice précédent, appliquées chaque jour pendant six mois au maximum jusqu'à mise en conformité.

Qu'est-ce que le registre d'information au sens de DORA ?

Le registre d'information est un inventaire structuré de toutes les dispositions contractuelles qu'une entité financière a conclues avec des prestataires tiers de services TIC, tenu selon les modèles standard du règlement d'exécution (UE) 2024/2956. Il doit être mis à disposition de l'autorité compétente chaque année et sur demande. C'est la première source de constats, parce qu'il n'est jamais plus exact que la visibilité de l'entité sur son propre parc logiciel.

DORA exige-t-il une gestion des accès automatisée ?

Pas dans ces termes, mais presque. Le règlement délégué (UE) 2024/1774 impose des politiques documentées de gestion des identités et de contrôle des accès, la conservation des enregistrements d'attribution d'identité après le départ des personnes, et indique que les entités devraient recourir à des solutions automatisées pour le processus de cycle de vie des identités lorsque cela est réalisable et approprié. Pour une entité qui exploite des centaines d'applications SaaS, la revue manuelle est de plus en plus difficile à présenter comme appropriée.

Quelle est la différence entre DORA et le RGPD ?

Les deux textes ne gouvernent pas la même chose. Le RGPD protège les données à caractère personnel et s'applique à toute organisation qui traite les données de personnes situées dans l'Union européenne. DORA gouverne la résilience opérationnelle numérique et s'applique spécifiquement aux entités financières européennes et à leurs prestataires TIC. Une entité peut être parfaitement conforme au RGPD et échouer sur DORA, parce que DORA porte sur la capacité à absorber une perturbation TIC et à s'en remettre, pas sur la licéité du traitement des données.

DORA s'applique-t-il aux entreprises britanniques ou américaines ?

Pas directement, mais l'effet d'entraînement est fréquent. DORA lie les entités financières opérant dans l'Union européenne et les prestataires TIC qui les servent. Un éditeur britannique ou américain qui soutient une fonction critique ou importante d'une entité financière européenne hérite d'obligations contractuelles, de droits d'audit et de devoirs de notification par l'article 30, et peut être désigné prestataire tiers TIC critique et placé sous supervision européenne directe.

Une entité financière de taille intermédiaire peut-elle utiliser le cadre simplifié ?

En général non. Le cadre simplifié de gestion du risque TIC de l'article 16 visé les microentreprises, soit moins de 10 salariés et un chiffre d'affaires ou un bilan inférieur à 2 millions d'euros, plus un petit nombre d'autres entités. Une entité financière de 50 à 500 personnes est dans le périmètre complet, et la proportionnalité de l'article 4 ajuste la profondeur des contrôles sans supprimer d'obligations.