Presque toutes les entreprises disposent d’une politique de sécurité de l’information. Les difficultés commencent au moment de prouver que quelqu’un l’a réellement lue, qu’elle est revue à intervalles réguliers et que son contenu correspond à ce qui est effectivement configuré sur les postes de travail des collaborateurs. C’est le premier document que réclame un auditeur, et aussi celui que l’on copie le plus et que l’on adapte le moins bien.

Dans cet article, nous voyons ce qu’est exactement une politique de sécurité de l’information, quelles réglementations l’imposent, quelles rubriques elle doit contenir, comment l’élaborer étape par étape et quelles sont les erreurs les plus fréquentes lors de sa rédaction.

Qu’est-ce qu’une politique de sécurité de l’information ?

La politique de sécurité de l’information est le document approuvé par la direction dans lequel une organisation déclare son engagement à protéger l’information et fixe les principes qui vont régir cette protection. Elle définit le périmètre, attribue les responsabilités et pose le cadre dans lequel seront prises ensuite les décisions techniques et organisationnelles. En France, on la désigne le plus souvent par l’acronyme PSSI, pour politique de sécurité des systèmes d’information.

C’est un document de haut niveau. Il n’explique ni comment configurer un pare-feu ni tous les combien de jours un mot de passe expire. Il fixe le quoi et le pourquoi, et laisse le comment aux règles et aux procédures qui en découlent. C’est la raison pour laquelle une politique bien rédigée dépasse rarement quatre ou cinq pages.

Elle couvre l’ensemble de l’information de l’organisation, quel qu’en soit le support. Les données des systèmes internes, la documentation papier, les informations partagées avec les prestataires et celles qui circulent lors de conversations ou sur des supports amovibles entrent toutes dans le même périmètre.

Politique de sécurité de l’information et politiques de sécurité, est-ce la même chose ?

C’est la confusion la plus courante et mieux vaut la lever tout de suite. Au singulier, on parle du document cadre, celui que signe la direction et dont dépendent tous les autres. Au pluriel, on parle des politiques thématiques, celles qui déclinent chaque domaine et que les équipes appliquent réellement au quotidien.

La hiérarchie documentaire comporte en général trois niveaux.

Politique générale : document cadre approuvé par la direction, court et stable dans le temps.
Politiques thématiques : contrôle d’accès, usage des équipements, télétravail, sauvegardes, classification de l’information, gestion des incidents ou développement sécurisé, entre autres.
Procédures et enregistrements : le détail opérationnel de chaque politique et la preuve qu’elle a bien été appliquée.

À quoi sert une politique de sécurité de l’information ?

Sa fonction première est de donner une direction. Lorsqu’une situation imprévue se présente, la politique est le critère auquel on se réfère pour trancher. Sans elle, chaque service se débrouille comme il peut et les décisions de sécurité finissent par dépendre de la personne disponible ce jour-là.

Elle remplit par ailleurs quatre fonctions concrètes.

Elle rend visible l’engagement de la direction : la sécurité cesse d’être une affaire de service informatique pour devenir un sujet porté au plus haut niveau.
Elle répartit les responsabilités : chaque rôle sait ce qui lui incombe et à qui remonter l’information.
Elle rend l’exigence opposable en interne : sans règle communiquée et acceptée, il est difficile de reprocher son non-respect à un collaborateur.
Elle soutient l’ensemble du dispositif : les politiques thématiques, les procédures et les mesures techniques s’appuient sur elle et s’y justifient.

S’y ajoute un usage de plus en plus fréquent en dehors de l’organisation. Les grands comptes et les acheteurs publics réclament la politique de sécurité lors des processus de référencement fournisseur, et de nombreux assureurs la demandent avant d’émettre un contrat de cyberassurance.

Quel est l’impact de la politique de sécurité de l’information sur la certification ISO 27001 ?

L’ISO 27001 est la norme internationale qui certifie les systèmes de management de la sécurité de l’information, et la politique conditionne cette certification dès le départ. Son absence est éliminatoire, car l’exigence 5.2 appartient au corps de la norme et n’admet aucune exclusion dans la déclaration d’applicabilité. Sans politique approuvée par la direction, aucune certification n’est possible.

Sa qualité donne le ton du reste de l’audit. La mesure A.5.1 exige que la politique soit approuvée, publiée, communiquée, reconnue par les personnes concernées et revue à intervalles réguliers. Comme les politiques thématiques et les procédures s’appuient sur elle, une faiblesse à ce niveau entraîne des non-conformités en cascade. Son périmètre délimite par ailleurs celui du certificat, puisque ce qui n’est pas couvert par le document reste hors du système.

L’ISO 27001 n’est pas la seule à l’imposer. La directive NIS2 ouvre sa liste de mesures minimales par les politiques relatives à la sécurité des systèmes d’information, l’ANSSI en fait le socle de sa méthodologie d’élaboration d’une PSSI, et le RGPD impose de documenter les mesures organisationnelles appliquées aux traitements de données.

Que doit contenir une politique de sécurité de l’information ?

Il n’existe pas de sommaire obligatoire. En revanche, certaines rubriques reviennent dans presque toutes les politiques qui passent un audit avec succès.

1. Objet et périmètre

L’objet explique la raison d’être du document et doit s’aligner sur les objectifs de l’entreprise. Le périmètre est la partie la plus négligée et celle qui pose le plus de problèmes par la suite. Il doit délimiter précisément les processus, les sites, les systèmes, les actifs et les personnes couverts.

Un périmètre mal défini produit deux effets. Trop large, l’entreprise s’engage à protéger ce qu’elle ne maîtrise pas. Trop étroit, la certification perd de sa valeur auprès de clients qui s’attendaient à voir l’ensemble de l’activité couverte.

2. Principes et engagement de la direction

On y consigne les principes qui orientent la sécurité dans l’organisation. Les plus courants sont la gestion par les risques, la sécurité par défaut, le moindre privilège, la défense en profondeur et l’amélioration continue.

L’engagement de la direction doit être explicite et vérifiable. Il comprend l’allocation de moyens, l’approbation formelle du document et la participation à la revue périodique du système. Une déclaration d’intention générique, sans budget associé ni signature identifiable, n’apporte pas grand-chose.

3. Rôles et responsabilités

La politique définit qui fait quoi. Au minimum, on y trouve le responsable de la sécurité des systèmes d’information, le comité de sécurité lorsqu’il existe, les propriétaires de chaque actif ou processus et les obligations générales de l’ensemble des collaborateurs.

Chaque rôle doit être assorti de missions concrètes. Il est utile de préciser aussi les interactions avec la protection des données, avec le DPO lorsqu’il y en a un et avec les responsables RH, car les arrivées et les départs déclenchent des tâches de sécurité qui restent souvent sans propriétaire.

4. Politiques thématiques de référence

La politique générale énumère les politiques spécifiques qui la déclinent et indique où les consulter. Les plus fréquentes portent sur le contrôle d’accès, l’usage acceptable des ressources, les terminaux mobiles et le BYOD, le télétravail, la classification et le traitement de l’information, les sauvegardes, la cryptographie, la gestion des incidents, la relation avec les prestataires et le développement sécurisé.

Inutile de les décrire. Il suffit de les lister, d’indiquer leur propriétaire et de donner une référence documentaire claire.

5. Dérogations et conséquences en cas de non-respect

Toute politique se heurte tôt ou tard à un cas dans lequel une mesure ne peut pas s’appliquer. Le document doit préciser qui peut accorder une dérogation, sur quelle justification, pour quelle durée et où elle est consignée.

Les conséquences d’un non-respect doivent figurer explicitement, dans les limites autorisées par le droit du travail. Sans cette rubrique, l’organisation perd toute capacité de réaction face à un manquement grave.

6. Gestion des versions et approbation

Une politique sans gestion des versions est une politique inauditable. La page de garde ou le pied de page doit mentionner le numéro de version, la date d’approbation, l’instance qui approuve, l’auteur, la date de la prochaine revue et un historique des modifications.

Cette rubrique paraît secondaire et fait partie des premières que consulte un auditeur. Elle lui permet de vérifier en trente secondes si le système est vivant ou si le document n’a pas bougé depuis quatre ans.

Comment élaborer une politique de sécurité de l’information ?

Rédiger le document est la partie la plus courte du travail. Ce qui lui donne sa substance, c’est ce qui se passe avant et après.

1. Inventorier les actifs et analyser les risques

La politique protège des actifs précis, la première étape consiste donc à savoir lesquels. L’inventaire doit recenser les postes de travail, les serveurs, les applications et services cloud, les données, les supports et les personnes qui y ont accès. Dans un parc réparti entre les bureaux et le télétravail, cette photographie ne reste à jour que si elle est prise automatiquement.

Une fois l’inventaire en main, on identifie les menaces et les vulnérabilités, on évalue leur probabilité et leur impact, puis on décide quels risques sont acceptés, réduits, transférés ou évités. En France, la méthode EBIOS Risk Manager publiée par l’ANSSI sert de référence pour cette étape. Les principes qui figureront dans la politique en découlent, et c’est ce qui distingue un document propre à l’entreprise d’un modèle téléchargé.

2. Rédiger et faire approuver le document

La rédaction doit rester compréhensible par l’ensemble des collaborateurs, y compris ceux qui n’ont pas de profil technique. Des phrases courtes, un glossaire en fin de document et aucun terme qui ne puisse s’expliquer en une ligne.

L’approbation relève de la direction, avec une date et une signature identifiable. Dans les organisations dotées d’un comité de sécurité, l’usage veut que le comité propose le texte et que la direction l’approuve formellement en séance.

3. La communiquer et enregistrer son acceptation

Déposer la politique dans un dossier partagé ne revient pas à la communiquer. La norme demande que les personnes concernées en accusent réception, il faut donc pouvoir prouver que chacune l’a reçue et acceptée, avec une date.

La solution la plus simple consiste à l’intégrer à l’onboarding. Le collaborateur reçoit le document à son arrivée, l’accepte de façon dématérialisée et cet enregistrement rejoint son dossier. Lorsque la politique change de version, l’acceptation est redemandée à l’ensemble des équipes. Cet historique est exactement ce que l’on vous demandera lors d’un audit.

4. La revoir et la mettre à jour

La revue s’effectue à intervalles planifiés, en général une fois par an dans le cadre de la revue de direction. Elle intervient également à l’occasion de changements significatifs, comme une fusion, une évolution d’infrastructure, l’entrée dans un nouveau cadre réglementaire ou un incident de sécurité majeur.

Chaque revue laisse une trace, même en l’absence de modification. Consigner que le document a été revu à une date précise et maintenu en l’état constitue également une preuve recevable.

Exemple de politique de sécurité de l’information

De nombreuses organisations publient leur politique en libre accès, ce qui donne un bon aperçu du ton et de la longueur réels. Deux constantes s’en dégagent. Le document dépasse rarement cinq pages, et la quasi-totalité comporte un tableau de gestion des versions en première ou en dernière page.

Le sommaire type d’une politique de sécurité de l’information ressemble à ceci.

Objet et champ d’application
Cadre réglementaire de référence
Principes de sécurité de l’information
Engagement de la direction
Organisation de la sécurité, rôles et responsabilités
Gestion des risques
Règles et politiques spécifiques de déclinaison
Formation et sensibilisation
Gestion des incidents
Conformité, dérogations et régime disciplinaire
Revue et gestion des versions

Cette trame sert de point de départ. Le contenu de chaque rubrique n’a de valeur que s’il découle de l’analyse de risques de l’organisation elle-même.

Erreurs fréquentes lors de la rédaction d’une politique de sécurité de l’information

Les politiques qui échouent en audit reproduisent souvent les mêmes erreurs.

Reprendre un modèle sans adapter le périmètre : on y trouve des sites qui n’existent pas, des services que l’entreprise n’a jamais eus ou des systèmes jamais déployés. Un auditeur le repère dès la première lecture et examine ensuite le reste du dispositif avec plus de méfiance.
La faire approuver par le service informatique plutôt que par la direction : la norme demande que ce soit la direction qui l’établisse. Une politique signée du seul responsable technique ne répond pas à l’exigence et donne le sentiment que la sécurité n’est pas portée au plus haut niveau.
Confondre politique et procédure : si le document fixe la longueur minimale des mots de passe ou la fréquence des sauvegardes, chaque ajustement opérationnel oblige à le faire réapprouver par la direction. La politique cesse d’être mise à jour et se décale du réel en quelques mois.
Oublier les prestataires et les intervenants externes : beaucoup de politiques ne visent que les salariés et laissent de côté les indépendants, la sous-traitance et les prestataires qui accèdent aux systèmes. C’est l’une des portes d’entrée les plus courantes et l’un des points les plus regardés en audit.
Ne pas pouvoir prouver que les équipes en ont connaissance : le document existe, il est approuvé et publié, mais personne ne peut attester de qui l’a lu. Sans enregistrement de l’acceptation, l’exigence de communication et de reconnaissance n’est pas satisfaite.
Un écart entre le texte et la configuration réelle des postes : la politique annonce le chiffrement des disques, le verrouillage automatique et des mots de passe robustes, et l’examen du parc montre qu’une partie des équipements ne remplit aucune de ces trois conditions. C’est l’erreur la plus lourde de conséquences, car elle transforme une non-conformité mineure en non-conformité majeure.

Appliquez votre politique de sécurité de l’information avec Factorial IT

Une politique n’a d’utilité que si ce qu’elle annonce est réellement appliqué sur les postes et que cette application peut être prouvée. Plus le processus est manuel, plus le document et la réalité s’éloignent l’un de l’autre.

Factorial IT enrôle les équipements de l’entreprise et leur applique les règles de chiffrement, de verrouillage d’écran et de mots de passe sur Mac, Windows et Linux, sans avoir à passer poste par poste. La politique est transmise et acceptée dès l’onboarding, et cette acceptation est enregistrée avec sa date dans le dossier de chaque collaborateur.

plateforme factorial it

Résultat, la politique s’appuie désormais sur un état des lieux qui indique quels équipements respectent chaque mesure et qui a accepté le document.

Politique de sécurité de l’information : comment l’élaborer