Cartographier un jeu de politiques pour plusieurs référentiels

Un schéma courant : une entreprise rédige un jeu de politiques pour ISO 27001, puis un client demande SOC 2 et quelqu'un achète un second pack de modèles, puis PCI DSS arrive avec ses propres exigences. Trois jeux de politiques qui se chevauchent, chacun légèrement périmé, aucun ne correspondant à ce que les gens font réellement. Les politiques n'ont pas besoin d'être propres à un référentiel. Elles doivent être propres à l'organisation, et mises en correspondance.

Structure : trois niveaux

1. Une politique de sécurité de l'information : courte, approuvée par la direction, énonçant les objectifs, le périmètre, les responsabilités et l'engagement. La clause 5.2 d'ISO 27001 et la PCI DSS 12.1.1 l'exigent toutes deux.
2. Politiques thématiques (une douzaine environ) : contrôle d'accès, utilisation acceptable, gestion des actifs, cryptographie, réponse aux incidents, continuité d'activité, sécurité des fournisseurs, développement sécurisé, gestion des vulnérabilités et des correctifs, journalisation et surveillance, sécurité physique, sécurité des ressources humaines.
3. Procédures et normes en dessous, où figurent les fréquences, paramètres et étapes. Elles évoluent plus souvent et ne devraient pas nécessiter une validation de la direction à chaque fois.

Placez les détails propres à un référentiel dans les procédures, et non dans les politiques : « les accès sont revus tous les six mois » relève de la procédure de revue des accès, où la fréquence exigée par PCI DSS peut figurer sans alourdir la politique.

Cartographier, ne pas réécrire

Tenez un tableau de correspondance : une ligne par section de politique, avec les exigences qu'elle couvre dans chaque référentiel. Le sujet Gouvernance et politiques indique ce que chaque référentiel attend au plus haut niveau :

Référentiel	Politique de gouvernance	Lien
NIST CSF 2.0	GV.PO-01GV.PO-02	Définition du sujet
ISO 27001	A.5.1A.5.37Clause 5.2	Correspondance
CIS v8.1	—	Aucune correspondance dans nos données
SOC 2	CC5.3CC1.1	Éditorial
PCI DSS	12.1.112.1.2	Correspondance
CMMC	—	Aucune correspondance dans nos données
800-53	PM-1PL-1	Correspondance
HIPAA	§164.316(a)§164.316(b)(2)(iii)	Correspondance
GDPR	Art.24(2)	Éditorial
NIS2	1.1	Correspondance
Essential Eight	—	Aucune correspondance dans nos données

Détail complet et raison de chaque lien : Politique de gouvernance dans les référentiels →

Lorsqu'un nouveau référentiel arrive, réalisez une analyse d'écarts et examinez les exigences de gouvernance et de politiques : la plupart correspondront à une politique que vous possédez déjà ; les autres deviendront de nouvelles sections ou procédures.

Ce que les référentiels exigent précisément par écrit

• ISO 27001 : une politique de sécurité de l'information (5.2) et des politiques thématiques au besoin (A.5.1), communiquées et revues.
• SOC 2 : des politiques qui définissent les attentes, déployées au moyen de procédures (CC5.3).
• PCI DSS : pour chacune de ses douze exigences, des politiques et procédures documentées et à jour (x.1.1) et des rôles attribués (x.1.2), revus au moins annuellement.
• NIS2 : une politique relative à la sécurité des réseaux et systèmes d'information et des politiques thématiques (règlement d'application, point 1).
• NIST CSF 2.0 : la politique est établie, communiquée et appliquée (GV.PO).

Un jeu minimal de politiques

Pour la plupart des petites et moyennes organisations, ces documents couvrent les exigences en matière de politiques d'ISO 27001, SOC 2, NIST CSF, PCI DSS et NIS2 :

1. Politique de sécurité de l'information (niveau supérieur, approuvée par la direction)
2. Politique d'utilisation acceptable
3. Politique de contrôle d'accès
4. Politique de gestion des actifs et de classification des données
5. Politique de cryptographie
6. Politique de développement sécurisé et de gestion des changements
7. Politique de gestion des vulnérabilités et des correctifs
8. Politique de journalisation et de surveillance
9. Politique de réponse aux incidents (avec obligations de notification)
10. Politique de continuité d'activité et de sauvegarde
11. Politique de sécurité des fournisseurs
12. Politique de sécurité des ressources humaines
13. Politique de sécurité physique

Treize documents, pour la plupart de quelques pages, chacun avec un responsable et une date de revue. Les procédures portent le détail et évoluent plus souvent.

Points clés

• Les politiques doivent être propres à l'organisation et mises en correspondance, et non propres à un référentiel.
• Placez les fréquences et paramètres dans les procédures.
• Treize politiques courtes couvrent la plupart des référentiels.
• PCI DSS exige que ses politiques et procédures soient revues au moins annuellement.

Les maintenir exactes

• Écrivez ce que vous faites, et non ce qu'indique un modèle. Les auditeurs testent les politiques par rapport à la pratique.
• Revoyez annuellement, et après tout changement significatif, avec une approbation consignée.
• Court vaut mieux que complet : une politique de contrôle d'accès de deux pages que les gens lisent vaut mieux que vingt pages que personne ne lit.

Pour un jeu de contrôles commun construit sur la même idée, voir un jeu de contrôles commun pour SOC 2 et ISO 27001.

Questions

Combien de politiques de sécurité faut-il ?

Moins que ne le suggèrent la plupart des modèles. Une politique de sécurité de l'information de niveau supérieur, accompagnée d'une douzaine de politiques thématiques (accès, utilisation acceptable, réponse aux incidents, sécurité des fournisseurs, etc.), couvre généralement ISO 27001, SOC 2, NIST et PCI DSS.

PCI DSS exige-t-il des politiques spécifiques ?

Oui. Chaque exigence PCI DSS commence par une exigence de politiques et procédures documentées et à jour pour ce domaine (x.1.1), ainsi que par les rôles et responsabilités (x.1.2).