La 27001 et les Parties intéressées

C'est exactement le cas du §4.2 : compréhension des besoins et des attentes des parties intéressées (PI). Le paragraphe est court — il ne comporte que 3 alinéas et 6 lignes — mais il est truffé de pièges et constitue à lui seul un quasi-SMSI en miniature. Essayons pour voir.

L'Organisation doit déterminer les PI concernées par le SMSI (4.2-a). À la première itération c'est facile (l'établissement, les pouvoirs publics, les agents, les partenaires, les usagers, les organismes de contrôle, je ne dois pas en avoir oublié beaucoup), sauf que l'année suivante il va falloir réviser tout cela. La Revue de Direction (RD) impose en 9.3.2-c la révision des enjeux des PI, pas celle de la liste des PI elle-même : premier piège. Bon, il n'est pas trop difficile d'introduire dans la RD un prérequis de révision de la liste des PI, et si vous tombez sur un auditeur chafouin qui vous demande COMMENT vous avez révisé cette liste (tordu, hein ?), il suffit de lui répondre « veille permanente », ça devrait passer (surtout si vous l'avez mentionné dans le Manuel du SMSI).

Cela se corse avec le 4.2-b : détermination des exigences pertinentes de ces PI. Tout le monde se focalise sur « exigences » alors que le piège est dans « pertinentes » : c'est bien beau de sortir une liste à la Prévert, comment s'assure-t-on que cette liste est « pertinente » pour les PI ? La 27001 n'impose aucune méthode (et c'est bien là le côté difficile), mais elle impose que l'Organisation en ait une. On peut interroger les PI (par exemple lors de réunions annuelles, en CODIR, etc.), collecter les besoins, se tenir au courant de l'actualité. C'est comme vous voulez, il faut juste le mentionner, si possible dans le Manuel du SMSI. Et ne pas oublier de revérifier cette liste lors de la RD annuelle.

Le 4.2-c est plus facile (lesquels de ces enjeux sont couverts par le SMSI ?), car il revient à délimiter un sous-ensemble de la liste précédente — encore faut-il, une fois de plus, décrire la méthode et réviser cette sous-liste tous les ans.

La note de fin du §4.2 précise que ces exigences peuvent (et non pas « doivent ») inclure le légal, le réglementaire et le contractuel — merci pour l'aide —, ce qui est un bon point d'entrée (et permet d'ailleurs de justifier les réponses des 3 alinéas) sans vous interdire d'aller plus loin.

À condition, bien entendu, de réviser tout cela, à la fois sur le fond (le résultat, les éléments et les listes produites, etc.) et sur la forme (la méthode utilisée).

Rien de tout cela n'est complexe : quand on a compris le truc, la révision de ces 3 alinéas prend très peu de temps, et le passage en RD du §4.2 se fait en 15 min chrono si tout le monde est aligné. Comme à son habitude, la 27001 donne très peu d'indications sur le « comment » ; elle exige juste que :

• le sujet soit traité ;
• la méthode soit formalisée ;
• résultats et méthode soient périodiquement revus.

On va me prendre pour un monomaniaque à invoquer le cambriolage du Louvre à toutes les sauces, mais l'une des causes racines (et certainement pas la seule) est l'absence de démarche à la sauce §4.2 de la 27001 : sinon, les exigences des 2 PI que sont l'État et les citoyens auraient permis de déterminer sans équivoque que l'une de leurs exigences, qui plus est pertinente, était de ne pas se faire chouraver les bijoux de la Couronne.

Et d'ailleurs, lors de la dernière réunion du club 27001 nantais, un des participants a évoqué, à titre d'exercice, le cas classique suivant : pour une entreprise qui fabrique des meubles, quel intérêt de se faire certifier 27001 ? Facile : comme pour le Louvre, il y a des PI (clients, commissaires aux comptes, comptable) qui ont tout intérêt à ce que les données du SI (leurs coordonnées, les identifiants admin en capacité de trafiquer la paie, etc.) soient un minimum sécurisées.