PSSI : structure, exemple de politique de sécurité et ce qu'un auditeur
y cherche

L'auditrice s'installe à 9 h 30. Avant le café, une seule demande : "Vous pouvez me transmettre votre PSSI ?" Vous dites oui, bien sûr, et vous ouvrez le SharePoint. Dossier Sécurité, sous-dossier Politiques. Il y a un PSSI_v0.9_DRAFT.docx de 2021, 74 pages, avec les commentaires du consultant encore dans la marge, et un PDF signé de 2019 qui décrit en détail la sauvegarde d'un ERP décommissionné depuis deux ans. L'auteur des deux documents a quitté l'entreprise. Vous envoyez le PDF. L'auditrice le feuillette, va directement au chapitre "Gestion des vulnérabilités", lit "les systèmes exposés font l'objet d'un scan mensuel", et demande le dernier rapport de scan. Ce sera la question de la journée.

La PSSI, politique de sécurité des systèmes d'information, est le document que tout le monde cite et que peu de gens ont lu jusqu'au bout. Le PDF de 2019 était pourtant très bien écrit. Ce qui lui manquait tenait ailleurs : un propriétaire, une revue, et un artefact daté derrière chacune de ses phrases. Il n'y aura donc pas de modèle à télécharger ici, parce qu'une PSSI recopiée rejoue la scène du paragraphe précédent, en plus récent.

PSSI : définition, et la place du document dans la gouvernance

La définition française de référence date de 2004. Le guide pour l'élaboration d'une politique de sécurité de système d'information de la DCSSI, l'ancêtre de l'ANSSI, la décrit comme l'"ensemble formalisé des éléments stratégiques, des directives, procédures, codes de conduite, règles organisationnelles et techniques, ayant pour objectif la protection du (des) système(s) d'information de l'organisme". Cette définition est large à dessein : en 2004, la PSSI était conçue comme tout le corpus. Vingt ans plus tard, l'usage a resserré le mot sur le document de tête, et c'est cette acception qu'on retient ici, parce que c'est celle que les référentiels récents emploient.

Le corpus se lit donc en quatre étages, et la confusion entre eux explique la plupart des PSSI illisibles. La politique dit pourquoi et qui : le périmètre, les enjeux, l'organisation, les principes, l'engagement de la direction. Elle est signée par le dirigeant et tient en une vingtaine de pages. Les politiques thématiques, qu'on appelle aussi directives, disent quoi, domaine par domaine : authentification, chiffrement, contrôle d'accès, gestion des vulnérabilités, sauvegarde. Elles sont portées par le RSSI et changent plus souvent. Les procédures disent comment, poste par poste, et appartiennent aux équipes qui les exécutent. Les preuves, enfin, sont ce que ces procédures produisent quand elles tournent : un rapport daté, un ticket, un compte rendu, un journal. La charte informatique est à part : c'est la déclinaison de la politique vers les utilisateurs, opposable aux salariés lorsqu'elle est intégrée au règlement intérieur selon la procédure du Code du travail, et elle ne remplace aucun des quatre étages.

Cette hiérarchie dit si le document a une chance d'être vivant. Une PSSI qui contient la longueur minimale des mots de passe sera obsolète au premier changement d'annuaire, et personne ne fera resigner le directeur général pour passer de 12 à 14 caractères. Le détail descend d'un étage, ou il fige tout le reste. Pour situer la PSSI parmi les autres briques de pilotage, le pilier sur la GRC en cybersécurité replace le document dans l'ensemble gouvernance, risques, conformité.

Qui signe, qui porte, qui relit : la PSSI est un acte de direction

Une PSSI signée par le RSSI n'engage que le RSSI. Le texte européen est explicite sur ce point. L'article 20 de la directive (UE) 2022/2555 impose que les organes de direction des entités essentielles et importantes "approuvent les mesures de gestion des risques en matière de cybersécurité", "supervisent sa mise en œuvre" et "puissent être tenus responsables" des manquements de l'entité à l'article 21. Le ReCyF de l'ANSSI enfonce le clou en français courant : la mesure 2.A.1 rend le dirigeant exécutif responsable de la sécurité numérique de son entité, et la mesure 2.B.3 précise que c'est lui qui approuve la PSSI. Pas le comité, pas la DSI. Lui.

Nommez les rôles dans la PSSI elle-même, faute de quoi personne ne saura à qui s'adresser un an plus tard. Le signataire est le dirigeant : sa signature transforme une recommandation en règle interne. Le propriétaire répond du contenu et de la mise à jour, en général le RSSI, ou la personne qui en tient lieu dans une structure sans RSSI dédié. Les contributeurs sont les responsables de domaine qui rédigent les politiques thématiques : infrastructure, développement, juridique, RH. Quand le propriétaire part et que personne ne reprend le rôle, le document meurt en silence. C'est ce qui est arrivé au PDF de 2019 de l'introduction, et c'est le cas le plus fréquent.

La relecture obéit à la même logique. Le ReCyF demande (mesure 2.B.4) que la PSSI soit "au minimum revue annuellement et mise à jour lorsque nécessaire", en particulier après une évolution majeure de la menace ou du contexte métier, technique ou organisationnel. Une revue qui ne laisse pas de trace n'a pas eu lieu : le minimum est une ligne dans l'historique des versions, avec la date, l'auteur et la nature du changement, même si la conclusion est "aucune modification".

Exemple de plan de PSSI, section par section

Le plan ci-dessous n'est pas un modèle à remplir. C'est la structure qu'on retrouve, à quelques intitulés près, dans les PSSI qui tiennent devant un contrôle, avec pour chaque section ce qu'on y écrit, une longueur cible, et le document ou la preuve qu'elle doit rattacher. La colonne de droite est la plus importante : une section sans rattachement est une section que l'auditeur ne pourra pas vérifier.

Ce plan descend en droite ligne de celui que proposait la DCSSI. Le plan-type du guide de 2004 avait deux parties : une partie I "Éléments stratégiques" en six chapitres (périmètre, enjeux et orientations, aspects légaux et réglementaires, échelle de besoins, besoins de sécurité, origines des menaces) et une partie II "Règles de sécurité" classées par thème. La différence avec la pratique d'aujourd'hui tient dans cette partie II : on ne met plus les règles dans la politique, on y met les principes, et les règles descendent dans des politiques thématiques qui ont chacune leur propriétaire et leur rythme. Sinon on obtient les 74 pages du brouillon de l'introduction.

Ce qu'on ne met pas dans la PSSI

Tout ce qui a une valeur numérique ou un nom d'outil. La durée de conservation des journaux, le délai de correction d'une vulnérabilité critique, les algorithmes autorisés, le nom du scanner ou de l'EDR changent au rythme des contrats et des attaques, pas au rythme des signatures de direction. La PSSI dit "les vulnérabilités des systèmes exposés sont identifiées en continu et corrigées dans des délais fonction de leur criticité" ; la politique de gestion des vulnérabilités dit "scan hebdomadaire, correction sous 7 jours au-dessus de CVSS 9" ; la procédure dit quelle commande, quel ticket, quel retest.

Ce que NIS2, le ReCyF et ISO 27001 attendent d'une PSSI

Les trois cadres qu'un auditeur français aura sur la table ne disent pas la même chose, et il vaut mieux savoir lequel il applique avant de lui répondre.

Sur NIS2, l'exigence tient en une ligne du paragraphe 2 de l'article 21, le point (a), et elle est doublée par le point (f), qui réclame "des politiques et des procédures pour évaluer l'efficacité des mesures de gestion des risques". La conjonction des deux est ce qui fait la différence entre une politique et un tract : la directive n'impose pas seulement d'écrire des règles, elle impose d'écrire comment on vérifie qu'elles marchent. Le calendrier, les seuils et les sanctions sont détaillés dans le pilier sur la directive NIS2. Au moment de la rédaction (septembre 2026), la loi française de transposition, dite loi Résilience, a été adoptée par le Sénat le 12 mars 2025 et par la commission spéciale de l'Assemblée nationale le 10 septembre 2025, mais elle n'est pas promulguée à cette date, et l'état du dossier se revérifie avant de s'appuyer dessus (dossier législatif du Sénat). Les obligations précises viendront de ses décrets.

Le ReCyF, Référentiel Cyber France, est la traduction opérationnelle que l'ANSSI a mise en ligne le 17 mars 2026, en version de travail 2.5, dans l'attente de la loi. Il compte vingt objectifs de sécurité : les quinze premiers s'appliquent aux entités importantes comme aux essentielles, en réservant à l'intérieur certaines mesures aux seules essentielles, et les cinq derniers ne visent que les essentielles. L'objectif 2, "Mise en œuvre d'un cadre de gouvernance de la sécurité numérique", est celui qui parle de la PSSI, et il est plus précis que la directive. Le texte du référentiel liste ce que la PSSI comprend au minimum : l'organisation de la gouvernance avec les rôles du personnel interne et externe, les orientations stratégiques déclinées de la stratégie globale, l'engagement du dirigeant à assurer la sécurité des systèmes dont il est responsable et à respecter les exigences légales, et la prise en compte des spécificités du secteur. Il exige ensuite, en 2.B.5, au moins quatre politiques thématiques (chiffrement, contrôle d'accès physique et logique, revue de l'application des mesures, gestion des comptes), et rattache le tout, en 2.C.1 et 2.C.2, à une analyse de conformité par système d'information et à un plan d'action avec un responsable et une échéance par action. La lecture objectif par objectif est dans l'article consacré au référentiel ReCyF.

Un détail du ReCyF mérite d'être connu avant d'écrire une ligne : pour l'objectif 2, une entité peut se prévaloir lors d'un contrôle d'un SMSI certifié ISO/IEC 27001:2022 sur les systèmes couverts par le certificat. La clause 5.2 de la norme attend que la direction établisse une politique adaptée à la finalité de l'organisme, qui porte des objectifs de sécurité ou un cadre pour les fixer, un engagement à satisfaire les exigences applicables et un engagement d'amélioration continue, et que cette politique soit documentée, communiquée et disponible aux parties intéressées. Le contrôle A.5.1 de l'annexe A ajoute la revue à intervalles planifiés. Ce que la certification coûte et qui produit ses preuves techniques est détaillé dans l'article sur la certification ISO 27001.

Le guide PSSI de la DCSSI (2004) et la PSSIE (2014) : ce qui sert encore

La façon dont on écrit une PSSI en France doit encore beaucoup à deux documents publics assez mal connus. Le premier est le guide de la DCSSI du 3 mars 2004, en quatre sections (introduction, méthodologie, principes de sécurité, références SSI), héritier d'un guide de politique de sécurité interne de 1994. Il précise lui-même qu'il "n'a pas de caractère obligatoire" et qu'il "ne constitue pas un résultat final qu'un responsable SSI peut recopier". Sa page a disparu du catalogue de l'ANSSI : en septembre 2026, l'URL historique renvoie une page "guide introuvable", et il faut passer par une archive pour le lire. Sa méthode en quatre phases reste la plus claire qu'on ait en français.

Le second document est la PSSIE, la politique de sécurité des systèmes d'information de l'État, approuvée par la circulaire du Premier ministre n° 5725/SG du 17 juillet 2014. Elle s'applique aux administrations, pas à vous, sauf si vous êtes un établissement public sous tutelle d'un ministère, une autorité administrative indépendante ou un prestataire intervenant sur un système d'information de l'État. Mais c'est le meilleur exemple public d'une PSSI de direction lisible : dix principes stratégiques en une page, une instruction en dix articles qui fixe le champ d'application, les délais (conformité totale dans les trois ans, PSSI et plan d'action de chaque entité au 1er janvier 2015), le pilotage et le contrôle, puis les règles classées par thème. Son article 6, avec ses trois déclencheurs de revue (menaces et incidents, analyses de risques et contrôles, évolutions du contexte), est un modèle de section "cycle de vie". Son principe P10, l'hébergement des informations sensibles sur le territoire national, est une contrainte d'État, pas une bonne pratique générale.

Ce qui a vieilli dans le guide de 2004, c'est le poids de la méthode : six tâches pour la seule phase stratégique, et seize domaines de principes dont certains (signaux compromettants, infrastructures de gestion de clés) ne concernent pas une PME. On en garde la colonne vertébrale, stratégie, règles, plan d'action, et on adosse l'analyse de risques à une méthode courante, décrite dans l'article sur la gestion des risques selon ISO 27005.

Les erreurs classiques d'une PSSI

La PSSI de 80 pages est la plus répandue, et elle a toujours la même origine : un cabinet a livré un document qui couvre tous les domaines d'un référentiel, contrôle par contrôle, pour que rien ne manque. Rien ne manque, et personne ne lit. Demandez à un responsable d'équipe ce que dit la PSSI sur son périmètre : s'il ne sait pas, le document n'existe pas pour lui, quelle que soit sa qualité.

La PSSI copiée d'un modèle se repère en trois minutes. Elle nomme un comité qui ne s'est jamais réuni, un outil que vous n'avez pas, un site que vous n'avez plus. Elle décrit un RSSI, un correspondant par direction et un comité trimestriel, dans une entreprise de quatre-vingts personnes où la sécurité est portée par l'administrateur système un jour par semaine. Un auditeur qui trouve une incohérence de ce type cesse de faire confiance au reste du document et bascule en vérification systématique.

La PSSI sans propriétaire ni revue est celle de l'introduction : signataire parti, personne mandaté pour la modifier. Le guide de 2004 y consacrait déjà son premier principe, PSI-01, "Évolutions de la PSSI". Enfin, il y a la PSSI qui contredit la pratique, la plus dangereuse des quatre, parce qu'elle transforme un écart technique en écart de gouvernance. Le document dit que l'authentification multifacteur est obligatoire sur tous les accès distants ; le VPN accepte un mot de passe seul. Le document dit scan mensuel ; le dernier rapport date de l'été précédent. Chaque règle écrite est une promesse, et un contrôleur teste les promesses.

Relier la PSSI à des preuves : une politique sans scan daté est du papier

Reprenons la question de la journée. L'auditrice a lu "scan mensuel des systèmes exposés" et demande le dernier rapport. La suite dépend entièrement de ce qu'on lui tend. Le rapport existe, daté du mois dernier, avec la liste des hôtes et les écarts par rapport au mois précédent : la règle est prouvée. Le rapport existe, daté d'il y a huit mois : la règle est écrite mais pas appliquée, ce qui vaut un constat. Il n'y a pas de rapport, parce que le scan est fait "à la main, de temps en temps" : la règle est une intention, et le constat porte sur la politique elle-même, qui déclare une mesure qui n'existe pas. Une politique de gestion des vulnérabilités sans scan daté est du papier, et le ReCyF le formalise en rattachant l'objectif 2 au point (f) de l'article 21.2, l'évaluation de l'efficacité des mesures.

La bonne façon de construire le document est donc de partir de la preuve et de remonter. Pour chaque principe de la section 7 du plan, on se demande quel artefact daté prouvera qu'il est appliqué, et qui le produit. Pour les vulnérabilités, c'est un rapport de scanner ou d'EASM avec son périmètre et sa date, un ticket par correction, et un retest. Pour la sécurité du développement, c'est un rapport de pentest avant mise en production, avec les correctifs vérifiés. Pour les fournisseurs, c'est la liste des prestataires et les clauses de sécurité des contrats. Si aucun artefact n'existe, il reste deux choix honnêtes : créer la procédure qui le produira, ou ne pas écrire le principe. Le troisième choix, écrire le principe sans la preuve, coûte un constat.

Cette chaîne preuve, procédure, politique est celle que décrit le guide de la gestion des vulnérabilités côté opérationnel, et c'est à cet étage-là qu'own2pwn intervient, celui des artefacts. Rédiger la politique et animer un SMSI sont le travail d'un cabinet de gouvernance, métier qu'une société unipersonnelle de sécurité offensive n'exerce pas. Ce qu'elle rend, ce sont des documents datés sur le périmètre exposé : la matrice de couverture de l'article 21.2 et la preuve d'efficacité dans le volet technique d'un audit NIS2, ou un test d'intrusion daté qui alimente la section "Conformité et contrôle".

À retenir

• La PSSI est le document de tête, signé par le dirigeant, en quinze à vingt-cinq pages : périmètre, enjeux, organisation, principes, engagement. Les règles chiffrées descendent dans des politiques thématiques, le mode opératoire dans des procédures.
• NIS2 exige à l'article 21(2)(a) des politiques d'analyse des risques et de sécurité des SI, approuvées par les organes de direction (article 20). Le ReCyF (objectif 2) précise le contenu minimal, l'approbation par le dirigeant exécutif, la revue annuelle et quatre politiques thématiques.
• Le guide DCSSI de 2004 fournit la méthode (quatre phases) et un plan-type ; la PSSIE de 2014 est le meilleur exemple public d'une politique de direction lisible. Ni l'un ni l'autre n'est un modèle à recopier.
• Les quatre défauts qui coûtent un constat : le document trop long pour être lu, le document copié qui décrit une organisation qui n'existe pas, le document sans propriétaire ni revue, et le document qui promet ce que la pratique dément.
• Chaque principe écrit doit désigner la preuve datée qui l'appuie et la personne qui la produit. Quand cette preuve n'existe pas et qu'on ne compte pas la créer, mieux vaut ne pas écrire le principe.

Reste le cas le plus courant, celui d'une politique qui promet une surveillance de l'exposition externe ou une gestion des vulnérabilités sans qu'aucun artefact daté ne suive. Deux issues honnêtes : retirer la phrase, ou produire l'artefact avant le contrôle. La seconde coûte souvent moins qu'une réécriture du document, parce qu'elle se fait une fois et laisse une trace réutilisable. C'est ce que rend le volet technique d'un audit NIS2 : la politique confrontée au périmètre réellement exposé, et une matrice de couverture de l'article 21.2 que votre auditeur pourra verser au dossier.

Questions fréquentes sur la PSSI