Enjeux et pratique
DORA a une particularité qui le distingue des réglementations de cybersécurité classiques : une partie substantielle de ses obligations est de nature contractuelle. L’article 30 du règlement liste des dispositions qui doivent figurer dans les contrats conclus avec les prestataires de services informatiques : description complète des services, lieux de traitement des données, niveaux de service, obligations d’assistance en cas d’incident, droits d’audit et d’accès, conditions de résiliation et stratégies de sortie. Les exigences sont renforcées pour les prestataires soutenant des fonctions critiques ou importantes.
Concrètement, DORA oblige les entités financières à trois exercices contractuels. Un inventaire : tenir un registre d’informations recensant tous les accords contractuels avec des prestataires TIC, registre que les superviseurs peuvent exiger. Une mise à niveau : revoir les contrats existants pour y intégrer les clauses obligatoires, ce qui suppose de savoir ce que contiennent les contrats en cours. Un suivi : surveiller l’exécution effective de ces clauses (niveaux de service, notifications d’incidents, tests), pas seulement leur présence dans le document.
C’est un cas d’école du déplacement du risque réglementaire vers le contrat : la conformité ne se joue plus seulement dans les systèmes, mais dans la capacité à produire, sur demande du régulateur, une vue exhaustive et à jour de ses engagements avec ses prestataires. Une organisation dont les contrats sont dispersés ne peut structurellement pas être conforme à DORA.
Le règlement va au-delà du contrat isolé. Il impose une analyse du risque de concentration : dépendre d’un même prestataire pour plusieurs fonctions critiques, ou d’un sous-traitant commun à toute la chaîne, est un risque en soi, que la seule qualité des clauses ne corrige pas. Il encadre aussi la sous-traitance en cascade, exige des stratégies de sortie testées et non seulement écrites, et prévoit un cadre de supervision directe des prestataires TIC jugés critiques à l’échelle européenne. La logique d’ensemble est celle d’une résilience démontrable, documents à l’appui, et non simplement affirmée.
En pratique
La mise en conformité DORA se joue moins dans la rédaction de clauses parfaites que dans la maîtrise du parc contractuel qui les porte.
Commencez par retrouver les contrats avant de les corriger. La première difficulté n’est pas juridique mais documentaire : identifier tous les prestataires TIC, retrouver la version signée de chaque contrat, repérer ceux qui n’en ont pas. Sans cet inventaire, la mise à niveau des clauses tourne à vide.
Cartographiez les clauses de l’article 30 contrat par contrat. Pour chaque accord, savoir lesquelles des stipulations obligatoires sont présentes, absentes ou insuffisantes transforme un chantier flou en plan de remédiation priorisable.
Priorisez par criticité de la fonction soutenue. Les contrats qui soutiennent des fonctions critiques ou importantes appellent les exigences les plus lourdes et méritent d’être traités en premier ; les autres suivent selon leur exposition.
Faites du registre un état vivant, pas un livrable ponctuel. Un registre exact le jour de sa production se périme au premier nouveau contrat ou avenant. L’alimenter au fil de l’eau, idéalement depuis un référentiel contractuel unique, est ce qui permet de répondre au superviseur sans reconstitution d’urgence.
Exemple concret
Une société de gestion doit produire son registre DORA. L’exercice révèle 70 prestataires TIC actifs, dont 22 sans contrat retrouvable dans sa version signée et 35 sans clause d’audit ni stratégie de sortie. La mise en conformité commence par la reconstitution du parc contractuel, avant toute renégociation des clauses.
À ne pas confondre avec
DORA porte sur la résilience opérationnelle numérique du secteur financier et se distingue de réglementations proches. Le RGPD encadre la protection des données personnelles, avec le DPA de l’article 28 comme instrument contractuel : un contrat TIC peut relever des deux, mais les objets diffèrent. La directive NIS2 vise la cybersécurité d’un champ sectoriel large, sans le même socle de clauses contractuelles imposées. Enfin, les orientations sur l’externalisation des autorités de supervision préexistaient à DORA, qui les prolonge et les durcit en règlement directement applicable.
Questions fréquentes
DORA concerne-t-il les prestataires informatiques eux-mêmes ?
Indirectement mais fortement : leurs clients financiers doivent leur imposer les clauses de l’article 30. Les prestataires critiques désignés au niveau européen sont en outre soumis à une supervision directe. Anticiper ces clauses devient un argument commercial pour un prestataire qui veut travailler avec le secteur financier.
Quelles clauses DORA rend-il obligatoires dans les contrats TIC ?
L’article 30 impose un socle de stipulations : description complète des services, localisation des traitements de données, niveaux de service, obligations d’assistance et de notification en cas d’incident, droits d’audit et d’accès, conditions de résiliation et stratégies de sortie. Les exigences sont renforcées pour les contrats soutenant des fonctions critiques ou importantes, notamment sur la réversibilité et la coopération avec les superviseurs.
Le registre d’informations DORA doit-il couvrir tous les prestataires ?
Oui, le registre doit recenser l’ensemble des accords contractuels portant sur l’usage de services TIC, actifs comme en cours de conclusion. Les superviseurs peuvent en exiger la production, ce qui suppose une vue à jour et exhaustive du parc de prestataires. Une organisation dont les contrats sont dispersés ne peut structurellement pas produire ce registre de façon fiable.
Sur le même thème
D'autres notions et pages du territoire proches de ce terme.