Skip to content
Retour aux guides
Guide

Rédiger votre PSSI : modèle et guide complet pour PME

Modèle de Politique de Sécurité des Systèmes d'Information (PSSI) pour PME. Structure, contenu obligatoire, validation et lien avec NIS2, ISO 27001 et RGPD.

Thomas Ferreira 21 min de lecture

Une PME industrielle de 120 employés. Lors d’un audit de qualification pour un marché public, l’acheteur demande la PSSI en vigueur. Le responsable informatique envoie un document Word téléchargé sur un forum en 2021, rebaptisé au nom de l’entreprise, dont la section « gouvernance » désigne encore l’ancien prestataire informatique parti depuis deux ans. Le marché est perdu. L’acheteur a noté : « absence de politique de sécurité formalisée et à jour ».

Ce scénario est fréquent. Les PME ont souvent un document qu’elles appellent PSSI. Mais ce document n’engage personne, ne correspond à aucune réalité opérationnelle, et ne passerait pas la moindre vérification sérieuse. Ce guide explique comment rédiger une PSSI qui tient — pas un document de façade, mais un outil de gouvernance qui correspond à ce que fait réellement votre entreprise.

Qu’est-ce qu’une PSSI et pourquoi en rédiger une

La Politique de Sécurité des Systèmes d’Information (PSSI) est le document central de la gouvernance cybersécurité d’une organisation. Elle formule les objectifs de sécurité, définit les responsabilités, fixe les règles à respecter dans chaque domaine, et trace le cadre dans lequel les mesures techniques s’inscrivent.

PSSI versus charte informatique : deux documents différents

La confusion entre les deux est fréquente. Voici la distinction pratique :

PSSICharte informatique
AudienceDirection, responsables, auditeursTous les collaborateurs
NiveauStratégique et gouvernanceOpérationnel et comportemental
ContenuPolitiques, objectifs, responsabilitésRègles d’usage, obligations, sanctions
SignataireDirection généraleChaque salarié
Longueur20-40 pages5-15 pages

La PSSI dit pourquoi et quoi (« l’entreprise applique le principe du moindre privilège pour les accès aux données sensibles »). La charte informatique traduit ce principe en règle utilisateur (« ne jamais communiquer ses identifiants, même à un collègue »).

L’un ne remplace pas l’autre. Une PME bien structurée dispose des deux.

Pourquoi les auditeurs et les assureurs l’exigent

La PSSI est devenue le premier document demandé lors d’un audit de sécurité ou d’une souscription d’assurance cyber. Elle sert de preuve que votre sécurité repose sur une politique délibérée, pas sur les habitudes individuelles de votre équipe informatique.

Sans PSSI, un auditeur ne peut pas évaluer si vos pratiques sont conformes à vos propres règles — car il n’y a pas de règles documentées. Sans PSSI, un assureur peut refuser la garantie ou appliquer une franchise majorée après sinistre, au motif que l’entreprise n’avait pas de politique de gestion des risques.

Les obligations réglementaires

NIS2 — Article 21 : les entités concernées doivent adopter des mesures de gestion des risques qui comprennent des « politiques relatives à la sécurité des réseaux et des systèmes d’information ». La PSSI est la traduction directe de cette exigence. L’article 20 ajoute que la direction approuve ces politiques et peut être tenue personnellement responsable en cas de manquement. Une PSSI non validée par la direction générale ne satisfait pas NIS2.

ISO 27001 — Clause 5.2 : la norme exige que la direction établisse une politique de sécurité de l’information documentée, approuvée et communiquée. La PSSI est le document qui matérialise cette clause. Sans elle, la certification ISO 27001 est impossible.

RGPD — Article 32 : le règlement oblige les responsables de traitement à mettre en place des « mesures organisationnelles appropriées » pour garantir la sécurité des données personnelles. La PSSI constitue la principale mesure organisationnelle documentée. En cas de contrôle CNIL après une violation de données, la présence ou l’absence d’une PSSI à jour pèse dans l’évaluation de la diligence de l’entreprise.

L’ANSSI a publié un guide méthodologique pour l’élaboration d’une PSSI, disponible sur cyber.gouv.fr. Ce guide reste la référence française pour les PME qui souhaitent un cadre structuré.

La structure type d’une PSSI

Une PSSI bien structurée couvre onze chapitres. Voici leur contenu et leur utilité pour une PME.

Chapitre 1 — Introduction et contexte

Ce chapitre pose les bases. Il doit contenir :

  • La description de l’entreprise (activité, taille, secteur) et de son environnement numérique
  • Le périmètre couvert par la PSSI : quels systèmes, quelles données, quels sites géographiques, quels utilisateurs (salariés, prestataires, sous-traitants)
  • Les référentiels et réglementations applicables (NIS2, RGPD, ISO 27001, DORA selon votre secteur)
  • La date d’approbation et la signature de la direction générale

La signature de la direction n’est pas une formalité : elle engage la responsabilité de l’organisation et donne du poids au document face à un auditeur ou à un tribunal.

Chapitre 2 — Gouvernance de la sécurité

Ce chapitre identifie qui fait quoi :

  • Le responsable sécurité (ou la personne qui assume ce rôle en l’absence d’un poste dédié)
  • Le DPO pour les aspects protection des données
  • La direction générale et son rôle d’approbation
  • Le comité de pilotage sécurité, s’il existe (fréquence des réunions, ordre du jour type)
  • Les responsabilités de chaque rôle en cas d’incident

Pour une PME sans responsable sécurité dédié, désignez clairement qui endosse ce rôle (souvent le responsable informatique). L’absence de désignation explicite est un écart immédiatement noté lors d’un audit.

Chapitre 3 — Classification des actifs et des données

Ce chapitre liste ce que vous protégez et à quel niveau :

  • Inventaire des actifs informatiques critiques (serveurs, applications métier, données clients)
  • Niveaux de classification des données : public, interne, confidentiel, très confidentiel
  • Règles de traitement selon le niveau de classification (où stocker, comment transmettre, qui peut accéder)

Ce chapitre est souvent bâclé dans les PME. Or, sans classification, les règles d’accès et de sauvegarde n’ont pas de base rationnelle.

Chapitre 4 — Contrôle des accès et authentification

Les règles sur l’attribution et la révocation des accès :

  • Principe du moindre privilège (chaque utilisateur n’accède qu’aux ressources nécessaires à son travail)
  • Processus d’attribution des droits à l’arrivée d’un collaborateur
  • Processus de révocation à son départ — point souvent défaillant dans les PME
  • Exigences d’authentification : complexité des mots de passe, authentification multi-facteur obligatoire sur les accès sensibles
  • Gestion des comptes administrateurs (comptes distincts, traçabilité des actions)

Chapitre 5 — Sécurité des communications et de la messagerie

Les règles sur les flux entrants et sortants :

  • Messagerie professionnelle : chiffrement, filtrage anti-spam et anti-phishing, règles de transfert vers l’extérieur
  • Accès distants : VPN obligatoire, restrictions réseau
  • Transferts de données sensibles : protocoles autorisés, interdiction des plateformes de partage non approuvées
  • Utilisation des outils d’IA générative : quelles données peuvent y être saisies, lesquelles ne le peuvent pas

Chapitre 6 — Gestion des incidents de sécurité

La procédure de réponse aux incidents, résumée ici et détaillée dans un document opérationnel annexé :

  • Définition de ce qui constitue un incident (incident mineur vs incident majeur)
  • Canal de signalement interne (email dédié, astreinte)
  • Responsabilités dans les premières heures : qui décide, qui communique, qui préserve les preuves
  • Obligations de notification externe : ANSSI sous 24 heures pour NIS2, CNIL sous 72 heures pour les violations de données personnelles
  • Critères d’escalade vers une cellule de crise

Ce chapitre renvoie idéalement vers votre plan de réponse à incident pour les procédures détaillées.

Chapitre 7 — Sauvegarde et continuité d’activité

Les règles sur la résilience opérationnelle :

  • Fréquence des sauvegardes par type de données
  • Règle 3-2-1 (3 copies, 2 supports différents, 1 hors site)
  • Délais de restauration cibles (Recovery Time Objective et Recovery Point Objective)
  • Tests de restauration obligatoires (au minimum une fois par an)
  • Procédure de fonctionnement en mode dégradé en cas d’indisponibilité des systèmes

Chapitre 8 — Sensibilisation et formation

Voir la section dédiée ci-dessous — c’est le chapitre le plus souvent sous-traité dans les PSSI de PME.

Chapitre 9 — Gestion des prestataires et sous-traitants

Les règles applicables aux tiers qui accèdent à vos systèmes :

  • Processus de qualification sécurité des prestataires (questions à poser avant contractualisation)
  • Clauses contractuelles de sécurité obligatoires dans les contrats avec les sous-traitants (exigences RGPD article 28)
  • Conditions d’accès aux systèmes (accès limités dans le temps, traçabilité)
  • Procédure de révocation des accès à la fin d’une prestation

Ce chapitre est directement lié à l’article 21.2.d de NIS2, qui exige la sécurisation de la chaîne d’approvisionnement.

Chapitre 10 — Conformité réglementaire

La liste des obligations réglementaires applicables et la façon dont la PSSI y répond :

  • RGPD : mesures organisationnelles documentées, registre des traitements, procédure de violation
  • NIS2 : mesures de l’article 21, obligation de notification des incidents
  • Secteur spécifique : DORA pour les entités financières, HDS pour les acteurs de santé, etc.

Ce chapitre doit être mis à jour à chaque évolution réglementaire.

Chapitre 11 — Révision et amélioration continue

Les conditions dans lesquelles la PSSI sera revue :

  • Révision annuelle systématique (date fixée à l’avance)
  • Révision exceptionnelle après tout incident significatif
  • Révision exceptionnelle après tout changement organisationnel ou technologique majeur
  • Processus de validation des révisions (approbation direction)
  • Gestion des versions (numérotation, historique des modifications)

Le chapitre sensibilisation dans la PSSI

Le chapitre 8 est souvent rédigé en deux lignes : « Les collaborateurs suivent une formation annuelle à la cybersécurité. » Ce n’est pas une politique — c’est une déclaration d’intention qui ne dit rien sur ce que l’entreprise fait réellement.

Un chapitre sensibilisation opérationnel doit couvrir les points suivants.

L’obligation de participation

Formulez explicitement que la participation aux formations et aux exercices de sécurité est une obligation professionnelle, pas une démarche volontaire. Cette mention est nécessaire pour pouvoir sanctionner un refus répété. Précisez :

  • Les types de formations concernées (e-learning, ateliers présentiel, simulations)
  • La fréquence minimale (au moins une session par an, avec rappels si nécessaire)
  • La procédure de dispense exceptionnelle (demande écrite, validation du responsable)

La fréquence et les modalités des simulations de phishing

La PSSI doit mentionner que l’entreprise réalise régulièrement des simulations d’attaques par email pour évaluer la vigilance des équipes. Cette mention remplit deux fonctions :

  1. Elle constitue la base légale des simulations au regard de la CNIL (information préalable des personnes concernées)
  2. Elle engage l’organisation à maintenir un programme structuré, pas des tests ponctuels sans suite

Précisez la fréquence (par exemple : au minimum deux campagnes par an) et le fait que les résultats agrégés sont utilisés pour adapter le programme de formation. Les simulations de phishing de nophi.sh génèrent automatiquement les indicateurs attendus dans ce chapitre : taux de clics, taux de signalement, évolution dans le temps.

Le canal et l’obligation de signalement

Définissez le canal de signalement des incidents et des emails suspects : une adresse email dédiée, un bouton dans le client de messagerie, ou un numéro d’astreinte. Formalisez l’obligation de signaler — pas seulement l’invitation. Le taux de signalement est l’un des indicateurs de maturité cybersécurité les plus fiables : une équipe qui signale sans cliquer est une équipe qui a intégré les bons réflexes.

Les sanctions en cas de récidive

Un collaborateur qui clique sur un lien de phishing lors d’une première simulation est une donnée normale. Un collaborateur qui clique à chaque campagne, après plusieurs formations ciblées, pose une question de responsabilité. La PSSI doit tracer la ligne : après combien d’incidents malgré formation, quelles mesures disciplinaires entrent en jeu ? Sans cette mention, vous ne pouvez pas agir.

Les indicateurs de suivi

La PSSI doit définir les métriques qui permettront de mesurer l’efficacité du programme :

  • Taux de participation aux formations
  • Taux de clics sur les simulations de phishing (avec objectif de réduction)
  • Taux de signalement des simulations (avec objectif de progression)
  • Nombre d’incidents réels liés à un comportement utilisateur sur la période

Ces indicateurs sont présentés à la direction lors de la revue annuelle. Nophi.sh fournit ces indicateurs en tableau de bord, prêts à être intégrés dans votre reporting de gouvernance.

PSSI et cadre réglementaire

La PSSI n’est pas un document réglementaire en soi : c’est l’instrument qui prouve que vous avez mis en place les mesures que les réglementations vous imposent. Voici comment les principales obligations se croisent.

Tableau de correspondance

Obligation réglementaireRéférenceChapitre PSSI concerné
Politiques de sécurité des SINIS2, Art. 21.11 (périmètre), 2 (gouvernance)
Approbation par la directionNIS2, Art. 201 (signature direction)
Sécurité de la chaîne d’approvisionnementNIS2, Art. 21.2.d9 (prestataires)
Gestion des incidentsNIS2, Art. 21.2.b6 (incidents)
Formation et cyber-hygièneNIS2, Art. 21.2.g8 (sensibilisation)
Politique de sécurité documentéeISO 27001, Clause 5.2Tout le document
Contrôle d’accèsISO 27001, Annexe A 5.154 (accès)
Gestion des incidentsISO 27001, Annexe A 5.246 (incidents)
Mesures organisationnellesRGPD, Art. 322, 3, 4, 8, 9, 10
Sous-traitants et contratsRGPD, Art. 289 (prestataires)
Gouvernance TIC et politiquesDORA, Art. 52 (gouvernance)
Résilience opérationnelleDORA, Art. 117 (sauvegarde)

NIS2 et la responsabilité de la direction

L’article 20 de NIS2 est une nouveauté par rapport à NIS1 : les membres de la direction qui ont approuvé les mesures de gestion des risques — et donc la PSSI — peuvent être tenus personnellement responsables en cas de manquement grave. Cette disposition change la nature de l’approbation par la direction : ce n’est plus une signature de façade, c’est un engagement avec des conséquences juridiques potentielles.

Pour les entités NIS2, la PSSI doit être signée par un membre de la direction habilitée à engager l’organisation, et les révisions annuelles doivent être formellement approuvées.

RGPD : la PSSI comme preuve de conformité article 32

L’article 32 du RGPD n’impose pas de contenu précis pour les mesures organisationnelles. Il impose un résultat : un niveau de sécurité adapté au risque, démontrable. La PSSI est la pièce maîtresse de cette démonstration. En cas de violation de données suivie d’un contrôle CNIL, l’absence de PSSI à jour est interprétée comme l’absence de politique de sécurité — ce qui aggrave l’évaluation de la faute.

DORA pour les entités financières

Si votre entreprise entre dans le périmètre de DORA (établissements financiers, prestataires de services TIC pour le secteur financier), l’article 5 impose des politiques de gouvernance TIC approuvées par l’organe de direction. La PSSI remplit cette exigence à condition d’inclure un chapitre dédié à la résilience opérationnelle numérique.

Rédiger une PSSI pragmatique

Les PSSI qui finissent dans un tiroir ont des caractéristiques communes. Les voici, avec les façons d’éviter chaque écueil.

Erreur 1 : trop long

Une PSSI de 200 pages, rédigée en langage juridique dense, ne sera lue par personne — pas même lors de l’audit si l’auditeur est pressé. Pour une PME, 20 à 40 pages couvrent tous les chapitres nécessaires. Au-delà, on ajoute du volume sans ajouter de valeur. Chaque règle incluse dans la PSSI doit avoir une raison d’être, un responsable, et un moyen de vérification. Si vous ne pouvez pas remplir ces trois cases, supprimez la règle.

Erreur 2 : trop vague

« L’entreprise protège ses données » ne veut rien dire. Une règle opérationnelle doit être testable : soit elle est respectée, soit elle ne l’est pas. « Les comptes des collaborateurs partis sont révoqués dans les 24 heures suivant leur départ » est une règle testable. Visez cette précision pour chaque politique définie.

Erreur 3 : non validée par la direction

Une PSSI signée uniquement par le responsable informatique n’engage pas l’organisation. Elle n’est pas opposable à un auditeur NIS2, elle ne satisfait pas la clause 5.2 d’ISO 27001, et elle ne prouve rien au regard de l’article 32 du RGPD. La signature de la direction générale est une condition, pas une option.

Erreur 4 : non communiquée

Une PSSI gardée dans un dossier partagé que personne ne consulte n’existe pas, en pratique. Communiquez-la à tous les collaborateurs au moment de la mise en place, intégrez une version synthétique dans le parcours d’onboarding, et mentionnez les points clés lors des formations de sensibilisation. Conservez une trace de la communication (email, signature d’un document de prise de connaissance).

Erreur 5 : jamais mise à jour

Une PSSI de 2021 dans un environnement de 2026, avec du télétravail généralisé, des outils d’IA générative et NIS2 en vigueur, est un document obsolète. Inscrivez la révision annuelle dans votre calendrier dès aujourd’hui. Prévoyez un rappel automatique pour ne pas la sauter. Après chaque incident ou audit, vérifiez si le document doit être mis à jour.

Modèle de PSSI pour PME

Ce squelette vous donne la structure de chaque chapitre avec les points à traiter. Ce n’est pas un texte prêt à l’emploi : chaque section doit être adaptée à votre environnement réel, puis validée par la direction et, le cas échéant, par votre DPO ou un prestataire spécialisé.


POLITIQUE DE SÉCURITÉ DES SYSTÈMES D’INFORMATION [Raison sociale] — Version [X.X] — Approuvée le [date] par [nom, fonction]


1. Introduction et contexte

1.1 Présentation de l’entreprise [Activité, taille, sites concernés, environnement informatique global : cloud, on-premise, SaaS utilisés.]

1.2 Périmètre de la PSSI [Systèmes couverts, données concernées, catégories d’utilisateurs : salariés, prestataires, stagiaires. Exclusions explicites si nécessaire.]

1.3 Référentiels applicables [Réglementations et normes : RGPD, NIS2, ISO 27001, DORA, sectoriels. Indiquer pour chacun si l’entreprise est directement soumise ou si elle s’en inspire volontairement.]

1.4 Approbation [Signature du dirigeant ou de la personne déléguée. Date. Numéro de version. Prochain rendez-vous de révision.]


2. Gouvernance de la sécurité

2.1 Responsabilités [Nom et rôle du responsable sécurité. Rôle du DPO. Rôle de la direction générale. Rôle des managers d’équipe.]

2.2 Comité de pilotage [Composition, fréquence des réunions, ordre du jour type (revue des indicateurs, incidents du trimestre, plan d’action).]

2.3 Gestion des risques [Référence à l’analyse de risques menée (date, méthode) et au plan de traitement des risques. Fréquence de mise à jour de l’analyse.]


3. Classification des actifs et des données

3.1 Inventaire des actifs critiques [Liste des systèmes et données à protéger en priorité. Pour chaque actif : propriétaire, niveau de criticité, localisation.]

3.2 Niveaux de classification [Définition de vos niveaux : ex. Public / Interne / Confidentiel / Très confidentiel. Pour chaque niveau : exemples concrets, règles de stockage et de partage.]

3.3 Règles par niveau [Qui peut accéder à quoi, par quel canal, avec quelle authentification.]


4. Contrôle des accès et authentification

4.1 Principes directeurs [Moindre privilège, séparation des droits, comptes nominatifs obligatoires (pas de comptes génériques).]

4.2 Attribution et révocation des droits [Processus d’onboarding : qui demande, qui approuve, quel délai. Processus de départ : délai de révocation des accès (recommandé : immédiat ou sous 24h), confirmation écrite.]

4.3 Mots de passe et MFA [Exigences de complexité, durée de validité, interdiction de partage. Périmètre du MFA obligatoire : messagerie, VPN, applications métier critiques.]

4.4 Comptes à hauts privilèges [Règles spécifiques pour les administrateurs : comptes distincts, journalisation des actions, revue périodique des droits.]


5. Sécurité des communications

5.1 Messagerie professionnelle [Filtrage anti-phishing en place, règles sur les transferts externes, chiffrement des pièces jointes sensibles, obligation de signalement des emails suspects via [préciser le canal].]

5.2 Accès distants et VPN [VPN obligatoire hors locaux, réseaux Wi-Fi publics interdits sans VPN, règles sur le télétravail.]

5.3 Transferts de données [Outils de partage approuvés, interdiction des plateformes non approuvées (WeTransfer, Dropbox personnel, etc.) pour les données internes ou confidentielles.]

5.4 IA générative [Liste des données interdites dans les outils d’IA : données clients, données personnelles, informations stratégiques, code source sensible.]


6. Gestion des incidents

6.1 Définitions [Incident mineur vs incident majeur. Exemples concrets pour votre contexte.]

6.2 Signalement interne [Canal de signalement, astreinte si applicable, délai de prise en charge.]

6.3 Réponse et investigation [Référence au plan de réponse à incident annexé. Rôles dans la cellule de crise.]

6.4 Notifications obligatoires [ANSSI sous 24h pour NIS2. CNIL sous 72h pour les violations de données personnelles. Clients/partenaires selon contrats.]


7. Sauvegarde et continuité d’activité

7.1 Politique de sauvegarde [Fréquence par type de données. Règle 3-2-1. Chiffrement des sauvegardes. Localisation (y compris copie hors site).]

7.2 Tests de restauration [Fréquence minimale (au moins annuelle). Procédure de test. Documentation des résultats.]

7.3 Plan de continuité [Systèmes prioritaires à rétablir. Délais cibles (RTO, RPO). Mode de fonctionnement dégradé documenté.]


8. Sensibilisation et formation

[Voir section dédiée dans ce guide. Points à couvrir : obligation de participation, fréquence des formations, programme de simulations de phishing, canal de signalement, indicateurs de suivi, sanctions en cas de récidive après formation répétée.]


9. Prestataires et sous-traitants

9.1 Qualification sécurité [Questions à poser avant contractualisation : politique de sécurité du prestataire, certifications, gestion des sous-traitants de rang 2.]

9.2 Clauses contractuelles [Exigences minimales à inclure dans les contrats : confidentialité, notification des incidents, droit d’audit, clauses RGPD article 28.]

9.3 Gestion des accès tiers [Accès limités au périmètre nécessaire, durée définie, révocation systématique à la fin de la prestation. Traçabilité des accès.]


10. Conformité réglementaire

[Tableau de correspondance entre vos obligations et les chapitres de la PSSI. Référence au registre des traitements RGPD. Référence aux enregistrements NIS2 si applicables.]


11. Révision et amélioration continue

[Date de la prochaine révision annuelle. Conditions déclenchant une révision exceptionnelle. Processus de validation des modifications. Tableau des versions avec dates et nature des changements.]


Ce squelette est le point de départ. Votre responsable informatique ou votre prestataire doit le compléter avec les informations réelles de votre entreprise. Le DPO doit valider les chapitres 3, 4, 9 et 10 au regard du RGPD. La direction générale doit approuver et signer avant diffusion.

FAQ

La PSSI est-elle obligatoire pour les PME ?

La PSSI n’est pas exigée par un texte unique pour toutes les entreprises, mais elle devient obligatoire dès que vous entrez dans le périmètre de NIS2 (article 21.1), et elle est attendue comme mesure organisationnelle par ISO 27001 (clause 5.2) et RGPD (article 32). Même hors obligations formelles, une PME sans PSSI ne peut pas prouver à ses assureurs, clients grands comptes ou auditeurs que sa sécurité repose sur une gouvernance documentée. En pratique, toute entreprise traitant des données sensibles ou exposée à des risques cyber a intérêt à en rédiger une.

Quelle est la différence entre une PSSI et une charte informatique ?

La PSSI est un document de gouvernance stratégique : elle définit la politique de l’entreprise en matière de sécurité, fixe les objectifs, les responsabilités et les règles à haut niveau. La charte informatique est un document opérationnel destiné aux utilisateurs finaux : elle traduit certaines règles de la PSSI en obligations quotidiennes. La PSSI s’adresse à la direction, aux responsables et aux auditeurs. La charte s’adresse à chaque collaborateur. Les deux documents sont complémentaires.

Quelle longueur doit avoir une PSSI pour une PME ?

Pour une PME de 50 à 250 employés, une PSSI de 20 à 40 pages est une bonne cible. Un document de 80 pages sera lu par personne, relu lors des audits uniquement, et jamais mis à jour. Mieux vaut une PSSI de 25 pages tenue à jour qu’un document de 120 pages sorti du tiroir une fois par an.

Qui doit rédiger la PSSI ?

La PSSI est rédigée par le responsable informatique ou le responsable sécurité, en collaboration avec le DPO pour les aspects RGPD et la direction pour la partie gouvernance. Pour les PME sans ressource interne dédiée, un prestataire peut assurer la rédaction initiale, mais la validation et la signature doivent rester en interne. La direction doit approuver formellement : une PSSI signée par le seul responsable informatique n’engage pas l’organisation.

NIS2 exige-t-elle une PSSI ?

Oui. L’article 21 de la directive NIS2 impose aux entités concernées d’adopter des politiques relatives à la sécurité des réseaux et des systèmes d’information. L’article 20 ajoute que la direction doit approuver ces politiques et peut être tenue responsable en cas de manquement. Sans PSSI validée par la direction, une entité NIS2 ne peut pas démontrer sa conformité lors d’un contrôle ANSSI.

Combien coûte la rédaction d’une PSSI par un prestataire externe ?

La rédaction d’une PSSI par un consultant cybersécurité externe coûte généralement entre 3 000 et 15 000 euros pour une PME, selon la complexité de l’environnement et le niveau de détail souhaité. Des cabinets proposent des prestations forfaitaires avec modèle à personnaliser, ce qui réduit les coûts. Certaines aides du dispositif France Num peuvent financer partiellement cette démarche.

Faut-il réviser la PSSI après un incident de sécurité ?

Oui. Après tout incident significatif, la PSSI doit être relue pour identifier si l’incident a révélé une lacune dans les règles ou les procédures documentées. De même, tout changement organisationnel majeur (fusion, ouverture d’un site, déploiement d’un nouvel outil) doit déclencher une révision ciblée des chapitres concernés.


Votre PSSI définit l’obligation de sensibilisation — nophi.sh l’applique. Nos simulations de phishing génèrent les indicateurs attendus dans votre chapitre 8 : taux de clics, taux de signalement, évolution dans le temps. Lancez votre première campagne gratuitement — résultats en 48h, sans installation.

Sources

  • ANSSI, Guide pour l’élaboration d’une PSSI, 2024 — cyber.gouv.fr
  • ANSSI, Référentiel NIS2 et guide d’accompagnement, 2025 — cyber.gouv.fr
  • Directive (UE) 2022/2555 (NIS2), articles 20 et 21 — eur-lex.europa.eu
  • Règlement (UE) 2016/679 (RGPD), articles 28, 32, 33 — eur-lex.europa.eu
  • ISO/IEC 27001:2022, clause 5.2 et Annexe A — iso.org
  • Règlement (UE) 2022/2554 (DORA), articles 5 et 11 — eur-lex.europa.eu
  • CNIL, Guide de la sécurité des données personnelles, 2024 — cnil.fr

Tester la vigilance de vos équipes face au phishing | Rédiger votre charte informatique | Conformité NIS2 pour les PME