En resumen: lessons learned tras un incidente de TI significa que, tras el cierre técnico, todos los implicados se sientan juntos, reconstruyen el desarrollo, señalan sin culpar a nadie qué salió bien y qué no, y derivan de ello medidas con responsables y fechas. Esto vale también para casi incidentes, como una semana de PHP2Shell que terminó sin consecuencias graves. Lo decisivo no es el acta, sino el control posterior de si las medidas se aplicaron.
Por qué la semana posterior al incidente es tan importante
Cuando el servidor vuelve a funcionar y los parches están instalados, la tentación de volver rápido a la rutina es grande. Justo entonces se pierde el conocimiento más valioso: ¿quién notó qué y cuándo? ¿Dónde faltó una información? ¿Qué decisión tardó demasiado? Dentro de unas semanas nadie lo recordará con exactitud.
La semana de octubre de 2026 es un buen ejemplo. Muchas empresas parchearon servidores PHP, escribieron a sus proveedores de alojamiento, desconectaron sitios web de forma preventiva o aseguraron registros. Aunque no se detectara ninguna intrusión, hay en ello mucha materia de aprendizaje. ¿Cuánto tiempo pasó hasta saber qué sistemas estaban afectados? ¿Quién tenía que autorizar la desconexión y era localizable esa persona?
Los pasos técnicos tras un ataque propiamente dicho los trata la lista de comprobación tras un hackeo. Este artículo parte de ahí: ¿qué aprendemos de ello?
Lessons learned en un incidente de TI: reglas básicas para la reunión posterior
Una reunión posterior no es un tribunal. Quien teme que los errores tengan consecuencias personales cuenta solo la mitad de la historia. Por eso rige el principio: buscamos causas en procedimientos, herramientas e información, no culpables. Las personas actuaron con el conocimiento que tenían en ese momento.
Invite a todos los que participaron, también a externos como el proveedor de alojamiento, la agencia o proveedores de servicios, en la medida de lo posible. Reserve dos horas. Pida de antemano material: tickets, historiales de chat, correos, notas, extractos de registros. De ahí surge la cronología, la columna vertebral de la reunión. Cómo elaborarla correctamente lo describe Crear la cronología de un incidente.
La moderación no debería asumirla la persona que dirigió el incidente a nivel operativo. De lo contrario valoraría sus propias decisiones. Es neutral, por ejemplo, alguien de otro departamento o un socio externo.
El procedimiento en seis pasos
- Presentar la cronología: ¿qué ocurrió y cuándo, desde el primer aviso hasta el cierre? Marcar las lagunas de la cronología, no adivinar.
- ¿Qué salió bien? Empiece conscientemente por lo positivo. Muestra qué debe mantenerse y relaja a la ronda.
- ¿Dónde hubo fallos? Se recoge cada retraso, cada información que faltaba, cada incertidumbre, de entrada sin debatir soluciones.
- Aclarar las causas: para los puntos más importantes, pregunte varias veces por qué. «El parche llegó tarde» es un hallazgo; «nadie sabía que en el servidor antiguo todavía se ejecutaba PHP» es una causa.
- Fijar medidas: para cada causa, una medida concreta, una persona responsable y una fecha.
- Acordar el control posterior: una cita dentro de cuatro a ocho semanas para comprobar qué está aplicado.
Preguntas y medidas típicas tras una situación de PHP
La tabla siguiente muestra preguntas que suelen plantearse tras una situación como PHP2Shell, y posibles respuestas en forma de medidas. No todas encajan en cada empresa; sirve para afinar la mirada.
| Pregunta en la reunión posterior | Hallazgo típico | Medida posible |
|---|---|---|
| ¿Cómo nos enteramos de la vulnerabilidad? | Por casualidad, por las noticias | Suscribirse de forma dirigida a los avisos de seguridad de php.net y del BSI |
| ¿Sabíamos qué sistemas estaban afectados? | Lista incompleta, sistema antiguo olvidado | Inventario de todos los sitios web y servidores con la versión de PHP |
| ¿Quién podía decidir la desconexión? | Poco claro, decisión retrasada | Fijar la facultad de decisión en el plan de emergencia |
| ¿Confirmó el proveedor de alojamiento el parche? | Solo de palabra o en absoluto | Solicitar confirmación por escrito, completar el contrato |
| ¿Se reiniciaron todos los procesos de PHP? | No se comprobó | Incorporar el reinicio y el control como paso fijo |
| ¿Había registros disponibles desde el 20/10? | Parcialmente ya sobrescritos | Ampliar la duración de conservación, asegurar los registros de forma centralizada |
| ¿Cómo fue la comunicación interna y externa? | Los empleados se enteraron por la prensa | Preparar una información interna inicial |
Anote también lo que decide conscientemente no cambiar. A veces un hallazgo es conocido, pero la medida sería desproporcionada. Una decisión documentada es mejor que un olvido silencioso.
Separe en el acta los hechos probados, las suposiciones probables y las preguntas abiertas. Precisamente tras PHP2Shell, para el que no hay indicadores de compromiso publicados y confirmados, esta separación es importante.
Del acta al cambio
El fracaso más frecuente de los lessons learned es banal: se envía el acta y después no pasa nada. Tres hábitos ayudan. Primero, cada medida pertenece al sistema en el que de todos modos se trabaja, es decir, el sistema de tickets o la lista de tareas, no a un documento aparte. Segundo, el control posterior recibe una fecha fija en la agenda de la dirección. Tercero, los resultados se incorporan al plan de emergencia, a la lista de contactos y a los ejercicios.
Quien quiera comprobar las conclusiones sin esperar al próximo incidente real puede repasarlas en un ejercicio de emergencia sobre la mesa. Y donde la reunión posterior muestre que las actualizaciones dependían demasiado del azar, compensa reconvertirlas en una gestión de parches como proceso.
Para la protección de datos, el seguro y, en su caso, las autoridades, el informe final es además un documento importante. La valoración jurídica, por ejemplo si era necesaria una notificación según el art. 33 del RGPD, corresponde sin embargo al delegado de protección de datos o al abogado, no a la reunión técnica posterior.
¿Cómo ayuda PHP SOS en concreto?
- Elaboramos a partir de registros, tickets y notas una cronología del incidente y marcamos las lagunas.
- Moderamos la reunión posterior como instancia neutral y cuidamos de que se busquen causas en lugar de culpables.
- Traducimos los hallazgos técnicos en medidas con estimación de esfuerzo y prioridad.
- Acompañamos el control posterior y, si lo desea, aplicamos nosotros mismos las medidas técnicas, tal como está previsto en nuestra respuesta a incidentes.
Conclusión
Un incidente ya es bastante caro. Quien no lo evalúa vuelve a pagar la próxima vez. Una reunión posterior honesta y sin culpables, una cronología limpia y medidas con nombre y fecha convierten una semana difícil en una ganancia duradera de seguridad.
Preguntas frecuentes
¿Cuándo debe celebrarse la reunión de lessons learned?
Cuando el incidente está técnicamente cerrado, pero el recuerdo sigue fresco. En la práctica da buen resultado una cita aproximadamente una o dos semanas después del cierre. Antes suele faltar distancia; después, los detalles se difuminan.
¿Hay que hacer una reunión posterior también tras un casi incidente?
Merece la pena. Una situación como PHP2Shell, en la que al final no ocurrió nada, muestra igualmente dónde fallaron los procedimientos. Estas conclusiones son especialmente valiosas porque se obtuvieron sin daño.
¿Quién dirige la reunión posterior?
Lo mejor es alguien que no haya dirigido el incidente a nivel operativo. Así la moderación sigue siendo neutral y nadie tiene que defender sus propias decisiones. Puede ser también un proveedor de servicios externo.
¿Qué pasa con los resultados?
Cada conclusión se convierte en una medida con persona responsable y fecha. Se adaptan el plan de emergencia, la lista de contactos y la documentación. Pasadas unas semanas, alguien comprueba qué se ha aplicado realmente.