L'Architecture de Documentation : Ce qui Doit Exister, Ce qui Doit Être Prouvé et Ce qui Tue les Certifications
"Si ce n'est pas écrit, ça n'existe pas."
- Premier principe de l'auditeur
Introduction : Le Paradoxe de la Documentation
Il existe une tension au cœur de la documentation ISO 27001 que chaque praticien finit par affronter. La norme exige de l'information documentée - politiques, procédures, enregistrements, preuves - comme mécanisme par lequel le SMSI démontre qu'il est opérationnel plutôt qu'aspirationnel.
Et pourtant, la cause la plus fréquente de dégradation du SMSI après la certification n'est pas un échec de sécurité. C'est un échec de documentation - un SMSI qui produit des montagnes de papier, consomme une énorme énergie organisationnelle à le maintenir, et échoue quand même à satisfaire les auditeurs parce que la documentation raconte l'histoire d'un SMSI qui était planifié plutôt que d'un SMSI qui fonctionne.
Le paradoxe se résout quand on comprend à quoi sert réellement la documentation. La documentation ISO 27001 n'est pas une archive de conformité. C'est la mémoire d'un système de management - le mécanisme par lequel une organisation capture ses décisions de sécurité, préserve le raisonnement qui les sous-tend, communique les attentes aux personnes qui doivent y donner suite, et démontre aux parties prenantes internes et externes que les promesses de sécurité qu'elle fait sont soutenues par la réalité opérationnelle.
Partie 1 - Le Cadre de la Clause 7.5
1.1 Ce qu'ISO 27001 Exige Réellement
La Clause 7.5 d'ISO 27001:2022 établit les exigences pour l'information documentée. La norme utilise deux termes distincts qui ont des significations différentes :
Information documentée est le terme générique pour tout ce que le SMSI produit et maintient par écrit - politiques, procédures, plans, enregistrements, preuves.
La distinction entre maintenir et conserver est opérationnellement importante :
-
Maintenir - documents qui décrivent comment les choses doivent être faites ou quelles décisions ont été prises. Ce sont des documents vivants - ils doivent être gardés à jour, révisés périodiquement et mis à jour quand la situation qu'ils décrivent change. Les politiques sont maintenues. Les procédures sont maintenues. Le registre des risques est maintenu.
-
Conserver - enregistrements qui prouvent que les choses ont été faites. Ce sont des documents historiques - une fois créés, ils ne doivent pas être modifiés, et ils doivent être préservés pendant une période définie. Les enregistrements de complétion de formation sont conservés. Les constatations d'audit sont conservées. Les procès-verbaux de revue de direction sont conservés.
La plupart des échecs de documentation du SMSI impliquent de confondre ces deux catégories : traiter les documents vivants comme s'ils étaient des enregistrements immuables (ne jamais mettre à jour les politiques), ou traiter les enregistrements comme des documents vivants (amender les constatations d'audit après coup).
1.2 Les Trois Exigences de la Clause 7.5.2
Pour chaque élément d'information documentée, ISO 27001 exige qu'il soit :
Approprié au contexte - le format, le niveau de détail et le support doivent être adaptés à l'objet que le document sert et à l'audience qui l'utilisera.
Disponible et adapté à l'usage - le document doit être accessible aux personnes qui en ont besoin, au moment où elles en ont besoin, dans la forme qu'elles peuvent utiliser. Un plan de réponse aux incidents stocké sur le réseau qu'un attaquant actif vient de chiffrer n'est pas disponible au moment où on en a le plus besoin.
Adéquatement protégé - la documentation elle-même doit être protégée contre la perte, l'accès non autorisé et la modification inappropriée. Le registre des risques contient des informations sensibles sur les vulnérabilités et les risques résiduels de l'organisation.
1.3 Contrôle de l'Information Documentée (Clause 7.5.3)
Le système de gestion documentaire minimal viable comprend :
- Un registre de documents listant tous les documents du SMSI
- Un processus d'approbation
- Un contrôle de version
- Des contrôles d'accès
- Un calendrier de révision
- Un processus pour retirer les documents obsolètes
Partie 2 - Les Documents Obligatoires
ISO 27001 exige explicitement certaines informations documentées. Ce sont des éléments non négociables - un audit de Phase 2 cherchera chacun d'eux, et leur absence ou inadéquation constitue une non-conformité.
2.1 La Liste Complète des Documents Obligatoires
| Document | Clause | Catégorie | Description |
|---|---|---|---|
| Périmètre du SMSI | 4.3 | Maintenir | Définit les limites du SMSI |
| Politique de sécurité de l'information | 5.2 | Maintenir | Engagement et principes de haut niveau |
| Processus d'évaluation des risques | 6.1.2 | Maintenir | Méthodologie, critères et approche |
| Critères d'acceptation des risques | 6.1.2 | Maintenir | Seuils pour l'acceptation du risque résiduel |
| Résultats de l'évaluation des risques | 6.1.2 | Conserver | Résultats de chaque exercice d'évaluation des risques |
| Plan de traitement des risques | 6.1.3 | Maintenir | Actions de traitement planifiées, propriétaires, calendriers |
| Déclaration d'Applicabilité | 6.1.3 | Maintenir | Tous les contrôles de l'Annexe A - inclus, exclus, justifiés |
| Objectifs de sécurité de l'information | 6.2 | Maintenir | Objectifs mesurables et plans pour les atteindre |
| Preuves de compétence | 7.2 | Conserver | Enregistrements démontrant que les compétences requises existent |
| Preuves de communication | 7.4 | Conserver | Enregistrements que les exigences de communication ont été satisfaites |
| Planification et contrôle opérationnels | 8.1 | Maintenir | Plans et processus documentés pour les opérations |
| Résultats de l'évaluation des risques | 8.2 | Conserver | Enregistrements de chaque évaluation des risques effectuée |
| Résultats du traitement des risques | 8.3 | Conserver | Enregistrements des décisions et approbations de traitement des risques |
| Résultats de surveillance et mesure | 9.1 | Conserver | Preuves que la surveillance se produit et est analysée |
| Programme d'audit interne | 9.2 | Maintenir | Le calendrier et le périmètre d'audit |
| Résultats de l'audit interne | 9.2 | Conserver | Constatations, preuves et conclusions de chaque audit |
| Résultats de la revue de direction | 9.3 | Conserver | Procès-verbaux et décisions de la revue de direction |
| Non-conformités et actions correctives | 10.1 | Conserver | Enregistrements de toutes les non-conformités et leur résolution |
2.2 La Déclaration d'Applicabilité - L'Empreinte Digitale du SMSI
La DdA mérite une attention particulière car elle est simultanément l'un des documents les plus importants du SMSI, l'un des plus fréquemment incompris et l'un des plus souvent cités dans les non-conformités d'audit.
La DdA est le document qui rend le SMSI ISO 27001 unique à l'organisation qui le détient. Un SoA bien construit est une articulation complète de l'approche de sécurité basée sur les risques de l'organisation - pourquoi elle a les contrôles qu'elle a, pourquoi elle n'a pas les contrôles qu'elle n'a pas.
Structure d'une DdA conforme :
Pour chacun des 93 contrôles de l'Annexe A, la DdA doit enregistrer :
- La référence et le titre du contrôle - comme indiqué dans l'Annexe A d'ISO 27001:2022
- Détermination d'applicabilité - ce contrôle est-il applicable au SMSI ? (Oui/Non)
- Justification d'inclusion ou d'exclusion :
- Pour les contrôles inclus : référence aux risques spécifiques que le contrôle traite
- Pour les contrôles exclus : justification documentée expliquant pourquoi le contrôle n'est pas applicable
- Statut d'implémentation - pour les contrôles inclus : implémenté, partiellement implémenté, planifié
- Référence aux documents d'implémentation
Exigence critique : "Non applicable" et "N/A" ne sont pas des justifications d'exclusion. Une exclusion sans justification substantielle est une non-conformité. La justification doit expliquer pourquoi le contrôle n'est pas applicable.
Exclusions légitimes courantes :
- Contrôle 7.10 (Supports de stockage) : exclu pour une organisation qui opère entièrement dans des environnements cloud sans support physique dans le périmètre
- Contrôle 8.30 (Développement externalisé) : exclu pour une organisation qui développe tout logiciel en interne
- Certains contrôles physiques (7.1–7.6) : peuvent être exclus pour les organisations qui externalisent toute infrastructure physique à des fournisseurs de centres de données certifiés
La DdA doit être à jour. Chaque fois que l'évaluation des risques est mise à jour, la DdA doit être révisée.
Partie 3 - Politiques et Procédures : L'Ensemble de Documents Vivants
3.1 L'Architecture du Cadre de Politique
Couche 1 - La Politique de Sécurité de l'Information : Un document concis (généralement 2–4 pages), approuvé par la haute direction, qui énonce l'engagement de l'organisation envers la sécurité de l'information.
Couche 2 - Politiques Thématiques : Politiques détaillées pour des domaines de sécurité spécifiques qui traduisent les principes de haut niveau en exigences opérationnelles.
Couche 3 - Procédures : Guides opérationnels étape par étape pour des activités spécifiques.
3.2 L'Ensemble de Politiques Principal
Pour la plupart des organisations, l'ensemble de politiques minimal cohérent comprend :
Politique de Sécurité de l'Information (Couche 1) Le document de fondation.
Politique de Contrôle d'Accès Qui peut accéder à quoi, sur quelle base, via quel processus d'approbation et avec quel cycle de révision.
Politique de Gestion des Actifs Comment les actifs informationnels sont identifiés, classifiés, détenus, protégés et éliminés.
Politique de Cryptographie L'approche de l'organisation pour la protection cryptographique - algorithmes approuvés, interdits, gestion des clés.
Politique de Sécurité Physique et Environnementale Contrôles d'accès physiques, exigences de protection environnementale, bureau propre et écran propre.
Politique de Sécurité des Fournisseurs Exigences pour l'évaluation de la sécurité des fournisseurs, exigences contractuelles minimales.
Politique de Gestion des Incidents Comment les incidents sont identifiés, signalés, classifiés, escaladés, gérés et révisés.
Politique de Continuité des Activités et Résilience TIC
Politique de Sécurité des Ressources Humaines
Politique de Développement Sécurisé (pour les organisations qui développent des logiciels)
3.3 Ce que Signifie une Bonne Politique
Elle est spécifique à l'organisation. Elle aborde les actifs réels, les menaces, les exigences réglementaires et le profil de risque de l'organisation.
Elle est rédigée pour son audience. Différentes politiques ont différentes audiences.
Elle est actionnable. Chaque exigence dans la politique peut être opérationnalisée.
Elle est cohérente avec les autres politiques et avec la réalité opérationnelle.
Elle est détenue et datée. Chaque politique doit avoir un propriétaire identifié, un numéro de version, une date d'entrée en vigueur, une date de révision et un enregistrement d'approbation.
Partie 4 - Enregistrements et Preuves : Prouver que le SMSI Fonctionne
4.1 Le Problème des Preuves
La cause la plus fréquente d'échec de certification - plus fréquente que les documents manquants, plus fréquente que les lacunes de contrôle - est l'absence de preuves que le SMSI fonctionne réellement.
La différence est la preuve. Un SMSI implémenté produit des enregistrements comme sous-produit naturel de son fonctionnement - les revues de direction produisent des procès-verbaux, les évaluations des risques produisent des registres mis à jour, les formations produisent des enregistrements de complétion. Un SMSI documenté produit des politiques et procédures qui décrivent des activités qui ne se produisent pas.
Le test pratique est simple : pour n'importe quelle activité du SMSI, l'organisation peut-elle produire des enregistrements qui démontrent que l'activité a eu lieu - pas des enregistrements créés pour l'audit, mais des enregistrements créés quand l'activité a été effectuée ?
4.2 Le Calendrier de Preuves
Activités mensuelles produisant des preuves :
- Revue des indicateurs de sécurité
- Résultats des analyses de vulnérabilité
- Échantillonnage de révision d'accès
- Revue du journal des incidents
- Surveillance des incidents de sécurité des fournisseurs
Activités trimestrielles produisant des preuves :
- Révision et mise à jour du registre des risques
- Sessions de sensibilisation ou simulations de phishing
- Revue des enregistrements de gestion des changements
- Reporting des indicateurs de performance clés à la haute direction
Activités annuelles produisant des preuves :
- Évaluation complète des risques
- Programme d'audit interne
- Revue de direction
- Cycle de révision des politiques
- Révision de la DdA
- Tests de récupération de continuité des activités et de sauvegarde
- Révision des fournisseurs
- Complétion de la formation de sensibilisation à la sécurité
Activités déclenchées par des événements produisant des preuves :
- Déploiement de nouveaux systèmes
- Changement organisationnel significatif
- Incident de sécurité
- Défaillance de contrôle ou constatation d'audit
- Nouvelle exigence réglementaire ou exigence modifiée
4.3 Ce que les Auditeurs Recherchent Réellement
Le document dit-il ce qu'il doit dire ? Pour les documents obligatoires, les auditeurs vérifient que les éléments requis sont présents.
La preuve démontre-t-elle le fonctionnement, pas seulement l'existence ?
Y a-t-il une cohérence temporelle ? Les enregistrements d'un SMSI genuinement opérationnel montrent une activité tout au long de la période d'audit.
Les enregistrements sont-ils connectés les uns aux autres ? Dans un SMSI authentique, les enregistrements forment un récit connecté.
Les décisions sont-elles expliquées ?
Partie 5 - Les Échecs de Documentation qui Tuent les Certifications
5.1 Catégorie 1 : Le Document Manquant
L'échec le plus simple - un document obligatoire qui n'existe tout simplement pas. Le plus courant :
Pas de Déclaration d'Applicabilité. Une DdA qui couvre uniquement les contrôles que l'organisation a implémentés, sans traiter les contrôles qu'elle a exclus, n'est pas conforme.
Pas de méthodologie d'évaluation des risques documentée.
Pas de plan de traitement des risques documenté.
Pas d'enregistrements d'audit interne.
Pas d'enregistrements de revue de direction.
5.2 Catégorie 2 : Le Document Obsolète
L'évaluation des risques de 2019. L'évaluation n'a pas été mise à jour depuis. L'organisation a adopté des services cloud, ajouté le travail à distance, changé sa base de fournisseurs - rien de cela n'est reflété dans le registre des risques.
La politique qui date d'avant la technologie. La politique de sécurité de l'information fait référence à des serveurs sur site et au travail en bureau. L'organisation est maintenant cloud-native et entièrement à distance.
La DdA qui ne reflète pas les contrôles actuels.
5.3 Catégorie 3 : Le Document qui ne Correspond pas à la Réalité
La politique que personne ne suit. La politique de contrôle d'accès exige des révisions d'accès trimestrielles. Aucune révision d'accès n'a été effectuée.
La procédure qui décrit le mauvais processus. La procédure de réponse aux incidents a été rédigée pour une ancienne pile technologique.
Les enregistrements de formation qui ne correspondent pas à la formation.
5.4 Catégorie 4 : Le SMSI Sans Preuves
Le registre d'incidents perpétuellement vierge. Un registre d'incidents qui ne montre aucun incident sur plusieurs années n'est pas la preuve d'une sécurité exceptionnelle - c'est la preuve que la culture de signalement des incidents n'existe pas.
La revue de direction qui ne couvre rien. Des procès-verbaux de revue de direction qui enregistrent la présence et notent que "la sécurité de l'information a été discutée" sans spécificités ne sont pas la preuve d'une revue de direction conforme à la Clause 9.3.
L'audit sans constatations. Un audit interne qui conclut sans constatations, sans observations et sans opportunités d'amélioration n'est pas crédible.
Partie 6 - Construire un Système de Documentation Lean et Efficace
6.1 L'Ensemble de Documentation Minimum Viable
Pour la plupart des petites et moyennes organisations, cet ensemble peut être maintenu dans un espace partagé avec des contrôles d'accès appropriés, sans logiciel GRC spécialisé.
6.2 La Hiérarchie de Documentation en Pratique
Niveau 1 - Documents stratégiques (changent rarement, nécessitent l'approbation de la direction) : Politique de sécurité de l'information, déclaration de périmètre du SMSI, stratégie et objectifs de sécurité.
Niveau 2 - Documents de politique (changent annuellement ou lors d'événements significatifs) : Politiques thématiques. Déclaration d'Applicabilité.
Niveau 3 - Documents de procédure (changent plus fréquemment à mesure que les systèmes et processus évoluent) : Procédures étape par étape pour des activités spécifiques.
Niveau 4 - Enregistrements opérationnels et preuves (créés en continu à mesure que le SMSI fonctionne) : Résultats d'évaluation des risques, constatations d'audit, enregistrements d'incidents, enregistrements de complétion de formation.
6.3 Les Responsabilités du Propriétaire de Document
Exactitude : Le propriétaire veille à ce que le document décrive avec précision ce qu'il est censé décrire.
Mise à jour : Le propriétaire veille à ce que le document soit révisé à sa date de révision prévue.
Communication : Le propriétaire veille à ce que les changements apportés au document soient communiqués aux personnes qui agissent en conséquence.
Disponibilité : Le propriétaire veille à ce que le document soit accessible à ceux qui en ont besoin.
6.4 Outillage GRC : Quand Investir et à Quoi S'Attendre
Investissez dans un outil GRC quand :
- L'organisation a un SMSI complexe, multi-sites
- Le volume d'information documentée est suffisamment large pour que le contrôle de version manuel soit sujet aux erreurs
- L'organisation a plusieurs cadres de conformité qui se chevauchent
- Le registre des risques a des centaines de risques
N'investissez pas dans un outil GRC pour :
- Faire paraître un SMSI simple plus sophistiqué
- Remplacer la discipline organisationnelle requise pour maintenir le SMSI
- Impressionner les auditeurs qui évalueront le contenu, pas le logiciel
Partie 7 - Documentation pour des Activités SMSI Spécifiques
7.1 Documenter les Évaluations des Risques
Un enregistrement d'évaluation des risques doit contenir :
- Date de l'évaluation et participants
- Périmètre de l'évaluation
- Référence à la méthodologie
- Risques identifiés avec des descriptions suffisamment spécifiques
- Scores de probabilité et d'impact
- Détermination du niveau de risque
- Décisions de traitement avec approbation du propriétaire du risque
- Détermination du risque résiduel
- Date de la prochaine révision prévue
7.2 Documenter la Revue de Direction
Entrées requises de la revue de direction :
- Statut des actions des revues de direction précédentes
- Changements dans les problèmes externes et internes pertinents pour le SMSI
- Retour sur la performance de la sécurité de l'information
- Retour des parties intéressées
- Résultats de l'évaluation des risques et statut du traitement
- Opportunités d'amélioration continue
Sorties requises de la revue de direction :
- Décisions sur les opportunités d'amélioration continue
- Tout changement au SMSI
- Décisions sur les objectifs de sécurité de l'information
7.3 Documenter les Audits Internes
L'ensemble de documentation d'audit interne comprend :
Le programme d'audit : Le calendrier annuel des activités d'audit.
Les plans d'audit : Pour chaque audit individuel, un plan précisant le périmètre, les objectifs, les critères, les méthodes et le calendrier.
Les enregistrements de preuves d'audit : Notes, observations et preuves documentées recueillies pendant l'audit.
Les rapports d'audit : Enregistrements formels des constatations d'audit, incluant les zones conformes, les non-conformités et les opportunités d'amélioration.
Les enregistrements d'actions correctives : Pour chaque non-conformité, un enregistrement de la correction, de l'analyse des causes profondes, de l'action corrective et de la vérification de l'efficacité.
7.4 Documenter les Incidents
Un enregistrement d'incident doit contenir :
- Identifiant de l'incident et date/heure de détection
- Date/heure d'occurrence (si différente de la détection - le temps de présence)
- Classification par catégorie et gravité
- Description de l'incident
- Chronologie de la réponse
- Analyse des causes profondes
- Actions de confinement, d'éradication et de récupération
- Communications - notifications aux régulateurs, clients, forces de l'ordre
- Enseignements tirés et mises à jour du registre des risques
- Actions correctives pour prévenir la récurrence
Partie 8 - Maturité de la Documentation : Le Chemin d'Évolution
8.1 Niveaux de Maturité de la Documentation
Niveau 1 - Réactif : La documentation existe pour satisfaire des exigences immédiates. Les politiques ont été rédigées pour la certification. Elle se dégrade progressivement entre les audits.
Niveau 2 - Défini : Un ensemble complet de documentation existe et est maintenu. Les cycles de révision sont définis et respectés.
Niveau 3 - Opérationnel : La documentation est un sous-produit naturel du fonctionnement du SMSI. Les enregistrements de preuves sont créés quand les activités se produisent.
Niveau 4 - Intégré : Le système de documentation est intégré avec les outils opérationnels. La documentation reflète l'état en temps réel du SMSI.
Niveau 5 - Optimisé : La documentation est continuellement améliorée. Les indicateurs de qualité de la documentation sont suivis.
La plupart des organisations atteignent le Niveau 2 lors de la certification initiale. Le Niveau 3 est la cible pratique pour un SMSI genuinement opérationnel.
Résumé : Ce que le Chapitre 5 a Établi
La documentation est la mémoire du SMSI. Pour bien faire, il faut comprendre la distinction entre ce qui doit être maintenu (documents vivants) et ce qui doit être conservé (enregistrements historiques), entre ce que la norme exige explicitement et ce que l'efficacité opérationnelle demande, et entre la documentation qui sert la conformité et la documentation qui sert la sécurité.
Les 18 documents obligatoires représentent le fondement non négociable. Leur absence constitue une non-conformité.
La DdA est l'empreinte digitale du SMSI - le document qui rend la certification spécifique à l'organisation et démontre la logique basée sur les risques derrière chaque décision de contrôle.
Les preuves distinguent un SMSI qui existe sur le papier d'un qui fonctionne en pratique. Le calendrier de preuves est le mécanisme pratique par lequel les preuves sont générées de façon routinière plutôt qu'assemblées frénétiquement.
Suivant : Chapitre 6 - Opérer le SMSI à l'Échelle : Gestion des Actifs, Contrôle des Changements, Risque Fournisseurs et Réponse aux Incidents en Mouvement
© ISO 27001 Wiki - Pour les RSSI, Analystes de Sécurité et Professionnels GRC