Se préparer à DORA : entités financières et prestataires de services TIC

Le règlement sur la résilience opérationnelle numérique du secteur financier (DORA) s'applique depuis le 17 janvier 2025. Pour les entités financières, être prêt signifie désormais faire vivre un modèle opérationnel de résilience opérationnelle numérique, et non se préparer à une échéance future. Pour les fournisseurs de technologies, cela signifie comprendre leurs responsabilités envers leurs clients et savoir si un régime distinct de supervision directe s'applique.

La question pour la direction est concrète : l'organisation peut-elle expliquer quels services financiers dépendent de quels systèmes TIC, comment une perturbation sera gérée et quelles preuves étayent ses hypothèses de rétablissement ? Les politiques comptent, mais elles ne peuvent pas répondre seules à cette question. La direction a besoin d'une vue reliée des responsabilités, des dépendances, des contrats, des tests, des incidents et des risques non résolus.

Déterminer votre rôle avant de construire la liste de contrôle

Commencez par une décision d'applicabilité documentée pour chaque entité juridique concernée. L'article 2 de DORA identifie les catégories couvertes et les exclusions. Une entreprise qui se présente comme une FinTech, une start-up ou une PME n'est pas automatiquement dans le champ d'application ni exemptée.

Parmi les entités financières couvertes figurent par exemple les établissements de crédit, les établissements de paiement, les entreprises d'investissement et les entreprises d'assurance, sous réserve des règles détaillées du règlement relatives au champ d'application. Consignez la catégorie applicable, toute exclusion ou exemption, l'autorité compétente concernée et le raisonnement qui fonde votre conclusion.

Pour les fournisseurs, distinguez trois positions :

Un fournisseur qui soutient une fonction financière critique ou importante n'est pas, pour ce seul motif, un prestataire tiers critique de services TIC désigné. Les entités financières évaluent l'importance de leurs fonctions et de leurs dépendances ; la désignation des prestataires critiques intervient dans le cadre de supervision prévu à l'article 31.

La localisation ne règle pas la question du fournisseur. Un fournisseur de cloud ou de logiciels établi aux États-Unis peut être confronté à des exigences de ses clients liées à DORA lorsqu'il sert des entités financières de l'Union. Cette relation commerciale ne le soumet pas automatiquement à toutes les obligations imposées à une entité financière.

La proportionnalité exige elle aussi une évaluation motivée. L'article 4 tient compte de facteurs tels que la taille, le profil de risque global et la nature, l'ampleur et la complexité des services. L'article 16 prévoit un cadre simplifié de gestion du risque lié aux TIC pour certaines catégories. Ces notions ne sont pas interchangeables, et le simple statut de PME n'est pas un raccourci universel. Conservez l'analyse d'éligibilité avec la décision relative au champ d'application.

Rendre visible la responsabilité de la direction

En vertu de l'article 5 de DORA, l'organe de direction assume la responsabilité ultime de la gestion du risque lié aux TIC de l'entité financière. Déléguer la mise en œuvre à un RSSI, à une équipe technique ou à un prestataire externe ne transfère pas cette responsabilité.

La direction doit établir qui propose les décisions, qui les approuve et qui vérifie que la mise en œuvre fonctionne. Le modèle opérationnel doit couvrir la continuité des activités, la réponse aux incidents et le rétablissement, les accords avec les tiers, le budget et les connaissances nécessaires à une supervision effective.

Recommandation pratique : fournissez à la direction un dossier de reporting orienté vers les décisions plutôt qu'un tableau de bord exprimé en pourcentage d'avancement. Incluez :

• Les fonctions critiques ou importantes dont les hypothèses de rétablissement n'ont pas été testées.
• Les incidents significatifs, leurs effets sur les clients et les actions correctives en suspens.
• Les dépendances envers des fournisseurs dont les contrats sont incomplets ou les options de sortie fragiles.
• Les lacunes importantes dans les mesures, les responsables désignés et les dates de remédiation.
• Les décisions nécessitant un financement, un changement de fournisseur ou une réponse explicite au risque.

Chaque lacune doit distinguer l'exigence réglementaire, la faiblesse opérationnelle actuelle et le remède proposé. L'absence d'une trace d'approbation est différente d'une sauvegarde impossible à restaurer. Les deux peuvent nécessiter une action, mais elles relèvent de responsables et de priorités différents.

L'approbation d'un plan de remédiation par la direction n'autorise pas à reporter indéfiniment des obligations applicables. Lorsqu'une lacune est significative, envisagez des mesures de protection immédiates, une escalade et les éventuelles implications en matière de surveillance, en parallèle de la correction à plus long terme.

Construire le programme autour des fonctions financières

Un inventaire des actifs est nécessaire, mais la planification de la résilience doit partir du service qui doit continuer à fonctionner. Identifiez la fonction financière, son responsable métier, les conséquences d'une perturbation ainsi que les systèmes et prestataires qui la soutiennent.

Pour un service de paiement, cartographiez l'identité, l'infrastructure cloud, le traitement des transactions, la surveillance et l'escalade vers les fournisseurs. Incluez les dépendances moins visibles comme le DNS, la connectivité, les accès à privilèges, les clés de chiffrement et les outils de support. Un environnement de production alternatif peut être inutilisable s'il dépend du même service d'identité défaillant.

La cartographie obtenue doit relier chaque fonction :

• Aux applications, infrastructures, actifs informationnels et services externes qui la soutiennent.
• Aux contrats et responsables de service concernés.
• Aux objectifs de rétablissement et à l'analyse d'impact sur l'activité qui les fonde.
• Aux dispositifs de détection, de réponse, de rétablissement et de communication.
• Aux tests, constats et risques de dépendance non résolus.

Faites valider la cartographie par les équipes opérationnelles et métier. Les données des achats montrent ce qui a été acheté ; elles ne montrent pas nécessairement comment un service fonctionne aujourd'hui.

Utilisez ce modèle pour organiser la gestion du risque lié aux TIC, la gestion et la notification des incidents, les tests de résilience et le risque lié aux prestataires tiers de services TIC. DORA contient aussi des dispositions relatives au partage volontaire d'informations sur les cybermenaces. Si vous y participez, définissez l'adhésion, la confidentialité, l'usage autorisé et les règles de traitement plutôt que de considérer le partage comme un échange illimité de données d'incident.

Transformer la gestion du risque lié aux TIC en travail financé

Les dispositions de DORA relatives à la gestion du risque lié aux TIC couvrent l'identification, la protection et la prévention, la détection, la réponse et le rétablissement, l'apprentissage et la communication. Le cadre doit relier ces activités plutôt que de les laisser sous forme de recueils de politiques séparés.

Commencez l'analyse des écarts par les fonctions cartographiées. Demandez-vous si les contrôles d'accès protègent leurs systèmes, si les vulnérabilités sont traitées, si les changements sont maîtrisés, si les activités suspectes sont détectées et si les dispositifs de rétablissement reflètent des défaillances réalistes. Tenez compte des pannes techniques et des erreurs opérationnelles autant que des attaques malveillantes.

Pour chaque faiblesse significative, créez une fiche de remédiation comportant un responsable, l'impact métier, l'action requise, les critères d'achèvement et la preuve de clôture. Les dépendances comptent : améliorer les procédures de restauration peut exiger des changements dans l'accès aux sauvegardes, les engagements des fournisseurs et la formation du personnel avant qu'un test puisse réussir.

Les objectifs de rétablissement doivent découler des besoins métier et de l'analyse d'impact, et non du niveau de service standard que propose un fournisseur. Lorsque la capacité technique ne permet pas d'atteindre l'objectif, la direction doit décider d'améliorer l'architecture, de modifier le dispositif de service ou de reconsidérer le modèle opérationnel. Une cible inscrite dans un plan de continuité n'est pas une preuve de capacité de rétablissement.

Préparer les décisions relatives aux incidents avant la perturbation

DORA impose aux entités financières de gérer les incidents liés aux TIC et de notifier les incidents majeurs à l'autorité compétente concernée. Les articles 17 à 23 établissent le cadre ; les normes techniques de réglementation et d'exécution applicables précisent les critères de classification, les seuils, le contenu des notifications et les procédures.

Ne vous fiez pas à une liste de contrôle générique des incidents pour le calendrier détaillé de notification. Tenez à jour une matrice de notification identifiant les normes applicables, les instructions de l'autorité, le canal de transmission, les étapes de notification et le calcul des délais. Désignez la personne chargée de la maintenir à jour.

Le processus de réponse doit rendre plusieurs décisions exécutables sous pression :

• Qui enregistre les horodatages de détection, d'évaluation et de classification ?
• Qui obtient les informations d'impact auprès des opérations et des fournisseurs ?
• Qui décide si les critères d'incident majeur sont remplis ?
• Qui approuve et transmet les notifications, y compris en dehors des heures ouvrées ?
• Qui gère la communication avec les clients et les autres notifications applicables ?

Consignez le raisonnement de classification même lorsqu'un incident n'est pas notifié comme majeur. Une première vision incomplète doit déclencher une réévaluation à mesure que les informations évoluent, et non une hypothèse définitive selon laquelle l'événement est mineur.

Les engagements de notification des fournisseurs doivent laisser à l'entité financière suffisamment de temps pour évaluer et remplir ses propres obligations. Les tâches de notification peuvent être externalisées lorsque c'est autorisé, mais la responsabilité reste celle de l'entité financière.

Lorsqu'un incident majeur lié aux TIC a une incidence sur les intérêts financiers des clients, DORA impose aux entités financières d'informer ces clients dans les meilleurs délais de l'incident et des mesures prises pour en atténuer les effets négatifs. Évaluez séparément les obligations en matière de violation de données personnelles et les autres règles applicables. Une même perturbation peut entraîner plusieurs décisions de notification, avec des destinataires et des critères juridiques différents.

Tester les hypothèses sur lesquelles la direction s'appuie

Un programme de tests de résilience opérationnelle numérique doit être proportionné et fondé sur les risques. Les évaluations de vulnérabilités, les exercices de scénarios, les tests de sécurité et les tests de rétablissement répondent à des questions différentes ; aucun ne doit être considéré comme un substitut universel des autres.

Un exercice sur table peut établir si les décideurs comprennent l'escalade. Il ne peut pas prouver que les données de transaction peuvent être restaurées avec exactitude. Un test d'intrusion peut mettre en évidence des faiblesses exploitables sans prouver qu'un fournisseur alternatif peut reprendre un service.

Pour chaque test, définissez la fonction, le scénario, le périmètre, les critères de réussite, les dispositifs d'indépendance lorsqu'ils sont requis et les preuves attendues. Conservez les résultats, les constats, les décisions de remédiation et les résultats des nouveaux tests. Vérifiez les exigences applicables de couverture et de fréquence au regard de DORA et des normes pertinentes, y compris les éventuelles exemptions ou dispositions relatives au cadre simplifié.

Les tests de pénétration fondés sur la menace constituent une exigence de surveillance distincte pour certaines entités financières au titre de l'article 26. Ce n'est pas une obligation générale pour toute entreprise financière ou tout prestataire de services TIC.

La direction doit examiner les hypothèses qui se sont révélées fausses, et pas seulement si les tests ont eu lieu. Si un exercice révèle que la restauration dépend d'un seul administrateur indisponible, le résultat est un risque opérationnel appelant une action, et non un jalon de test atteint.

Traiter le risque lié aux tiers comme une question de continuité de service

En vertu de DORA, une entité financière reste responsable de ses obligations lorsqu'elle recourt à des prestataires de services TIC. Les articles 28 à 30 relient l'évaluation du risque lié aux tiers, les dispositions contractuelles, le suivi et la planification de la sortie.

Tenir le registre et la vision opérationnelle

Les entités financières doivent tenir un registre d'informations relatif aux accords contractuels portant sur des services TIC, aux niveaux individuel, sous-consolidé et consolidé requis. Utilisez les normes d'exécution applicables pour sa structure. Un tableur d'achats ou une liste de fournisseurs approuvés ne suffit pas automatiquement.

Rapprochez le registre des contrats, des responsabilités de service et des cartographies de dépendances. Maintenez les distinctions requises pour les services qui soutiennent des fonctions critiques ou importantes. Un nouveau sous-traitant, un nouveau lieu de prestation ou un périmètre élargi peut modifier le profil de risque même lorsque le nom du fournisseur reste le même.

Examiner les contrats au regard du service réel

Évaluez les exigences contractuelles applicables, notamment la description des services, les lieux, la protection des données, l'accès aux données et leur récupération, l'assistance en cas d'incident, la coopération, les droits de résiliation et les niveaux de service. Les accords qui soutiennent des fonctions critiques ou importantes exigent des dispositions supplémentaires, notamment en matière de reporting, de continuité, d'accès, d'inspection, d'audit et de sortie.

Les responsables juridiques, achats, techniques et métier doivent les examiner ensemble. Un droit d'audit contractuel peut être difficile à exercer en pratique ; un dispositif de rétablissement promis peut ne pas couvrir l'ensemble de la chaîne de service du client. Identifiez ces limites avant d'accepter l'accord.

Examiner la concentration et la capacité de sortie

Le risque de concentration ne se limite pas à l'achat de plusieurs services auprès d'une même entreprise. Des fournisseurs différents peuvent dépendre de la même plateforme cloud, de la même région, du même réseau ou du même sous-traitant. Évaluez la substituabilité, la complexité de la migration et les conséquences d'une défaillance commune.

Un plan de sortie doit traiter les formats de données, l'extraction, l'accès, les dépendances de migration, l'accompagnement de la transition, la suppression et la continuité pendant le transfert. Pour les fonctions critiques ou importantes, considérez les tests et la revue de la sortie comme un travail de fond, et non comme un exercice de rédaction.

Les fournisseurs peuvent préparer un dossier d'assurance cohérent comprenant le périmètre du service, les limites de responsabilité, les contacts en cas d'incident, les preuves de continuité, les informations sur la sous-traitance et leurs positions contractuelles. Les exigences propres à chaque client doivent toujours être examinées ; un certificat ne les remplace pas.

Comprendre l'articulation entre DORA et NIS2

DORA est un règlement de l'Union directement applicable. NIS2 est une directive transposée en droit national, dont l'applicabilité dépend du secteur, de la taille, du service et des règles d'inclusion. Sa date limite de transposition nationale était le 17 octobre 2024 ; les organisations doivent examiner la transposition nationale applicable plutôt que de supposer un régime opérationnel unique et identique.

L'article 1, paragraphe 2, de DORA, combiné à l'article 4 de NIS2, établit la relation sectorielle spécifique pour les entités financières couvertes dans les domaines concernés. N'interprétez pas cela comme une invitation à dupliquer des mesures équivalentes de gestion des risques et de notification des incidents. De même, ne supposez pas que cela supprime les obligations de toutes les sociétés d'un groupe financier ou de sa chaîne d'approvisionnement.

Un prestataire de services managés qui sert une banque peut avoir besoin de sa propre évaluation NIS2 tout en respectant des engagements contractuels liés à DORA. Une matrice des obligations établie entité par entité doit consigner la base juridique, le champ d'application, l'autorité, la voie de notification et les preuves requises.

Des mesures communes peuvent servir DORA, l'ISO 27001, les obligations de protection des données et l'assurance client lorsque le périmètre et les preuves correspondent. Réutilisez une revue des accès ou un test de rétablissement lorsqu'il étaye réellement plusieurs exigences, tout en préservant les spécificités du secteur financier. Un certificat ISO 27001 n'établit pas la conformité à DORA.

Les régimes de sanctions diffèrent également. Les pouvoirs de surveillance et les sanctions de DORA à l'égard des entités financières dépendent de ses dispositions et des mesures nationales applicables ; les prestataires critiques désignés relèvent d'un régime de supervision distinct. Ne budgétez pas le risque autour d'une prétendue amende DORA universelle. Évaluez l'exposition juridique pertinente et les conséquences opérationnelles d'une résilience insuffisante.

Exemple détaillé : revue des dépendances d'un service de paiement

Prenons l'exemple illustratif d'un établissement de paiement qui utilise une plateforme cloud, un fournisseur d'identité et un service de surveillance externalisé. Supposons que l'établissement relève de DORA et que l'exécution des paiements soit classée comme fonction critique ou importante.

La première revue met au jour trois faiblesses : les environnements de production et de rétablissement partagent la même dépendance d'identité ; le processus d'escalade des incidents du fournisseur de surveillance est flou ; et le plan de sortie du cloud cite un fournisseur alternatif sans démontrer l'extraction et la migration des données.

La direction lance trois chantiers liés :

Le responsable métier vérifie si les objectifs de rétablissement des paiements restent atteignables. La conformité vérifie que les procédures de notification et les entrées du registre reflètent les accords. La direction approuve le financement nécessaire et examine les limites restantes.

Cet exemple n'établit pas à lui seul la conformité. Il montre comment une seule fonction peut révéler des décisions qui resteraient cachées dans des listes de contrôle distinctes sur les politiques, les fournisseurs et les tests.

Instaurer un rythme de revue fondé sur les preuves

DORA ne prévoit aucun processus de certification universel qui remplacerait les obligations continues. Une assurance indépendante peut éclairer la direction, mais l'état de préparation doit être démontré par des mesures en fonctionnement, des enregistrements et, lorsque c'est requis, des échanges avec l'autorité de surveillance.

L'étape suivante concrète consiste à choisir une fonction critique ou importante et à rassembler sa décision de champ d'application, sa cartographie des dépendances, son appréciation des risques, ses contrats, ses procédures d'incident, ses résultats de tests et ses actions ouvertes. Vérifiez si ces documents racontent une histoire cohérente.

Secani soutient ce processus en modélisant les systèmes et services, en reliant les dépendances et en conservant dans leur contexte les exigences, preuves, responsables, tâches et décisions de revue. Téléversez les documents existants en les rattachant aux objets concernés, transformez les lacunes en tâches assignées et conservez une approbation humaine explicite pour les suggestions et conclusions assistées par IA.

Élargissez à partir de cette première fonction une fois que les responsabilités et les chemins de preuve sont clairs. La direction doit pouvoir voir ce qui a été démontré, ce qui reste incertain et quelle décision est nécessaire ensuite.