Pourquoi les chaînes d'approvisionnement des fournisseurs de services gérés (MSP) constituent désormais votre principale surface d'attaque
Les fournisseurs de services gérés modernes sont confrontés à des risques croissants liés à leurs chaînes d'approvisionnement TIC, et pas seulement à leurs propres centres de données. Les outils, plateformes et partenaires en amont peuvent devenir des points de défaillance uniques qui, en cas de compromission ou d'indisponibilité, affectent simultanément de nombreux clients et services. L'annexe A.5.21 a pour but de vous aider à comprendre ces dépendances, à définir des exigences de sécurité claires avec vos fournisseurs et clients, et à intégrer pleinement le risque lié à la chaîne d'approvisionnement à votre système de gestion de la sécurité de l'information (SGSI), et non à le considérer comme une simple considération a posteriori.
Pour de nombreux fournisseurs de services gérés, la chaîne d'approvisionnement en outils, plateformes et partenaires est devenue l'un des aspects les plus risqués de leur environnement, au même titre que leur propre centre de données. Ces composants partagés sont essentiels à leurs revenus, à leurs contrats et à leurs engagements réglementaires. Lorsqu'un seul d'entre eux tombe en panne ou est compromis, l'impact peut se propager en cascade à de nombreux clients en quelques heures. C'est pourquoi l'annexe A.5.21 est si importante pour transformer ce réseau de dépendances en un système que vous concevez et gérez de manière responsable.
Les fournisseurs de services gérés (MSP) modernes héritent des risques liés à la nature mutualisée des plateformes de gestion à distance, des services cloud, des fournisseurs d'identité et des outils spécialisés qui servent d'intermédiaires entre eux et leurs clients. Une simple compromission en amont peut donner à un attaquant un accès privilégié à une grande partie de votre clientèle. De même, une panne d'une plateforme centrale peut déconnecter plusieurs clients simultanément, quelle que soit la qualité de votre infrastructure.
Des chaînes d'approvisionnement solides commencent par savoir de qui on dépend réellement.
La nouvelle réalité du risque lié à la chaîne d'approvisionnement des MSP
Pour les fournisseurs de services gérés (MSP), la nouvelle réalité est que les attaques et les pannes se propagent désormais plus rapidement via les plateformes TIC partagées qu'à travers les réseaux individuels des clients. À mesure que vous intégrez des outils de gestion à distance, des services cloud, des plateformes d'identité et des produits de sécurité à vos offres, chaque composant partagé devient un point de défaillance unique potentiel. L'annexe A.5.21 vise à vous aider à prendre conscience de cette réalité et à mettre en place des mesures de contrôle adaptées.
Les fournisseurs de services gérés (MSP) modernes héritent la majeure partie de leurs risques liés à la chaîne d'approvisionnement des plateformes cloud, des outils SaaS et des sous-traitants qu'ils intègrent à leurs services. Lors du développement de nouvelles offres, il est naturel d'ajouter des plateformes spécialisées, des outils de surveillance, des fournisseurs de sauvegarde et des services de sécurité à un ensemble de fonctionnalités de base.
Le rapport « État de la sécurité de l'information 2025 » montre que la majorité des organisations ont subi au moins un incident de sécurité au cours de l'année écoulée, incident qui provenait d'un tiers ou d'un fournisseur.
Au fil du temps, cette croissance engendre des chaînes de dépendances denses et complexes : outils de surveillance à distance hébergés sur le cloud public, plateformes d’identité intégrées aux environnements clients, fournisseurs de sauvegarde répliquant les données entre les régions et outils de sécurité spécialisés intégrés via des API. Les attaquants n’ont plus besoin de cibler chaque client individuellement. La compromission d’un seul service en amont peut leur donner accès à de nombreux environnements gérés, ou permettre à un ransomware de se propager rapidement entre clients utilisant les mêmes outils. Les analyses d’incidents affectant la chaîne d’approvisionnement logicielle illustrent précisément ce schéma : la compromission d’un fournisseur ou d’un composant largement utilisé peut impacter simultanément un grand nombre d’organisations en aval (analyse des attaques de la chaîne d’approvisionnement logicielle).
Les pannes se comportent de la même manière. Une défaillance d'un fournisseur d'identité central ou d'une plateforme de gestion à distance peut mettre hors service plusieurs clients, entraîner des pénalités contractuelles et attirer l'attention des autorités de réglementation, même si votre propre infrastructure n'est pas affectée. Les recommandations sectorielles relatives à l'évaluation et à la gestion des risques de cybersécurité liés à la chaîne d'approvisionnement soulignent souvent comment une perturbation ou une compromission des services cloud ou d'identité partagés peut provoquer des pannes simultanées et impacter l'activité de nombreux clients, tout en engendrant des conséquences contractuelles et réglementaires pour les fournisseurs qui en dépendent (aperçu des risques de cybersécurité liés à la chaîne d'approvisionnement). L'annexe A.5.21 vise précisément cet impact technique et contractuel global, et non pas seulement les vulnérabilités isolées.
Dans de nombreux fournisseurs de services gérés (MSP), les indicateurs de sécurité n'ont pas suivi cette évolution. Les équipes continuent de surveiller les événements de périmètre, les taux de correctifs et les alertes sur les terminaux, mais ont peu de visibilité sur les vulnérabilités héritées ou les incidents liés aux fournisseurs. Sans une vision claire des dépendances en amont et de leurs profils de risque, vous naviguez à vue là où les défaillances sont les plus susceptibles d'avoir des conséquences graves. C'est pourquoi vous avez besoin d'une vision globale de la chaîne d'approvisionnement au sein de votre système de gestion de la sécurité de l'information (SGSI), et pas seulement d'indicateurs réseau.
Là où la visibilité se dégrade vraiment
La visibilité se dégrade généralement au sein de la chaîne d'approvisionnement « parallèle » : outils, services et partenaires qui se sont glissés hors des procédures d'achat officielles. Ces décisions, souvent perçues comme ponctuelles sur le moment, s'intègrent en réalité à votre modèle de dépendance permanent.
La plupart des fournisseurs de services gérés (MSP) peuvent énumérer leurs principaux fournisseurs de mémoire, mais rares sont ceux qui peuvent dresser un tableau complet de leurs véritables dépendances. Les services freemium adoptés par les ingénieurs, les outils pilotes « temporaires » qui n’ont jamais été abandonnés et les plateformes imposées par les clients et que vous avez accepté de prendre en charge contribuent tous à cette complexité.
Le problème est que les attaquants et les organismes de réglementation ne se soucient pas de savoir si une dépendance a été formellement approuvée ou adoptée discrètement. Si une faille de sécurité se propage à vos environnements gérés, vos clients exigeront des explications de votre part. L'annexe A.5.21 considère ces relations comme faisant partie du champ d'application. Elle vous demande de les intégrer à votre cartographie de la chaîne d'approvisionnement, de les classifier et de définir pour chacune d'elles le niveau de sécurité « suffisant » en fonction des risques.
Une première étape pratique consiste à cartographier la zone d'impact de vos composants partagés les plus critiques. Pour chaque outil ou plateforme majeur, estimez le nombre de clients, les types de données et les services qui en dépendent. Constater qu'une seule infrastructure de gestion à distance sous-tend une part importante de votre chiffre d'affaires est souvent le moment où le risque lié à la chaîne d'approvisionnement cesse d'être abstrait et exige des contrôles structurés.
Pourquoi votre conseil d'administration devrait s'en soucier autant que vos ingénieurs
Votre conseil d'administration et votre direction générale doivent considérer la sécurité de la chaîne d'approvisionnement des TIC comme un enjeu de gouvernance, et non comme une simple préoccupation technique pour les ingénieurs. Les clients, les assureurs et les organismes de réglementation demandent de plus en plus comment les risques liés aux tiers et à l'externalisation informatique sont identifiés, évalués et maîtrisés, et ils attendent des réponses cohérentes qui dépassent le cadre de l'équipe de sécurité. Les organismes sectoriels qui surveillent les menaces pesant sur les logiciels et la chaîne d'approvisionnement des TIC constatent que les parties prenantes externes s'intéressent davantage à la manière dont les organisations gèrent les risques liés aux tiers, et pas seulement aux technologies qu'elles déploient (menace croissante d'attaques ciblant la chaîne d'approvisionnement des logiciels).
Selon l'enquête 2025 d'ISMS.online, les clients attendent de plus en plus des fournisseurs qu'ils s'alignent sur des cadres formels tels que l'ISO 27001, l'ISO 27701, le RGPD ou le SOC 2 plutôt que de se fier à des affirmations génériques de bonnes pratiques.
Lorsque les parties prenantes constatent que vos services gérés s'appuient sur ceux d'autres fournisseurs potentiellement vulnérables, elles exigent des preuves de votre compréhension et de votre maîtrise de ces liens. La sécurité de la chaîne d'approvisionnement devient alors un enjeu majeur pour la direction, car toute défaillance à ce niveau peut entraîner simultanément une interruption d'activité, un contrôle réglementaire accru et une atteinte à votre réputation.
Les dirigeants ont généralement besoin d'être assurés que :
- Les outils et partenaires critiques en amont sont identifiés, font l'objet d'une évaluation des risques et sont liés contractuellement à des exigences de sécurité claires.
- L'organisation comprend quels clients et services seraient affectés par certaines défaillances en amont.
- Il existe des procédures éprouvées pour les incidents fournisseurs qui couvrent la réponse technique, la communication et les obligations contractuelles.
Sans cette garantie, les questions délicates risquent de surgir au pire moment lors d'une panne, d'une violation de données ou d'un audit. En considérant l'annexe A.5.21 comme le fondement formel de votre assurance qualité pour la chaîne d'approvisionnement TIC, vous offrez aux dirigeants une explication standardisée et fiable, plutôt que des justifications improvisées sous pression.
Demander demoAnnexe A.5.21 et nouvelle définition de l’assurance de la chaîne d’approvisionnement des TIC
L’annexe A.5.21 vous invite à définir, documenter et maintenir des exigences appropriées en matière de sécurité de l’information avec vos fournisseurs et clients TIC. Concrètement, vous devez savoir de qui vous dépendez, ce que vous attendez d’eux, ce qu’ils attendent de vous et comment ces exigences sont vérifiées dans le temps. Pour un fournisseur de services gérés (MSP), cela signifie prendre conscience de son rôle au sein des chaînes d’approvisionnement TIC de nombreux clients, en plus de la gestion de sa propre chaîne. Cette approche est conforme à la description du contrôle A.5.21 dans la norme ISO/IEC 27001:2022, présentée dans son catalogue des contrôles de sécurité de l’information pour les chaînes d’approvisionnement TIC (Présentation de la norme ISO/IEC 27001:2022).
Presque toutes les organisations interrogées dans le cadre de l'enquête 2025 d'ISMS.online ont indiqué que l'obtention ou le maintien de certifications de sécurité telles que l'ISO 27001 ou le SOC 2 constituait une priorité absolue.
Appliquée sérieusement, l'annexe A.5.21 permet de passer d'une approche intuitive à une pratique documentée et fondée sur les risques pour l'assurance de la chaîne d'approvisionnement des TIC. Elle s'appuie sur l'ensemble des contrôles de l'annexe A relatifs aux relations avec les fournisseurs, aux contrats et au suivi, et les applique spécifiquement aux produits et services TIC. Comprendre son articulation avec les annexes A.5.19, A.5.20 et A.5.22 vous offre un cadre pour mettre en œuvre cette approche sans avoir à repenser l'intégralité de votre système de gestion de la sécurité de l'information (SGSI).
Une plateforme ISMS intégrée telle que ISMS.online peut vous aider à centraliser ces informations en reliant les fournisseurs, les clients, les services, les risques et les contrôles de l'annexe A, afin qu'ils soient faciles à consulter et à mettre à jour au fur et à mesure de l'évolution de votre entreprise.
Ces informations sont d'ordre général et ne constituent pas un avis juridique ; les organisations doivent solliciter des conseils professionnels appropriés pour leurs décisions réglementaires.
Ce que l'annexe A.5.21 prévoit réellement
L’annexe A.5.21 vous invite à considérer la sécurité de la chaîne d’approvisionnement des TIC comme une responsabilité partagée et continue, et non comme une simple clause contractuelle ponctuelle. Elle souligne que les attentes doivent être fondées sur une analyse des risques, documentées et mises à jour régulièrement, au lieu d’être présumées ou définies une fois pour toutes. Pour les fournisseurs de services gérés (MSP), cela implique de définir des attentes en amont et en aval, et de vérifier leur pertinence face à l’évolution des services et des risques.
L’annexe A.5.21 est associée à trois contrôles étroitement liés :
- A.5.19, qui traite des politiques relatives aux relations avec les fournisseurs.
- A.5.20, qui vise à garantir que la sécurité de l'information soit prise en compte dans les accords avec les fournisseurs.
- A.5.22, qui traite du suivi, de l'examen et de la gestion des changements des services des fournisseurs.
Ensemble, ces contrôles peuvent se traduire, en termes simples, par : identifier votre chaîne d'approvisionnement TIC, définir les exigences de sécurité de l'information que vous attendez d'elle, intégrer ces exigences dans vos processus de sélection, de contractualisation et de supervision des fournisseurs, et maintenir cette supervision malgré l'évolution des services. L'annexe A.5.21 détaille les services et produits TIC, en amont comme en aval. Ces intitulés et regroupements de contrôles suivent la structure publiée dans la norme ISO/IEC 27001:2022, qui présente les contrôles de l'annexe A et leurs domaines d'intervention pour la sécurité des fournisseurs et de la chaîne d'approvisionnement TIC (présentation de la norme ISO/IEC 27001:2022).
Pour un fournisseur de services gérés (MSP), la situation se complexifie. Vous êtes à la fois client et fournisseur. Vous dépendez des services TIC en amont pour proposer vos offres et vous êtes un maillon essentiel des chaînes d'approvisionnement TIC de vos clients. L'annexe A.5.21 exige que vous gériez ces deux aspects de manière cohérente, en tenant compte des risques et en intégrant cette gestion dans vos processus quotidiens, plutôt que de la déléguer à des documents isolés.
Transformer un texte standard en quelque chose que tout le monde peut comprendre
Vos équipes seront plus enclines à s'engager si vous traduisez le langage de la norme en un ensemble restreint d'engagements clairs et concrets. Ces engagements doivent décrire vos actions réelles, dans des termes compréhensibles par les ingénieurs, les responsables de comptes et les juristes, plutôt que de simplement citer la norme.
Vous pourriez reformuler l'annexe A.5.21 sous forme d'engagements tels que :
- « Nous vérifions et classons les fournisseurs et les plateformes TIC sur lesquels nous nous appuyons et nous les utilisons lorsqu'ils répondent aux critères de sécurité convenus. »
- « Nous définissons et documentons les responsabilités de chacun en matière de mesures de sécurité pour chaque service géré que nous vendons. »
- « Nous assurons un suivi régulier de nos principaux fournisseurs et services et réagissons rapidement et de manière transparente en cas de changement ou de problème. »
Une fois ces traductions réalisées, il devient beaucoup plus facile de repérer les éléments de l'annexe A.5.21 déjà en place, tels que les contrôles d'intégration des fournisseurs, les modèles de contrats ou les revues périodiques. Cela permet également de mettre en évidence les pratiques ponctuelles, non documentées ou dépendant du personnel. Cette cartographie constitue un point de départ pour le travail de conception plus détaillé en amont et en aval qui suivra.
L’annexe A.5.21 exige que vos exigences soient proportionnées au risque et non transposées aveuglément d’une relation à l’autre. Les fournisseurs et clients à fort impact nécessitent généralement une diligence accrue et des obligations plus strictes que ceux à faible impact ; ce même principe renforce la solidité de vos contrats en aval face aux autorités de réglementation et aux auditeurs.
Ce contrôle n'implique pas que vous deviez imposer des exigences de sécurité identiques et détaillées à chaque fournisseur ou client. Il vous demande simplement de justifier vos exigences au regard des risques. Une plateforme cloud critique hébergeant des données clients exige une diligence raisonnable plus approfondie, des clauses contractuelles plus strictes et une surveillance plus intensive qu'un outil non critique à faible risque.
La même logique s'applique en aval. Un service géré fourni à un hôpital ou à un établissement financier est soumis à des obligations et à un contrôle différents de ceux appliqués à une petite entreprise non réglementée. Votre mise en œuvre de l'annexe A.5.21 est crédible lorsque ces différences sont clairement visibles dans vos évaluations des risques et dans la structuration de vos accords, et non lorsque chaque relation utilise une formulation standardisée, sans tenir compte de son impact.
L’harmonisation de l’annexe A.5.21 avec les référentiels que vous utilisez déjà, tels que SOC 2, les recommandations reconnues en matière de cybersécurité ou les recommandations nationales relatives à la chaîne d’approvisionnement, peut s’avérer utile. Les bonnes pratiques en matière de chaîne d’approvisionnement, issues des fournisseurs et des experts en sécurité, encouragent à recenser les objectifs de contrôle communs aux différentes normes, comme l’ISO 27001, SOC 2 et les référentiels nationaux de cybersécurité, afin d’éviter que les équipes ne gèrent plusieurs ensembles d’exigences contradictoires (aperçu des pratiques de sécurité de la chaîne d’approvisionnement). Dans ce contexte, la « hiérarchisation » consiste simplement à regrouper les fournisseurs et les clients selon quelques niveaux d’impact, plutôt que de considérer chaque relation comme unique.
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.
Contrôles en amont et en aval dans un contexte MSP
Dans un fournisseur de services gérés (MSP), le terme « amont » désigne les fournisseurs, les plateformes et les sous-traitants dont vous dépendez, tandis que le terme « aval » désigne les clients et les locataires qui dépendent de vous. L’annexe A.5.21 est plus facile à mettre en œuvre lorsque ces relations sont considérées comme distinctes mais liées, avec des responsabilités et des attentes clairement définies dans chaque sens. Cette structure transforme les problématiques abstraites de la chaîne d’approvisionnement en contrats, en procédures et en tableaux de bord exploitables.
Un modèle amont/aval clair transforme les textes standards en contrats, manuels d'exploitation et tableaux de bord opérationnels. Vous pouvez définir comment sélectionner et contrôler vos fournisseurs, comment partager les responsabilités avec vos clients et comment réagir en cas d'incident, quel que soit le sens de la démarche. Une fois cette structure formalisée, sa mise en œuvre opérationnelle dans les outils et les comportements devient beaucoup plus simple.
Définition des relations en amont, en aval et hybrides
Votre première tâche consiste à identifier et à classer les relations externes dont vous dépendez, au lieu de les considérer toutes comme de simples « fournisseurs » ou « clients ». Cette classification détermine les parties de l’annexe A.5.21 les plus pertinentes et les domaines sur lesquels concentrer vos efforts de conception. Elle permet également d’établir un langage commun au sein de votre organisation lors des discussions sur les risques liés à la chaîne d’approvisionnement.
Commencez par recenser les parties externes et classez-les selon deux critères : sont-elles vos fournisseurs ou les leur fournissez-vous ? Et quel est leur rôle essentiel dans vos services ? Un fournisseur TIC en amont peut être un fournisseur d’infrastructure cloud, un outil de surveillance à distance, une plateforme de sauvegarde ou un partenaire spécialisé en sécurité. Les parties en aval sont vos clients de services gérés, y compris ceux pour lesquels vous agissez en tant que sous-traitant de données au sens de la législation sur la protection des données.
Certaines relations sont hybrides. Un fournisseur de services gérés (MSP) homologue, dans le cadre d'un accord de cogestion, vous fournit certaines fonctionnalités et dépend en retour de vos services. Un client qui héberge son propre environnement cloud mais vous demande de l'administrer brouille la frontière entre la plateforme client et l'environnement en amont. Ces relations hybrides exigent une attention particulière, car il est facile que des responsabilités importantes soient assumées par les deux parties ou par aucune.
Une fois ces rôles recensés, vous pouvez définir les catégories de contrôles applicables à chaque rôle. Pour les relations en amont, la diligence raisonnable, l'intégration technique sécurisée, la notification des incidents et les contrôles des sous-traitants deviennent essentiels. Pour les relations en aval, la responsabilité partagée, les exigences minimales de sécurité et les obligations envers le client sont plus importantes. Les dispositifs hybrides nécessitent une combinaison de ces éléments et des limites clairement définies afin d'éviter toute lacune.
Utiliser des niveaux de risque pour structurer
La hiérarchisation des risques permet de transformer une longue liste de fournisseurs et de clients en un ensemble plus exploitable. En regroupant les relations en quelques classes basées sur l'impact, vous pouvez définir des ensembles de contrôles standard pour chaque niveau au lieu de concevoir chaque relation de A à Z.
Vous pourriez, par exemple, créer trois niveaux pour les fournisseurs en amont :
- Niveau 1 : plateformes critiques disposant d’un accès privilégié ou hébergeant des données clients.
- Niveau 2 : services de soutien importants avec un accès direct limité aux systèmes des clients.
- Niveau 3 : outils à faible risque sans accès aux données sensibles ni aux environnements de production.
En aval, vous pourriez adopter des niveaux tels que « réglementé », « haute disponibilité » et « standard », en fonction de la sensibilité des données et de l’impact des pannes sur l’activité.
Chaque combinaison de niveaux amont et aval engendre des attentes différentes. Une plateforme amont de niveau 1, utilisée par un client du secteur de la santé soumis à une réglementation stricte, exige une assurance plus poussée et des contrôles plus rigoureux qu'un outil de niveau 2 destiné à un client standard. Documenter ces combinaisons selon des modèles simples – par exemple, « MSP – hyperscaler – client soumis à une réglementation » versus « MSP – distributeur – MSP – entreprise » – permet de concevoir des ensembles de contrôles standardisés au lieu de repartir de zéro pour chaque nouvelle relation.
Une manière concise de visualiser cela consiste à utiliser une petite matrice qui montre comment les responsabilités diffèrent selon le type de relation.
| Type de relation | Responsabilités en amont (exemples) | Responsabilités en aval (exemples) |
|---|---|---|
| MSP – plateforme cloud – client réglementé | Certifications, notification d'incident, segmentation, journaux d'accès | Approbations, obligations en matière de protection des données, communication avec les clients concernant la sécurité |
| MSP – Outil de sécurité SaaS – Clientèle mixte | Intégration sécurisée, conception des rôles, surveillance, évaluation des fournisseurs | Sensibilisation du client à la portée de l'outil, consentement le cas échéant |
| MSP – MSP homologue (cogéré) – client | Définition des limites, gestion conjointe des incidents, accès partagé | Le client comprend la répartition des tâches et les procédures d'escalade. |
Comme le suggère le tableau, les responsabilités varient considérablement entre, par exemple, un scénario de fournisseur de services cloud hyperscaler et un modèle de fournisseur de services gérés en cogestion. Concrètement, vous pouvez commencer par cartographier vos relations actuelles selon l'un de ces modèles, en identifiant les responsabilités de chacun, puis standardiser vos clauses contractuelles et vos procédures internes en fonction de ces modèles.
Conception de contrôles en amont pour les fournisseurs et les sous-processeurs
Les contrôles en amont définissent la manière dont vous sélectionnez, intégrez, surveillez et mettez fin aux relations avec les fournisseurs et les plateformes que vous utilisez. Un cycle de vie simple et reproductible transforme la confiance envers les fournisseurs, initialement présumée, en une confiance étayée par des évaluations des risques, des contrats et une configuration. L'annexe A.5.21 exige que ce cycle de vie soit proportionné au risque et appliqué de manière cohérente aux fournisseurs les plus importants.
Une bonne conception en amont transforme la confiance, initialement basée sur un jugement informel, en une décision formalisée. Cela implique de comprendre le rôle de chaque fournisseur, les risques encourus, les contrôles qu'il met en place et ceux que vous devez assurer vous-même. Une approche par cycle de vie des risques simplifie cette gestion et rassure les auditeurs, qui ont ainsi la certitude que vos fournisseurs ne sont pas perçus comme une boîte noire.
Élaboration d'un cycle de vie des fournisseurs reconnu par les auditeurs
Les auditeurs recherchent généralement un cycle de vie clair et fondé sur les risques pour les fournisseurs critiques : comment évaluer un fournisseur avant de collaborer avec lui, comment intégrer les contrôles lors de son adoption, comment assurer un suivi continu et comment se retirer de la collaboration en toute sécurité. Si vous pouvez démontrer ces étapes et les preuves qui les sous-tendent, votre section A.5.21 sera crédible et complète. Les recommandations en matière de risques fournisseurs d’organismes tels que SANS décrivent les cycles de vie des fournisseurs fondés sur les risques – couvrant la sélection, l’intégration, le suivi continu et la sortie – comme une caractéristique essentielle d’une gestion mature de la sécurité des tiers (Livre blanc de SANS sur les risques fournisseurs).
Le rapport « État de la sécurité de l’information 2025 » indique que la majorité des organisations ont déjà renforcé la gestion des risques liés aux tiers et prévoient d’y investir davantage.
Un cycle de vie pratique en amont comprend quatre étapes : vérification préalable, intégration, suivi courant et fin de collaboration. Pour chaque étape, définissez les attentes vis-à-vis de chaque niveau de fournisseur et les éléments justificatifs nécessaires pour attester de la réalisation de ces activités.
Étape 1 : Effectuer une vérification préalable fondée sur les risques
L’analyse de la conformité fondée sur les risques consiste à recueillir suffisamment d’informations pour comprendre le niveau de sécurité d’un fournisseur et son adéquation à vos besoins. Cela inclut généralement des certifications indépendantes, des déclarations de sécurité générales, des résumés de tests, les rôles respectifs du fournisseur dans le traitement des données personnelles et des informations sur les sous-traitants. Le résultat doit être un rapport d’évaluation complet expliquant pourquoi le fournisseur est acceptable au niveau de sécurité choisi.
Étape 2 : Intégration avec des contrôles techniques et contractuels concrets
L'intégration transforme l'évaluation en mesures de contrôle concrètes. Pour une plateforme critique, cela peut inclure la configuration d'une authentification forte, la restriction des rôles d'administrateur, l'activation et l'intégration de la journalisation, ainsi que la définition des délais et des points de contact pour la notification des incidents. Une simple liste de contrôle d'intégration permet de s'assurer qu'aucune étape n'est oubliée et qu'une personne est clairement responsable de chacune d'elles.
Étape 3 : Maintenir la surveillance des activités courantes
Le contrôle des activités courantes doit être souple mais rigoureux. Pour les fournisseurs à fort impact, définissez des cycles de revue afin de vérifier le maintien des certifications, le respect des engagements de sécurité et l'absence de changements majeurs à votre insu. Pour les fournisseurs de second rang, les revues peuvent être déclenchées par des événements tels que des modifications de service, de nouveaux flux de données ou des incidents. Les comptes rendus de ces revues, même succincts, démontrent que le contrôle est actif et non présumé.
Étape 4 : Quittez la zone en toute sécurité et mettez à jour votre carte de la chaîne d’approvisionnement
La procédure de sortie est souvent négligée, mais elle est pourtant cruciale. Lorsque vous cessez de collaborer avec un fournisseur ou que vous passez à une nouvelle plateforme, il est indispensable de définir un processus de révocation des accès, de restitution ou de suppression sécurisée des données et de mise à jour de votre documentation afin de garantir l'exactitude de votre cartographie de la chaîne d'approvisionnement. Une simple liste de contrôle de sortie et une entrée de registre mise à jour attestent que la relation a été clôturée de manière contrôlée.
Les auditeurs n’attendent pas la perfection, mais ils s’attendent à constater qu’un tel cycle de vie existe, qu’il est fondé sur les risques et qu’il est appliqué dans la pratique pour les fournisseurs critiques.
Aucun fournisseur n'est parfait, et l'annexe A.5.21 n'exige pas la perfection. Elle attend de vous que vous preniez des décisions éclairées et documentées concernant les risques hérités et les mesures de contrôle compensatoires mises en œuvre, et que vous soyez en mesure d'expliquer ces décisions aux auditeurs et aux clients.
Tous les fournisseurs ne répondent pas à tous les critères de contrôle idéaux, et ce n'est pas nécessaire. L'important est votre capacité à expliquer pourquoi une relation est acceptable compte tenu des risques qu'elle comporte. La hiérarchisation des niveaux de contrôle est utile, mais il est également essentiel de déterminer clairement dans quels cas vous êtes à l'aise avec l'adoption des contrôles du cadre de sécurité interne du fournisseur et dans quels cas vous préférez des mesures compensatoires.
Par exemple, si un grand fournisseur de services cloud possède des certifications largement reconnues et applique des normes de sécurité rigoureuses, il est généralement raisonnable de s'y fier pour de nombreux contrôles sous-jacents, à condition de gérer votre configuration de manière sécurisée. En revanche, pour une plateforme spécialisée plus petite, offrant moins de garanties formelles, vous pouvez décider de limiter son périmètre, d'exiger des engagements contractuels spécifiques ou d'ajouter vos propres mécanismes de surveillance et de test.
La gestion des incidents mérite une attention particulière. Pour les plateformes critiques, des engagements clairs doivent être pris quant à la rapidité avec laquelle vous serez informé(e) d'un problème de sécurité, aux informations que vous recevrez et à la manière dont vous pourrez coordonner les réponses pour protéger vos clients. Il est préférable que ces attentes soient consignées dans des contrats ou des accords de service plutôt que de rester de simples accords informels.
Le fait de consigner ces jugements dans votre registre des risques et votre déclaration d'applicabilité démontre aux auditeurs que l'annexe A.5.21 est appliquée de manière réfléchie et non automatique. Votre déclaration d'applicabilité est simplement la liste formelle des contrôles prévus à l'annexe A, dans laquelle vous expliquez lesquels s'appliquent, comment et pourquoi.
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é.
Concevoir des mécanismes de contrôle en aval pour les clients et leurs obligations
Les contrôles en aval définissent la répartition des responsabilités avec les clients et les attentes à leur égard pour garantir la sécurité des services. Pour les fournisseurs de services gérés (MSP), des contrôles en aval clairs réduisent le risque d'être tenus responsables des vulnérabilités imputables au client et démontrent aux autorités de réglementation que des attentes appropriées et documentées ont été établies. L'annexe A.5.21 souligne l'importance de rendre ces attentes explicites, exécutoires et étayées par des preuves.
En pratique, le contrôle en aval consiste à définir des limites et à s'assurer que chacun les comprenne. Il s'agit de définir vos actions par défaut, les obligations des clients et la manière dont vous démontrerez que les deux parties respectent leurs responsabilités. Lorsque ce processus est bien mené, les discussions relatives aux incidents, aux nouvelles exigences ou aux services supplémentaires s'appuient sur une compréhension partagée plutôt que sur un désaccord quant aux responsabilités de chacun.
Conception de modèles de responsabilité partagée spécifiques aux services
Un modèle de responsabilité partagée utile explique clairement aux clients les aspects de la sécurité dont vous êtes responsable et ceux dont ils sont responsables pour un service donné. Les répartitions varient selon les familles de services ; il est donc nécessaire d'avoir un modèle simple et adapté à chaque service, reflétant sa conception réelle. Dans ce contexte, un modèle de responsabilité partagée décrit simplement la répartition des responsabilités en matière de sécurité entre vous et le client.
Pour chaque famille de services, élaborez un modèle de responsabilité partagée qui répond à trois questions :
- Quelle configuration et quel système de surveillance proposez-vous par défaut ?
- Que doit faire le client pour que cela soit efficace ?
- Comment prouverez-vous que les deux parties font leur part ?
Par exemple, pour un service Microsoft 365 géré, vos responsabilités pourraient inclure la configuration des stratégies d'accès conditionnel, l'activation de la journalisation et la surveillance des alertes importantes. Les responsabilités du client pourraient inclure la mise à jour des informations utilisateur, l'application des politiques d'utilisation acceptable et la réponse rapide aux notifications de sécurité. La validation du modèle pourrait s'effectuer par le biais de rapports de configuration périodiques et d'approbations client documentées.
Ces modèles doivent être rédigés dans un langage accessible, réutilisés dans tous les contrats et propositions, et accompagnés de guides internes expliquant à vos équipes comment respecter vos engagements. Lorsque les clients comprennent le modèle dès le départ, les discussions ultérieures concernant les incidents de sécurité ou les obligations supplémentaires s'appuient sur cette compréhension partagée plutôt que sur des attentes ponctuelles.
Définir les obligations des clients et gérer les cas de non-conformité
Les obligations du client décrivent ce que celui-ci doit faire pour que vos services soient efficaces et pour que son propre risque reste dans des limites acceptables. L’annexe A.5.21 exige que vous définissiez clairement ces obligations, que vous en contrôliez le respect dans la mesure du possible et que vous décidiez à l’avance de la manière dont vous gérerez les écarts.
Les contrôles en aval comprennent souvent des obligations telles que :
- Maintenance des systèmes d'exploitation pris en charge.
- S'assurer que le personnel suive une formation de sensibilisation à la sécurité.
- Activer l’authentification multifacteurs sur leurs propres systèmes.
- Vous informer rapidement des changements pertinents dans leur environnement.
Ces obligations doivent être adaptées au service et au profil de risque, être inscrites dans les contrats ou les plans de sécurité, et s'appuyer sur des mécanismes simples de collecte de preuves. Il peut s'agir d'attestations périodiques, de contrôles techniques lorsque vous avez une visibilité sur les opérations, ou des conclusions d'examens conjoints.
Il est tout aussi important de décider à l'avance de la manière dont vous gérerez les cas de non-conformité. Certaines lacunes peuvent être atténuées ; d'autres peuvent donner lieu à des exceptions, à des frais supplémentaires ou, dans des cas extrêmes, à un refus de fournir un service.
Étape 1 : Définir comment la non-conformité est identifiée
Déterminez quelles obligations peuvent être vérifiées techniquement et lesquelles reposent sur des attestations clients ou des réunions de revue. Intégrez ces contrôles dans vos processus ou outils afin de détecter toute non-conformité.
Étape 2 : Déterminer qui peut accorder et approuver les exceptions
Documentez les rôles habilités à approuver les dérogations temporaires, les conditions et la durée de ces dérogations. Cela permet d'éviter les compromis improvisés qui pourraient devenir permanents par la suite.
Étape 3 : Enregistrer et examiner le risque résiduel
Veillez à ce que les exceptions et les cas de non-conformité soient consignés dans votre registre des risques et examinés lors des instances de gouvernance appropriées. Cela démontre que vous gérez, et non que vous ignorez, le risque résiduel.
Des modèles et obligations clairs en aval sont un atout pour les clients avertis. Ils démontrent que vous prenez leurs risques au sérieux et que vous êtes prêt à fixer et à maintenir des limites raisonnables plutôt que de faire des promesses vagues et inapplicables.
Gouvernance, rôles et cycle de vie du contrôle de la chaîne d'approvisionnement
La sécurité de la chaîne d'approvisionnement ne peut être pleinement efficace que si elle est clairement attribuée à une personne et que le reste de l'organisation comprend son rôle. L'annexe A.5.21 devient pérenne lorsqu'elle est intégrée à la gouvernance, avec des rôles, des responsabilités et des cycles de revue définis, au lieu d'être reléguée au second plan et considérée comme une tâche informelle. Une gouvernance efficace consiste moins à multiplier les réunions qu'à poser les bonnes questions lors des réunions existantes.
Si la sécurité de la chaîne d'approvisionnement est considérée comme « le problème de quelqu'un d'autre » sans définition claire, elle risque de se dégrader. Il est essentiel de déterminer qui est responsable du contrôle, qui contribue à l'élaboration des plans, qui réalise les tâches spécifiques et à quelle fréquence les performances sont évaluées. Une bonne gouvernance repose sur des décisions claires et un retour d'information régulier, et non sur une multiplication des réunions.
Une gouvernance efficace de la chaîne d'approvisionnement consiste à poser de meilleures questions lors des réunions existantes.
Attribution des responsabilités et de la matrice RACI au sein de l'entreprise
La désignation d'un responsable de contrôle désigné permet de définir clairement l'annexe A.5.21, mais sa mise en œuvre repose sur une coordination étroite entre les services des achats, des opérations, juridiques et de la gestion de comptes. Un modèle RACI simple permet d'identifier clairement les rôles et responsabilités, les personnes habilitées et celles qui doivent être informées de l'évolution des risques liés aux fournisseurs ou aux clients.
Pour commencer, il est conseillé de désigner un responsable unique du contrôle pour l'annexe A.5.21, généralement votre responsable de la sécurité des systèmes d'information ou votre RSSI virtuel. Cette personne est chargée de s'assurer que le contrôle est conçu et opérationnel, mais elle ne peut pas le mettre en œuvre seule. Les services Achats, Juridique, Opérations et Gestion de compte ont tous un rôle à jouer.
Une simple matrice RACI (Responsable, Autorité, Consulté, Informé) est utile. Par exemple, pour l'intégration d'un nouveau fournisseur de niveau 1 :
- Le service des achats est responsable de s'assurer que les clauses de sécurité convenues figurent dans le contrat.
- Le responsable de la sécurité de l'information est chargé d'approuver l'évaluation des risques et le niveau de risque du fournisseur.
- Le service juridique est consulté pour les clauses complexes, les exceptions et les responsabilités.
- Les équipes des opérations et de la gestion des comptes sont informées des obligations qui influent sur la manière dont elles fournissent leurs services.
Lorsque cette répartition est claire, les collègues cessent de considérer l'annexe A.5.21 comme « le problème de la personne ISO » et commencent à comprendre leur propre rôle dans son respect.
Choisir des rythmes de gouvernance adaptés aux opérations
La gouvernance est optimale lorsque les questions relatives à la chaîne d'approvisionnement sont intégrées aux réunions déjà essentielles, telles que les comités de gestion des risques, les revues de direction et les revues de service. L'annexe A.5.21 n'implique pas de nouvelles lourdeurs administratives ; elle exige simplement de poser les bonnes questions aux fournisseurs et aux clients au moment opportun et de consigner les réponses.
Les contrôles ont plus de chances d'être maintenus lorsqu'ils s'inscrivent dans les rythmes que l'organisation respecte déjà. Pour la sécurité de la chaîne d'approvisionnement, cela pourrait signifier :
- Intégrer les principaux sujets relatifs aux risques liés aux fournisseurs et aux clients comme points permanents à l'ordre du jour des comités d'examen des risques ou des services existants.
- Planifier des examens périodiques des fournisseurs critiques et des clients à haut risque en fonction des cycles contractuels ou des changements importants.
- Analyse des incidents et des quasi-accidents liés à la chaîne d'approvisionnement lors des revues post-incident et intégration des enseignements tirés dans la gestion des fournisseurs et des clients.
Évitez de créer de nouveaux comités, sauf nécessité absolue ; intégrez plutôt l’annexe A.5.21 aux instances de gouvernance existantes. Par exemple, votre revue de direction ISO 27001 peut aborder explicitement la performance au regard des indicateurs de la chaîne d’approvisionnement, tels que le nombre de fournisseurs critiques sans évaluation à jour, la fréquence des incidents liés aux fournisseurs ou la rapidité de notification des incidents.
La gouvernance doit également s'étendre aux relations moins visibles, telles que les sous-traitants intervenant en dehors des heures ouvrables ou les fournisseurs en marque blanche qui proposent des services sous votre marque. La chaîne d'approvisionnement est incomplète sans eux, et les incidents les impliquant peuvent être tout aussi dommageables. S'assurer qu'ils sont inclus dans le périmètre de l'évaluation des risques, des contrôles contractuels et de la supervision fait partie intégrante d'une mise en œuvre crédible de l'annexe A.5.21.
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é.
Intégration des points A.5.19 à A.5.22 aux processus de gestion des risques, des fournisseurs et des changements
Les annexes A.5.19 à A.5.22 sont optimales lorsqu'elles sont intégrées aux processus que vous utilisez déjà pour gérer les risques, les fournisseurs, les changements et les incidents. Plutôt que d'être considérées comme des « tâches ISO » isolées, elles doivent figurer dans votre registre des risques, votre processus d'approvisionnement, votre gestion des changements et vos analyses post-incident, afin que la gestion de la chaîne d'approvisionnement devienne une pratique quotidienne. Cette intégration permet de transformer les déclarations de principe en comportements cohérents.
Deux tiers des organisations interrogées dans le cadre de l'enquête 2025 sur l'état de la sécurité de l'information ont déclaré que la rapidité et l'ampleur des changements réglementaires rendent la conformité plus difficile à maintenir.
L'élaboration de politiques et de modèles est nécessaire, mais insuffisante. Les contrôles de la chaîne d'approvisionnement ne sont efficaces que s'ils sont intégrés aux formulaires, tickets et flux de travail déjà utilisés pour demander des modifications, intégrer de nouveaux outils, évaluer les risques et réagir aux incidents. Les annexes A.5.19 à A.5.22 sont optimales lorsqu'elles se reflètent dans la manière dont vous consignez les risques, prenez des décisions concernant les fournisseurs, approuvez les modifications et tirez les leçons des incidents.
Intégrer la réflexion sur la chaîne d'approvisionnement dans les flux de travail quotidiens
La première étape consiste à rendre visibles les risques liés à la chaîne d'approvisionnement des TIC, au même titre que les autres risques. Cela implique de créer des fiches de risque explicites pour les services et fournisseurs critiques et de décrire comment vous prévoyez de gérer ces risques. Une fois ce processus en place, vous pouvez ajouter des points de contrôle obligatoires et mineurs aux flux de travail que votre équipe suit déjà, afin que les décisions concernant les fournisseurs et les changements reflètent automatiquement les exigences de l'Annexe A.
Commencez par vous assurer que votre registre central des risques recense explicitement les risques liés à la chaîne d'approvisionnement des TIC. Pour chaque service majeur et fournisseur critique, des entrées de risque doivent être prévues, reflétant l'impact potentiel d'une défaillance ou d'une compromission, ainsi que les mesures correctives envisagées. Cela permet de mettre le risque lié à la chaîne d'approvisionnement au même niveau que les autres vulnérabilités et aide la direction à appréhender les compromis nécessaires.
Ensuite, intégrez les points de contrôle de la chaîne d'approvisionnement aux flux de travail existants :
- Les processus d'approvisionnement devraient inclure des invites permettant de vérifier si un fournisseur proposé appartient à un niveau de risque particulier, si les vérifications préalables ont été effectuées et si les modèles de contrat incluent les clauses de sécurité requises.
- Les demandes de modification qui introduisent ou remplacent des outils ou des sous-processeurs importants devraient automatiquement déclencher un examen des impacts en amont et en aval, et pas seulement de la compatibilité technique.
- La conception des services ou les processus d'intégration des nouveaux clients doivent inclure des étapes permettant d'appliquer le modèle de responsabilité partagée approprié et de confirmer que les obligations en aval sont documentées et acceptées.
Ces invites peuvent souvent être ajoutées aux formulaires et aux modèles de tickets avec un minimum de difficultés, à condition qu'elles soient obligatoires pour les scénarios importants et que les réponses soient enregistrées de manière centralisée afin d'être intégrées à vos dossiers ISMS.
Mesurer les performances et tirer des enseignements des incidents
On ne peut améliorer ce qu'on ne voit pas. L'annexe A.5.21 prend tout son sens lorsqu'on évalue l'efficacité des contrôles de la chaîne d'approvisionnement et qu'on intègre les enseignements tirés des incidents dans ses niveaux de contrôle, ses modèles et ses procédures. L'objectif n'est pas d'atteindre la perfection, mais de comprendre où se situent réellement les principaux risques liés à la chaîne d'approvisionnement et de démontrer qu'on les maîtrise.
Une fois les commandes en fonctionnement, il est nécessaire de recueillir des commentaires pour les améliorer. Voici quelques mesures utiles :
- La proportion de fournisseurs critiques disposant d’évaluations des risques à jour et d’engagements de sécurité documentés.
- Le nombre et la gravité des incidents dont la cause première impliquait une relation en amont ou en aval.
- Le délai nécessaire pour être informé des incidents concernant les fournisseurs et pour communiquer avec les clients touchés.
- Le taux de non-respect par les clients des principales obligations en aval et la fréquence à laquelle des exceptions sont accordées.
En cas d'incident, l'analyse des causes profondes doit clairement distinguer les défaillances en amont, les problèmes internes et les faiblesses en aval. Cette distinction permet d'identifier les points à améliorer : exigences accrues, pratiques optimisées ou obligations envers les clients. L'intégration de ces enseignements dans la hiérarchisation des fournisseurs, les modèles de contrats et les procédures opérationnelles standard rend la mise en œuvre de l'annexe A.5.21 véritablement itérative et non statique.
Une plateforme de gestion de la sécurité de l'information (GSSI) dédiée vous permet de centraliser la gestion des fournisseurs, des services, des clients, des risques et des contrôles, facilitant ainsi la traçabilité d'un changement ou d'un incident à travers toutes les relations concernées. Même si vous n'êtes pas prêt à adopter une telle plateforme immédiatement, concevoir vos processus de manière à centraliser ultérieurement les données nécessaires constitue une démarche pragmatique vers une GSSI plus intégrée.
Réservez une démo avec ISMS.online dès aujourd'hui
ISMS.online vous aide à centraliser l'annexe A.5.21, actuellement dispersée dans des listes de fournisseurs et des clauses contractuelles, dans une vision unique et actualisée de votre chaîne d'approvisionnement TIC, de vos contrôles et des justificatifs associés. En remplaçant les tableurs, les échanges de courriels et les documents isolés par un environnement connecté, vous visualisez plus clairement les relations en amont et en aval, vous suivez les responsabilités et vous répondez avec plus d'assurance aux questions pointues de vos clients et auditeurs.
Si vous pensez qu'un questionnaire client complexe ou un audit ISO 27001:2022 pourrait encore vous déstabiliser, c'est le signe qu'il est temps d'adopter une approche plus structurée. Visualiser clairement vos relations en amont et en aval, avec les responsabilités et les risques identifiés d'un coup d'œil, vous permettra de présenter un récit plus convaincant à vos clients, auditeurs et à votre direction.
Comment tester la solution A.5.21 dans un maillon de votre chaîne d'approvisionnement
Un projet pilote ciblé est la manière la plus simple de constater à quoi ressemble l'annexe A.5.21 lorsqu'elle est pleinement intégrée à un système de gestion de la sécurité de l'information (SGSI). Au lieu de tenter de modéliser l'ensemble de votre système d'approvisionnement d'un seul coup, vous vous concentrez sur une petite portion représentative de votre chaîne d'approvisionnement et vous vérifiez si la structure et les outils mis en place réduisent réellement les efforts et l'incertitude.
Un projet pilote concret pourrait débuter avec une plateforme amont critique et un client à haut risque. Vous pourriez importer ces relations dans ISMS.online, les associer aux annexes A.5.19 à A.5.22 et consigner les éléments clés : évaluations des risques fournisseurs, modèles de responsabilité partagée, obligations des clients et preuves de suivi. Dans ce cadre restreint, vous pourrez vérifier si la plateforme réduit significativement les efforts, clarifie les responsabilités et améliore votre préparation aux questions des auditeurs et des clients.
En limitant la taille du projet pilote, vous maîtrisez son périmètre et évitez de surcharger des équipes déjà très occupées. Parallèlement, vous vous constituez un corpus d'exemples concrets – un registre des risques complété, un cycle de vie documenté des fournisseurs, une matrice des responsabilités partagées – que vous pourrez présenter à vos collègues et à la direction lors des discussions sur le déploiement à plus grande échelle de cette approche.
Que faut-il apporter à une conversation ISMS.online ?
Vous tirerez le meilleur parti d'une conversation sur ISMS.online si vous arrivez avec une description simple de votre chaîne d'approvisionnement actuelle et des défis que vous rencontrez. Une petite préparation vous permettra de mieux comprendre comment la plateforme peut répondre à vos besoins spécifiques et si elle est adaptée à votre organisation.
Les éléments d'entrée utiles comprennent généralement :
- Une liste de vos principaux fournisseurs de services TIC en amont et des services qu'ils prennent en charge.
- Une liste restreinte de clients à fort impact, notamment ceux des secteurs réglementés.
- Tout document existant décrivant les responsabilités partagées, les obligations envers le client ou les attentes envers le fournisseur.
- Exemples d’incidents récents liés aux fournisseurs ou aux clients qui ont été difficiles à gérer.
Grâce à ces informations, l'équipe ISMS.online peut vous présenter la représentation de vos relations réelles au sein de la plateforme et la mise en œuvre concrète des annexes A.5.19 à A.5.22. L'objectif n'est pas de proposer une solution générique, mais de démontrer, à l'aide de vos propres exemples, comment un système de gestion de l'information (SGII) intégré peut simplifier l'annexe A.5.21 et optimiser votre chaîne d'approvisionnement.
Si vous reconnaissez votre propre organisation dans ces scénarios et souhaitez tester une approche plus intégrée, ISMS.online est prêt à explorer un projet pilote ciblé avec vous, en utilisant vos véritables fournisseurs et clients, afin de déterminer si un système de gestion de l'information (SGII) connecté est la prochaine étape appropriée pour votre fournisseur de services gérés (MSP).
Demander demoFoire aux questions
Comment l’annexe A.5.21 de la norme ISO 27001:2022 change-t-elle la façon dont un fournisseur de services gérés (MSP) doit envisager sa chaîne d’approvisionnement en TIC ?
L'annexe A.5.21 exige que vous gériez votre chaîne d'approvisionnement TIC comme un système unique et gouverné, de la plateforme cloud jusqu'au résultat client, et non comme un ensemble de fournisseurs, d'outils et de contrats indépendants. Pour un fournisseur de services gérés (MSP), cela signifie que vous devez avoir une vision en temps réel et fiable de la manière dont les fournisseurs en amont, vos propres services et vos clients en aval sont liés, et de la manière dont vous gérez les risques tout au long de cette chaîne.
Que signifie réellement « chaîne d’approvisionnement TIC de bout en bout » pour un fournisseur de services gérés (MSP) ?
L’expression « de bout en bout » signifie que vous pouvez commencer par un seul service et effectuer un suivi :
- Laquelle produits et services TIC sur qui vous comptez pour le livrer.
- Comment votre propres plateformes et processus Asseyez-vous au milieu.
- Laquelle clients ou segments de clientèle sont affectées si quelque chose se casse.
Au lieu de « nous utilisons le fournisseur X et nous servons le client Y », l’annexe A.5.21 suppose que vous comprenez et gérez l’ensemble du processus : cloud/plateformes → Outils et processus MSP → environnements clientsSi une plateforme centrale tombe en panne ou est compromise, vous devriez déjà savoir quels services et locataires sont exposés et quelles mesures vous prendrez.
En pratique, cela signifie que vous pouvez :
- Indiquez un registre de fournisseurs qui associe les fournisseurs de TIC aux services et aux classes de risque.
- Expliquez, en termes simples, qui fait quoi (vous, le fournisseur, le client) pour chaque type de service.
- Démontrer que cette situation reste actuelle malgré les changements de services, de fournisseurs ou de réglementation.
Si vous pouvez faire visiter cette histoire à un auditeur en utilisant des documents quotidiens au lieu d'un « dossier d'audit » unique, vous traitez l'annexe A.5.21 comme faisant partie de la façon dont vous gérez l'entreprise, ce qui est exactement ce qu'ils recherchent.
Comment l’annexe A.5.21 s’appuie-t-elle sur les autres contrôles des fournisseurs de l’annexe A.5 pour un fournisseur de services gérés ?
L'annexe A.5.21 reprend les thèmes généraux relatifs aux fournisseurs abordés dans les annexes A.5.19, A.5.20 et A.5.22 et les applique spécifiquement à l'infrastructure TIC qui sous-tend vos services gérés. Il s'agit moins d'inventer de nouveaux processus que d'intégrer la sélection des fournisseurs, les contrats, le suivi et la gestion du changement dans une approche cohérente pour les produits et services TIC.
Comment les contrôles des fournisseurs de l'annexe A.5 s'intègrent-ils dans la chaîne d'approvisionnement TIC d'un MSP ?
On peut considérer les quatre commandes comme un seul flux :
- A.5.19 – Sécurité de l’information dans les relations avec les fournisseurs : Déterminez où la sécurité est importante dans votre environnement de fournisseurs et comment vous l'intégrez dans vos choix.
- A.5.20 – Intégrer la sécurité de l’information dans les accords avec les fournisseurs : Transformez ces attentes en clauses claires, en addenda et en descriptions de services.
- A.5.21 – Gestion de la sécurité de l’information dans la chaîne d’approvisionnement des TIC : Appliquez ce raisonnement au réseau spécifique de plateformes, d'outils et d'intégrations TIC qui sous-tendent vos services gérés.
- A.5.22 – Suivi, examen et gestion des changements des services des fournisseurs : Surveillez régulièrement les risques et les performances des fournisseurs et réagissez aux incidents et aux changements.
Pour un fournisseur de services gérés (MSP), cela se traduit généralement par trois capacités visibles :
- A registre d’inscription où les fournisseurs de TIC sont liés à des services, à des notations de risque et à des engagements contractuels.
- A modèle cohérent pour la manière dont vous intégrez, surveillez et quittez vos fournisseurs de TIC, plutôt que pour des décisions ponctuelles par e-mail.
- A lien traçable de ces activités aux promesses faites aux clients et à votre registre interne des risques.
L'utilisation d'une plateforme comme ISMS.online simplifie la gestion de ces éléments, car elle permet de centraliser les fournisseurs, les contrats, les risques et les contrôles des annexes A.5.19 à A.5.22. Vous pouvez ainsi démontrer aux auditeurs et aux clients que vous gérez une chaîne d'approvisionnement TIC performante, et non un simple classeur de contrats.
Comment un MSP doit-il concevoir un cycle de vie des fournisseurs de services informatiques en amont qui satisfasse à l'annexe A.5.21 sans surcharger l'équipe ?
La méthode la plus efficace pour se conformer aux exigences de l'annexe A.5.21 en amont consiste à définir un cycle de vie fournisseur unique et reproductible, puis à adapter le niveau de contrôle en fonction du risque, et non par conjecture. Votre équipe n'a besoin d'apprendre qu'un seul modèle, et vous réservez les vérifications approfondies aux fournisseurs susceptibles de vous nuire, à vous ou à vos clients.
À quoi ressemble un cycle de vie pratique et reproductible pour un fournisseur de services gérés (MSP) dans le domaine des TIC ?
Un cycle de vie simple en quatre étapes permet généralement d'équilibrer effort et assurance :
- Sélectionner: Évaluez l'impact du fournisseur avant de vous engager. Une plateforme qui traite des données clients ou qui constitue un élément central de votre infrastructure de gestion à distance mérite une analyse plus approfondie qu'un simple utilitaire à faible valeur ajoutée.
- À bord: Transformez vos attentes en contrôles concrets. Configurez l'accès, la journalisation, les notifications de modification, les canaux de support et les conditions de sortie avant la mise en production.
- Opérer: Évaluez les performances et les risques à une fréquence raisonnable. Pour les plateformes critiques, prévoyez au moins une évaluation annuelle, ainsi que des vérifications après les avis de sécurité, les incidents ou les modifications importantes de service.
- Exit: Planifiez comment vous supprimerez ou migrerez les données, révoquerez les accès, modifierez les dépendances et mettrez à jour votre propre documentation lorsque vous quittez un fournisseur ou passez à un fournisseur moins performant.
Vous n’avez pas besoin d’outils complexes pour prouver que vous respectez ce cycle de vie. Un registre des fournisseurs tenu à jour, des notes de diligence raisonnable concises, des listes de contrôle d’intégration simples et des comptes rendus d’examen de base indiquent déjà clairement aux auditeurs que vous traitez les fournisseurs de TIC comme faisant partie intégrante de votre système de gestion de la sécurité de l’information (SGSI).
ISMS.online renforce encore ce dispositif en centralisant le registre des fournisseurs, les justificatifs du cycle de vie et les contrôles associés des annexes A.5.19 à A.5.22. Vous simplifiez ainsi le processus pour votre équipe tout en présentant un modèle clair et cohérent à vos clients, auditeurs et partenaires.
Comment un MSP peut-il définir les responsabilités partagées en aval avec ses clients afin que l'annexe A.5.21 soit couverte sans transformer chaque contrat en un roman juridique ?
En aval, l'annexe A.5.21 est respectée lorsque vos clients peuvent comprendre, en langage clair, les garanties offertes par défaut, les actions qu'ils doivent entreprendre et la manière dont vous collaborerez en cas de changement ou de problème. Il n'est pas nécessaire de rédiger des textes juridiques sur mesure pour chaque transaction, mais vous devez définir un ensemble restreint de modèles de responsabilité partagée que vos équipes comprennent et appliquent de manière cohérente.
À quoi ressemble un modèle de responsabilité partagée viable pour les services MSP courants ?
Une méthode pratique consiste à standardiser les modèles par famille de services et à conserver une structure identique à chaque fois. Pour chaque famille, définissez quatre blocs :
- Portée du service: Ce que couvre ce service géré et ce qu'il ne couvre pas.
- Vos responsabilités: Par exemple, la configuration de base, la journalisation, la sauvegarde, la surveillance, la gestion des vulnérabilités et la coordination des incidents.
- Responsabilités du client : Par exemple, en assurant la prise en charge des points de terminaison, en appliquant l'authentification multifactorielle, en gérant les arrivées et les départs, et en vous informant des changements majeurs.
- Responsabilités partagées : Par exemple, les examens d'accès, l'approbation des changements à haut risque ou la gestion des communications en cas d'incident.
Vous pouvez ensuite exprimer ces modèles de plusieurs manières :
- Brief matrices de responsabilité dans les propositions, les cahiers des charges et les documents d'intégration.
- Addenda de sécurité : qui s'ajoutent aux contrats sans en réécrire l'intégralité des termes.
- manuels d'exploitation internes : que vos équipes utilisent lors de l'intégration, de l'exploitation et de la gestion des incidents.
Lorsqu'un client a besoin d'une dérogation, vous documentez explicitement cette dérogation au lieu de modifier le modèle de manière implicite. Une fois ces modèles et exceptions intégrés à votre SMSI et consignés dans votre registre des risques, vous pouvez démontrer que les risques en aval sont gérés de manière délibérée et non informelle. C'est précisément ce que l'annexe A.5.21 vise à vérifier.
ISMS.online vous offre un emplacement central pour stocker et réutiliser ces modèles, les relier à des services et des clients spécifiques, et maintenir l'alignement des libellés de contrats, des procédures internes et des entrées de risques à mesure que votre portefeuille s'élargit.
Comment un MSP peut-il transformer un réseau complexe de fournisseurs, de plateformes et de clients en une carte claire des risques liés à la chaîne d'approvisionnement des TIC qui résiste aux examens de l'annexe A.5.21 ?
La méthode la plus simple pour élaborer une cartographie pertinente des risques liés à la chaîne d'approvisionnement consiste à partir du fonctionnement actuel de vos services plutôt que d'une liste statique de fournisseurs. En suivant les flux de données et les points de contrôle de gauche à droite, les relations les plus importantes pour l'annexe A.5.21 se révèlent généralement d'elles-mêmes.
Quelles sont les étapes pratiques pour créer une cartographie de la chaîne d'approvisionnement des TIC que les auditeurs peuvent suivre ?
Vous pouvez construire la carte en trois étapes indépendantes qui se renforcent mutuellement :
- Vue du service : Listez vos services gérés (par exemple, Microsoft 365 géré, terminaux gérés, sauvegarde gérée, cloud cogéré) et indiquez les plateformes, outils et intégrations en amont dont chacun dépend.
- Point de vue relationnel : Pour chaque service, veuillez indiquer :
- en amont Fournisseurs et plateformes TIC essentiels.
- en aval clients ou groupes de clients qui utilisent ce service.
- Vue des risques : Pour chaque fournisseur ou segment de clientèle à fort impact, consignez un risque distinct indiquant :
- Qu’est-ce qui pourrait raisonnablement mal tourner (par exemple, une panne, une fuite de données, un changement de licence) ?
- Comment cela affecterait-il vos services et les résultats obtenus par vos clients ?
- Quels contrôles, clauses contractuelles et pratiques opérationnelles permettent de réduire la probabilité ou l'impact ?
De nombreux fournisseurs de services gérés trouvent un schéma simple utile, même si vous ne le montrez jamais en externe : cloud/plateformes → Outils et processus MSP → environnements clientsL'utilisation de couleurs ou d'icônes permet d'indiquer le risque relatif. Ce schéma vous aide à déterminer où concentrer vos efforts et offre aux auditeurs et aux clients une compréhension claire de vos dépendances.
Dans ISMS.online, vous pouvez reproduire cette structure en reliant les services, les fournisseurs, les clients et les risques au sein d'un environnement unique. Il devient ainsi beaucoup plus facile de démontrer comment une nouvelle plateforme ou un nouveau client est ajouté à la cartographie, comment il est classé et comment les risques et responsabilités associés sont mis à jour de manière cohérente.
Quels enregistrements quotidiens convainquent les auditeurs ISO 27001 qu'un MSP gère réellement l'annexe A.5.21 au lieu de simplement la mentionner dans la documentation ?
Les auditeurs s'intéressent généralement davantage à la cohérence de vos enregistrements quotidiens qu'à l'apparence de vos outils. Concernant l'annexe A.5.21, ils souhaitent s'assurer que vous comprenez l'origine des risques liés à la chaîne d'approvisionnement des TIC, que vous appliquez un traitement reproductible et que vous pouvez le justifier sans créer une seconde entité dédiée à la documentation d'audit.
Quels artefacts normaux satisfont généralement à l’annexe A.5.21 pour les MSP sans créer une « industrie de l’audit » parallèle ?
Dans la plupart des fournisseurs de services gérés, un ensemble compact d'enregistrements suffit s'il est complet et tenu à jour :
- A registre des fournisseurs qui répertorie les fournisseurs de TIC, les relie aux services, indique leur classification des risques et enregistre les dates des dernières révisions.
- Court notes de diligence raisonnable pour les fournisseurs à risque plus élevé, comme des références à des certifications, des réponses à des questionnaires ou des évaluations de risques concises.
- Contrats ou avenants de sécurité : qui définissent les exigences en matière de sécurité, les règles de notification des incidents, le traitement des données et les conditions relatives aux sous-traitants.
- Suivi et examen des dossiers : , comme les tickets d'évaluation de service, les comptes rendus des réunions avec les fournisseurs ou les analyses post-incident qui montrent comment vous avez réagi.
- Modèles de responsabilité partagée : et les clauses correspondantes dans les contrats clients, ainsi que des exemples concrets de la manière dont vous réagissez lorsque les obligations de l'une ou l'autre partie ne sont pas respectées.
Au lieu de constituer des « dossiers d'audit » distincts, il est généralement plus efficace de s'assurer que vos documents habituels (listes de contrôle d'intégration, enregistrements de modifications, manuels d'exploitation, revues d'incidents et de problèmes) contiennent automatiquement les éléments de preuve qu'un auditeur demandera.
En centralisant ces éléments dans ISMS.online et en les liant explicitement aux contrôles de l'Annexe A et aux risques pertinents, vous pouvez répondre rapidement aux questions d'audit et aux questionnaires clients en filtrant et en exportant les données depuis une seule et même plateforme. À terme, cela réduit le stress lié aux audits, raccourcit les cycles de vente et permet à votre équipe d'être reconnue pour la gestion efficace de sa chaîne d'approvisionnement TIC, plutôt que de devoir tout reconstruire chaque année.
Comment un MSP peut-il utiliser ISMS.online pour intégrer l'annexe A.5.21 dans le travail normal de la chaîne d'approvisionnement au lieu de la traiter comme un projet de conformité ponctuel ?
L’annexe A.5.21 devient facile à gérer lorsqu’elle est intégrée à vos processus d’achat, de prestation et d’évaluation des services, et non lorsqu’elle est traitée comme une norme isolée à cocher. ISMS.online accompagne cette transition en vous offrant un environnement unique pour connecter fournisseurs, services, clients, risques, contrôles et preuves, afin que vos actions quotidiennes contribuent naturellement à la mise en conformité de l’annexe A.5.21.
À quoi cela ressemble-t-il lorsque l'annexe A.5.21 est réellement mise en œuvre dans ISMS.online ?
Voici un schéma réaliste pour de nombreux fournisseurs de services gérés :
- Vous maintenez une registre des fournisseurs en direct sur ISMS.online, classer les fournisseurs de TIC par impact et relier chacun d'eux aux services gérés et aux contrôles des annexes A.5.19 à A.5.22 qu'il prend en charge.
- Vous capturez activités de vérification préalable, d'intégration, de suivi et de sortie comme des éléments de travail ou des tâches normales, de sorte que les preuves dont vous avez besoin pour l'annexe A.5.21 s'accumulent automatiquement au fur et à mesure que votre équipe travaille avec les fournisseurs.
- Vous stockez et réutilisez modèles de responsabilité partagée en tant que contenu structuré, en les associant aux familles de services et aux groupes de clients afin que le langage contractuel, les manuels d'exploitation et les entrées de risques restent alignés.
- Votre lien risques aux fournisseurs en amont comme aux clients en aval, un changement dans un maillon de la chaîne modifie immédiatement votre vision de l'exposition globale de la chaîne d'approvisionnement.
Pour commencer, une méthode à faible risque consiste à choisir un service important, une plateforme amont critique et un client représentatif, à modéliser cette chaîne de bout en bout dans ISMS.online, puis à simuler un changement ou un incident réel dans le système. Si vos équipes et votre auditeur parviennent plus facilement à identifier les dépendances, à expliquer les obligations et à recueillir des preuves à partir de cet exemple, vous disposerez d'arguments internes solides pour étendre cette approche à l'ensemble de votre chaîne d'approvisionnement TIC.
Au fil du temps, cette méthode de travail permet à votre entreprise d'être perçue non seulement comme assurant le fonctionnement des systèmes, mais aussi comme gérant une chaîne d'approvisionnement TIC traçable et rigoureuse, capable de répondre aux questionnaires clients et aux audits ISO 27001, tout en minimisant les perturbations de votre activité quotidienne. Lorsque vous serez prêt à présenter ces éléments à un client ou à un auditeur, ISMS.online vous fournira tout ce dont vous avez besoin au même endroit, vous évitant ainsi de devoir tout rassembler sous pression.
