Risques cyber au conseil d’administration : ce qu’un bon rapport doit montrer
Réponse courte : un bon rapport prépare une décision
Réponse courte : un bon rapport cyber au conseil d’administration répond à trois questions. Qu’est-ce qui est en jeu pour l’entreprise ? Dans quelle mesure l’évaluation est-elle étayée ? Que doit décider le conseil d’administration ? Les chiffres d’activité et les feux verts ne répondent à aucune de ces questions à eux seuls.
Le modèle d’une page présenté dans cet article vous aide à vérifier votre rapport actuel. Il s’agit d’une aide de travail de SIDD, et non d’un résultat ou d’un modèle testé de l’étude citée.
Ce que montre une étude sur les rapports aux boards, et ce qu’elle ne montre pas
Opdenbusch, Hielscher et Sasse ont interrogé 18 dirigeants de grandes organisations britanniques : membres de direction, membres non exécutifs de boards, consultants et CISO. Un CISO (Chief Information Security Officer, souvent appelé RSSI en français) dirige la sécurité de l’information. Les entretiens ont eu lieu au premier semestre 2021.
Selon les personnes interrogées, les décisions des boards sur les risques cyber se résumaient le plus souvent à des questions de budget. Certaines questions n’étaient pas posées, par incertitude. Les auteurs y voient une forte dépendance à l’égard des personnes qui font rapport, ce qui affaiblit la surveillance. L’étude est qualitative, non représentative et ne dit rien des PME suisses. Un board britannique est en outre organisé autrement qu’un conseil d’administration suisse.
En Suisse, la haute surveillance sur les personnes chargées de la gestion reste une attribution intransmissible du conseil d’administration (art. 716a, al. 1, ch. 5, CO). Il « veille à ce que ses membres soient convenablement informés » (al. 2). La loi ne précise pas ce que cela implique pour les risques cyber.
Notre article « Un budget cyber ne vaut pas surveillance : les questions que le conseil d’administration devrait poser » montre quelles questions le conseil d’administration peut poser à ce sujet.
Pourquoi les chiffres d’activité ne suffisent pas à évaluer les risques
De nombreux rapports montrent tout ce que fait l’informatique : courriels d’hameçonnage filtrés, mises à jour installées, formations. L’hameçonnage (phishing) désigne des messages falsifiés destinés à dérober des identifiants. Ces chiffres sont utiles pour piloter l’informatique.
Pour évaluer les risques, il leur manque le lien avec les affaires. Un taux de clics en baisse lors de tests d’hameçonnage est réjouissant. Il ne montre pas si un mot de passe volé donnerait malgré tout accès au système de commande. Les auteurs de l’étude relèvent eux aussi qu’on n’a pas encore étudié quels indicateurs aident réellement un board.
Pourquoi un statut vert sans preuve en dit peu
Un feu tricolore montre comment la personne qui fait rapport évalue la situation, pas sur quoi repose cette évaluation. « Sauvegarde : vert » signifie souvent seulement que la sauvegarde s’exécute. Reste à savoir si les systèmes peuvent être restaurés à temps à partir de celle-ci.
Une preuve peut être vérifiée par un tiers. Elle indique la date, le résultat et le périmètre, c’est-à-dire ce sur quoi elle porte. Exemples : le procès-verbal d’un test de restauration ou un rapport de test d’intrusion avec les constats encore ouverts. Un test d’intrusion est une attaque mandatée et contrôlée contre vos propres systèmes.
Un champ réservé aux preuves n’est pas un vote de défiance. Le conseil d’administration peut poser des questions ciblées, et la direction peut étayer son évaluation.
Le modèle de rapport : neuf champs sur une page
Le modèle décrit un risque par page. Commencez par les deux ou trois processus dont l’interruption toucherait le plus votre entreprise. La colonne de droite vous aide à vérifier votre rapport actuel.
| Champ | Contenu | Question à poser à votre rapport |
|---|---|---|
| 1. Processus d’affaires critique | Un processus sans lequel l’entreprise ne peut pas fonctionner. | Le rapport nomme-t-il un processus ou seulement un système informatique ? |
| 2. Scénario de défaillance concret | Ce qui se passe, par quelle cause et avec quels systèmes. | Le scénario est-il assez concret pour être exercé ? |
| 3. Conséquences pour les affaires | Conséquences pour les clients, le chiffre d’affaires, les contrats, les données personnelles et la réputation. | Les hypothèses sont-elles indiquées ? |
| 4. Tolérance fixée par les organes dirigeants | Durée d’interruption maximale acceptable et perte de données maximale acceptable. | Les organes dirigeants ont-ils décidé, ou l’informatique ? |
| 5. Mesures de protection existantes et preuves vérifiables | Chaque mesure avec sa preuve, sa date et son périmètre. | Chaque affirmation est-elle étayée ? |
| 6. Risque résiduel et incertitude | Ce qui reste ouvert et le degré de certitude de l’évaluation. | L’incertitude est-elle nommée ? |
| 7. Options d’action et effort | Deux ou trois options, y compris assumer le risque en connaissance de cause. | Existe-t-il un véritable choix ? |
| 8. Personne responsable | Nom et fonction, pas un service. | Sait-on clairement qui met en œuvre ? |
| 9. Décision requise et échéance | Ce que le conseil d’administration doit décider, et d’ici quand. | Le rapport se termine-t-il par une question au conseil d’administration ? |
Si la tolérance, les preuves ou la décision requise manquent, le rapport informe, mais soutient à peine la surveillance. Le modèle peut par exemple devenir contraignant si le règlement d’organisation y renvoie. Celui-ci « règle en particulier l’obligation de faire rapport » (art. 716b, al. 3, CO).
Exemple complété (fictif)
L’exemple est entièrement inventé : une entreprise commerciale avec entrepôt et boutique en ligne. Les montants des dommages et les probabilités ne sont volontairement pas estimés.
| Champ | Exemple fictif |
|---|---|
| 1. Processus | Traitement des commandes, de la réception de la commande à l’expédition. |
| 2. Scénario | Un logiciel malveillant chiffre l’ERP, le progiciel de gestion central pour les commandes, le stock et les factures. Les commandes ne peuvent être ni saisies ni livrées. |
| 3. Conséquences | Retards de livraison pour les grands clients, pénalités contractuelles possibles. Si des données de clients sont touchées, il faut examiner une annonce au PFPDT, l’autorité fédérale de protection des données (art. 24 LPD). Perte de chiffre d’affaires par jour et pénalités contractuelles : encore à déterminer. |
| 4. Tolérance | Proposition de la direction : traiter à nouveau les commandes au plus tard après 48 heures, au besoin de manière restreinte. Perte de données d’au maximum un jour ouvrable. Encore à confirmer par le conseil d’administration. |
| 5. Mesures et preuves | Sauvegarde quotidienne, une copie déconnectée du réseau (preuve : journaux de sauvegarde). Accès à distance uniquement avec un second facteur en plus du mot de passe (preuve : extrait de la gestion des utilisateurs). Test de restauration de l’ERP : encore à déterminer. |
| 6. Risque résiduel et incertitude | Rien n’établit que l’ERP fonctionnerait à nouveau dans les 48 heures. Jusqu’ici, seuls des fichiers isolés ont été restaurés, la direction informatique juge donc l’objectif incertain. |
| 7. Options et effort | A : test de restauration avec le partenaire informatique, effort encore à déterminer. B : définir et exercer une procédure d’urgence pour la saisie manuelle des commandes, faible effort interne. C : porter la tolérance à 72 heures et assumer le risque en connaissance de cause. |
| 8. Responsabilité | Responsable finances et informatique, membre de la direction (nommément dans un rapport réel). |
| 9. Décision et échéance | Confirmer ou adapter la tolérance. Approuver les options A et B ou choisir C. Échéance : prochaine séance ordinaire. |
Le véritable constat figure au champ 5 : la sauvegarde fonctionne, mais rien n’établit son efficacité en cas d’urgence.
Pourquoi les estimations financières exigent des hypothèses et des fourchettes
Un chiffre unique de dommage paraît précis, mais masque ses hypothèses. Une estimation solide les indique : combien de temps le processus sera-t-il interrompu ? Quels coûts surviennent par jour, par exemple du fait de la perte de chiffre d’affaires, du travail supplémentaire ou de l’aide externe ? Qu’est-ce qui n’est pas pris en compte ?
Au lieu d’un chiffre unique, le rapport devrait indiquer une fourchette, avec un cas favorable et un cas défavorable. Il précise aussi qui a fait l’estimation et quand. Si une base fait défaut, le rapport indique « encore à déterminer ».
Dans l’étude, un consultant souhaitait pouvoir mieux chiffrer les conséquences des risques cyber. Un membre non exécutif d’un board a renvoyé au secteur financier : la mesure y est familière, mais les risques cyber s’intègrent mal dans les cadres existants. Des fourchettes avec des hypothèses explicites constituent une voie médiane pragmatique.
Atelier ponctuel ou pilotage continu de la sécurité ?
Votre besoin de soutien dépend de ce qui se passe après le premier rapport. Un bon rapport ne nécessite pas de certification.
Un atelier ponctuel suffit si
- vous remplissez le modèle pour la première fois et souhaitez situer votre rapport actuel.
- quelques processus critiques sont au premier plan.
- quelqu’un en interne ou chez votre partenaire informatique met en œuvre les mesures et tient le rapport à jour.
L’atelier risques cyber pour CA et direction, une variante de notre atelier de sécurité informatique axée sur la direction, convient pour cela.
Un pilotage continu de la sécurité est judicieux si
- le rapport doit être mis à jour régulièrement et si personne en interne ne peut assumer ce rôle.
- de nombreuses mesures restent ouvertes pendant des mois.
- des clients, des assureurs ou l’autorité de surveillance demandent régulièrement des preuves.
- le conseil d’administration souhaite une évaluation qui ne provienne pas uniquement de l’équipe informatique chargée de la mise en œuvre.
Un CISO externe peut alors assurer le pilotage et faire rapport à la direction et au conseil d’administration. Vous souhaitez passer en revue votre rapport actuel avec nous ? Utilisez le formulaire de contact.
Sources
Toutes les sources consultées le 20 octobre 2026.
- Opdenbusch, J. C., Hielscher, J., Sasse, M. A. : « Where Are We On Cyber? » A Qualitative Study On Boards’ Cybersecurity Risk Decision Making, NDSS Symposium 2025, DOI 10.14722/ndss.2025.240595 (en anglais)
- Code des obligations (CO, RS 220), art. 716a et 716b, Fedlex, état le 1er octobre 2026
- Loi fédérale sur la protection des données (LPD, RS 235.1), art. 24, Fedlex, état le 7 juillet 2025
Cet article est une information générale et ne constitue pas un conseil juridique. Le modèle de rapport est une aide de travail de SIDD et non un résultat de l’étude citée.
