Incident Triage : Classification et Priorisation SOC 2026

La classification et la priorisation des incidents de sécurité sont les fondations sur lesquelles repose l'efficacité de la réponse. Un SOC qui ne dispose pas d'une taxonomie claire et de critères de priorisation objectifs traite chaque incident de manière ad hoc, avec des résultats inconsistants et une allocation inefficiente des ressources. En 2026, la complexité des incidents de sécurité a augmenté avec la multiplication des vecteurs d'attaque (cloud, supply chain, IoT, IA), la diversification des motivations (ransomware, espionnage, hacktivisme, fraude) et le renforcement des obligations de notification imposées par NIS 2 et DORA. Une classification rapide et précise détermine la vitesse et la qualité de la réponse, l'allocation des bonnes compétences au bon niveau de complexité, le respect des délais de notification réglementaire et la qualité des métriques de performance du SOC. Ce guide vous fournit un framework complet de classification des incidents, des critères de priorisation objectifs et des workflows de triage structurés qui garantissent une réponse cohérente et proportionnée à chaque type d'incident, indépendamment de l'analyste qui le traite. La standardisation du triage est le premier pas vers un SOC mature dont les processus sont reproductibles, mesurables et améliorables systématiquement au fil du temps.

Taxonomie des incidents de sécurité

Une taxonomie d'incidents standardisée fournit le vocabulaire commun nécessaire pour classifier, communiquer et analyser les incidents de manière cohérente. La taxonomie recommandée s'appuie sur celle de l'ENISA (European Union Agency for Cybersecurity) enrichie des spécificités opérationnelles d'un SOC. Les catégories principales incluent les intrusions (compromission de système, exploitation de vulnérabilité, accès non autorisé), les codes malveillants (malware, ransomware, spyware, cryptominer), les collectes d'information (scanning, phishing, ingénierie sociale), les atteintes à la disponibilité (DDoS, destruction de données, sabotage), les atteintes à la confidentialité (exfiltration de données, fuite d'information, accès non autorisé aux données) et les fraudes (usurpation d'identité, compromission de email business, fraude financière).

Chaque catégorie est subdivisée en sous-catégories qui précisent le type d'incident. Par exemple, la catégorie Intrusion se décline en : compromission de compte utilisateur, compromission de compte à privilèges, exploitation de vulnérabilité connue, exploitation de vulnérabilité zero-day, mouvement latéral et compromission de système. Cette granularité permet de déclencher automatiquement le bon workflow de réponse et d'assigner les bonnes compétences. La taxonomie doit être vivante et évolutive : revoyez-la trimestriellement pour ajouter les nouvelles catégories de menaces (attaques IA, compromission de LLM, abus de services cloud) et retirer les catégories obsolètes. La classification doit être effectuée dans les 15 premières minutes suivant la détection de l'incident et peut être révisée au fur et à mesure de l'investigation. Consultez les recommandations de l'ANSSI pour la taxonomie officielle française et le framework MITRE ATT&CK pour le mapping aux techniques d'attaque.

Comment définir les niveaux de sévérité ?

Les niveaux de sévérité doivent être définis selon des critères objectifs et mesurables, pas selon l'intuition de l'analyste. Un système à quatre niveaux est recommandé. La sévérité Critique (P1) s'applique quand l'incident affecte un système vital de l'organisation, qu'une exfiltration de données sensibles est confirmée ou probable, qu'un ransomware est actif et se propage, ou qu'un attaquant a obtenu des privilèges de domaine. Le SLA de réponse est de 15 minutes et l'escalade au management est immédiate. La sévérité Haute (P2) s'applique quand un système important est compromis sans impact immédiat sur les opérations, qu'un compte à privilèges est suspecté compromis, ou qu'un phishing ciblé a potentiellement réussi. Le SLA de réponse est de 30 minutes à 1 heure.

La sévérité Moyenne (P3) s'applique quand un malware est détecté et contenu sur un endpoint isolé, qu'une tentative d'intrusion est détectée mais non réussie, ou qu'un compte utilisateur standard est compromis sans mouvement latéral. Le SLA de réponse est de 4 heures. La sévérité Basse (P4) s'applique aux incidents mineurs sans impact opérationnel : scan de ports externe, phishing générique détecté et bloqué, violation de politique de sécurité sans conséquence. Le SLA de réponse est de 24 heures. Le calcul de la sévérité doit combiner deux dimensions : la criticité de l'actif impacté (un contrôleur de domaine est plus critique qu'un poste de travail standard) et la gravité de la menace (un ransomware actif est plus grave qu'un adware). Une matrice de sévérité croisant ces deux dimensions fournit une classification objective et reproductible. Pour les incidents impliquant des techniques AD avancées, consultez notre article sur les attaques Active Directory et pour les aspects forensiques, notre guide forensics Windows.

Pourquoi la cohérence du triage est-elle critique ?

La cohérence du triage signifie que deux analystes différents, confrontés au même incident, le classifient de la même manière et déclenchent le même workflow de réponse. L'absence de cohérence a des conséquences graves. Un incident critique classifié comme moyen par un analyste sera traité avec retard, potentiellement aggravant les dommages. Des statistiques incohérentes faussent les métriques de performance du SOC et empêchent l'identification des tendances réelles. Les obligations de notification réglementaire (NIS 2 impose une notification dans les 24 heures pour les incidents significatifs) peuvent être manquées si la classification est subjective. Pour garantir la cohérence, trois mécanismes sont essentiels. Le premier est la matrice de classification documentée avec des critères objectifs et des exemples concrets pour chaque niveau de sévérité. Le deuxième est la formation régulière des analystes avec des exercices de classification sur des scénarios réels ou simulés, suivis d'un debriefing collectif pour aligner les pratiques. Le troisième est la revue systématique des classifications par le SOC manager pour identifier et corriger les incohérences.

L'automatisation via le SOAR peut significativement améliorer la cohérence en appliquant automatiquement les critères de classification aux incidents entrants. Un playbook de pré-classification évalue automatiquement la criticité de l'actif impacté (via la CMDB), la nature de l'alerte déclencheuse, le contexte CTI (l'IOC est-il lié à une campagne connue ?) et les corrélations avec d'autres alertes récentes, pour proposer une classification initiale que l'analyste valide ou ajuste. Consultez notre article sur les techniques de phishing modernes pour des exemples de classification d'incidents de phishing, et notre guide sur le Zero Trust Microsoft 365 pour la classification des incidents cloud. Les recommandations de l'ANSSI fournissent un cadre de référence pour les niveaux de gravité.

Workflow d'escalade structuré

Le processus d'escalade définit comment et quand un incident remonte dans la chaîne de commandement. Un workflow d'escalade bien conçu distingue l'escalade technique (de L1 vers L2 ou L3 quand l'expertise requise dépasse le niveau de l'analyste actuel) et l'escalade hiérarchique (vers le SOC manager, le RSSI ou la direction quand l'impact business justifie une information ou une décision managériale). Les critères d'escalade technique doivent être explicites : escalader au L2 si l'investigation L1 ne permet pas de qualifier l'incident en 15 minutes, si l'incident implique plus de 3 systèmes, si une analyse forensique ou malware est nécessaire, ou si l'incident concerne un actif critique. Les critères d'escalade hiérarchique sont liés à l'impact : notifier le SOC manager pour tout incident P1 ou P2, le RSSI pour tout incident P1 ou tout incident impliquant une exfiltration de données personnelles, et la direction pour tout incident susceptible d'avoir un impact médiatique, financier ou réglementaire significatif.

Le processus d'escalade doit être testé régulièrement via des exercices de simulation (tabletop exercises) qui vérifient que chaque niveau de la chaîne est joignable, connaît son rôle et sait prendre les décisions appropriées. Un arbre d'escalade documenté et accessible (idéalement intégré au SOAR) avec les numéros de téléphone directs de chaque escalade est indispensable. La nuit et le weekend, le processus d'escalade doit être adapté avec un système d'astreinte clairement défini. Consultez notre article sur la réponse aux ransomwares pour un exemple de workflow d'escalade en situation de crise et notre comparatif DFIR pour les outils d'investigation à chaque niveau d'escalade.

Quelles sont les obligations de notification NIS 2 ?

La directive NIS 2 impose des obligations de notification strictes pour les incidents significatifs. Un incident est considéré comme significatif s'il cause ou peut causer une perturbation grave des services, s'il affecte un nombre important de personnes, ou s'il engendre des pertes matérielles ou immatérielles considérables. Les délais de notification sont les suivants : une alerte précoce dans les 24 heures suivant la détection de l'incident significatif, une notification d'incident dans les 72 heures avec une évaluation initiale de la sévérité et de l'impact, et un rapport final dans le mois suivant la notification incluant la description détaillée de l'incident, son impact, les mesures de remédiation prises et les leçons apprises. Ces obligations impactent directement les processus de classification du SOC : la sévérité assignée à un incident détermine si une notification est requise et dans quels délais. Une classification trop basse d'un incident significatif peut entraîner un manquement aux obligations de notification, avec des sanctions potentiellement lourdes. Intégrez les critères de notification NIS 2 dans votre matrice de classification et automatisez les alertes vers le RSSI et le DPO quand un incident déclenche une obligation de notification. Consultez le portail Elastic Security pour des tableaux de bord de suivi de conformité NIS 2.

Vos analystes SOC classifient-ils les incidents de la même manière quand ils sont confrontés au même scénario, ou la sévérité dépend-elle de qui est de garde ce jour-là ?

Perspectives et prochaines étapes

L'avenir de la classification des incidents sera marqué par l'IA qui assistera les analystes dans la classification initiale en analysant automatiquement les caractéristiques de l'incident et en proposant une catégorie et une sévérité avec un niveau de confiance. L'harmonisation européenne des taxonomies d'incidents, portée par l'ENISA et NIS 2, va progressivement standardiser les pratiques au niveau continental. Pour améliorer votre triage dès maintenant, documentez votre matrice de classification avec des exemples concrets, formez vos analystes avec des exercices de classification mensuels et mesurez le taux d'accord inter-analyste comme indicateur de qualité de votre processus.