Comment construire une procédure d'escalade avec un SOC ?

Pour construire une procédure d’escalade avec un SOC, on définit des niveaux de gravité, puis pour chacun : qui prévenir, par quel canal, dans quel délai, et quelles actions le SOC peut appliquer sans attendre. On y ajoute les contacts d’astreinte, une règle si personne ne répond, puis on teste le tout avant la mise en service.

Cet article fait partie de notre série sur la mise en œuvre d’un SOC managé. Pour la démarche complète, voir Comment mettre en place un SOC managé ?.

Étape 1 : définir les niveaux de gravité

Une procédure d’escalade commence par une échelle simple, partagée par le SOC, l’infogérant et le client. Trois ou quatre niveaux suffisent :

Niveau	Exemple	Réaction attendue
Information	Vulnérabilité à corriger, configuration à revoir	Rapport ou ticket, traitement planifié
Modéré	Logiciel suspect bloqué par l’EDR sur un poste	Ticket et vérification dans la journée
Élevé	Compte Microsoft 365 compromis, poste infecté	Appel de l’astreinte, confinement immédiat
Critique	Chiffrement en cours, plusieurs machines touchées	Appel immédiat, mobilisation du CERT

Les exemples doivent parler aux équipes de l’infogérant. Une échelle trop fine crée des débats au moment où il faut agir.

Étape 2 : fixer les actions autorisées

C’est le cœur de la procédure. Pour chaque niveau, on décide à l’avance :

• ce que le SOC fait seul : isoler un poste, désactiver un compte compromis, forcer une déconnexion ;
• ce qui demande l’accord de l’infogérant : bloquer un flux réseau, isoler un serveur ;
• ce qui demande l’accord du client : arrêter une application métier ou une ligne de production.

Plus la liste des actions autonomes est claire, plus le confinement est rapide la nuit et le week-end. La répartition générale des rôles est détaillée dans SOC managé et infogérant : qui fait quoi ?.

Étape 3 : établir la chaîne de contacts

Pour chaque client, la procédure liste les personnes à joindre, dans l’ordre :

1. l’astreinte de l’infogérant, avec un numéro qui sonne vraiment la nuit ;
2. un suppléant, si le premier ne répond pas dans le délai prévu ;
3. un décideur chez le client final, pour les actions lourdes ;
4. si besoin, la personne chargée des données personnelles chez le client (par exemple son délégué à la protection des données), quand une fuite de données est possible.

On précise le canal selon le niveau : le ticket ou l’e-mail suffisent pour une information, le téléphone s’impose pour un incident élevé ou critique. On fixe aussi un délai de réponse attendu et la règle par défaut si personne ne répond : contact suivant, puis action prévue à l’avance.

Étape 4 : prévoir la suite de l’escalade

Un incident critique ne s’arrête pas au confinement. La procédure dit qui décide de mobiliser une équipe de réponse à incident, qui informe la direction du client, et qui prépare les éventuelles notifications.

Ces notifications ont des délais courts. Pour les entités soumises à NIS2, l’article 23 de la directive prévoit, en cas d’incident important, une alerte précoce dans les 24 heures, une notification dans les 72 heures et un rapport final dans le mois. Pour une violation de données personnelles, l’article 33 du RGPD prévoit une notification à l’autorité de contrôle dans les 72 heures après en avoir pris connaissance. Le SOC fournit les faits ; ces textes font porter la notification sur l’entité concernée, et son conseil juridique peut préciser ce qui s’applique à elle. Voir Que se passe-t-il quand un SOC managé détecte une attaque ?.

Chez Cyna, le CERT, membre de l’InterCERT France, travaille avec les équipes du SOC et peut être mobilisé rapidement ; il prend le relais du SOC quand l’incident dépasse le confinement. L’astreinte réponse à incident de Cyna est joignable 24h/24 et 7j/7 depuis la page Déclarer un incident.

Étape 5 : tester et tenir à jour

Une procédure qui n’a jamais servi a souvent un défaut : un numéro erroné, un contact parti, une action autorisée que personne n’a validée. Avant la mise en service, on fait un exercice simple : le SOC simule une alerte élevée et vérifie que la chaîne de contacts répond dans le délai prévu.

Ensuite, la procédure se relit à chaque changement de contact, de prestataire ou de système critique, et au moins lors des revues périodiques avec le SOC. Les informations à réunir au démarrage sont listées dans Quelles informations fournir au SOC au démarrage ?.

Les erreurs les plus fréquentes

• Un seul contact, sans suppléant : l’incident tombe pendant ses congés.
• Aucune action autonome accordée au SOC : il détecte, mais attend une réponse pour isoler un poste.
• Des niveaux de gravité flous, interprétés différemment par chacun.
• Une procédure jamais testée, découverte le jour de l’incident.

Faire le point avec un expert

Vous voulez construire ou revoir la procédure d’escalade de vos clients ? Si vous travaillez avec un infogérant partenaire de Cyna, il est votre premier interlocuteur. Vous êtes infogérant, ou vous n’avez pas encore de partenaire ? Contactez-nous.

Questions fréquentes

Qui doit figurer dans la liste de contacts d'escalade ?

Au minimum un contact d'astreinte chez l'infogérant, un suppléant, et un décideur chez le client final capable d'autoriser une action lourde, comme l'arrêt d'un serveur de production.

Faut-il une procédure différente pour chaque client ?

La trame peut être commune à tous les clients de l'infogérant. Les contacts, les systèmes critiques et les actions autorisées, eux, sont propres à chaque client.

Que se passe-t-il si personne ne répond la nuit ?

La procédure doit le prévoir : contact suivant dans la liste, puis action par défaut décidée à l'avance. Sans cette règle, le SOC peut se retrouver bloqué au moment où il faut agir vite.

La procédure d'escalade sert-elle aussi pour les notifications réglementaires ?

Elle les prépare. Le SOC fournit la chronologie et les faits ; les textes (NIS2, RGPD) font porter la notification à l'autorité sur l'entité concernée. Voir La réponse à incident est-elle obligatoire ?.