La alerta suena a las 3:14 de la mañana. Es real: hay actividad sospechosa en un servidor. Y entonces empieza lo que decide si esto será una anécdota o un desastre: ¿quién contesta?, ¿qué mira primero?, ¿aísla el equipo o eso rompe algo más grande?, ¿a quién despierta? Si esas respuestas se están inventando en ese momento, ya se perdió tiempo que no vuelve. Para eso existe el runbook.
Qué es (y por qué no es un lujo)
Un runbook de respuesta a incidentes es el guion de "qué hacemos cuando pasa X". No es teoría de seguridad: es el procedimiento concreto que convierte el pánico en pasos. Su valor no está en lo que dice cuando todo está tranquilo, sino en que a las 3 de la mañana nadie tenga que pensar desde cero.
Anatomía de un runbook que funciona
- Disparador: qué alerta o condición lo activa. Aquí es donde un SIEM bien afinado paga: el runbook arranca de una señal que significa algo.
- Triage: cómo se confirma que es real y se clasifica su severidad. Muchos incidentes mueren aquí, y está bien.
- Roles y contactos: quién hace qué, quién decide, a quién se llama —con datos que funcionen aunque el correo esté caído.
- Contención: los pasos para detener el sangrado sin causar un daño peor. Aislar, revocar, bloquear: en concreto, no "contener el incidente".
- Escalamiento: cuándo deja de ser un tema de guardia y sube, y por qué ruta.
- Comunicación: qué se dice, a quién y quién lo dice —al equipo, a dirección, a clientes si aplica.
- Post-mortem: qué aprendimos, sin cacería de brujas, para que el próximo sea más fácil.
Del disparador a la contención: un recorrido
Bajémoslo a un caso. 3:14 a.m.: el SIEM correlaciona tres señales en un mismo equipo —un inicio de sesión desde una IP desconocida, la creación de una cuenta local con privilegios y, acto seguido, un pico de cifrado de archivos—. El runbook arranca solo. Triage: ¿es real? La cadena, no un evento suelto, lo confirma en segundos. Contención: aislar ese equipo de la red (paso escrito, con el comando exacto), no apagarlo, porque apagarlo destruiría evidencia en memoria. Escalamiento: esto dejó de ser un tema de guardia; se despierta al responsable y, como huele a ransomware, se activa en paralelo la maquinaria de recuperación. Aquí el runbook de respuesta se conecta con algo más grande: contener el ataque, recuperar los sistemas y sostener la operación son tres planes distintos que trabajan a la vez. Sin el runbook, cada uno de esos pasos se habría debatido en un chat de crisis mientras el cifrado seguía avanzando.
Lo que un runbook no es
No es una camisa de fuerza ni pretende cubrir todos los escenarios imaginables. Su gracia es ordenar lo repetible para que el criterio humano se reserve a lo verdaderamente nuevo o ambiguo. Un buen runbook libera atención; no la sustituye.
Vivo o inservible
Como el plan de recuperación ante desastres, un runbook que se escribió una vez y se archivó envejece rápido y falla el día que se necesita. Se prueba con simulacros, se ajusta tras cada incidente real y se guarda donde se pueda alcanzar. Puedes medir qué tan preparado estás con nuestro assessment de madurez de monitoreo, y operar la respuesta —no solo la alerta— es el corazón de nuestro servicio de monitoreo continuo y respuesta a incidentes. Detectar es la mitad; saber qué hacer es la otra.
Preguntas frecuentes
help ¿Qué es un runbook de respuesta a incidentes?
Es un documento operativo que define, paso a paso, qué hacer cuando ocurre un tipo de incidente: quién participa, cómo se confirma, cómo se contiene, cuándo se escala y a quién, y cómo se comunica. Convierte la respuesta en un procedimiento repetible en lugar de una improvisación bajo presión.
help ¿Qué debe contener un runbook?
El disparador (qué alerta o condición lo activa), el triage inicial para confirmar y clasificar, los roles y contactos, los pasos concretos de contención, los criterios y rutas de escalamiento, el plan de comunicación y, al cierre, el post-mortem para aprender del incidente. Todo redactado para que lo ejecute alguien bajo estrés, no solo quien lo escribió.
help ¿Un runbook reemplaza al criterio humano?
No. Un runbook acelera y ordena las decisiones repetibles para que el equipo dedique su criterio a lo que de verdad es nuevo o ambiguo. No cubre todos los escenarios posibles ni pretende hacerlo; da estructura a los conocidos y libera atención para los que no lo son. Y solo sirve si se mantiene actualizado y se prueba.
Rubén Espinoza es fundador y Director Técnico de IT Experts de México. Trabaja en la industria de TI desde 1998: diseña y opera soluciones de infraestructura, ciberseguridad, continuidad, automatización y tecnología OT para entornos empresariales e industriales. Escribe desde proyectos reales y sistemas en producción.
Ver perfil y todos sus artículos →