Guide · Conformité DORA
Un établissement financier, une société de gestion ou un prestataire informatique qui travaille pour le secteur financier reçoit des demandes précises : une clause à revoir dans un contrat, un registre des fournisseurs à tenir, un plan de continuité à montrer. Cette page explique ce que recouvre la conformité au règlement européen DORA, ce qu’il demande concrètement, à quel moment faire appel à un spécialiste, et comment comparer les propositions.
Sommaire
La conformité DORA, c’est quoi ?
Un règlement européen sur la résilience numérique
DORA, pour Digital Operational Resilience Act, est un règlement de l’Union européenne sur la résilience opérationnelle numérique du secteur financier. Il ne désigne ni un outil ni une technique : il fixe un cadre commun de gestion des risques liés aux technologies de l’information et de la communication (TIC). Il s’applique directement aux entités financières qu’il vise et organise la manière dont elles maîtrisent leurs systèmes, leurs incidents et leurs fournisseurs.
Les grands blocs du texte
Le règlement regroupe plusieurs exigences : la gouvernance et la gestion du risque TIC, la classification et la notification des incidents liés aux TIC, les tests de résilience, la gestion des prestataires TIC tiers avec un registre d’informations, et le partage d’informations sur les menaces. L’organe de direction de l’entité en porte la responsabilité. Le sujet ne peut donc pas être traité comme une affaire purement informatique.
Le cas des prestataires
Un prestataire de services TIC n’est pas forcément une entité financière. Il se trouve pourtant concerné par ricochet : ses clients financiers doivent encadrer leurs contrats avec lui et lui demandent, en retour, des engagements, des preuves et des informations. Pour ce prestataire, la conformité se joue dans les contrats et dans sa capacité à répondre aux questionnaires. Le périmètre exact se vérifie au cas par cas avec le conseil juridique de l’entreprise ou avec l’autorité de supervision compétente, comme l’ACPR ou l’AMF.
Quand faut-il s’en occuper ?
Le sujet arrive rarement sous le nom du règlement. Il apparaît à travers des situations concrètes :
- Une clause ajoutée au contrat : un client financier demande de nouvelles garanties sur la sécurité, la continuité ou la réversibilité, et le contrat en cours ne les prévoit pas.
- Une direction qui doit valider un cadre inconnu : l’organe de direction est appelé à approuver une démarche dont il ne connaît pas encore les exigences, et personne ne sait par où commencer.
- Un registre des prestataires incomplet : les contrats informatiques sont répartis entre plusieurs services, et la liste des fournisseurs ne correspond plus à la réalité.
- Des sous-traitants en cascade : le prestataire principal fait appel à d’autres intervenants que l’entreprise n’a jamais identifiés.
- Un plan de continuité jamais essayé : il existe sur le papier, mais personne ne sait s’il tiendrait lors d’une panne réelle.
- Des incidents traités à la volée : sans classification ni trace écrite, il est difficile de savoir ce qui doit être signalé, et à qui.
- Une dépendance sans sortie : un service essentiel repose sur un seul fournisseur, sans solution documentée s’il faut changer.
- Un questionnaire envoyé par un client : la réponse engage l’entreprise et appelle des preuves, pas seulement des déclarations.
Comment se déroule un projet
Une démarche de mise en conformité commence par un diagnostic, se poursuit par la remise à niveau des dispositifs, puis se maintient dans la durée.
Avant la mission
Le cadrage porte d’abord sur l’applicabilité : quelle entité est concernée, à quel titre (entité financière ou prestataire TIC), et quels points doivent être confirmés avec le conseil juridique. Il délimite ensuite le périmètre des systèmes et des activités critiques, et établit la liste des fournisseurs et des contrats à examiner.
Pendant la mission
L’analyse d’écart compare les pratiques actuelles aux exigences du règlement et de ses normes techniques, domaine par domaine. Le cadre de gestion du risque TIC, la cartographie des actifs et des dépendances, la procédure de classification des incidents et le plan de continuité sont ensuite rédigés ou repris. Pour les contrats, le registre des prestataires est constitué et les clauses sont revues avec les services concernés.
Après la mise en place
Le dispositif se maintient : exercices sur le plan de continuité, simulations d’incidents, mise à jour du registre à chaque changement de contrat, comptes rendus à l’organe de direction. Un dispositif jamais testé ne peut pas démontrer son efficacité devant une autorité de supervision ou un client exigeant.
Ce qui distingue une bonne offre
Le montant dépend de la position de l’entreprise, de sa taille, de la maturité de ses pratiques et du nombre de contrats à revoir. Trois points permettent de comparer deux propositions.
Le premier est la méthode d’applicabilité. Une proposition sérieuse commence par établir la position de l’entreprise et indique ce qui reste à confirmer avec le conseil juridique. Une offre qui affirme d’emblée qu’une entreprise est soumise au règlement, ou qu’elle en est exemptée, mérite des questions.
Le deuxième est la nature du livrable. Un registre des prestataires, des procédures et un plan de tests doivent pouvoir être utilisés par les équipes après la mission, et pas seulement lus le jour de la remise. La question à poser : qui mettra ces documents à jour, et avec quel outil ?
Le troisième est la place laissée à l’entreprise. Les choix d’organisation, la validation par la direction et les échanges avec l’autorité de supervision restent du ressort de l’entreprise. Un intervenant qui propose de décider à sa place crée une dépendance, alors que le règlement attend une responsabilité interne identifiée.
Les erreurs fréquentes
- Traiter DORA comme un sujet purement informatique. L’organe de direction reste responsable des décisions. Il faut un cadre validé par la direction et un compte rendu écrit de chaque arbitrage.
- Un registre des prestataires qui ignore les sous-traitants. Les contrats directs ne suffisent pas. Il faut demander à chaque fournisseur la liste de ses propres intervenants et les intégrer au registre.
- Une stratégie de sortie absente. Pour chaque service jugé essentiel, il faut documenter comment le remplacer ou le rapatrier, même si cette sortie n’est jamais utilisée.
- Un plan de continuité jamais essayé. Il faut organiser un exercice, noter ce qui a échoué et corriger le plan en conséquence.
- Des incidents traités sans trace. Chaque incident doit donner lieu à une fiche : date, impact, classification, décisions prises et personnes informées.
Les questions à poser avant de signer
Avant de confier une mission ou de signer un contrat, quelques questions permettent de vérifier le sérieux de la démarche.
Comment l’applicabilité du règlement à l’entreprise est-elle établie, et avec qui ? Une réponse qui associe le conseil juridique ou l’autorité compétente est un bon signe. Une réponse qui tranche sans justifier appelle des précisions.
L’analyse d’écart s’appuie-t-elle sur le règlement et sur ses normes techniques ? Le livrable doit indiquer les écarts domaine par domaine, avec leur priorité.
Comment le registre des prestataires TIC est-il constitué, qui le tient à jour, et que se passe-t-il quand un contrat change ? La réponse dit beaucoup de la capacité à tenir la conformité dans la durée.
Le conseil juridique de l’entreprise est-il associé aux points d’interprétation, et qui valide les conclusions finales ? Les choix d’interprétation ne doivent pas reposer sur le seul prestataire.