IT Experts de México
Centro de Operaciones Consultoría y Soporte Hardware y Licenciamiento Cloud Operations Ciberseguridad Herramientas Blog Contáctanos
Ciberseguridad

Runbook de respuesta a incidentes: de la alerta a la contención

09/07/2026 3 min de lectura Rubén Espinoza

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.

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.

#runbook #respuesta a incidentes #soc #contencion #playbook

Preguntas frecuentes

¿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.

¿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ó.

¿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.

¿Necesitas ayuda con este tema?

El equipo de IT Experts puede evaluar tu infraestructura sin costo.

Hablar con un especialista

Más de Ciberseguridad

Cifrado en reposo y en tránsito: qué protege cada uno y contra qué no
Umbrales de monitoreo: ni alertar por todo ni callar lo importante
Control de acceso a datos: mínimo privilegio sin frenar el trabajo