Comment auditer le risque tiers de vos fournisseurs SaaS en 6 etapes

En 2026, l’entreprise moyenne utilise 130 a 180 applications SaaS. Chacune represente un point d’entree potentiel dans votre systeme d’information. Les breaches MOVEit (2023), Okta (2024) et Canvas/Instructure (mai 2026) ont montre que la compromission d’un seul fournisseur peut exposer des centaines de millions de comptes.

Pourtant, la majorite des RSSI n’ont pas de processus structure pour evaluer et surveiller le risque tiers SaaS. Un SOC 2 Type II ou une certification ISO 27001 du fournisseur ne suffit pas : ces audits testent le perimetre global du fournisseur, pas l’isolation specifique de vos donnees dans son environnement.

Ce guide presente 6 etapes concretes pour construire un programme d’audit de risque tiers SaaS robuste, applicable des le prochain trimestre. Chaque etape produit un delivrable actionnable et s’inscrit dans les exigences NIS2 et DORA pour les entites regulees.

— Etape 1 : Dresser l’inventaire exhaustif de vos applications SaaS

Avant d’evaluer un risque, il faut le connaitre. La premiere etape est de dresser l’inventaire complet de toutes les applications SaaS utilisees dans votre entreprise — y compris le shadow IT, ces outils que vos equipes utilisent sans validation de la DSI.

Methode 1 : Analyse des flux reseau. Utilisez votre proxy ou votre CASB (Cloud Access Security Broker) pour identifier tous les domaines SaaS contactes par vos postes de travail sur les 90 derniers jours. Outil accessible : Microsoft Defender for Cloud Apps, Netskope, ou meme une simple analyse des logs DNS.

Methode 2 : Audit des OAuth tokens. Interrogez votre IdP (Azure AD, Okta, Google Workspace) pour lister toutes les applications tierces ayant obtenu des OAuth tokens. Chaque token represente une delegation d’acces que vous devez connaitre et maitriser.

Methode 3 : Enquete aupres des metiers. Envoyez un questionnaire aux managers de chaque departement : « Quels outils en ligne utilisez-vous au quotidien, meme ponctuellement ? » Les reponses revelent systematiquement 20 a 40 % d’applications inconnues de la DSI.

Delivrable attendu : un registre SaaS avec pour chaque application : nom, editeur, URL, nombre d’utilisateurs, donnees traitees (types), methode d’authentification, et responsable metier. Ce registre sera la base de l’etape 2.

— Etape 2 : Classifier vos fournisseurs par niveau de risque

Tous les fournisseurs SaaS ne representent pas le meme niveau de risque. L’etape 2 consiste a classifier chaque application en trois tiers pour prioriser vos efforts d’audit.

Tier 1 — Critique : le fournisseur traite des donnees personnelles sensibles (RH, sante, finance) ET/OU son indisponibilite bloque un processus metier critique. Exemples : SIRH, CRM avec donnees clients, ERP, messagerie d’entreprise, plateforme de paiement. Audit annuel complet + revue trimestrielle.

Tier 2 — Standard : le fournisseur traite des donnees internes non sensibles ou son indisponibilite degrade mais ne bloque pas l’activite. Exemples : outils de collaboration (Miro, Figma), gestion de projet (Asana, Monday), analytics. Audit tous les 18 mois.

Tier 3 — Non critique : le fournisseur ne traite pas de donnees sensibles et est facilement remplacable. Exemples : outils de design, utilitaires ponctuels. Questionnaire simplifie tous les 2 ans.

Les criteres de classification reposent sur quatre axes : volume et sensibilite des donnees, criticite pour la continuite d’activite, niveau d’integration technique (API, SSO, acces reseau), et exposition reglementaire (NIS2, RGPD, DORA). Un fournisseur qui coche deux axes ou plus est automatiquement en tier 1.

— Etape 3 : Administrer un questionnaire de securite structure

Pour chaque fournisseur tier 1 et tier 2, administrez un questionnaire de due diligence securite. Les frameworks de reference sont le CAIQ (Consensus Assessments Initiative Questionnaire) de la CSA et le SIG (Standardized Information Gathering) de Shared Assessments. Nous recommandons une version adaptee de 60 a 80 questions pour les tier 1, et 25 a 30 pour les tier 2.

Les 10 questions incontournables :

1. Architecture multi-tenant : comment les donnees de chaque client sont-elles isolees (isolation logique, physique, encryption par tenant) ?
2. Gestion des vulnerabilites : quelle est la frequence des pentests ? Transmettez-vous les rapports complets aux clients ?
3. Chiffrement : les donnees sont-elles chiffrees au repos et en transit ? Qui detient les cles ?
4. Gestion des acces : supportez-vous le SSO (SAML/OIDC) et le SCIM pour le provisioning ?
5. Reponse aux incidents : quel est le SLA de notification en cas de breach ? Sous combien d’heures ?
6. Sous-traitants : quels sous-traitants traitent nos donnees ? Ou sont-ils localises ?
7. Certifications : SOC 2 Type II, ISO 27001, et depuis quand ? Transmettez le rapport complet.
8. Continuite d’activite : quel est le RTO/RPO ? Les backups sont-ils testes regulierement ?
9. Portabilite des donnees : dans quel format et delai les donnees sont-elles exportables en cas de fin de contrat ?
10. Droit d’audit : acceptez-vous un droit d’audit contractuel ? Un pentest par le client ?

L’approche zero trust s’applique aussi a la relation fournisseur : ne prenez jamais les reponses au questionnaire pour argent comptant. L’etape 4 vient verifier techniquement les affirmations.

— Etape 4 : Tester l’isolation tenant et la posture technique

Le questionnaire capture la posture declaree du fournisseur. L’etape 4 la verifie. Pour chaque fournisseur tier 1, nous recommandons un test d’isolation tenant — un pentest cible qui verifie que vos donnees ne sont pas accessibles depuis un autre tenant du meme fournisseur.

Scenario de test type : creer un second compte sur la meme plateforme (version trial ou freemium), puis tenter d’acceder aux donnees du tenant de production via les APIs, les identifiants enumeres, ou les mecanismes de partage internes. C’est exactement le vecteur utilise par ShinyHunters sur Canvas — et un test qui aurait revele la faille avant l’exploitation.

Au-dela de l’isolation tenant, testez egalement : les permissions API (un token avec des droits excessifs est un vecteur d’exfiltration), la gestion des sessions (expiration, rotation des tokens), et les mecanismes de logging (le fournisseur enregistre-t-il les acces aux donnees et vous les transmet-il ?). Notre guide sur les differences entre vulnerability assessment et pentest detaille les methodes applicables.

Point cle : le droit d’audit doit etre inscrit dans le contrat. Sans clause contractuelle, le fournisseur peut refuser le pentest. NIS2 et DORA renforcent cette exigence pour les entites regulees : les fournisseurs critiques doivent accepter un droit d’audit annuel.

— Etape 5 : Mettre en place un monitoring continu

L’audit ponctuel ne suffit pas. Le risque tiers evolue en continu : un fournisseur certifie peut perdre sa certification, subir un incident, ou modifier son architecture sans vous prevenir. L’etape 5 met en place un monitoring continu de votre surface de risque tiers.

Niveau 1 : Monitoring reputation et incidents. Configurez des alertes sur les noms de vos fournisseurs tier 1 dans Google Alerts, Recorded Future, ou un outil de threat intelligence. Objectif : etre informe dans l’heure si votre fournisseur apparait dans un incident de securite ou sur un forum darknet.

Niveau 2 : Monitoring technique. Surveillez les changements de posture technique de vos fournisseurs : expiration des certificats TLS, modifications DNS, nouvelles sous-domaines, changements de headers de securite. Des outils comme SecurityScorecard, BitSight ou UpGuard automatisent cette surveillance et fournissent un score de risque continu.

Niveau 3 : Monitoring contractuel. Mettez en place un calendrier de revue des certifications et des rapports d’audit de vos fournisseurs. Un SOC 2 expire, une ISO 27001 non renouvelee, ou un rapport de pentest qui date de plus de 12 mois sont des signaux d’alerte.

— Etape 6 : Preparer un plan de sortie et de reversibilite

La derniere etape est souvent la plus negligee, et pourtant elle est cruciale. Un plan de sortie repond a la question : « Si ce fournisseur est compromis demain, combien de temps me faut-il pour migrer vers une alternative ? »

Elements d’un plan de sortie robuste :

• Fournisseur alternatif identifie : pour chaque fournisseur tier 1, identifiez au moins un fournisseur alternatif et validez qu’une migration technique est possible en moins de 30 jours.
• Export de donnees teste : ne vous contentez pas de la promesse contractuelle de portabilite. Testez l’export de vos donnees au moins une fois par an pour verifier que le format est exploitable et que les volumes sont coherents.
• Procedure de coupure d’urgence : documentez la procedure pour couper l’acces a un fournisseur compromis en moins de 4 heures : revocation des tokens OAuth, blocage des domaines au proxy, desactivation des integrations API.
• Communication de crise pre-redigee : preparez les templates de communication interne et externe a utiliser si un fournisseur est compromis. Le temps de crise n’est pas le moment de rediger.
• Budget de migration provisionne : la migration d’urgence coute 3 a 5 fois plus cher qu’une migration planifiee. Provisionnez un budget annuel de contingence pour les migrations non planifiees.

La breach Canvas est l’illustration parfaite : les institutions qui avaient un plan de sortie et un LMS alternatif ont pu basculer en 48 heures. Les autres ont subi une semaine d’interruption en pleine periode d’examens. La preparation en amont fait toute la difference.

— Synthese : construire une maturite progressive

L’audit de risque tiers SaaS n’est pas un projet ponctuel — c’est un programme continu. La bonne nouvelle : il n’est pas necessaire de tout faire d’un coup. Commencez par les etapes 1 et 2 (inventaire et classification), qui peuvent etre realisees en 2 semaines. Les etapes 3 a 6 se deploient progressivement sur les 6 mois suivants.

L’investissement initial est modeste — 4 a 8 semaines de travail pour un ETP GRC — mais le retour est measurable : reduction du risque tier-1 de 60 a 80 %, conformite NIS2/DORA demontrable, et surtout, la capacite a reagir en heures plutot qu’en semaines quand le prochain Canvas surviendra.

Car il surviendra. La question n’est pas de savoir si un de vos fournisseurs sera compromis, mais quand. Votre programme de risque tiers est ce qui determine si cet incident sera une crise majeure ou un incident maitrise.

— FAQ