Gestion des risques TIC DORA

Un dispositif vivant et proportionné

Ce que DORA attend de la gestion des risques TIC

Le Digital Operational Resilience Act ne réduit pas la gestion des risques TIC à un audit ponctuel ou à une liste de solutions de cybersécurité. L’article 6 du règlement (UE) 2022/2554 demande un cadre intégré au système global de gestion des risques de l’entité financière. Ce cadre doit permettre de parer rapidement et de manière exhaustive aux risques liés aux réseaux, aux systèmes d’information, aux données et aux processus dépendant de la technologie.

L’organe de direction conserve la responsabilité ultime du dispositif : il approuve la stratégie de résilience opérationnelle numérique, définit la tolérance au risque, attribue les rôles et suit les résultats. Les équipes informatiques contribuent à cette gouvernance avec des informations fiables sur l’environnement technique, les vulnérabilités, les incidents, les contrôles et les actions correctives.

La mise en œuvre reste proportionnée à la taille, au profil de risque et à la complexité des activités. Certaines entités relèvent d’un cadre simplifié et plusieurs obligations sont allégées pour les microentreprises. Cette proportionnalité ne dispense toutefois pas d’identifier les fonctions critiques ou importantes, les actifs TIC qui les soutiennent et les risques susceptibles d’en compromettre la disponibilité, l’intégrité, l’authenticité ou la confidentialité.

• Identifier : connaître les fonctions métier, les actifs informationnels, les actifs TIC et leurs dépendances.
• Protéger : définir des mesures adaptées aux menaces, aux vulnérabilités et à la criticité des services.
• Détecter et réagir : surveiller les événements, traiter les incidents et limiter leur impact.
• Rétablir et apprendre : tester la reprise, corriger les écarts et réviser périodiquement le cadre de gestion.

Partir des services rendus

Cartographier les actifs, les services et les dépendances

Une cartographie des risques TIC utile ne commence pas par une simple liste de matériels. Elle part des activités, des enjeux métier et des services du secteur financier : quelles fonctions doivent continuer à être assurées, quelles données sont utilisées, quels délais d’interruption sont acceptables et qui en porte la responsabilité ? Cette lecture métier permet ensuite de rattacher chaque service aux ressources techniques qui le rendent possible.

Postes, serveurs, applications, bases de données, équipements réseau, identités, services cloud et sites externes doivent être identifiés et classés. DORA demande également de documenter les liens entre ces actifs, les fonctions qu’ils soutiennent et les processus dépendant de prestataires tiers de services TIC. L’objectif est de faire apparaître les dépendances cachées et les points uniques de défaillance avant qu’un incident ne les révèle.

Relier chaque fonction critique à ses ressources

• Fonction ou service : activité financière concernée, niveau de criticité et responsable métier.
• Actifs informationnels : données nécessaires, emplacement, sensibilité et besoins de protection.
• Actifs TIC : matériels, logiciels, réseaux, comptes, configurations et systèmes hérités.
• Dépendances : interconnexions internes, services cloud, fournisseurs et prestataires de services TIC.
• Mesures existantes : contrôles d’accès, sauvegardes, surveillance, correctifs et procédures de continuité.

La cartographie doit être tenue à jour lors de toute modification importante : nouveau logiciel, migration cloud, changement de prestataire, évolution du réseau ou transformation d’un processus. Elle devient ainsi la base commune des équipes IT, risques, conformité et directions opérationnelles.

Hiérarchiser avant d’agir

Évaluer et prioriser les risques TIC

Une fois l’environnement connu, chaque scénario de risque doit être évalué à partir de faits observables. Une cybermenace, une erreur humaine, une panne, une obsolescence ou la défaillance d’un fournisseur n’ont pas la même probabilité ni les mêmes conséquences selon la fonction concernée. L’analyse combine donc la menace, les vulnérabilités, les mesures existantes et l’impact potentiel sur les opérations, les données, les clients et le risque de non-conformité.

La criticité permet de concentrer les ressources sur les risques les plus importants. Une méthode interne peut utiliser des niveaux ou un score pour distinguer le risque inhérent, l’efficacité des contrôles et le risque résiduel. DORA n’impose cependant pas une matrice de scoring universelle : les critères doivent rester cohérents avec le profil de risque, l’appétit pour le risque et la gouvernance de l’entité financière.

• Décrire le scénario : événement redouté, actifs concernés et fonction métier affectée.
• Apprécier l’exposition : menaces, vulnérabilités, historique et changements récents.
• Mesurer l’impact : indisponibilité, perte ou altération de données, conséquences financières et réglementaires.
• Évaluer les contrôles : mesures de prévention, détection, réponse et rétablissement déjà opérationnelles.
• Décider du traitement : réduire, éviter, transférer ou accepter le risque selon les règles internes.

Un audit de sécurité pour identifier les vulnérabilités du système d’information peut alimenter cette évaluation. Il fournit des constats techniques ; la priorisation finale reste liée aux enjeux métier et à la gouvernance du client.

Réduire l’exposition

Définir et mettre en œuvre les mesures de traitement

Le plan d’actions traduit l’évaluation en mesures concrètes. Les enjeux et les priorités dépendent de la criticité des fonctions, du niveau de risque résiduel et des ressources disponibles. Certaines corrections peuvent être immédiates ; d’autres nécessitent une évolution d’architecture, un projet de migration ou un changement contractuel.

DORA attend des systèmes, protocoles et outils TIC adaptés, fiables et suffisamment résilients. La prévention, la protection, la détection, la réponse et le rétablissement doivent former un ensemble cohérent : protéger un accès sans maintenir les correctifs, surveiller un serveur sans procédure d’escalade ou sauvegarder des données sans tester leur restauration laisse subsister un risque important.

• Accès et identités : authentification multifacteur, gestion des privilèges, revues de droits et suppression des comptes inutiles.
• Postes, serveurs et réseaux : EDR/XDR, pare-feu, segmentation, configurations sécurisées et protection des flux.
• Vulnérabilités et obsolescences : correctifs, mises à jour, suivi des systèmes hérités et maintien en condition opérationnelle.
• Détection et réponse : journalisation, alertes, supervision, critères d’escalade et procédure de gestion des incidents.
• Continuité et données : sauvegardes protégées, tests de restauration, capacités de reprise et contrôles d’intégrité.

ACI peut mettre en œuvre et maintenir dans la durée les mesures de protection du système d’information, assurer le maintien en condition opérationnelle et organiser une surveillance des événements et des dérives selon le périmètre retenu.

Rendre le dispositif démontrable

Documenter, surveiller et réviser le cadre de gestion

La gestion des risques TIC sous DORA doit pouvoir être comprise, pilotée et démontrée. Les inventaires, analyses, plans d’action, indicateurs, comptes rendus de revue et historiques d’intervention doivent donc rester cohérents entre eux. Une mesure annoncée comme déployée doit être vérifiable ; un écart critique doit être suivi jusqu’à sa correction ou son acceptation formelle.

Un registre des risques TIC constitue un outil pratique pour centraliser cette information. Il peut préciser le scénario, la fonction concernée, les actifs associés, le niveau de risque, les contrôles existants, le responsable, le plan de traitement, l’échéance et le statut. Il ne doit pas être confondu avec le registre d’information DORA, qui documente les accords contractuels portant sur l’utilisation de services TIC fournis par des prestataires tiers.

Pour les entités soumises au cadre général, le cadre de gestion est documenté et réexaminé au moins une fois par an. Une révision doit également être déclenchée lorsqu’un incident majeur survient, qu’un test révèle une faiblesse, qu’un audit produit une constatation critique ou qu’une modification importante affecte le réseau, un système d’information ou un processus. Pour les microentreprises, le règlement prévoit une revue périodique proportionnée.

• Indicateurs de risque : exposition, actifs obsolètes, vulnérabilités critiques, échecs de sauvegarde ou incidents récurrents.
• Indicateurs de suivi : actions ouvertes, responsables, délais, corrections réalisées et contrôles de vérification.
• Rapports : synthèse destinée à l’encadrement, décisions prises et évolution du profil de risque.
• Preuves : tickets, journaux, résultats de tests, changements, validations et historiques disponibles.

Transformer les évènements en apprentissage

Tirer parti des incidents pour améliorer l’évaluation

Un incident lié aux TIC révèle souvent un scénario mal évalué, une dépendance insuffisamment connue ou un contrôle inefficace. Après un incident majeur, l’analyse des causes, de la rapidité de détection, de l’escalade, de la réponse et du rétablissement doit alimenter la gestion des risques. Les actions correctives sont ensuite intégrées au plan de traitement et leur efficacité doit être vérifiée.

ACI peut fournir la chronologie technique, les alertes, les interventions et les éléments relevant de son périmètre. L’entité financière conserve la qualification réglementaire de l’événement, la décision de notification d’incidents et les échanges avec l’autorité compétente.

Vérifier l’efficacité

Contrôler les mesures par des tests de résilience

Une politique ou une procédure ne suffit pas à prouver qu’un risque est maîtrisé. Les tests de résilience permettent d’évaluer la robustesse des mesures face à des scénarios réalistes : vulnérabilité, mauvaise configuration, perte de données, indisponibilité d’un service critique, cyberattaque ou défaillance d’une dépendance externe. Chaque résultat doit produire des écarts, des actions de remédiation et une nouvelle vérification.

Le programme de tests reste proportionné au profil de risque. Les tests TLPT fondés sur la menace répondent à un cadre spécifique et ne concernent pas toutes les entités financières. La page présente dédiée précisera les différents niveaux de tests sans les confondre avec une certification DORA.

Étendre l’analyse à la chaîne de services

Intégrer les risques liés aux prestataires tiers TIC

L’utilisation de services TIC externalisés ne transfère pas la responsabilité de l’entité financière. Un hébergeur, un fournisseur cloud, un éditeur SaaS, un opérateur de télécommunications ou un prestataire d’infogérance peut soutenir une fonction critique ou importante. Sa défaillance, une concentration excessive ou une réversibilité mal préparée doivent donc être intégrées au profil de risque.

L’analyse porte sur la nature du service, les données concernées, les dépendances, les niveaux de service, les incidents, la sous-traitance pertinente et les conditions contractuelles. Lorsque le service soutient une fonction critique, les clauses, les droits d’accès et d’audit, la continuité ainsi que la stratégie de sortie prennent une importance particulière.

• Identifier : recenser les processus et fonctions dépendant de chaque prestataire tiers de services TIC.
• Évaluer : apprécier la criticité, les impacts potentiels, la concentration et les alternatives disponibles.
• Encadrer : aligner les accords contractuels, les niveaux de service, la sécurité et les modalités de coopération.
• Surveiller : suivre les changements, incidents, performances et risques affectant la prestation.
• Préparer la sortie : documenter la réversibilité, les délais, la restitution des données et les solutions de remplacement.

Un accompagnement opérationnel

Comment ACI Technology contribue à votre gestion des risques TIC

ACI Technology intervient sur les informations et les mesures techniques nécessaires au cadre de gestion. Notre rôle consiste à rendre l’environnement visible, à produire des constats exploitables, à déployer les protections retenues et à assurer leur suivi dans la durée. Cette contribution s’intègre au dispositif piloté par vos responsables SI, risques, conformité et directions métier.

• Cartographie technique : inventaire des actifs administrés, configurations, dépendances et services couverts.
• État des lieux : identification des vulnérabilités, obsolescences, défauts de configuration et points de défaillance.
• Plan de traitement : priorisation technique, chiffrage, calendrier et répartition des responsabilités.
• Mise en œuvre : correctifs, accès, protection, supervision, sauvegarde et maintien en condition selon le contrat.
• Suivi : indicateurs, tickets, historiques, rapports, revues et contrôle des actions correctives.

ACI vous aide à construire un état des lieux exploitable par vos équipes SI, risques et conformité. Besoin de relier vos constats techniques à un plan de traitement suivi dans la durée ?