PSSI : contenu, rédaction et suivi de la politique

La politique de sécurité des systèmes d’information, ou PSSI, fixe les objectifs, les responsabilités et les règles de sécurité de l’organisation. Pour être utilisable, elle doit relier chaque règle à une personne chargée de l’appliquer et à une preuve de fonctionnement. Un document approuvé mais sans suivi ne démontre pas que les systèmes sont protégés.

Une PSSI obligatoire dans tous les cas ?

Le RGPD impose de mettre en œuvre et de pouvoir démontrer des mesures appropriées. L’Art. 24(2) prévoit des politiques de protection des données lorsque cela est proportionné aux activités ; l’Art. 32 porte sur la sécurité adaptée au risque. Il ne prescrit pas à chaque organisme un document universel portant le titre « PSSI ». Des obligations sectorielles ou contractuelles peuvent être plus précises. Source : RGPD, Art. 24 et 32.

NIS2 distingue la gouvernance de l’Art. 20 et les mesures de l’Art. 21. L’approbation et la supervision par les organes de direction relèvent du premier. Le second énumère notamment analyse des risques, incidents, continuité, fournisseurs et contrôle de l’efficacité. Les règles nationales applicables doivent être vérifiées ; au 27 septembre 2026, le dossier français reste un projet, dont la discussion à l’Assemblée nationale est annoncée pour le 7 octobre. Cet agenda ne vaut pas entrée en vigueur. Sources : directive (UE) 2022/2555, Art. 20 et 21 ; dossier de l’Assemblée nationale.

La PSSI est un moyen d’organiser ces exigences. Son contenu doit correspondre aux risques et aux décisions de l’entreprise, plutôt qu’à un sommaire rempli pour sa seule longueur.

Le plan de PSSI à adapter

L’ANSSI propose de structurer les mesures autour de la gouvernance, de la protection, de la défense et de la résilience. Le plan ci-dessous est une trame pratique de rédaction, à adapter à votre contexte. Source : ANSSI, structurer ses mesures de sécurité.

Évitez de mêler dans un même texte les orientations durables et chaque réglage technique. La politique peut renvoyer à des procédures ou standards plus faciles à maintenir. Une procédure de départ des utilisateurs doit, par exemple, préciser comment les accès sont retirés, au-delà du principe général de limitation des habilitations.

Transformer un principe en règle contrôlable

Une règle comme « les données doivent être sécurisées » ne permet pas de vérifier l’application de la politique. Pour la rendre exploitable, renseignez cinq éléments : périmètre, comportement attendu, responsable, contrôle et traitement des écarts.

Ces exemples ne constituent pas un référentiel réglementaire exhaustif. Ils doivent être reliés à l’analyse des risques et aux contraintes de chaque activité.

Une clause commentée : le départ d’un utilisateur

Comparez deux formulations. La première, « Les comptes des personnes parties sont supprimés rapidement », laisse sans réponse plusieurs questions : qui annonce le départ, quelle heure retenir, faut-il supprimer les données du compte et comment traiter un accès fourni par un prestataire ? Deux services peuvent croire l’avoir appliquée tout en laissant une voie d’accès ouverte.

Voici un extrait de règle interne proposé, à compléter selon les systèmes et les risques :

Le responsable métier transmet à la DSI la date et l’heure de fin de l’accès, les applications utilisées et le suppléant à joindre. La DSI désactive les accès concernés à l’échéance convenue et vérifie les autres moyens d’authentification rattachés à l’utilisateur. Pour les services exploités par un tiers, le responsable du contrat obtient la confirmation du retrait. Le dossier de départ distingue accès retirés, vérifications restantes et données conservées pour une finalité justifiée.

Cette formulation organise une décision et une preuve ; elle n’impose pas un délai réglementaire universel. Pour un départ conflictuel ou un risque immédiat, la procédure d’urgence doit permettre une action adaptée sans attendre le circuit ordinaire. Le traitement du dossier RH reste séparé de la mesure de sécurité.

Première précision : le déclencheur. La date de fin du contrat et le dernier jour d’accès nécessaire peuvent différer. Le métier doit transmettre une consigne claire, validée selon l’organisation ; la DSI ne doit pas découvrir le départ en constatant une absence prolongée.

Deuxième précision : le périmètre. Un annuaire central ne contient pas nécessairement tous les outils. Recensez aussi les comptes locaux, les accès fournisseurs, les liens partagés et les moyens d’accès propres à certaines applications. Cette liste doit être adaptée à l’architecture réelle ; ne supposez pas qu’une désactivation centrale ferme automatiquement chaque accès.

Troisième précision : la preuve. Une demande envoyée n’est pas une confirmation d’exécution. Le dossier doit faire apparaître ce qui a été retiré, à quel moment et ce qui reste à vérifier. Une application dont le prestataire n’a pas répondu demeure dans les actions ouvertes, avec une mesure de maîtrise du risque à décider.

Quatrième précision : les données restantes. Bloquer l’accès ne signifie pas effacer indistinctement tous les documents. L’entreprise doit identifier ce qui relève d’un dossier professionnel à reprendre, d’une conservation nécessaire ou d’une suppression. La PSSI renvoie aux règles de conservation et de confidentialité au lieu de faire de la fermeture du compte une règle d’archivage générale.

Relier la politique à trois documents de travail

Pour que cet extrait soit applicable, préparez une fiche de départ, une procédure technique par famille de systèmes et un relevé de contrôle. Leur séparation permet de modifier un paramétrage sans réécrire toute la politique, tout en conservant la même exigence de résultat.

Ce dispositif peut rester simple : un registre partagé à accès restreint suffit pour organiser les preuves si son contenu, ses droits d’accès et son suivi sont adaptés. Le choix d’un logiciel ne résout pas une responsabilité indéfinie. Les justificatifs eux-mêmes contiennent parfois des données personnelles ; leur contenu et leur conservation doivent rester limités à ce qui est utile, conformément à l’Art. 5(1)(c) et (e). Source : RGPD, principes du traitement.

Répartir la rédaction, l’approbation et l’application

Le RSSI peut coordonner la rédaction avec les équipes métier, informatiques et juridiques. La direction compétente doit arbitrer les règles, les ressources et les risques résiduels. Les personnes qui exploitent les systèmes doivent ensuite disposer de consignes applicables.

La diffusion doit être adaptée aux destinataires : collaborateurs, administrateurs ou fournisseurs n’ont pas nécessairement besoin du même niveau de détail. L’ajout d’une règle dans un document ne règle pas à lui seul son opposabilité contractuelle ou disciplinaire. Les formalités propres au contexte doivent être examinées.

Le panorama des logiciels de conformité et de cybersécurité permet de relier certains besoins aux catégories d’outils. Chaque acquisition doit répondre à une mesure définie et à un responsable capable de l’exploiter.

Organiser les exceptions et les révisions

Une exception doit préciser le motif, le périmètre, la personne qui l’autorise, la durée et les mesures compensatrices. À son échéance, elle est supprimée ou réexaminée explicitement. Un simple oubli ne doit pas transformer une dérogation temporaire en règle permanente.

Une demande telle que « conserver le compte de Léa pendant la transition » ne suffit donc pas. Dans cet exemple fictif, le besoin est de transmettre trois dossiers au successeur. Examinez d’abord une attribution limitée des documents, avec traçabilité, plutôt que le maintien de tous les droits de Léa. Si un maintien temporaire est réellement nécessaire, la décision doit préciser quels droits, pour quelle personne autorisée, jusqu’à quand et sous quel contrôle. Elle n’autorise pas implicitement le partage du mot de passe ni l’utilisation de l’identité de l’ancienne salariée.

Une dérogation interne ne rend pas licite une mesure interdite par une règle applicable. Son approbation atteste un arbitrage documenté ; elle ne dispense ni de respecter la loi ni de vérifier que les mesures annoncées existent.

Réexaminez la politique après les changements importants : nouveau service, prestataire, incident, audit ou évolution des exigences. Une cadence interne régulière peut compléter ces déclencheurs ; elle ne remplace pas la mise à jour lorsqu’un risque change. L’Art. 24(1) prévoit le réexamen et l’actualisation des mesures si nécessaire. Source : RGPD, Art. 24(1).

L’audit de sécurité vérifie les pratiques et les preuves, pas seulement l’existence du document. La procédure de gestion des incidents doit rester cohérente avec les pouvoirs et les circuits décrits par la PSSI.

Ce qu’il faut retenir

• Adaptez la PSSI aux activités et obligations de l’organisme.
• Associez chaque règle à une mise en œuvre et à un contrôle.
• Faites arbitrer les moyens et les risques par les décideurs compétents.
• Suivez les exceptions et mettez à jour la politique lorsque le contexte change.

FAQ

Une PSSI signée prouve-t-elle la conformité RGPD ?

Non. Elle documente une organisation et des règles. Il faut aussi démontrer leur mise en œuvre, leur pertinence et leur efficacité.

Peut-on partir d’un modèle ?

Oui, comme trame de travail. Les responsabilités, systèmes, contraintes et procédures doivent ensuite être renseignés et vérifiés dans l’organisation.

Faut-il revoir la PSSI exactement tous les ans ?

Une revue annuelle peut être une règle interne utile. Les exigences applicables et les changements de risque peuvent imposer d’agir plus tôt ; le RGPD ne fixe pas un calendrier annuel universel pour ce document.

Recevez nos analyses pratiques sur la gouvernance de la sécurité.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.