DORA mapping : des exigences aux preuves pour l’audit

Sans être une obligation explicite, le DORA mapping, ou mappage DORA, devient déterminant en cas d’audit : voici comment il relie les exigences du règlement aux processus, contrats et preuves dont votre organisation dispose déjà.

Sommaire

1. Qu’est-ce que le DORA mapping  ?
2. Pourquoi est-il nécessaire ?
3. Le DORA mapping est-il obligatoire ?
4. Processus, contrôles et responsabilités
5. Gestion des risques liés aux tiers
6. DORA mapping : ISO 27001 et NIS2

Points à retenir : DORA mapping

• Le DORA mapping relie les exigences du règlement (UE) 2022/2554 aux processus, contrôles et contrats déjà en place au sein d’une entité financière de l’UE
• Le règlement n’impose pas explicitement de mappage. Mais pour tenir les registres, gérer les contrats et préparer les audits, il devient difficile de s’en passer
• La gestion des risques liés aux tiers repose sur deux éléments : un registre central d’informations et, pour chaque prestataire TIC, une classification selon qu’il soutient ou non une fonction critique ou importante (FCI)
• La norme ISO 27001 et la directive SRI 2 (NIS2) couvrent une grande partie des exigences, mais des écarts subsistent concernant les délais de notification, les dispositions contractuelles obligatoires et les tests de pénétration
• Le tableau de bord de gestion du risque humain de SoSafe fournit les éléments de preuve permettant d’attester que la sensibilisation est adaptée aux fonctions, conformément à l’article 13, paragraphe 6

Au-delà de DORA : indicateurs et conformité en perspective

De l’évaluation de maturité à la préparation des audits, ces sujets aident les équipes informatique et sécurité à replacer le DORA mapping dans un cadre de conformité plus large et à anticiper les prochaines étapes.

Lire la suite

Glossary

Conformité DORA : exigences, checklist et risque humain

Lire la suite

Glossary

DORA

Qu’est-ce que le DORA mapping ?

Le DORA mapping, ou mappage DORA, consiste à mettre en correspondance, de manière structurée, les exigences définies dans le règlement sur la résilience opérationnelle numérique (règlement (UE) 2022/2554) avec les processus, contrôles, contrats et responsabilités effectivement en place au sein d’une entité financière. Plutôt que d’examiner les articles un à un, un mappage efficace relie chaque exigence aux dispositifs qui permettent déjà à l’organisation d’y répondre ou, au contraire, fait apparaître les points qui restent à traiter.

Trois niveaux se combinent ici : le pilier DORA auquel se rattache le domaine concerné parmi les cinq piliers du règlement (gestion du risque lié aux TIC, notification des incidents, tests de résilience opérationnelle numérique, risques liés aux prestataires tiers de services TIC et partage d’informations) ; le processus ou contrôle existant qui couvre déjà l’exigence ; et les éléments qui permettraient de le démontrer lors d’un audit, qu’il s’agisse d’un document, d’un journal ou d’une clause contractuelle. C’est ce dernier niveau qui distingue un DORA mapping d’une liste de contrôle. Une liste de contrôle confirme qu’une action est réalisée. Un mappage montre quels éléments peuvent être produits pour le prouver.

Le règlement DORA s’applique directement dans chaque État membre de l’UE depuis le 17 janvier 2025. Pour la plupart des institutions concernées, le DORA mapping n’est donc pas un projetponctuel, mais une tâche continue. De nouveaux prestataires, des processus modifiés ou des normes techniques de réglementation (RTS) mises à jour par les autorités européennes de surveillance (AES) peuvent à nouveau modifier la situation.

Pourquoi le DORA mapping est utile en pratique

Sans DORA mapping, la conformité au règlement DORA peut apparaître comme un ensemble de mesures distinctes, sans véritable lien entre elles. Chaque mesure est pertinente prise isolément, mais une fois qu’un audit commence, le fil conducteur qui les relie fait souvent défaut. Un DORA mapping structuré apporte alors des bénéfices concrets.

Les auditeurs demandent rarement si vous respectez le règlement DORA de manière générale. Vous devrez plutôt répondre à des questions précises : comment démontrez-vous le respect de l’exigence X dans le processus Y au moyen du contrôle Z ? Le DORA mapping fournit cette chaîne, allant de l’exigence à la preuve, au lieu de vous laisser l’improviser pendant l’audit.

Les écarts peuvent également être identifiés de manière plus fiable. Ce n’est qu’en mettant l’exigence en regard du processus réellement en place que l’on voit clairement ce qui manque, qu’il s’agisse d’une clause contractuelle exigée par l’article 30 mais absente d’un accord existant avec un fournisseur, ou d’une chaîne d’escalade qui ne tient pas encore compte des délais plus stricts fixés par le règlement.

La plupart des organisations réglementées répondent déjà à une grande partie des exigences du règlement DORA grâce à des cadres de référence tels que la norme ISO 27001 ou la directive NIS2, sans que ces recoupements soient nécessairement documentés. Le mappage DORA permet de les formaliser et évite de refaire deux fois le même travail.

Pour les équipes sécurité disposant de ressources limitées, c’est là que réside la valeur concrète du DORA mapping. Satisfaire à l’exigence a le même coût qu’auparavant. En revanche, en apporter la preuve lors d’un audit coûte nettement moins cher lorsque la chaîne est déjà formalisée.

Le cadre juridique : le DORA mapping est-il obligatoire ?

Non, pas explicitement. Le règlement DORA n’exige nulle part la réalisation d’un « mappage ». Cependant le règlement impose :

• un registre d’informations continuellement mis à jour couvrant tous les contrats avec des prestataires tiers de service TIC (art. 28, paragraphe 3), que les autorités de surveillance peuvent demander si nécessaire ;
• une diligence préalable avant la conclusion d’un contrat, portant notamment sur la substituabilité, le risque d’insolvabilité, la protection des données et les chaînes de sous-traitance (art. 28, paragraphe 4) ; 28(4)),
• des dispositions contractuelles minimales au titre de l’article 30 pour les contrats portant sur des « fonctions critiques ou importantes » ;
• un suivi continu des relations avec les prestataires (art. 28, paragraphe 6). 28(6)).

Dans la pratique, il est difficile de respecter ces obligations sans mettre en correspondance de manière structurée les exigences avec les processus, contrôles et éléments de preuve, notamment parce que les examens de surveillance suivent généralement exactement cette chaîne, depuis la mise à jour du registre jusqu’à la présence, dans les contrats, des clauses obligatoires prévues à l’article 30. Il est donc difficile de se passer du DORA mapping en pratique, même s’il n’est jamais désigné comme une obligation à part entière. Se contenter d’affirmer « nous respectons les exigences individuelles » sans les documenter ni les attribuer rend cette conformité nettement plus difficile à prouver.

Processus, contrôles et responsabilités dans le DORA mapping

La transposition interne d’une exigence du règlement DORA en un processus concret, qu’il existe déjà ou qu’il reste à créer, avec une attribution claire des responsabilités, est l’une des composantes les plus efficaces du DORA mapping. Sans cette étape, le DORA mapping reste un simple tableau sans réelle valeur opérationnelle.

En pratique, quatre colonnes suffisent : exigence, fonction, contrôle et preuve. Le processus de gestion des incidents montre à quoi ressemblent ces lignes.

Chacune des cinq sections du règlement DORA peut être structurée de la même manière. Aucune ligne ne doit rester sans responsable clairement identifié, qu’il s’agisse d’une personne ou d’une fonction. À défaut, la frontière entre l’informatique, la conformité et la gestion des risques devient floue, ce qui est souvent à l’origine de constats d’audit liés à la gouvernance.

Un élément est régulièrement sous-estimé dans le DORA mapping : le facteur humain. L’article 13, paragraphe 6, impose au personnel comme à la direction des actions de sensibilisation et de formation documentées et adaptées aux fonctions. Il ne s’agit pas d’un complément facultatif : ce volet mérite sa propre ligne dans le mappage, avec les éléments de preuve correspondants, comme n’importe quelle autre exigence. Pour convaincre un auditeur, il ne suffit pas de présenter un taux de participation. Il faut aussi démontrer que les contenus sont adaptés aux fonctions et que les connaissances ont été assimilées. Le tableau de bord de gestion du risque humain de SoSafe comble précisément cette lacune grâce à des contenus d’apprentissage adaptés aux fonctions et des registres exploitables en audit. Cette ligne du mappage peut ainsi être renseignée avec des données fiables plutôt qu’avec une déclaration d’intention.

Gestion des risques liés aux tiers dans le DORA mapping

Le règlement DORA laisse peu de place à l’interprétation ici : vous pouvez externaliser le service, mais pas la résilience ni le risque qui l’accompagne. Lorsqu’une fonction critique dépend d’un prestataire externe de services TIC, la responsabilité incombe à l’entité soumise au règlement DORA. Aussi complète soit-elle, la documentation de conformité d’un prestataire ne saurait se substituer à la vôtre.

En pratique, trois actions en découlent :

1. Tenir un registre central unique : le registre ne fait pas de distinction entre une plateforme cloud mondiale et un outil SaaS de niche. Tous deux figurent dans le même registre d’informations à jour prévu à l’article 28, paragraphe 3, avec l’identité du prestataire, le service fourni, les données contractuelles et la chaîne de sous-traitance associée.
2. Classer selon la criticité : le fait qu’un prestataire soutienne une fonction critique ou importante (FCI) conditionne presque tout ce qui suit. L’article 30 applique à cette catégorie de prestataires l’ensemble des clauses obligatoires supplémentaires, des droits d’audit aux stratégies de sortie et à la portabilité des données.
3. Vérifier la présence des clauses obligatoires dans les contrats : les accords existants doivent être examinés au regard des prescriptions de l’article 30. Pour les contrats-cadres plus anciens, cet examen débouche souvent sur une véritable renégociation.

Plusieurs grands prestataires de services TIC publient désormais leur propre documentation sur le règlement DORA, notamment GoTo, GitLab et SAP. Il convient de garder à l’esprit qu’il s’agit d’informations provenant du prestataire, et non de votre DORA mapping. Ce type de documents est utile pour l’examen du contrat et pour la diligence requise concernant ce prestataire. En revanche, ils ne remplacent ni votre registre d’informations couvrant l’ensemble des prestataires ni votre classification interne par niveau de criticité, que seule l’entité financière peut réaliser.

DORA mapping : ISO 27001 et NIS2

Peu d’organisations commencent leur DORA mapping entièrement de zéro. Toute entité déjà certifiée ISO 27001, ou ayant mis en œuvre les exigences de la directive NIS2, couvre déjà une part substantielle des exigences du règlement DORA. Rendre les recoupements DORA-ISO 27001 et DORA-NIS2 visibles évite les doublons et répond souvent précisément aux attentes des auditeurs.

Vue simplifiée des points de convergence entre les exigences DORA, ISO 27001 et NIS2 :

DORA et ISO 27001

C’est dans la gestion du risque lié aux TIC que la mise en correspondance entre le règlement DORA et la norme ISO 27001 est la plus utile, puisque les contrôles de l’annexe A couvrent déjà une grande partie des articles 5 à 15. Elle atteint toutefois ses limites pour les aspects que la norme ISO 27001 n’a jamais eu à traiter : les délais stricts et échelonnés après un incident et les tests de pénétration fondés sur la menace (TLPT) dans les établissements importants. Une certification existante constitue donc un excellent point de départ, mais elle ne remplace pas les éléments de preuve propres au règlement DORA.

DORA et NIS2

Avec le règlement DORA et la directive NIS2, c’est à nouveau en matière de sécurité de la chaîne d’approvisionnement et de gestion des risques que les recoupements sont les plus importants. La difficulté n’est toutefois pas la même qu’avec ISO 27001 : NIS2 est une directive, transposée différemment d’un pays à l’autre, tandis que DORA s’applique directement et de manière uniforme en tant que règlement. Pour les entités financières qui relèvent également du champ d’application de la directive NIS2, une règle supplémentaire s’applique : en tant que réglementation sectorielle, le règlement DORA prévaut en cas de doute. Formaliser cette articulation dans le DORA mapping permet d’éviter les doublons et les incohérences entre processus.

Ce guide est destiné à fournir une première orientation et ne constitue pas un avis juridique. Sources juridiques : règlement (UE) 2022/2554 (DORA), ISO/IEC 27001:2022, directive (UE) 2022/2555 (NIS2). Dernière mise à jour : septembre 2026