Règlement DORA : qui est concerné et quelles obligations

DORA, pour Digital Operational Resilience Act, est le règlement européen 2022/2554 sur la résilience opérationnelle numérique du secteur financier. Il s’applique depuis le 17 janvier 2025, directement et sans transposition nationale.

Son point de départ est simple : la solidité d’une entité financière ne se mesure plus seulement à ses fonds propres, mais aussi à sa capacité à résister à une panne, une cyberattaque ou la défaillance d’un prestataire informatique.

Qui est concerné ?

Une vingtaine de catégories d’entités financières : établissements de crédit, entreprises d’investissement, sociétés de gestion, compagnies d’assurance et intermédiaires, établissements de paiement et de monnaie électronique, prestataires de services sur actifs numériques, entre autres.

Le règlement touche aussi, indirectement, tous les prestataires informatiques de ces entités : éditeurs, hébergeurs, infogérants, agences. Les clauses de leurs contrats, l’auditabilité de leurs services et leur stratégie de sortie deviennent des sujets réglementaires pour leurs clients. Les prestataires TIC jugés critiques à l’échelle européenne relèvent en plus d’une supervision directe.

DORA applique un principe de proportionnalité : les exigences se modulent selon la taille et le profil de risque de l’entité. Un courtier de dix personnes n’a pas les obligations d’une banque systémique, mais il a des obligations.

Les cinq piliers de DORA

1. Gouvernance et gestion des risques informatiques

Un cadre formalisé de gestion des risques liés aux technologies de l’information, sous la responsabilité de l’organe de direction : cartographie des actifs, politiques de sécurité, continuité d’activité, plans de reprise testés.

2. Notification des incidents majeurs

Les incidents informatiques sont classifiés selon des critères communs. Les incidents majeurs sont notifiés à l’autorité compétente (en France l’ACPR ou l’AMF) selon un calendrier précis : notification initiale, rapport intermédiaire, rapport final.

3. Tests de résilience opérationnelle numérique

Un programme de tests réguliers, du test de vulnérabilité au test d’intrusion. Les entités les plus importantes mènent en plus des tests de pénétration fondés sur la menace (TLPT) tous les trois ans.

4. Gestion des risques liés aux prestataires tiers

C’est le pilier qui déborde le plus sur les prestataires. Les entités doivent recenser tous leurs contrats informatiques dans un registre d’information, évaluer la criticité de chaque prestation, intégrer des clauses contractuelles obligatoires et prévoir des stratégies de sortie pour les fonctions critiques ou importantes.

5. Partage d’informations

Le règlement encourage l’échange de renseignements sur les menaces entre entités financières, dans des cadres protégés.

Le registre d’information et vos contrats

Le registre d’information recense l’ensemble des accords contractuels portant sur des services informatiques, avec leur criticité, leurs chaînes de sous-traitance et leurs conditions de sortie. Il est tenu à jour en continu et remis chaque année aux autorités de supervision.

Concrètement, chaque nouveau contrat avec un prestataire informatique doit documenter : la description précise du service, les lieux de traitement des données, les niveaux de service, les droits d’accès et d’audit de l’entité et de son superviseur, les conditions de résiliation et la réversibilité.

Ce que DORA change avec un prestataire de développement

Pour une entité financière qui fait développer un outil, DORA ne dit pas « n’externalisez pas ». Il dit : choisissez des prestataires que vous pouvez documenter, auditer et quitter. Trois éléments facilitent la relation :

La propriété du code et sa documentation, qui rendent la prestation auditable. L’hébergement transférable, en France ou dans l’Union européenne, qui répond aux questions de localisation. La réversibilité organisée dès le départ, qui alimente directement la stratégie de sortie exigée par le règlement.

C’est la manière dont nous construisons nos projets, des applications souveraines aux projets d’automatisation de la conformité KYC et LCB-FT : un périmètre d’outillage non critique, du code livré et documenté, une sortie possible à tout moment. Sur le dispositif anti-blanchiment lui-même, voir notre article LCB-FT : obligations et dispositif.