Aller au contenu

Questionnaire sécurité grand compte : répondre avec preuves

Publié et mis à jour le · Rédaction : Scope & Evidence

Un questionnaire de sécurité grand compte doit recevoir des réponses correspondant au SaaS acheté et à l’état réel de vos pratiques. Écrire « oui » pour éviter un blocage commercial peut créer une contradiction avec le contrat ou les preuves. Organisez les réponses avec leurs responsables, leurs sources et leur date. Un certificat, un rapport SOC 2 et un pentest répondent à des questions différentes. Leur présence ne justifie pas une affirmation générale de conformité à toutes les demandes.

Cadre de référence : source primaire du sujet. Les recommandations opérationnelles ci-dessous sont à adapter à votre organisation.

Qualifier la question avant de répondre

Identifiez le produit, l’environnement et l’entité visés. Certaines formulations concernent la sécurité interne de toute l’entreprise, d’autres l’exploitation d’un service précis. Si la question est ambiguë, demandez une clarification plutôt que d’étendre votre réponse. Distinguez aussi une exigence contractuelle d’un simple recueil d’informations. Le commercial peut centraliser l’échange, mais les affirmations techniques doivent être validées par les responsables compétents. Conservez les précisions reçues du client avec le dossier.

Créer un registre de réponses contrôlé

Pour chaque sujet, indiquez une formulation, une preuve de référence, un propriétaire et une date de revue. Le registre doit permettre de répondre sans recopier une ancienne version non vérifiée. Les changements d’architecture, de fournisseur ou de politique peuvent rendre une réponse obsolète. Identifiez les sujets nécessitant une validation juridique ou contractuelle. Évitez les garanties générales qui dépassent les engagements réellement pris. Une formulation courte peut être précise si elle indique la portée et les limites utiles au client.

Utiliser le bon document

Le certificat ISO décrit une portée de SMSI ; le rapport SOC 2 comporte le système et la période examinés ; le pentest décrit des travaux techniques limités à son propre périmètre. Une politique exprime une règle, tandis qu’une trace d’exécution aide à montrer son application. Associez chaque pièce à la question qu’elle soutient. Un rapport sur un autre produit ne doit pas être présenté comme couvrant celui vendu. Si une preuve manque, indiquez le statut réel et les éléments disponibles.

Organiser le partage sous confidentialité

Classez les documents selon leur sensibilité et leurs restrictions de communication. Le partage d’un rapport complet peut nécessiter un accord ou des modalités propres au document. Ne transmettez pas de secrets, de vulnérabilités détaillées ou de données personnelles sans besoin défini. Préparez des synthèses adaptées et des accès limités lorsque cela convient. Le client doit comprendre les limites d’une synthèse ; elle ne doit pas masquer une exception importante du rapport qu’elle décrit.

Garder une trace de ce qui a été promis

Conservez la version du questionnaire envoyée et les validations internes. Certaines réponses peuvent être incorporées au contrat : elles doivent rester compatibles avec vos pratiques et vos engagements. Si vous découvrez une erreur, organisez une correction avec les interlocuteurs concernés. Les demandes récurrentes peuvent alimenter le plan de préparation ISO ou SOC 2, mais chaque grand compte garde son propre processus de qualification. Aucun document ne garantit l’acceptation du fournisseur ni la signature commerciale.

Préparer une revue avant envoi

Faites relire les réponses sensibles par le CTO et, lorsque nécessaire, les responsables contractuels. Vérifiez les liens vers les pièces et leurs restrictions. Un champ de texte peut sembler informatif alors qu’il devient un engagement dans un contrat. Conservez la validation et la version finale. Si vous corrigez une réponse après envoi, tracez la modification et les interlocuteurs concernés. Le registre doit permettre de savoir ce que le client a reçu, pas seulement ce qui figure dans votre bibliothèque actuelle.

Exemple de travail, fictif

Exemple fictif : un questionnaire demande si le service a une reprise testée pour toute perte de région. Le SaaS dispose seulement d’un test de restauration de base en environnement isolé. Le CTO décrit cette portée et indique que le scénario régional n’a pas encore été testé. Le commercial demande les preuves complémentaires acceptées par le client. Cette réponse peut ouvrir un chantier de préparation, mais elle évite de transformer un test limité en garantie contractuelle plus large.

Ce que votre dossier doit permettre de vérifier

  • Le produit et l’environnement visés par le questionnaire.
  • Une réponse datée avec propriétaire et source de preuve.
  • Des limites explicites lorsque les documents ne couvrent pas tout.
  • Des règles de partage adaptées à la sensibilité des pièces.
  • La version envoyée, les validations et un circuit de correction.

Questions avant de décider

Que répondre quand la preuve manque ?

Décrivez le statut réel, les limites et les éléments disponibles. Une réponse inconnue ou partielle expliquée vaut mieux qu’une affirmation de conformité sans fondement.

Peut-on réutiliser les réponses d’un autre client ?

Comme point de départ seulement. Vérifiez le produit, la date, les changements et les formulations contractuelles. Gardez un registre contrôlé plutôt qu’une copie non relue.

Un rapport SOC 2 dispense-t-il de répondre ?

Non. Les questions peuvent être hors portée, plus récentes ou plus spécifiques. Reliez les réponses au rapport réel et aux autres preuves disponibles.

Préparer la suite du travail

Sources et portée de lecture

Les sources ci-dessous documentent le cadre ou le fait cité. Les propositions d’organisation sont des conseils de préparation à adapter à votre situation. Elles ne reproduisent pas le texte des normes et ne constituent pas une décision d’audit ni un avis juridique.