Une PSSI, pour Politique de Sécurité des Systèmes d’Information, est le document qui fixe par écrit ce que votre entreprise protège, contre quoi, et qui décide quoi. Ce n’est ni un manuel technique ni une formalité administrative : c’est la référence qu’on ouvre quand une décision doit être prise vite, et le premier document qu’un auditeur ou un régulateur demande à voir.
Depuis l’entrée en application de DORA en janvier 2025, ce document a changé de statut pour une partie des entreprises françaises. Il n’est plus une bonne pratique recommandée, il fait partie de ce qu’il faut pouvoir montrer.
Ce qu’est une PSSI, et ce qu’elle n’est pas
Une PSSI rassemble les règles, les procédures et les responsabilités qui encadrent l’usage du système d’information. Elle répond à trois questions : quels actifs comptent vraiment, quelles menaces pèsent sur eux, et qui fait quoi le jour où quelque chose arrive.
Ce qu’elle n’est pas, et c’est là que la plupart échouent : une liste d’outils. Une PSSI qui se contente d’énumérer un antivirus, un pare-feu et une sauvegarde n’est pas une politique, c’est un inventaire. Ce qui la rend utile, ce sont les arbitrages qu’elle acte à l’avance : qui a le droit d’accorder un accès administrateur, dans quel délai on isole un poste suspect, qui prévient la direction et à partir de quel seuil.
Le même objet qu’une politique qualité
Si votre entreprise est certifiée ISO 9001, vous connaissez déjà la PSSI sans le savoir : c’est le même objet, appliqué à un autre domaine. Là où la politique qualité énonce ce que l’entreprise s’engage à tenir sur la qualité de ses prestations, la PSSI énonce ce qu’elle s’engage à tenir sur la sécurité de son information. Même nature, même rôle, mêmes obligations d’entretien.
Ce n’est pas une analogie commode. Les deux normes partagent la structure harmonisée, longtemps appelée Annexe SL, qui impose à toutes les normes de système de management le même squelette : contexte, leadership, planification, support, réalisation, évaluation des performances, amélioration. La conséquence est frappante : la politique est exigée au même endroit, le chapitre 5.2, dans les deux normes. ISO 9001 y demande une politique qualité, ISO 27001 y demande une politique de sécurité de l’information. Cette dernière, c’est votre PSSI.
| ISO 9001 · qualité | ISO 27001 · sécurité de l’information |
|---|---|
| Politique qualité (chapitre 5.2) | Politique de sécurité, la PSSI (chapitre 5.2) |
| Objectifs qualité | Objectifs de sécurité |
| Risques et opportunités | Appréciation et traitement du risque |
| Procédures et modes opératoires | Procédures d’exploitation et charte informatique |
| Non-conformités et actions correctives | Incidents et actions correctives |
| Audit interne | Audit interne |
| Revue de direction | Revue de direction |
| Amélioration continue | Amélioration continue |
Tout ce qui fait qu’une politique qualité vit se transpose donc tel quel : la roue de Deming, la revue de direction qui tranche, l’écart consigné puis corrigé, et surtout la preuve datée. Un responsable qualité sait qu’un auditeur ne demande pas si la procédure existe, mais de montrer qu’elle était appliquée le 15 mars. C’est exactement ce que demande un auditeur sécurité, et c’est ce que la plupart des entreprises découvrent trop tard.
Là où le parallèle s’arrête
Deux exigences de l’ISO 27001 n’ont pas d’équivalent en qualité, et ce sont celles qui surprennent.
La première est l’appréciation formelle du risque. L’ISO 9001 demande de considérer les risques et opportunités, sans imposer de méthode. L’ISO 27001 exige un processus documenté, reproductible et rejoué : c’est le rôle d’une méthode comme EBIOS Risk Manager.
La seconde est la déclaration d’applicabilité. Il faut passer en revue les 93 mesures de l’annexe A, réparties en quatre thèmes (organisationnelles, liées aux personnes, physiques, technologiques), et justifier par écrit chacune de celles que l’on retient comme chacune de celles que l’on écarte. Justifier une exclusion est un exercice inhabituel, et c’est souvent lui qui révèle qu’une PSSI avait été écrite en survol.
Ce que cela change en pratique
Une entreprise déjà certifiée ISO 9001 possède le moteur. Elle sait tenir une revue de direction, traiter une non-conformité, produire une preuve horodatée. Il lui reste à y brancher le domaine sécurité, et sa PSSI n’est pas un document de plus : c’est la politique du chapitre 5.2, écrite pour un autre périmètre.
Une entreprise qui n’a jamais vécu de système de management découvre les deux en même temps, le moteur et les contrôles. C’est là que les démarches s’enlisent, et c’est la raison pour laquelle une PSSI rédigée sans le réflexe de la preuve finit invariablement dans un tiroir.
Nous parlons de ce que nous pratiquons : ITAIA fait auditer son système de management par un organisme indépendant depuis 2021 au titre de l’ISO 9001, et aborde son cinquième audit. Nous avons détaillé ce que cinq ans de système audité changent pour une démarche de certification en sécurité dans ce billet.
Ce qu’une PSSI contient
Le contenu s’organise autour de trois principes, souvent appelés la triade CIA.
- Confidentialité. Seules les personnes autorisées accèdent aux données. Cela suppose des droits nominatifs, revus, et non hérités d’un poste précédent.
- Intégrité. Les données ne se modifient pas sans autorisation ni sans trace. C’est ce qui distingue une erreur rattrapable d’une falsification indétectable.
- Disponibilité. Les ressources restent accessibles quand on en a besoin. Une sauvegarde dont la restauration n’a jamais été rejouée ne garantit rien.
À ces trois principes s’ajoutent les éléments qui font vivre le document : la classification des actifs, la gestion des accès à privilèges, la conduite à tenir en cas d’incident, les obligations des prestataires, et la fréquence de révision.
À qui et à quoi elle s’applique
Une PSSI couvre l’ensemble du système d’information, interne comme externalisé. Elle engage tous ceux qui le touchent : les salariés, mais aussi les prestataires, les partenaires et les intérimaires. Et elle couvre tous les supports, des serveurs aux téléphones personnels utilisés pour consulter la messagerie.
C’est le point le plus souvent négligé. Une politique qui ne dit rien des accès de votre infogéreur laisse ouvert le chemin d’attaque le plus court vers votre environnement. La question à trancher dans le document est simple : qui, chez votre prestataire, peut accéder à quoi, et qui le vérifie.
Six étapes pour écrire la vôtre
1. Faire l’état des lieux
Avant d’écrire une règle, il faut savoir ce qu’on protège. Un audit identifie les actifs critiques : données clients et financières, infrastructures et applications métier, équipements et terminaux mobiles. Sans cette étape, la politique protège ce qu’on imagine plutôt que ce qui compte.
2. Fixer les objectifs et les priorités
Tout ne peut pas être critique. Hiérarchiser suppose d’accepter des risques, explicitement, plutôt que de les ignorer implicitement. C’est l’objet d’une analyse de risques, et la méthode publiée par l’ANSSI, EBIOS Risk Manager, existe précisément pour rendre ces arbitrages traçables. Une PSSI qui ne renonce à rien n’a pas été écrite, elle a été recopiée.
3. Rédiger les règles et les procédures
La politique d’accès d’abord : quels rôles, quelles autorisations, quelles restrictions, et comment sont gérés les mots de passe. Puis les procédures d’incident, de sauvegarde et de mise à jour. Chaque règle doit désigner un responsable nommé, faute de quoi elle n’est appliquée par personne.
4. Déployer les mesures techniques
C’est seulement ici qu’interviennent les outils : durcissement des postes et du tenant, détection et réponse, journalisation conservée, sauvegardes testées, cloisonnement du réseau. Ils servent les règles, ils ne les remplacent pas.
5. Écrire une charte pour les utilisateurs
La PSSI s’adresse aux équipes techniques et à la direction. La charte informatique, elle, s’adresse à tout le monde : ce qui est autorisé, ce qui ne l’est pas, et ce qu’il faut faire en cas de doute. Une politique que les utilisateurs n’ont jamais lue ne change rien à leur comportement.
6. Réviser, et le prouver
Une PSSI figée vieillit en quelques mois. Ce qui déclenche sa révision n’est pas le calendrier seul, c’est l’analyse de risques : elle seule dit ce qui a changé dans la menace, dans votre activité et dans vos moyens. Une mesure devenue accessible rend inacceptable un risque que vous aviez légitimement accepté. En pratique, on révise au moins une fois par an, après chaque incident significatif et à chaque changement d’architecture. La révision doit laisser une trace datée : c’est elle, et non le document lui-même, qui démontre que la politique est vivante.
Cette page vous a aidé ? C’est notre métier.
- Support 8h-20h · 7j/7
- SOC 24/7
- < 10 min
- Équipe dédiée
Ce que le régulateur en attend
Pour une société de gestion ou tout acteur soumis à DORA, la PSSI n’est plus un document de bonne volonté. Elle est le cadre auquel se rattachent les obligations concrètes du règlement : gestion du risque lié aux tiers, détection et notification des incidents, tests de résilience, continuité d’activité.
Et l’exigence a changé de nature. En 2026, l’ACPR ne demande plus si la politique existe, elle demande de montrer qu’elle est appliquée : journaux, tickets horodatés, comptes rendus de revue, restaurations testées. Nous l’avons détaillé dans ce que veut dire passer de « où en êtes-vous ? » à « montrez-moi ».
C’est aussi la logique des systèmes de management : une PSSI est le cœur d’un dispositif ISO 27001, dont l’essentiel n’est pas la liste des contrôles mais la capacité à prouver qu’ils étaient en place à une date donnée.
Les quatre erreurs qui rendent une PSSI inutile
La copier. Un modèle trouvé en ligne décrit l’entreprise de quelqu’un d’autre. Il ne cite ni vos applications métier, ni votre infogéreur, ni vos contraintes réglementaires, et il se voit immédiatement en audit.
L’écrire sans la direction. Une politique arbitre des priorités et engage des budgets. Rédigée par la seule équipe technique, elle n’a pas l’autorité nécessaire pour être appliquée quand elle dérange.
Oublier les prestataires. Vos accès délégués sont un périmètre à part entière. S’ils ne figurent pas dans le document, ils ne sont contrôlés par personne.
Ne jamais la relire. Une PSSI datée de trois ans qui décrit une infrastructure disparue est pire qu’une absence de politique : elle donne l’illusion d’une maîtrise.
Check-list
- État des lieux réalisé et actifs critiques identifiés
- Objectifs fixés et risques acceptés, explicitement
- Règles et procédures écrites, chacune avec un responsable nommé
- Mesures techniques déployées et vérifiées
- Charte utilisateurs diffusée et signée
- Accès des prestataires couverts par le document
- Date de prochaine révision fixée, et preuve de la précédente conservée
Se faire aider
Écrire une PSSI demande du temps et une connaissance précise de l’infrastructure. Chez ITAIA, nous fournissons le socle technique qui la rend applicable et démontrable : durcissement, supervision, journalisation conservée, sauvegardes testées, gestion tracée des accès à privilèges. Par indépendance, nous ne réalisons ni l’audit ni le test d’intrusion sur les environnements que nous exploitons.
Pour situer votre niveau avant d’écrire quoi que ce soit, lancez le pré-diagnostic : trois minutes, sans inscription. La suite se discute en 30 minutes avec un ingénieur, sans engagement.
Pour aller plus loin
La PSSI n’est pas le seul document attendu : voir qui rédige quoi entre la politique, la charte informatique, le plan de continuité et le dispositif de crise.
La PSSI se met en œuvre avec des mesures concrètes : les bonnes pratiques cybersécurité, le durcissement de la sécurité et notre approche de la cybersécurité. Pour les sociétés régulées, elle s’articule avec les exigences DORA : voir la FAQ conformité.