Aller au contenu
Legiscope
Menu
Cybersécurité et GRC

Appétence au risque cyber : traduire une décision de direction en seuils

Cahier de décision pour relier résultats métiers, seuils de risque cyber, conditions d'escalade et déclencheurs de révision.

Une direction peut dire qu’elle a « une faible appétence au risque cyber » sans que cette formule aide à arbitrer une interruption de service, une exception de sécurité ou une dépense de réduction du risque. Pour devenir utilisable, la décision doit désigner les résultats métiers à protéger, les limites acceptables, la personne qui tranche et les circonstances qui imposent un nouvel examen. Cette page propose un cahier de décision, avec des seuils illustratifs et une règle d’escalade; elle ne prétend pas fournir des valeurs universelles.

Le NIST Cybersecurity Framework 2.0 et son guide de liaison avec la gestion des risques d’entreprise, SP 1303, offrent un contexte pour articuler gouvernance cyber et objectifs de l’organisation. Les limites chiffrées restent propres à l’entité. Une méthode comme EBIOS Risk Manager aide à analyser des scénarios; elle ne remplace pas le jugement de la direction sur les conséquences qu’elle est prête à supporter.

Partir des résultats métiers, pas d’un score isolé

Demandez à la direction quels résultats doivent être préservés: capacité à fournir un service, sécurité des personnes, confidentialité d’informations, exactitude d’une décision, respect d’engagements ou continuité de revenus. Décrivez ces résultats en termes compréhensibles par les responsables métiers. Un score technique « 4 sur 5 » ne dit pas si une panne de ce service est acceptable pendant une heure, un jour ou pas du tout au moment considéré.

Définissez pour chaque résultat un périmètre. La continuité d’un service de paiement en production n’est pas la même chose que celle d’un environnement de formation. Indiquez les clients ou opérations concernés, la période sensible, les interdépendances et la capacité de reprise. L’appétence peut varier selon les services et les conséquences; une affirmation unique pour toute l’entreprise est souvent trop vague pour arbitrer.

La PSSI exprime les règles générales de sécurité. Le cahier d’appétence indique où la direction place la limite de décision et comment traiter un cas qui la dépasse.

Distinguer appétence, tolérance et limite d’alerte

L’appétence décrit le type et le niveau de risque que l’organisation accepte de prendre pour atteindre ses objectifs. Une tolérance précise l’écart admissible autour d’un objectif donné; une limite d’alerte signale que l’on approche d’une zone nécessitant une décision. Les termes sont parfois utilisés différemment selon les référentiels internes: définissez-les dans le document pour éviter que deux équipes interprètent le même seuil de manière opposée.

Par exemple, la direction peut vouloir éviter toute interruption longue d’un service essentiel tout en tolérant une maintenance courte et planifiée. Un seuil d’alerte peut être déclenché avant que l’interruption atteigne la limite maximale envisagée. La question n’est pas de trouver un chiffre « certifié », mais de choisir une règle cohérente avec le service, les engagements et la capacité de réponse. Ne confondez pas une limite interne avec une obligation légale ni avec une garantie de disponibilité.

Évitez les seuils construits seulement autour d’une probabilité estimée. Les probabilités cyber sont souvent difficiles à mesurer précisément. Une décision peut combiner des conséquences plausibles, une exposition observée et des conditions de maîtrise. Le cahier doit exposer les incertitudes qui comptent, plutôt que leur donner une apparence de précision avec deux décimales.

Rédiger un cahier de décision

Une ligne du cahier associe un résultat métier, un scénario, un seuil, une mesure observable, un propriétaire et une condition d’escalade:

Champ Exemple fictif à adapter
Résultat Répondre aux demandes urgentes sur le portail client pendant les heures de service
Scénario Perte d’accès à la plateforme d’identité
Signal d’alerte Interruption continue de 30 minutes, ou essai de bascule dépassant 60 minutes
Limite de tolérance Au plus 2 heures d’interruption continue en heures de service dans ce scénario
Décideur Direction du service active le mode dégradé à 30 minutes; au-delà de 2 heures, décision explicite de la direction désignée avec sécurité et continuité
Dépassement Mesure temporaire, responsable, date de réduction et acceptation limitée dans le temps
Révision Changement d’architecture, incident, échec de bascule ou nouvel engagement client

Les 30 minutes, 60 minutes et 2 heures sont des valeurs fictives propres à cette organisation imaginaire, pas des exigences universelles ni une promesse contractuelle. La ligne est formulée en termes de résultat. La preuve peut ensuite porter sur un test de bascule, une dépendance ou un délai réel de remise en service. Un seuil non mesurable ne permet pas d’identifier son franchissement. À l’inverse, une mesure purement technique sans conséquence métier n’aide pas la direction à choisir.

Conservez la version du cahier, la date, les participants et le périmètre approuvé. Une phrase prononcée en réunion ne constitue pas une délégation permanente à tous les chefs de projet. Indiquez qui peut accepter une exception et pour combien de temps. Les données sensibles sur les vulnérabilités ou les dépendances peuvent être référencées dans des pièces à accès limité.

Faire approuver des arbitrages réalistes

Présentez à la direction deux ou trois scénarios opposés. Un contrôle peut coûter cher et réduire un risque de faible conséquence; un autre peut être peu coûteux mais retarder une activité commerciale. La direction doit savoir ce qu’elle gagne et ce qu’elle risque dans chaque option. Une formulation utile est: « Si le service A est indisponible pendant une période donnée, voici l’effet métier; voici les contrôles et leur coût; voici l’exposition restante. » La décision porte alors sur un arbitrage concret.

Demandez aussi ce qui n’est pas délégué. Certaines conséquences exigent une escalade immédiate, même si un chef de service souhaite accepter le risque pour tenir un calendrier. Cela peut concerner la sécurité des personnes, une obligation réglementaire particulière ou un niveau de perte dépassant sa délégation. Documentez les délégations avec les instances compétentes; ce guide ne fixe pas un organe de direction universel pour toutes les structures.

Le guide d’homologation de sécurité éclaire une décision formelle d’acceptation dans les contextes auxquels cette démarche s’applique. L’appétence organisationnelle reste distincte de l’homologation d’un système particulier.

Traduire la décision dans les dossiers de risque

Chaque scénario de risque devrait pouvoir pointer vers une limite du cahier. S’il reste en deçà, indiquez pourquoi et quelle surveillance confirme les hypothèses. S’il la dépasse, proposez une réduction, un transfert, un changement d’activité ou une décision d’acceptation au bon niveau. « Risque accepté » sans référence au résultat métier, au seuil et à la durée est trop faible pour expliquer l’arbitrage.

Prenons un accès administrateur partagé sur un outil essentiel. Le dossier ne se contente pas d’une note de gravité; il décrit ce qu’une utilisation abusive pourrait interrompre ou modifier, les traces disponibles et l’effet d’une suppression de ce partage. Si la correction demande une migration, un contrôle temporaire et une date sont définis. Le franchissement du seuil d’appétence déclenche l’escalade prévue. Une acceptation temporaire ne transforme pas le contrôle provisoire en solution définitive.

Pour lier plusieurs risques de manière cohérente, le guide EBIOS Risk Manager peut fournir une analyse structurée. Le cahier de décision n’a toutefois pas besoin de reproduire toute l’étude de risques: il indique comment la direction utilisera ses conclusions.

Exemple: une dépendance de sous-traitance

Une organisation fictive dépend d’un fournisseur SaaS pour traiter des demandes clients. La direction a défini comme résultat prioritaire la capacité à répondre aux demandes urgentes même en cas d’indisponibilité du fournisseur. Un exercice mesure 2 heures et 15 minutes avant que l’équipe puisse rétablir un accès exploitable. L’alerte interne se déclenche à 30 minutes et l’essai de bascule échoue à son objectif de 60 minutes; la durée observée franchit aussi la tolérance fictive de 2 heures. Le risque dépasse donc la limite approuvée, bien que le fournisseur annonce une bonne disponibilité historique.

Le responsable du service présente trois options: tester et améliorer une procédure de continuité, réduire la dépendance en maintenant une capacité interne limitée, ou accepter explicitement une interruption plus longue pendant une période donnée. Le cahier identifie qui décide et à quelle date l’acceptation sera revue. Les critères de décision comprennent la qualité de l’export, le délai mesuré de reprise, le coût et les effets sur les clients. La direction peut choisir une combinaison, mais le procès-verbal doit montrer ce qu’elle a accepté.

Ce cas illustre pourquoi un pourcentage annuel de disponibilité ne suffit pas. Deux heures d’indisponibilité au moment d’une échéance critique peuvent avoir plus d’effet que plusieurs interruptions courtes en période calme. Le seuil doit être lié au résultat métier que la direction entend protéger. La politique de sécurité des fournisseurs peut ensuite traduire certaines exigences en échanges contractuels.

Prévoir les conditions d’escalade

Une escalade ne doit pas attendre qu’un indicateur dépasse définitivement la limite. Définissez des déclencheurs anticipés: dégradation d’un contrôle essentiel, exception prolongée, incident chez un fournisseur, découverte d’une dépendance non cartographiée ou résultat de test inférieur à l’objectif. Associez chacun à une personne qui rassemble les faits, un décideur et une fenêtre de réponse. Ces fenêtres sont internes et dépendantes du contexte; n’inventez pas un délai réglementaire commun à tous les risques cyber.

Un risque peut être accepté sous conditions. Précisez les mesures à maintenir, l’échéance, la surveillance et les événements qui rendent la décision caduque. Si une mesure compensatoire échoue, la décision doit remonter sans attendre sa date de revue planifiée. L’absence d’alerte n’est pas une preuve que le seuil est respecté lorsque la mesure n’est pas alimentée par des données fiables.

Les preuves d’audit devenues périmées montrent l’importance de cette dimension temporelle. Une décision de risque fondée sur une architecture ancienne ou un test de reprise dépassé ne devrait pas rester valable par inertie.

Mesurer sans réduire la décision à une couleur

Un tableau de bord peut signaler les limites franchies, les exceptions proches de l’expiration et les mesures correctives retardées. Il doit aussi indiquer la qualité des données: couverture du périmètre, date de la dernière mesure, propriétaire et hypothèses. Un feu vert fondé sur une mesure indisponible est trompeur. Affichez « non déterminé » lorsque les preuves ne permettent pas de conclure, et donnez à cet état un responsable.

Comparez les décisions et les résultats. Plusieurs acceptations temporaires prorogées peuvent montrer que les seuils sont irréalistes ou que les moyens de réduction manquent. Plusieurs incidents sous le seuil formel peuvent montrer que le résultat métier a été mal défini. Ne modifiez pas discrètement les chiffres pour améliorer le tableau; soumettez une proposition de révision de l’appétence avec ses conséquences.

La démonstration d’un outil de gestion des risques cyber peut donner des idées sur les données à demander à un outil. Le cahier et les décisions de direction restent nécessaires quelle que soit l’application utilisée; aucune fonction produit particulière n’est supposée ici.

Déclencher une révision lorsque le contexte change

Planifiez une révision périodique, mais ajoutez des événements qui l’avancent: acquisition, nouveau marché, changement d’obligation, incident sérieux, dépendance technique majeure, évolution des attentes clients ou échec d’un test de continuité. Pour chaque déclencheur, indiquez ce qui doit être repris: périmètre, conséquence métier, seuil, délégation ou mesure. Un changement d’infrastructure ne demande pas toujours une nouvelle déclaration complète; il peut rendre caduc un seul seuil.

Conservez l’historique. Une acceptation de risque conforme à l’ancienne limite peut devenir hors limite après une nouvelle décision, ou l’inverse. Le dossier doit montrer la règle en vigueur à la date de l’arbitrage et les actions ouvertes lors de la révision. Cela permet d’apprendre des décisions passées sans réécrire rétrospectivement leur justification.

Le cahier final doit permettre à un responsable de répondre: quel résultat métier est en jeu, quelle limite la direction a approuvée, comment le franchissement se constate, qui peut accepter un écart et quels faits imposent un nouvel examen. C’est cette chaîne, et non l’expression « faible appétence », qui permet de décider face à un risque cyber concret.

Éprouver les seuils sur des décisions passées

Avant publication, reprenez quelques arbitrages réels déjà clos et appliquez le cahier tel qu’il est rédigé. Une dérogation d’accès accordée pendant un lancement, une panne de fournisseur et un investissement de sécurité différé peuvent servir d’exemples. Demandez si le seuil aurait déclenché une escalade, qui aurait reçu la décision et quelle information aurait manqué. Si le cahier produit toujours une escalade vers la direction générale, les délégations sont peut-être insuffisantes; s’il ne la déclenche jamais pour des cas graves, le résultat métier ou le signal précoce est mal formulé.

Ne réécrivez pas le passé pour donner raison au nouveau modèle. Identifiez plutôt les différences: le service était-il moins important, les données moins fiables ou la capacité de reprise inconnue ? Un seuil utile peut conduire à un choix différent de celui fait antérieurement, à condition que la direction comprenne pourquoi. Cette mise à l’épreuve révèle aussi les indicateurs indisponibles. Il vaut mieux choisir un signal observable, même imparfait et explicitement limité, qu’une mesure élégante que personne ne collecte.

Faites lire une même ligne du cahier à un responsable métier, un exploitant et un membre de la direction. Chacun doit savoir quel événement impose une action et à qui transmettre le dossier. Si leurs interprétations divergent, ajoutez un exemple ou redéfinissez le terme litigieux. Une appétence au risque ne sert pas seulement à communiquer la philosophie de l’organisation; elle doit être assez précise pour guider le choix suivant sous pression, tout en laissant une place documentée au jugement.

L
Rédigé par
Legiscope
Legiscope

Mettez ces conseils en pratique

Découvrez comment Legiscope relie les registres de confidentialité, les sources et les travaux soumis à validation.

Réserver une démo personnalisée
Poursuivre la lecture

Articles liés

01Cybersécurité et GRC

Délais de correction des vulnérabilités : bâtir une matrice de priorité

Fixer le même délai de correction à toutes les vulnérabilités dites « critiques » paraît simple, mais laisse de côté des questions décisives : l'actif est-il exposé, l'exploitation est-elle…

1 octobre 2026
02Cybersécurité et GRC

Migration vers un logiciel GRC : définir les critères de reprise des données

Une migration GRC peut afficher le bon nombre de risques et perdre pourtant ce qui rend les dossiers utilisables: leurs identifiants, les liens vers les contrôles, les propriétaires ou l'historique…

1 octobre 2026
03Cybersécurité et GRC

Sortie d'un fournisseur SaaS : faire accepter l'export des données

Recevoir un fichier compressé du fournisseur ne suffit pas à prouver qu'une sortie SaaS est possible. Il faut savoir si toutes les données et relations attendues sont présentes, si le format permet…

1 octobre 2026
04RGPD

Accountability RGPD : démontrer une conformité qui fonctionne

L'« accountability » désigne la responsabilité du responsable de traitement de respecter les principes du RGPD et d'être en mesure de montrer comment il les respecte. L'article 5, paragraphe 2, du…

12 avril 2026
05Données personnelles

Adresse IP donnée personnelle : jurisprudence CJUE et RGPD

L'adresse IP est-elle une donnée personnelle au sens du RGPD ? La question a été tranchée par la Cour de justice de l'Union européenne dans l'arrêt Breyer c/ Bundesrepublik Deutschland (C-582/14, 19…

12 avril 2026
06Personal Data

AI Act : Guide Complet sur le Règlement Européen sur l'Intelligence Artificielle

L'AI Act de l'Union Européenne transforme radicalement le paysage de l'intelligence artificielle en établissant des normes strictes pour le développement et l'utilisation des systèmes d'IA. Ce…

9 décembre 2024
07Données personnelles

Alternatives à OneTrust : cinq pistes à comparer

Chercher une alternative à OneTrust ne revient pas à chercher le même catalogue de modules avec un autre logo. Il faut d'abord savoir ce que l'organisation utilise réellement : registre des…

6 juillet 2026
08Données personnelles

Analyse d'impact RGPD (AIPD) : méthodologie et exemples

L'analyse d'impact RGPD (AIPD ou DPIA en anglais) est l'une des obligations les plus structurantes du RGPD. L'Art. 35 impose au responsable de traitement de réaliser cette analyse avant tout…

12 avril 2026