Comprendre et appliquer la norme ISO/IEC 27001:2022 : construire un SMSI, apprécier les risques, choisir les 93 mesures de l'annexe A, préparer les preuves et passer la certification.
Un auditeur ne croit que ce qu'il voit. « On fait des revues d'accès » ne vaut rien. Un ticket daté, avec l'export, les écarts trouvés et leur correction, vaut preuve. Ce chapitre couvre ce qui transforme un ensemble de bonnes pratiques en système auditable : la documentation, les indicateurs, les incidents, l'audit interne et la revue de direction.
La norme n'utilise plus les mots « procédure » ou « enregistrement ». Elle parle d'informations documentées, à tenir à jour (un document vivant) ou à conserver (une preuve). Voici ce qu'exigent les clauses 4 à 10 :
| Clause | Information documentée |
|---|---|
| 4.3 | Périmètre du SMSI |
| 5.2 | Politique de sécurité de l'information |
| 6.1.2 | Processus d'appréciation des risques |
| 6.1.3 | Processus de traitement des risques |
| 6.1.3 d | Déclaration d'applicabilité |
| 6.2 | Objectifs de sécurité |
| 7.2 | Preuves de compétence |
| 8.1 | Éléments montrant que les processus sont réalisés comme prévu |
| 8.2 | Résultats des appréciations des risques |
| 8.3 | Résultats du traitement des risques |
| 9.1 | Résultats de la surveillance et des mesures |
| 9.2 | Programme d'audit et résultats des audits internes |
| 9.3 | Résultats des revues de direction |
| 10.2 | Non-conformités, actions menées et leurs résultats |
À cela s'ajoutent les documents que vos mesures de l'annexe A rendent nécessaires : politiques thématiques, inventaire des actifs, registre des fournisseurs, procédure de gestion des incidents, plan de continuité. La norme dit simplement « les informations documentées jugées nécessaires à l'efficacité du SMSI ». C'est à vous de juger, mais l'auditeur jugera aussi.
La règle d'or : documenter ce que vous faites, pas ce que vous aimeriez faire. Une procédure de vingt pages copiée d'un modèle, que personne n'applique, est pire qu'une page fidèle. L'auditeur interroge les équipes, et l'écart entre le document et la pratique devient une non-conformité.
Factura a choisi un dépôt Git pour les documents du SMSI, publié en site interne :
smsi/
├── README.md # carte du SMSI, qui fait quoi
├── 01-contexte/
│ ├── perimetre.md
│ ├── enjeux-parties-interessees.md
│ └── roles-responsabilites.md
├── 02-politiques/
│ ├── politique-securite.md # signée par le CEO
│ ├── controle-acces.md
│ ├── developpement-securise.md
│ ├── sauvegarde.md
│ ├── incidents.md
│ └── fournisseurs.md
├── 03-risques/
│ ├── methode.md
│ ├── risques.yaml
│ └── declaration-applicabilite.csv
├── 04-registres/
│ ├── actifs.csv
│ ├── fournisseurs.csv
│ └── obligations-legales.md
└── 05-pilotage/
├── objectifs-indicateurs.md
├── audits/
└── revues-direction/Les pull requests jouent le rôle de circuit de validation. L'historique Git répond à l'exigence de maîtrise des versions de la clause 7.5. Pour une équipe moins technique, un wiki avec historique et workflow d'approbation fait le même travail.
Les preuves, elles, restent dans les outils où elles naissent : tickets Jira, journaux, rapports de CI, comptes rendus. Le SMSI n'a pas besoin de les copier, seulement de savoir où les trouver.
La clause 9.1 demande de décider quoi surveiller et mesurer, avec quelles méthodes, quand, et qui analyse les résultats. Le piège : définir trente indicateurs et n'en suivre aucun. Factura en suit huit, dans un tableau de bord mensuel :
| Indicateur | Cible | Source |
|---|---|---|
| Disponibilité mensuelle | ≥ 99,9 % | Sonde de supervision externe |
| Vulnérabilités critiques corrigées en < 7 jours | 100 % | Tickets étiquetés |
| Comptes avec authentification forte | 100 % | Export du fournisseur d'identité |
| Revues d'accès réalisées à temps | 4/4 par an | Tickets |
| Tests de restauration réussis | 12/12 par an | Tickets |
| Salariés sensibilisés dans l'année | 100 % | Plateforme de formation |
| Incidents de sécurité, délai moyen de clôture | Suivi, pas de cible | Registre des incidents |
| Actions du plan de traitement en retard | 0 | Tableau Jira |
Ces chiffres servent en revue de direction. Un indicateur qui ne déclenche jamais de décision peut être supprimé.
Les mesures 5.24 à 5.28 et 6.8 demandent une chaîne complète : signaler, qualifier, traiter, apprendre. Pour une PME, la procédure tient en une page :
Procédure de gestion des incidents — Factura
1. SIGNALER Toute personne signale un événement suspect sur #securite
ou securite@factura.example. Sans crainte de reproche.
2. QUALIFIER L'astreinte décide sous 1 h : événement sans suite,
incident mineur, incident majeur.
3. TRAITER Incident majeur : cellule (CTO, lead ops, CEO, DPO si
données personnelles). Contenir, éradiquer, restaurer.
4. NOTIFIER Données personnelles : évaluation DPO, notification CNIL
sous 72 h si nécessaire. Clients : selon contrats.
5. CONSERVER Journaux et éléments de preuve préservés avant remise en état.
6. APPRENDRE Retour d'expérience sous 15 jours, actions dans le plan
de traitement, mise à jour des risques.Un registre des incidents vide pendant un an éveille les soupçons de l'auditeur. Il prouve rarement l'absence d'incident, plus souvent l'absence de signalement. Enregistrez aussi les événements mineurs : un email de phishing signalé, un ordinateur perdu, une alerte écartée après analyse.
La clause 7.3 et la mesure 6.3 exigent que chacun connaisse la politique, sa contribution et les conséquences d'un manquement. L'auditeur le vérifie en posant des questions à des salariés pris au hasard : « Que faites-vous si vous recevez un email suspect ? Où est la politique de sécurité ? »
Chez Factura : une session à l'arrivée, un module annuel de 45 minutes, une campagne de phishing simulé par trimestre, et un rappel en réunion d'équipe après chaque incident notable. Les développeurs suivent en plus une formation annuelle au développement sécurisé, conservée comme preuve de compétence (7.2).
Les mesures 5.19 à 5.23 demandent d'évaluer les fournisseurs avant de les choisir, de prévoir des clauses de sécurité et de les suivre dans le temps. Le registre de Factura classe chaque fournisseur par criticité :
| Fournisseur | Données | Criticité | Preuves obtenues | Revue |
|---|---|---|---|---|
| Hébergeur cloud | Toutes | Critique | Certificat ISO 27001, attestation HDS, DPA | Annuelle |
| GitHub | Code source | Élevée | Rapport SOC 2, DPA | Annuelle |
| Suite bureautique | Emails, documents | Élevée | Certificat ISO 27001, DPA | Annuelle |
| Prestataire emails | Emails clients | Moyenne | Questionnaire, DPA | Tous les 2 ans |
Pour un fournisseur certifié, vérifiez la phrase de périmètre de son certificat et sa date de validité. Pour un fournisseur non certifié, un questionnaire court suffit, proportionné à la criticité.
La clause 9.2 exige un programme d'audits internes réalisés par des personnes objectives et impartiales. Un développeur ne peut pas auditer sa propre CI. Dans une PME, trois solutions :
Sur un cycle de trois ans, tout le SMSI doit être audité : clauses 4 à 10 et mesures applicables. La première année, avant la certification, il est fortement recommandé de tout couvrir. L'organisme de certification vérifiera qu'au moins un audit interne complet et une revue de direction ont eu lieu avant l'audit de certification.
Un audit interne qui ne trouve rien n'a pas fait son travail. Les écarts trouvés en interne sont une bonne nouvelle : ils seront corrigés avant que l'auditeur externe ne les trouve.
La clause 9.3 impose une revue par la direction à intervalles planifiés. Elle doit examiner une liste d'entrées précise :
Ordre du jour — revue de direction Factura (annuelle + point semestriel)
1. Suivi des actions de la revue précédente
2. Évolution des enjeux internes et externes
3. Évolution des besoins des parties intéressées
4. Retours sur la performance :
- non-conformités et actions correctives
- résultats de la surveillance et des mesures (tableau de bord)
- résultats des audits
- atteinte des objectifs de sécurité
5. Retours des parties intéressées (clients, auditeurs, assureur)
6. Résultats de l'appréciation des risques, état du plan de traitement
7. Opportunités d'amélioration
Décisions attendues : acceptation des risques résiduels, ressources,
modifications du SMSI, nouveaux objectifs.Le compte rendu doit montrer des décisions. Une revue qui se contente de « prendre acte » ne démontre pas l'engagement de la direction.
La clause 10.2 demande, pour chaque non-conformité : réagir pour la maîtriser, analyser la cause, décider d'une action corrective, vérifier son efficacité. La différence entre correction et action corrective est classique en audit :
Non-conformité : un développeur parti il y a 3 mois a toujours accès à GitHub.
Correction : compte retiré le jour même.
Cause : le départ a été signalé à la console cloud mais GitHub
n'était pas relié au fournisseur d'identité.
Action corrective : SSO imposé sur l'organisation GitHub, comptes locaux
interdits ; ajout de GitHub à la checklist de départ.
Vérification : revue d'accès suivante sans écart (2026-07-01). Close.Corriger sans chercher la cause, c'est garantir que le problème reviendra. C'est aussi le signe que l'auditeur cherche pour juger de la maturité d'un SMSI.
Le dernier chapitre accompagne Factura jusqu'à l'audit de certification.