Gestion des risques TIC sous DORA : cadre et exigences

Introduction

Le cadre de gestion des risques liés aux technologies de l’information et de la communication (TIC) constitue le coeur du règlement DORA (règlement (UE) 2022/2554). Les articles 5 à 16 définissent un ensemble d’exigences structurées autour de cinq fonctions fondamentales : identification, protection, détection, réponse et rétablissement. Ce modèle, inspiré du NIST Cybersecurity Framework, est adapté aux spécificités du secteur financier européen et rendu juridiquement contraignant par le règlement.

Toute entité financière soumise à DORA doit mettre en place et maintenir un cadre de gestion des risques TIC conforme à ces exigences. La responsabilité ultime repose sur l’organe de direction. Les normes techniques de réglementation (RTS) adoptées par les autorités européennes de surveillance (AES) precisent les modalités d’application.

Pour une vue d’ensemble du règlement, consultez notre guide DORA. Pour des recommandations sur la formalisation de votre politique de sécurité, consultez notre article sur la politique de sécurité des systèmes d’information (PSSI).

Gouvernance des risques TIC (article 5)

Responsabilité de l’organe de direction

L’article 5 de DORA place la responsabilité de la gestion des risques TIC au niveau le plus élevé de l’organisation. L’organe de direction de l’entité financière (conseil d’administration, directoire, ou équivalent) est tenu de :

• Définir, approuver et superviser la mise en oeuvre du cadre de gestion des risques TIC.
• Assumer la responsabilité ultime de la gestion des risques TIC de l’entité.
• Définir les rôles et responsabilités en matière de fonctions TIC, y compris la continuité d’activité et les plans de réponse aux incidents.
• Approuver et reexaminer périodiquement la stratégie de résilience opérationnelle numérique de l’entité, y compris la politique de gestion des risques TIC, les arrangements relatifs aux prestataires tiers de services TIC et le plan d’audit TIC.
• Allouer un budget adéquat pour la mise en oeuvre du cadre de gestion des risques TIC, y compris les programmes de sensibilisation et de formation.
• Être informe régulièrement des incidents TIC majeurs et de leurs conséquences.

Cette implication directe de l’organe de direction constitue un changement culturel significatif pour de nombreuses entités financières ou la gestion des risques TIC était historiquement déléguée aux directions informatiques sans supervision formalisée au niveau du conseil.

Formation et compétences

Bien que DORA ne contienne pas d’obligation explicite de formation des membres de l’organe de direction (à la différence de NIS2), l’article 5 exigé implicitement que les dirigeants disposent de connaissances suffisantes pour exercer leur mission de supervision. Les entités financières doivent prévoir des programmes de sensibilisation réguliers a destination de l’organe de direction.

Fonction de contrôle

L’article 6, paragraphe 4, de DORA impose aux entités financières de mettre en place une fonction de contrôle (control function) pour la gestion des risques TIC, dotee d’une indépendance suffisante pour éviter les conflits d’intérêts. Cette fonction peut être assurée par un RSSI (Responsable de la Sécurité des Systèmes d’Information), un directeur des risques TIC ou toute personne disposant de l’autorité et de l’indépendance nécessaires.

Le cadre de gestion des risques TIC (article 6)

Structuré du cadre

L’article 6 impose aux entités financières de mettre en place un cadre de gestion des risques TIC complet, documenté et intègre à leur dispositif global de gestion des risques. Ce cadre doit comprendre :

• Des stratégies, politiques, procédures et outils nécessaires pour protéger l’ensemble des actifs TIC et des informations de l’entité.
• Un dispositif de gestion des actifs TIC incluant l’identification et la classification de tous les actifs.
• Des mécanismes de détection des activités anormales.
• Des plans de réponse aux incidents et de rétablissement.
• Des mécanismes de remontée d’information vers l’organe de direction.

Le cadre doit être documenté de manière exhaustive et reexamine au moins une fois par an, ainsi qu’après tout incident majeur, toute évolution significative des menaces ou tout changement important dans l’infrastructure TIC.

Stratégie de résilience opérationnelle numérique

En complement du cadre de gestion des risques, l’article 6, paragraphe 8, impose aux entités financières de définir une stratégie de résilience opérationnelle numérique. Cette stratégie doit couvrir :

• Les objectifs de résilience TIC de l’entité.
• L’architecture TIC ciblé et les évolutions prévues.
• Les mécanismes de détection et de prévention des incidents.
• La stratégie de tests de résilience.
• La stratégie de gestion des prestataires TIC.

Identification (articles 8 et 9)

Inventaire des actifs TIC

L’article 8 constitue le socle de la fonction d’identification. Il impose aux entités financières de :

Identifier, classifier et documenter l’ensemble de leurs fonctions métier, de leurs actifs d’information et de leurs actifs TIC qui supportent ces fonctions. Cette cartographie doit être exhaustive et maintenue à jour.

La classification des actifs doit prendre en compte :

• La criticite de chaque actif pour les fonctions métier de l’entité.
• Les interconnexions et dépendances entre les actifs.
• Les propriétaires de chaque actif (responsable métier et responsable technique).

Cartographie des systèmes TIC

L’article 8, paragraphe 4, impose une obligation spécifique de cartographie des systèmes TIC. Les entités financières doivent identifier et documenter :

• Les processus métier qui dépendent de prestataires TIC tiers.
• Les interconnexions entre les systèmes TIC internes et les systèmes des prestataires.
• Les flux de données entre les systèmes.
• L’architecture réseau, y compris les points d’entrée et de sortie.

Cette cartographie est essentielle pour comprendre l’exposition de l’entité aux risques TIC et pour planifier les mesures de protection et les tests de résilience.

Analyse d’impact sur l’activité (BIA)

L’article 11 de DORA impose aux entités financières de réaliser une analyse d’impact sur l’activité (Business Impact Analysis – BIA) pour évaluer les conséquences potentielles d’une perturbation majeure de leurs systèmes TIC.

La BIA doit :

• Identifier les fonctions critiques ou importantes de l’entité.
• Évaluer l’impact d’une interruption de ces fonctions (impact financier, opérationnel, réputationnel, réglementaire).
• Déterminer les objectifs de temps de rétablissement (RTO – Recovery Time Objective) et les objectifs de point de rétablissement (RPO – Recovery Point Objective) pour chaque fonction critique.
• Prendre en compte les dépendances vis-à-vis des prestataires TIC tiers.

La BIA constitue la basé sur laquelle sont construits les plans de continuité d’activité et de reprise d’activité.

Protection (articles 9 et 10)

Mesures de protection

L’article 9 définit les exigences en matière de protection des systèmes TIC. Les entités financières doivent mettre en oeuvre des mesures techniques et organisationnelles pour :

Sécurité des réseaux et de l’infrastructure. Les entités doivent mettre en place des mécanismes de protection de l’infrastructure réseau, incluant la segmentation, le filtrage, le chiffrement des communications et la surveillance des flux.

Gestion des accès. Les politiques de contrôle d’accès doivent appliquer le principe du moindre privilège et du besoin d’en connaître. L’authentification forte doit être déployée pour les accès aux systèmes critiques. Les comptes privilégiés doivent faire l’objet d’une gestion renforcée.

Chiffrement. Les entités doivent mettre en oeuvre des politiques de chiffrement couvrant les données en transit et les données au repos. La gestion des clés cryptographiques doit être documentée et sécurisée.

Gestion des changements. Toute modification des systèmes TIC doit suivre un processus formalisé de gestion des changements, incluant une évaluation des risques, des tests préalables et une approbation formelle.

Gestion des correctifs. Les entités doivent mettre en place un processus de gestion des correctifs de sécurité, incluant la veille sur les vulnérabilités, l’évaluation de leur criticite et le déploiement des correctifs dans des délais adaptés au risque.

Sécurité physique. La protection physique des infrastructures TIC (centres de données, salles serveurs) doit être assurée par des mesures adaptées (contrôle d’accès physique, surveillance, protection contre les risques environnementaux).

Politique de sécurité de l’information

L’article 9, paragraphe 4, impose l’adoption d’une politique de sécurité de l’information (ou PSSI) couvrant l’ensemble des exigences de protection. Cette politique doit être approuvée par l’organe de direction, communiquée à l’ensemble du personnel et reexaminee régulièrement.

La PSSI doit couvrir au minimum :

• La classification des informations et des actifs TIC.
• Les règles de contrôle d’accès.
• Les règles de chiffrement.
• La gestion des incidents de sécurité.
• La sécurité des opérations.
• La sécurité des communications.
• La gestion de la continuité.
• La sensibilisation et la formation du personnel.

Sensibilisation et formation

L’article 13, paragraphe 6, impose aux entités financières de mettre en place des programmes de sensibilisation et de formation à la sécurité TIC a destination de l’ensemble du personnel, y compris la direction. Ces programmes doivent être adaptés au profil de risque de l’entité et aux fonctions des personnes formées.

Detection (article 10)

Mécanismes de détection

L’article 10 impose aux entités financières de mettre en place des mécanismes de détection des activités anormales, y compris les problèmes de performance des réseaux TIC et les incidents liés aux TIC. Ces mécanismes doivent permettre :

• La détection rapide des incidents de sécurité et des anomalies.
• L’identification de la source et de la nature des incidents.
• La categorisation des incidents selon leur sévérité.
• Le déclenchement des procédures de réponse appropriées.

Surveillance continue

Les entités doivent mettre en oeuvre une surveillance continue de leurs systèmes TIC. Cela implique :

• Le déploiement d’outils de supervision et de journalisation (SIEM, IDS/IPS, SOC).
• La définition de seuils d’alerte adaptés au profil de risque.
• La corrélation des évènements pour détecter les attaques complexes.
• La conservation des journaux pendant une durée suffisante pour permettre les investigations post-incident.

Les normes techniques de réglementation (RTS) precisent les exigences en matière de capacités de détection, incluant les délais de détection attendus et les types d’incidents devant être detectes.

Réponse et rétablissement (articles 11 et 12)

Plans de continuité d’activité (BCP)

L’article 11 impose aux entités financières de mettre en place des plans de continuité d’activité TIC (Business Continuity Plans – BCP) couvrant l’ensemble de leurs fonctions critiques ou importantes. Ces plans doivent :

• Être fondés sur la BIA réalisée par l’entité.
• Définir les procédures de basculement vers les systèmes de secours.
• Fixer des objectifs de rétablissement (RTO/RPO) alignes sur les besoins métier.
• Identifier les ressources nécessaires pour la mise en oeuvre (personnel, équipements, prestataires).
• Être testes régulièrement pour vérifier leur efficacité.

Plans de réponse aux incidents

L’article 17 (qui relève du chapitre sur la gestion des incidents mais s’intègre dans le cadre de gestion des risques) impose aux entités financières de définir des plans de réponse aux incidents TIC comprenant :

• Les procédures d’alerte et de remontée d’information.
• Les rôles et responsabilités de chaque intervenant.
• Les procédures de confinement de l’incident.
• Les procédures de communication interne et externe.
• Les procédures de retour à la normale.
• Les procédures d’analyse post-incident (retour d’expérience).

Plans de reprise d’activité (DRP)

Les plans de reprise d’activité TIC doivent assurer la restauration des systèmes TIC dans les délais définis par les objectifs de rétablissement. Ils doivent prendre en compte :

• La sauvegarde des données : fréquence, localisation, tests de restauration.
• Les sites de secours : capacité, localisation, délai d’activation.
• Les procédures de basculement : manuelles et automatiques.
• Les procédures de retour sur le site principal après resolution de l’incident.

Tests des plans

L’article 11, paragraphe 6, impose aux entités financières de tester régulièrement leurs plans de continuité et de reprise d’activité. Ces tests doivent :

• Couvrir des scénarios réalistes, incluant des cyberattaques et des défaillances de prestataires TIC.
• Être réalisés au moins une fois par an pour les fonctions critiques.
• Impliquer les prestataires TIC lorsque les plans dépendent de leurs services.
• Faire l’objet d’un rapport incluant les écarts identifiés et les actions correctives.

Documentation (articles 6 et 15)

Exigences de documentation

DORA impose un niveau élevé de documentation du cadre de gestion des risques TIC. Les documents requis incluent :

Document	Reference DORA	Frequence de révision
Cadre de gestion des risques TIC	Article 6	Annuelle (minimum)
Stratégie de résilience opérationnelle	Article 6.8	Annuelle
Politique de sécurité de l’information	Article 9.4	Annuelle
Inventaire des actifs TIC	Article 8	Continue (mise à jour permanente)
Cartographie des systèmes TIC	Article 8.4	Annuelle et après chaque changement
Analyse d’impact sur l’activité (BIA)	Article 11	Annuelle et après chaque changement
Plans de continuité d’activité (BCP)	Article 11	Annuelle et après chaque test
Plans de réponse aux incidents	Article 17	Annuelle et après chaque incident majeur
Programme de tests de résilience	Article 24	Annuelle
Registre des prestataires TIC	Article 28.3	Continue
Plan d’audit TIC	Article 6.6	Annuelle

Accessibilite de la documentation

L’ensemble de cette documentation doit être accessible aux autorités de surveillance sur demande. Les entités financières doivent être en mesure de la produire dans des délais raisonnables dans le cadre d’un contrôle.

Le cadre simplifié (article 16)

Entites eligibles

L’article 16 de DORA prévoit un cadre de gestion des risques TIC simplifié pour certaines catégories de petites entités financières :

• Les petites entreprises d’investissement non interconnectées.
• Les établissements de paiement exemptés au titre de la DSP2.
• Les établissements exemptés au titre de la directive sur la monnaie électronique.
• Les petites institutions de retraite professionnelle.

Allegements

Le cadre simplifié allegge certaines exigences tout en maintenant les obligations essentielles :

• Le cadre de gestion des risques TIC peut être moins formalisé, mais il doit néanmoins exister et être documenté.
• Les exigences de gouvernance sont allegees : l’organe de direction doit définir et superviser le cadre, mais les processus peuvent être simplifies.
• Les exigences de tests sont reduites, mais les tests de base (vulnérabilité, continuité) restent obligatoires.
• Les exigences de documentation sont proportionnées.

Le cadre simplifié ne dispense pas de l’essentiel : identification des risques, mesures de protection, détection des incidents, capacité de réponse et de rétablissement.

Les cinq fonctions en synthèse

Fonction	Articles DORA	Exigences clés
Identification	8, 9	Inventaire des actifs TIC, cartographie des systèmes, classification, BIA
Protection	9, 10, 13	Contrôle d’accès, chiffrement, gestion des changements, correctifs, PSSI, formation
Detection	10	Surveillance continue, SIEM/SOC, corrélation d’évènements, seuils d’alerte
Réponse	11, 17	Plans de réponse aux incidents, procédures de confinement, communication de crise
Retablissement	11, 12	BCP, DRP, objectifs RTO/RPO, sites de secours, tests réguliers

Mise en conformité : approche recommandée

La mise en conformité avec les exigences de gestion des risques TIC de DORA peut être abordee selon les étapes suivantes :

1. Diagnostic initial. Évaluer l’existant par rapport aux exigences de DORA. Identifier les écarts entre le cadre actuel de gestion des risques TIC et les exigences du règlement.

2. Cartographie des actifs et des risques. Réaliser ou mettre à jour l’inventaire des actifs TIC et la cartographie des systèmes. Identifier les fonctions critiques et les dépendances.

3. Formalisation du cadre. Rédiger ou mettre à jour les politiques, procédures et plans requis par DORA. S’assurer de leur cohérence et de leur exhaustivité.

4. Mise en oeuvre des mesures de protection. Déployer ou renforcer les mesures techniques et organisationnelles identifiées comme nécessaires (contrôle d’accès, chiffrement, surveillance…).

5. Test et validation. Tester l’ensemble du dispositif (plans de continuité, procédures de réponse, mécanismes de détection) pour valider son efficacité.

6. Gouvernance et suivi. Instaurer les mécanismes de gouvernance (reporting à l’organe de direction, fonction de contrôle, programme d’audit) et assurer le suivi continu du cadre.

Conclusion

Le cadre de gestion des risques TIC de DORA est ambitieux et structurant. Il élevé la gestion des risques informatiques au rang de priorité stratégique pour les entités financières, avec une responsabilité directe de l’organe de direction. Les cinq fonctions – identification, protection, détection, réponse et rétablissement – constituent un modèle complet qui couvre l’ensemble du cycle de vie des risques TIC.

La mise en conformité représente un effort significatif, mais elle s’inscrit dans une logique de renforcement de la résilience opérationnelle qui dépasse la simple conformité réglementaire. Les entités qui investissent dans ce cadre ameliorent concrètement leur capacité à faire face aux incidents cyber et aux perturbations opérationnelles.

Consultez notre guide DORA pour le cadre complet du règlement et notre article sur la politique de sécurité des systèmes d’information pour des orientations complémentaires sur la formalisation de votre PSSI.