Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

Adapter la gestion des risques aux décideurs

Adapter la gestion des risques aux décideurs
2013-04-022013-04-02bonnes pratiquesfr
L’une des grandes difficultés rencontrées par les DSI et les RSSI dans la gestion des risques est d’obtenir des budgets pour réduire les risques à un niveau acceptable. Je vous livre ma méthode personnelle...
Publié le 2 Avril 2013 par Johny Gasser dans bonnes pratiques
business man

De mon expérience personnelle, l’une des grandes difficultés rencontrées par les DSI et les RSSI dans la gestion des risques n’est pas d’identifier les risques ou de les évaluer, mais bel et bien d’obtenir des budgets pour réduire les risques à un niveau acceptable, en particulier en période de pression budgétaire accrue. Mais que faire lorsque les dirigeants ne comprennent pas les risques ? Je vous livre ma méthode.

la réaction type du dirigeant face à un risque IT élevé

Quelle serait la réaction naturelle et prévisible d’un directeur si je l’informe qu’il a un score de risque de 92 sur un maximum de 100 pour un serveur ou une application et que les conséquences peuvent lui coûter très cher, des millions peut-être ?

  1. Externaliser les activités liées. Après tout, pourquoi prendre un risque pour l’entreprise et pour son bonus ou sa place de travail ? Si cela est externalisé, il n’a pas plus de souci, et si le risque se réalise, c’est la faute d’un autre.
  2. Attendre que quelque chose de fâcheux se produise, si cela devait réellement se produire un jour. Cela lui permettra de vérifier si vos prédictions sont crédibles, ou pas. Et si le risque se réalise, il sera toujours temps d’investir. Pendant ce temps-là, on a une meilleure marge et lui un meilleur bonus. Il pourra même se sentir conforté dans sa décision en se disant que « si c’était vrai, ça se saurait ou cela se serait déjà produit ou un concurrent l’aurait déjà subi ». C’est cynique, mais c’est un modèle de décision (trop) courant.

mais que faire pour qu’ils comprennent ?

Il est important de comprendre les motivations et les critères de décisions des dirigeants pour les convaincre. En étant très pragmatique, on peut dire que les dirigeants, de manière générale, comprennent deux éléments: les résultats financiers et les processus métiers qui leur permettent d’atteindre les objectifs de l’entreprise. Et définitivement pas les problèmes d’informatique.

Je pars du principe que vous savez gérer les risques purement technologiques comme la gestion des vulnérabilités techniques, avec votre budget de DSI ou RSSI.

Viser à pouvoir quantifier chaque risque technologique ou liés à l'utilisation de technologies en termes financiers me parait bien hasardeux et surtout requiert une connaissance telle des rouages financiers que vous seriez probablement déjà directeur financier si vous l’aviez. Il me semble que ceux qui s'y sont essayé ont surtout perdu leur crédibilité aux yeux de leurs dirigeants, car leurs prédictions ne se sont pas souvent réalisées, ou du moins elles n’ont pas été révélées.

ma méthode

Mon but est donc de lier les risques "IT" à des processus métiers. Les dirigeants comprendront les conséquences et détermineront très rapidement si un risque est acceptable ou pas, et combien ils sont prêts à dépenser pour réduire le risque à un niveau acceptable.

Je n'aime pas réinventer la roue... Je préfère utiliser l'expérience des autres. Dans ce contexte, la question était « qui est efficace dans la diminution effective des risques depuis des décennies? ». La réponse m'est venue tout naturellement: le travail en usine, le travail à la chaine, les chaines de montage. Ils ont des procédures efficaces pour réduire le nombre d'accidents de travail. Quelle est leur méthode? C’est FMEA pour [Failure Mode and Effects Analysis] pour la plupart. Je la résume: je regarde à chaque étape ce qui peut "mal tourner" et je trouve une solution.

Si on adapte cette solution à l'informatique, on suit un processus métier et à chaque étape on se pose les questions suivantes:

  1. quelles sont les ressources informatiques liées ?
  2. qu'est-ce qui pourrait mal se passer d'un point de vue confidentialité, intégrité, disponibilité ?

Je continue mon évaluation de risque comme j'ai toujours fait avec les conséquences prévisibles, leurs évaluations, l’estimation de la probabilité du scénario, etc.

Maintenant quand je présente les résultats, les dirigeants comprennent réellement les conséquences pour le métier et peuvent prendre une décision en toute connaissance de cause. C'est également ainsi que je peux identifier ce qu'un utilisateur peut faire comme erreur de manipulation et les conséquences liées. De même, on comprend plus facilement comment une fraude pourrait être commise. Ainsi, on peut améliorer les interfaces des applications développées, adapter la formation, identifier des contrôles supplémentaires, etc.

en conclusion

Il faut rendre les risques intelligibles aux dirigeants, à celui ou celle qui prendra la décision. Pour obtenir un budget lié à une exposition inacceptable à des risques, il ne suffit pas de donner un score de risque, mais s’assurer que la perception du risque et des conséquences par le décideur sont correctes. Il convient de lui présenter des éléments que non seulement il comprend, mais qu’il maîtrise.

Il faut adapter sa méthode et son langage au(x) décideur(s), et non pas aux standards de gouvernance informatique aussi bon soient-ils. Pour les risques informatique, avoir un lien direct avec les activités métiers est une méthode très efficace. N’hésitez pas à me demander pour avoir des exemples concrets.

Et vous, comment faites-vous pour obtenir du budget basé sur les risques identifiés?

Johny

crédit photo : © alphaspirit - Fotolia.com

2 Commentaires

  • 3 Avril 2013
    2013-04-03
    par
    Johny
    Christophe, c'était mon expérience également. C'est pourquoi j'ai changé de "tactique". Je ne fais plus du BIA "standard", je ne donne que la liste des processus métier qui seront stoppés ou affectés.
    Ensuite, les décideurs métiers (CxOs) viennent eux-mêmes demandant de l'aide et le budget qu'ils peuvent "entrer en matière".
    Comme j'ai reçu quelques demandes comment appliquer mon modèle "théorique" dans la pratique, je vais rédiger un post avec un exemple réel, il sera publié dans les jours qui viennent
  • 2 Avril 2013
    2013-04-03
    par
    Christophe GUILLOU
    Concernant la disponibilité, les mesures visant à assurer la continuité d'activité sont souvent négliglées car néccessitant un CAPEX et OPEX important. Le BIA (Bussiness Impact Analysis) permet d'évaluer l'impact métier et les côuts pour l'entreprise en cas de sinistre grave de l'IT. Malheureusement, force est de constater que bien souvent, l'allocation d'un budget (et la prise de conscience) est consécutif à un sinistre ayant impacté fortement l'entreprise.

Ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.
Changer d'affichage