Introduction

Le cadre de gestion des risques lies aux technologies de l’information et de la communication (TIC) constitue le coeur du reglement DORA (reglement (UE) 2022/2554). Les articles 5 a 16 definissent un ensemble d’exigences structurees autour de cinq fonctions fondamentales : identification, protection, detection, reponse et retablissement. Ce modele, inspire du NIST Cybersecurity Framework, est adapte aux specificites du secteur financier europeen et rendu juridiquement contraignant par le reglement.

Toute entite financiere soumise a DORA doit mettre en place et maintenir un cadre de gestion des risques TIC conforme a ces exigences. La responsabilite ultime repose sur l’organe de direction. Les normes techniques de reglementation (RTS) adoptees par les autorites europeennes de surveillance (AES) precisent les modalites d’application.

Pour une vue d’ensemble du reglement, consultez notre guide DORA. Pour des recommandations sur la formalisation de votre politique de securite, consultez notre article sur la politique de securite des systemes d’information (PSSI).

Gouvernance des risques TIC (article 5)

Responsabilite de l’organe de direction

L’article 5 de DORA place la responsabilite de la gestion des risques TIC au niveau le plus eleve de l’organisation. L’organe de direction de l’entite financiere (conseil d’administration, directoire, ou equivalent) est tenu de :

• Definir, approuver et superviser la mise en oeuvre du cadre de gestion des risques TIC.
• Assumer la responsabilite ultime de la gestion des risques TIC de l’entite.
• Definir les roles et responsabilites en matiere de fonctions TIC, y compris la continuite d’activite et les plans de reponse aux incidents.
• Approuver et reexaminer periodiquement la strategie de resilience operationnelle numerique de l’entite, 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 adequat pour la mise en oeuvre du cadre de gestion des risques TIC, y compris les programmes de sensibilisation et de formation.
• Etre informe regulierement des incidents TIC majeurs et de leurs consequences.

Cette implication directe de l’organe de direction constitue un changement culturel significatif pour de nombreuses entites financieres ou la gestion des risques TIC etait historiquement deleguee aux directions informatiques sans supervision formalisee au niveau du conseil.

Formation et competences

Bien que DORA ne contienne pas d’obligation explicite de formation des membres de l’organe de direction (a la difference de NIS2), l’article 5 exige implicitement que les dirigeants disposent de connaissances suffisantes pour exercer leur mission de supervision. Les entites financieres doivent prevoir des programmes de sensibilisation reguliers a destination de l’organe de direction.

Fonction de controle

L’article 6, paragraphe 4, de DORA impose aux entites financieres de mettre en place une fonction de controle (control function) pour la gestion des risques TIC, dotee d’une independance suffisante pour eviter les conflits d’interets. Cette fonction peut etre assuree par un RSSI (Responsable de la Securite des Systemes d’Information), un directeur des risques TIC ou toute personne disposant de l’autorite et de l’independance necessaires.

Le cadre de gestion des risques TIC (article 6)

Structure du cadre

L’article 6 impose aux entites financieres de mettre en place un cadre de gestion des risques TIC complet, documente et integre a leur dispositif global de gestion des risques. Ce cadre doit comprendre :

• Des strategies, politiques, procedures et outils necessaires pour proteger l’ensemble des actifs TIC et des informations de l’entite.
• Un dispositif de gestion des actifs TIC incluant l’identification et la classification de tous les actifs.
• Des mecanismes de detection des activites anormales.
• Des plans de reponse aux incidents et de retablissement.
• Des mecanismes de remontee d’information vers l’organe de direction.

Le cadre doit etre documente de maniere exhaustive et reexamine au moins une fois par an, ainsi qu’apres tout incident majeur, toute evolution significative des menaces ou tout changement important dans l’infrastructure TIC.

Strategie de resilience operationnelle numerique

En complement du cadre de gestion des risques, l’article 6, paragraphe 8, impose aux entites financieres de definir une strategie de resilience operationnelle numerique. Cette strategie doit couvrir :

• Les objectifs de resilience TIC de l’entite.
• L’architecture TIC cible et les evolutions prevues.
• Les mecanismes de detection et de prevention des incidents.
• La strategie de tests de resilience.
• La strategie 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 entites financieres de :

Identifier, classifier et documenter l’ensemble de leurs fonctions metier, de leurs actifs d’information et de leurs actifs TIC qui supportent ces fonctions. Cette cartographie doit etre exhaustive et maintenue a jour.

La classification des actifs doit prendre en compte :

• La criticite de chaque actif pour les fonctions metier de l’entite.
• Les interconnexions et dependances entre les actifs.
• Les proprietaires de chaque actif (responsable metier et responsable technique).

Cartographie des systemes TIC

L’article 8, paragraphe 4, impose une obligation specifique de cartographie des systemes TIC. Les entites financieres doivent identifier et documenter :

• Les processus metier qui dependent de prestataires TIC tiers.
• Les interconnexions entre les systemes TIC internes et les systemes des prestataires.
• Les flux de donnees entre les systemes.
• L’architecture reseau, y compris les points d’entree et de sortie.

Cette cartographie est essentielle pour comprendre l’exposition de l’entite aux risques TIC et pour planifier les mesures de protection et les tests de resilience.

Analyse d’impact sur l’activite (BIA)

L’article 11 de DORA impose aux entites financieres de realiser une analyse d’impact sur l’activite (Business Impact Analysis – BIA) pour evaluer les consequences potentielles d’une perturbation majeure de leurs systemes TIC.

La BIA doit :

• Identifier les fonctions critiques ou importantes de l’entite.
• Evaluer l’impact d’une interruption de ces fonctions (impact financier, operationnel, reputationnel, reglementaire).
• Determiner les objectifs de temps de retablissement (RTO – Recovery Time Objective) et les objectifs de point de retablissement (RPO – Recovery Point Objective) pour chaque fonction critique.
• Prendre en compte les dependances vis-a-vis des prestataires TIC tiers.

La BIA constitue la base sur laquelle sont construits les plans de continuite d’activite et de reprise d’activite.

Protection (articles 9 et 10)

Mesures de protection

L’article 9 definit les exigences en matiere de protection des systemes TIC. Les entites financieres doivent mettre en oeuvre des mesures techniques et organisationnelles pour :

Securite des reseaux et de l’infrastructure. Les entites doivent mettre en place des mecanismes de protection de l’infrastructure reseau, incluant la segmentation, le filtrage, le chiffrement des communications et la surveillance des flux.

Gestion des acces. Les politiques de controle d’acces doivent appliquer le principe du moindre privilege et du besoin d’en connaitre. L’authentification forte doit etre deployee pour les acces aux systemes critiques. Les comptes privilegies doivent faire l’objet d’une gestion renforcee.

Chiffrement. Les entites doivent mettre en oeuvre des politiques de chiffrement couvrant les donnees en transit et les donnees au repos. La gestion des cles cryptographiques doit etre documentee et securisee.

Gestion des changements. Toute modification des systemes TIC doit suivre un processus formalise de gestion des changements, incluant une evaluation des risques, des tests prealables et une approbation formelle.

Gestion des correctifs. Les entites doivent mettre en place un processus de gestion des correctifs de securite, incluant la veille sur les vulnerabilites, l’evaluation de leur criticite et le deploiement des correctifs dans des delais adaptes au risque.

Securite physique. La protection physique des infrastructures TIC (centres de donnees, salles serveurs) doit etre assuree par des mesures adaptees (controle d’acces physique, surveillance, protection contre les risques environnementaux).

Politique de securite de l’information

L’article 9, paragraphe 4, impose l’adoption d’une politique de securite de l’information (ou PSSI) couvrant l’ensemble des exigences de protection. Cette politique doit etre approuvee par l’organe de direction, communiquee a l’ensemble du personnel et reexaminee regulierement.

La PSSI doit couvrir au minimum :

• La classification des informations et des actifs TIC.
• Les regles de controle d’acces.
• Les regles de chiffrement.
• La gestion des incidents de securite.
• La securite des operations.
• La securite des communications.
• La gestion de la continuite.
• La sensibilisation et la formation du personnel.

Sensibilisation et formation

L’article 13, paragraphe 6, impose aux entites financieres de mettre en place des programmes de sensibilisation et de formation a la securite TIC a destination de l’ensemble du personnel, y compris la direction. Ces programmes doivent etre adaptes au profil de risque de l’entite et aux fonctions des personnes formees.

Detection (article 10)

Mecanismes de detection

L’article 10 impose aux entites financieres de mettre en place des mecanismes de detection des activites anormales, y compris les problemes de performance des reseaux TIC et les incidents lies aux TIC. Ces mecanismes doivent permettre :

• La detection rapide des incidents de securite et des anomalies.
• L’identification de la source et de la nature des incidents.
• La categorisation des incidents selon leur severite.
• Le declenchement des procedures de reponse appropriees.

Surveillance continue

Les entites doivent mettre en oeuvre une surveillance continue de leurs systemes TIC. Cela implique :

• Le deploiement d’outils de supervision et de journalisation (SIEM, IDS/IPS, SOC).
• La definition de seuils d’alerte adaptes au profil de risque.
• La correlation des evenements pour detecter les attaques complexes.
• La conservation des journaux pendant une duree suffisante pour permettre les investigations post-incident.

Les normes techniques de reglementation (RTS) precisent les exigences en matiere de capacites de detection, incluant les delais de detection attendus et les types d’incidents devant etre detectes.

Reponse et retablissement (articles 11 et 12)

Plans de continuite d’activite (BCP)

L’article 11 impose aux entites financieres de mettre en place des plans de continuite d’activite TIC (Business Continuity Plans – BCP) couvrant l’ensemble de leurs fonctions critiques ou importantes. Ces plans doivent :

• Etre fondes sur la BIA realisee par l’entite.
• Definir les procedures de basculement vers les systemes de secours.
• Fixer des objectifs de retablissement (RTO/RPO) alignes sur les besoins metier.
• Identifier les ressources necessaires pour la mise en oeuvre (personnel, equipements, prestataires).
• Etre testes regulierement pour verifier leur efficacite.

Plans de reponse aux incidents

L’article 17 (qui releve du chapitre sur la gestion des incidents mais s’integre dans le cadre de gestion des risques) impose aux entites financieres de definir des plans de reponse aux incidents TIC comprenant :

• Les procedures d’alerte et de remontee d’information.
• Les roles et responsabilites de chaque intervenant.
• Les procedures de confinement de l’incident.
• Les procedures de communication interne et externe.
• Les procedures de retour a la normale.
• Les procedures d’analyse post-incident (retour d’experience).

Plans de reprise d’activite (DRP)

Les plans de reprise d’activite TIC doivent assurer la restauration des systemes TIC dans les delais definis par les objectifs de retablissement. Ils doivent prendre en compte :

• La sauvegarde des donnees : frequence, localisation, tests de restauration.
• Les sites de secours : capacite, localisation, delai d’activation.
• Les procedures de basculement : manuelles et automatiques.
• Les procedures de retour sur le site principal apres resolution de l’incident.

Tests des plans

L’article 11, paragraphe 6, impose aux entites financieres de tester regulierement leurs plans de continuite et de reprise d’activite. Ces tests doivent :

• Couvrir des scenarios realistes, incluant des cyberattaques et des defaillances de prestataires TIC.
• Etre realises au moins une fois par an pour les fonctions critiques.
• Impliquer les prestataires TIC lorsque les plans dependent de leurs services.
• Faire l’objet d’un rapport incluant les ecarts identifies et les actions correctives.

Documentation (articles 6 et 15)

Exigences de documentation

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

Document	Reference DORA	Frequence de revision
Cadre de gestion des risques TIC	Article 6	Annuelle (minimum)
Strategie de resilience operationnelle	Article 6.8	Annuelle
Politique de securite de l’information	Article 9.4	Annuelle
Inventaire des actifs TIC	Article 8	Continue (mise a jour permanente)
Cartographie des systemes TIC	Article 8.4	Annuelle et apres chaque changement
Analyse d’impact sur l’activite (BIA)	Article 11	Annuelle et apres chaque changement
Plans de continuite d’activite (BCP)	Article 11	Annuelle et apres chaque test
Plans de reponse aux incidents	Article 17	Annuelle et apres chaque incident majeur
Programme de tests de resilience	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 etre accessible aux autorites de surveillance sur demande. Les entites financieres doivent etre en mesure de la produire dans des delais raisonnables dans le cadre d’un controle.

Le cadre simplifie (article 16)

Entites eligibles

L’article 16 de DORA prevoit un cadre de gestion des risques TIC simplifie pour certaines categories de petites entites financieres :

• Les petites entreprises d’investissement non interconnectees.
• Les etablissements de paiement exemptes au titre de la DSP2.
• Les etablissements exemptes au titre de la directive sur la monnaie electronique.
• Les petites institutions de retraite professionnelle.

Allegements

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

• Le cadre de gestion des risques TIC peut etre moins formalise, mais il doit neanmoins exister et etre documente.
• Les exigences de gouvernance sont allegees : l’organe de direction doit definir et superviser le cadre, mais les processus peuvent etre simplifies.
• Les exigences de tests sont reduites, mais les tests de base (vulnerabilite, continuite) restent obligatoires.
• Les exigences de documentation sont proportionnees.

Le cadre simplifie ne dispense pas de l’essentiel : identification des risques, mesures de protection, detection des incidents, capacite de reponse et de retablissement.

Les cinq fonctions en synthese

Fonction	Articles DORA	Exigences cles
Identification	8, 9	Inventaire des actifs TIC, cartographie des systemes, classification, BIA
Protection	9, 10, 13	Controle d’acces, chiffrement, gestion des changements, correctifs, PSSI, formation
Detection	10	Surveillance continue, SIEM/SOC, correlation d’evenements, seuils d’alerte
Reponse	11, 17	Plans de reponse aux incidents, procedures de confinement, communication de crise
Retablissement	11, 12	BCP, DRP, objectifs RTO/RPO, sites de secours, tests reguliers

Mise en conformite : approche recommandee

La mise en conformite avec les exigences de gestion des risques TIC de DORA peut etre abordee selon les etapes suivantes :

1. Diagnostic initial. Evaluer l’existant par rapport aux exigences de DORA. Identifier les ecarts entre le cadre actuel de gestion des risques TIC et les exigences du reglement.

2. Cartographie des actifs et des risques. Realiser ou mettre a jour l’inventaire des actifs TIC et la cartographie des systemes. Identifier les fonctions critiques et les dependances.

3. Formalisation du cadre. Rediger ou mettre a jour les politiques, procedures et plans requis par DORA. S’assurer de leur coherence et de leur exhaustivite.

4. Mise en oeuvre des mesures de protection. Deployer ou renforcer les mesures techniques et organisationnelles identifiees comme necessaires (controle d’acces, chiffrement, surveillance…).

5. Test et validation. Tester l’ensemble du dispositif (plans de continuite, procedures de reponse, mecanismes de detection) pour valider son efficacite.

6. Gouvernance et suivi. Instaurer les mecanismes de gouvernance (reporting a l’organe de direction, fonction de controle, 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 eleve la gestion des risques informatiques au rang de priorite strategique pour les entites financieres, avec une responsabilite directe de l’organe de direction. Les cinq fonctions – identification, protection, detection, reponse et retablissement – constituent un modele complet qui couvre l’ensemble du cycle de vie des risques TIC.

La mise en conformite represente un effort significatif, mais elle s’inscrit dans une logique de renforcement de la resilience operationnelle qui depasse la simple conformite reglementaire. Les entites qui investissent dans ce cadre ameliorent concretement leur capacite a faire face aux incidents cyber et aux perturbations operationnelles.

Consultez notre guide DORA pour le cadre complet du reglement et notre article sur la politique de securite des systemes d’information pour des orientations complementaires sur la formalisation de votre PSSI.