# Guía para principiantes sobre el nivel de gravedad del incidente

**Escrito por:** Saket  
**Revisado por:** Siddharth  
Publicado originalmente en: 23 de enero, 2026

## Introducción

**Escenario 1**: Imagine una ajetreada mañana de lunes en Zylker. En la región de Asia-Pacífico, el sistema de CRM se desconecta repentinamente durante una ventana de ventas crucial. El equipo regional siente el impacto de inmediato, pero dado que APAC sólo contribuye con una pequeña fracción de las ventas globales de Zylker, la interrupción —aunque es inconveniente— no supone una amenaza inminente para la continuidad global del negocio de la empresa.

**Escenario 2**: Ahora, considere otro escenario que se desarrolla simultáneamente: El sistema de la plataforma global de protección de endpoints (ERP) de Zylker comienza a volverse lenta. No se trata de una interrupción completa, pero la ralentización se extiende a todos los departamentos a escala mundial, desde ventas y finanzas hasta logística y gestión de entregas, lo que retrasa los envíos, la facturación y los flujos de trabajo críticos para el negocio.

¿Cuál de estas situaciones se calificaría como un incidente SEV-1? Si ha elegido la segunda, la degradación de la ERP, está en lo cierto. La razón clave reside en el impacto. Un SEV-1 no se define por el hecho de que un sistema esté totalmente fuera de servicio, sino por lo mucho que perjudica a las operaciones críticas del negocio. Una interrupción localizada y completa podría ocupar un lugar inferior a una ralentización global si esta última detiene las operaciones críticas que soportan el rendimiento de la empresa.

Esta diferencia deja claro que las definiciones de la gravedad del incidente deben centrarse en la criticidad y el alcance del impacto. No deben depender de medidas subjetivas como los ingresos a corto plazo o las cifras de ventas de regiones específicas. En momentos de gran tensión, los equipos de TI pueden utilizar estos criterios basados en el impacto para resolver los incidentes con rapidez y evitar que el incidente afecte a otras operaciones y procesos de la empresa.

En esta guía, descubriremos cómo el equipo de TI de Zylker estructuró su marco de gravedad del incidente para clasificar las interrupciones complejas de forma eficiente. Desglosaremos qué significan los niveles de gravedad, cómo pueden clasificarse y qué principios deben seguir las organizaciones a la hora de adaptar las definiciones de gravedad para alinearlas con sus prioridades empresariales.

### Key takeaways

This guide will equip readers with the knowledge to:

- **Standardize triage:** Master the art of categorizing disruptions through a structured severity framework to ensure the right resources hit the right problems.
- **Prioritize with purpose:** Understand how to define severity levels that reflect actual business impact, moving beyond technical metrics to operational reality.
- **Align stakes with urgency:** Connect incident response strategies directly to business priorities, ensuring high-stakes issues receive immediate attention.
- **Build a scalable framework:** Adopt a methodology for creating severity categories that grow and evolve alongside your organization’s IT infrastructure.

## ¿Qué es el nivel de gravedad del incidente?

Los niveles de gravedad del incidente indican y cuantifican el impacto de un incidente de TI en el negocio, los usuarios y las operaciones, proporcionando un lenguaje claro y estándar que permite a los técnicos y a las partes interesadas comprender rápidamente la criticidad del incidente. Los niveles de gravedad del incidente sirven para determinar su nivel de prioridad, ayudando a los equipos de respuesta a incidentes (IRT) a clasificar y responder al incidente que más importa.

Como en el caso de Zylker, donde un problema de lentitud de la aplicación afectó a los ingresos de su empresa, es esencial definir claramente los niveles de gravedad. También es crucial que las definiciones se ajusten a la dinámica específica de su negocio y de su equipo, garantizando que los incidentes críticos reciban una atención inmediata.

Ahora que entendemos los niveles de gravedad del incidente, veamos cómo se definen estos niveles y veamos los ejemplos de Zylker para cada uno de los niveles de gravedad.

## Definición y clasificación de los niveles de gravedad del incidente

Antes de profundizar en los diferentes niveles de gravedad del incidente, conviene señalar que no todas las organizaciones utilizan los cinco niveles de gravedad. La aplicación de estos niveles puede variar en función de diferentes factores como la estructura del equipo, la industria, entre otras cosas. Mientras que algunas organizaciones pueden utilizar toda la escala, otras pueden limitarse a unos pocos niveles que funcionen mejor.

| Tipo de gravedad | Descripción | Ejemplo |
|---|---|---|
| SEV 1 | Un incidente SEV-1 significa una interrupción crítica de un sistema o servicio principal de la empresa, que tiene un grave impacto en las operaciones diarias de TI. | Una interrupción completa de la ERP principal o del sistema de CRM, un ataque de ransomware exitoso o una violación importante de la seguridad de los datos que comprometa datos sensibles de la empresa o de los clientes. |
| SEV 2 | Un incidente SEV-2 suele ser una interrupción importante de un servicio o sistema empresarial significativo, pero no es tan devastador como un incidente SEV-1. | Interrupción parcial de un servicio clave que afecta a un departamento importante, como el sistema de inventario o de pedidos, la interrupción del servicio de VPN o de acceso remoto para un gran grupo de empleados remotos, el servicio de Active Directory que experimenta fallos intermitentes en el inicio de sesión de muchos usuarios. |
| SEV 3 | Un incidente SEV-3 se define como aquel que tiene un efecto moderado en las operaciones de una organización. | Una única impresora de red compartida está desconectada en un departamento, un error común de la aplicación hace que los usuarios necesiten una solución alternativa para completar una función menor no esencial, el rendimiento interno de la Wi-Fi se degrada en una zona específica, pero se dispone de una conexión alámbrica. |
| SEV 4 | Un incidente SEV-4 representa un problema de baja prioridad que causa una interrupción mínima o nula de las operaciones normales del servicio. | Problemas de rendimiento con un dashboard de análisis interno o un entorno de desarrollo/pruebas que no está orientado al cliente, fallo de una actualización de firmware menor y no crítica en un pequeño lote de estaciones de trabajo, degradación del rendimiento en un servidor de respaldo que funciona correctamente, pero por debajo de la velocidad óptima. |
| SEV 5 | Un incidente SEV-5 son problemas puramente informativos, estéticos o administrativos que no afectan a la funcionalidad del sistema. | Un hiperenlace que no funciona en el portal interno de autoservicio, un error tipográfico en la firma automatizada del correo electrónico de la herramienta de la mesa de servicio, pequeños problemas estéticos en la interfaz de usuario de una aplicación no esencial. |

*Tabla 1: Nivel de gravedad del incidente en términos de impacto y urgencia*

### 1. SEV-1: Interrupción crítica con gran impacto en el negocio

**Definición:** Un incidente SEV-1 significa una interrupción crítica de un sistema o servicio principal de la empresa, que tiene un grave impacto en las operaciones diarias de TI. Puede causar posibles daños financieros y de reputación a la organización.

**Ejemplo de Zylker:** La ralentización total e inesperada del sistema de ERP de Zylker en las principales unidades de negocio se clasifica como un SEV-1. El incidente saboteó los equipos de ventas, marketing y soporte al cliente, impidiéndoles acceder a datos cruciales del cliente y procesar pedidos.

### 2. SEV-2: Un incidente importante con un impacto sustancial en el negocio

**Definición:** Una interrupción importante de un servicio o sistema empresarial significativo. Aunque no es tan devastador como un SEV-1, tiene un impacto significativo y podría afectar a varios equipos.

**Ejemplo de Zylker:** Una interrupción parcial del sistema que sólo afecta a una división, como que la aplicación de logística falle por completo o que se impida el acceso a la gestión de clientes potenciales.

### 3. SEV-3: Un incidente con impacto moderado

**Definición:** Tiene un efecto moderado en las operaciones; suele afectar a funcionalidades no críticas dentro de los sistemas centrales.

**Ejemplo de Zylker:** Fallos menores en la aplicación de CRM, como tiempos de carga lentos o imposibilidad de cargar archivos adjuntos de más de 5MB.

### 4. SEV-4: Un incidente menor con un impacto operativo muy bajo

**Definición:** Problema de baja prioridad que causa una interrupción mínima o nula de las operaciones normales.

**Ejemplo de Zylker:** En el portal interno de HRMS, la función "Exportar a PDF" no funciona para un subconjunto de usuarios, pero existen alternativas como CSV o DOCX.

### 5. SEV-5: Impacto mínimo o nulo

**Definición:** Problemas puramente informativos, estéticos o administrativos que no afectan a la funcionalidad.

**Ejemplo de Zylker:** Un pequeño error tipográfico en una sección menos utilizada de la base de conocimientos interna.

## ¿Cuál es la diferencia entre la gravedad, el impacto y la prioridad del incidente?

Aunque están estrechamente relacionados, la gravedad, el impacto y la prioridad son métricas distintas que orientan la urgencia y la rapidez de la resolución.

### Gravedad e impacto

El impacto define el alcance y las consecuencias de un problema. El nivel de gravedad del incidente (SEV-1 a SEV-5) es la clasificación formal que se da en función de ese impacto. Responde a la pregunta: "¿Qué tan malo es este incidente para la organización?"

### Prioridad y urgencia

La prioridad indica la rapidez con la que se debe resolver un incidente. Se calcula combinando la gravedad (impacto) con un factor de urgencia sensible al tiempo.

Por ejemplo, un error tipográfico en la página principal puede tener baja gravedad técnica (SEV-4 o SEV-5), pero alta prioridad debido a su impacto en la percepción de la marca.

## Por qué definir el nivel de gravedad del incidente es esencial para gestionar eficazmente los incidentes

Definir los niveles de gravedad es fundamental para establecer una comprensión uniforme de cómo los distintos tipos de incidentes afectan a las operaciones.

- **Permitir una planificación estructurada de la respuesta:** Activa manuales estratégicos predefinidos según la gravedad.
- **Ofrecer una asignación de recursos óptima:** Permite asignar conocimientos técnicos y herramientas según la criticidad.
- **Mejorar la comunicación y la alineación:** Optimiza las comunicaciones internas y externas durante interrupciones.
- **Ayudar en el análisis de tendencias y mejora continua:** Facilita revisiones posteriores, análisis de causa raíz y cumplimiento del SLA/SLO.

## Conclusión

El viaje de Zylker desde un caótico fallo de la CRM a un sistema de gestión de incidentes eficiente demuestra la importancia de establecer niveles claros de gravedad.

Los incidentes de TI son inevitables. Sin embargo, el caos que causan no tiene por qué serlo. Al comprender, definir y aplicar rigurosamente los niveles de gravedad del incidente, las organizaciones pueden pasar de una reacción improvisada a una resolución estratégica y proactiva.

Un enfoque claro comienza por definir el número de niveles necesarios, diferenciar entre interrupciones parciales y completas, y mantener la sencillez para evitar confusión dentro del equipo.

## Preguntas frecuentes

### 1. ¿Por qué su organización necesita niveles de gravedad del incidente?

Los niveles de gravedad ayudan a clasificar los tickets entrantes según su urgencia e impacto, permitiendo priorizar adecuadamente y minimizar el impacto en las operaciones.

### 2. ¿Cómo funciona una matriz de gravedad del incidente?

Se utiliza para clasificar un incidente comparando el impacto con la urgencia. El eje horizontal representa el impacto y el eje vertical la urgencia. El punto de intersección determina el nivel de gravedad final.

![incident severity matrix](https://cdn.manageengine.com/sites/meweb/images/service-desk/images/incident-severity-matrix.jpg)

*Matriz de gravedad del incidente*

### 3. ¿Cuál es la diferencia entre la respuesta a incidentes y la gestión de incidentes?

**Respuesta a incidentes:** Enfoque práctico que implica detectar, clasificar y resolver incidentes rápidamente.

**Gestión de incidentes:** Abarca todo el ciclo de vida del incidente, desde la creación del ticket hasta la documentación final en la base de conocimientos.