Mise en conformité DORA : les étapes, de l'état des lieux au contrôle

Le règlement DORA fixe des obligations, pas une méthode de mise en œuvre. L'ordre ci-dessous suit la logique du texte : on vérifie d'abord ce qui s'applique, on installe la gouvernance qui portera le projet, on mesure l'écart, puis on construit les dispositifs pilier par pilier avant de les faire vivre.

1. Étape 1 Périmètre et régime Vérifier que l'entité est visée et quel régime s'applique.
2. Étape 2 Gouvernance Faire porter le projet par l'organe de direction.
3. Étape 3 État des lieux Comparer l'existant au règlement et aux normes techniques.
4. Étape 4 Cadre de gestion du risque TIC Documenter, cartographier, protéger, détecter, rétablir.
5. Étape 5 Incidents et tests Classer, notifier, tester chaque année.
6. Étape 6 Prestataires et registre Stratégie, registre d'information, clauses de l'article 30.
7. Étape 7 Faire vivre le dispositif Réexamen annuel, audit interne, suivi des constats.

L'article 2 liste les 20 catégories d'entités financières visées et ses exclusions. Une fois l'entité dans le champ, deux questions fixent le niveau d'exigence : le principe de proportionnalité de l'article 4, qui adapte la mise en œuvre à la taille, au profil de risque et à la complexité de l'entité, et le cadre simplifié de l'article 16, réservé à certaines petites entités (petites entreprises d'investissement non interconnectées, certains établissements de paiement et de monnaie électronique exemptés, petites institutions de retraite professionnelle…).

Dans un groupe, ce travail se fait entité par entité : une filiale peut relever du régime général, une autre du cadre simplifié, une troisième d'aucun des deux. Le chapitre entités concernées détaille ces cas.

DORA place la conformité au plus haut niveau. Selon l'article 5, l'organe de direction définit, approuve et supervise le cadre de gestion du risque lié aux TIC et en est responsable. Il fixe les rôles et responsabilités, approuve la stratégie de résilience opérationnelle numérique, la politique de continuité et les plans d'audit, et alloue un budget suffisant. Ses membres doivent maintenir leurs connaissances à jour, notamment par une formation régulière.

Hors microentreprises, l'article 6 demande aussi de confier la gestion et la surveillance du risque lié aux TIC à une fonction de contrôle disposant d'un niveau d'indépendance suffisant, pour éviter qu'une même équipe conçoive, opère et contrôle ses propres mesures.

L'état des lieux, ou analyse d'écart, compare ce qui existe déjà aux exigences du règlement et de ses normes techniques, au premier rang desquelles le règlement délégué (UE) 2024/1774 sur les outils, méthodes, processus et politiques de gestion du risque lié aux TIC. Peu d'entités partent de zéro : politiques de sécurité, plans de continuité, contrats et procédures d'incident couvrent souvent une partie des exigences.

Pour que l'exercice soit utile, chaque exigence reçoit un statut (couverte, partiellement couverte, non couverte), la preuve qui la justifie et, si besoin, une action avec un responsable et une échéance. Les écarts se hiérarchisent ensuite selon leur effet sur les fonctions critiques ou importantes.

Si l'entité suit déjà ISO 27001 ou NIS 2, les correspondances sont nombreuses : le chapitre DORA et NIS 2 explique comment mutualiser le travail.

C'est le chantier le plus lourd. Le cadre des articles 5 à 16 comprend des stratégies, politiques, procédures et outils documentés, ainsi qu'une stratégie de résilience opérationnelle numérique (article 6). Il couvre l'identification des fonctions, des actifs et des dépendances (article 8), la protection et la prévention (article 9), la détection (article 10), la continuité et le rétablissement (articles 11 et 12), puis l'apprentissage et la communication (articles 13 et 14).

La cartographie de l'article 8 est le point de départ concret : on ne protège, ne teste et ne contractualise bien que ce que l'on a identifié. Le chapitre gestion du risque lié aux TIC détaille chaque bloc.

Deux dispositifs doivent être prêts avant d'en avoir besoin. Le processus de gestion des incidents (articles 17 à 19) fixe comment détecter, classer et notifier un incident majeur, avec des délais comptés en heures : voir le chapitre incidents majeurs. Le programme de tests (articles 24 à 27) prévoit au moins chaque année des tests sur les systèmes qui soutiennent les fonctions critiques ou importantes, et un TLPT tous les trois ans pour les entités désignées : voir tests de résilience et TLPT.

L'article 28 demande, hors cadre simplifié, une stratégie relative au risque lié aux prestataires tiers de services TIC, un registre d'information de tous les accords contractuels, remis chaque année à l'autorité selon les modèles du règlement d'exécution (UE) 2024/2956, et des stratégies de sortie pour les services qui soutiennent des fonctions critiques ou importantes. L'article 30 liste les clauses que les contrats doivent contenir.

Ce chantier prend du temps parce qu'il dépend des prestataires : il faut collecter leurs informations, puis renégocier les contrats. Mieux vaut le lancer en parallèle de l'étape 4. Le chapitre prestataires et registre en donne le détail.

La conformité DORA n'est jamais acquise. L'article 6 impose de réexaminer le cadre au moins une fois par an (périodiquement pour les microentreprises), ainsi qu'après un incident majeur ou à la suite d'instructions de l'autorité ou de conclusions de tests et d'audits. Le cadre fait l'objet d'un audit interne régulier, et un processus formel de suivi doit garantir que les constats critiques sont vérifiés et corrigés à temps. Un rapport sur le réexamen est remis à l'autorité si elle le demande.

Chaque réexamen est en pratique un nouvel état des lieux : la démarche reboucle sur l'étape 3.

Lors d'un contrôle, l'ACPR ou l'AMF attend des documents datés et approuvés, pas des déclarations. Le tableau suivant récapitule les principales pièces, rattachées à leur article.