Approvisionnement logiciel sécurisé par exigence en 2026

Nous sommes un mardi matin, début 2026, et Maria, RSSI d’une société européenne de paiement en forte croissance, présente un dossier au conseil d’administration. Le dernier point à l’ordre du jour devrait être routinier : l’approbation d’une nouvelle plateforme de détection de fraude fondée sur l’IA. Le fournisseur dispose d’une démonstration convaincante, d’une remise limitée dans le temps, d’une synthèse de sécurité d’une page et d’un contrat standard.

Puis les questions commencent.

Le directeur général demande : « Comment savons-nous que cette plateforme est sécurisée ? Nos clients du secteur financier nous demandent des éléments probants de conformité DORA, et ce fournisseur devient une composante de notre infrastructure critique. »

Le service juridique demande si l’accord de traitement des données est prêt, où les données des clients de l’UE seront traitées et si les sous-traitants ultérieurs sont déclarés. Le responsable de la résilience opérationnelle demande des précisions sur la planification de sortie, les exports de sauvegarde et la continuité des fonctions critiques. L’ingénieur sécurité produit demande des informations sur la divulgation des vulnérabilités, des éléments de preuve d’application des correctifs et un SBOM ou une déclaration équivalente de transparence des composants. Les achats posent la question qui rend le risque fournisseur coûteux : « Pouvons-nous approuver maintenant et collecter les documents après signature ? »

C’est le moment où l’approvisionnement logiciel moderne devient soit un contrôle, soit un futur rapport d’incident.

En 2026, l’approvisionnement logiciel sécurisé ne peut pas reposer sur la bonne volonté post-contractuelle. La sécurité de la chaîne d’approvisionnement NIS2, les risques liés aux prestataires tiers de services TIC selon DORA, la responsabilité des sous-traitants au titre du GDPR et les attentes de sécurité produit du Cyber Resilience Act ont déplacé l’assurance fournisseurs au point de décision d’achat. Les acheteurs ont besoin d’un approvisionnement logiciel sécurisé par exigence, dans lequel le client définit les éléments probants de sécurité, les clauses contractuelles, les points de contrôle d’intégration et les responsabilités opérationnelles avant l’achat.

Pour les clients de Clarysec, la réponse n’est pas une énième feuille de calcul qui meurt dans une boîte de réception. C’est un système de contrôles d’approvisionnement aligné sur ISO/IEC 27001:2022, mappé au moyen des politiques Clarysec, du Zenith Blueprint : feuille de route en 30 étapes pour auditeurs et de Zenith Controls, afin que chaque achat de logiciel ou de SaaS dispose d’une piste défendable depuis le besoin métier jusqu’à la décision de risque fournisseur.

La sécurité par exigence est le nouveau contrôle d’approvisionnement logiciel

La sécurité dès la conception est généralement abordée du côté fournisseur. La sécurité par exigence est la discipline côté acheteur : l’organisation refuse d’acheter un logiciel tant que le fournisseur ne peut pas démontrer que la sécurité, la protection des données, la résilience, la gestion des vulnérabilités et l’auditabilité sont intégrées à l’offre.

Cela modifie la discussion d’achat. Au lieu de demander : « Avez-vous de la sécurité ? », les achats posent des questions plus précises :

• Quelles données traiterez-vous, où et dans quel rôle juridique ?
• De quelle fonction métier dépendrez-vous, et quel est son niveau de criticité ?
• Quels éléments de preuve démontrent que vos contrôles fonctionnent, et pas seulement qu’ils sont documentés ?
• À quels délais de notification des incidents vous engagez-vous ?
• Quels éléments de preuve de divulgation des vulnérabilités, d’application des correctifs, de SBOM ou de VEX pouvez-vous fournir ?
• Quels sous-traitants ou sous-traitants ultérieurs auront accès à nos données ou à notre service ?
• Pouvons-nous auditer, inspecter ou demander des éléments de preuve pendant la durée du contrat ?
• Que se passe-t-il en cas de résiliation, de migration, de violation, d’insolvabilité ou de demande d’une autorité de régulation ?

ISO/IEC 27001:2022 fournit l’ossature du système de management nécessaire à ce changement. La clause 4 impose à l’organisation de comprendre son contexte, les parties intéressées et le domaine d’application du SMSI, y compris les exigences réglementaires externes et celles liées aux fournisseurs. La clause 5 fait du risque fournisseur une responsabilité de leadership et de gouvernance. La clause 6 exige l’appréciation des risques, le traitement des risques, la sélection des contrôles, une déclaration d’applicabilité et des décisions relatives au risque résiduel. La clause 8 exige la maîtrise opérationnelle des processus, y compris les processus fournis par des tiers. La clause 9 exige la surveillance, l’audit interne et la revue de direction.

L’approvisionnement logiciel n’est donc pas un simple workflow commercial. Il devient un processus SMSI exploité et auditable. Les autorités de régulation et les auditeurs demandent de plus en plus pourquoi une organisation a accepté un fournisseur avant d’en comprendre le risque. L’approvisionnement sécurisé par exigence apporte une réponse claire : le risque a été évalué, traité, contractualisé et attribué avant la création de la dépendance.

Pourquoi NIS2, DORA, GDPR et CRA convergent lors de la sélection des fournisseurs

Le conseil d’administration de Maria pose les bonnes questions, car un seul fournisseur logiciel peut déclencher plusieurs obligations à la fois.

NIS2 s’applique selon le secteur, la taille et la criticité, les Annexes I et II faisant entrer dans le périmètre de nombreuses organisations numériques, financières, d’infrastructure, de services managés et dépendantes du cloud. Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, notamment la sécurité de la chaîne d’approvisionnement, l’acquisition sécurisée, le développement et la maintenance sécurisés, la gestion des vulnérabilités, le contrôle d’accès, la gestion des actifs, la continuité, la gestion des incidents et l’évaluation de l’efficacité des contrôles. Article 21(3) impose spécifiquement de prendre en compte les vulnérabilités des fournisseurs directs et les pratiques de cybersécurité des fournisseurs. Article 23 crée des attentes de notification échelonnée des incidents significatifs, notamment une alerte précoce dans les 24 heures et une notification dans les 72 heures.

DORA s’applique depuis le 17 janvier 2025 aux entités financières entrant dans son champ d’application. Il crée des exigences uniformes relatives à la gestion des risques liés aux TIC, à la notification des incidents liés aux TIC, aux tests de résilience opérationnelle numérique et à la gestion des risques liés aux prestataires tiers de services TIC. DORA est particulièrement prescriptif pour l’approvisionnement. Les entités financières doivent disposer de stratégies de gestion des risques liés aux prestataires tiers de services TIC, de registres des accords portant sur des services TIC, de diligences préalables, d’analyses du risque de concentration, de contrats écrits comportant des dispositions de sécurité et de résilience, de droits d’audit et d’accès, d’obligations de coopération, de droits de résiliation et de plans de sortie. Les Articles 28 et 30 sont centraux pour le risque lié aux prestataires tiers de services TIC et les contrôles contractuels, tandis que les Articles 17 à 23 structurent la gestion des incidents et la notification.

Le GDPR ajoute le point de contrôle de responsabilité du sous-traitant. Les Articles 5, 28, 32, 33 et 34 exigent la responsabilité, des contrats avec les sous-traitants, une sécurité appropriée, la coopération pour la notification des violations et la gestion de l’impact sur les personnes concernées. Un fournisseur SaaS qui traite des données à caractère personnel n’est pas un simple fournisseur. Il devient un élément du niveau de conformité du responsable du traitement. Le DPA, les mesures techniques et organisationnelles, la liste des sous-traitants ultérieurs, les garanties applicables au transfert, les règles de conservation et les obligations de suppression doivent être compris avant le début du traitement.

Les attentes du CRA ajoutent l’assurance produit. Même lorsque l’acheteur n’est pas le fabricant, les équipes achats doivent exiger des éléments de preuve relatifs au développement sécurisé, à la gestion des vulnérabilités, au support produit, aux mises à jour de sécurité, à la divulgation coordonnée des vulnérabilités et à la transparence des composants, par exemple un SBOM ou une déclaration équivalente. Ces exigences doivent figurer dans les appels d’offres, les annexes de sécurité et les critères d’acceptation.

Le point commun est simple : l’organisation acheteuse doit savoir ce qu’elle achète, quel risque elle importe et quels éléments de preuve elle peut produire lorsque les autorités de régulation, les clients ou les auditeurs les demandent.

L’ossature de contrôles ISO 27001 pour l’assurance fournisseurs

Le modèle d’approvisionnement sécurisé par exigence le plus efficace n’est pas construit réglementation par réglementation. Il part des contrôles. Clarysec utilise ISO/IEC 27001:2022 comme ossature du SMSI, avec l’appui des lignes directrices de contrôle ISO/IEC 27002:2022 et du mapping de conformité croisée dans Zenith Controls.

Dans Zenith Controls, l’assurance fournisseurs s’appuie sur les contrôles ISO/IEC 27002:2022 5.19, 5.20 et 5.21. Il ne s’agit pas d’éléments de liste de contrôle isolés. Ils constituent un cycle de vie de l’approvisionnement.

Zenith Controls mappe ces contrôles ISO sur les attentes réglementaires et d’audit. Il ne crée pas des contrôles propriétaires distincts appelés Zenith Controls. Il aide les équipes à comprendre comment les contrôles ISO/IEC 27002:2022 soutiennent l’assurance attendue au titre de NIS2, DORA, GDPR, NIST CSF 2.0 et des audits orientés COBIT.

Le réseau de contrôles associé est également important. L’assurance fournisseurs s’articule avec la gestion des actifs, le contrôle d’accès, la sécurité cloud, la gestion des vulnérabilités, la journalisation, la gestion des incidents, la préparation des TIC à la continuité d’activité, le développement sécurisé, la sécurité des applications, la gestion des configurations, la sauvegarde, la redondance, la conformité juridique, la protection de la vie privée, la gestion des changements et la revue indépendante. Les achats coordonnent le processus, mais la responsabilité du risque doit inclure le propriétaire métier, la sécurité de l’information, le juridique, la protection des données, l’informatique, la finance et le responsable de service.

Les points de contrôle Clarysec avant signature

Le modèle de politiques de Clarysec déplace délibérément l’assurance fournisseurs en amont. La formulation la plus ferme apparaît à l’endroit approprié : avant la signature des accords, avant l’activation des abonnements cloud et avant le partage de données.

La version PME de la Politique de sécurité des tiers et des fournisseurs de Clarysec indique :

Évaluer et documenter les risques fournisseurs avant la signature des accords ou l’octroi d’un accès.

Cette exigence provient de la section « Objectifs », clause de politique 3.3. La clause est courte parce que l’intention de contrôle n’est pas négociable : pas d’appréciation des risques, pas de contrat, pas d’accès.

Pour les environnements d’entreprise, la Politique de sécurité des tiers et des fournisseurs de Clarysec renforce le point de contrôle précontractuel :

Tous les nouveaux fournisseurs doivent faire l’objet d’une évaluation de sécurité documentée avant l’exécution du contrat.

Cette exigence provient de la section « Exigences de mise en œuvre de la politique », clause de politique 6.1.1. La même politique identifie également les « droits d’auditer, d’inspecter et de demander des éléments de preuve de sécurité » dans la section « Exigences de gouvernance », clause de politique 5.3.4.

Pour l’achat de services cloud et SaaS, la Politique d’utilisation du cloud PME ajoute un point d’approbation pratique :

Toute utilisation de services cloud doit être revue et approuvée par le Directeur général (DG) avant la mise en œuvre ou la souscription.

Cette exigence provient de la section « Exigences de gouvernance », clause de politique 5.1. Dans une petite organisation, cette approbation peut être l’équivalent d’un comité de gouvernance du cloud. Dans une entreprise, elle devient un workflow impliquant les achats, la sécurité, la protection des données et l’architecture. La Politique d’utilisation du cloud entreprise soutient également les exigences contractuelles applicables au cloud, y compris des dispositions opposables dans les contrats avec les CSP.

Pour l’acquisition de logiciels, la Politique relative aux exigences de sécurité des applications entreprise est explicite :

Les accords d’acquisition de logiciels ou d’externalisation doivent inclure des exigences de sécurité dans les appels d’offres, les contrats et les SLA, y compris des dispositions relatives aux délais de remédiation des vulnérabilités et aux droits d’audit des tiers.

Cette exigence provient de la section « Exigences de gouvernance », clause de politique 5.4. L’ordre est important : appels d’offres, contrats et SLA. La sécurité apparaît dès l’étape de consultation du marché, et non comme une pièce jointe après attribution.

Pour l’approvisionnement piloté par le GDPR, la Politique de conformité juridique et réglementaire PME de Clarysec exige :

Les clauses de l’Accord de traitement des données ou des clauses contractuelles équivalentes doivent être convenues avant tout partage de données à caractère personnel ou sensibles.

Cette exigence provient de la section « Exigences de mise en œuvre de la politique », clause de politique 6.3.2. Elle évite l’un des échecs les plus courants de l’intégration SaaS : téléverser des données à caractère personnel dans un outil avant d’avoir convenu des conditions applicables au sous-traitant, des obligations relatives aux violations et des conditions liées aux sous-traitants ultérieurs.

Pour la sécurité des applications des fournisseurs, la Politique relative aux exigences de sécurité des applications PME exige des achats qu’ils :

précisent les obligations relatives à la divulgation des vulnérabilités, aux délais de réponse et à l’application des correctifs.

Cette exigence provient de la section « Exigences de gouvernance », clause de politique 5.3.2. Elle indique également :

Le DG doit demander la documentation ou les certifications (par exemple SOC 2, ISO 27001, rapports de tests de sécurité) comme éléments de preuve de la conformité du fournisseur, le cas échéant.

Cette exigence provient de la section « Exigences de mise en œuvre de la politique », clause de politique 6.3.2. Le mot clé est éléments de preuve. L’approvisionnement sécurisé par exigence ne repose pas sur des déclarations de confiance. Il repose sur des livrables justificatifs pouvant être revus.

Le point de contrôle d’approvisionnement du Zenith Blueprint

Le Zenith Blueprint traite la sécurité fournisseur comme un contrôle exploité, et non comme un slogan d’achats. Dans la phase « Contrôles en action », l’étape 23 couvre les Contrôles organisationnels 5.19 à 5.37, notamment la sécurité de l’information dans les relations avec les fournisseurs.

Le Blueprint explique :

Tout commence par la classification du fournisseur. Tous les fournisseurs ne présentent pas le même risque. Un service de nettoyage peut disposer d’un accès physique aux bureaux, mais pas aux réseaux. Une société de tests d’intrusion ou un prestataire d’hébergement cloud, en revanche, peut disposer d’un accès technique profond au cœur même de votre infrastructure. La classification doit déterminer si le fournisseur manipule ou traite directement vos informations, s’il fournit l’infrastructure ou les plateformes sur lesquelles vous opérez, s’il gère ou maintient des systèmes pour votre compte, et si sa compromission pourrait avoir un impact sur vos objectifs de confidentialité, d’intégrité ou de disponibilité.

Pour le contrôle 5.20, le Blueprint est direct :

Les principaux domaines généralement traités dans les accords avec les fournisseurs comprennent les obligations de confidentialité ; les responsabilités de contrôle d’accès ; les mesures techniques et organisationnelles pour la protection des données, le chiffrement, la transmission sécurisée, la sauvegarde et les engagements de disponibilité ; les délais et protocoles de signalement des incidents ; le droit d’audit, y compris la fréquence, le périmètre et l’accès aux éléments de preuve pertinents ; les contrôles des sous-traitants ; et les dispositions de fin de contrat, telles que la restitution ou la destruction des données, la récupération des actifs et la désactivation des comptes.

Il conclut que le contrôle 5.20 est « votre dernier levier » et qu’il « appartient au point de contrôle d’approvisionnement ». Une fois le contrat signé, le levier diminue. Avant la signature, les éléments de preuve et les obligations peuvent devenir des conditions d’achat.

Pour le développement externalisé, la phase « Contrôles en action », étape 21, contrôle 8.30, ajoute une autre exigence d’approvisionnement. Le Blueprint indique :

Le principe au cœur de ce contrôle est que la sécurité doit être une exigence contractuelle, et non une attente verbale.

Les équipes externalisées doivent satisfaire aux mêmes normes de développement sécurisé que les équipes internes, y compris l’analyse statique, la revue par les pairs, le chiffrement, l’authentification MFA vers les référentiels et la visibilité sur le code, les décisions d’architecture, les vulnérabilités, les demandes de changement, les journaux CI/CD et les résultats de scan.

Construire en un après-midi un point de contrôle RFP sécurisé par exigence

Supposons que votre organisation souhaite acquérir une plateforme d’analyse clients. Elle ingérera des identifiants clients, des événements comportementaux, des métadonnées de support et des références de transactions. Le propriétaire métier souhaite une approbation rapide. L’équipe sécurité dispose d’une semaine.

Commencez par un enregistrement de point de contrôle d’approvisionnement en utilisant la Politique de sécurité des tiers et des fournisseurs, la Politique relative aux exigences de sécurité des applications, la Politique d’utilisation du cloud, la Politique de conformité juridique et réglementaire et l’étape 23 du Zenith Blueprint comme documents sources.

Joignez un questionnaire de sécurité par exigence à l’appel d’offres. Évitez les questions génériques comme « Chiffrez-vous les données ? ». Posez des questions fondées sur les éléments de preuve :

1. Fournissez votre rapport indépendant d’assurance sécurité en vigueur, votre certificat ou des éléments de preuve de contrôle équivalents.
2. Identifiez les lieux d’hébergement, les options de localisation des données, les lieux de sauvegarde et les lieux d’accès au support.
3. Fournissez le DPA, la liste des sous-traitants ultérieurs et le processus de notification des changements de sous-traitants ultérieurs.
4. Confirmez les délais de notification des incidents, y compris le support d’alerte précoce sous 24 heures lorsque des workflows NIS2 peuvent être déclenchés et le support de notification par phases pour les clients soumis à DORA.
5. Fournissez la politique de divulgation des vulnérabilités, les SLA d’application des correctifs par niveau de gravité et des éléments de preuve récents de gouvernance de la remédiation des vulnérabilités.
6. Fournissez des éléments de preuve de sécurité produit, tels qu’une description du cycle de vie de développement sécurisé, une synthèse de test d’intrusion, un SBOM ou une déclaration de transparence des composants et la période de support des mises à jour de sécurité.
7. Confirmez l’authentification MFA, le moindre privilège, la journalisation, la surveillance des accès administratifs et les droits d’audit client ou de demande d’éléments de preuve.
8. Décrivez les modalités d’export, de suppression, de restitution, de support à la résiliation et d’assistance à la transition.
9. Listez les sous-traitants importants et les dépendances TIC qui soutiennent le service.
10. Confirmez si les données clients sont utilisées pour l’entraînement, l’analytique, l’amélioration du produit ou le développement de modèles d’IA, et identifiez la base légale ou le modèle d’instruction du sous-traitant.

Notez ensuite le fournisseur avant la négociation.

Enfin, mettez à jour le registre des risques et la déclaration d’applicabilité. L’enregistrement de traitement des risques doit montrer pourquoi les contrôles ISO/IEC 27002:2022 5.19, 5.20 et 5.21 s’appliquent, quelles exigences contractuelles et techniques ont été sélectionnées, qui est responsable du risque résiduel et quelle cadence de surveillance s’applique. Si le métier souhaite poursuivre malgré les lacunes, utilisez un enregistrement formel d’acceptation du risque avec une date d’expiration, des contrôles compensatoires et une approbation de la direction.

Les clauses contractuelles qui transforment la réglementation en obligations opposables

Les attentes de sécurité doivent devenir des engagements contractuels. Un certificat peut être utile, mais il répond rarement à toutes les questions concernant votre service exact, la localisation des données, les sous-traitants, le modèle de support, les engagements relatifs aux incidents ou les droits de sortie.

Ce tableau constitue le pont pratique entre les obligations juridiques et le travail d’approvisionnement. Il aide également les équipes juridique, sécurité et achats à négocier à partir du même référentiel minimal de contrôles.

Mapping de conformité croisée : un dossier fournisseur, plusieurs obligations

L’avantage d’utiliser ISO/IEC 27001:2022 comme ossature est qu’un seul dossier d’assurance fournisseurs peut soutenir plusieurs échanges réglementaires.

NIST CSF 2.0 est utile comme couche de communication. Sa fonction GOVERN met l’accent sur la connaissance des exigences juridiques, réglementaires, contractuelles, de vie privée et de dépendance. Ses résultats GV.SC relatifs à la chaîne d’approvisionnement exigent des processus de gestion des risques liés à la chaîne d’approvisionnement, des rôles fournisseurs, une priorisation des fournisseurs par criticité, des exigences contractuelles, des diligences préalables, une surveillance, une planification des incidents et une planification de résiliation.

Cela se mappe proprement à l’étape 23 du Zenith Blueprint et aux contrôles ISO/IEC 27002:2022 5.19 à 5.21 tels que mappés dans Zenith Controls. Cela donne également aux conseils d’administration un langage qu’ils comprennent : état actuel, état cible, écart, risque, action, responsable et date.

Ce que les auditeurs demanderont

Un processus d’approvisionnement sécurisé par exigence robuste doit résister à différents angles d’audit.

Un auditeur ISO/IEC 27001:2022 commencera par le contexte et le domaine d’application du SMSI. Il demandera si les interfaces et dépendances fournisseurs sont incluses, si les exigences des parties intéressées incluent NIS2, DORA, GDPR et les contrats clients, et si les risques fournisseurs sont évalués de manière cohérente selon la méthodologie de risque. Il suivra la piste jusqu’au traitement des risques, à la déclaration d’applicabilité, aux contrôles fournisseurs, aux éléments de preuve opérationnels, à l’audit interne et à la revue de direction.

Un examinateur DORA se concentrera sur les fonctions métier soutenues par les TIC, les fonctions critiques ou importantes, les enregistrements de dépendances vis-à-vis de tiers, les clauses contractuelles, les droits d’audit et d’accès, la coopération en cas d’incident, les tests de résilience, les stratégies de sortie et le risque de concentration. Si un SaaS soutient une fonction critique ou importante, un questionnaire fournisseur léger ne suffira pas.

Une autorité NIS2 demandera comment l’organisation a évalué les pratiques de cybersécurité des fournisseurs, les vulnérabilités des fournisseurs directs, le support de notification des incidents, les dépendances de continuité et les décisions d’acquisition sécurisée. Elle testera si l’assurance fournisseurs soutient les propres obligations de l’organisation au titre de l’Article 21 et de l’Article 23.

Un examinateur GDPR demandera si les rôles de responsable du traitement et de sous-traitant ont été compris avant le début du traitement, si un DPA ou des clauses équivalentes ont été convenus avant le partage des données, si les sous-traitants ultérieurs ont été déclarés, si les mesures de sécurité étaient appropriées, si la coopération en cas de violation est contractuelle et si la restitution ou la suppression des données est opposable.

Un auditeur de type COBIT 2019 ou ISACA se concentrera sur la gouvernance et la responsabilité : qui a approuvé le fournisseur, quel risque a été accepté, si les exigences de politique ont été suivies, si les exceptions sont suivies et si les bénéfices, les risques et les ressources ont été équilibrés.

Votre dossier d’éléments de preuve doit inclure la classification du fournisseur, l’approbation du propriétaire métier, l’appréciation des risques, les exigences de sécurité de l’appel d’offres, les réponses du fournisseur, le DPA, l’annexe de sécurité, le SLA, les droits d’audit, le registre des sous-traitants ultérieurs, les engagements relatifs aux vulnérabilités, les clauses relatives aux incidents, les éléments de preuve de localisation cloud, les éléments de preuve de journalisation et de chiffrement, les conditions de sortie, les enregistrements de réévaluation, les exceptions et le mapping de la déclaration d’applicabilité.

Schémas d’échec courants dans l’achat de logiciels

Le premier échec consiste à traiter les achats comme un workflow commercial et la sécurité comme un workflow technique. Lorsque la sécurité reçoit le contrat, le métier s’est déjà engagé psychologiquement, la date de mise en œuvre a été annoncée et le levier de négociation est faible.

Le deuxième échec est la substitution des éléments de preuve. Un fournisseur fournit un certificat, et l’acheteur suppose qu’il répond à toutes les questions. La certification peut aider, mais elle peut ne pas couvrir le produit exact, la région d’hébergement, le modèle de support, la chaîne de sous-traitance, les obligations relatives aux incidents, l’usage des données par l’IA ou les exigences de sortie.

Le troisième échec est l’absence de prise en compte du risque en aval. Un fournisseur SaaS peut dépendre d’un hébergement cloud, d’outils d’analytique, de plateformes de support, d’équipes de développement offshore, de fournisseurs de modèles d’IA et de processeurs de paiement. Le contrôle ISO/IEC 27002:2022 5.21 exige de porter attention à la chaîne d’approvisionnement des TIC située derrière le fournisseur direct. Au titre de DORA, cela se rattache à la sous-traitance et au risque de concentration. Au titre du GDPR, cela se rattache aux sous-traitants ultérieurs. Au titre de NIS2, cela se rattache aux vulnérabilités des fournisseurs directs et aux pratiques de cybersécurité des fournisseurs.

Le quatrième échec est un libellé insuffisant sur les incidents. Un contrat qui indique que « le fournisseur notifiera le client rapidement » peut ne pas soutenir l’alerte précoce NIS2, la notification par phases DORA, les communications client ou l’escalade interne. Les clauses relatives aux incidents doivent préciser les délais, les déclencheurs, les contacts, les obligations de coopération et les obligations en matière d’éléments de preuve.

Le cinquième échec concerne des droits de sortie imprécis. Si un fournisseur devient non sécurisé, non conforme, acquis, insolvable ou stratégiquement inadapté, l’acheteur a besoin d’exports, de suppression, de support de transition, de désactivation des comptes et d’éléments de preuve de destruction. La sortie n’est pas une considération juridique secondaire. C’est un contrôle de résilience.

Du point de contrôle d’approvisionnement à une assurance fournisseurs vivante

L’approvisionnement sécurisé par exigence ne s’arrête pas à la signature. Un cycle de vie fournisseur mature dans le style Clarysec comporte cinq étapes.

Pour les fournisseurs à risque élevé, la surveillance doit inclure l’actualisation des éléments de preuve, des réunions de revue de sécurité, la participation à des exercices sur table relatifs aux incidents, la revue des accès, la notification des vulnérabilités et des correctifs, la revue des changements de service et les mises à jour des sous-traitants ultérieurs. Pour les fournisseurs à moindre risque, une revue annuelle peut suffire. La scalabilité d’ISO 27001, la proportionnalité NIS2 et la proportionnalité DORA permettent toutes l’adaptation, mais celle-ci doit être justifiée et documentée.

La prochaine étape avec Clarysec

Le prochain achat SaaS risqué n’attendra pas une refonte parfaite de la gouvernance. Commencez par la prochaine demande d’approvisionnement.

Utilisez le Zenith Blueprint : feuille de route en 30 étapes pour auditeurs pour mettre en œuvre les contrôles de relations fournisseurs de l’étape 23 et les contrôles de développement externalisé de l’étape 21. Utilisez Zenith Controls pour mapper les contrôles ISO/IEC 27002:2022 5.19, 5.20 et 5.21 sur NIS2, DORA, GDPR, NIST CSF 2.0 et les attentes d’audit orientées COBIT. Utilisez la bibliothèque de politiques Clarysec, notamment la Politique de sécurité des tiers et des fournisseurs, la Politique relative aux exigences de sécurité des applications, la Politique d’utilisation du cloud et la Politique de conformité juridique et réglementaire, pour rendre le point de contrôle opposable.

Avant la signature du prochain contrat, exigez la classification du fournisseur, les éléments de preuve de sécurité, la préparation du DPA, les engagements relatifs aux incidents, la gestion des vulnérabilités, la transparence des sous-traitants, les droits d’audit et les conditions de sortie.

C’est cela, l’approvisionnement sécurisé par exigence. C’est ainsi que les RSSI transforment la pression réglementaire en pouvoir d’achat. C’est ainsi que les responsables conformité transforment des obligations qui se recoupent en un dossier unique d’éléments de preuve. C’est ainsi que les auditeurs constatent que le risque fournisseur a été pris en compte avant la création de la dépendance. Et c’est ainsi que les propriétaires métier achètent des logiciels plus rapidement sans hériter de risques non maîtrisés.

Prêt à transformer votre prochain achat logiciel en contrôle compatible avec les exigences d’audit ? Découvrez la suite intégrée de politiques Clarysec, téléchargez le Zenith Blueprint, consultez Zenith Controls ou planifiez une démonstration pour construire un programme d’approvisionnement sécurisé par exigence capable de résister à NIS2, DORA, GDPR, aux attentes CRA et à l’examen réel des auditeurs.