Fournisseur critique sans certification : préparer une évaluation proportionnée

Un fournisseur peut être essentiel à votre service sans présenter de certificat ISO/IEC 27001. Cette absence ne prouve pas à elle seule que ses mesures sont mauvaises ; elle ne permet pas non plus de supposer qu’elles sont bonnes. La décision utile consiste à définir le risque du service acheté, les garanties que vous devez comprendre et les preuves alternatives accessibles. Elle peut conduire à contracter sous conditions, à demander une correction, à réduire la dépendance ou à choisir un autre fournisseur.

Cette page propose un plan d’assurance alternatif. La politique de sécurité fournisseurs fixe le cadre d’évaluation et le questionnaire ; le guide de criticité fournisseur aide à classer les dépendances. Ici, le cas précis est un fournisseur critique qui ne dispose pas d’une certification couvrant le service. Le NIST SP 1305 recommande d’adapter les exigences à la criticité et mentionne diverses formes de preuve, notamment auto-attestation, normes, certifications ou inspections. Il ne rend pas une certification particulière obligatoire pour toute relation contractuelle française.

Décrire le service, pas seulement l’entreprise

Quel service est acheté, par quelle entité et pour quelle activité ? Quelles fonctions seraient interrompues si le fournisseur s’arrêtait ? Dispose-t-il d’un accès privilégié, héberge-t-il des données, développe-t-il un composant ou intervient-il seulement pendant une maintenance ? Deux prestations du même groupe peuvent demander des preuves différentes. La fiche doit préciser les lieux et les personnes morales connus, ainsi que les hypothèses encore à confirmer.

Un fournisseur de DNS peut être critique pour la disponibilité sans traiter de données sensibles. Un prestataire de santé peut être critique par la confidentialité et la continuité. La classification doit distinguer ces dimensions et expliquer les conséquences concrètes. Un score global « critique » ne dit pas quel contrôle examiner. Le guide NIS 2 sur la chaîne de sous-traitance donne le contexte pour les entités concernées, mais ne transforme pas tous leurs prestataires en détenteurs obligatoires d’un même certificat.

Vérifiez aussi la substituabilité. Un service peut être techniquement simple mais difficile à remplacer à cause d’une intégration, d’un format propriétaire ou d’une concentration de fournisseurs. Le plan d’assurance doit alors examiner davantage la réversibilité et la continuité que l’apparence d’un questionnaire de sécurité très détaillé.

Vérifier ce que l’absence de certificat signifie

Demandez si le fournisseur n’a jamais cherché de certification, si un audit est prévu, si une autre entité du groupe est certifiée ou si le certificat existe mais exclut le service acheté. Ces situations ne sont pas équivalentes. Un certificat portant sur un autre centre de données ne couvre pas automatiquement votre traitement. Une certification expirée reste un élément historique, pas une assurance courante. Le guide de certification ISO/IEC 27001 situe le rôle du périmètre et du système de management.

Ne convertissez pas l’absence de certification en dérogation administrative automatique. Si un contrat ou une règle sectorielle applicable exige effectivement un niveau de qualification, identifiez la source, le service et la personne morale concernés. Une analyse de risque interne ne supprime pas une exigence obligatoire. À l’inverse, si aucune source applicable n’impose cette certification, vous pouvez rechercher d’autres garanties proportionnées.

L’ISO présente publiquement ISO/IEC 27001:2022 comme un système de management de la sécurité de l’information fondé sur la gestion du risque. Sa page publique ne permet pas de réciter des clauses ou de décréter qu’un fournisseur sans certificat ne respecte aucune mesure. Une preuve directe peut éclairer une question précise, tout en offrant une portée plus limitée qu’un audit indépendant sur un système de management.

Préparer le plan d’assurance par scénario

Dans la fiche, écrivez le scénario d’échec avant la demande de documents. Un risque de panne appelle preuves de continuité et d’essai de reprise ; un risque d’accès excessif appelle liste des rôles, procédure de retrait et résultats de contrôle ; un risque de modification malveillante appelle chaîne de développement, approbations et traçabilité. Une politique générale de sécurité peut fournir du contexte, mais elle ne démontre pas que ces mécanismes fonctionnent sur le service acheté.

Cette fiche est un outil de décision, pas un substitut à une clause contractuelle ni à une obligation propre au secteur. Elle doit permettre à une personne indépendante de comprendre pourquoi les preuves demandées répondent aux risques du service et ce que la décision laisse ouvert.

Demander des preuves directes et limitées

Pour la gouvernance, demandez qui est responsable de la sécurité du service, comment une exception remonte et comment les décisions sont conservées. Pour les accès, cherchez un échantillon de revue datée, la méthode de retrait et un cas de mobilité ou de départ. Pour la continuité, demandez les objectifs de reprise contractuels et un résultat de restauration qui couvre une composante pertinente du service. Pour les incidents, vérifiez les contacts et le chemin de communication convenu.

Il n’est pas toujours nécessaire de recevoir le rapport complet d’un test d’intrusion ou des journaux contenant les données d’autres clients. Une synthèse datée, le périmètre, les principaux écarts et la preuve de leur traitement peuvent être plus adaptés. Si le fournisseur invoque la confidentialité, discutez une consultation sous accord, un entretien avec un auditeur indépendant ou une attestation ciblée. Notez ce que ces alternatives ne permettent pas de conclure.

Le NIST SP 800-53A distingue examen, entretien et test ; ces méthodes peuvent être combinées selon le besoin. Une auto-attestation est une source d’information, pas une confirmation indépendante. Un essai réussi sur un environnement de démonstration ne prouve pas toute la production. Qualifiez toujours la portée de la pièce.

Conduire un entretien utile au lieu d’un long questionnaire

Un entretien court peut lever des ambiguïtés qu’un formulaire standard entretient. Demandez au responsable opérationnel de décrire le dernier incident significatif pour le service, ou un exercice de reprise récent : qui a décidé, quelles ressources ont été utilisées, quel résultat était inattendu et quelle correction a suivi ? Posez la même question au contact sécurité et comparez les réponses. Une divergence n’est pas nécessairement un mensonge ; elle peut révéler une responsabilité mal définie.

Préparez les questions à partir du scénario, pas d’une liste universelle de « bonnes pratiques ». Pour un fournisseur de DNS, la disponibilité, la résilience des changements et la procédure de bascule comptent probablement plus qu’une politique RH détaillée. Pour un développeur doté d’un accès en production, l’authentification, les droits, la revue de code et la révocation peuvent être centrales. Notez le rôle de l’interlocuteur et les limites de ce qu’il a personnellement vérifié.

L’entretien ne doit pas produire un « conforme » parce que l’interlocuteur est convaincant. Rattachez les affirmations matérielles à un extrait, un essai ou une clause. Quand une preuve ne peut être partagée, consignez la raison, la mesure alternative et le risque résiduel à faire accepter.

Exemple suivi : un prestataire de sauvegarde sans certificat

Dans un exemple fictif, une PME confie la sauvegarde d’un service de commandes à un prestataire régional. Aucun certificat ISO/IEC 27001 ne couvre cette activité. Le prestataire produit une politique de sécurité et une présentation de son architecture, mais pas de rapport de restauration récent. L’entreprise identifie deux risques : perte de données après une attaque et impossibilité de récupérer les clés si le prestataire est indisponible.

Le plan d’assurance demande le dernier essai de restauration avec périmètre, date, durée et résultat, puis organise un essai conjoint limité à des données de test. Il vérifie qui détient les clés, comment l’accès est révoqué après départ d’un technicien et quel canal d’incident est prévu. Le fournisseur accepte l’essai, mais la première restauration dépasse l’objectif du service. Cette information vaut davantage qu’une réponse « sauvegardes quotidiennes » cochée dans un questionnaire.

Le responsable métier choisit une mesure provisoire : une copie indépendante sur un périmètre réduit, pendant que le prestataire corrige la procédure et programme un retest. Le contrat précise les objectifs, les rôles, les notifications et les conditions de sortie. Après un nouvel essai concluant, la réserve sur le délai peut être levée ; celle sur la dépendance aux clés demeure jusqu’à vérification. L’absence de certificat n’est ni l’unique raison du risque ni une preuve de sa disparition après le retest.

Relier l’assurance au contrat et aux droits réels

Une preuve fournie volontairement au début de la relation ne garantit pas l’accès aux mêmes informations pendant le contrat. Définissez les engagements pertinents : notification d’incident, droit de demander des éléments de contrôle, coopération en cas de test, changements de sous-traitants, continuité et restitution à la sortie. Leur portée doit correspondre au service et au pouvoir de négociation réel. Une clause impossible à exercer peut donner une fausse impression de maîtrise.

Si le fournisseur agit comme sous-traitant de données personnelles, l’article 28 du RGPD exige notamment des garanties suffisantes et un contrat ou autre acte juridique avec le contenu prévu. L’appréciation doit être liée au traitement confié ; une certification facultative ne remplace pas l’examen des garanties ni les clauses nécessaires. Un prestataire sans données personnelles n’entre pas dans ce rôle sur la seule base de sa criticité pour la disponibilité.

Pour une entité financière du champ de DORA, les prestataires TIC et leurs contrats demandent une analyse spécifique des fonctions soutenues et des dispositions applicables. Ne transposez pas ces clauses à tout achat informatique sans qualifier le client et le service. De même, la sécurité de la chaîne NIS 2 doit être reliée à l’entité et au droit national pertinent.

Décider explicitement malgré une information incomplète

Le plan doit présenter les faits confirmés, les hypothèses, les preuves manquantes, les options et la conséquence de chacune. « Fournisseur accepté » est insuffisant si un essai important reste à faire. La décision peut être une acceptation limitée dans le temps, un démarrage sur un périmètre réduit, une mesure compensatoire vérifiée ou un refus. Nommez la personne habilitée à prendre ce risque et la date ou l’événement qui rouvrira la décision.

Un score de questionnaire ne remplace pas cette analyse. Deux défauts peuvent avoir le même poids numérique mais des effets très différents : un retard dans la transmission d’une charte et une restauration impossible pour le seul service critique. Le dossier doit montrer pourquoi la mesure retenue traite le scénario important. Le plan d’actions d’audit aide à séparer correction déclarée et résultat retesté.

Si le fournisseur refuse toute information pertinente, documentez ce refus et son impact. Il ne constitue pas automatiquement une interdiction légale universelle ; il peut néanmoins rendre impossible une assurance suffisante pour votre service ou votre obligation particulière. Comparez alors une alternative, une réduction de dépendance et le coût d’un report. La décision doit être explicite, non cachée derrière « questionnaire non retourné ».

Réévaluer lorsque le service change

Une évaluation datée concerne un service, une architecture et une relation contractuelle. Un nouveau sous-traitant, une migration de données, un accès administrateur supplémentaire, un incident ou un changement d’objectif de reprise peut rendre une preuve insuffisante. Définissez les événements qui déclenchent une revue et la personne qui les signale. Une revue annuelle peut être choisie en interne, mais elle ne remplace pas l’analyse après changement significatif.

Conservez les anciennes preuves et la décision qui s’y rapportait. Lorsque le fournisseur obtient finalement une certification, vérifiez le périmètre, la validité et ce qu’elle ajoute à la conclusion ; ne supprimez pas les réserves sans examen. Lorsqu’il perd une certification, ne supposez pas que toutes ses mesures se sont effondrées ; demandez ce qui a changé et quelles garanties restent disponibles. La matrice de validité des preuves peut aider à qualifier ces situations.

Préparez enfin la sortie. Quel autre fournisseur pourrait reprendre le service, dans quel délai, avec quelles données, clés et procédures ? Le NIST SP 1305 en texte intégral traite la gestion du risque dans la chaîne d’approvisionnement tout au long du cycle. Pour un fournisseur critique sans certificat, une voie de sortie testable peut apporter plus de résilience qu’une demande de document répétée sans résultat.

Vérifier que le dossier répond à la vraie question

Le lecteur doit pouvoir retrouver le service, les scénarios, les preuves examinées, les réserves, les mesures provisoires et le décideur. Il doit aussi comprendre ce qui n’a pas été vérifié. Une évaluation proportionnée n’est pas une évaluation superficielle : elle concentre les efforts sur les conséquences importantes et choisit des preuves qui peuvent réellement les éclairer.

L’absence de certification reste un fait à noter, pas un verdict automatique. La décision repose sur la qualité des garanties disponibles pour le service précis et sur la possibilité de corriger ou de limiter les risques restants. Ce dossier permet de prendre cette décision de manière explicite, puis de la revoir lorsque la relation ou le service évolue.