Pourquoi ISO 27001 repose autant sur les politiques
ISO 27001 est une norme de management, pas une checklist technique. Les auditeurs ne se soucient pas de la qualité de votre pare-feu — ils veulent savoir si vous avez décidé comment le configurer, si vous l'avez écrit, communiqué, revu, et si vous prouvez l'avoir appliqué. Les politiques documentées sont le tissu conjonctif qui transforme des pratiques de sécurité éparses en un système de management défendable.
La révision 2022 (ISO/IEC 27001:2022) a réorganisé l'Annexe A : de 114 mesures réparties en 14 domaines, on passe à 93 mesures regroupées en quatre thèmes — Organisationnel (37), Personnes (8), Physique (14) et Technologique (34) — avec 11 mesures réellement nouvelles, comme le renseignement sur les menaces, la sécurité du cloud et la prévention des fuites de données. Les exigences des chapitres 4 à 10, qui pilotent votre documentation, n'ont en revanche pas changé d'esprit : elles disent précisément ce que vous devez écrire.
Deux types de documents « obligatoires »
Un point qui piège la plupart des débutants : ISO 27001 comporte deux obligations documentaires distinctes, et les confondre est une cause fréquente de frictions en audit.
- Informations documentées obligatoires — explicitement exigées par les chapitres 4 à 10, quel que soit votre périmètre. Cela inclut le périmètre du SMSI (4.3), la politique de sécurité de l'information (5.2), le processus d'appréciation et de traitement du risque (6.1.2–6.1.3), la Déclaration d'applicabilité (DdA / SoA) (6.1.3 d), les objectifs de sécurité (6.2), les preuves de compétence (7.2) et les enregistrements de surveillance, audit interne et revue de direction (9.1–9.3). L'absence de l'un d'eux constitue une non-conformité majeure — point.
- Politiques liées aux mesures de l'Annexe A — la mesure 5.1 de l'Annexe A exige des « politiques de sécurité de l'information » définies et approuvées. La norme ne vous impose pas une liste figée de titres ; elle attend les politiques thématiques que votre analyse de risque justifie. Les 14 ci-dessous sont la base pratique que rédige quasiment tout SaaS.
Autrement dit : la *politique de sécurité de l'information* est obligatoire nommément ; les treize autres le sont *de fait*, car les mesures 5.1, 5.15, 8.24 et consorts exigent que ces sujets soient encadrés par une politique approuvée.
Les 14 politiques de base, mappées à l'Annexe A:2022
| # | Politique | Mesure Annexe A:2022 principale |
|---|---|---|
| 1 | Politique de sécurité de l'information | 5.1 |
| 2 | Politique d'usage acceptable | 5.10, 8.1 |
| 3 | Politique de contrôle d'accès | 5.15, 5.16, 5.18 |
| 4 | Politique de mots de passe / authentification | 5.17, 8.5 |
| 5 | Politique de cryptographie & gestion des clés | 8.24 |
| 6 | Politique de sauvegarde | 8.13 |
| 7 | Politique antivirus / protection des postes | 8.1, 8.7 |
| 8 | Politique de gestion des changements | 8.32 |
| 9 | Politique de réponse aux incidents | 5.24, 5.25, 5.26 |
| 10 | Politique de continuité d'activité | 5.29, 5.30 |
| 11 | Politique de classification des données | 5.12, 5.13 |
| 12 | Politique fournisseurs | 5.19, 5.20, 5.21 |
| 13 | Politique de télétravail | 6.7 |
| 14 | Politique réseau & accès à distance | 8.20, 8.21, 8.22 |
Vous pouvez retenir un ensemble plus restreint, mais chaque exclusion doit être justifiée dans la Déclaration d'applicabilité. En pratique, retirer l'une de ces quatorze appelle des questions qu'un auditeur préférerait vous voir anticiper.
Anatomie d'une politique qui passe l'audit
Une politique qui survit à un audit n'est pas la plus longue — c'est celle qui répond aux trois questions de l'auditeur dès sa première page. Prenons une politique de contrôle d'accès comme exemple :
- Objet & périmètre — un paragraphe : quels systèmes, quelles identités, quels environnements.
- Les règles concrètes — moindre privilège par défaut ; accès accordé uniquement via une demande tracée approuvée par le propriétaire des données ; MFA obligatoire sur tout accès admin exposé sur Internet ; revues d'accès trimestrielles ; révocation sous 24 h après un départ.
- Rôles — qui approuve l'accès, qui réalise la revue trimestrielle, qui possède la politique.
- Bloc d'approbation — nom, rôle, version, date d'approbation.
- Date de revue — prochaine revue planifiée et événements déclencheurs d'une revue anticipée.
Remarquez que les règles sont *précises et vérifiables*. « L'accès est contrôlé de manière appropriée » est inauditable. « L'accès est revu chaque trimestre et révoqué sous 24 h après un départ » donne à l'auditeur de quoi échantillonner vos dossiers RH et votre outil de tickets.
Ce que l'auditeur vérifie réellement
Pour chaque politique, l'auditeur pose trois questions — puis cherche la preuve :
- Approbation : qui l'a approuvée, quand, sur quelle version ? (Il demandera la signature ou l'enregistrement d'approbation.)
- Communication : comment les collaborateurs l'ont-ils découverte (email d'onboarding, intranet, accusé de réception) ? (Il interrogera quelques personnes.)
- Revue : quand a-t-elle été révisée pour la dernière fois, annuellement ou après un changement majeur ? (Il vérifiera que la date n'est pas périmée.)
Si vous ne pouvez pas répondre aux trois, la politique est non-conforme — même si son contenu est parfait. C'est pourquoi un historique de modifications documenté et infalsifiable compte plus qu'une belle rédaction.
Maintenir l'ensemble après la certification
La certification suit un cycle de trois ans, avec des audits de surveillance en années 1 et 2 et une recertification en année 3. Le moyen le plus rapide de perdre le certificat est de figer les politiques le lendemain de l'audit de stage 2. Prévoyez :
- Une revue annuelle de chaque politique, plus une revue hors cycle dès qu'une mesure change de façon notable.
- Une revue de direction au moins annuelle qui réexamine objectifs, incidents, résultats d'audit et plan de traitement du risque (chapitre 9.3).
- Une Déclaration d'applicabilité vivante — à chaque adoption ou retrait de mesure, la DdA et la politique concernée évoluent ensemble.
Sources primaires à lire
- ISO/IEC 27001:2022 — la norme elle-même (iso.org/standard/27001).
- Guides de l'ENISA sur la gestion de la sécurité de l'information pour les PME (enisa.europa.eu).
- NIST SP 800-63B pour des exigences d'authentification modernes et fondées sur les preuves, bien alignées avec la mesure 8.5 (pages.nist.gov/800-63-3/sp800-63b.html).
Comment PolicyForge accélère cela
Chaque modèle PolicyForge est mappé à sa mesure précise de l'Annexe A:2022, fourni en français et en anglais, et inclut un bloc d'approbation, des notes de communication et un champ de date de revue. Vous générez les quatorze politiques de base en moins de 30 minutes et arrivez à votre audit avec la documentation déjà structurée comme un auditeur la lit.