5.2 — Politique de sécurité de l’information

Le document le plus souvent téléchargé, le moins souvent lu dans le SGSI de la plupart des entreprises — et pourtant ses quatre contenus requis sont exactement ce qu’un auditeur vérifie en premier.

En langage clair

La 5.2 exige que la direction établisse une politique de sécurité de l’information qui correspond réellement à votre organisation, fixe ou encadre vos objectifs de sécurité, s’engage à satisfaire vos exigences applicables, et s’engage à l’amélioration continue — puis s’assure qu’elle est documentée, communiquée à l’interne, et accessible aux parties intéressées le cas échéant.

Pourquoi cette exigence existe

Une politique générique téléchargée d’un modèle et légèrement modifiée signale à un auditeur — et à votre propre personnel — que la sécurité est une formalité de conformité plutôt qu’une chose que l’organisation prend réellement au sérieux. Cette exigence force la politique à dire quelque chose d’assez précis pour ne pouvoir appartenir qu’à votre organisation, pas à n’importe quelle entreprise de votre industrie.

Scénario : un employé qui doit décrire la politique de sécurité de l’entreprise ne peut dire que « on en a une, je pense qu’elle est sur l’intranet quelque part ». La politique existe, satisfaisant techniquement l’exigence de documentation, mais l’exigence de communication — que le personnel sache réellement qu’elle existe et ce qu’elle dit en gros — n’a manifestement pas été respectée.

Ce que la norme attend

La norme attend que la direction établisse une politique de sécurité de l’information appropriée à la finalité de l’organisation ; incluant des objectifs de sécurité de l’information, ou fournissant le cadre pour les fixer ; incluant un engagement à satisfaire les exigences applicables liées à la sécurité de l’information ; et incluant un engagement à l’amélioration continue du SGSI. La politique doit être disponible en tant qu’information documentée, communiquée au sein de l’organisation, et accessible aux parties intéressées le cas échéant.

En pratique

• Garder la politique courte et lisible — un énoncé d’intention d’une à deux pages, pas un manuel technique de contrôles (cela appartient à des procédures distinctes).
• Faire référence à votre industrie réelle, votre posture de risque et vos priorités stratégiques plutôt qu’un langage de sécurité générique qui pourrait appartenir à n’importe quelle entreprise.
• La communiquer activement — une étape d’accueil, un affichage interne, un rappel périodique — plutôt que de la classer en espérant que le personnel la trouve.
• Décider délibérément quelle version externe, le cas échéant, est partagée avec les clients ou partenaires qui la demandent.

Preuves que l’auditeur demandera

• Le document de politique actuel et approuvé, daté et sous contrôle de version.
• Une preuve de communication interne — une liste de vérification d’accueil, un affichage intranet, un registre d’accusé de réception.
• Des entretiens aléatoires avec le personnel confirmant qu’il est au moins conscient que la politique existe et de ce qu’elle couvre globalement.

Pièges courants

• Une politique générique tirée d’un modèle, sans référence à la finalité ou au contexte réels de l’organisation.
• Une politique classée sur un intranet sans étape de communication active, de sorte que le personnel ne peut démontrer en avoir conscience.
• Une politique qui n’a pas été mise à jour depuis la certification malgré des changements significatifs au périmètre, au contexte ou aux objectifs.

Exigences liées

• 5.1 Leadership et engagement — l’alignement stratégique que cette politique est censée refléter.
• 6.2 Objectifs de sécurité — les cibles mesurables que cette politique fixe ou encadre.
• 7.3 Sensibilisation — là où le personnel apprend réellement ce que dit cette politique et pourquoi elle compte.
• Clause parente : Clause 5 · Leadership