Gestion de la posture de sécurité SaaS pour les audits de 2026

Le constat d’audit SaaS dont personne n’était responsable

À 08:15 un mardi, le RSSI d’une fintech en forte croissance reçoit un message du délégué à la protection des données : « Pourquoi un export client issu d’un outil collaboratif est-il partageable publiquement, et qui a approuvé l’application OAuth capable de le lire ? »

À 09:00, la direction financière confirme que l’outil est payé avec une carte de département, et non via le processus d’achats centralisé. À 10:30, la DSI découvre que l’utilisateur ayant créé le lien public a quitté l’entreprise trois mois auparavant. À midi, le service juridique demande s’il s’agit d’une violation de données à caractère personnel au sens du GDPR. À 14:00, le comité des risques demande si le sujet affecte l’hygiène cyber NIS2 et les risques liés aux tiers TIC au titre de DORA. À 16:00, l’auditeur interne demande les configurations de référence, les revues des accès administrateurs, la propriété du service cloud, les journaux et les due diligences fournisseurs.

La vérité est difficile à accepter : l’organisation n’a pas subi une indisponibilité SaaS classique ni une défaillance fournisseur. Elle a subi une défaillance de gouvernance.

Ce scénario n’a plus rien d’exceptionnel. Une équipe marketing connecte une plateforme d’IA à un CRM avec des autorisations OAuth étendues. Les RH achètent un outil d’analytique spécialisé en dehors du processus d’achats. Une équipe de support client active les exports publics de tickets par commodité. L’ingénierie intègre une extension de navigateur dans un flux de développement. Chaque décision peut sembler mineure, mais leur accumulation crée une surface de contrôle distribuée, remplie de données réglementées, de processus à privilèges et de dépendances opérationnelles.

La gestion de la posture de sécurité SaaS, ou SSPM, est la discipline qui transforme cette réalité SaaS dispersée en un contrôle gouverné, testé et auditable. Bien menée, elle fournit aux RSSI, aux responsables conformité, aux auditeurs et aux propriétaires métier une piste d’éléments probants unique pour ISO/IEC 27001:2022, l’hygiène cyber NIS2, les risques liés aux TIC de DORA et la responsabilité en matière de sécurité au titre du GDPR.

La position de Clarysec est directe : le SSPM ne doit pas être traité comme un tableau de bord supplémentaire. Il doit être intégré au SMSI, rattaché à la propriété du risque, cartographié avec les obligations légales, soutenu par des politiques et testé au moyen d’éléments probants récurrents.

C’est là que Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls et les modèles de politiques Clarysec deviennent opérationnels. Ils aident à convertir la prolifération SaaS en un modèle de contrôle compréhensible par un auditeur et supervisable par un organe de direction.

Pourquoi la gestion de la posture de sécurité SaaS est devenue un sujet de conformité

Le SaaS était autrefois considéré comme « un logiciel exploité par quelqu’un d’autre ». Cette lecture n’est plus défendable.

Dans le cadre de NIS2, de nombreux fournisseurs de cloud, de SaaS, d’infrastructure numérique, de services managés et de sécurité managée peuvent relever d’attentes réglementées en matière de cybersécurité selon le secteur, la taille, le rôle et la criticité. Plus important encore, les organisations qui s’appuient sur le SaaS doivent le gouverner dans le cadre de leurs propres mesures de gestion des risques. L’article 20 de NIS2 rend les organes de direction responsables de l’approbation des mesures de gestion des risques de cybersécurité, de la supervision de leur mise en œuvre et de la formation. L’article 21 exige des mesures techniques, opérationnelles et organisationnelles concrètes, notamment l’analyse des risques, les politiques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, l’acquisition et la maintenance sécurisées, les tests d’efficacité, l’hygiène cyber, la cryptographie, la sécurité RH, le contrôle d’accès, la gestion des actifs et l’authentification multifacteur lorsque cela est approprié.

DORA élève encore le niveau d’exigence pour les entités financières. Depuis le 17 janvier 2025, DORA s’applique à de nombreuses organisations du secteur financier comme régime de résilience opérationnelle numérique pour les entités entrant dans son champ. Il impose la gouvernance des TIC, l’identification et la classification des actifs TIC et des fonctions prises en charge, les contrôles de protection et de prévention, la gestion des incidents, la continuité, les tests et la gestion des risques liés aux prestataires tiers TIC. Les fournisseurs SaaS qui soutiennent des fonctions critiques ou importantes deviennent partie intégrante du périmètre des éléments probants DORA, tandis que l’entité financière réglementée demeure responsable.

GDPR ajoute une couche d’éléments probants relative à la vie privée. L’article 5 exige l’intégrité, la confidentialité et la responsabilité. L’article 32 exige une sécurité appropriée du traitement. En pratique, une organisation doit savoir quelles données à caractère personnel existent, où elles sont traitées, qui peut y accéder, quels fournisseurs les traitent et quelles mesures de protection les protègent. Une mauvaise configuration SaaS transforme ces questions en questions urgentes d’évaluation d’une violation.

ISO/IEC 27001:2022 constitue le pont. Les clauses 4.1 à 4.4 exigent que l’organisation définisse le contexte, les exigences des parties intéressées, le domaine d’application, les interfaces et les dépendances. La clause 5 exige le leadership, la politique, les rôles et les responsabilités. Les clauses 6.1.1 à 6.1.3 exigent l’appréciation des risques, le traitement des risques, la Déclaration d’applicabilité et les décisions relatives au risque résiduel. Les clauses 8.1, 8.2 et 8.3 exigent la planification opérationnelle, l’appréciation des risques et le traitement des risques. Les clauses 9 et 10 exigent la surveillance, l’audit interne, la revue de direction et l’amélioration.

Si vous ne pouvez pas répondre à la question de savoir quels outils SaaS traitent des données réglementées, qui en est propriétaire, comment ils sont configurés, qui dispose d’un accès administrateur, quelles intégrations sont actives et quels éléments probants démontrent que le contrôle fonctionne, votre posture de conformité est fragile.

Le modèle SSPM de Clarysec : inventaire, propriété, référentiel, éléments probants

Clarysec traite la gestion de la posture de sécurité SaaS comme une boucle de contrôle répétable, et non comme un projet ponctuel de remise en ordre.

1. Découvrir chaque service SaaS, y compris le shadow SaaS.
2. Attribuer un propriétaire métier et un propriétaire technique.
3. Classifier les données, les utilisateurs, les intégrations et la criticité opérationnelle.
4. Appliquer des configurations de référence sécurisées.
5. Examiner les utilisateurs, les administrateurs, les invités, les comptes de service et les périmètres OAuth.
6. Activer la journalisation, les alertes et la conservation.
7. Surveiller le partage public et l’exposition des données.
8. Relier les fournisseurs, les contrats, les accords de traitement des données et la planification de sortie.
9. Collecter les éléments probants selon une cadence définie.
10. Alimenter les constats dans le traitement des risques, la revue de direction et l’amélioration.

Ce modèle s’aligne étroitement sur les contrôles ISO/IEC 27002:2022 ISO/IEC 27002:2022, en particulier 5.9 inventaire des informations et autres actifs associés, 5.15 contrôle d’accès, 5.18 droits d’accès, 5.19 sécurité de l’information dans les relations avec les fournisseurs, 5.20 prise en compte de la sécurité de l’information dans les accords fournisseurs, 5.21 gestion de la sécurité de l’information dans la chaîne d’approvisionnement TIC, 5.23 sécurité de l’information pour l’utilisation des services cloud, 8.2 droits d’accès à privilèges, 8.3 restriction d’accès aux informations, 8.9 gestion des configurations, 8.15 journalisation, 8.16 activités de surveillance et 8.32 gestion des changements.

Le Zenith Blueprint, dans la phase Controls in Action, Step 23 consacrée aux contrôles organisationnels, indique :

Le cloud n’est plus une destination, c’est le mode par défaut. Du stockage à la collaboration, de l’infrastructure à l’apprentissage automatique, les organisations reposent de plus en plus sur des couches d’environnements tiers, abstraits et administrés à distance. Le contrôle 5.23 reconnaît cette réalité et exige que la sécurité de l’information soit explicitement prise en compte dans la sélection, l’utilisation et la gestion des services cloud, non pas comme une considération après coup, mais comme un principe de conception dès l’origine.

C’est le cœur du SSPM. Il ne s’agit pas seulement de détecter les mauvaises configurations après coup. Il s’agit d’intégrer la sélection, l’intégration, l’exploitation, la surveillance et la sortie des services SaaS au système de management.

La même section du Zenith Blueprint explique la réalité de la responsabilité partagée dans des termes que tout membre du conseil d’administration devrait entendre :

Les fournisseurs cloud sécurisent l’infrastructure, mais vous demeurez responsable de vos données, de vos configurations, de vos politiques d’accès et de votre préparation à la réponse aux incidents. Un compartiment de stockage mal configuré, un tableau de bord exposé publiquement ou des permissions excessives dans une configuration IAM cloud ne sont pas des défaillances du cloud. Ce sont des défaillances de gouvernance.

Votre fournisseur peut exploiter la plateforme, mais vous restez responsable de la configuration du tenant, des identités, des approbations d’accès, des données exposées, des intégrations, des processus de gestion des incidents et des éléments probants de conformité.

Le contrôle 5.23 est l’ancrage, mais le SSPM nécessite une famille de contrôles

Dans Zenith Controls, le contrôle ISO/IEC 27002:2022 5.23, sécurité de l’information pour l’utilisation des services cloud, est classé comme contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité. Son concept de cybersécurité est Protect, avec une capacité opérationnelle liée à la sécurité des relations fournisseurs et des domaines couvrant la gouvernance, l’écosystème et la protection.

C’est important, car le SSPM n’est pas un contrôle unique. C’est une discipline transverse à plusieurs contrôles.

Zenith Controls relie 5.23 aux relations fournisseurs au titre de 5.19, car les fournisseurs SaaS sont des fournisseurs critiques, mais 5.23 ajoute des préoccupations propres au SaaS, telles que la mutualisation, la transparence de la localisation des données et la responsabilité partagée. Il relie 5.23 au transfert d’informations, car les interfaces de programmation (API), les intégrations et les flux inter-SaaS déplacent constamment les données. Il relie 5.23 à l’inventaire des actifs, car les organisations doivent disposer d’une visibilité à jour sur les données stockées dans le cloud et les ressources SaaS. Il relie également la gouvernance cloud à la surveillance, à la restriction d’accès, à la gestion des configurations et à la supervision des fournisseurs.

Pour les droits d’accès, Zenith Controls cartographie 5.18 avec 5.15 contrôle d’accès, 5.16 gestion des identités, 5.3 séparation des tâches, 5.36 conformité aux politiques, règles et normes de sécurité de l’information et 8.2 droits d’accès à privilèges. Pour le SSPM, cela signifie que la revue d’accès n’est pas un simple exercice de tableur. C’est la preuve opérationnelle que le cycle de vie des identités, le moindre privilège, la séparation des tâches et la gouvernance des accès à privilèges fonctionnent dans les applications SaaS.

Socle de politiques : définir ce qui est conforme avant d’acheter des outils

De nombreuses défaillances SaaS commencent par un langage de politique trop vague. « Utiliser les outils approuvés de manière sécurisée » ne suffit pas. Les politiques Clarysec définissent des exigences précises en matière de registre, d’accès, de journalisation, de configuration et de revue des fournisseurs.

Pour les PME, la Politique d’utilisation du cloud - PME Politique d’utilisation du cloud - PME constitue un point de départ pratique. Dans la section « Exigences de gouvernance », la clause de politique 5.3 prévoit :

Un registre des services cloud doit être tenu par le prestataire informatique ou le DG. Il doit consigner : 5.3.1 Le nom et l’objet de chaque service cloud approuvé 5.3.2 La personne ou l’équipe responsable (propriétaire d’application) 5.3.3 Les types de données stockées ou traitées 5.3.4 Le pays ou la région où les données sont stockées 5.3.5 Les autorisations d’accès utilisateur et les comptes administratifs 5.3.6 Les détails contractuels, les dates de renouvellement et les contacts de support

Cette clause constitue le cœur opérationnel du SSPM. Elle fournit aux auditeurs le premier objet probant : un registre qui relie l’usage SaaS aux propriétaires, aux données, à la localisation, aux accès et aux contrats.

La même Politique d’utilisation du cloud - PME, dans la section « Exigences de mise en œuvre de la politique », clause de politique 6.2, définit les paramètres de référence :

Exigences de configuration de sécurité 6.2.1 Les éléments suivants doivent être activés sur toutes les plateformes cloud : 6.2.2 L’authentification multifacteur (MFA) pour les comptes administratifs et utilisateurs 6.2.3 Les paramètres de complexité des mots de passe (minimum 10 caractères, pas de réutilisation) 6.2.4 La journalisation d’activité pour les tentatives de connexion et l’accès aux données 6.2.5 Les restrictions d’accès (par exemple, listes d’autorisation d’adresses IP, lorsque cela est pris en charge) 6.2.6 L’accès administratif doit être limité à des personnes nommément désignées ou à des prestataires de support autorisés. 6.2.7 Les contenus partagés publiquement doivent être surveillés régulièrement afin de prévenir la fuite de données. 6.2.8 Lorsque les comptes utilisateurs ne sont plus requis, les accès doivent être révoqués immédiatement et toute donnée résiduelle doit être revue puis archivée ou supprimée.

Pour les environnements d’entreprise, la Politique d’utilisation du cloud Politique d’utilisation du cloud attribue une gouvernance centralisée plus forte. Dans la section « Exigences de gouvernance », la clause de politique 5.3 prévoit :

Chaque service cloud doit avoir un responsable de service désigné, responsable de la gestion du cycle de vie des actifs informationnels, de la gouvernance des usages, du suivi budgétaire et de la surveillance continue de la conformité.

Cette phrase ferme une lacune d’audit fréquente. Si personne n’est propriétaire d’un service SaaS, personne n’est responsable de la dérive de configuration, de la recertification des accès, de l’exposition des données, des décisions de renouvellement, du contact incident ou de la planification de sortie.

La gouvernance des privilèges doit également être explicite. La Politique de gestion des comptes utilisateurs et des privilèges - PME Politique de gestion des comptes utilisateurs et des privilèges - PME, dans la section « Exigences de mise en œuvre de la politique », clause de politique 6.4, indique :

Revues d’accès et journalisation 6.4.1 Une revue de tous les comptes utilisateurs et privilèges doit être effectuée tous les six mois. 6.4.2 Lors des revues, le responsable informatique doit valider si chaque compte demeure actif, nécessaire et doté des autorisations appropriées. 6.4.3 Les journaux de création de compte, de désactivation de compte et de changements de privilèges doivent être conservés de manière sécurisée pendant au moins 12 mois.

Pour le SaaS, chaque plateforme critique a besoin d’un cycle de revue d’accès défini, même si la plateforme est administrée par une équipe métier plutôt que par la DSI centrale.

La journalisation doit également être explicite. La Politique de journalisation et de surveillance - PME Politique de journalisation et de surveillance - PME, dans la section « Exigences de gouvernance », clause de politique 5.5, indique :

Services cloud et journalisation des tiers 5.5.1 Pour les plateformes dont la journalisation n’est pas sous le contrôle direct de l’informatique (par exemple, messagerie SaaS), les exigences suivantes s’appliquent : 5.5.1.1 La journalisation doit être activée et configurée lorsqu’elle est disponible 5.5.1.2 Les alertes doivent être routées vers le prestataire de support informatique 5.5.1.3 Les contrats doivent exiger des fournisseurs qu’ils conservent les journaux pendant au moins 12 mois et qu’ils en fournissent l’accès sur demande

Enfin, la gouvernance des fournisseurs SaaS doit être documentée. La Politique de sécurité des tiers et des fournisseurs - PME Politique de sécurité des tiers et des fournisseurs - PME, dans la section « Exigences de mise en œuvre de la politique », clause de politique 6.3, indique :

Surveillance continue de la sécurité des fournisseurs 6.3.1 Les fournisseurs critiques ou à haut risque doivent être revus au moins annuellement. La revue doit vérifier : 6.3.1.1 Le maintien de l’utilisation de méthodes d’accès sécurisées 6.3.1.2 La validité des certifications de sécurité ou la mise à jour des éléments probants de contrôle 6.3.1.3 L’historique des incidents ou les problèmes signalés 6.3.1.4 La conformité contractuelle avec les clauses de sécurité 6.3.2 Ces revues doivent être documentées et conservées avec le dossier du fournisseur. Les actions de suivi doivent faire l’objet d’un suivi clair. 6.3.3 Lorsque des fournisseurs gèrent l’infrastructure informatique ou des applications, la surveillance peut inclure : 6.3.3.1 La demande de journaux d’audit 6.3.3.2 La revue de l’activité des comptes 6.3.3.3 La confirmation qu’aucun accès non autorisé n’a eu lieu

Ensemble, ces politiques transforment le SSPM d’une ambition de sécurité en un modèle opérationnel opposable.

Un sprint SSPM de 30 jours pour produire des éléments probants

Un RSSI ou un responsable conformité pragmatique peut commencer par un sprint de 30 jours axé sur les éléments probants. Sélectionnez les cinq plateformes SaaS les plus importantes pour les données réglementées ou les opérations critiques. Les candidats habituels incluent Microsoft 365 ou Google Workspace, le CRM, la gestion des tickets, le SIRH, l’automatisation financière, le support client et l’analytique.

Semaine 1 : créer le registre SaaS

Utilisez les champs de la clause 5.3 de la Politique d’utilisation du cloud - PME comme registre minimal. Pour chaque service SaaS, consignez :

• Le nom du service et son objectif métier
• Le propriétaire d’application et le propriétaire technique
• Les types de données, y compris les données à caractère personnel et les catégories particulières de données le cas échéant
• Le pays ou la région de stockage des données
• Les groupes d’utilisateurs et les comptes administrateur
• Les applications OAuth et les intégrations de tiers
• Le propriétaire du contrat, la date de renouvellement et le contact de support
• La criticité pour les opérations
• Les obligations applicables, telles que NIS2, DORA, GDPR ou les contrats clients

Cela soutient les clauses 4.2 et 4.3 d’ISO/IEC 27001:2022, car les dépendances réglementaires, contractuelles et liées aux tiers doivent structurer le domaine d’application du SMSI. Cela soutient également l’identification et la classification, au sens de l’article 8 de DORA, des fonctions métier soutenues par les TIC, des actifs informationnels, des actifs TIC et des dépendances.

Semaine 2 : définir les configurations de référence sécurisées

Pour chaque plateforme SaaS sélectionnée, définissez 10 à 15 contrôles de référence.

• MFA imposée pour tous les utilisateurs, avec MFA résistante au phishing pour les administrateurs lorsque cela est possible
• Partage externe désactivé par défaut ou limité aux domaines approuvés
• Liens publics désactivés ou limités dans le temps
• Comptes invités revus mensuellement
• Rôles administrateur attribués à des personnes nommément désignées
• Authentification héritée désactivée
• Workflow d’approbation des applications OAuth activé
• Périmètres OAuth à haut risque bloqués ou soumis à approbation sécurité
• Journalisation d’audit activée
• Autorisations d’export de données restreintes
• Paramètres de conservation alignés sur les exigences légales et métier
• Jetons d’interface de programmation (API) revus et soumis à rotation
• Alertes de sécurité routées vers l’informatique ou le SOC
• Paramètres de prévention des pertes de données (DLP) activés lorsque cela est pris en charge
• Comptes administrateur « break glass » documentés et surveillés

Le Zenith Blueprint, phase Controls in Action, Step 19, contrôle 8.9 gestion des configurations, explique pourquoi cela compte :

De nombreuses violations ne résultent pas de faiblesses logicielles ; elles proviennent de mauvais choix de configuration. Mots de passe par défaut non modifiés, services non sécurisés activés, ports inutiles ouverts ou systèmes exposés à Internet sans justification. Le contrôle 8.9 garantit que chaque système est construit selon une configuration de référence sécurisée et régulièrement revu afin de prévenir la dérive dans le temps.

Pour le SaaS, la dérive de configuration inclut un propriétaire métier qui active le partage public, un administrateur qui approuve un accès tiers étendu ou un fournisseur qui modifie les paramètres par défaut après une mise en production fonctionnelle.

Semaine 3 : revoir les accès et les intégrations

Exportez les utilisateurs, les groupes, les administrateurs et les applications connectées. Pour chaque compte administrateur, confirmez la personne nommément désignée, la justification métier, le statut MFA, la dernière connexion, le niveau de privilège, la couverture de secours, les préoccupations liées à la séparation des tâches et les éléments probants d’approbation.

Pour les applications OAuth et les intégrations, confirmez le propriétaire de l’application, les données consultées, les autorisations demandées, le statut de risque fournisseur, la dernière date d’utilisation, le besoin continu et si le consentement a été accordé par l’utilisateur ou approuvé par un administrateur.

Le Zenith Blueprint, phase Controls in Action, Step 19, contrôle 8.3 restriction d’accès aux informations, énonce le principe opérationnel :

L’accès à l’information doit être aussi ouvert que nécessaire, mais aussi restreint que possible.

Cela s’applique non seulement aux personnes, mais aussi aux applications, aux services et aux interfaces de programmation (API). Une intégration OAuth inactive peut conserver un accès longtemps après la disparition de l’employé ou du projet qui l’a créée.

Semaine 4 : produire des éléments probants prêts pour l’audit et traiter les risques

Pour chaque plateforme SaaS, conservez l’entrée de registre, la configuration de référence, les captures d’écran ou exports prouvant les paramètres clés, la validation de la revue d’accès, les éléments probants de revue administrateur, les éléments probants de revue OAuth, les éléments probants de journalisation et d’alertes, l’enregistrement de revue de sécurité fournisseur, les constats ouverts et les actions de traitement des risques.

Créez ensuite une synthèse de direction d’une page présentant les constats critiques, les propriétaires en retard, les lacunes de configuration à haut risque non résolues, les intégrations non approuvées, les lacunes de journalisation, les exceptions et les décisions requises. Cela soutient ISO/IEC 27001:2022 clause 9.1 surveillance, clause 9.2 audit interne et clause 9.3 revue de direction. Cela crée également un lien pratique avec la responsabilité des organes de direction prévue par l’article 20 de NIS2 et la supervision de l’organe de direction au titre de DORA.

Cartographie de conformité croisée : un seul dossier de preuves SSPM, plusieurs obligations

La valeur métier du SSPM ne se limite pas à une meilleure sécurité. Elle réside aussi dans la réduction des doublons de conformité.

L’article 21 de NIS2 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées. L’inventaire SaaS soutient la gestion des actifs. Les configurations de référence soutiennent l’hygiène cyber. La MFA et les revues d’accès soutiennent le contrôle d’accès. La journalisation soutient la gestion des incidents. La revue fournisseurs soutient la sécurité de la chaîne d’approvisionnement. La cadence des éléments probants soutient les politiques et procédures permettant d’évaluer l’efficacité.

DORA exige que les entités financières identifient et classifient les fonctions soutenues par les TIC, les actifs informationnels, les actifs TIC et les dépendances vis-à-vis de tiers. Il exige également des mesures de protection et de prévention, des contrôles d’accès, une authentification forte, le chiffrement, la continuité, les tests, la gestion des incidents et la gouvernance des risques liés aux prestataires tiers TIC. Un dossier d’éléments probants SSPM SaaS peut soutenir les registres DORA, la cartographie des dépendances, la supervision contractuelle, les droits d’audit et la planification de sortie.

GDPR exige des responsables du traitement qu’ils démontrent la conformité avec l’intégrité, la confidentialité et la responsabilité. Les registres SaaS identifient où les données à caractère personnel sont traitées. Les configurations de référence réduisent la divulgation non autorisée. Les revues d’accès soutiennent le moindre privilège. La journalisation soutient l’investigation des violations. Les enregistrements fournisseurs soutiennent la gouvernance des sous-traitants et la responsabilité.

NIST CSF 2.0 ajoute une couche utile de communication. Sa fonction GOVERN exige que les exigences de cybersécurité légales, réglementaires et contractuelles soient comprises et gérées. Ses résultats liés à la chaîne d’approvisionnement exigent des rôles fournisseurs, des contrats, des due diligences, une surveillance et des activités postérieures à la relation. Ses fonctions IDENTIFY, PROTECT, DETECT, RESPOND et RECOVER se cartographient naturellement avec l’inventaire SaaS, le contrôle d’accès, la protection des données, la journalisation, la réponse aux incidents et le rétablissement.

Les auditeurs orientés COBIT 2019 et ISACA abordent généralement le SSPM sous l’angle de la gouvernance, des objectifs de management, de la propriété du risque, du fonctionnement des contrôles et de l’assurance. Ils demanderont si les décisions SaaS sont alignées avec les objectifs de l’entreprise, si les réponses aux risques sont documentées, si les responsabilités sont attribuées et si les activités d’assurance prouvent que les contrôles fonctionnent.

Le regard de l’auditeur : comment les différents auditeurs testent la posture SaaS

Un programme SSPM robuste résiste à différents styles d’audit, car il produit les éléments probants au bon niveau.

Un auditeur ISO/IEC 27001:2022 commencera par le périmètre, les parties intéressées, l’appréciation des risques, la Déclaration d’applicabilité et les éléments probants opérationnels. Si le contrôle 5.23 est inclus, il attendra des éléments probants relatifs à la sélection, à l’utilisation, à la gestion et à la sortie des services cloud. Si les contrôles relatifs aux droits d’accès sont inclus, il échantillonnera des utilisateurs et demandera si les arrivées, mobilités et départs sont reflétés dans les permissions SaaS.

Un évaluateur DORA se concentrera sur les fonctions critiques ou importantes, les dépendances vis-à-vis de prestataires tiers TIC, l’exhaustivité du registre, les contrats, la classification des incidents, les tests et la planification de sortie. Si une plateforme SaaS soutient les opérations de paiement, l’intégration client, le trading, l’analytique des risques ou les communications clients, le niveau d’exigence en matière de preuve augmente.

Un auditeur GDPR ou un réviseur protection des données demandera où les données à caractère personnel sont stockées, qui peut y accéder, quels exports et paramètres de partage existent, si les sous-traitants sont gouvernés, si les journaux soutiennent l’évaluation des violations et si les contrôles sont proportionnés au risque.

Risque fournisseur, responsabilité partagée et préparation aux incidents

Le SSPM commence souvent par la configuration, mais il ne peut pas s’y arrêter. Le SaaS est également un sujet de risque fournisseur et de préparation aux incidents.

DORA exige des entités financières qu’elles tiennent des registres des contrats de services TIC, distinguent les accords soutenant des fonctions critiques ou importantes, évaluent le risque de concentration, évaluent l’aptitude du prestataire et maintiennent des stratégies de sortie. Les contrats doivent traiter les descriptions de service, la localisation des données, la protection de la disponibilité, de l’authenticité, de l’intégrité et de la confidentialité, l’accès aux données, la récupération et la restitution, l’assistance en cas d’incident, la coopération avec les autorités, les droits de résiliation, les exigences de sécurité, les droits d’audit et l’accompagnement de transition.

L’article 21 de NIS2 inclut également la sécurité de la chaîne d’approvisionnement et exige des entités qu’elles prennent en compte les vulnérabilités propres aux fournisseurs directs et aux prestataires de services, la qualité des produits et les pratiques de cybersécurité des fournisseurs.

En pratique, une revue SaaS critique doit combiner les éléments probants issus des questionnaires de sécurité, la revue contractuelle, le statut de l’accord de traitement des données, l’historique des incidents, les engagements de niveau de service, l’accès aux journaux, les rapports d’audit, les éléments probants de configuration et la faisabilité de sortie.

La lacune de responsabilité partagée apparaît lorsque les équipes supposent que la certification du fournisseur couvre la configuration du tenant. Ce n’est pas le cas. Un fournisseur peut exploiter une plateforme sécurisée pendant que le client active le partage public, laisse actifs des comptes administrateur dormants ou accorde des périmètres API excessifs. Le SSPM ferme cette lacune.

La préparation aux incidents est tout aussi importante. La notification des incidents significatifs NIS2 inclut une alerte précoce sous 24 heures, une notification sous 72 heures et un rapport final au plus tard un mois après la notification de 72 heures. DORA exige une gestion des incidents liés aux TIC comprenant la détection, l’enregistrement, la classification, l’escalade, la communication et la notification. L’évaluation d’une violation de données à caractère personnel au titre du GDPR dépend également de la compréhension rapide de ce qui s’est produit, des données affectées et des personnes concernées.

Si une application OAuth suspecte a accédé à des fichiers clients, vous devez savoir quand l’application a été autorisée, quel utilisateur l’a autorisée, quels périmètres ont été accordés, quelles données ont été consultées, si des données ont été téléchargées ou partagées, quels utilisateurs ou clients ont été affectés, si l’accès reste actif et quelles actions de confinement ont été prises.

Sans journalisation ni conservation, l’organisation peut être contrainte de retenir des hypothèses de pire cas. Cela accroît l’exposition juridique, la pression de communication client et l’incertitude réglementaire. Lorsqu’un fournisseur SaaS facture en supplément les journaux d’audit, le propriétaire du risque doit accepter explicitement le risque résiduel ou approuver le niveau de licence requis. Cette décision doit figurer dans l’enregistrement de traitement des risques et dans la revue de direction.

Schémas courants de défaillance SSPM

Les mêmes schémas de défaillance apparaissent dans tous les secteurs.

Premièrement, le shadow SaaS est découvert via les factures, l’historique de navigation ou les journaux SSO plutôt que par le processus d’achats. La solution ne consiste pas seulement à bloquer les outils. Elle consiste à mettre en place un processus d’accueil léger que les équipes métier peuvent utiliser.

Deuxièmement, la propriété SaaS est floue. Le CRM est « détenu par les ventes », mais personne dans l’équipe commerciale ne peut expliquer les rôles administrateur, les jetons API, les exports de données ou les paramètres de conservation. Attribuez séparément des propriétaires d’applications et des propriétaires techniques.

Troisièmement, les revues d’accès sont trop génériques. Un réviseur valide « tous les utilisateurs approuvés » sans vérifier les rôles à haut risque, les utilisateurs inactifs, les invités, les collaborateurs externes ou les comptes de service. La revue d’accès SSPM doit être priorisée selon le risque.

Quatrièmement, les applications OAuth sont ignorées. De nombreuses organisations passent en revue les utilisateurs humains, mais pas les permissions d’application à application. Dans le SaaS moderne, les intégrations peuvent être plus puissantes que les utilisateurs.

Cinquièmement, les configurations de référence n’existent que sous forme de captures d’écran du projet de certification. Elles ne sont pas surveillées pour détecter la dérive. Alignez le SSPM avec la gestion des configurations afin que les contrôles de référence deviennent des éléments probants récurrents.

Sixièmement, la revue fournisseur et la revue de posture SaaS sont séparées. Les achats détiennent le contrat, l’informatique détient la console d’administration, l’équipe protection des données détient l’accord de traitement des données et la sécurité détient le registre des risques. L’auditeur voit des fragments. Le SSPM les réunit.

Reporting de direction : rendre le risque SaaS visible au conseil d’administration

NIS2 et DORA font tous deux de la gouvernance des TIC et de la cybersécurité un sujet de direction. ISO/IEC 27001:2022 exige également le leadership, les ressources, l’attribution des rôles, la surveillance et la revue de direction.

Un reporting de direction SSPM efficace doit répondre aux questions suivantes :

• Quels services SaaS critiques sont dans le périmètre ?
• Quels processus réglementés en dépendent ?
• Lesquels contiennent des données à caractère personnel ou des données métier sensibles ?
• Lesquels ont des revues d’accès en retard ?
• Lesquels présentent des lacunes de configuration à haut risque non résolues ?
• Lesquels comportent des applications ou intégrations OAuth non approuvées ?
• Quels fournisseurs ne disposent pas d’éléments probants de sécurité à jour ?
• Quelles lacunes de journalisation affectent la notification des incidents ?
• Quelles exceptions nécessitent une acceptation du risque ?
• Quels investissements ou quelles décisions sont nécessaires ?

Cela transforme le SSPM d’un projet technique de remise en ordre en un intrant de gouvernance. Cela rend également le RSSI plus efficace, car l’acceptation du risque est portée au bon niveau.

Transformer la posture SaaS en éléments probants prêts pour l’audit

Si votre organisation s’appuie sur le SaaS pour des données réglementées, des opérations financières, le support client, les RH, la collaboration, l’ingénierie ou l’analytique, le SSPM n’est plus optionnel. Il fait partie de l’hygiène cyber, de la gestion des risques liés aux TIC, de la responsabilité en matière de vie privée et de la préparation à l’audit.

Clarysec peut vous aider à passer de constats SaaS dispersés à un programme structuré et piloté par les éléments probants en utilisant :

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pour structurer la mise en œuvre autour de l’utilisation du cloud, de la restriction d’accès et de la gestion des configurations.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls pour cartographier les contrôles ISO/IEC 27002:2022 avec NIS2, DORA, GDPR, NIST CSF 2.0 et les attentes d’audit.
• Les modèles de politiques Clarysec, tels que la Politique d’utilisation du cloud Politique d’utilisation du cloud, la Politique d’utilisation du cloud - PME Politique d’utilisation du cloud - PME, la Politique de gestion des comptes utilisateurs et des privilèges - PME Politique de gestion des comptes utilisateurs et des privilèges - PME, la Politique de journalisation et de surveillance - PME Politique de journalisation et de surveillance - PME et la Politique de sécurité des tiers et des fournisseurs - PME Politique de sécurité des tiers et des fournisseurs - PME, afin de créer des règles opérationnelles opposables.

Commencez par vos cinq plateformes SaaS présentant le niveau de risque le plus élevé. Attribuez des propriétaires. Recensez les données, les accès, la configuration, les intégrations, les journaux et les éléments probants fournisseurs. Transformez les constats en actions de traitement des risques et en décisions de direction.

C’est ainsi que la gestion de la posture de sécurité SaaS devient plus qu’une catégorie d’outils. Elle devient une discipline de conformité défendable pour 2026.

Téléchargez les modèles de politiques Clarysec, utilisez Zenith Blueprint pour planifier votre sprint SSPM de 30 jours axé sur les éléments probants, et cartographiez vos contrôles SaaS avec Zenith Controls avant que votre prochain audit ne trouve les lacunes à votre place.