Match 27001 versus RSSI : 1 à 0

J’appelle un ami – un confrère – et lui pose la question suivante : « Brad, dis-moi un truc, comment fait-on quand on pilote un SMSI pour dire à l’organisation que, en gros, ils travaillent comme des gorets-gougnafiers, qu’ils vont se vautrer grave à la prochaine visite de certification et que ce sera bien fait pour leur groin ? »

Là, Brad me rétorque qu’il ne faut pas parler comme ça et qu’il vaut mieux être un minimum diplomate dans ce genre de situation. Bon, je reformule : comment dire à l’organisation que de graves dysfonctionnements dans leurs processus de travail mettent potentiellement en jeu le fonctionnement même du SMSI et que la perte de la certification les guette. Et que ce sera bien fait pour leur groin.

Si vous allez décortiquer le chapitre 9.3 de la norme sur la revue de direction (seul point de contact institutionnalisé entre le RSSI et l’organisation), nulle mention de cette possibilité. Certes le 9.3.1 (Généralités) est assez vague et on peut y coller pas mal d’items, mais dans le 9.3.2, nada, bernique et peau de balle. En plus d’appeler Brad, j’ai aussi appelé Georges (qui m’a donné peu ou prou la même réponse), et la solution n’est pas si triviale. En fait, il y a trois solutions, par ordre croissant de pertinence.

Solution 1 : le 9.3 décrit le minimum syndical de ce que doit comprendre une revue de direction, rien n’empêche d’y apporter des éléments additionnels, tels que le point objet du présent filet. Mouais, ça marche, mais je n’aime pas trop : intervenir sur le code source pour faire un fork, j’ai donné dans ma précédente vie de développeur, on finit par se le prendre dans la face un jour ou l’autre.

Solution 2 : utiliser l’audit interne, et faire remonter ce point pour qu’il apparaisse dans le rapport d’audit interne, qui sera (comme c’est pratique) un entrant de la revue de direction. J’aime mieux : les points de passage obligés de l’audit interne peuvent intégrer cet élément sans difficulté (9.2.1.b et 9.2.2.a pour les intimes, je vous laisse vérifier).

Solution 3 (que je pensais inadéquate au départ, mais qui au final est la meilleure, et qui implique un léger changement de paradigme, vous allez voir) : la revue de direction impose d’examiner le retour des parties intéressées (PI). Or, ma remarque de départ (vous bossez comme des tanches) est celle d’un RSSI : il suffit donc de considérer le RSSI comme une PI. Conséquence directe : la séparation entre le RSSI (responsable sécurité du système d’information) et le RSMSI (le responsable du fonctionnement du SMSI), et le fait que le RSMSI comptabilise le RSSI dans la liste des PI.

Alors je sais, je sais, vous allez me sortir les arguments habituels : on coupe les cheveux en quinze, on a déjà du mal à avoir un RSSI, si en plus il faut un RSMSI, qui par-dessus le marché est souvent la même personne, et blablabla et blablabla. Mais là n’est pas le plus important. Le plus important, c’est que :

– les rôles RSSI/RSMSI sont bien distincts ; la 27001 le découvre juste, la 9001 le sait depuis des lustres ;

– un SMSI, ce n’est pas de la cyber, c’est un système de management, la distinction des deux rôles le démontre bien ;

– un argument de plus (s’il en fallait encore un) pour bien dire que le RSSI ne peut pas être dans la DSI (sinon il ne pourrait pas être une PI à lui tout seul).

Mais ce qui m’a le plus impressionné dans cette réflexion, c’est la souplesse et la solidité de la norme : incroyable qu’un document aussi court (11 pages hors annexes) puisse à la fois faire face aux situations les plus simples comme les plus complexes. Normal, il ne faut tout de même pas oublier qu’il est le résultat de milliers d’heures de jus de cerveau, depuis plus de 20 ans, par des centaines de personnes. On ne va tout de même pas le prendre en défaut aussi facilement.

De rien.

 (1) Oui, je sais, cela ne veut rien dire, c’est juste pour faire genre.