La politique de sécurité des systèmes d'information (PSSI) est le premier document demandé dans la plupart des situations de contrôle : audit de certification ISO 27001, questionnaire de sécurité d'un client, due diligence. C'est aussi le document le plus souvent produit de la mauvaise façon : un modèle générique téléchargé, complété avec le nom de l'entreprise, approuvé une fois puis oublié. Cet article décrit ce que les référentiels exigent réellement d'une politique de sécurité, ce qu'un auditeur y vérifie et pourquoi une PSSI doit partir de l'évaluation de l'organisation, pas d'un modèle.
Ce que les textes exigent
Selon le guide d'élaboration de PSSI de l'ANSSI (publié en mars 2004 par la DCSSI, prédécesseur de l'agence, et toujours la référence méthodologique française), une PSSI « reflète la vision stratégique de la direction de l'organisme en matière de sécurité des systèmes d'information ». Elle comprend des éléments stratégiques (enjeux, référentiel applicable, besoins de sécurité, menaces principales) et des règles de sécurité applicables. Deux points de méthode comptent pour une PME : le document engage la direction, pas le service informatique, et il découle d'une analyse préalable des enjeux et des risques.
La clause 5.2 d'ISO/IEC 27001:2022 formule la même exigence en termes auditables. La direction doit établir une politique de sécurité de l'information qui est appropriée à la mission de l'organisation, qui contient des objectifs de sécurité ou un cadre pour les définir, qui inclut l'engagement de satisfaire aux exigences applicables et l'engagement d'amélioration continue. La politique doit être disponible sous forme documentée, communiquée dans l'organisation et accessible aux parties intéressées lorsque c'est pertinent.
La mesure 5.1 d'ISO/IEC 27002:2022 complète le dispositif : la politique générale et les politiques thématiques (contrôle d'accès, sauvegarde, cryptographie, gestion des incidents, développement sécurisé, entre autres) doivent être définies, approuvées par la direction, publiées, communiquées au personnel concerné qui en accuse réception, et revues à intervalles planifiés ainsi qu'à chaque changement significatif.
Pourquoi le modèle générique ne passe pas l'audit
Le modèle Word générique produit un document qui satisfait la forme et contredit le fond. Les incohérences sont détectables à la lecture croisée, qui est précisément la méthode d'un auditeur. Une politique qui impose le chiffrement des postes de travail alors qu'aucun poste n'est chiffré crée une non-conformité que l'organisation s'est infligée elle-même : l'écart n'est pas mesuré par rapport à la norme, mais par rapport à ce que l'organisation a déclaré faire. Une politique qui mentionne un « comité de sécurité trimestriel » sans compte rendu, un rôle de RSSI que personne ne tient, ou des outils que l'entreprise n'utilise pas produit le même effet.
Le second problème du modèle est l'absence de lien avec les risques. Dans la logique d'ISO 27001, la politique s'articule avec l'appréciation des risques (clause 6.1.2) et la déclaration d'applicabilité : les mesures que la politique impose doivent correspondre aux risques identifiés dans le registre des risques et aux mesures retenues dans la SoA. Un document rédigé avant toute évaluation ne peut pas présenter cette cohérence.
Ce qu'un auditeur vérifie concrètement
Les exigences citées plus haut se traduisent en points de contrôle. Le document est-il approuvé, daté et signé par la direction, avec une version identifiée ? Le périmètre décrit correspond-il à l'organisation réelle (entités, sites, systèmes) ? Les engagements de la politique se retrouvent-ils dans les faits : si elle annonce une revue annuelle, existe-t-il une trace de la dernière revue ; si elle annonce une sensibilisation du personnel, existe-t-il des preuves de diffusion et d'accusé de réception ? Les politiques thématiques couvrent-elles les domaines pertinents pour l'activité, et uniquement ceux-là ? Enfin, la politique est-elle cohérente avec l'appréciation des risques et la déclaration d'applicabilité, ou décrit-elle une organisation qui n'existe pas ?
Aucun de ces points ne porte sur la longueur ou l'élégance du document. Un auditeur ne cherche pas une PSSI de quarante pages ; il cherche un document court, exact, approuvé, diffusé, revu et raccordé au reste du système de management.
Une PSSI proportionnée pour une PME
Pour une structure de vingt à deux cents personnes, une PSSI utilisable tient en quelques pages : les enjeux et le périmètre, les responsabilités (direction, référent sécurité, utilisateurs), les engagements exigés par la clause 5.2, et le renvoi vers les politiques thématiques. Celles-ci ne couvrent que les domaines où l'entreprise a des pratiques réelles à encadrer. Une PME sans développement logiciel n'a pas besoin d'une politique de développement sécurisé ; en écrire une affaiblit le dispositif au lieu de le renforcer.
L'ordre des opérations découle de ce qui précède : évaluer d'abord (périmètre, risques, état des mesures), écrire ensuite. La politique formalise ce que l'évaluation a établi, en fixant les règles que l'organisation est en mesure de tenir et les cibles d'amélioration assumées comme telles. Ce séquencement est celui du guide ANSSI comme celui d'ISO 27001, où la politique (clause 5.2) s'appuie sur le contexte (clause 4) et alimente le traitement des risques (clause 6).
Générer la politique depuis l'évaluation
C'est le fonctionnement de Komplyo : la PSSI et les politiques associées sont générées à partir des réponses de l'évaluation, pas d'un modèle statique. Les règles reprennent les mesures effectivement en place, les écarts identifiés deviennent des cibles datées dans la feuille de route, et chaque mesure porte ses correspondances CSF, ISO 27001, SOC 2 et RGPD issues de la table de mappings. Le document produit décrit l'organisation telle qu'elle est, ce qui est exactement ce qu'un auditeur vérifie. Le diagnostic gratuit (23 questions, environ 5 minutes) donne un premier état des pratiques sur lequel ce travail s'appuie.