Pourquoi la sécurité du cloud des MSP s'est-elle effondrée du jour au lendemain ?
La sécurité du cloud des MSP a été compromise lorsque les plateformes cloud ont cessé d'être de simples fournisseurs pour devenir des environnements à responsabilité partagée nécessitant une gouvernance active. La norme ISO 27001 A.5.23 formalise ce changement en exigeant que vous maîtrisiez la sélection, l'utilisation et la sortie des services cloud conformément à votre SMSI, au lieu de vous fier uniquement aux certifications des fournisseurs. Cette exigence reflète le libellé de la norme ISO 27001:2022 A.5.23 et les recommandations générales en matière de sécurité du cloud, qui mettent l'accent sur des processus définis pour l'acquisition, l'utilisation, la gestion et la sortie des services cloud, plutôt que sur la seule confiance dans les garanties des fournisseurs, comme le soulignent les commentaires relatifs à la norme ISO 27001 A.5.23.
Les services cloud permettent à votre MSP de croître rapidement, mais ils ont également mis en lumière des lacunes en matière de propriété, de gouvernance et de traçabilité que l'ancien modèle de fournisseur n'avait pas à résoudre. Lorsque les clients et les auditeurs demandent désormais qui est responsable de quoi dans le cloud, l'affirmation « c'est le fournisseur qui s'en charge » ne suffit plus. La norme A.5.23 cristallise cette tension en exigeant une approche contrôlée et documentée de l'utilisation du cloud, plutôt que des choix de plateformes improvisés.
Le cloud ne devient un avantage pour les MSP que lorsque la responsabilité est partagée délibérément, et non présumée.
Le cloud a dépassé votre ancienne mentalité de « fournisseur ».
Le cloud ne se résume plus à la simple signature d'un contrat, à la confiance accordée à un certificat et à la garantie que la sécurité s'arrête au niveau du fournisseur. Pour les fournisseurs de services gérés (MSP), la norme A.5.23 impose de prendre conscience que la gestion des identités, des configurations et des opérations quotidiennes sur chaque plateforme relève désormais de leur responsabilité.
De nombreux fournisseurs de services gérés (MSP) traitent encore les fournisseurs de cloud comme des fournisseurs traditionnels, et c'est précisément là que l'article 5.23 montre ses limites. Pendant des années, il suffisait de signer un contrat, de faire confiance aux certifications, d'ajouter un système de surveillance et de continuer. Cela fonctionnait lorsque le cloud se limitait à l'hébergement de messagerie ou à quelques machines virtuelles.
Aujourd'hui, des catalogues de services entiers s'exécutent sur des plateformes hyperscale, vos ingénieurs disposant de pouvoirs d'administration étendus et d'outils d'automatisation permettant d'interagir simultanément avec des dizaines de clients. Dans ce contexte, l'idée que « la sécurité est gérée par le fournisseur » n'est plus d'actualité. Le fournisseur de cloud sécurise son infrastructure et ses services essentiels, mais vous gérez les identités, les configurations, les intégrations et une grande partie de la résilience opérationnelle. Les clients en sont de plus en plus conscients et attendent de vous que vous leur expliquiez comment les responsabilités partagées sont définies et comment votre équipe met en œuvre ces contrôles au quotidien.
Le point A.5.23 de la norme souligne explicitement ce changement. Il exige que vous passiez d'une assurance fournisseur générique à une gouvernance active de la manière dont les plateformes cloud prennent en charge vos services et vos clients.
La complexité cachée de votre pile cloud actuelle
La complexité cachée de votre infrastructure cloud ne devient évidente que lorsqu'on la décrit par écrit. Un inventaire concis et ciblé révèle généralement bien plus de services, de flux de données et de rôles d'administrateur que prévu, ce que la norme A.5.23 vous invite précisément à identifier et à gérer de manière réfléchie.
La plupart des fournisseurs de services gérés (MSP) découvrent qu'ils gèrent beaucoup plus de services, et de bien plus de façons, que ce que l'on imaginait :
- Outils SaaS internes pour la collaboration, la billetterie, la gestion de la relation client (CRM) et la finance.
- Plateformes de cloud public alimentant les services d'infrastructure gérée, de sauvegarde, de surveillance et de sécurité.
- Outils cloud de niche choisis par des équipes ou des ingénieurs pour résoudre des problèmes spécifiques.
Ensemble, ces services créent un réseau complexe de données, de rôles d'administrateur, de journaux et de modes de défaillance. Sans vue centralisée, les risques s'accumulent insidieusement : un ingénieur détient les droits d'administrateur global pour plusieurs locataires, un outil SaaS « temporaire » devient critique pour l'entreprise, un service de sauvegarde n'a jamais été testé en conditions réelles de restauration. Une plateforme de gestion de la sécurité de l'information (SGSI) comme ISMS.online vous permet de maintenir cette vue centralisée et d'éviter que cette complexité ne reste cachée.
Pour concrétiser ce changement, il est utile de comparer l'ancienne mentalité des fournisseurs avec la gouvernance du cloud attendue par la version A.5.23.
Une brève comparaison montre comment votre approche doit évoluer :
| Aspect | Ancien modèle de fournisseur | A.5.23 Gouvernance du cloud pour les MSP |
|---|---|---|
| Point de vue du fournisseur | « La sécurité est assurée par un fournisseur de confiance. » | « Partenaire dans un modèle de responsabilité partagée défini. » |
| Portée du contrôle | Contrat plus surveillance de base | Cycle de vie complet : sélection, utilisation, modification, sortie |
| Preuves que vous détenez | Certificats et contrats | Registres, fiches de risques, matrices, artefacts de cycle de vie |
| Propriété au sein du MSP | Implicite, dépendant de la personne | Intégration explicite des rôles, des manuels d'exploitation et du SMSI |
Une fois que vous avez analysé votre situation sous cet angle, il devient plus facile de déterminer où vous avez besoin de structure plutôt que de solutions ponctuelles.
Là où clients et auditeurs mettent en lumière les failles
Les clients et les auditeurs mettent en lumière les failles de votre infrastructure cloud en posant des questions précises sur les services, les données et les responsabilités. Leurs questions révèlent souvent des lacunes en matière de propriété, de cycle de vie et de preuves, bien avant qu'une violation ou une panne ne survienne. La gestion des risques liés aux tiers et le suivi de la conformité des fournisseurs ont été cités comme un défi majeur par 41 % des organisations interrogées dans le cadre de l'enquête 2025 d'ISMS.online.
Les questions typiques comprennent :
- Quels services cloud utilisez-vous pour notre compte, et où sont stockées nos données ?
- Qui est responsable de la sauvegarde, de l'identité, de la journalisation et de la configuration sur chaque plateforme ?
- Comment évaluer, surveiller et, si nécessaire, se séparer des fournisseurs de services cloud ?
- Comment nous soutiendrez-vous si nous souhaitons changer de service ?
Ces questions révèlent les imprécisions de votre approche actuelle. Si vos réponses dépendent des participants à la réunion ou nécessitent une vérification, le point A.5.23 pose déjà problème. Ce contrôle exige que vous ayez mis en place des processus d'acquisition, d'utilisation, de gestion et de sortie des services cloud, conformément aux exigences de sécurité définies. Pour un fournisseur de services gérés (MSP), cela implique de passer d'une architecture cloud improvisée à une architecture structurée, vérifiable par les auditeurs et les clients.
C’est là que la mise en place d’un registre vivant des services cloud, lié aux risques, aux responsabilités et aux historiques de cycle de vie, devient essentielle plutôt qu’un simple atout.
Demander demoCe que la norme ISO 27001 A.5.23 attend réellement de vous
La norme ISO 27001 A.5.23 exige de considérer le cloud comme un environnement de services gouverné, doté de règles, de responsabilités et de preuves clairement définies, et non comme un ensemble disparate d'outils et de fournisseurs. Concrètement, cela signifie être en mesure de démontrer comment les services cloud sont sélectionnés, contrôlés et mis hors service conformément aux exigences de sécurité de l'information.
Le rapport 2025 sur l'état de la sécurité de l'information note que les clients s'attendent le plus souvent à ce que les fournisseurs s'alignent sur des cadres formels tels que l'ISO 27001, l'ISO 27701, le RGPD, Cyber Essentials, SOC 2 et les normes émergentes en matière d'IA.
Dans l'édition 2022, le point A.5.23 stipule qu'il convient d'établir et de mettre en œuvre des processus pour l'acquisition, l'utilisation, la gestion et la sortie des services cloud, conformément aux exigences de sécurité de l'information. Cette formulation est conforme au texte de contrôle publié dans la norme ISO 27001:2022, point A.5.23, ainsi qu'aux recommandations relatives au cloud, telles que les normes ISO 27017 et ISO 27018, qui insistent toutes sur une gouvernance de bout en bout des services cloud plutôt que sur des contrôles ponctuels des fournisseurs. Une plateforme de gestion de la sécurité de l'information (GSSI) centralisée, telle que ISMS.online, peut simplifier ce travail en regroupant les politiques, les risques, les responsabilités et les enregistrements.
Les auditeurs recherchent généralement un lien clair entre le texte de contrôle et les politiques, procédures et enregistrements concrets. Si vous pouvez expliquer avec vos propres mots ce que la norme A.5.23 signifie pour votre entreprise, vous avez déjà une longueur d'avance sur de nombreux fournisseurs de services gérés qui se fient uniquement au libellé officiel.
De la phrase aux objectifs pratiques
Transformer l'exigence A.5.23 en objectifs pratiques consiste à la décomposer en un petit nombre d'attentes concrètes et vérifiables, permettant de concevoir des contrôles et des preuves. Ces objectifs fournissent un cadre pour expliquer le contrôle à votre équipe et aux auditeurs. Les praticiens de la norme ISO 27001 spécialisés dans le cloud regroupent généralement les exigences A.5.23 autour de thèmes tels que la politique cloud, les risques et exigences, la responsabilité partagée, le cycle de vie et les preuves ; c'est l'approche adoptée ici.
En pratique, la norme A.5.23 exige que vous réalisiez cinq actions de manière systématique et que vous puissiez le prouver. Une manière utile d'interpréter ce contrôle consiste à le décomposer en cinq objectifs pratiques :
- Politique et étendue du cloud – Définissez ce que signifie le « cloud » pour votre organisation, quels services et données sont concernés et qui peut adopter les nouveaux services.
- Risques et exigences – identifier les risques spécifiques au cloud tels que la mutualisation, la localisation et la connectivité des données, et définir des exigences minimales en matière de sécurité et de confidentialité.
- Responsabilité partagée – documenter qui est responsable des contrôles clés chez le fournisseur, le MSP et le client pour chaque plateforme et service majeur.
- Gestion du cycle de vie – Intégrer la sécurité à la sélection, à l’intégration, à la gestion des changements, à la surveillance et à la sortie des services cloud, et pas seulement dans les contrats.
- Preuves et amélioration – Conservez des documents attestant du bon fonctionnement de ces processus et révisez-les en fonction de l’évolution des plateformes, des clients et de la réglementation.
Ensemble, ces objectifs transforment la règle A.5.23, initialement formulée en une simple phrase, en un ensemble de bonnes pratiques. Ils vous fournissent également un cadre pour intégrer ce contrôle à votre déclaration d'applicabilité et à votre système de gestion de la sécurité de l'information (SGSI) global. L'enregistrement des objectifs, des responsables et des justificatifs dans un système tel que ISMS.online vous permet d'en assurer la cohérence malgré l'évolution des services et des normes.
Comment la version A.5.23 étend l'ancien modèle de fournisseur
La section A.5.23 élargit le modèle traditionnel de fournisseur en reconnaissant que le cloud constitue une infrastructure technique et non un simple contrat d'externalisation. Lorsque vos services reposent sur des plateformes partagées, vos choix en matière de configuration, d'accès et d'exploitation ont une incidence majeure sur la sécurité, même si l'infrastructure sous-jacente appartient à un tiers.
Comparé aux contrôles génériques des fournisseurs dans des domaines tels que la gestion des fournisseurs et la sécurité des opérations, A.5.23 :
- L'accent est mis sur le cycle de vie des services cloud, et pas seulement sur la sélection du fournisseur.
- Exige une prise en compte explicite de la responsabilité partagée et du multi-locataires.
- Ce document explique comment vous pouvez quitter ou remplacer les services cloud sans perdre le contrôle de vos données.
Ces points essentiels se retrouvent dans les commentaires spécialisés relatifs à la norme A.5.23 et dans les cartographies des contrôles du cloud, qui mettent en avant le cycle de vie, la responsabilité partagée et la planification de la sortie, contrairement à la supervision traditionnelle des fournisseurs. Pour les fournisseurs de services gérés (MSP), la norme A.5.23 complète également le contrôle d'accès, la gestion des actifs, la gestion des incidents et les autres contrôles de l'annexe A. L'objectif n'est pas de dupliquer le travail, mais de garantir que vos contrôles existants prennent pleinement en compte le cloud et votre mode de prestation de services.
Lier clairement ce contrôle à votre SMSI permet aux auditeurs de constater que la gouvernance du cloud est intégrée et non traitée comme une voie distincte.
Types de documents que les auditeurs s'attendent à voir
Les documents attendus par les auditeurs pour la norme A.5.23 sont ceux qui prouvent que vos politiques, processus et responsabilités relatifs au cloud sont réels, cohérents et appliqués. Ils privilégieront un ensemble restreint et cohérent d'éléments probants plutôt qu'une multitude de documents disparates. Les guides de mise en œuvre de la gouvernance du cloud pour la norme A.5.23 préconisent généralement une combinaison de politiques, de registres de services, d'évaluations des risques et de journaux de cycle de vie comme principal ensemble de preuves attendu par les auditeurs.
Lors d'un audit, il est probable qu'on vous demande des preuves telles que :
- Une politique d'utilisation ou de sécurité du cloud.
- Un registre des services cloud utilisés en interne et pour le compte des clients.
- Évaluations des risques et plans de traitement spécifiques au cloud.
- Documents de diligence raisonnable pour les principaux fournisseurs de services cloud et sous-traitants.
- Matrices de responsabilités partagées ou définitions de rôles équivalentes.
- Procédures ou guides de procédures pour l'intégration et la sortie des services.
- Exemples de journaux, d'avis ou de tickets illustrant le fonctionnement de ces processus.
Si ces éléments sont facilement repérables et qu'ils forment un récit cohérent, l'A.5.23 semblera maîtrisée et proportionnée. En revanche, s'ils ne sont présents que dans des documents épars ou dans les mémoires, leur contrôle devient une source de difficultés et de travail supplémentaire. Centraliser ces éléments sur une plateforme de gestion de la sécurité de l'information (SGSI) comme ISMS.online facilite grandement la démonstration de la gestion concrète du cloud.
La norme ISO 27001 simplifiée
Une avance de 81 % dès le premier jour
Nous avons fait le plus gros du travail pour vous, en vous offrant une avance de 81 % dès votre connexion. Il ne vous reste plus qu'à remplir les champs.
La double vie du MSP : client et fournisseur de services cloud
Votre fournisseur de services gérés (MSP) remplit une double fonction au sens de la clause A.5.23 : vous êtes à la fois un client exigeant des fournisseurs de services cloud en amont et un fournisseur de services cloud responsable envers vos propres clients. Ce contrôle exige que vous compreniez, documentiez et gouverniez ces deux rôles, y compris leurs interactions au sein de la chaîne de responsabilité partagée.
En tant que client cloud, vous dépendez des plateformes hyperscale et des outils SaaS pour gérer votre activité et fournir vos services. En tant que fournisseur de services cloud, vos clients vous considèrent comme responsable de la sécurité, de la continuité d'activité et du support, même si l'infrastructure technologique sous-jacente appartient à un tiers. La norme A.5.23 concilie ces deux perspectives et vous invite à les gérer de manière cohérente.
Comprendre vos rôles en amont et en aval
Comprendre vos rôles en amont et en aval implique de reconnaître que vous utilisez des services cloud en tant que client interne tout en vendant des services cloud à vos propres clients. La norme A.5.23 exige que vous preniez en compte ces deux perspectives et que vous veilliez à ce qu'elles se complètent plutôt qu'elles ne se contredisent.
En client cloudVous utilisez des services tels que des suites bureautiques, des plateformes de gestion des tickets et de supervision, ainsi que des infrastructures de cloud public. Il vous incombe de configurer ces services, de contrôler les accès et de veiller à leur surveillance. En cas d'incident ou de questionnement de la part des autorités de réglementation, votre capacité à démontrer votre maîtrise dépend de la qualité de la gestion de cette utilisation et de son intégration claire à vos processus de gestion de la sécurité de l'information (GSSI), notamment l'évaluation des risques et la gestion des changements.
En fournisseur ou gestionnaire de cloudVous concevez, fournissez et prenez en charge des services fonctionnant sur ces plateformes. Vous proposez peut-être des services d'infrastructure gérée, de sauvegarde, de SOC, d'hébergement d'applications ou de sécurité. Vos clients vous considèrent comme le responsable, même lorsque votre service s'appuie sur un cloud tiers. Ils ne font pas de distinction entre votre service et le fournisseur de services cloud qui l'héberge ; ils partent du principe que vous avez géré tous les détails techniques.
Un problème fréquent survient lorsque vous prenez des engagements auprès de vos clients concernant la conservation des journaux ou l'historique des sauvegardes, alors qu'un outil en amont fonctionne toujours avec ses paramètres par défaut, bien plus courts. Dans ce cas, votre engagement en aval est devenu obsolète par rapport à votre configuration en amont, et la version A.5.23 mettra en évidence cet écart.
Élaboration d'une vision à double responsabilité
Mettre en place une vision à double rôle des responsabilités implique de cartographier les responsabilités des fournisseurs, de vos équipes MSP et de vos clients dans un modèle unique et cohérent. Cela permet à votre RSSI, à votre responsable de la prestation de services et à vos gestionnaires de comptes d'avoir une vision partagée des responsabilités de chacun tout au long de la chaîne.
Une méthode pratique consiste à créer une matrice de responsabilités à double rôle. Pour chaque domaine de contrôle clé – gestion des identités et des accès, configuration, journalisation, sauvegarde, réponse aux incidents, gestion des changements, protection des données – vous listez :
- Ce à quoi s'engagent vos fournisseurs en amont.
- Ce à quoi vous, en tant que MSP, vous vous engagez en amont (par exemple, activer certaines fonctionnalités, gérer certains risques).
- Ce à quoi vous vous engagez en aval dans vos contrats clients et vos SLA.
- Ce que vous attendez de vos clients.
Cet exercice révèle souvent des incohérences : des obligations envers les clients sans soutien en amont, ou des hypothèses concernant les fournisseurs non étayées par leurs contrats. Il permet également d’identifier les domaines nécessitant des contrôles renforcés, une formulation plus claire ou une conception de service différente. En intégrant cette vision dans une plateforme de gestion de la sécurité de l’information (GSSI) telle que ISMS.online, vous offrez aux équipes une source unique d’information fiable sur les responsabilités partagées.
Transformer les cartes de responsabilités en pratique quotidienne
Intégrer les cartographies des responsabilités dans la pratique quotidienne implique de s'assurer que tous les intervenants en services cloud comprennent les responsabilités qui leur incombent et peuvent agir rapidement en conséquence. Ces cartographies doivent orienter les comportements des équipes commerciales, d'ingénierie, de support et de gestion de comptes.
Concrétiser les cartes de responsabilités signifie :
- Les utiliser pour informer les équipes commerciales et les équipes de gestion de comptes, afin qu'elles ne fassent pas de promesses excessives ni n'improvisent leurs engagements.
- Aligner les manuels d'exploitation et les procédures avec les responsabilités que vous avez définies, afin que les équipes techniques agissent de manière cohérente.
- Former les ingénieurs sur la manière et le moment d'exercer leurs droits auprès des locataires clients, y compris les procédures d'élévation et d'approbation dans les délais impartis.
- Convenir des modalités de communication et de gestion des incidents impliquant des fournisseurs avec les clients, y compris les procédures d'escalade.
Lorsque votre vision à double rôle est ainsi intégrée, l'exigence A.5.23 cesse d'être abstraite et devient un outil naturel pour comprendre le fonctionnement de votre fournisseur de services gérés dans le cloud. Elle vous offre également une explication claire aux conseils d'administration et aux clients qui souhaitent comprendre votre rôle dans la chaîne de responsabilité partagée.
Un modèle pratique de responsabilité partagée pour les plateformes cloud des fournisseurs de services gérés
Un modèle pratique de responsabilité partagée pour les plateformes cloud des MSP consiste en un ensemble de matrices claires indiquant les rôles et responsabilités de chaque acteur (fournisseur, MSP et client) pour chaque service. Conformément à la section A.5.23, ces matrices transforment le concept de responsabilité partagée en un système opérationnel, formable et auditable.
La plupart des fournisseurs de cloud public proposent une répartition simple : ils sécurisent l’infrastructure, vous sécurisez ce que vous y développez. Ce modèle est documenté dans les explications relatives à la responsabilité partagée des principaux fournisseurs tels qu’AWS, Azure et Google Cloud, et il est devenu une base courante pour la conception du contrôle du cloud. Pour les fournisseurs de services gérés (MSP), ce n’est qu’un point de départ. Vous avez besoin de modèles qui reflètent les plateformes spécifiques que vous utilisez, les services que vous proposez et le mode de fonctionnement réel de vos équipes.
Dépasser le cadre de la « responsabilité conjointe » générique
Dépasser l’expression générique de « responsabilité conjointe » implique de remplacer les déclarations vagues par des tâches précises et nommées, compréhensibles par les individus et les équipes. La norme A.5.23 valorise cette clarté, car les auditeurs et les clients peuvent ainsi identifier les responsables des actions concrètes, et non de simples concepts abstraits.
Les étiquettes génériques de « responsabilité conjointe » masquent des risques réels. Pour aller au-delà, il faut prendre en compte :
- Les plateformes spécifiques que vous utilisez (par exemple, infrastructure-as-a-service, logiciel-as-a-service, outils de sécurité gérés).
- Les services spécifiques que vous proposez (par exemple, sauvegarde gérée, SOC géré, environnement de travail moderne géré).
- La manière dont votre équipe fonctionne réellement (par exemple, l'utilisation de l'automatisation, la surveillance centralisée, les fenêtres de maintenance).
Pour chaque combinaison de plateforme et de service, une matrice des responsabilités doit définir les rôles et responsabilités avec suffisamment de précision pour permettre à chacun d'agir. Il s'agit notamment de préciser qui active la journalisation, qui teste les restaurations, qui gère les demandes d'accès aux données et qui coordonne la communication en cas d'incident, plutôt que de se contenter d'indiquer « partagé ».
Cette étape supplémentaire facilite également les contrôles connexes, tels que la gestion des incidents et la sécurité des opérations, car chacun peut voir où son rôle commence et où il s'arrête.
Structurer vos matrices de responsabilités
Bien structurer vos matrices de responsabilités implique d'utiliser une présentation cohérente qui reflète le mode de pensée de vos ingénieurs et responsables de service, tout en étant suffisamment détaillée pour guider leurs actions. Une structure simple, appliquée de manière uniforme à tous les services, facilite grandement la formation et l'évaluation.
Une matrice pratique pour chaque service pourrait couvrir des domaines tels que :
- Gestion des identités et des accès : – qui crée et révoque les comptes, gère les rôles et examine les accès.
- Configuration et durcissement : – qui définit les configurations de référence, gère les mises à jour de sécurité et examine les dérives de configuration.
- Journalisation et surveillance : – qui active les journaux, les stocke, examine les alertes et répond aux incidents.
- Sauvegarde et récupération : – qui configure les sauvegardes, teste les restaurations et vérifie les objectifs de récupération.
- Protection des données et confidentialité : – qui classe les données, applique les règles de conservation et gère les droits des personnes concernées.
- Continuité et sortie : – qui est responsable des modèles de résilience, du basculement et de l'exportation ou de la suppression des données à la fin d'un contrat.
Pour chaque ligne, la matrice doit clairement indiquer les responsabilités : fournisseur, MSP, client, ou partagées avec des tâches spécifiques assignées. Il est également important de veiller à ce que chaque matrice soit versionnée et révisée lors de toute modification des services, des plateformes ou des contrats, afin de garantir son exactitude dans le temps.
Voici un exemple simplifié de sauvegarde gérée sur une plateforme de cloud public :
| Domaine | Responsabilités du fournisseur / du MSP / du client |
|---|---|
| Configuration de sauvegarde | Le fournisseur propose cette fonctionnalité ; le **MSP** configure les politiques ; le client examine la portée |
| Restaurer les tests | **Le fournisseur de services gérés** effectue des tests de restauration périodiques ; le client valide l’intégrité des données. |
| Paramètres de rétention | Le fournisseur applique les limites ; le **MSP** fixe la durée de conservation ; le client approuve la politique |
Vous pouvez ensuite réutiliser ces matrices pour tous les clients qui utilisent le même modèle de service, en les ajustant uniquement lorsque cela est vraiment nécessaire.
Lier le modèle à votre SMSI et à vos clients
Lier le modèle de responsabilité partagée à votre SMSI et à vos clients garantit qu'il influence les décisions, de la prévente à la fin du contrat, au lieu de rester isolé. Plus vous l'intégrez, plus il devient utile et crédible.
Une fois ces modèles définis, connectez-les :
- En interne, en les intégrant dans les politiques, les procédures, les manuels d'exploitation et les formations.
- Sur le plan commercial, en alignant vos descriptions de services, vos propositions et vos SLA sur les responsabilités que vous avez définies.
- Avec les clients, en partageant des vues ou des schémas simplifiés lors de l'intégration, afin que les attentes soient claires dès le premier jour.
Lorsqu'un auditeur vous interroge sur la gestion des responsabilités partagées au titre de l'article 5.23, vous pouvez lui présenter ces matrices, leurs liens avec votre SMSI et des exemples concrets de leur application dans la prise de décisions. Si un client, comme un RSSI ou un directeur informatique, vous demande « Qui est responsable de ce contrôle ? », vous disposez d'une réponse cohérente à l'échelle de l'entreprise. Une plateforme centralisée telle que ISMS.online permet de stocker ces matrices, ainsi que les risques, les contrôles et les contrats, facilitant ainsi leur mise à jour et leur justification.
Libérez-vous d'une montagne de feuilles de calcul
Intégrez, développez et faites évoluer votre conformité, sans complications. IO vous offre la résilience et la confiance nécessaires pour croître en toute sécurité.
Conception des processus du cycle de vie des services cloud pour A.5.23
Les processus de gestion du cycle de vie des services cloud permettent de démontrer que la norme A.5.23 est bien plus qu'une simple déclaration de principe : ils prouvent que vous sélectionnez, exploitez et mettez hors service les services cloud de manière contrôlée et reproductible. Pour un fournisseur de services gérés (MSP), l'objectif est d'intégrer les étapes du cycle de vie du cloud à ses processus de gestion de la sécurité de l'information (SGSI) existants, et non de créer une bureaucratie supplémentaire.
Le point A.5.23 exige que vous démontriez que les services cloud suivent des étapes définies, de leur conception à leur mise hors service, en tenant compte de la sécurité et du partage des responsabilités à chaque étape. Ceci est en parfaite adéquation avec la terminologie du contrôle concernant « l’acquisition, l’utilisation, la gestion et la mise hors service » des services cloud, conformément aux exigences de sécurité de l’information, et avec les modèles de cycle de vie courants utilisés dans la norme ISO 27001 et les recommandations relatives aux normes cloud, telles que le commentaire du point A.5.23 de l’ISO 27001. Cela correspond naturellement aux clauses de l’ISO 27001 relatives au traitement des risques, à la planification opérationnelle, à la gestion des changements et à la gestion des fournisseurs.
Définir un cycle de vie des services cloud que les utilisateurs peuvent suivre
Définir un cycle de vie de service cloud compréhensible par tous implique de transformer l'A.5.23 en une série d'étapes répétables et adaptées à vos méthodes de travail existantes. Ce cycle de vie doit être suffisamment simple pour que les responsables produit, les ingénieurs et les équipes d'approvisionnement puissent l'appliquer sans connaissances spécialisées. Deux tiers des organisations interrogées dans le cadre de l'enquête 2025 d'ISMS.online sur l'état de la sécurité de l'information affirment que la rapidité et l'ampleur des changements réglementaires rendent la conformité plus difficile à maintenir.
Le cycle de vie typique des services cloud importants peut comprendre des étapes telles que :
- Idée et évaluation – Quelqu’un propose un nouveau service cloud ou une nouvelle façon d’utiliser un service existant. Vous évaluez sa valeur commerciale, sa sécurité et sa conformité réglementaire.
- Sélection et diligence raisonnable – vous vérifiez les certifications, l’emplacement des données, les conditions contractuelles et les capacités de support, et vous comparez les options.
- Conception et intégration – vous décidez comment le service sera configuré, intégré et surveillé, et qui en sera propriétaire.
- Fonctionnement et changement – vous gérez le service, consultez les journaux et les indicateurs, gérez les changements et les incidents, et veillez à ce que la configuration soit conforme à vos normes.
- Révision et renouvellement – vous examinez périodiquement si le service répond toujours aux besoins, si les risques sont acceptables et si des améliorations sont nécessaires.
- Sortie ou remplacement – Si vous désactivez ou remplacez le service, vous gérez l’exportation, la suppression et la communication avec les clients.
Ces étapes permettent de systématiser les décisions relatives aux services cloud au lieu de les prendre au cas par cas. Pour chacune d'elles, définissez les actions, approbations et enregistrements minimaux requis. Cela peut inclure des évaluations des risques, des listes de vérification de diligence raisonnable, des configurations de référence, des enregistrements de modifications et des confirmations de sortie, le tout aligné sur votre système de gestion de la sécurité de l'information (SGSI) central.
Pour rendre cela encore plus facile à utiliser, vous pouvez exprimer le cycle de vie sous forme d'une série d'étapes simples à suivre pour les équipes.
Étape 1 : Capturer et sélectionner l'idée
Capturez et évaluez chaque idée de service cloud avant que quiconque ne s'y inscrive ou ne l'intègre, afin de pouvoir en évaluer la valeur, le risque et l'alignement avec votre système de gestion de la sécurité de l'information (SGSI).
Consignez le service cloud proposé, son objectif et ses risques initiaux avant toute inscription ou intégration.
Étape 2 : Réaliser l’analyse préalable et la conception
Il convient de réaliser une analyse approfondie et une conception rigoureuse avant d'adopter un service cloud, afin de définir la configuration, la surveillance et les responsabilités plutôt que de les improviser.
Vérifier l'assurance, les contrats et le traitement des données, puis définir la configuration, la surveillance et les responsabilités partagées.
Étape 3 : Embarquer, opérer et planifier la sortie
Mettez en œuvre, exploitez et planifiez la sortie de manière structurée, afin de pouvoir démontrer comment le service est contrôlé tout au long de son cycle de vie.
Intégrez le service en fonction de vos paramètres de référence, surveillez-le et consignez comment vous le quitterez ou le remplacerez en toute sécurité.
Intégrer les contrôles du cycle de vie dans votre façon de travailler
Intégrer les contrôles du cycle de vie à vos méthodes de travail implique de les intégrer aux processus et outils que vos équipes utilisent déjà. Lorsque le cycle de vie devient la norme, la conformité à la norme A.5.23 est grandement facilitée.
Considérer:
- L’aligner sur les processus d’approvisionnement, afin que les contrats ne puissent être signés tant que les exigences de sécurité, de confidentialité et opérationnelles n’ont pas été vérifiées.
- Liez-le à votre processus de lancement de services, afin que les nouvelles offres ou les changements majeurs passent par les étapes du cycle de vie du cloud.
- Intégrez les tâches du cycle de vie dans vos systèmes de gestion des tickets et des changements, et non pas seulement dans des documents cloud séparés.
En reliant les étapes du cycle de vie aux processus établis, tels que la gestion du changement et la gestion des fournisseurs, vous réduisez les obstacles et favorisez l'adoption. Les utilisateurs suivent le cycle de vie car c'est la voie la plus simple, et non parce qu'on leur a demandé de consulter une autre politique.
Préparer les preuves du cycle de vie pour l'audit
Pour que les preuves relatives au cycle de vie soient conformes aux exigences d'audit, il faut pouvoir présenter quelques exemples complets illustrant l'application de la même logique à différents services. Les auditeurs recherchent des tendances, et non des succès isolés.
Pour chaque exemple, veillez à démontrer :
- Pourquoi ce service a-t-il été choisi, en fonction des risques et des exigences ?
- Comment les responsabilités ont été définies, selon votre modèle de responsabilité partagée.
- Quels contrôles ont été mis en place lors de l'intégration, y compris les paramètres de référence et les modèles d'accès ?
- Comment le service est surveillé et évalué, avec des exemples de changements ou d'améliorations.
- Comment les données et les accès seraient gérés lors de la sortie, même si cette sortie n'a pas encore eu lieu.
Si vous pouvez fournir ces éléments de preuve sans difficulté majeure, la norme A.5.23 semblera intégrée et non pas simplement ajoutée. Un système comme ISMS.online peut vous y aider en centralisant les services, les risques, les responsabilités, les changements et les enregistrements de sortie, vous évitant ainsi de devoir reconstituer le dossier à chaque fois qu'on vous le demande.
Contrôles techniques multilocataires : mise en œuvre de garanties cohérentes
Les contrôles techniques mutualisés concrétisent vos décisions de gouvernance du cloud (A.5.23) dans le travail d'ingénierie quotidien. Ils traduisent les modèles de responsabilité partagée et les processus de cycle de vie en référentiels concrets qui protègent simultanément de nombreux clients.
Lorsque vous gérez plusieurs locataires sur des plateformes communes, la norme A.5.23 exige une approche proactive et standardisée en matière d'identité, de configuration, de journalisation, de sauvegarde et d'isolation. Vous pourrez ainsi démontrer que vos mesures de protection techniques sont conformes aux responsabilités que vous avez acceptées et aux engagements que vous avez pris envers vos clients.
Pourquoi les référentiels multi-locataires sont importants
Les référentiels de sécurité mutualisés sont essentiels, car de petites failles peuvent avoir des conséquences importantes pour de nombreux clients simultanément. Un rôle trop permissif, une mise à jour manquée ou une sauvegarde non testée peuvent compromettre la sécurité globale de votre cloud. Les cadres de sécurité du cloud et les recommandations nationales, comme les analyses des risques liés à la mutualisation dans les catalogues de contrôles et les recueils de données sur la sécurité du cloud des centres nationaux de cybersécurité, soulignent systématiquement que la gestion des identités, les correctifs et les sauvegardes constituent des zones de risque systémiques susceptibles de se propager rapidement à l'ensemble des clients en cas de défaillance. La majorité des organisations interrogées dans le cadre de l'enquête 2025 d'ISMS.online ont déclaré avoir été affectées par au moins un incident de sécurité lié à un tiers ou à un fournisseur au cours de l'année précédente.
Dans un environnement MSP, un seul compte administrateur aux privilèges excessifs, une action critique non consignée ou un processus de sauvegarde non testé peuvent impacter des dizaines de clients lors d'un incident unique. La norme A.5.23 exige une gestion systématique et non réactive de ces risques, ainsi que la capacité de démontrer l'application de vos contrôles à l'ensemble des services cloud que vous utilisez et fournissez. Des référentiels cohérents définissent les contrôles minimaux requis pour tout client utilisant une plateforme ou un service donné, garantissant ainsi aux auditeurs et aux clients que vous n'avez pas à réinventer la sécurité à chaque fois.
Du point de vue du leadership, ces référentiels offrent également une garantie : vous pouvez montrer aux conseils d'administration et aux clients que les mesures de protection techniques sont conformes aux décisions de gouvernance et contractuelles que vous avez déjà prises.
Thèmes techniques fondamentaux à normaliser
Les principaux thèmes techniques à standardiser sont les domaines où des mesures de protection cohérentes réduisent la probabilité de problèmes entre locataires et offrent aux ingénieurs un point de départ clair sur chaque plateforme.
Bien que les détails varient selon les plateformes, la plupart des fournisseurs de services gérés (MSP) ont intérêt à standardiser au moins les points suivants. Cela facilite le travail d'équipe entre le responsable de la sécurité, le responsable des opérations et les ingénieurs.
- Gestion des identités et des accès : – accès basé sur les rôles, principe du moindre privilège, séparation des tâches, élévation des pouvoirs limitée dans le temps pour les actions à haut risque et procédure de désactivation robuste.
- Configuration et durcissement : – modèles de base pour la segmentation du réseau, le chiffrement, la protection des terminaux, les politiques de correctifs et la dénomination des ressources.
- Journalisation et surveillance : – des configurations de journalisation cohérentes, une agrégation centralisée des journaux, des règles d'alerte définies et des procédures de réponse documentées.
- Sauvegarde et récupération : – calendriers de sauvegarde standard, conservation, chiffrement, procédures de test de restauration et documentation des objectifs de récupération du client.
- Isolement et location : – des modèles de séparation des locataires au niveau du réseau, de l'identité et des données, ainsi que des contrôles permettant de vérifier que l'isolation est maintenue.
Chaque configuration de base doit clairement indiquer ce que le fournisseur propose, ce que vous configurez et maintenez, et ce que vous attendez des clients. Ensemble, ces éléments constituent la base technique de votre implémentation A.5.23.
Une fois ces thèmes définis, l'étape suivante consiste à les intégrer là où vivent les ingénieurs : modèles, scripts, infrastructure en tant que code, outils de gestion centralisés et manuels de procédures documentés.
Raccordement des commandes techniques à A.5.23 et au-delà
Lier les contrôles techniques à la norme A.5.23 et aux contrôles associés garantit la cohérence de votre gouvernance, de vos engagements juridiques et de vos pratiques d'ingénierie. Cette cohérence facilite l'explication et la justification de votre système global.
Cela signifie:
- Associer chaque élément de référence à vos matrices de responsabilité partagée, afin que les contrôles techniques correspondent aux responsabilités que vous avez attribuées.
- S'assurer que les référentiels font partie intégrante du cycle de vie de vos services cloud, afin qu'ils soient appliqués lors de l'intégration et réexaminés lors des évaluations.
- Lier des thèmes tels que l'accès, la journalisation et la sauvegarde aux contrôles de l'annexe A relatifs au contrôle d'accès, à la sécurité des opérations, à la gestion des incidents et à la continuité des activités.
Cet alignement confère une cohérence globale à votre système de contrôle. Ainsi, lors des audits ou des revues clients, vous serez en mesure de présenter non seulement des politiques, mais aussi des mesures techniques opérationnelles conformes à votre gouvernance. En gérant ces référentiels dans un système centralisé comme ISMS.online, vous pourrez démontrer en quelques clics le lien entre un service cloud, son évaluation des risques et ses contrôles techniques.
Gérez toute votre conformité, en un seul endroit
ISMS.online prend en charge plus de 100 normes et réglementations, vous offrant une plate-forme unique pour tous vos besoins de conformité.
Contrats, SLA et clauses de sous-traitance qui résistent à l'audit
Les contrats, les SLA et les clauses relatives aux sous-traitants sont les éléments qui transforment vos décisions de gouvernance du cloud (A.5.23) en engagements juridiquement contraignants. Le contrôle exige que vos accords avec les fournisseurs, les sous-traitants et les clients reflètent la responsabilité partagée, le cycle de vie et les choix techniques que vous avez effectués, et non qu'ils les contredisent.
La norme A.5.23 n'impose pas de format particulier pour la rédaction des contrats, mais les auditeurs et les clients vérifieront la cohérence entre vos engagements juridiques et votre réalité technique. Les recommandations fondées sur des principes concernant la norme A.5.23 et les contrôles cloud associés insistent régulièrement sur l'importance d'aligner les promesses contractuelles sur les contrôles effectifs et les modèles de responsabilité partagée, car c'est souvent le manque d'alignement qui est à l'origine des constatations d'audit et des litiges.
La norme A.5.23 ne vous impose aucune forme particulière de rédaction contractuelle, mais les auditeurs et les clients vérifieront la cohérence entre vos engagements juridiques et votre réalité technique. En cas de divergence, ce contrôle devient source de risques et de constatations.
Expliciter les responsabilités et les attentes dans les contrats et les SLA implique de traduire vos matrices de responsabilités internes en un langage clair et précis, compréhensible par les services juridiques, commerciaux et les clients. Il est beaucoup plus facile de prouver l'application de l'article A.5.23 lorsque ces documents reflètent fidèlement vos pratiques opérationnelles.
Les contrats et les SLA sont souvent source de malentendus et de litiges, notamment lorsqu'il s'agit de services cloud. Pour être conforme à la norme A.5.23, vos accords doivent :
- Décrivez clairement les services, y compris toute utilisation de plateformes cloud tierces.
- Définissez les obligations en matière de sécurité et de protection des données avec suffisamment de détails pour être pertinentes, sans promettre l'impossible.
- Expliquez qui est responsable de quels aspects de la détection, de la réponse et de la communication en matière d'incidents.
- Précisez ce qui se passe à la fin du contrat, notamment l'exportation ou la suppression des données et toute assistance à la transition.
Dans la mesure du possible, alignez ce langage directement sur les domaines de vos matrices de responsabilité partagée, afin d'établir une cohérence claire entre le modèle et la formulation. Cela contribue également à satisfaire aux exigences de la norme ISO 27001 relatives aux obligations légales, réglementaires et contractuelles.
Une fois les responsabilités clairement définies dans les matrices et les contrats, vos équipes auront moins de risques d'interprétations contradictoires en cas d'incidents ou de demandes complexes de la part des clients.
Aligner la réalité technique sur les engagements juridiques
L’alignement des contraintes techniques sur les engagements juridiques implique de vérifier que les promesses contractuelles sont réalisables avec les outils, processus et référentiels existants. Cela réduit le risque que les clients ou les auditeurs constatent des écarts entre les termes et la pratique. Seules 29 % des organisations interrogées en 2025 par ISMS.online ont déclaré n’avoir reçu aucune amende pour manquement à la protection des données, la majorité ayant fait état d’amendes, certaines s’exposant même à des sanctions supérieures à 250 000 £.
Il est facile que les clauses juridiques s'éloignent de la réalité technique au fil du temps. Un modèle peut par exemple promettre une notification d'incident très rapide, mais vos processus de surveillance et d'escalade peuvent rendre sa mise en œuvre difficile. Ou encore, un SLA peut s'engager sur des objectifs de reprise qui ne correspondent pas aux plans de sauvegarde.
Pour éviter cela, examinez conjointement vos contrats et SLA avec les services juridiques, de sécurité, d'exploitation et de gestion de comptes. Demandez :
- Pouvons-nous respecter systématiquement les engagements que nous prenons, compte tenu de nos systèmes de surveillance, de nos heures d'assistance et de nos référentiels techniques actuels ?
- Existe-t-il des domaines où nous devons investir dans de meilleurs contrôles ou outils pour les respecter ?
- Existe-t-il des obligations qui devraient plutôt incomber au client ou au fournisseur, et être communiquées comme telles ?
Lorsque vos engagements juridiques et vos capacités techniques sont alignés, la conformité à la clause A.5.23 est plus facile à justifier et moins risquée à mettre en œuvre. Vous réduisez également le risque de mauvaises surprises pour vos clients, les organismes de réglementation ou les auditeurs qui examinent en détail vos engagements.
Intégrer la gouvernance dans vos accords
Intégrer la gouvernance à vos accords signifie utiliser le langage contractuel pour définir clairement les comportements attendus des prestataires et des clients, et non se contenter de documenter les services et les prix. Cela permet d'ancrer la responsabilité partagée et la notion de cycle de vie dans la relation au quotidien.
Cela pourrait inclure :
- Droit de recevoir ou de consulter les assurances des fournisseurs, telles que les certifications mises à jour ou les rapports indépendants.
- Attentes concernant la participation à des exercices conjoints de gestion des incidents ou de continuité des opérations.
- Obligation de signaler tout changement important de service ou de lieu.
- Exigences relatives au respect des procédures de sortie convenues, y compris les échéanciers et la coopération.
En intégrant ces principes à vos contrats, vous vous assurez que la gouvernance ne reste pas une simple affaire interne. Elle devient partie intégrante de votre mode de collaboration avec vos fournisseurs et vos clients tout au long du cycle de vie du service. Lors des audits portant sur la norme A.5.23, les auditeurs peuvent constater que le cycle de vie et la responsabilité partagée sont systématiquement reflétés dans vos accords, et pas seulement dans vos politiques.
Réservez une démo avec ISMS.online dès aujourd'hui
Réserver une démonstration avec ISMS.online est une solution pratique pour découvrir comment votre fournisseur de services gérés (MSP) peut vous aider à maîtriser la gouvernance du cloud (conformément à la norme A.5.23) sans complexifier vos équipes. Vous visualiserez en un seul endroit les liens entre les services cloud, les risques, les responsabilités, les étapes du cycle de vie et les justificatifs, vous préparant ainsi aux audits, aux questions des clients et aux revues du conseil d'administration.
Vous maîtrisez la gouvernance du cloud (A.5.23) en remplaçant les documents épars et les décisions ponctuelles par un système unique et cohérent qui relie les services, les risques, les responsabilités, les étapes du cycle de vie et les preuves. Pour de nombreux fournisseurs de services gérés (MSP), l'utilisation d'une plateforme ISMS dédiée, telle que ISMS.online, peut constituer une solution pratique pour parvenir à cette consolidation sans complexifier davantage les processus.
ISMS.online vous aide à transformer vos responsabilités de gouvernance du cloud (A.5.23) en un système unique et intégré qui connecte les inventaires cloud, les modèles de responsabilité partagée, les flux de travail du cycle de vie, les contrats et les preuves. Au lieu de rechercher des documents sur différents disques, consoles et boîtes de réception, vous pouvez visualiser la gouvernance des services cloud et la gestion des responsabilités depuis une plateforme unique.
Pour les fournisseurs de services gérés (MSP), cela signifie pouvoir présenter aux auditeurs, aux conseils d'administration et aux clients un récit plus clair et cohérent : les services cloud utilisés, la répartition des responsabilités, les contrôles mis en place et leur évolution. Les observateurs des outils de gouvernance, de gestion des risques et de conformité (GRC) constatent souvent que les plateformes centralisées facilitent l'élaboration et la cohérence de ce récit, car elles regroupent les risques, les contrôles et les preuves dans un environnement unique. Vous gardez la maîtrise de vos décisions ; la plateforme vous aide à démontrer cette maîtrise, de manière constante, à mesure que votre entreprise se développe et que les normes évoluent.
Visualisez votre espace cloud en un seul coup d'œil
Visualiser votre infrastructure cloud en un seul coup d'œil facilite la tâche de votre RSSI, de votre responsable des opérations et de vos équipes en contact avec les clients pour répondre aux questions complexes, et ce, sans heurts. La norme A.5.23 devient moins une simple formalité de conformité et davantage un moyen simple de décrire votre mode de fonctionnement réel.
En centralisant votre gouvernance cloud sur une plateforme SMSI, vous vous offrez, ainsi qu'à votre équipe, un point de référence unique pour A.5.23. Vous pouvez alors :
- Tenir à jour un registre des services cloud internes et destinés aux clients.
- Associez chaque service aux risques, aux contrôles, aux matrices de responsabilités et aux étapes du cycle de vie.
- Joindre les contrats, les documents de vérification préalable, les registres de modifications et les preuves de sortie directement aux services auxquels ils se rapportent.
Ensemble, ces fonctionnalités facilitent grandement la réponse aux questions des auditeurs, aux revues de sécurité des clients et aux décideurs internes qui souhaitent comprendre la gestion du cloud. Vous n'avez plus besoin de vous fier à votre mémoire ni à des feuilles de calcul disparates pour présenter votre stratégie cloud.
Passez à l'étape suivante en toute confiance
Si votre fournisseur de services gérés (MSP) se reconnaît dans les défis décrits ici (responsabilités floues, preuves dispersées, pression croissante des clients et des auditeurs), explorer une plateforme comme ISMS.online lors d'une démonstration courte et ciblée constitue une prochaine étape pratique. Malgré cette pression croissante, la quasi-totalité des répondants à l'enquête 2025 sur l'état de la sécurité de l'information placent l'obtention ou le maintien de certifications de sécurité telles que l'ISO 27001 ou le SOC 2 au premier plan de leurs priorités.
Vous pouvez constater comment il prend en charge vos outils et méthodes de travail existants tout en vous fournissant la structure attendue par A.5.23.
Choisissez ISMS.online pour centraliser votre registre des services cloud, vos responsabilités, vos risques et vos justificatifs. Vous pourrez ainsi démontrer, et non simplement affirmer, que la conformité à la norme A.5.23 est assurée. Si vous accordez une grande importance à une gouvernance claire, à des audits simplifiés et à une présentation plus convaincante à vos clients et à votre conseil d'administration, notre équipe est à votre disposition pour vous accompagner dans la mise en œuvre de ces solutions au sein de votre environnement.
Demander demoFoire aux questions
Qu’attend réellement un fournisseur de services gérés (MSP) utilisant des services cloud selon la norme ISO 27001:2022 A.5.23 ?
La norme ISO 27001:2022, paragraphe 5.23, exige que votre fournisseur de services gérés (MSP) Gérez activement l'intégralité du cycle de vie de chaque service cloud sur lequel vous vous appuyez.Il ne s'agit pas simplement de collecter des certificats de fournisseurs et de croiser les doigts. Vous devez être en mesure de démontrer, rapidement et systématiquement, ce que vous utilisez, pourquoi vous l'utilisez, les risques de dysfonctionnement, qui détient quels contrôles et comment vous pouvez vous désengager sans perte de données ni interruption de service.
À quoi ressemble une « bonne » preuve A.5.23 pour un MSP ?
Les auditeurs et les clients avertis recherchent généralement un petit faisceau cohérent de preuves, et non d'archives gigantesques. Pour un MSP, l'ensemble de base comprend généralement :
- Un clair politique d'utilisation du cloud / de sécurité du cloud
Cela définit ce qui est considéré comme « cloud » dans votre environnement (IaaS, SaaS, PaaS, services de sécurité gérés), qui peut approuver les nouveaux services et vos attentes minimales en matière de configuration, de surveillance et de sortie.
- A registre de service cloud qui couvre :
- outils internes (RMM, PSA, billetterie, facturation, CRM, surveillance, transfert de fichiers sécurisé) ; et
- services destinés aux clients (plateformes IaaS, Microsoft 365 et autres suites SaaS, sauvegarde/DR, SOC/XDR, pare-feu et WAF gérés).
- Évaluations et traitements des risques spécifiques au cloud :
Ces éléments doivent mentionner l'exposition aux environnements multi-locataires, les rôles étendus entre locataires, la résidence des données, la dépendance vis-à-vis d'un fournisseur, les dépendances API et la gestion des clés. Les risques doivent être liés à des mesures de contrôle concrètes et à des actions d'amélioration.
- Documents de diligence raisonnable : pour les principaux fournisseurs et sous-traitants
Cela inclut généralement des résumés de sécurité, des certifications (par exemple ISO 27001, SOC 2), des DPA, l'historique de disponibilité, l'historique des violations de données et les limitations ou exclusions connues qui affectent vos conceptions.
- Matrices de responsabilité partagée :
Pour chaque service principal, indiquez clairement les prestations du fournisseur, celles de votre MSP et les responsabilités du client. Le langage doit être suffisamment précis pour qu'un ingénieur ou un client puisse identifier ses tâches sans réunion supplémentaire.
- Enregistrements du cycle de vie des services cloud :
Preuve que la sélection, l'intégration, la configuration, le changement, l'examen périodique et la sortie sont gérés de manière contrôlée et reproductible plutôt que par le biais de tickets ad hoc.
Si ces éléments sont bien coordonnés et faciles d'accès, la clause A.5.23 paraît maîtrisée et crédible. L'utilisation d'ISMS.online pour centraliser les politiques, les entrées de risques, les dossiers fournisseurs, les matrices de responsabilités et les justificatifs du cycle de vie dans un espace de travail ISMS unique vous évite de devoir reconstituer votre historique cloud à partir de recherches dans votre boîte de réception et de captures d'écran de la console chaque fois qu'un auditeur ou un client évoque cette clause.
Comment un MSP devrait-il construire un modèle de responsabilité partagée utilisable pour le cloud selon la norme A.5.23 ?
Vous répondez à l'intention de l'article A.5.23 lorsque la « responsabilité partagée » devient une cartographie des tâches réelles service par serviceIl ne s'agit pas simplement d'une diapositive marketing affirmant que « la sécurité est une priorité pour nous et pour le fournisseur ». Toute personne qui la lit – ingénieur, vendeur, relecteur de contrat ou client – doit pouvoir voir exactement ce qui lui appartient.
Comment transformer la « responsabilité partagée » en quelque chose de concret ?
Un modèle pratique qui fonctionne bien pour les fournisseurs de services gérés consiste à :
1. Classez vos services cloud par catégorie.
Commencez par une courte liste de catégories :
- Charges de travail du cloud public (IaaS/PaaS).
- Suites de productivité SaaS (Microsoft 365, Google Workspace et similaires).
- Services de sauvegarde et de reprise après sinistre gérés.
- Services gérés de SOC/XDR et de détection des menaces.
- Autres outils cloud récurrents que vous utilisez pour gérer votre entreprise ou fournir des services.
Cette liste reflète généralement les entrées de votre registre de services cloud, ce qui facilite la cohérence des informations.
2. Choisir un ensemble commun de domaines de sécurité
Choisissez un petit ensemble de domaines qui s'appliquent à la plupart de vos services, tels que :
- Gestion des identités et des accès.
- Configuration de base et durcissement.
- Journalisation, surveillance et alerte.
- Procédures de sauvegarde, de restauration et de test.
- Cryptage et gestion des clés.
- Détection, triage et intervention en cas d'incident.
- Gestion des changements et approbations.
- Conservation, résidence et élimination des données.
Le respect d'un ensemble standard facilite la compréhension et la réutilisation du modèle entre les services.
3. Attribuer la propriété par domaine et par service
Pour chaque service et chaque domaine de sécurité, déterminez qui effectue réellement le travail en pratique :
- Fournisseur de cloud : – résilience de l’infrastructure, sécurité physique, la plupart des correctifs de la plateforme sous-jacente, certaines options de stockage des journaux.
- Votre MSP : – configurations de référence des locataires, routage des alertes, planification des sauvegardes, tests de restauration, triage des incidents, rapports clients.
- Client: – comportement des utilisateurs, utilisation acceptable, classification des données, approbation d'accès, décisions relatives au cycle de vie du contenu.
Lorsque les responsabilités sont partagées, indiquez la répartition comme suit : tâches spécifiques, et non pas des étiquettes vagues de « jointure ». Par exemple :
- « Le client approuve la période de conservation ; le fournisseur de services gérés met en œuvre et examine la configuration trimestriellement. »
- « Le fournisseur de services gérés examine les alertes de sécurité ; le fournisseur prend en charge la réponse aux incidents au niveau de la plateforme. »
4. Intégrer le modèle dans les opérations quotidiennes
Une matrice des responsabilités n'a d'importance que si elle est utilisée sur le lieu de travail. Assurez-vous de :
- Référencez-le dans manuels d'exploitation et guides de jeu, afin que les ingénieurs puissent voir ce qu'il faut faire lors d'incidents et de changements.
- Aligner descriptions de services standard et énoncés de travaux avec ça, pour que les commerciaux ne promettent pas des tâches que vous n'effectuerez pas.
- Réfléchissez-y dans contrats et SLA, afin que les engagements juridiques correspondent à la réalité technique et aux capacités des fournisseurs en amont.
- Incluez-le dans packs d'accueil, afin que les nouveaux clients comprennent quelles actions les concernent et lesquelles restent de votre responsabilité.
La gestion centralisée de ces matrices dans ISMS.online – liées aux services de votre registre cloud, aux entrées de risques et aux enregistrements fournisseurs – permet de mettre à jour une matrice une seule fois et de voir la modification se propager automatiquement aux manuels d'exploitation, à la documentation et aux preuves d'audit. Il devient ainsi beaucoup plus facile de démontrer que la norme A.5.23 est applicable en pratique, et pas seulement dans un document de politique.
Quels sont les risques spécifiques au cloud que la norme A.5.23 met en évidence pour les MSP, et où ont-ils tendance à glisser ?
Pour les fournisseurs de services gérés (MSP), la norme A.5.23 concerne moins les histoires génériques de « violation de données dans le cloud » et davantage les attentes divergentes, faiblesses de configuration et mauvaise gestion du cycle de vie Dans les environnements partagés, les problèmes surviennent généralement lorsque les promesses marketing, les capacités du fournisseur et les comportements de l'équipe ne sont pas cohérents.
Où les fournisseurs de services gérés (MSP) se font-ils généralement piéger ?
Les schémas qui posent problème de manière récurrente incluent :
Dépendance excessive aux hypothèses de sécurité du fournisseur
Il est facile de parler de « sécurité dès la conception » en supposant que des tâches telles que les tests de restauration, l'analyse des journaux, la recherche de menaces ou le renforcement de la sécurité au niveau du locataire sont incluses dans un abonnement cloud. En réalité, bon nombre de ces activités sont… votre responsabilité en tant que MSPet parfois en partie celles de votre client. Lorsqu'elles ne sont pas consignées dans vos matrices de responsabilités et vos manuels d'exploitation, elles sont rarement exécutées de manière cohérente.
Accès privilégié excessif et mal encadré
Les fournisseurs de services gérés (MSP) détiennent souvent des rôles clés – comptes d'administrateur global, portails partenaires, identifiants d'accès d'urgence – qui s'étendent à de nombreux locataires. Si ces droits d'accès ne font l'objet d'aucune approbation, journalisation ou vérification rigoureuse, une simple authentification compromise ou un compte utilisé à mauvais escient peut engendrer un incident majeur affectant plusieurs locataires. La norme A.5.23 exige que vous preniez en compte ce risque dans vos registres d'actifs et de risques, et que vous mettiez en place des contrôles clairs.
SaaS non enregistré ou « fantôme »
Les équipes adoptent des outils SaaS qui traitent des données sensibles ou des données clients (pour le support, la collaboration, le développement, les ventes ou l'automatisation) sans jamais les intégrer à leur système de gestion de la sécurité de l'information (SGSI), à leur registre des fournisseurs ou à leurs processus de gestion des risques. Ces services échappent alors à leurs plans de surveillance, de réponse aux incidents et de sortie de crise.
Plans de sortie faibles ou non testés
Nombre de fournisseurs de services gérés (MSP) ne pensent à la migration que lorsqu'un fournisseur annonce l'arrêt d'un produit, une modification importante des tarifs ou une panne. Sans plan de migration formalisé – incluant l'exportation des données, la migration, la conservation des preuves et la communication avec les clients – vous improvisez au moment même où vous avez le plus besoin de contrôle.
Des SLA qui promettent plus que ce que l'on espère
Les contrats vous engagent parfois à respecter des objectifs de récupération, des durées de conservation ou des spécificités de résidence des données que l'infrastructure sous-jacente ne peut garantir. Lorsque la conception du service, les fonctionnalités du fournisseur de cloud et les termes du contrat ne sont pas cohérents, vous vous exposez à des risques inutiles.
A.5.23 vous fournit un cadre pour aborder ces problèmes de manière systématique :
- Inventaire et classification des services cloud : Vous savez ainsi où se concentre le risque.
- Effectuer évaluations des risques spécifiques au cloud qui traitent des problèmes liés aux multi-locataires, à l'accès privilégié et aux modes de défaillance des fournisseurs.
- Maintenir matrices de responsabilité Les tâches sont donc attribuées, prises en charge et examinées.
- Preuve étapes du cycle de vie – de l’intégration au départ – afin que chacun puisse constater que les changements, les évaluations et les départs sont des événements maîtrisés, et non des réactions.
Lorsque vous pouvez retracer un risque – par exemple, un accès excessif au portail partenaire – de votre registre aux matrices de responsabilité, puis aux enregistrements de modifications et aux actions d'amélioration, vous n'êtes pas seulement conforme à la section A.5.23 ; vous présentez également aux auditeurs et aux clients une version beaucoup plus solide des risques liés au cloud.
Comment un fournisseur de services gérés peut-il intégrer la norme A.5.23 à son SMSI sans tout repenser ?
On peut généralement couvrir A.5.23 par superposer une gouvernance spécifique au cloud à votre système de gestion de l'information (SGSI) existantPlutôt que de créer une structure parallèle, l'objectif est que toute personne connaissant la norme ISO 27001 puisse comprendre comment vous sélectionnez, contrôlez et mettez hors service les services cloud aussi facilement que les actifs ou fournisseurs traditionnels.
Comment intégrer la gouvernance du cloud à votre infrastructure existante ?
Une méthode simple mais efficace consiste à commencer par trois composants connectés, puis à les intégrer à votre système de gestion de la sécurité de l'information (SGSI) existant :
1. Politique d'utilisation du cloud / de sécurité du cloud
Complétez votre politique de sécurité de l'information existante avec un document ciblé qui :
- Définit ce qui constitue un service cloud dans votre contexte.
- Définit les seuils d'approbation (par exemple, qui peut autoriser un nouveau fournisseur).
- Les attentes des États en matière de diligence raisonnable, de configurations de référence, de surveillance, de gestion des incidents et de sortie.
Cette politique devient le point de référence pour les procédures et les documents connexes.
2. Enregistrement du service cloud
Créez un registre – souvent une liste d’actifs ou de fournisseurs ISMS.online – recensant au minimum :
- Nom du service et fournisseur.
- Propriétaire interne.
- Des fins commerciales.
- Types de données traitées et emplacements des données.
- Caractère critique et impact de la perte.
- Liens vers les contrats, les accords de protection des données, les certifications et les matrices de responsabilités.
Vous pouvez intégrer cela à votre inventaire d'actifs existant afin que les services cloud ne fonctionnent pas dans un univers séparé.
3. Matrices de responsabilité partagée
Pour les services les plus importants, élaborez et tenez à jour des matrices de responsabilités comme décrit précédemment. Concentrez-vous initialement sur :
- Votre plateforme cloud publique principale.
- Votre suite SaaS principale de productivité et de collaboration.
- Votre offre phare de sauvegarde et de reprise après sinistre gérée.
- Vos solutions SOC/XDR gérées ou solutions de sécurité en tant que service similaires.
Vous pouvez ensuite connecter ces composants aux éléments du SMSI que vous utilisez déjà :
- Gestion des risques: – relier les services cloud aux entrées et traitements des risques, en particulier dans les scénarios multi-locataires ou de défaillance du fournisseur.
- Gestion des fournisseurs: – joindre les contrats, les résumés de sécurité, les accords de protection des données et les rapports d’audit aux fournisseurs concernés ; consigner les examens et les décisions périodiques.
- Contrôles opérationnels : – référencer les étapes d’intégration, de changement, de révision et de sortie spécifiques au cloud dans vos processus existants de gestion des changements et de gestion des incidents.
- Gestion des preuves : – relier les incidents, les résultats des tests de sauvegarde, les analyses d'accès et les actions d'amélioration aux entrées et risques pertinents du cloud.
L'utilisation d'exemples concrets – par exemple, un SaaS interne, une solution client déployée sur le cloud public et une plateforme de niche mais essentielle – vous permet de démontrer aux auditeurs la reproductibilité du modèle sans avoir à documenter individuellement chaque service mineur. ISMS.online est conçu pour ce type de modélisation : politiques, registres, risques, fournisseurs, tâches et justificatifs sont regroupés, et des liens facilitent la compréhension de la gouvernance du cloud.
Quels contrats et SLA un MSP doit-il aligner pour démontrer A.5.23 à ses clients ?
Pour démontrer de manière convaincante le point A.5.23, vous devez vos accords en amont et en aval Pour que cela corresponde à votre gestion réelle des risques liés au cloud. Cela signifie que vos contrats et SLA avec les fournisseurs et sous-traitants, ainsi que vos conditions avec les clients, doivent tous refléter la même répartition des responsabilités et les mêmes capacités que celles documentées dans votre SMSI.
Que faut-il vérifier dans les contrats avec les fournisseurs en amont et les sous-traitants ?
Examinez attentivement les clauses de chaque accord qui affectent directement vos services et vos réclamations :
- Engagements en matière de sécurité et de disponibilité : – assurez-vous que les objectifs RPO/RTO, les SLA de disponibilité et la durabilité des données correspondent à la manière dont vous concevez vos services et aux engagements de vos propres SLA.
- Déclarations relatives à la localisation et à la résidence des données : – vous devriez pouvoir répondre avec assurance à la question « Où sont nos données ? », en précisant notamment les emplacements de sauvegarde et les régions de basculement.
- Notification et escalade des incidents : – vérifiez comment et quand les fournisseurs s’engagent à vous informer des incidents susceptibles d’affecter vos clients.
- Prise en charge des commandes principales : – vérifiez si les fonctionnalités telles que la journalisation détaillée, les clés de chiffrement gérées par le client, les sauvegardes immuables ou les contrôles d’accès avancés dont vous avez besoin sont explicitement disponibles et prises en charge.
- Mécanismes d'assurance : – identifier les certifications, les rapports d’assurance, les résumés de tests d’intrusion ou les droits d’audit contractuels que vous pouvez utiliser comme preuves dans votre propre système de gestion de la sécurité de l’information (SGSI) et vos rapports clients.
Vous n'aurez peut-être pas besoin de renégocier tous les contrats, mais vous devez comprendre et documenter les points sur lesquels les engagements d'un fournisseur ne correspondent pas à vos descriptions de service actuelles, et adapter vos propres offres ou architectures en conséquence.
Comment les contrats clients et les SLA doivent-ils être modifiés pour refléter le point A.5.23 ?
En aval, vos documents destinés aux clients doivent :
- Identifier clairement Quels services dépendent de quelles plateformes cloud ?, notamment lorsque cela affecte la localisation, la résilience ou le support des données.
- Expliquer Qui est responsable de quelles zones de contrôle ? – telles que les approbations d’accès des utilisateurs, l’utilisation acceptable, la classification, les obligations légales et le cycle de vie du contenu – conformément à vos matrices de responsabilité partagée.
- S'engager à objectifs de rétablissement, périodes de conservation et délais de communication des incidents que vos accords et conceptions en amont puissent garantir une livraison fiable.
- Référence ou lien vers, informations sur la responsabilité et la dépendance de manière à ce que les clients puissent comprendre sans avoir à lire votre SMSI.
Lorsque les contrats en amont, les matrices de responsabilités internes et les SLA en aval présentent tous la même information, il est beaucoup plus facile d'expliquer à un client ou à un auditeur comment vous gérez les risques liés au cloud conformément à la section A.5.23. La gestion de ces documents dans ISMS.online, en parallèle de vos politiques et de vos risques, vous aide à maintenir la cohérence du discours à mesure que les fournisseurs mettent à jour leurs conditions, que la réglementation évolue et que les clients deviennent plus exigeants.
Comment un fournisseur de services gérés (MSP) peut-il utiliser ISMS.online pour garder le contrôle de la norme A.5.23 face à l'évolution des services cloud ?
ISMS.online vous aide à maîtriser la norme A.5.23 en transformant la gouvernance du cloud en un outil performant. système connecté mis à jour en continuPlutôt qu'un ensemble de documents statiques qui ne suivent plus l'évolution de votre infrastructure, votre vision du SMSI reste à jour, auditable et explicable, même lors de l'adoption, la modification ou la mise hors service de services cloud.
À quoi ressemble la gestion quotidienne de l'A.5.23 dans ISMS.online ?
Dans une configuration classique, votre équipe utiliserait ISMS.online pour :
Tenir un registre de service cloud actif
- Consignez chaque service cloud en indiquant son propriétaire, sa finalité, les types de données, l'emplacement des données et son niveau de criticité.
- Services d'étiquetage utilisés en interne par rapport à ceux utilisés pour fournir des services gérés.
- Associez chaque entrée aux politiques, risques, fournisseurs et matrices de responsabilités pertinents.
Identifier et suivre les risques et traitements spécifiques au cloud
- Créez des entrées de risque pour l'exposition multi-locataires, les comptes inter-locataires puissants, la résidence des données, la dépendance vis-à-vis du fournisseur et les dépendances API.
- Attribuer les traitements, les responsables et les dates de révision.
- Utilisez les travaux et projets liés à la plateforme pour suivre les actions correctives et d'amélioration.
Stockez les contrats, les certifications et les vérifications préalables en un seul endroit.
- Téléchargez directement les contrats fournisseurs, les accords de protection des données, les résumés de sécurité et les rapports d'assurance dans les dossiers des fournisseurs.
- Consignez les résultats et les décisions des examens afin de pouvoir démontrer que le risque lié au fournisseur est géré dans le temps.
Centraliser les matrices de responsabilité partagée
- Maintenir une matrice de référence par service cloud majeur ou famille de services.
- Intégrez les matrices de liaison aux politiques, aux descriptions de services, aux entrées de risques et aux dossiers des fournisseurs.
- Utilisez-les comme points de référence lors de la mise à jour des manuels d'exploitation, des SLA et des supports de formation.
Activités liées au cycle de vie des preuves
- Sélection des journaux, intégration, approbations de la configuration de référence, revues des modifications, réévaluations périodiques et étapes de sortie sous forme de tâches ou d'éléments de travail liés.
- Associer les incidents connexes, les tests de sauvegarde, les revues d'accès et les améliorations aux services et risques pertinents.
Lors de l'intégration d'une nouvelle plateforme, vous pouvez cloner une entrée existante, ajuster la configuration et les responsabilités, et la connecter aux risques et aux fournisseurs en quelques minutes. Lors de la mise hors service d'un service, vous pouvez consigner les décisions relatives à la migration des données, à leur effacement et à la conservation des preuves au même endroit.
Pour les audits, les questionnaires clients ou les réunions du conseil d'administration, vous pouvez constituer un dossier de preuves A.5.23 ciblé directement depuis ISMS.online : la politique cloud, le registre actuel, des exemples de matrices de responsabilités, les principaux risques et traitements liés au cloud, la diligence raisonnable des fournisseurs et un exemple de documentation sur le cycle de vie et les incidents. Cette capacité à présenter un récit cohérent et complet permet à un MSP de paraître maître de sa gouvernance cloud plutôt que de constamment réagir. Si vous souhaitez que vos clients et auditeurs vous considèrent comme faisant partie de ce premier groupe, investir dans une structuration adéquate de la conformité A.5.23 au sein d'ISMS.online constitue une étape cruciale.
