Organigramme de classification de la gravité des incidents
Un organigramme de classification de la gravité des incidents : un arbre de décision prenant en compte les tests de disponibilité, de portée, d'impact commercial et d'exposition jusqu'à P1, P2, P3 ou P4.
Qu'est-ce que le processus organigramme de classification de la gravité des incidents ?
La classification de la gravité d'un incident est l'étape qui transforme un rapport en un niveau. Quelqu'un lit les preuves, applique un ensemble de tests convenus et atterrit sur P1, P2, P3 ou P4, et tout ce qui se trouve en aval découle de cette réponse. Il vaut la peine de séparer le mot priorité dès le départ, car les deux mots sont utilisés de manière interchangeable et ensuite débattus au milieu de l’incident. La gravité décrit l'impact et donc la réponse que vous devez : qui est bipé, si un pont s'ouvre, à quelle fréquence les parties prenantes sont mises à jour. La priorité décrit la commande : ce que l'équipe récupère ensuite. La gravité est évaluée à partir des preuves et ne bouge que lorsque les preuves bougent ; la priorité peut être réinitialisée chaque matin sans que personne ne rouvre l'analyse d'impact.
Cette page est un arbre de décision, pas une cartographie des processus, et c'est la raison pour laquelle elle existe séparément. Il répond à une question : quel niveau atteint cet incident et qui a le droit de décider, en enchaînant sept tests jusqu'à ce que chaque chemin atteigne un résultat nommé. Il s'arrête volontairement au moment où le niveau est fixé. Si vous avez besoin du flux de bout en bout après ce point, de la manière dont le ticket est diagnostiqué, remonté, résolu, confirmé avec l'utilisateur et fermé au niveau du service desk, du gestionnaire d'incidents et des niveaux de support, utilisez l'organigramme du processus de gestion des incidents sur /fr/templates/organigramme-du-processus-de-gestion-des-incidents. Utilisez ce tableau pour décider du niveau ; utilisez celui-là pour exécuter le travail.
Les couloirs nomment ici les droits de décision plutôt que les départements, ce qui est la partie que la plupart des matrices de gravité laissent implicite. Le service desk répond à ce qui peut être observé dans le rapport : le service est-il indisponible ou dégradé, et combien d'utilisateurs ou de sites sont concernés. Le propriétaire du service répond si une fonction commerciale critique ou un chemin de revenus est véritablement bloqué. Le gestionnaire d'incidents est propriétaire du test de solution de contournement, de la déclaration elle-même et de la revue. Les aspects juridiques et de conformité comportent deux questions et rien d'autre : existe-t-il une exposition aux données ou à la sécurité, et une horloge réglementaire ou contractuelle est-elle en marche. Quatre groupes suffisent pour trancher la question de savoir qui décide sans dessiner un organigramme.
Ce que couvre cet organigramme
Dans ce modèle
- Quatre voies de droits de décision plutôt qu'une carte de service (service desk, propriétaire de service, gestionnaire d'incidents, juridique et conformité) réparties en cinq étapes d'évaluation : admission, portée de l'impact, impact commercial, appel de gravité, résultat et examen.
- Le test d'ouverture, 'Service indisponible ou dégradé ?', avec trois réponses : 'Indisponible' et 'Dégradé' continue dans l'arborescence, tandis que 'Aucun impact' se termine immédiatement par 'Fermé comme demande de service', donc une requête ou une requête ne prend jamais de niveau de gravité.
- Périmètre évalué avant impact business : « Combien d'utilisateurs ou de sites concernés ? » se divise en « Sites multiples », qui va directement à une déclaration P1, « Une équipe », qui est transmise au propriétaire du service, et « Utilisateur unique », dont l'exposition est toujours vérifiée.
- Deux escalators indépendants vers critique : « Fonction critique ou revenus bloqués ? » alimentant « Solution de contournement viable disponible ? », où « Aucune solution de contournement » déclare P1 et « Solution de contournement » attribue P2 ; et « Données ou exposition de sécurité ? », où « Exposition » déclare P1, mais peu d'utilisateurs sont concernés.
- L'extrémité inférieure de la matrice est décidée par une question, « SLA ou horloge réglementaire engagée ? », séparant « P3 moyen, délai suivi » de « P4 bas, travail planifié » plutôt que de le laisser au jugement, donnant cinq points finaux distincts au total aux côtés de « P1 critique, pont en cours », « P2 élevé, correctif en cours » et la sortie fermée sur demande, plus un chemin de reclassification explicite où « Impact modifié lors de la prochaine mise à jour ? renvoie « l'impact a augmenté » dans la déclaration P1.
- Critères écrits sur les décisions cruciales : ce que signifie "indisponibilité", où se situent les seuils d'utilisateur et de site, ce qui compte comme une solution de contournement viable et pourquoi une exposition est traitée comme critique quelle que soit sa portée.
Quand utiliser ce modèle
- Écrivez les définitions de gravité sur lesquelles votre équipe se dispute actuellement, afin que deux personnes triant le même incident à trois heures du matin atteignent le même niveau sans négocier.
- Configuration d'un outil ITSM ou d'astreinte où la gravité est un champ obligatoire et où vous avez besoin des tests derrière chaque niveau plutôt que d'une liste déroulante avec quatre options et aucune guidance.
- Convenir des droits de décision avant une panne plutôt que pendant celle-ci : qui peut déclarer un P1, qui confirme une exposition de données ou de sécurité, et qui est autorisé à reclasser.
- Examiner un incident passé pour vérifier si le niveau attribué correspondait aux preuves disponibles à ce moment-là, ce qui est une question différente de celle de savoir si la réponse a été bonne.
- Intégration des ingénieurs de garde et des nouveaux agents du centre de services qui ont besoin d'une page montrant les questions, les seuils et où arrive chaque réponse.
Comment cela fonctionne
Renommez les voies selon vos véritables droits de décision
Remplacez le centre de services, le propriétaire du service, le gestionnaire des incidents, ainsi que les fonctions juridique et de conformité par les rôles qui détiennent réellement chaque appel dans votre organisation. Si personne ne possède les données ou les questions de sécurité en dehors des heures d'ouverture, il s'agit d'un écart de rotation à combler avant de redessiner la voie.
Écrivez vos seuils de portée sur le graphique
Ouvrez « Combien d'utilisateurs ou de sites sont concernés ? » et remplacez la note par vos propres définitions de plusieurs sites, d'une équipe et d'un seul utilisateur : une région, un niveau client, un pourcentage d'utilisateurs actifs, une liste de comptes nommés. Les seuils qui ne sont pas consignés sont renégociés à chaque incident.
Définir indisponible ou dégradé pour vos services
Convenez de ce que « Indisponible » signifie service par service, y compris les cas de disponibilité partielle tels que le mode lecture seule, une région en échec ou une file d'attente qui accepte toujours du travail mais ne le traite pas. L'ambiguïté déplace ici l'ensemble de l'arbre d'un niveau.
Définissez honnêtement le test de solution de contournement
Décidez de ce qui rend une solution de contournement viable : documentée, autorisée, dans les limites de ses capacités et utilisable par les utilisateurs concernés aujourd'hui. Une solution de secours manuelle qui nécessite une formation, du personnel supplémentaire ou une exception à la politique ne constitue pas une solution de contournement, et la traiter comme telle est la manière la plus courante d'enregistrer un P1 en tant que P2.
Attachez un engagement de réponse distinct à chaque résultat
Chacun des éléments « P1 critique, pont en cours », « P2 élevé, correctif en cours », « P3 moyen, délai suivi » et « P4 faible, travail planifié » doit comporter sa propre règle de pagination, sa propre cadence de mise à jour et ses heures cibles. Si deux niveaux produisent un comportement identique, fusionnez-les plutôt que de conserver un niveau que personne ne peut distinguer.
Convenez de qui peut reclasser et enregistrez la raison
Le message « Impact modifié lors de la prochaine mise à jour ? La décision est la seule voie sanctionnée pour changer de niveau. Nommez qui peut le passer, exigez que les tests soient réexécutés plutôt que le niveau renégocié, et enregistrez les nouvelles preuves et l'heure afin que l'examen post-incident puisse voir quand la situation a changé.
Faites circuler le tableau pour approbation et conservez la version
Les critères de gravité ne sont utiles que s’ils correspondent à ceux convenus. Partagez le graphique avec la direction du service, les propriétaires du service et le service juridique pour approbation, puis conservez la version approuvée afin que les définitions que vous exercez soient celles que vous publiez.
Questions fréquentes
Quelle est la différence entre la gravité de l'incident et la priorité de l'incident ?
La gravité est une déclaration sur l'impact : dans quelle mesure le service est interrompu, pour combien de personnes et ce que cela bloque. La priorité est une déclaration sur la commande : ce que l'équipe récupère ensuite. ITIL n'utilise pas réellement le terme « gravité » comme terme formel ; sa priorité découle de l’impact et de l’urgence. De nombreuses équipes d'ingénierie et SRE utilisent la gravité comme raccourci pour la moitié de l'impact, c'est ainsi que ce tableau l'utilise. La règle pratique est que la gravité détermine la réponse que vous devez (pagination, pont, cadence de mise à jour) et ne change que lorsque les preuves changent, tandis que la priorité détermine la file d'attente et peut être réinitialisée quotidiennement. Le fait de conserver un champ pour chacun empêche les gens de renégocier l’évaluation d’impact afin d’obtenir un service plus rapide.
En quoi est-ce différent d’un organigramme de processus de gestion des incidents ?
Ils répondent à différentes questions sur le même sujet. Ce graphique est un arbre de décision : quel niveau de gravité cet incident atteint-il et qui a le droit de décider. Il s’agit d’une chaîne de tests se terminant par des résultats nommés, et elle s’arrête dès que le niveau est fixé. Un organigramme du processus de gestion des incidents est une cartographie des processus interfonctionnels : ce qui se passe ensuite et qui le fait, de la journalisation au diagnostic, en passant par l'escalade, la résolution et la clôture. La plupart des équipes ont besoin des deux, et elles se connectent exactement en un seul point, l'étape où un niveau est attribué. La version du processus se trouve à /fr/templates/organigramme-du-processus-de-gestion-des-incidents.
Combien de niveaux de gravité devrions-nous avoir ?
Quatre est la valeur par défaut courante et celle utilisée par ce graphique, certaines organisations ajoutant un P0 ou SEV0 au-dessus pour les événements existentiels. Le nombre importe moins que le fait que chaque niveau comporte une réponse écrite distincte. Si P3 et P4 conduisent à la même règle de pagination, aux mêmes temps cibles et à la même cadence de mise à jour, vous disposez de trois niveaux et d'une étiquette inutilisée. Moins de niveaux appliqués systématiquement battent plus de niveaux appliqués de manière lâche, car la valeur de la classification est que tout le monde en aval peut agir en conséquence sans rien demander.
Qui est autorisé à déclarer un P1 ?
Nommez le rôle à l’avance et gardez la liste courte. Dans ce graphique, la déclaration se trouve dans la file du gestionnaire d'incidents et trois branches distinctes y alimentent : une panne multisite, une fonction critique bloquée sans solution de contournement viable et une exposition confirmée de données ou de sécurité. Cette structure est délibérée, car un P1 doit être accessible par des preuves provenant de plusieurs directions, mais déclarable par un rôle qui peut également engager la réponse. N’importe qui devrait pouvoir demander un P1 ; un rôle nommé le confirme.
Une exposition de données ou de sécurité fait-elle automatiquement d’un incident un P1 ?
Dans ce graphique, oui, et la branche d'exposition contourne entièrement le test du nombre d'utilisateurs. La raison en est qu’une exposition déclenche une horloge qui fonctionne en fonction de la conscience plutôt que de la résolution, de sorte qu’un petit incident peut entraîner une obligation importante. En vertu du RGPD du Royaume-Uni et de l'UE, une violation de données personnelles doit être notifiée à l'autorité de contrôle sans délai injustifié et, si possible, dans les 72 heures suivant la prise de conscience, avec notification aux personnes concernées par un test distinct lié au risque élevé. D'autres régimes et contrats fixent leurs propres fenêtres, et les délais de préavis des clients sont souvent plus courts que les délais légaux, alors définissez ceux qui s'appliquent à vous sur la boîte de décision. De nombreuses organisations acheminent également les expositions hors de cette arborescence vers un processus de réponse aux incidents de sécurité.
Quand un niveau de gravité doit-il être modifié une fois qu’il a été défini ?
Quand les preuves changent, pas quand la pression change. Ce graphique donne un seul itinéraire, le « Impact modifié lors de la prochaine mise à jour ? » décision, dont la branche « Impact a augmenté » renvoie un P2 dans la déclaration P1. Répétez les tests plutôt que de rouvrir la discussion, et enregistrez quelles nouvelles preuves sont arrivées et quand. Les déclassements suivent la même règle et méritent d'être traités explicitement, car un incident qui reste au niveau P1 après le retrait de l'impact entraîne tranquillement les gens à ignorer le niveau.
Où ce processus s'inscrit
Dans la plupart des opérations, ce processus suit Organigramme du processus de réponse aux incidents de phishing (e-mail signalé) et passe le relais à Organigramme du processus de réponse aux incidents de cybersécurité (SOC).
C'est une étape de Réponse aux incidents de sécurité.
Étape 1: Organigramme du processus de réponse aux incidents de phishing (e-mail signalé)
Modèle de diagramme de réponse aux incidents de phishing : rapport utilisateur, verdict de triage SOC, recherche de courrier à l'échelle du locataire, purge et blocage des indicateurs, réinitialisation des informations d'identification…
Étape 2: Organigramme de classification de la gravité des incidents Vous êtes ici
Un organigramme de classification de la gravité des incidents : un arbre de décision prenant en compte les tests de disponibilité, de portée, d'impact commercial et d'exposition jusqu'à P1, P2, P3 ou P4.
Étape 3: Organigramme du processus de réponse aux incidents de cybersécurité (SOC)
Organigramme à couloirs du cycle de vie de réponse aux incidents techniques de cybersécurité qu'un SOC ou un CSIRT exécute, du tri des alertes à l'éradication, en passant par la récupération et le réglage des règles.
Étape 4: Organigramme du processus de remontée des incidents de sécurité (SOC à RSSI)
Étape 5: Organigramme du processus de réponse aux incidents de sécurité
Étape 6: Organigramme du processus de réponse aux violations de données (horloge RGPD…