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.
Le périmètre décide de tout le reste : les actifs à inventorier, les risques à analyser, les personnes à former, les sites que l'auditeur visitera. Trop large, le projet s'enlise. Trop étroit, le certificat ne sert à rien commercialement.
La question à se poser : que veut voir le client qui exige le certificat ? Pour Factura, le groupement hospitalier veut l'assurance que ses factures et les données de ses fournisseurs sont protégées dans le SaaS. Il se moque de la sécurité du CRM commercial.
Trois options s'offrent à Factura :
| Option | Contenu | Avantage | Problème |
|---|---|---|---|
| Toute l'entreprise | Produit, ventes, RH, finance | Message clair | Charge maximale dès la première année |
| Le produit SaaS | Développement, exploitation, support | Couvre ce que le client achète | Interfaces avec le reste à gérer |
| L'hébergement seul | Infrastructure cloud | Rapide | Le client ne sera pas convaincu |
Factura choisit la deuxième option. Le périmètre s'écrit en une phrase, celle qui figurera sur le certificat :
Le système de management de la sécurité de l'information couvrant la
conception, le développement, l'hébergement, l'exploitation et le support
de la plateforme SaaS Factura, opérée depuis le site de Lyon et en
télétravail, conformément à la déclaration d'applicabilité version 1.2.Lisez toujours la phrase de périmètre d'un certificat fournisseur. Un « ISO 27001 » qui ne couvre que le datacenter d'un hébergeur ne dit rien sur la sécurité de son application.
Un périmètre partiel n'est pas une île. La norme demande d'identifier les interfaces et les dépendances avec ce qui est hors périmètre ou externe. Pour Factura :
Dans le périmètre
├── Équipe produit (développeurs, ops, support)
├── Plateforme SaaS (production, préproduction)
├── Dépôts GitHub, pipeline CI/CD
└── Outils de support (Zendesk, accès d'administration)
Interfaces avec le hors périmètre
├── Équipe commerciale → crée des comptes clients via le back-office
├── RH → arrivées et départs (création/suppression d'accès)
└── Finance → accès aux exports de facturation
Dépendances externes (fournisseurs)
├── Hébergeur cloud → infrastructure, sauvegardes
├── GitHub → code source, CI
├── Google Workspace → identités, messagerie
└── Prestataire d'envoi d'emailsL'interface RH est critique : si les départs ne sont pas signalés à l'équipe produit, un ancien salarié garde ses accès à la production. Le périmètre partiel n'excuse pas ce trou. Il faut une procédure qui traverse la frontière.
La clause 4.1 demande de lister les enjeux qui influencent la capacité du SMSI à atteindre ses résultats. Pas besoin d'un document de vingt pages. Un tableau clair suffit, à condition d'être revu chaque année :
| Type | Enjeu | Conséquence pour le SMSI |
|---|---|---|
| Externe | Clients publics et santé exigeants | Certification et engagements contractuels |
| Externe | Hausse des rançongiciels visant les PME | Sauvegardes hors ligne, détection |
| Externe | RGPD, données de facturation | Registre, sous-traitance, notification |
| Externe | Épisodes de canicule, risque sur le datacenter | Choix d'un hébergeur multi-zones (amendement 2024) |
| Interne | Pas de RSSI dédié | Rôle porté par le CTO, appui externe |
| Interne | Équipe à 60 % en télétravail | Sécurité des postes, accès distants |
| Interne | Croissance de 30 % par an | Onboarding rapide, gestion des accès |
L'amendement climatique de 2024 inquiète souvent pour rien. Il demande seulement de se poser la question. Pour un SaaS sans bureaux à risque, la réponse peut tenir en une ligne. Pour un hébergeur, elle touche le refroidissement et les sites de secours.
Même exercice pour la clause 4.2 : qui attend quoi du SMSI, et lesquelles de ces attentes le SMSI prend en charge.
| Partie intéressée | Exigences | Traitée par le SMSI |
|---|---|---|
| Clients | Confidentialité, disponibilité 99,9 %, notification d'incident sous 48 h | Oui |
| Autorité de protection des données | Conformité RGPD | Oui, en partie (le DPO pilote) |
| Salariés | Outils utilisables, respect de la vie privée | Oui |
| Hébergeur | Respect de ses conditions d'utilisation | Oui |
| Assureur cyber | Authentification forte, sauvegardes testées | Oui |
| Actionnaires | Continuité de l'activité | Oui |
La dernière colonne vient de la version 2022. Elle oblige à dire clairement ce qu'on ne couvre pas, ce qui évite les malentendus en audit.
ISO 27001 n'exige pas de RSSI à plein temps. Elle exige que les responsabilités soient attribuées et communiquées. Chez Factura :
| Rôle | Personne | Responsabilités |
|---|---|---|
| Sponsor | CEO | Valide la politique, les risques résiduels, le budget |
| Responsable du SMSI | CTO | Pilote le système, anime les revues |
| Propriétaires de risques | Lead dev, lead ops, responsable support | Décident du traitement des risques de leur domaine |
| Référent RGPD | DPO externe | Articulation avec la protection des données |
| Auditeur interne | Consultant externe | Audit interne annuel, indépendant de l'équipe |
Le propriétaire de risque est une notion importante : c'est la personne qui a l'autorité pour accepter un risque. Ce n'est pas forcément celle qui applique les mesures.
La clause 5.2 exige une politique de haut niveau, signée par la direction. Elle doit :
Une bonne politique tient sur deux pages. Voici la structure retenue par Factura :
# Politique de sécurité de l'information — Factura
Version 1.0 — approuvée par le CEO le 2026-02-03
## Pourquoi
Nos clients nous confient leurs données de facturation. Leur confiance
est notre actif principal.
## Notre engagement
- Protéger la confidentialité, l'intégrité et la disponibilité des données
clients selon une analyse des risques revue chaque année.
- Respecter nos obligations légales, réglementaires et contractuelles.
- Fournir les moyens nécessaires et améliorer le SMSI en continu.
## Objectifs (détaillés dans le tableau de bord du SMSI)
- Disponibilité de la plateforme ≥ 99,9 % par mois.
- 100 % des accès production protégés par authentification forte.
- Vulnérabilités critiques corrigées en moins de 7 jours.
- 100 % des salariés sensibilisés chaque année.
## Responsabilités
Chaque salarié applique les règles qui le concernent et signale tout
incident à securite@factura.example. Le CTO est responsable du SMSI.
## Politiques thématiques
Contrôle d'accès, développement sécurisé, sauvegarde, gestion des
incidents, usage acceptable, fournisseurs, télétravail.La politique de haut niveau reste stable. Les détails vivent dans des politiques thématiques (topic-specific policies), que la 27002 cite mesure par mesure : contrôle d'accès, cryptographie, sauvegarde, développement sécurisé… Elles changent plus souvent et sont approuvées par le niveau de management adapté.
La clause 6.2 demande des objectifs mesurables (si possible), surveillés, communiqués et mis à jour. Un objectif comme « améliorer la sécurité » ne passe pas l'audit. Pour chaque objectif, on précise :
Objectif : Vulnérabilités critiques corrigées en moins de 7 jours
Indicateur : délai médian entre l'alerte Dependabot/scan et la mise en prod
Source : tickets Jira étiquetés "vuln-critique"
Fréquence : mensuelle
Responsable : lead dev
Cible 2026 : 100 % < 7 jours ; actuel : 64 %
Actions : alerte Slack automatique, revue hebdo des dépendancesUn objectif non atteint n'est pas une non-conformité. Ne pas le suivre en est une.
Le périmètre est posé, la direction s'est engagée. Le chapitre suivant aborde le cœur de la norme : l'analyse de risques.