Un SOC, centre opérationnel de sécurité, surveille des événements pour repérer des activités suspectes. Pour l’entreprise cliente, la valeur du service dépend surtout de ce qui se passe après la détection.
Définir un périmètre compréhensible
Quels systèmes sont surveillés ? Quelles plages horaires sont couvertes ? Qui traite une alerte lorsque le responsable IT est absent ? Ces réponses doivent être connues avant le premier incident. Les journaux contribuent à la détection et au traitement, comme le rappelle la CNIL, sans justifier une collecte illimitée.
Distinguer analyse et intervention
Identifier une connexion suspecte et désactiver un compte sont deux actions différentes. Le prestataire dispose-t-il du droit d’intervenir ? Dans quels cas doit-il attendre une validation ? Définissez les responsabilités et les canaux d’escalade avec les métiers concernés.
Tester un scénario contractuel
Exemple fictif : une alerte concerne le compte d’un dirigeant un dimanche. L’exercice consiste à vérifier les contacts, les informations transmises et la décision possible. Il ne nécessite pas d’attaque réelle.
Le regard Aztechnix
Demandez des indicateurs qui éclairent le fonctionnement : périmètre effectivement couvert, sources manquantes, qualité des escalades et actions correctives suivies. Un volume d’alertes élevé ne prouve pas une meilleure protection. Prévoyez aussi la sortie du contrat : restitution des informations utiles, retrait des accès et continuité de la surveillance. Ces points doivent être examinés avant le démarrage du service.
Source et méthode
CNIL — Tracer les opérations. Source consultée le 1er novembre 2026. Synthèse et recommandations pratiques : Aztechnix. Les mises en situation sont fictives ; elles ne constituent pas des références clients.