Dernière mise à jour : 6 août 2026

Quels certificats de sécurité doit-on exiger des prestataires de services informatiques ?

L'essentiel en bref

• Exigez des preuves basées sur le risque et liées aux services. Plus de documents ne signifient pas automatiquement de meilleures preuves.
• Vérifiez à chaque preuve le champ d'application, l'organisation, le service, la période, les exceptions et l'entité émettrice ou vérificatrice.
• ISO/IEC 27001, les rapports SOC et BSI C5 répondent à des questions différentes et ne sont pas interchangeables sans contexte.
• Les tests techniques, les politiques, les processus d'incidents et les preuves BCM complètent les preuves formelles lorsqu'elles correspondent au risque.
• Protégez les rapports confidentiels et documentez quels points ouverts ou contrôles clients restent.

Les preuves doivent correspondre à la décision.

Les preuves de sécurité aident à vérifier les déclarations d'un fournisseur de services informatiques. Cependant, elles diffèrent considérablement en matière d'objet, de profondeur et d'actualité. Un certificat évalue un système de gestion dans un champ d'application défini. Un rapport d'audit peut examiner la conception des contrôles et leur efficacité pendant une période. Un résumé de pentest examine un domaine technique.

Il n'existe pas de catalogue d'obligations universel pour chaque service. Le choix dépend de la performance, de la criticité, de l'accès aux données et de l'impact potentiel. Cet article aide à la demande et à l'évaluation des preuves. Il ne remplace pas un examen juridique ou une vérification de la protection des données.

Dérivez les preuves du risque et de la performance.

Commencez par le service concret. Quelles données traite le fournisseur ? A-t-il des droits administratifs ? Développe-t-il des logiciels, gère-t-il des infrastructures ou fournit-il un service cloud standardisé ? Quels processus d'affaires seraient affectés en cas de défaillance ? Ces questions déterminent quelle déclaration doit être prouvée.

Associez chaque exigence à un risque. Pour le support privilégié, le partage d'accès, l'authentification forte, la journalisation et le retrait des droits sont des points pertinents. En matière de développement de logiciels, le processus de développement, la gestion des dépendances et le traitement des vulnérabilités sont d'intérêt. Pour un service cloud, la séparation des clients, le chiffrement, la disponibilité et le contrôle des sous-traitants peuvent être au premier plan.

NIST SP 1326 décrit la due diligence comme la recherche d'informations disponibles et pertinentes sur les fournisseurs ou les produits, afin que les décisions soient prises sur une base suffisante. Le guide est adapté aux fournisseurs IKT et mentionne entre autres la résilience, les pratiques de cybersécurité de base et les niveaux de la chaîne d'approvisionnement. Il ne fournit pas de catalogue de preuves allemand universel, mais soutient la construction basée sur le risque.

Définissez avant la demande quel document, quel résumé ou quelle confirmation sera acceptée. Certains rapports ne peuvent être consultés que sous accord de confidentialité. Dans d'autres cas, un résumé de gestion suffisamment détaillé peut suffire. Si une preuve n'est pas fournie, le fournisseur doit être en mesure d'expliquer des preuves alternatives.

ISO/IEC 27001 : Vérifiez le certificat et le champ d'application.

ISO/IEC 27001:2022 définit les exigences pour un système de gestion de la sécurité de l'information. Une certification montre que le SGSI a été vérifié dans le champ d'application spécifié par rapport à la norme. Elle ne confirme pas automatiquement chaque contrôle technique individuel et chaque performance de l'entreprise.

Vérifiez le nom de l'organisation certifiée, les emplacements, les activités, la période de validité et l'organisme de certification. La description de la portée est cruciale : couvre-t-elle le service, l'environnement opérationnel et la société avec laquelle vous concluez le contrat ? Une portée très générale nécessite des questions de suivi. Un certificat pour le siège social peut exclure un service exploité séparément par une filiale.

Demandez pour les services critiques le Statement of Applicability ou un résumé approprié, dans la mesure où le fournisseur peut les divulguer. Ce document montre quels contrôles ont été sélectionnés ou exclus dans le SGSI et comment les exclusions sont justifiées. La déclaration concrète doit être liée à la portée et au service concerné.

Tenez également compte de l'actualité et des changements. Un certificat valide peut provenir d'un audit effectué avant une acquisition majeure ou un changement de produit. Clarifiez les changements substantiels et les constatations ouvertes lors d'un entretien avec le fournisseur. La certification reste une preuve importante, mais n'est pas une approbation automatique.

Utilisez les rapports SOC et BSI C5 dans le contexte approprié.

Les rapports SOC proviennent du cadre d'audit américain de l'AICPA. Le SOC 1 traite des contrôles pertinents pour la communication financière interne de l'organisation utilisatrice. Le SOC 2 examine les contrôles d'une organisation de service en matière de sécurité, de disponibilité, d'intégrité de traitement, de confidentialité ou de protection des données. Pour un audit de sécurité général, tous les rapports SOC ne sont donc pas également adaptés.

Vérifiez pour le SOC 2 la description du système, les critères de confiance inclus, la période, le résultat de l'audit, les exceptions et les contrôles complémentaires de l'entité utilisatrice. Ces contrôles clients doivent être mis en œuvre par l'organisation utilisatrice elle-même pour atteindre les objectifs de contrôle considérés. Un rapport avec un bon résultat peut perdre sa pertinence si le client ne met pas en œuvre la configuration sécurisée requise.

Le Catalogue de critères de conformité pour le cloud computing C5 du BSI est axé sur la sécurité de l'information des services cloud. Le BSI clarifie qu'une certification C5 est réalisée par des auditeurs externes et n'est pas une certification du BSI. Vérifiez donc le rapport, l'objet de l'audit et les indications d'utilisation. Un rapport C5 est particulièrement pertinent lorsque le service cloud concerné est dans le champ d'application.

C5 distingue entre les rapports de type 1 et de type 2. Selon le BSI, le type 1 évalue la description ainsi que la conception et l'implémentation des contrôles à un moment donné. Le type 2 inclut en outre des actions d'audit sur l'efficacité sur une période. Le BSI considère le type 2 comme nécessaire pour une pertinence adéquate ; des configurations particulières peuvent néanmoins justifier un rapport de type 1.

Les preuves techniques et opérationnelles doivent être complétées

Un test de pénétration examine un champ technique convenu avec une expertise humaine. Ne demandez pas nécessairement le rapport brut complet. Un résumé peut contenir la date, la méthodologie, les systèmes testés, les domaines exclus, les constatations par gravité, les risques ouverts et l'état du retest. Un test sans champ clair ou retest donne peu d'informations sur l'état actuel du service concerné.

Pour la gestion des vulnérabilités, la description du processus, la responsabilité, les sources, la logique de priorisation et les preuves des constatations fermées sont pertinentes. Les résultats d'analyse internes peuvent être très sensibles. Convenez donc d'une forme qui fournisse des preuves suffisantes sans créer de surface d'attaque inutile par la distribution de documents. Un externe Analyse des risques informatiques peut en outre vérifier les systèmes accessibles et les caractéristiques visibles.

Dans la gestion des incidents, les voies de signalement, l'accessibilité, la classification, l'investigation, l'information client et le suivi peuvent être vérifiés. Les preuves appropriées peuvent être une description de processus, un protocole d'exercice ou un résumé de cas anonymisé. Ne demandez pas de données d'incidents réels concernant des personnes ou des clients si elles ne sont pas nécessaires à votre décision.

Pour la continuité des activités et le redémarrage, il compte des responsabilités définies, des dépendances, des objectifs de redémarrage et des tests. Une politique atteste de l'exigence ; un protocole de test actuel montre si un scénario a été pratiqué et évalué. Vérifiez si le scénario testé inclut le service concerné et les sous-traitants essentiels.

Évaluer l'actualité, les exceptions et la confidentialité

Chaque preuve nécessite un état des données. Déterminez pour chaque classe de risque l'ancienneté autorisée des documents et quels événements déclenchent un nouvel examen. Des modifications essentielles du produit, un incident de sécurité, un changement de sous-traitant critique ou une nouvelle région d'exploitation peuvent rendre une preuve formellement valide nécessitant des compléments.

Lisez les exceptions et les limitations. Un rapport d'audit peut contenir des contrôles avec constatations, couvrir une courte période d'audit ou exclure des parties de la prestation. Demandez des réactions de la direction, le statut de traitement et des mesures compensatoires. Une constatation n'est pas un motif automatique de rejet ; sa signification dépend du risque et du traitement.

Traitez les rapports sensibles selon un principe de besoin d'en connaître. Utilisez une transmission protégée, un accès basé sur les rôles, une conservation définie et une suppression régulée. Conservez dans le dossier fournisseur, dans la mesure du possible, l'évaluation et la référence, sans créer de copies inutiles. Les règles contractuelles de confidentialité doivent être respectées.

La protection des données reste un domaine d'examen distinct. Si un prestataire traite des données personnelles pour le compte d'un autre, les rôles, le contrat et les exigences selon le droit applicable en matière de protection des données doivent être examinés séparément. Un certificat ISO, un rapport SOC ou un rapport C5 ne remplace pas cet examen. De même, un accord de protection des données ne prouve pas l'efficacité de tous les contrôles de sécurité.

Dériver une décision documentée à partir des preuves

Ne créez pas une simple liste de contrôle documentaire. Pour chaque risque, rassemblez la déclaration du prestataire, la preuve correspondante, ses limites et les questions ouvertes. Évaluez les preuves en fonction de leur pertinence, provenance, actualité et profondeur de vérification. Plusieurs documents faibles ne donnent pas automatiquement une déclaration forte.

Le prestataire doit pouvoir expliquer les écarts et proposer des preuves alternatives. Un petit fournisseur peut ne pas avoir de rapport SOC ou C5, mais peut fournir des preuves de processus et de tests ciblés. La décision dépend du risque et non de la taille ou de la notoriété de l'entreprise. Pour des prestations critiques, l'absence de preuves indépendantes peut néanmoins nécessiter un contrôle supplémentaire.

Documentez les preuves acceptées, l'état des données, les constatations, les mesures, les délais et le risque résiduel. Liez les dates d'échéance aux rappels. Pour les prestations en cours, des signaux externes peuvent déclencher un contrôle précoce. Cela Note de sécurité fournit un point de vue externe supplémentaire, mais ne remplace pas l'évaluation des preuves.

LocateRisk soutient la perspective technique sur les systèmes identifiés ou accessibles et leurs changements. Pour les preuves organisationnelles, des documents, des interviews et un contrôle interne restent nécessaires. Des informations sur l'intégration dans le portefeuille fournisseur se trouvent chez le Gestion du risque vendeur.

Questions fréquentes

---

Quelles preuves de sécurité sont pertinentes pour les prestataires de services informatiques ?

Cela dépend de la prestation et du risque. Les preuves possibles incluent des certificats ISO/IEC-27001, des rapports SOC ou C5, des résumés de tests d'intrusion, des politiques, des preuves de processus ainsi que des preuves de gestion des incidents et de reprise. Chaque preuve doit couvrir le service concerné dans un périmètre approprié.

---

Que faut-il vérifier dans un certificat ISO/IEC-27001 ?

Vérifiez l'organisation certifiée, les sites, les activités, la validité et l'organisme de certification. Le champ d'application doit inclure le service concerné et l'environnement opérationnel pertinent.

---

Le BSI C5 est-il une certification du BSI ?

Non. Le BSI précise que les attestations C5 sont effectuées par des auditeurs externes et ne constituent pas une certification BSI. Les éléments décisifs sont le rapport concret, son objet d'audit et les constatations.

---

Le prestataire doit-il fournir le rapport complet de test d'intrusion ?

Pas nécessairement. Selon le risque, un résumé protégé, suffisamment détaillé avec périmètre, date, méthodologie, constats, risques ouverts et statut de retest peut suffire. La confidentialité et le besoin de décision doivent être équilibrés.

---

Les preuves de sécurité remplacent-elles l'examen de la protection des données ?

Non. Les rôles relatifs à la protection des données, les exigences contractuelles et le traitement concret des données personnelles doivent être examinés séparément. Les preuves de sécurité peuvent documenter des aspects techniques et organisationnels, mais ne remplacent pas une qualification légale.

Souhaitez-vous compléter les preuves formelles par une perspective technique externe ? Demandez une évaluation de sécurité gratuite et attribuez les résultats à votre périmètre d'examen.