Notre dépendance aux prestataires et aux applications SaaS augmente chaque année : RH, paye, gestion de projet, processus métiers... . Les risques tiers menacent directement l'activité des entreprises. La démarche est maintenant plutôt bien ancrée pour les RSSI. Pour tous les nouveaux fournisseurs, il est nécessaire de contrôler le niveau de sécurité.

Mais comment être efficient pour évaluer la maturité cyber des fournisseurs ?

Le questionnaire de sécurité est systématiquement utilisé comme méthode d'évaluation, parce qu'il semble "gratuit", alors qu’un simple Excel peut faire l'affaire. Mais il y a en amont de nombreuses étapes : prendre contact avec les fournisseurs, définir les questions à poser, challenger les réponses, analyser les preuves... Des tâches chronophages et acceptables seulement par 20 ou 30 fournisseurs.

Intuitivement et pour aller plus vite, il arrive d'extraire les contrôles de l'ISO pour en faire un questionnaire de sécurité. C'est rassurant mais cela omet un point crucial : qui va évaluer la pertinence des réponses et leur adéquation avec le projet ? Qui aura le temps de contrôler 90 points de sécurité pour 100, 200, 300 fournisseurs ?

Cet article propose une réflexion sur ce sujet et liste les 10 questions essentielles qu’un RSSI doit impérativement poser à un fournisseur SaaS. Elles s’inscrivent dans une démarche TPRM (Third-Party Risk Management).

Industrialiser la due diligence TPRM

Industrialiser les questionnaires de sécurité dans une démarche TPRM est essentiel si vous souhaitez passer à l'échelle. En effet, dans le cadre de NIS2, il est devenu obligatoire d'élargir l'analyse de maturité sur des périmètres pouvant aller de 100 à 300 fournisseurs en fonction des organisations.

Il y a plusieurs composantes à cette industrialisation, notamment :

• Identifier les fournisseurs de votre organisation
• Réaliser un “tiering” de ses fournisseurs
• Définir des dispositifs d'évaluation en fonction du tiering
• Rechercher le budget et les ressources

Industrialiser les questionnaires de sécurité

La collecte d’informations sur la maturité doit être structurée et simplifiée pour maintenir une capacité à diffuser les questionnaires vers de nombreux fournisseurs  :

• Définir un processus de gestion des questionnaires
• Limiter le nombre de questions
• Concentrer votre effort sur l'essentiel et sur des contrôles vérifiables

La standardisation produit des réponses exploitables (“machine-readable”), alimente des tableaux de bord (taux de complétion, délais, risques résiduels) et permet une priorisation factuelle des plans d’action, concentrée sur les écarts à plus fort impact.

L’expérience fournisseur s’en trouve aussi améliorée grâce à des trames stables, des consignes explicites sur le format des preuves et la possibilité de réutiliser des réponses validées, ce qui accélère la complétion et diminue la friction. Vos fournisseurs vous diront merci !

RSSI : Les 10 questions essentielles à poser pour une application SaaS

Pour chaque question, nous vous partageons les points suivants :

• Pourquoi c’est clé
• Bonne réponse attendue
• Signaux d’alerte
• Preuves à demander

1. Gouvernance : Avez-vous mis en place une PSSI et réalisé une analyse de risque sur votre SI ou Service ?

• Pourquoi c’est clé : Sans gouvernance, pas de priorisation ni de responsabilité. Les incidents durent plus longtemps.
• Bonne réponse attendue : Gouvernance formalisée, RACI (Responsible, Accountable, Consulted, Informed) à jour, comité de sécurité actif. Analyse de risques annuelle alignée sur ISO/IEC 27005.
• Signaux d’alerte : Rôles flous, pas de revue de risques, politique de sécurité non publiée.
• Preuves à demander : Politique de sécurité signée, matrice RACI, compte-rendu de comité, registre des risques et plans d’action.

2. Gestion des accès : Avez-vous mis en place un SSO sur vos applications et vos services ?

• Pourquoi c’est clé : Le SSO (Single Sign-On) réduit l’attaque par mot de passe et centralise les droits.
• Bonne réponse attendue : Intégration IAM (Identity and Access Management) avec votre IdP. Provisioning automatisé (SCIM). Révocation instantanée.
• Signaux d’alerte : Comptes locaux permanents, absence de journalisation des connexions, MFA partiel.
• Preuves à demander : Diagramme d’architecture SSO, procédure de “deprovisioning”, extrait de logs d’authentification, configuration SCIM.

3. Accès privilégiés : Est-ce que vos administrateurs se connectent systématiquement, en interne comme aux services avec à minima, un deuxième facteur d'authentification et via un VPN pour un service en ligne ?

• Pourquoi c’est clé : Les comptes admin sont ciblés en priorité. Un accès distant non contrôlé élargit la surface d’attaque.
• Bonne réponse attendue : MFA (Multi-Factor Authentication) fort pour tous les admins. Accès admin via bastion ou VPN restreint. PAM (Privileged Access Management) et élévation JIT (Just-In-Time).
• Signaux d’alerte : Comptes “break-glass” non protégés, super-admin permanents, accès depuis internet sans filtrage.
• Preuves à demander : Liste des rôles admin, politique MFA, traces PAM, liste des comptes d’urgence, preuves de contrôle d’origine IP.

4. Gestion des vulnérabilités : Avez-vous mis en place un suivi et un système de gestion des vulnérabilités afin de déployer rapidement en production les nouveaux patchs publiés par les éditeurs (notamment pour les vulnérabilités critiques) ?

• Pourquoi c’est clé : Le délai de correction reste déterminant. Les CVE (Common Vulnerabilities and Exposures) doivent être traitées selon la criticité.
• Bonne réponse attendue : Inventaire des actifs, priorisation CVSS, SLA (Service Level Agreement) de patching clair, scans récurrents.
• Signaux d’alerte : Absence d’inventaire, correctifs “best effort”, backlog non priorisé.
• Preuves à demander : Politique de patching, rapports de scan récents, indicateurs MTTR, exemples de tickets fermés.

5. Développements : Les environnements de production, dans le cadre d'un service ou de développement logiciel, sont-ils cloisonnés logiquement ? Les données de production sont-elles utilisées en développement ?

• Pourquoi c’est clé : Confondre dev / test / prod mène à des fuites de données et à des incidents.
• Bonne réponse attendue : Environnements distincts, données masquées en test, secrets gérés en coffre-fort. Revue de code et CI/CD avec contrôles.
• Signaux d’alerte : Accès direct à la prod depuis dev, clés en clair, absence de peer review.
• Preuves à demander : Schéma des environnements, politiques CI/CD, extraits d’audit de dépôts, exemple de pipeline avec contrôles.

6. Protection des données : Avez-vous mis en place un chiffrement des données au repos sur tous les systèmes (postes de travail et serveurs) ? Avez-vous réalisé toutes les démarches liées à la réglementation RGPD ? (Déclaration, hébergement...)

• Pourquoi c’est clé : La conformité et la confiance client reposent sur ces garanties.
• Bonne réponse attendue : RGPD (Règlement Général sur la Protection des Données) respecté, DPA (Data Processing Agreement) en place, localisation définie, chiffrement au repos et en transit.
• Signaux d’alerte : DPA générique, transferts internationaux non cadrés, clés non gérées.
• Preuves à demander : DPA signé, registre des traitements, DPIA si applicable, attestation de chiffrement, inventaire des sous-traitants.

7. Codes malveillants : Avez-vous déployé un EDR sur les équipements compatibles ?

• Pourquoi c’est clé : Les terminaux d’admin et de support exposent le SaaS.
• Bonne réponse attendue : EDR (Endpoint Detection and Response) déployé et supervisé. Intégration au SIEM (Security Information and Event Management).
• Signaux d’alerte : Couverture partielle, alertes non traitées, absence de tests d’évasion.
• Preuves à demander : Taux de couverture EDR, playbooks de réponse, échantillons d’alertes, preuves d’intégration SIEM.

8. Continuité : Quelle est la fréquence des sauvegardes de vos services critiques et quels sont les RTO/RPO de votre service ?

• Pourquoi c’est clé : La résilience opérationnelle reste un impératif contractuel et réglementaire.
• Bonne réponse attendue : Sauvegardes régulières, tests de restauration. RTO (Recovery Time Objective) et RPO (Recovery Point Objective) définis et réalistes. BCP/DRP (Business Continuity / Disaster Recovery) validés.
• Signaux d’alerte : Sauvegardes “à la demande”, absence de tests, dépendance à un seul cloud.
• Preuves à demander : Rapports de tests DR, métriques de restauration, diagramme d’architecture de résilience, extrait de procédure de crise.

9. Chaîne d’approvisionnement : Maintenez vous un inventaire et réalisez-vous des contrôles de sécurité de vos fournisseurs ?

• Pourquoi c’est clé : Les sous-traitants de vos sous-traitants héritent de vos exigences.
• Bonne réponse attendue : Inventaire des quatrièmes parties, évaluations régulières, critères de criticité alignés avec NIS2 (directive sur la cybersécurité des réseaux et systèmes d’information) et DORA (Digital Operational Resilience Act).
• Signaux d’alerte : Liste incomplète, dépendances cachées, aucune clause de réversibilité.
• Preuves à demander : Registre des “fourth parties”, clauses contractuelles, résultats d’audits, preuves de réversibilité et d’exit plan.

10. Audit : Réalisez-vous des pentest internes ou sur votre service, à minima de façon annuelle ?

• Pourquoi c’est clé : Les preuves techniques confirment la réalité opérationnelle, pas seulement l’intention.
• Bonne réponse attendue : Pentest annuel indépendant, remédiation suivie, évaluation externe type Security Rating.
• Signaux d’alerte : Pentest daté, périmètre incomplet, aucune vérification externe.
• Preuves à demander : Rapport de pentest récent, plan d’actions et statuts, attestations SOC 2 (System and Organization Controls 2)

Conclusion

En tant que RSSI, structurer vos exigences autour de ces 10 questions accélère la due diligence. Vous obtiendrez des réponses comparables, des preuves vérifiables, et des décisions documentées.

Industrialisez la démarche avec des rôles clairs, un calendrier lisible et des outils adaptés. Vous réduisez le risque tiers sans freiner la performance des métiers.

FAQ

Quelles preuves demander à un fournisseur critique ? Politiques signées, RACI, rapports de scan, pentest récent, attestations ISO/IEC 27001 ou SOC 2, DPA, extraits de logs, résultats de tests DR.

Comment aligner NIS2 et TPRM ? Mappez les exigences NIS2 aux contrôles TPRM : gouvernance, gestion des incidents, continuité, chaîne d’approvisionnement. Fixez une cadence de revue selon la criticité.

Quelle cadence d’audit pour les sous-traitants ? À l’onboarding puis annuellement pour les services critiques. Bisannuel pour les services non critiques. Revue exceptionnelle après incident ou changement majeur.

Article rédigé par Gilles Favier - VP Product - Board of Cyber