DORA : ce que le règlement change vraiment pour vos prestataires TIC
Registre d'information, tests de résilience, stratégies de sortie, sous-traitance en cascade. Ce qu'une organisation régulée doit désormais exiger d'un opérateur informatique, et comment le prouver en audit.
Le règlement UE 2022/2554, dit DORA, est applicable depuis le 17 janvier 2025. Il ne s'adresse pas seulement aux banques, aux assureurs et aux entreprises d'investissement : il redéfinit ce que ces entités doivent exiger de leurs prestataires de services informatiques, et ce que ces prestataires doivent être capables de démontrer. Pour un opérateur qui exploite l'infrastructure d'une organisation régulée, ce n'est pas une contrainte de plus, c'est le cahier des charges.
La question utile n'est donc pas « sommes-nous conformes ? » mais « qu'est-ce que notre prestataire nous permet de prouver le jour de l'audit ? ». Voici ce que DORA place noir sur blanc.
Le registre d'information
DORA impose à l'entité financière de tenir un registre de tous ses accords contractuels portant sur l'usage de services TIC (art. 28), et de le communiquer à l'autorité compétente, au Luxembourg, la CSSF. Ce registre suit un format défini par des normes techniques et distingue notamment les services qui soutiennent des fonctions critiques ou importantes.
Concrètement, votre opérateur doit vous fournir les éléments de ce registre sans que vous ayez à les reconstituer : identité et lieu d'établissement du prestataire, nature du service, localisation des données et de leur traitement, et la liste des sous-traitants. Si obtenir ces informations demande trois relances et un tableur bricolé, le problème n'est pas le registre : c'est le prestataire.
Les tests de résilience
DORA exige un programme de tests de résilience opérationnelle numérique proportionné au risque, et, pour les entités les plus critiques, des tests de pénétration fondés sur la menace (TLPT). Un opérateur sérieux ne se contente pas de dire que ses sauvegardes existent : il les teste, il horodate ces tests, et il vous en remet le résultat. La différence entre « nous sauvegardons » et « voici le journal de la dernière restauration testée, réussie » est exactement celle que cherche un auditeur.
La gestion et la notification des incidents
Le règlement encadre la classification et la notification des incidents majeurs liés aux TIC. Pour que l'entité financière puisse notifier dans les délais, son opérateur doit détecter, qualifier et remonter l'incident vite, et documenter la chronologie. Un incident dont on ne peut pas reconstituer le déroulé n'est pas un incident géré, c'est un incident subi.
La sous-traitance en cascade, et la sortie
DORA regarde toute la chaîne. Un prestataire qui sous-traite à son tour une brique critique doit le déclarer, et l'entité financière doit pouvoir en apprécier le risque. Le règlement encadre aussi les clauses contractuelles (art. 30) et impose des stratégies de sortie pour les services qui soutiennent des fonctions critiques : vous devez pouvoir quitter un prestataire sans interrompre votre activité ni perdre vos données.
C'est là que la conformité rejoint la souveraineté. Une stratégie de sortie n'a de valeur que si elle est réalisable : données restituables dans un format ouvert, configurations documentées, absence de dépendance qui rendrait le départ théorique. Une clause de réversibilité qu'on ne peut pas exécuter n'est pas une garantie, c'est une formule.
Ce que DORA ne fait pas. Le règlement n'exige pas que vos données restent sur le sol européen, ni que votre prestataire soit européen. Il exige que vous maîtrisiez et prouviez votre dispositif. La souveraineté est un choix distinct, que DORA rend simplement plus facile à documenter, voir notre analyse du CLOUD Act.
Regulation EU 2022/2554, known as DORA, has applied since 17 January 2025. It does not address only banks, insurers and investment firms: it redefines what those entities must require of their IT service providers, and what those providers must be able to demonstrate. For an operator running the infrastructure of a regulated organisation, this is not one more constraint, it is the specification.
The useful question is therefore not “are we compliant?” but “what does our provider let us prove on audit day?”. Here is what DORA sets down in black and white.
The register of information
DORA requires the financial entity to maintain a register of all its contractual arrangements on the use of ICT services (art. 28), and to report it to the competent authority, in Luxembourg, the CSSF. This register follows a format defined by technical standards and distinguishes, in particular, services supporting critical or important functions.
In practice, your operator must supply the elements of that register without you having to reconstruct them: identity and place of establishment of the provider, nature of the service, location of the data and of its processing, and the list of subcontractors. If obtaining this takes three follow-ups and an improvised spreadsheet, the problem is not the register: it is the provider.
Resilience testing
DORA requires a digital operational resilience testing programme proportionate to risk and, for the most critical entities, threat-led penetration testing (TLPT). A serious operator does not merely state that backups exist: it tests them, timestamps those tests, and hands you the result. The difference between “we take backups” and “here is the log of the last tested restore, successful” is exactly what an auditor is looking for.
Incident management and notification
The regulation frames the classification and notification of major ICT-related incidents. For the financial entity to notify within the deadlines, its operator must detect, qualify and escalate the incident quickly, and document the timeline. An incident whose sequence cannot be reconstructed is not a managed incident, it is an incident endured.
Subcontracting down the chain, and the exit
DORA looks at the whole chain. A provider that in turn subcontracts a critical component must declare it, and the financial entity must be able to assess the risk. The regulation also frames contractual clauses (art. 30) and requires exit strategies for services supporting critical functions: you must be able to leave a provider without interrupting your activity or losing your data.
This is where compliance meets sovereignty. An exit strategy is only worth something if it can actually be carried out: data returnable in an open format, configurations documented, no dependency that would make departure theoretical. A reversibility clause you cannot execute is not a guarantee, it is a form of words.
What DORA does not do. The regulation does not require your data to stay on European soil, nor your provider to be European. It requires you to control and prove your arrangements. Sovereignty is a separate choice, one that DORA simply makes easier to document, see our analysis of the CLOUD Act.