Comment réaliser une PSSI (Politique de Sécurité des Systèmes d'Information) ?

L'ANSSI définit la Politique de Sécurité des Systèmes d'Information comme le document qui formalise, au niveau de la direction, les règles, les responsabilités et les mesures de sécurité applicables au système d'information. Son guide PSSI insiste sur un point souvent négligé : une politique n'a de valeur que si elle reflète une réalité observée. Une PSSI recopiée d'un modèle générique, sans état des lieux préalable, ne résiste ni à un audit ni à un incident réel.

Qu'est-ce qu'une PSSI, concrètement ?

Une PSSI n'est pas un document technique isolé. C'est l'expression, au niveau de la direction, des exigences de sécurité que l'organisation s'impose, ensuite déclinées en procédures opérationnelles : gestion des accès, sauvegardes, réponse aux incidents. Elle sert de référence commune aux équipes internes, aux prestataires et, le cas échéant, aux auditeurs ou aux assureurs cyber, qui demandent de plus en plus souvent à la consulter avant de couvrir un sinistre.

Les étapes pour rédiger une PSSI

1. Réaliser un état des lieux factuel de l'existant : infrastructure, gestion des accès, sauvegardes, supervision, incidents passés.
2. Identifier les actifs critiques (données, applications, infrastructures) et les risques associés à chacun.
3. Définir les règles et objectifs de sécurité par domaine, en cohérence avec les risques identifiés : aucune règle ne devrait être fixée sans justification opérationnelle.
4. Attribuer les responsabilités (qui décide, qui applique, qui contrôle) et faire valider la politique par la direction.
5. Décliner la PSSI en procédures opérationnelles et en indicateurs de suivi.
6. Réviser la PSSI à intervalle régulier et après tout changement significatif (nouvel outil, incident, croissance des effectifs).

Les domaines qu'une PSSI doit couvrir

Ce que vérifient concrètement les auditeurs et les assureurs cyber

De plus en plus d'assureurs cyber demandent à consulter la PSSI, ou à défaut un questionnaire détaillé qui en reprend le contenu, avant d'émettre une police ou de couvrir un sinistre. Dans les deux cas, ce qui est vérifié n'est jamais la forme du document mais la cohérence entre ce qu'il affirme et ce qui est réellement en place : un auditeur ISO 27001 demandera systématiquement des preuves (extraits de journaux, tickets de revue d'accès, comptes rendus de comité sécurité), pas seulement une politique signée. Une PSSI qui affirme une revue trimestrielle des accès sans qu'aucune trace de revue n'existe est un signal d'alerte immédiat, souvent plus pénalisant qu'une politique plus modeste mais intégralement respectée.

Relier la PSSI à ISO 27001 et à NIS2

La PSSI n'est pas un exercice isolé : elle constitue la pierre angulaire du système de management de la sécurité de l'information (SMSI) requis par ISO 27001, et recoupe largement les dix domaines de mesures minimales imposés par la directive européenne NIS2 (gestion des risques, gestion des incidents, continuité d'activité, sécurité de la chaîne d'approvisionnement, entre autres). Une entreprise qui rédige sa PSSI en gardant ces deux référentiels en tête évite de devoir la refondre entièrement si elle vise une certification ou entre dans le périmètre NIS2 par la suite.

Bonnes pratiques pour une PSSI vivante

• Limiter la première version à ce qui est réellement applicable sous 90 jours, plutôt que viser l'exhaustivité dès le départ.
• Associer un indicateur mesurable à chaque règle importante (taux de couverture MFA, délai moyen de révocation d'un accès) pour objectiver son application.
• Prévoir une revue annuelle formelle, en plus des révisions déclenchées par un changement significatif.
• Diffuser une version accessible aux équipes non techniques, en complément de la version complète destinée aux auditeurs.

Erreurs fréquentes à éviter

• Rédiger la PSSI sans état des lieux préalable, en copiant un modèle trouvé en ligne.
• Fixer des règles trop strictes pour être réellement appliquées au quotidien.
• Ne jamais réviser la PSSI après sa première publication.
• Ne pas associer les équipes opérationnelles à sa rédaction, ce qui produit un document théorique déconnecté du terrain.
• Affirmer des contrôles dans le document sans conserver la moindre preuve de leur application réelle.

Une PSSI, aussi bien rédigée soit-elle, ne protège en elle-même de rien : elle fixe un cadre, pas un blindage. Sa valeur se mesure à la constance avec laquelle elle est appliquée et révisée, bien plus qu'à la qualité littéraire du document. Un état des lieux mené domaine par domaine, preuves à l'appui, reste la meilleure base de départ pour en rédiger une version réaliste et opposable, plutôt qu'un exercice de style qui ne survivra pas au premier incident.