Plan de gestión de incidentes: cómo construir un plan práctico para ciberincidentes en las empresas
Un plan de gestión de incidentes describe cómo actúa la organización desde los primeros indicios de un incidente cibernético hasta que las operaciones se estabilizan, se aseguran las pruebas, se realizan las notificaciones necesarias y se implementan las lecciones aprendidas. El plan debe ser lo suficientemente conciso para utilizarse bajo presión, pero lo suficientemente detallado para eliminar dudas sobre roles, canales de contacto y decisiones.
¿Qué debe abarcar un plan de gestión de incidentes?
El plan debe aplicarse a aquellos eventos que puedan afectar la confidencialidad, integridad, disponibilidad o autenticidad de los sistemas y la información de la empresa. Ejemplos de ello son el ransomware, la usurpación de cuentas, las fugas de datos, los ataques de denegación de servicio, un proveedor comprometido, configuraciones incorrectas, sabotajes e interrupciones graves del servicio.
Defina un punto de entrada para las alertas, incluso cuando el evento sea incierto. El empleado no debe tener que determinar si algo constituye jurídicamente un «incidente» antes de que pueda ser reportado internamente.
Roles y mandato de decisión: defina antes del incidente
Los incidentes suelen empeorar cuando todos esperan por el mismo superior. Por ello, establezca los roles con antelación. Una organización pequeña puede combinar varias funciones, pero las responsabilidades deben quedar claras.
| Rol | Responsabilidad |
|---|---|
| Líder de incidentes | Coordina la visión general, prioridades, decisiones y ritmo de reunión. |
| Responsable técnico | Análisis, contención, registros, remediación y restauración. |
| Propietario de la actividad | Evalúa el impacto empresarial, servicios críticos y tiempos de inactividad aceptables. |
| Legal/protección de datos | Evalúa las obligaciones de notificación e información, así como los contratos. |
| Comunicación | Coordina la información interna y externa. |
| Dirección | Toma decisiones que exceden el mandato del equipo de incidentes. |
Documente también a los sustitutos, números de emergencia y cómo se reunirá el equipo de incidentes si los sistemas de comunicación habituales no funcionan.
Flujo de incidentes en ocho pasos
- Detectar y registrar. Cree un ID de incidente, registre la hora, el informante y la observación inicial.
- Triaje. Evalúe rápidamente qué sistemas, datos, usuarios y servicios podrían estar afectados.
- Clasificar y escalar. Establezca el nivel de gravedad preliminar y active los roles correspondientes.
- Contener. Limite el daño sin destruir innecesariamente pruebas ni dificultar la restauración.
- Analizar. Determine la causa probable, la línea de tiempo, el punto de entrada y el alcance.
- Remediar. Elimine la causa, cierre la vulnerabilidad y verifique que la amenaza haya desaparecido.
- Restaurar. Restablezca los servicios de forma controlada y refuerce la vigilancia.
- Post-análisis. Documente la causa raíz, las decisiones, las lecciones aprendidas y las medidas de mejora.
Cree un modelo de clasificación sencillo
La clasificación debe apoyar la toma de decisiones, no convertirse en un modelo académico de puntuación. Evalúe, por ejemplo:
- si una actividad crítica está inactiva,
- cuántos usuarios/clientes están afectados,
- si se han expuesto datos personales u otra información sensible,
- si el atacante tiene acceso privilegiado,
- si el incidente se está propagando,
- si hay proveedores u otras organizaciones afectadas,
- si podría ser necesaria una notificación regulatoria.
Determine qué nivel activa automáticamente a la dirección, al área legal, al responsable de protección de datos o a un socio externo de incidentes.
Preservar registros y pruebas sin detener la respuesta
Bajo presión de tiempo es fácil borrar o sobrescribir información importante. El plan debe indicar quién asegura los registros, instantáneas, líneas de tiempo, correos electrónicos, eventos de cuenta y otros documentos técnicos relevantes. Documente quién hizo qué y cuándo.
La necesidad de pruebas debe equilibrarse con el requisito de limitar el daño en curso. En incidentes graves, puede ser necesario activar expertos forenses externos desde el inicio.
Comunicación y notificación externa
Cree listas de contacto independientes para autoridades, proveedores de respuesta a incidentes, ciberseguros, proveedores de TI críticos, dirección y comunicación. Prepare plantillas para un primer informe de situación interno y para puntos de decisión clave.
Para las empresas sujetas a la ley de ciberseguridad, existen normas específicas sobre la notificación de incidentes significativos. La ley establece una primera notificación a más tardar 24 horas después de que el operador tenga conocimiento del incidente, seguida de la notificación del incidente según los plazos aplicables al tipo de actividad. Los detalles se tratan por separado en la guía sobre el flujo de 24/72 horas de NIS2.
La restauración es más que encender los sistemas
Defina criterios para determinar cuándo un servicio puede volver a abrirse. Compruebe que la vulnerabilidad se ha solucionado, que las cuentas privilegiadas se han asegurado, que los datos restaurados son fiables y que la monitorización se refuerza durante un periodo de tiempo.
Vincule el orden de restauración al BIA (Análisis de Impacto en el Negocio) y al plan de continuidad de la organización. Lea BIA paso a paso y qué debe contener un plan de continuidad.
Post-análisis: haga obligatorio el aprendizaje
Después del incidente, la organización debe documentar la causa raíz, qué funcionó, qué retrasó el trabajo y qué controles deben modificarse. Cada medida debe tener un responsable y una fecha límite. Luego, haga seguimiento para asegurar que realmente se haya ejecutado.
Pruebe el plan antes de que sea necesario
Un plan de incidentes que nunca se ha practicado casi siempre contiene números de teléfono incorrectos, mandatos poco claros o suposiciones sobre sistemas que ya no existen. Realice simulacros de mesa (table-top) periódicos donde la dirección, TI, operaciones y las funciones de apoyo pertinentes deban gestionar un escenario realista.
Varíe los escenarios: ransomware, proveedor de SaaS comprometido, cuenta de administrador filtrada o interrupciones prolongadas. Actualice el plan tras cada ejercicio.
Lista de verificación para el plan
- Un único canal de alerta interno claro
- Roles, sustitutos y mandatos
- Datos de contacto, incluso fuera del horario de oficina
- Niveles de gravedad y criterios de escalada
- Pasos para la contención, análisis y restauración
- Procedimientos para registros y pruebas
- Punto de decisión para NIS2 y otras notificaciones oficiales
- Punto de decisión para RGPD/incidente de datos personales
- Responsabilidad de comunicación interna y externa
- Vinculación con el BIA y el plan de continuidad
- Post-análisis con medidas de mejora asignadas
- Intervalos de ejercicio y actualización
¿Necesitan documentar el flujo de incidentes?
El Paquete de Plantillas NIS2 de Mallbutiken 2026 contiene plantillas integradas para, entre otros, gestión de incidentes, notificación, gestión de riesgos, continuidad y seguridad de proveedores. Precio en tienda: 199 SEK.
Ver el paquete de plantillas NIS2Orientación relacionada
Lea también Medidas de seguridad NIS2, notificación de incidentes 24/72 horas y plan de continuidad.
Fuentes y lecturas adicionales
Esta guía proporciona información general. El plan de incidentes debe adaptarse a los sistemas, actividades, contratos y requisitos de notificación aplicables de cada organización.
