Diagrama de clasificación de severidad de incidentes

¿Qué es diagrama de clasificación de severidad de incidentes?

La clasificación de severidad es el paso que convierte un aviso en un nivel. Alguien lee las evidencias, aplica un conjunto de pruebas acordado y aterriza en P1, P2, P3 o P4, y todo lo que viene después depende de esa respuesta. Conviene separarla de la prioridad desde el principio, porque las dos palabras se usan como sinónimos y luego se discuten en mitad del incidente. La severidad describe el impacto y, por tanto, la respuesta que debes: a quién se avisa, si se abre un puente de crisis, cada cuánto se informa a las partes interesadas. La prioridad describe el orden: qué coge el equipo a continuación. La severidad se evalúa a partir de evidencias y solo se mueve cuando las evidencias se mueven; la prioridad se puede recolocar cada mañana sin que nadie reabra la valoración del impacto.

Esta página es un árbol de decisión, no un mapa de procesos, y por eso existe aparte. Responde a una sola pregunta: qué nivel le corresponde a este incidente y quién está facultado para decidirlo, encadenando siete pruebas hasta que cada camino llega a un resultado con nombre. Se detiene a propósito en el momento en que el nivel queda fijado. Si lo que necesitas es el flujo completo a partir de ahí (cómo se diagnostica el ticket, cómo se escala, cómo se resuelve, cómo se confirma con la persona usuaria y cómo se cierra entre el service desk, el gestor de incidentes y los niveles de soporte), eso es la plantilla del proceso de gestión de incidencias. Usa este diagrama para decidir el nivel; usa aquel para ejecutar el trabajo.

Los carriles de aquí nombran derechos de decisión y no departamentos, que es justo la parte que casi todas las matrices de severidad dejan implícita. El service desk responde a lo que se observa en el aviso: si el servicio está caído o degradado y a cuántos usuarios o sedes afecta. El responsable del servicio responde a si hay una función crítica de negocio o una vía de ingresos realmente bloqueada. El gestor de incidentes es dueño de la prueba de la solución alternativa, de la declaración en sí y de la revisión. Legal y cumplimiento responden a dos preguntas y a ninguna más: si hay exposición de datos o de seguridad, y si hay un reloj normativo o contractual en marcha. Cuatro bandas bastan para zanjar la discusión sobre quién decide sin dibujar un organigrama.

Qué cubre este diagrama de flujo

En esta plantilla

• Cuatro carriles de derechos de decisión en lugar de un mapa de departamentos (Service desk, Responsable del servicio, Gestor de incidentes, y Legal y cumplimiento) repartidos en cinco fases de evaluación: Recepción, Alcance del impacto, Impacto en el negocio, Decisión de severidad, y Resultado y revisión
• La prueba inicial, «¿Servicio caído o degradado?», con tres salidas: «Caído» y «Degradado» siguen dentro del árbol, mientras que «Sin impacto» termina de inmediato en «Cerrado como petición de servicio», de modo que una petición o una consulta nunca recogen un nivel de severidad
• El alcance se evalúa antes que el impacto en el negocio: «¿Cuántos usuarios o sedes afectados?» se abre en «Varias sedes», que va directo a declarar un P1; «Un equipo», que pasa al responsable del servicio; y «Un solo usuario», al que aun así se le comprueba la exposición
• Dos vías independientes hacia lo crítico: «¿Función crítica o ingresos bloqueados?» alimenta «¿Solución alternativa viable?», donde «Sin alternativa» declara P1 y «Con alternativa» asigna P2; y «¿Exposición de datos o de seguridad?», donde «Exposición» declara P1 por pocos usuarios que haya
• La parte baja de la matriz decidida por una sola pregunta, «¿Reloj de SLA o normativo activo?», que separa «P3 medio, plazo controlado» de «P4 bajo, trabajo planificado» en vez de dejarlo al criterio de cada cual, con cinco finales distintos en total junto a «P1 crítico, puente activo», «P2 alto, corrección en curso» y la salida como petición de servicio, más una vía explícita de reclasificación donde «¿Cambió el impacto en la siguiente actualización?» devuelve «Aumentó» a la declaración de P1
• Criterios escritos en las decisiones que más pesan: qué significa caído, dónde están los umbrales de usuarios y sedes, qué cuenta como solución alternativa viable y por qué una exposición se trata como crítica sea cual sea el alcance

Cuándo usar esta plantilla

• Queréis poner por escrito las definiciones de severidad que ahora mismo se discuten, para que dos personas triando el mismo incidente a las tres de la madrugada lleguen al mismo nivel sin negociar
• Estáis configurando una herramienta de ITSM o de guardias donde la severidad es un campo obligatorio, y necesitáis las pruebas que hay detrás de cada nivel y no un desplegable con cuatro opciones sin explicación
• Queréis acordar los derechos de decisión antes de una caída y no durante ella: quién puede declarar un P1, quién confirma una exposición de datos o de seguridad y quién está autorizado a reclasificar
• Estáis revisando un incidente pasado para comprobar si el nivel asignado se correspondía con las evidencias disponibles en ese momento, que es una pregunta distinta de si la respuesta fue buena
• Incorporáis a personal de guardia y a agentes nuevos del service desk que necesitan una sola página con las preguntas, los umbrales y adónde lleva cada respuesta

Cómo funciona

1. Renombra los carriles con vuestros derechos de decisión reales

   Sustituye service desk, responsable del servicio, gestor de incidentes, y legal y cumplimiento por los roles que de verdad tienen cada decisión en vuestra organización. Si fuera de horario nadie es dueño de la pregunta de exposición de datos o de seguridad, eso es un hueco de guardia que cerrar antes de redibujar el carril.

2. Escribe vuestros umbrales de alcance en el diagrama

   Abre «¿Cuántos usuarios o sedes afectados?» y sustituye el comentario por vuestras propias definiciones de varias sedes, un equipo y un solo usuario: una región, un segmento de clientes, un porcentaje de usuarios activos, una lista de cuentas concretas. Los umbrales que no están escritos se renegocian en cada incidente.

3. Define caído frente a degradado para vuestros servicios

   Acordad qué significa «Caído» servicio por servicio, incluidos los casos de disponibilidad parcial: modo solo lectura, una región caída o una cola que sigue aceptando trabajo pero no lo procesa. La ambigüedad aquí desplaza el árbol entero un nivel.

4. Aplica la prueba de la solución alternativa con honestidad

   Decide qué hace viable una solución alternativa: que esté documentada, permitida, dentro de la capacidad disponible y que las personas afectadas puedan usarla hoy. Un procedimiento manual que exige formación, personal extra o una excepción de política no es una solución alternativa, y tratarlo como tal es la forma más habitual de que un P1 quede registrado como P2.

5. Asocia a cada resultado un compromiso de respuesta distinto

   Cada uno de «P1 crítico, puente activo», «P2 alto, corrección en curso», «P3 medio, plazo controlado» y «P4 bajo, trabajo planificado» debería llevar su propia regla de aviso, su cadencia de actualización y sus tiempos objetivo. Si dos niveles producen el mismo comportamiento, fúndelos en vez de mantener un nivel que nadie sabe distinguir.

6. Acordad quién puede reclasificar, y registrad el motivo

   La decisión «¿Cambió el impacto en la siguiente actualización?» es la única vía autorizada para cambiar un nivel. Nombra a quién puede tomarla, exige que se vuelvan a aplicar las pruebas en lugar de renegociar el nivel, y registra las nuevas evidencias y la hora para que la revisión posterior vea cuándo cambió la foto.

7. Pon el diagrama en circulación para su aprobación y guarda la versión

   Los criterios de severidad solo sirven si son los acordados. Compártelo con gestión de servicios, con los responsables de los servicios y con legal para que lo firmen, y conserva la versión aprobada, de modo que las definiciones que entrenáis sean las definiciones que publicáis.

Preguntas frecuentes

¿Qué diferencia hay entre severidad y prioridad de un incidente?

La severidad es una afirmación sobre el impacto: cuánto servicio está roto, para cuánta gente y qué bloquea. La prioridad es una afirmación sobre el orden: qué coge el equipo a continuación. ITIL en realidad no usa «severidad» como término formal; deriva la prioridad del impacto y la urgencia. Muchos equipos de ingeniería y de SRE usan severidad como atajo para la mitad del impacto, que es como la usa este diagrama. La regla práctica es que la severidad determina la respuesta que debes (avisos, puente, cadencia de actualización) y solo cambia cuando cambian las evidencias, mientras que la prioridad gobierna la cola y se puede recolocar cada día. Mantener un campo para cada cosa evita que se renegocie la valoración del impacto para conseguir un servicio más rápido.

¿En qué se diferencia esto de un diagrama del proceso de gestión de incidencias?

Responden a preguntas distintas sobre el mismo asunto. Este diagrama es un árbol de decisión: qué nivel de severidad le corresponde a este incidente y quién está facultado para decidirlo. Es una cadena de pruebas que termina en resultados con nombre, y se detiene en cuanto el nivel queda fijado. Un diagrama del proceso de gestión de incidencias es un mapa de procesos interfuncional: qué pasa después y quién lo hace, desde el registro hasta el diagnóstico, el escalado, la resolución y el cierre. La mayoría de los equipos necesitan los dos, y conectan exactamente en un punto: el paso en el que se asigna un nivel.

¿Cuántos niveles de severidad deberíamos tener?

Cuatro es el valor por defecto habitual y el que usa este diagrama, con algunas organizaciones añadiendo un P0 o SEV0 por encima para sucesos existenciales. El número importa menos que si cada nivel lleva asociada una respuesta distinta y escrita. Si P3 y P4 llevan a la misma regla de aviso, a los mismos tiempos objetivo y a la misma cadencia de actualización, tienes tres niveles y una etiqueta sin usar. Pocos niveles aplicados con coherencia ganan a muchos niveles aplicados a ojo, porque el valor de la clasificación es que todo el mundo aguas abajo pueda actuar sin preguntar.

¿Quién puede declarar un P1?

Nombra el rol por adelantado y mantén la lista corta. En este diagrama la declaración vive en el carril del gestor de incidentes y le llegan tres ramas distintas: una caída en varias sedes, una función crítica bloqueada sin solución alternativa viable, y una exposición confirmada de datos o de seguridad. Esa estructura es deliberada, porque a un P1 se debería poder llegar por evidencias desde más de una dirección, pero debería declararlo un rol que además pueda comprometer la respuesta. Cualquiera debería poder pedir un P1; un rol con nombre lo confirma.

¿Una exposición de datos o de seguridad convierte el incidente automáticamente en P1?

En este diagrama sí, y la rama de exposición se salta por completo la prueba del número de usuarios. La razón es que una exposición pone en marcha un reloj que corre desde que hay constancia y no desde que se resuelve, así que un incidente pequeño puede arrastrar una obligación grande. Con el RGPD de la UE y del Reino Unido, una violación de datos personales debe notificarse a la autoridad de control sin dilación indebida y, cuando sea posible, en un plazo de 72 horas desde que se tiene constancia, con la notificación a las personas afectadas como prueba aparte ligada al alto riesgo. Otros regímenes y contratos fijan sus propios plazos, y los avisos a clientes suelen ser más cortos que los legales, así que pon en la caja de decisión los que os apliquen. Muchas organizaciones además sacan las exposiciones de este árbol y las derivan a un proceso de respuesta ante incidentes de seguridad.

¿Cuándo debe cambiarse un nivel de severidad ya asignado?

Cuando cambian las evidencias, no cuando cambia la presión. Este diagrama le da una única vía: la decisión «¿Cambió el impacto en la siguiente actualización?», cuya rama «Aumentó» devuelve un P2 a la declaración de P1. Vuelve a aplicar las pruebas en lugar de reabrir la discusión, y registra qué evidencia nueva llegó y cuándo. Las bajadas de nivel siguen la misma regla y conviene tratarlas de forma explícita, porque un incidente que sigue en P1 después de que el impacto haya remitido enseña a la gente, en silencio, a ignorar el nivel.