DORA : rapports au conseil d’administration, indicateurs, éléments probants et tableau de bord

1. Commencez par les décisions que le conseil doit prendre

Un dossier pour le conseil peut rassembler tous les indicateurs de sécurité collectés par l’organisation sans répondre à la question cruciale : l’entreprise peut-elle continuer à servir les clients en cas d’incident ? Un rapport trouve sa place s’il met au jour une incertitude majeure, explique un arbitrage ou soutient une décision sur les ressources, les priorités ou le risque.

Demandez : qu’est-ce qui a changé depuis la réunion précédente ? Quel service destiné aux clients pourrait désormais connaître une défaillance inacceptable pour l’organisation ? Quelle décision faut-il prendre aujourd’hui ? Présentez les réponses avant les graphiques qui les étayent. Un administrateur ne devrait pas avoir à déduire d’une case rouge à la page trente qu’une décision de financement urgente est nécessaire.

Dans le cadre général de gestion des risques liés aux TIC, l’Article 5 couvre la responsabilité de l’organe de direction et la formation régulière ; l’Article 6 traite du cadre de gestion des risques et de sa révision ; l’Article 13(5) exige au moins un rapport annuel des responsables TIC sur certaines constatations et recommandations. Voir DORA, articles 5, 6 et 13.

Ces dispositions n’imposent ni tableau de bord agréé ni format universel pour un dossier mensuel du conseil. Adaptez la fréquence des rapports aux risques et à votre gouvernance, avec une procédure d’escalade pour les urgences entre deux réunions. Distinguez les notifications légales, les demandes de l’autorité de surveillance et les rapports internes à la direction. Ce guide propose une méthode pratique ; il ne remplace pas l’analyse des obligations propres à votre entité. Pour comprendre la répartition des rôles, consultez notre guide sur les responsabilités du conseil au titre de DORA.

2. Organisez le rapport en fonction des services et de l’impact métier

Commencez par une courte liste de services métier que les administrateurs connaissent : effectuer un paiement, accéder à un compte d’investissement, régler une transaction ou recevoir une demande d’indemnisation d’assurance. Reliez ces services à l’évaluation des fonctions critiques ou importantes de l’entité. Ne remplacez pas sans le préciser cette vision métier par une liste d’applications. Un service peut nécessiter plusieurs applications, équipes, installations et prestataires externes.

Pour chaque service, identifiez un responsable métier et décrivez les conséquences d’une interruption. Incluez les clients ou transactions concernés, les échéances critiques, les solutions manuelles et le point à partir duquel les arriérés deviennent difficiles à résorber. Distinguez impact mesuré et estimations. Si le nombre de clients est incomplet, indiquez l’incertitude plutôt que de présenter un total qui paraît précis.

Une ligne utile consacrée à un service associe exposition et preuves : le principal scénario de défaillance, l’objectif de reprise, le test pertinent le plus récent et la faiblesse restante. Une restauration réussie de base de données peut apporter peu d’assurance sur le service de paiement si l’accès via le service d’identité, le rapprochement et la connectivité sortante ont été exclus de l’exercice.

Rendez les changements visibles. Un nouveau prestataire, une acquisition, un lancement de produit ou une migration peut rendre obsolète la cartographie des services de la veille. Marquez une évaluation comme à actualiser lorsqu’une dépendance majeure évolue. Sinon, la présentation peut rester artificiellement verte alors que les preuves décrivent un modèle opérationnel dépassé.

Gardez les inventaires techniques détaillés accessibles par des liens à accès contrôlé. La page destinée au conseil doit expliquer les conséquences et les décisions ; les éléments de preuve doivent permettre aux personnes chargées de l’examen de relier ces affirmations aux équipes responsables.

3. Définissez chaque indicateur avant de lui attribuer une couleur

Un pourcentage sans dénominateur prête à confusion. « Tests de reprise terminés : 90 % » peut signifier neuf exercices sur dix prévus, neuf services métier sur dix ou neuf applications sur dix. Ces affirmations ne mesurent pas la même chose. Indiquez le numérateur et le dénominateur à côté de l’indicateur et précisez les exclusions.

• Objectif : la décision ou la question de risque à laquelle l’indicateur aide à répondre.
• Population : les services, systèmes, fournisseurs ou personnes inclus, ainsi que les exclusions.
• Calcul : le numérateur exact, le dénominateur, l’unité et le traitement des données manquantes.
• Responsabilités : le responsable métier, le producteur de données et la personne chargée de la vérification.
• Temporalité : période d’observation, date d’extraction, date d’analyse et prochaine mise à jour.
• Éléments probants : le document ou l’enregistrement qui étaye le résultat, avec sa version et des règles de gestion définies.
• Escalade : seuil convenu en interne et action déclenchée en cas de dépassement.

Distinguez « non testé », « test échoué » et « preuve indisponible ». Les regrouper dans un seul statut vert ou orange masque le travail restant. Affichez les chiffres absolus en plus des pourcentages afin qu’une petite population ne crée pas une fausse confiance. Passer d’une action en retard à deux représente un doublement, mais sa signification dépend du service concerné et de la gravité.

Préservez la comparabilité. Si le dénominateur s'élargit après une acquisition, indiquez la nouvelle population et la raison de la rupture de continuité. N'interprétez pas un pourcentage d'achèvement plus faible comme une dégradation de l'exécution sans vérifier le périmètre.

4. Séparez les objectifs de reprise de la performance démontrée

L’objectif de délai de reprise (RTO) fixe le temps visé pour rétablir un service ou une capacité après une interruption. L’objectif de point de reprise (RPO) définit la perte de données acceptable, exprimée en durée. Aucun des deux ne prouve que la reprise fonctionne réellement. Présentez séparément l’objectif et le résultat observé, avec le scénario, le périmètre et les limites de la mesure.

Un RTO de quatre heures ne signifie pas qu’une commande de restauration doit se terminer en quatre heures, tandis que le rapprochement des données a lieu plus tard. Définissez quand le décompte commence et quelle validation métier y met fin. Pour le RPO, consignez le point de reprise exploitable le plus récent et indiquez si le rapprochement des transactions a confirmé l’exhaustivité des données. Un système peut redémarrer rapidement avec des données trop anciennes ou peu fiables.

Dans le cadre général, l’article 11, paragraphe 6, prévoit des tests annuels des plans de continuité et de reprise pour l’ensemble des fonctions, ainsi que des tests en cas de changements substantiels. L’article 24, paragraphe 6, exige des tests appropriés au moins annuels de tous les systèmes et applications TIC soutenant des fonctions critiques ou importantes, à l’exception des microentreprises. Voir les dispositions de DORA relatives aux tests. Vérifiez le périmètre spécifique à l’entité avant de transformer ces exigences en calendrier.

L’article 25 du règlement délégué 2024/1774relie les tests de continuité aux analyses d’impact sur l’activité et aux évaluations des risques. Il exige que les insuffisances soient analysées, corrigées et signalées à l’organe de direction. Associez chaque objectif non atteint à une action corrective, à un responsable désigné et à un programme de nouveaux tests.

Traitez séparément les tests de pénétration fondés sur la menace, ou TLPT. Ils s’appliquent à des entités identifiées, et non à toutes les entités ; les critères de sélection et les exigences relatives aux tests sont détaillés dans le règlement délégué 2025/1190, parallèlement aux articles 26–27 de DORA. Un exercice sur table, un scan de vulnérabilités ou un test de pénétration classique ne doit pas être qualifié de TLPT. Précisez le type d’éléments de preuve que chaque exercice fournit réellement.

5. Montrez la concentration des fournisseurs à travers les dépendances des services

Le nombre de prestataires ne révèle pas la concentration. Trois fournisseurs peuvent dépendre de la même région cloud, de la même plateforme d’identité ou de la même liaison de télécommunications. Pour chaque service important, demandez quelles dépendances pourraient tomber en panne ensemble et si la solution de remplacement proposée est indépendante sur le plan opérationnel. Distinguez les solutions de remplacement contractuelles de celles qui ont été configurées, dotées de personnel et testées lors d’exercices.

Les orientations de l’ABE sur le registre d’informations expliquent le registre des accords contractuels relatifs aux services TIC et proposent des ressources pour la déclaration. Utilisez ce registre pour alimenter les informations présentées au conseil. Un registre complet est utile, mais le conseil doit aussi comprendre ce que ces relations impliquent pour la continuité des services.

Un tableau synthétique des dépendances peut présenter les services pris en charge par un prestataire, les éléments d’assurance les plus récents, les limites non résolues, le délai estimé de sortie et la prochaine étape nécessitant une décision. Présentez le délai de sortie comme une estimation tant qu’il n’est pas étayé par des travaux crédibles. Incluez l’extraction des données, la migration, les compétences, les restrictions contractuelles et la transition des clients, et pas seulement le remplacement de l’infrastructure.

Posez une question centrée sur la décision à prendre : si ce fournisseur devenait indisponible ou inadapté, quel service nous obligerait à agir en premier et qu’est-ce qui empêcherait une transition ordonnée ? Signalez explicitement aux responsables concernés les informations manquantes et les responsabilités encore non définies pour les dépendances. Notre guide DORA sur les risques liés aux prestataires tiers de services TIC développe plus en détail les questions sur les fournisseurs et les contrats.

6. Expliquez les tendances des incidents et depuis quand les risques restent ouverts

Le nombre d’incidents doit être mis en contexte. Une hausse peut refléter une meilleure détection plutôt qu’une dégradation de la résilience. Une baisse peut refléter un flux de données incomplet. Précisez la définition utilisée, la période d’observation, l’impact significatif sur le service et si les méthodes de collecte ont changé. Distinguez les niveaux de gravité internes de la classification réglementaire des incidents ; un graphique destiné au conseil ne doit pas redéfinir implicitement le processus de notification.

Des vues utiles incluent le temps de perturbation par service, les récurrences, les changements infructueux, la performance de reprise et l’ancienneté des actions correctrices importantes. Pour les métriques de détection ou de temps de réponse, consignez des événements de début et de fin cohérents. Les moyennes peuvent masquer une interruption prolongée : affichez l’étendue ou l’exception la plus significative si cela influe sur la décision.

Suivez les actions issues des incidents, tests, audits et évaluations des fournisseurs dans une vue commune, tout en conservant leur origine. Chaque entrée doit préciser le responsable, l’échéance initiale, l’échéance actuelle, le service concerné, les preuves d’achèvement et la personne chargée de les vérifier. Un ticket marqué « terminé » ne prouve pas à lui seul que la faiblesse a été corrigée.

Montrez les prolongations et les actions rouvertes. Reporter une échéance peut améliorer un graphique de retard sans modifier l’exposition. Notez qui a autorisé la prolongation, la raison, les protections provisoires et la prochaine revue. Priorisez les conséquences de la faiblesse résiduelle plutôt que de récompenser la clôture de tickets peu impactants.

Terminez cette rubrique par une brève explication du problème récurrent et de l’intervention proposée. Si plusieurs incidents révèlent la même responsabilité mal définie, une décision opérationnelle claire peut être plus utile qu’un nouveau tableau de bord.

7. Reliez les données de suivi des apprentissages au discernement démontré

La validation d’une formation est une bonne preuve de participation, mais n’indique pas si les administrateurs savent remettre en cause une promesse de rétablissement optimiste ou faire un choix difficile de priorisation de service. Associez les enregistrements de formation à quelques exercices appliqués. Demandez aux participants d’identifier les preuves manquantes, de choisir des points d’escalade et d’expliquer les arbitrages en cas de perturbation de service fictive.

Déclarez la population formée, le contenu assigné et sa version, les dates d’achèvement, la méthode d’évaluation et les besoins de suivi. Consignez les changements de rôle et nouvelles nominations pour garder un dénominateur exact. Pour ceux disposant d’une expérience pertinente, documentez comment cela a été pris en compte et les connaissances spécifiques à l’organisation restant à acquérir.

Une discussion utile sur les apprentissages peut révéler que les participants comprennent la terminologie des rançongiciels, mais ne peuvent pas expliquer qui peut autoriser une dépense d’urgence. L’action à mener est alors précise : clarifier les pouvoirs d’autorisation, mettre à jour le plan et s’entraîner à l’utiliser. Évitez de présenter la note moyenne d’un quiz comme une mesure de la résilience globale de l’organisation.

Pour la conception de programmes, utilisez notre guide des exigences DORA pour la formation des conseils. Pour l’entraînement, le guide de l’exercice sur table de réponse aux incidents pour les dirigeants montre comment transformer une interruption en décisions et en apprentissage documenté. Limitez convenablement l’accès aux preuves individuelles d’apprentissage ; le dossier du conseil requiert généralement la couverture, les lacunes et les actions résultantes plutôt que le détail des réponses de chaque participant.

8. Un tableau de bord fictif du conseil d’administration présentant des écarts appelant une action

L’exemple suivant est entièrement fictif. Les chiffres ne sont ni des références sectorielles, ni des seuils légaux, ni des constats concernant une organisation réelle. Supposons qu’une entité financière ait retenu quatre services pour ce rapport. Le dossier de septembre présente la situation au 30 septembre et désigne les responsables des éléments probants pour le suivi.

Dans cet exemple, l’objectif de perte de données a été atteint, mais l’objectif de délai de reprise ne l’a pas été. Regrouper les deux sous une seule mention « reprise réussie » masquerait le retard de rétablissement du service. La ligne de couverture mesure les services, et non l’ensemble des éléments soumis aux tests au niveau des systèmes ; le registre de tests sous-jacent doit conserver ce périmètre distinct.

Le tableau évite également de confondre un résultat inconnu avec un échec de test. Les administrateurs distinguent les incertitudes à examiner des faiblesses avérées qui nécessitent une réponse financée. Reliez chaque ligne aux preuves conservées selon vos règles de gestion et de contrôle d’accès. Reprenez la décision dans les dossiers suivants jusqu’à la vérification de son résultat.

9. Transformez le rapport en un processus de décision reproductible

Utilisez un compte-rendu de décision succinct pour chaque dérogation importante. Décrivez le service concerné, le scénario, les preuves disponibles et l’incertitude résiduelle. Précisez les options réalistes, leur coût ou implications en ressources, la recommandation du management et la conséquence du report. Identifiez l’autorité de décision et la date limite pour décider.

Exemple de formulation d’une décision : approuver l’amélioration proposée pour la reprise du service de paiement, le directeur des opérations étant responsable de sa mise en œuvre. Exiger un nouveau test au regard des objectifs énoncés, au plus tard à la date convenue. Consigner les mesures provisoires, l’exposition résiduelle et les déclencheurs d’escalade. Présenter le résultat et les preuves lors de la prochaine réunion du comité compétent.

Si un risque est accepté temporairement, consignez la justification, l’autorité qui approuve cette acceptation, ses conditions et sa date d’expiration. L’acceptation est une décision de gouvernance ; elle ne fait pas disparaître une obligation légale non respectée. Un procès-verbal qui indique simplement que le conseil « a pris note du rapport » renseigne peu sur l’examen critique, les autres options ou le suivi.

1. Convenez de l’ensemble des services concernés et reliez-les aux exigences applicables et aux responsabilités internes.
2. Commencez par un petit nombre d’indicateurs et définissez-les avant d’automatiser la collecte.
3. Désignez des responsables des données et des personnes chargées de les vérifier, fixez une date limite et précisez comment traiter les éléments de preuve manquants.
4. Vérifiez un indicateur en le rapprochant de sa source, puis assurez-vous que le commentaire correspond au résultat réel.
5. Organisez une répétition avec une exception fictive et vérifiez si le dossier permet de trancher clairement.
6. Consignez la décision, communiquez l’action à mener et vérifiez ses effets dans les rapports suivants.

Commencez par un dossier fiable que les participants peuvent examiner de manière critique. Automatisez ensuite la collecte, une fois les définitions stabilisées. Pour une base commune en matière de supervision, notre programme «Formation à la cybersécurité pour les conseils d’administration et les dirigeants dans le cadre de DORA» comprend huit modules et environ trois heures d’étude guidée. Intégrez-le à un programme plus large de discussions, de pratique et de suivi adaptés à l’organisation. Son achèvement ne suffit pas, à lui seul, à établir la conformité réglementaire.