ISO/IEC 27017:2015 a été révisée. La nouvelle version, ISO/IEC 27017:2026, est publiée officiellement depuis le 27 juillet.

Ce n’est pas un changement majeur mais plutôt un ajustement de la structure, avec quatre nouveaux contrôles qui vont toucher la façon dont vous évaluez vos fournisseurs.

J’avais couvert la première édition dans cet article en 2022.

ISO/IEC 27017 est un complément à ISO/IEC 27002 (la liste de contrôles de sécurité de l’information) spécifique à l’infonuagique. Elle s’adresse aux deux côtés de la relation : le CSC (cloud service customer, le client du service) et le CSP (cloud service provider, le fournisseur).

D’après mon expérience, la grande majorité des PME sont des CSC. Elles achètent Microsoft 365, un ERP hébergé ou un logiciel SaaS, elles ne vendent pas de service infonuagique. C’est la vision que je prends ici pour écrire.

Pourquoi ça a pris quatre ans de retard

ISO/IEC 27001:2022 a changé complètement l’annexe A il y a quatre ans : nouvelle structure en quatre thèmes (organisationnels, personnes, physiques, technologiques), nouveaux contrôles, nouvelle terminologie. ISO/IEC 27017 restait accrochée à la structure de la version 2013, avec ses quatorze domaines. La nouvelle édition corrige cela et s’aligne enfin sur ISO/IEC 27002:2022.

Concrètement, la norme reprend la même architecture que 27002:2022. Pour chaque contrôle qui a besoin d’une précision infonuagique, une section « guidance for cloud services » est ajoutée. Deux formats existent : le Type 1 sépare les recommandations pour le CSC et pour le CSP, le Type 2 donne une orientation commune aux deux. Quand un contrôle standard n’a besoin d’aucune précision, il n’y a qu’un renvoi à 27002:2022. Le texte est donc plus léger que la version 2015, qui répétait beaucoup.

Quatre nouveaux contrôles infonuagiques (préfixe CLD)

C’est la partie qui va réellement demander du travail. Quatre contrôles étendus, identifiés « CLD », sont ajoutés.

CLD 5.38 — Rôles et responsabilités partagés

Les rôles et responsabilités partagés entre vous et votre fournisseur infonuagique doivent être définis : qui gère les correctifs de sécurité, qui gère les sauvegardes, qui répond en cas d’incident.

Dans beaucoup de contrats SaaS que j’ai vus, cette répartition reste implicite ou noyée dans 40 pages de conditions d’utilisation.

Pour vous conformer :

  • demandez à votre fournisseur une description écrite de ses capacités de sécurité (authentification, chiffrement, sauvegardes, journalisation) ;
  • confirmez que vous êtes capable de remplir la part qui vous revient ;
  • faites inscrire cette répartition des rôles dans votre entente de service, pas seulement dans une page web de conditions d’utilisation.

CLD 5.39 — Partenaire de service infonuagique (CSN)

Un accord sur les rôles et responsabilités du partenaire de service infonuagique, ce que la norme appelle un CSN. Si votre fournisseur sous-traite une partie de l’hébergement ou du support à un tiers, cette chaîne doit être couverte, pas seulement le premier maillon.

Une note sur l’acronyme CSN, parce que je me suis posé la même question en le lisant la première fois : ça veut dire « cloud service partner », le partenaire du service infonuagique. Le C et le S suivent la logique de CSC et CSP, mais le P était déjà pris par le fournisseur (provider), alors la norme a choisi CSN pour le partenaire, sans expliquer pourquoi cette lettre plutôt qu’une autre. La norme ISO/IEC 22123-3 précise trois rôles possibles pour un CSN : développeur de service infonuagique, auditeur infonuagique et courtier de service infonuagique.

Pour vous conformer :

  • demandez à votre fournisseur principal s’il utilise des partenaires ou des sous-traitants pour livrer le service ;
  • assurez-vous que l’entente que vous avez avec lui reste cohérente avec le partage de rôles de CLD 5.38 une fois ce tiers ajouté dans l’équation.

CLD 8.35 — Ségrégation dans les environnements virtuels

La ségrégation dans les environnements de calcul virtuel : la garantie que vos données ne se mélangent pas avec celles d’un autre client sur la même infrastructure partagée.

Pour vous conformer :

  • vous ne pourrez pas tester ça vous-même sur un service SaaS ;
  • demandez à votre fournisseur ses attestations existantes (certification ISO 27001, rapport SOC 2) comme preuve que cette séparation entre clients est réellement en place.

CLD 8.36 — Utilisation non autorisée de services infonuagiques

La détection et la prévention de l’utilisation non autorisée de services infonuagiques. Dans mes audits, je vois régulièrement une équipe qui ouvre un compte SaaS avec une carte de crédit corporative sans en parler à personne. Ce contrôle vise exactement ça.

Pour vous conformer :

  • suivez les activités de vos utilisateurs ;
  • révisez périodiquement par rapport à votre politique d’utilisation de l’infonuagique ;
  • détectez les anomalies, comme une hausse inexpliquée de l’utilisation d’un service.

Pour une PME, ça commence par un inventaire simple des services infonuagiques réellement utilisés, révisé de temps en temps plutôt qu’une seule fois.

Nouveau vocabulaire, portée élargie

La norme reconnaît maintenant qu’une PME utilise rarement un seul fournisseur infonuagique. Elle nomme les différents montages possibles (infonuagique privé, public, multi-fournisseurs, hybride) et décrit trois façons de les gérer : vous orchestrez vous-même vos différents services, un fournisseur en combine plusieurs pour vous, ou plusieurs fournisseurs s’associent entre eux pour livrer le service. Le point pratique à retenir : si vous combinez Microsoft 365, un hébergeur infonuagique et un logiciel SaaS tiers, la norme couvre maintenant explicitement cette réalité au lieu de présumer un fournisseur unique.

La portée s’élargit aussi : la norme précise qu’elle s’applique à tous les modèles de déploiement, y compris l’infonuagique privé, avec un ajustement possible quand un même département agit à la fois comme client et comme fournisseur à l’interne. Un nouveau chapitre 4 couvre les relations fournisseurs en infonuagique et renvoie explicitement à ISO/IEC 27036-4 pour la sécurité de la chaîne d’approvisionnement infonuagique, un sujet que la version 2015 traitait à peine.

Deux annexes, pas trois

Certaines analyses publiées pendant la phase de vote FDIS (Final Draft International Standard, la dernière étape avant publication) décrivaient une troisième annexe consacrée à la surveillance continue des services infonuagiques. En lisant le texte final publié le 27 juillet, ce n’est pas ce que je trouve. La norme publiée contient deux annexes, toutes deux informatives : l’annexe A est la table de correspondance complète avec l’édition 2015, l’annexe B couvre la surveillance des services infonuagiques.

Concrètement, l’annexe B explique que votre capacité à surveiller les événements de sécurité dépend du type de service que vous utilisez. Avec un SaaS comme Microsoft 365, votre capacité de surveillance reste limitée à ce que le logiciel vous montre lui-même : vous dépendez de ce que votre fournisseur accepte de vous partager, ce qui rejoint directement le partage de rôles de CLD 5.38 vu plus haut. Avec un service de type IaaS (infrastructure), vous avez accès à des outils de surveillance beaucoup plus étendus, incluant des outils de gestion de la posture de sécurité infonuagique. L’annexe mentionne aussi que la surveillance manuelle devient difficile à grande échelle et pousse vers des outils automatisés.

Ce que ça veut dire pour votre lecture : si vous êtes surtout client de logiciels SaaS, demandez à vos fournisseurs quels rapports ou journaux de sécurité ils vous rendent disponibles et faites inscrire cet engagement dans votre entente de service. Vous ne pourrez pas installer vos propres outils de surveillance sur leur infrastructure, votre seul levier est contractuel.

Calendrier de migration

Au Japon, la norme de certification basée sur la version 2015 est en révision, avec une publication prévue à l’automne 2026 et une transition de trois ans pour les organisations déjà certifiées. Le même rythme s’applique généralement ailleurs, la norme sort en premier, les standards de certification nationaux suivent quelques mois plus tard et la migration se compte ensuite en années, pas en mois.

En pratique

Voici ce que je recommande à mes clients qui utilisent ISO/IEC 27017 dans leur SGSI, peu importe où ils en sont :

  • Si 27017 fait partie de votre déclaration d’applicabilité (SoA), utilisez la table de correspondance de l’annexe A pour voir quels contrôles ont changé de numéro ou de contenu, avant votre prochain audit de surveillance.
  • Redemandez à vos fournisseurs infonuagiques principaux (SaaS, hébergement, infrastructure) s’ils ont un plan de transition vers la version 2026 et sur quel échéancier.
  • Reprenez les quatre blocs « Pour vous conformer » plus haut un par un avec vos fournisseurs actuels, ce sont eux qui vont réellement occuper votre temps.
  • Ne retardez pas une certification en cours pour attendre la nouvelle version. Les standards de certification nationaux prennent des mois à s’aligner et la migration qui suit se compte en années.

Minimalement, cette révision reste ce qu’elle a toujours été : un outil pour évaluer et documenter vos relations avec vos fournisseurs infonuagiques. La conformité reste votre responsabilité, pas celle de votre fournisseur infonuagique ni celle de votre consultant. Cette mise à jour est une occasion de revoir ces relations, pas une tâche à déléguer en entier.

Bref, quatre contrôles concrets à intégrer et un texte enfin aligné sur ISO/IEC 27002:2022. Le vrai travail sera de retourner voir vos contrats de service actuels et de vérifier si les rôles qu’ils décrivent tiennent encore la route.

Un audit s’en vient et vous n’êtes pas certain d’être prêt sur ce point? Parlons-en.