Un playbook de respuesta a incidentes es el procedimiento escrito que dice, paso a paso, qué se hace cuando ocurre un tipo concreto de incidente: quién actúa, en qué orden, con qué permisos, a quién se avisa y en qué momento. No es un documento de estrategia. Es una guía operativa que alguien tiene que poder abrir a las 3 de la mañana, con sueño y con presión, y ejecutar sin tener que decidir nada que ya estuviera decidido.
La diferencia entre una empresa que contiene un incidente en veinte minutos y otra que tarda dos días casi nunca está en la herramienta. Está en si alguien escribió esto antes.
Lo veo seguido en las primeras reuniones: la empresa tiene un EDR bien configurado, tiene alertas, tiene incluso monitoreo contratado. Y cuando pregunto qué pasa exactamente cuando esa alerta se enciende un sábado, la respuesta es una lista de nombres y un grupo de WhatsApp. Eso no es un playbook.
¿Qué contiene un playbook, exactamente?
Un playbook útil es corto y aburrido. Si ocupa cuarenta páginas, nadie lo va a leer durante un incidente. Estas son las partes que no pueden faltar:
- Disparador. Qué señal concreta activa este playbook. No “actividad sospechosa”, sino algo verificable: cifrado masivo de archivos en un servidor, un inicio de sesión válido desde un país donde no hay operación, un correo con adjunto que dos usuarios ya abrieron.
- Clasificación y severidad. Cómo se decide si esto es un incidente crítico o una molestia, con criterios escritos. Esta parte evita la discusión más costosa de todas, que es la de si hay que despertar a alguien o no.
- Roles. Quién dirige el incidente, quién ejecuta en los sistemas, quién habla con el negocio, quién documenta. Un solo responsable de la decisión por incidente, siempre.
- Pasos de contención. Las acciones técnicas en orden, con el detalle suficiente para ejecutarlas: qué se aísla, qué se deshabilita, qué credenciales se rotan y en qué secuencia.
- Autoridad previa. Qué está autorizado a hacer el analista sin pedir permiso, y qué necesita aprobación humana. Es la parte que más se olvida y la que más tiempo cuesta cuando falta.
- Evidencia. Qué se preserva antes de tocar nada, porque hay acciones que borran justo lo que después hace falta para entender qué pasó.
- Comunicación. A quién se avisa, en qué momento, por qué canal y con qué mensaje. Incluido el canal alterno, para el escenario en que el correo corporativo sea justamente lo comprometido.
- Cierre y aprendizaje. Qué condiciones tienen que cumplirse para declarar el incidente cerrado, y qué se revisa después.
El marco de referencia detrás de todo esto es la guía SP 800-61 revisión 3 del NIST, publicada en 2025, que reorganizó la respuesta a incidentes alrededor de las funciones del marco de ciberseguridad: identificar, proteger, detectar, responder y recuperar. Y si necesitas un punto de partida en lugar de una hoja en blanco, los playbooks públicos de CISA son gratuitos y perfectamente adaptables a una empresa privada.
¿Cómo se ve un playbook de verdad?
Con un ejemplo se entiende mejor que con una definición. Este es el arranque de un playbook de ransomware, resumido, tal como lo ejecutaría un analista de guardia:
Playbook de ransomware · severidad crítica
Disparador: más de 50 archivos modificados por minuto en un mismo servidor, o detección de proceso de cifrado por el EDR.
1. Aislar el equipo de la red desde la consola. Autorizado sin aprobación previa.
2. No apagar el equipo. La memoria contiene evidencia que se pierde al reiniciar.
3. Identificar la cuenta que ejecutó el proceso y deshabilitarla. Rotar sus credenciales.
4. Verificar si el respaldo más reciente está accesible desde esa cuenta. Si lo está, desconectarlo.
5. Buscar el mismo indicador en el resto del parque. El primer equipo casi nunca es el único.
6. Avisar al responsable de TI del cliente y al líder de incidente. Canal alterno si hay sospecha de compromiso del correo.
Requiere aprobación humana: apagar servicios de producción, pagar cualquier cosa, comunicar hacia fuera.
Fíjate en el paso 2. Es una sola línea y contradice el instinto de cualquiera que vea su servidor cifrándose. Sin esa línea escrita antes, el equipo apaga el servidor, se pierde la memoria y la investigación arranca a ciegas. Un playbook es, en buena medida, una colección de decisiones tomadas en frío para que nadie las tenga que tomar en caliente.
¿Qué playbooks se escriben primero?
Nadie tiene un playbook para cada escenario posible, y tampoco hace falta. Con cinco se cubre la enorme mayoría de lo que realmente ocurre en una empresa mediana:
| Playbook | Por qué este | La decisión que resuelve |
|---|---|---|
| Ransomware | El de mayor impacto y el que menos tolera improvisación | Aislar sin apagar, y quién puede detener producción |
| Cuenta comprometida | El más frecuente, casi siempre por phishing | Cerrar sesiones y rotar credenciales sin esperar al dueño de la cuenta |
| Correo malicioso masivo | Llega a decenas de buzones a la vez | Borrado del mensaje en todos los buzones y aviso al personal |
| Malware en endpoint | El pan de cada día del SOC | Cuándo basta con limpiar y cuándo se reinstala el equipo |
| Acceso indebido a datos | Es el que activa obligaciones legales | Cuándo se notifica y a quién, con los plazos en la mano |
El quinto merece un comentario aparte. En México, un acceso indebido a datos personales deja de ser solo un problema técnico y entra en el terreno de la obligación de notificar. Ese playbook se escribe con el área legal sentada en la mesa, no después.
¿En qué se diferencia de un plan de respuesta a incidentes?
Se usan como sinónimos y no lo son. El plan es el documento marco: define el comité, los niveles de severidad, las responsabilidades generales, cómo se declara una crisis. Es lo que pide un auditor. Suele tener firmas y vigencia anual.
El playbook es el nivel de abajo: un procedimiento por tipo de incidente, escrito para ejecutarse. Un plan sin playbooks es una declaración de intenciones. Los playbooks sin plan funcionan bastante bien en la práctica, aunque no pasen una auditoría.
Hay un tercer término que también se mezcla, el runbook, que en el mundo de la operación de infraestructura es el procedimiento para tareas rutinarias y programadas. La distinción práctica: el runbook se ejecuta porque toca, el playbook se ejecuta porque pasó algo.
¿Quién decide qué puede hacer el proveedor sin llamarte?
Esta es la pregunta que hay que resolver antes de firmar con cualquier servicio de monitoreo, y la que casi nunca se hace. Un SOC puede detectar en minutos y quedarse esperando autorización durante horas. La detección rápida con respuesta lenta produce el mismo daño que la detección lenta, con la diferencia de que queda registrada.
Por eso el playbook incluye una matriz de autoridad. Acciones que el analista ejecuta de inmediato, por escrito y aceptadas de antemano: aislar un equipo, deshabilitar una cuenta, bloquear un dominio, borrar un correo de todos los buzones. Acciones que siempre requieren un humano del lado del cliente: apagar sistemas de producción, notificar a clientes o autoridades, cualquier decisión con consecuencia comercial o legal.
Cuando un prospecto nos pregunta qué hacemos exactamente al detectar algo, la respuesta no es una lista de tecnologías. Es esto: el playbook acordado con él, con su matriz de autoridad, sus tiempos y sus contactos. Un proveedor que responde a esa pregunta con “lo notificamos de inmediato” está describiendo un servicio de alertas, no de respuesta.
¿Por qué un playbook que nadie ensaya no cuenta?
Un playbook sin ensayar es una hipótesis. Se descubre cuando se prueba, y lo que aparece siempre son las mismas cosas: el teléfono del responsable ya no es ese, la persona que aparece en el paso 4 cambió de puesto en marzo, nadie tiene claro quién autoriza detener la facturación, el respaldo que se iba a usar tiene ocho meses.
El ejercicio no necesita ser costoso. Se juntan las personas involucradas durante noventa minutos, se lee un escenario en voz alta y cada uno dice qué haría y con qué acceso. Se llama ejercicio de mesa y suele dejar más hallazgos que una auditoría entera. Dos al año, uno de ransomware y uno de cuenta comprometida, ya marcan una diferencia enorme.
Después de cada incidente real, el playbook se actualiza. Ese es el momento en que más se aprende y el que más se desperdicia, porque cuando todo volvió a la normalidad nadie quiere volver a hablar del tema.
¿Se pueden automatizar?
En parte, y ahí es donde entra SOAR. Los pasos mecánicos y sin criterio se automatizan bien: enriquecer una alerta con inteligencia de amenazas, abrir el ticket, consultar si el indicador aparece en otros equipos, aislar el endpoint. Eso recorta minutos donde los minutos importan y baja el tiempo medio de respuesta.
Lo que no se automatiza es el criterio. Decidir si este servidor se puede apagar en plena operación, si el impacto justifica activar el comité de crisis, si lo que estamos viendo es un ataque real o el consultor externo trabajando un domingo. Un playbook bien escrito distingue con claridad las dos cosas: lo que ejecuta la máquina y lo que decide una persona.
Preguntas frecuentes
¿Cuántas páginas debe tener un playbook?
¿Quién escribe los playbooks, el proveedor o la empresa?
¿Un playbook sirve para cumplir con ISO 27001?
¿Cada cuánto se revisan?
¿Qué pasa si tenemos alertas pero ningún playbook?
Lo que se escribe antes es lo que se ejecuta después
Ningún incidente sale exactamente como dice el papel. Eso no es un argumento contra el papel: en el momento en que suena la alerta, lo único que se ejecuta bien es lo que ya estaba decidido.
En ZetTateK los playbooks son parte del servicio de SOC 24/7 gestionado, y se acuerdan con el cliente antes de conectar el primer sensor, con su matriz de autoridad y sus tiempos comprometidos. Si quieres saber qué escenarios tendrías que cubrir primero en tu operación, el diagnóstico de seguridad sin costo es el camino más corto. Los términos técnicos de este artículo están explicados en nuestro glosario de ciberseguridad.
Un incidente no se responde con herramientas. Se responde con decisiones, y las buenas se toman antes.
