Gestion des risques TIC sous DORA : cadre et exigences

Le cadre de gestion des risques TIC doit permettre à une entité financière de savoir quels services peuvent être interrompus, pourquoi et comment les rétablir. DORA exige une organisation documentée et suivie ; un inventaire de logiciels ou une politique de sécurité isolée ne suffit pas.

Commencez par vérifier le régime applicable. Les Art. 5 à 15 organisent le cadre ordinaire ; l’Art. 16 prévoit un cadre simplifié pour certaines catégories précises. La fiche sur les entités concernées par DORA permet de distinguer ces situations. Source : règlement DORA.

Relier les fonctions aux dépendances

Pour chaque fonction importante, identifiez les actifs informationnels, les systèmes, les accès, les flux et les prestataires dont elle dépend. L’Art. 8 organise l’identification ; les Art. 11 et 12 relient continuité, sauvegarde et rétablissement.

Une dépendance commune mérite une attention particulière : deux applications différentes peuvent reposer sur le même annuaire, le même réseau ou le même prestataire. Le risque ne se lit pas seulement dans la liste des fournisseurs.

Donner à la direction des décisions à prendre

L’Art. 5(2) attribue à l’organe de direction la responsabilité du cadre, notamment les rôles, la stratégie, la continuité, le budget et le suivi des prestataires. L’Art. 5(4) prévoit expressément le maintien des connaissances et compétences, notamment par une formation spécifique régulière proportionnée au risque. Cette obligation n’est pas simplement implicite. Source : Art. 5.

Présentez les risques résiduels, les mesures proposées, les ressources nécessaires et les dates de décision. Conservez les arbitrages et leur suivi. Pour les entités concernées, l’Art. 6(4) prévoit une fonction de contrôle suffisamment indépendante et une séparation appropriée des fonctions. L’attribution d’un titre de RSSI ne démontre pas automatiquement cette indépendance.

Construire un ensemble cohérent de mesures

Les Art. 9 et 10 portent sur la protection, la prévention et la détection. Les mesures doivent couvrir les accès, les changements, les vulnérabilités, les communications et les événements anormaux selon le cadre applicable. Définissez qui approuve un accès sensible, qui suit un correctif non appliqué et qui traite une alerte en dehors des heures habituelles.

Le règlement délégué (UE) 2024/1774 précise les outils, méthodes, processus et politiques ainsi que le cadre simplifié. Ses Art. 25 et 26 précisent notamment les essais et les plans de réponse et de rétablissement. Texte du règlement délégué 2024/1774. Utilisez sa version applicable pour détailler les procédures ; ne présentez pas un rythme interne choisi comme un minimum réglementaire universel.

La politique de sécurité des systèmes d’information peut rassembler les règles, à condition de les relier aux procédures et contrôles réels. Aucun nom de produit de supervision ne prouve à lui seul la capacité de détection.

Vérifier la continuité et le rétablissement

L’analyse d’impact sur l’activité permet d’identifier les effets des perturbations et les besoins de reprise. Définissez les objectifs de rétablissement à partir de ces besoins, puis confrontez-les aux possibilités des systèmes et des prestataires.

Une sauvegarde réussie ne suffit pas : il faut pouvoir restaurer les données, les applications, les droits et les dépendances nécessaires au service. Les tests de résilience DORA doivent documenter les écarts et leur correction. Les retours d’incidents alimentent également le cadre, conformément notamment aux Art. 6 et 13.

Fixer les réexamens selon le bon texte

L’Art. 6(5) impose un réexamen du cadre au moins annuel, ou périodique pour les microentreprises, ainsi qu’à l’occasion des événements qu’il prévoit. L’Art. 6(6) organise les audits internes réguliers des entités autres que les microentreprises avec une fréquence et un objectif proportionnés au risque. Il ne fixe pas indistinctement une révision annuelle de chaque document.

Pour les entités de l’Art. 16, appliquez le régime propre de son paragraphe 2. Conservez un calendrier par obligation, avec le texte, le responsable, le dernier contrôle et l’événement pouvant déclencher un réexamen anticipé. Le guide DORA replace ce dossier dans l’ensemble du dispositif.

Cas pratique : une reprise dépend du système déjà en panne

Scénario entièrement fictif. Un établissement de paiement français de 80 salariés, non exempté et relevant du cadre ordinaire, prépare la reprise de son service de traitement des ordres. Sa DSI annonce que les données sont sauvegardées et que le prestataire peut redémarrer l’application sur une infrastructure de secours. Le responsable des opérations demande pourtant une preuve sur le service complet, jusqu’au rapprochement des ordres, avant d’accepter ce dossier.

L’analyse des incidences retient deux heures comme objectif de délai de rétablissement, ou RTO, pour la fonction étudiée. Elle fixe à quinze minutes l’objectif de point de rétablissement, ou RPO, pour la copie de données utilisée. Ces valeurs sont des hypothèses du scénario fondées sur ses besoins métier, pas des seuils imposés à toutes les entités par DORA. Un RPO de quinze minutes n’autorise pas à ignorer les ordres reçus dans cet intervalle : la procédure prévoit leur reconstitution et leur rapprochement avec les journaux et les confirmations disponibles. DORA, Art. 12(6) et (7).

La fonction dépend de l’application, de la base des ordres, de l’annuaire d’authentification, du coffre donnant accès aux secrets techniques et d’un canal de communication avec le prestataire. Le responsable métier classe les conséquences : indisponibilité pour les clients, traitement tardif, ordre perdu ou doublonné. Restaurer uniquement la base ne traite donc qu’une partie du risque.

La fiche de risque renseignée

Cette fiche n’est pas un formulaire réglementaire complet. Elle fournit une unité de travail reliée aux politiques, à l’inventaire des actifs, aux engagements du prestataire et au programme d’audit. Le dossier conserve les pièces correspondantes plutôt qu’une simple couleur « risque maîtrisé ».

Premier exercice : l’objectif est dépassé

Un exercice isolé, avec des opérations fictives, simule la panne à 10 heures. La copie disponible date de 9 h 45. L’équipe découvre que le compte destiné à récupérer les secrets dépend encore de l’annuaire indisponible. Le portail d’assistance du prestataire utilise également cette connexion. L’application secondaire ne devient utilisable qu’à 12 h 40, après un rétablissement simulé de l’annuaire.

Le résultat est un échec : deux heures quarante dépassent l’objectif de deux heures. La présence d’une sauvegarde récente n’efface pas cette défaillance. Le rapport précise que la reprise autonome n’a pas été démontrée et décrit le chemin réellement suivi ; il ne remplace pas ce résultat par le délai de redémarrage du serveur seul.

La direction reçoit l’écart, son effet métier et les options chiffrables par les équipes. Elle affecte un responsable et des moyens à la suppression de la dépendance commune, reporte l’extension prévue du service et fixe une nouvelle démonstration avant de clore le risque. Inscrire « accepté par la direction » ne dispenserait pas de satisfaire aux obligations applicables. Le règlement délégué demande d’analyser, traiter et porter à l’organe de direction les défaillances des essais. Règlement 2024/1774, Art. 25(5).

Deuxième exercice : rétablir aussi l’intégrité

La DSI organise des accès de secours indépendants, limités et surveillés. Le canal d’urgence du prestataire est joignable sans l’annuaire ; les consignes restent accessibles dans cette situation. L’équipe vérifie d’abord ces moyens, puis rejoue le scénario complet. Cela ne signifie pas ouvrir un compte privilégié permanent sans protection.

Lors du second exercice fictif, la panne commence à 10 heures et les contrôles métier se terminent à 11 h 35. Le rapprochement détecte un ordre reconstitué deux fois ; le doublon est éliminé avant toute transmission simulée. Les références et totaux attendus concordent ensuite. Le délai de reprise de une heure trente-cinq comprend ces contrôles : on ne l’arrête pas dès l’affichage de l’écran de connexion.

La fonction de contrôle examine les traces, les exceptions et le périmètre exercé. La direction peut alors clore cette action précise. Elle ne déclare pas toute l’entité conforme : une panne réseau ou une défaillance durable du prestataire nécessitent d’autres scénarios. Les objectifs, dépendances et preuves alimentent le prochain réexamen du cadre.

Traiter les informations manquantes sans inventer une assurance

Si un prestataire ne fournit pas de résultat couvrant la fonction utilisée, notez « capacité non démontrée » avec le périmètre manquant. Demandez un exercice adapté ou une preuve exploitable et analysez les solutions de continuité. Une promesse contractuelle de disponibilité ne décrit pas forcément les conditions de restauration de vos données et de vos accès.

Pour un incident réel, activez aussi le processus de classification et les notifications applicables ; le suivi du plan correctif ne les remplace pas. À l’inverse, un défaut découvert dans un exercice isolé n’est pas, par sa seule existence, un incident majeur à déclarer. Il reste un écart à traiter. Cette distinction permet de produire un rapport fidèle sans masquer un événement réel derrière l’étiquette « test ».

Ce qu’il faut retenir

Le cadre doit relier fonctions, risques, mesures et preuves. La direction arbitre et suit ; les équipes vérifient les capacités réelles. Distinguez les régimes et les fréquences précises au lieu d’imposer une règle annuelle uniforme à toute la documentation.

FAQ

La formation des dirigeants est-elle explicitement prévue ?

Oui. L’Art. 5(4) prévoit notamment une formation spécifique régulière pour maintenir les connaissances et compétences suffisantes dans le cadre ordinaire.

Une certification de sécurité remplace-t-elle le cadre DORA ?

Non. Elle peut apporter des éléments utiles, mais il faut vérifier les obligations, le périmètre, les dépendances et la documentation propres à l’entité.

Le cadre simplifié dispense-t-il de tester la continuité ?

Non. L’Art. 16(1)(g) prévoit des tests réguliers des plans, mesures et contrôles qu’il vise. La simplification ne supprime pas la capacité à démontrer le fonctionnement.

Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.