Définir le périmètre du SMSI d’un SaaS
Le périmètre du SMSI doit décrire l’activité que vous souhaitez faire examiner et ses interfaces. Pour un SaaS, cela implique de relier le produit commercialisé aux équipes, à l’hébergement et aux opérations de support. Un périmètre étroit peut être pertinent, mais il ne doit pas servir à laisser croire que toute l’entreprise est couverte. Avant de rédiger la formule destinée au certificat, construisez une carte que le CTO et la direction peuvent expliquer.
Cadre de référence : source primaire du sujet. Les recommandations opérationnelles ci-dessous sont à adapter à votre organisation.
Partir du service vendu
Décrivez la fonction du SaaS et les engagements associés. Identifiez les données, les utilisateurs et les opérations nécessaires à la fourniture du service. Distinguez les environnements de production, de test et de développement. Le nom commercial du produit ne suffit pas à définir la portée. Ajoutez les activités qui permettent de le maintenir : support, exploitation, gestion des changements et administration des accès. Un client doit pouvoir comprendre si le service qu’il achète correspond à la portée proposée.
Cartographier les équipes et les interfaces
Listez les équipes internes et les intervenants externes qui peuvent agir sur le service ou sur ses informations. Examinez les interfaces avec les fonctions partagées, comme les ressources humaines et les achats. Une équipe exclue du périmètre peut encore fournir un processus indispensable au SMSI. Décrivez cette dépendance au lieu de l’effacer de la carte. La localisation des personnes ne dit pas tout : un prestataire distant peut disposer d’un accès plus sensible qu’une équipe située au siège.
Décrire le cloud et les externalisations
Identifiez les services cloud effectivement utilisés, leurs régions et les opérations que vous gérez. Les documents du fournisseur peuvent soutenir certaines réponses, mais ils ne décrivent pas vos configurations. Associez chaque dépendance à un propriétaire et à une preuve disponible. Les traitements confiés à un sous-traitant restent des interfaces à examiner. Faites apparaître le support externalisé, les outils de déploiement et les fournisseurs d’identité quand ils participent au fonctionnement du service.
Justifier les limites
Pour chaque exclusion envisagée, expliquez l’activité concernée et les interfaces conservées avec le reste du périmètre. Une exclusion n’est pas une affirmation d’absence de risque. Testez votre formulation avec un scénario : un incident dans le système exclu peut-il toucher le SaaS couvert ? Si oui, la dépendance mérite un traitement explicite. Discutez la formulation finale avec l’intervenant compétent et le certificateur. Ne promettez pas un libellé de certificat avant cette discussion.
Maintenir la carte après les changements
Prévoyez les événements qui déclenchent une revue : lancement d’un produit, acquisition, changement d’hébergement ou externalisation du support. Conservez les versions et les décisions de modification. Le commercial doit utiliser la portée actuelle lorsqu’il répond aux questionnaires clients. Si un service nouveau n’est pas encore couvert, dites-le. Une carte technique mise à jour et une formule commerciale ancienne peuvent créer une contradiction ; organisez un circuit de validation commun entre sécurité, produit et vente.
Tester la portée avec le commercial
Faites lire la formulation du périmètre à la personne qui répond aux grands comptes. Demandez-lui de l’appliquer à une offre précise : produit, support et fonctions annexes. Si elle comprend que toute l’entreprise est couverte alors que le projet vise un service, reformulez avant l’évaluation. Vérifiez aussi les noms des entités et des produits utilisés dans les documents. Le test porte sur la compréhension, pas sur l’approbation du certificateur. Conservez les questions à confirmer avec celui-ci et les limites à rappeler aux clients.
Exemple de travail, fictif
Exemple fictif : un éditeur souhaite couvrir son produit principal, mais utilise une équipe support partagée avec un produit historique. La carte distingue les deux services et décrit les accès du support au produit couvert. L’équipe ne peut pas être ignorée au seul motif qu’elle travaille aussi sur le produit exclu. Le CTO précise les outils et les autorisations ; la direction valide la limite recherchée. Le libellé du certificat reste à confirmer avec le certificateur.
Ce que votre dossier doit permettre de vérifier
- Une description du service acheté et des engagements associés.
- Une carte des environnements, équipes et fonctions partagées.
- Les interfaces avec les fournisseurs et les activités exclues.
- Les raisons des limites, discutées avec la direction.
- Un circuit de revue et de mise à jour des formulations commerciales.
Questions avant de décider
Peut-on certifier un seul produit ?
Une portée ciblée peut être envisagée, mais ses activités et ses interfaces doivent être définies. Confirmez la formulation et sa recevabilité avec le certificateur plutôt que de la promettre au client.
Le cloud doit-il apparaître ?
Les services et dépendances utiles à l’activité couverte doivent être compris. Un document fournisseur ne remplace pas la description des configurations et responsabilités propres au SaaS.
Quand revoir le périmètre ?
Lorsqu’un changement de produit, d’équipe, de fournisseur ou d’organisation modifie l’activité couverte. Gardez une trace de la décision et vérifiez les documents commerciaux associés.
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.