Después de un ciberincidente, la organización debe realizar una revisión post-incidente estructurada y sin culpables. Su objetivo es identificar las causas raíz, evaluar la eficacia de la respuesta y definir acciones de mejora con responsable, plazo y método de verificación. Solo así el incidente se convierte en una mejora real de la seguridad.
La mayoría de las organizaciones dan por cerrado un incidente cuando los sistemas vuelven a funcionar. Si se celebra una reunión de lecciones aprendidas, suele producir un informe genérico al que nadie da seguimiento.
El resultado es predecible: las mismas causas raíz vuelven a provocar incidentes. Una política mal configurada, una detección que no existía o una vía de escalado poco clara siguen ahí, esperando al siguiente atacante.
La respuesta a un incidente no termina cuando se restauran los sistemas. Termina cuando se corrigen las causas que lo hicieron posible y se comprueba que las mejoras funcionan.
Una revisión post-incidente es un análisis estructurado, realizado tras la contención y la recuperación, que reconstruye lo ocurrido, identifica por qué fue posible y define las acciones necesarias para evitar que se repita o para reducir su impacto. Se basa en las evidencias recogidas durante la investigación, no en impresiones.
Son documentos relacionados, pero con fines distintos:
El análisis forense en ciberseguridad aporta las evidencias. La revisión post-incidente las convierte en decisiones.
Hay cinco causas habituales.
En abril de 2025, NIST publicó la revisión 3 de su guía de respuesta a incidentes, SP 800-61, alineada con el NIST Cybersecurity Framework (CSF) 2.0. El cambio más relevante para este tema es el papel de las lecciones aprendidas.
En la revisión anterior, la "actividad post-incidente" era la última fase de un ciclo cerrado. En la revisión 3, la mejora se sitúa en el centro del modelo, dentro de la categoría Mejora (Improvement) de la función Identificar. Las lecciones aprendidas de todas las funciones alimentan esa categoría y, una vez analizadas y priorizadas, informan a todas las demás.
En la práctica, esto significa dos cosas:
Este cambio de enfoque es coherente con la evolución de los modelos tradicionales de respuesta, que analizamos en el artículo sobre por qué el modelo PICERL ya no es suficiente.
A lo largo de los pasos se usa un escenario ilustrativo y anonimizado: un ataque de phishing AiTM que roba la sesión de un responsable financiero y termina en un intento de fraude del CEO (BEC) mediante una regla de reenvío oculta.
No todos los incidentes requieren una revisión completa. Defina de antemano los criterios de activación:
Celebre la revisión cuando el incidente esté contenido y las evidencias disponibles, idealmente en las dos semanas siguientes a la recuperación, mientras los detalles siguen frescos.
Deben participar quienes intervinieron en la detección, la respuesta y la recuperación:
El moderador no debe haber tenido un papel principal en la respuesta. Su función es mantener el foco en los hechos y en las causas, no en las personas.
Construya una cronología única a partir de las evidencias, no de la memoria de los participantes: registros de inicio de sesión, logs de auditoría, alertas, telemetría del EDR y comunicaciones.
En el escenario ilustrativo, la cronología mostraría cuatro momentos:
Distinga entre el síntoma ("un usuario hizo clic en un enlace") y las causas que permitieron el impacto. Técnicas como los "5 porqués" o los diagramas de causa y efecto ayudan a profundizar.
En el escenario ilustrativo, las causas raíz no serían el clic, sino estas cuatro:
Mida cuánto se tardó en detectar el incidente (MTTD) y en contenerlo y resolverlo (MTTR). Analice además los puntos de decisión:
Identifique tanto lo que funcionó como lo que no. Lo que funcionó también debe documentarse, para mantenerlo.
Cada causa raíz debe traducirse en al menos una acción concreta sobre personas, procesos o tecnología. Toda acción necesita un responsable con nombre, una fecha límite, una prioridad basada en el riesgo y un método de verificación definido de antemano.
Revise el estado de las acciones en las reuniones periódicas de seguridad hasta su cierre. Una acción no se cierra cuando se implementa, sino cuando se verifica.
Por ejemplo, puede verificarse simulando de nuevo la técnica, comprobando que la detección genera una alerta o midiendo la cobertura del control. Informe del progreso a la dirección como parte del gobierno de la ciberseguridad.
Los hallazgos forenses son útiles cuando se traducen en cambios concretos. En entornos Microsoft, muchos de esos cambios se materializan en nuevas detecciones en Defender XDR, ajustes del acceso condicional, controles de hardening de Microsoft 365 y acciones de Secure Score.
| Hallazgo DFIR | Categoría de mejora | Acción de ejemplo |
|---|---|---|
| El atacante reutilizó un token de sesión robado | Identidad | Aplicar protección de tokens y MFA resistente al phishing |
| La alerta no se generó | Detección | Crear una regla de detección personalizada en Defender XDR |
| El atacante creó una regla de reenvío externo | Correo | Bloquear el reenvío automático externo y alertar sobre nuevas reglas |
| Una aplicación OAuth obtuvo acceso al buzón | Aplicaciones | Restringir el consentimiento de usuario y revisar las aplicaciones existentes |
| La cuenta tenía privilegios permanentes | Acceso privilegiado | Activar PIM con acceso just-in-time |
| Los logs necesarios habían caducado | Registro y auditoría | Ampliar la retención y enviar los registros a Microsoft Sentinel |
| El escalado se retrasó por no estar claro quién decidía | Proceso | Actualizar el plan de respuesta con roles y umbrales de decisión |
| El pago se aprobó sin verificación adicional | Proceso de negocio | Exigir verificación por un segundo canal en cambios de cuentas bancarias |
| El usuario no reconoció el phishing | Personas | Formación específica y simulaciones de ataque dirigidas |
Muchos de estos cambios afectan también al plan de respuesta. Revisarlo con regularidad, por ejemplo con un checklist de respuesta a incidentes de ciberseguridad, ayuda a que las lecciones aprendidas no se queden en el informe.
Un informe post-incidente útil debería incluir, como mínimo, las siguientes secciones:
La revisión post-incidente también sostiene la documentación que exigen varias normas. Un análisis riguroso de causas raíz y de medidas correctivas facilita la elaboración de los informes finales.
| Normativa | Qué exige documentar | Ante quién | Estado |
|---|---|---|---|
| RGPD (art. 33.5) | Toda violación de datos personales: hechos, efectos y medidas correctivas | AEPD, que puede verificar esa documentación | En vigor |
| ENS (RD 311/2022) | Registro y gestión de incidentes, incluidas las lecciones aprendidas | CCN-CERT, en los casos de notificación | En vigor para el sector público y sus proveedores |
| NIS2 | Informe final con descripción del incidente, causa raíz y medidas de mitigación | CSIRT y autoridad competente | Ley española en tramitación a octubre de 2026 |
| DORA | Informe final de incidentes TIC graves, con análisis de causa raíz | Banco de España, CNMV o DGSFP | En vigor desde enero de 2025 |
Mientras la ley española de transposición de NIS2 (Ley de Coordinación y Gobernanza de la Ciberseguridad) siga en tramitación, se aplica el Real Decreto-ley 12/2018. Como los requisitos concretos dependen del sector y del tipo de incidente, conviene validar con asesoría jurídica qué documentación debe conservar y presentar su organización. Las evidencias digitales preservadas durante el incidente son la base de toda esa documentación.
Sin métricas, es imposible saber si la revisión post-incidente ha servido para algo. Las más útiles son:
La revisión post-incidente es el paso que determina si un incidente hace más fuerte a la organización o simplemente la deja esperando el siguiente. Una revisión sin culpables, basada en evidencias, con acciones concretas, responsables y verificación, convierte un coste inevitable en una mejora medible de la seguridad.
Para su organización, el impacto es directo:
ne Digital ayuda a las organizaciones a:
Ninguna organización elige sufrir un ciberincidente, pero sí puede elegir qué hace con él. Las empresas que salen más fuertes no son las que nunca han sido atacadas, sino las que se toman el tiempo de entender por qué ocurrió, aceptan lo que el incidente revela sobre sus controles y sus procesos, y convierten esa incomodidad en cambios concretos.
La próxima vez que su organización dé un incidente por cerrado, conviene hacerse una pregunta sencilla: si el mismo atacante volviera mañana, ¿encontraría la misma puerta abierta?
Si quiere hacer un análisis detallado de su perímetro de seguridad, ¡contacte a los expertos de ne Digital!