PSSI : rédiger une politique de sécurité opposable et cohérente avec la charte informatique

Un grand compte vous envoie son questionnaire de sécurité, un auditeur ISO 27001 demande votre politique approuvée, un client soumis à NIS 2 veut savoir comment vos équipes appliquent ses règles. Les trois attendent le même document : une PSSI. Beaucoup d'entreprises en ont une, souvent copiée d'un modèle, rarement approuvée par la direction et presque jamais opposable à ceux qui doivent l'appliquer. Or NIS 2 impose des plafonds d'amende d'au moins 10 millions d'euros ou 2 % du chiffre d'affaires mondial pour les entités essentielles qui manquent à leurs mesures de sécurité, et la CNIL a infligé 5 millions d'euros à France Travail le 22 janvier 2026 en relevant qu'une mesure prévue par ses propres analyses d'impact avait été repoussée. Voici ce qu'une PSSI doit contenir, et surtout comment ses règles deviennent exigibles d'un salarié ou d'un prestataire.

PSSI : ce qu'est une politique de sécurité des systèmes d'information

La politique de sécurité des systèmes d'information (PSSI) est le document par lequel la direction fixe ses objectifs de sécurité, l'organisation qui les porte et les règles que doivent respecter tous ceux qui touchent au système d'information. Elle répond à trois questions : que protège-t-on, qui en est responsable, selon quels principes. Elle ne décrit pas la configuration d'un pare-feu.

Une décision de direction, pas un document technique

La PSSI informatique est souvent rédigée par le RSSI ou la DSI. C'est normal pour le fond, mais sa valeur vient de la signature. Le règlement d'exécution (UE) 2024/2690 du 17 octobre 2024, qui précise les mesures NIS 2 pour les fournisseurs de cloud, de centres de données et de services gérés, exige que la politique indique « la date d'approbation formelle par les organes de direction ». La norme ISO 27001 confie elle aussi la politique de sécurité à la direction (clause 5.2). Une PSSI validée par le seul service informatique reste une note interne.

Ce que la PSSI n'est pas

• Pas une analyse de risques : elle en découle et y renvoie.
• Pas une charte informatique : la charte traduit, pour chaque utilisateur, les comportements attendus.
• Pas un recueil de procédures : sauvegardes, gestion des comptes, réponse à incident vivent dans des documents d'exploitation, révisés au rythme de la DSI.

Confondre ces niveaux produit le défaut le plus courant : une PSSI de quatre-vingts pages, techniquement riche, que personne n'a lue et qu'aucun salarié ne peut se voir opposer.

PSSI obligatoire ou non : secteur public, NIS 2, ISO 27001 et clients

Aucun texte général n'impose à toute entreprise privée de rédiger un document intitulé PSSI. L'obligation naît du secteur, de la réglementation applicable ou du contrat.

Secteur public et opérateurs d'importance vitale

Les administrations de l'État relèvent de la PSSIE, la politique de sécurité des systèmes d'information de l'État, fixée par une circulaire du Premier ministre de juillet 2014 que l'ANSSI annonce remplacer par un cadre de gouvernance de la sécurité numérique. Les autorités administratives appliquent en outre le référentiel général de sécurité (décret n° 2010-112 du 2 février 2010). Pour les opérateurs d'importance vitale, le Premier ministre fixe des règles de sécurité que ces opérateurs appliquent « à leurs frais » (Code de la défense, art. L1332-6-1). Une entreprise privée qui travaille pour ces acteurs hérite souvent de leurs exigences par contrat.

NIS 2 : la politique devient une mesure minimale

La directive (UE) 2022/2555 liste, parmi les mesures que les entités essentielles et importantes doivent au minimum mettre en place, « les politiques relatives à l'analyse des risques et à la sécurité des systèmes d'information » (art. 21, § 2, a). Les organes de direction approuvent ces mesures, en supervisent la mise en œuvre et peuvent être tenus responsables de leur violation (art. 20). Les plafonds d'amende prévus par l'article 34 sont d'au moins 10 millions d'euros ou 2 % du chiffre d'affaires mondial pour une entité essentielle, 7 millions ou 1,4 % pour une entité importante.

Au 3 novembre 2026, la loi française de transposition n'est pas publiée au Journal officiel : le calendrier est suivi dans notre article sur la transposition de NIS 2 en France. Le règlement d'exécution 2024/2690 est, lui, directement applicable, mais il vise des entités dont la qualification dépend encore largement de la loi nationale. Pour un hébergeur, un éditeur SaaS ou une ESN qui infogère des systèmes, il donne dès maintenant le contenu attendu d'une PSSI, et c'est sur lui que les clients soumis à NIS 2 calquent leurs questionnaires.

ISO 27001 et les clients

Une entreprise qui vise la certification ISO 27001 doit disposer d'une politique de sécurité de l'information (clause 5.2) et de politiques thématiques (mesure A.5.1). Hors certification, l'obligation vient le plus souvent d'un client : un appel d'offres, une annexe sécurité, un plan d'assurance sécurité. Le RGPD ajoute un socle commun : le responsable de traitement met en œuvre, quand c'est proportionné, « des politiques appropriées en matière de protection des données » (art. 24, § 2), et le sous-traitant prend toutes les mesures de sécurité de l'article 32 (art. 28, § 3, c). Le manquement aux articles 28 et 32 expose à une amende pouvant atteindre 10 millions d'euros ou 2 % du chiffre d'affaires mondial (art. 83, § 4).

Le contenu d'une PSSI : ce que NIS 2 et ISO 27001 attendent

Les requêtes « PSSI exemple » renvoient à des modèles qui se ressemblent tous. Le meilleur sommaire disponible est réglementaire : l'annexe du règlement 2024/2690 (point 1.1.1) dit ce que doit contenir la politique de sécurité des réseaux et des systèmes d'information. Même hors de son champ, c'est une grille fiable.

Le socle de la politique

1. L'approche de l'entité pour gérer la sécurité, cohérente avec sa stratégie et ses objectifs économiques.
2. Des objectifs de sécurité, et des indicateurs pour suivre leur mise en œuvre et le niveau de maturité atteint.
3. Un engagement d'amélioration continue et un engagement de fournir les ressources : personnel, budget, outils.
4. Les rôles, responsabilités et pouvoirs, avec au moins une personne qui rend compte directement à la direction.
5. La liste des politiques thématiques et la liste des documents à conserver, avec leur durée de conservation.
6. La communication de la politique au personnel et aux tiers concernés, « qui en prennent acte ».
7. La date d'approbation formelle par la direction.

Les politiques thématiques

La PSSI de tête reste courte, dix à quinze pages pour une PME. Elle renvoie à des politiques par domaine, qui sont celles que l'auditeur et le client lisent vraiment : contrôle d'accès et authentification, gestion des actifs, sauvegarde et continuité, gestion des incidents, sécurité des fournisseurs, cryptographie, développement sécurisé pour un éditeur. NIS 2 cite ces domaines à son article 21, § 2, la mesure A.5.1 d'ISO 27001 vise les politiques propres à une thématique.

Point de vigilance. L'engagement de ressources n'est pas une formule de style. La décision France Travail relève que les analyses d'impact prévoyaient l'authentification multifacteur dès 2023 et que sa mise en place avait été repoussée (CNIL, SAN-2026-003, § 67 et 71). Un document qui promet une mesure non déployée devient une preuve contre son auteur.

PSSI, charte informatique, procédures : trois niveaux à ne pas confondre

Un corpus de sécurité tient sur trois étages, chacun avec ses destinataires et son régime juridique.

• La PSSI engage la direction et organise la sécurité. Ses destinataires sont la direction, le RSSI, la DSI, les auditeurs et les clients.
• La charte informatique fixe les obligations de chaque utilisateur : mots de passe, usage des outils, données interdites, signalement des incidents. C'est le seul document qui s'impose individuellement au salarié, à condition d'avoir été adopté comme il faut. Notre article sur l'obligation d'avoir une charte informatique et sa rédaction détaille cette mécanique.
• Les procédures décrivent la mise en œuvre technique. Elles évoluent souvent et ne doivent pas porter d'obligation sanctionnable pour l'ensemble du personnel.

La règle pratique tient en une phrase : toute exigence de la PSSI qui demande un comportement à l'utilisateur doit être reprise dans la charte. Si la PSSI écrit « l'authentification multifacteur est obligatoire pour tout accès distant » et que la charte n'en dit rien, le salarié qui la contourne ne viole aucune règle qui lui ait été rendue opposable : sa sanction devient fragile.

Un tableau de correspondance plutôt qu'une fusion

La tentation est de tout fusionner en un seul document. C'est une erreur : chaque modification de la PSSI déclencherait alors la procédure du règlement intérieur. La bonne pratique consiste à tenir un tableau de correspondance, règle par règle, entre la PSSI, la charte et les procédures. L'auditeur ISO y voit la cohérence, le juriste y voit ce qui est opposable.

Rendre la PSSI exigible des salariés

L'article L1321-5 du Code du travail règle la question. Un document qui comporte des obligations générales et permanentes en matière de santé, de sécurité ou de discipline est une adjonction au règlement intérieur, et il suit « en toute hypothèse » le même régime : avis du CSE, communication à l'inspecteur du travail, entrée en vigueur un mois au moins après la publicité (art. L1321-4). Le règlement intérieur est obligatoire à partir de 50 salariés (art. L1311-2).

Ce qui relève de la procédure, et ce qui y échappe

La Cour de cassation a jugé que le document interne qui se borne à rappeler les dispositions législatives et réglementaires applicables en matière de sécurité ne crée pas d'obligations nouvelles et n'est pas une adjonction (Cass. soc., 23 juin 2021, n° 19-15.737). L'arrêt portait sur des consignes de sécurité au travail, pas sur une politique informatique. Le raisonnement se transpose : la partie de la PSSI qui décrit l'organisation, les objectifs et les engagements de la direction n'impose rien au salarié. En revanche, l'interdiction de stocker des données clients sur un compte personnel ou l'obligation de signaler un courriel suspect dans l'heure sont des règles propres à l'entreprise, permanentes et sanctionnables. Elles doivent passer par la procédure, de préférence à travers la charte.

La sanction suppose une règle opposable

Quand la règle figure dans la charte, le juge la fait respecter. La Cour de cassation a approuvé le licenciement pour faute grave d'un salarié qui avait tenté de se connecter au poste du directeur en empruntant le mot de passe d'un collègue, comportement « contraire à l'obligation de respect de la charte informatique en vigueur dans l'entreprise » (Cass. soc., 21 décembre 2006, n° 05-41.165, inédit). Le règlement 2024/2690 demande d'ailleurs que l'entité établisse, communique et maintienne une procédure disciplinaire qui tient compte des exigences légales (point 10.4). La procédure d'adoption, l'échelle des sanctions et la preuve sont traitées dans notre article sur la charte informatique et les sanctions disciplinaires.

Deux points propres à la PSSI méritent l'attention. Les mesures de surveillance qu'elle prévoit (journalisation, filtrage, détection des fuites) doivent être portées à la connaissance des salariés avant leur mise en œuvre (art. L1222-4), et le CSE doit être consulté sur les moyens de contrôle de leur activité (art. L2312-38). Aucun arrêt de la Cour de cassation sur l'opposabilité d'une PSSI en tant que telle n'a été trouvé : la jurisprudence raisonne sur la charte et le règlement intérieur, ce qui confirme qu'il faut y loger les règles individuelles.

Rendre la PSSI exigible des prestataires

Le Code du travail ne s'applique pas à une ESN, à un hébergeur ou à un développeur indépendant. Pour eux, la PSSI ne vaut que par le contrat. Le Code civil pose la règle : des conditions générales n'ont d'effet à l'égard de l'autre partie que si elles ont été portées à sa connaissance et acceptées (art. 1119). Une PSSI publiée sur l'intranet, que le prestataire n'a jamais reçue, ne l'engage pas.

Le montage contractuel

• Annexer une version datée de la PSSI, ou des extraits applicables au prestataire, plutôt que renvoyer à « la PSSI en vigueur ».
• Prévoir la mise à jour : notification des nouvelles versions, délai de mise en conformité, droit de discuter le coût d'une exigence nouvelle.
• Traduire en obligations vérifiables : MFA, chiffrement, délai de notification d'un incident, droit d'audit, sort des données en fin de contrat.
• Articuler avec le DPA quand des données personnelles sont traitées : le sous-traitant doit prendre les mesures de l'article 32 (RGPD, art. 28, § 3, c).

Le règlement 2024/2690 va dans le même sens : l'entité exige du personnel et des tiers qu'ils appliquent ses mesures de sécurité (point 1.2.2), et elle établit une politique de sécurité de la chaîne d'approvisionnement (point 5.1).

Imposer sa PSSI ne transfère pas la responsabilité

La décision France Travail l'illustre. Les Cap emploi, qui accédaient à distance à son système d'information, signaient une adhésion par laquelle ils s'engageaient à « respecter, diffuser et appliquer les consignes » de sécurité, et les analyses d'impact renvoyaient au « corpus documentaire de la politique de sécurité des systèmes d'information » de France Travail. La CNIL en a tiré que France Travail restait « principal responsable de la détermination des règles de sécurité applicables » et que le déploiement des mesures lui incombait en premier lieu (SAN-2026-003, § 36 à 41). Faire signer sa PSSI à un tiers organise les obligations de chacun. Cela ne dispense pas de déployer les mesures qu'elle annonce.

Côté prestataire : lire la PSSI du client avant de signer

Une ESN ou un éditeur SaaS reçoit souvent la PSSI de son client en annexe, avec une clause d'acceptation « telle que modifiée ». C'est une obligation évolutive, fixée unilatéralement. Je recommande de négocier trois points : la liste des exigences réellement applicables au service, la procédure de changement avec son impact tarifaire, et un plafond de responsabilité qui couvre les manquements de sécurité.

PSSI et audit ISO 27001 : ce que l'auditeur regarde

L'auditeur de certification ne juge pas la qualité rédactionnelle. Il vérifie des preuves, et la PSSI en fournit plusieurs.

• L'approbation : une version signée et datée par la direction, cohérente avec le périmètre certifié.
• La communication : la preuve que les collaborateurs et les tiers concernés l'ont reçue, ce qu'un simple dépôt sur l'intranet ne prouve pas.
• Les politiques thématiques exigées par la déclaration d'applicabilité, et leur révision.
• La conformité réelle : la mesure A.5.36 demande de vérifier que les politiques sont respectées. Une PSSI qui impose le chiffrement des portables alors que la moitié du parc ne l'est pas devient un écart.
• Le lien avec les contrats et le processus disciplinaire (mesures A.5.20, A.6.2 et A.6.4).

Le volet juridique de la certification, en particulier le registre des exigences légales et le passage des politiques devant le CSE, est détaillé dans notre article sur ce que l'avocat prend en charge dans la certification ISO 27001. La PSSI n'en est qu'une pièce : son intérêt est d'être le point d'entrée de toutes les autres.

Scénario type : l'écart que l'on évite

Un éditeur de 80 salariés prépare son audit initial. Sa PSSI, approuvée en comité de direction, impose la MFA sur tous les accès d'administration. La charte informatique, adoptée en 2019, n'en parle pas, et un administrateur désactive la MFA sur son compte pour gagner du temps. L'auditeur relève un écart sur la conformité aux politiques. Le DRH constate qu'une sanction serait fragile : la règle n'existe que dans la PSSI. La correction prend six semaines, dont le mois imposé par l'article L1321-4 entre la publicité de la charte modifiée et son entrée en vigueur.

Faire vivre la PSSI : révision, preuves et calendrier

Une PSSI vieillit vite. Le règlement 2024/2690 impose un réexamen par la direction au moins une fois par an, et après tout incident important ou changement majeur, avec un résultat consigné (point 1.1.2). C'est un bon rythme pour toute entreprise, soumise ou non à NIS 2.

Le cycle de révision

1. Déclencheurs : revue annuelle, incident, nouveau client exigeant, nouvel outil (IA, cloud), texte nouveau comme la loi de transposition NIS 2.
2. Révision de la PSSI par le RSSI, validée par la direction, avec un historique des versions.
3. Répercussion : la modification change-t-elle une obligation des utilisateurs ? Si oui, la charte est modifiée et la procédure de l'article L1321-4 recommence. Si non, une simple information suffit.
4. Répercussion contractuelle : notification aux prestataires concernés, dans les formes prévues par leurs contrats.
5. Preuves : procès-verbal d'approbation, accusés de réception, supports de sensibilisation, conservés pour l'audit et pour un éventuel contentieux.

Ce qui fait échouer une PSSI

Trois erreurs reviennent. La PSSI copiée d'un modèle, qui cite des mesures que l'entreprise n'a pas. La PSSI jamais révisée, qui ignore le télétravail et les outils d'IA. La PSSI dont les règles ne descendent ni dans la charte ni dans les contrats, et qui ne peut donc être opposée à personne. Dans les trois cas, le document se retourne contre l'entreprise : il prouve qu'elle connaissait le risque.

Avocat au Barreau de Paris et développeur web certifié, je relis la PSSI avec le RSSI, j'identifie les règles qui doivent descendre dans la charte et dans les contrats, et je rédige les clauses qui les rendent exigibles. Cet accompagnement fait partie de mon intervention en droit de la cybersécurité. Si un audit, un appel d'offres ou un client NIS 2 vous impose de revoir votre politique, échangeons sur votre PSSI et sur ce qu'elle engage.