Que debe contener un IR playbook?

Un IR playbook completo tiene seis secciones: roles y responsabilidades (quien hace que), criterios de clasificacion (como determinar la severidad), procedimientos de contencion por tipo de incidente (ransomware, phishing, data breach), cadena de comunicacion (a quien informar y cuando), checklist de evidencia forense (que preservar), y procedimientos de recuperacion y lecciones aprendidas. Cada seccion debe ser concreta y accionable: un analista SOC en medio de un incidente no tiene tiempo de leer prosa.

Cual es la diferencia entre un playbook y un runbook?

Un playbook define la estrategia: que hacer, quien decide, cuando escalar. Un runbook detalla los pasos tecnicos exactos: que comando ejecutar, en que sistema, con que parametros. El playbook dice 'aislar el host comprometido'; el runbook dice 'en CrowdStrike Falcon, ir a Host Management, seleccionar el host, click en Contain Host'. Los equipos maduros tienen ambos: playbooks para la toma de decisiones y runbooks para la ejecucion tecnica.

Cada cuanto se debe actualizar un IR playbook?

Minimo cada 6 meses o despues de cada incidente significativo. Las lecciones aprendidas (post-mortem) de cada incidente real deben alimentar actualizaciones del playbook. Ademas, hay que actualizar cuando: se incorporan nuevas herramientas de seguridad, cambia la infraestructura critica, se identifican nuevas amenazas relevantes para el sector, o cambian los requisitos regulatorios (ENS, NIS2, DORA). Un playbook desactualizado es peor que no tener playbook, porque da falsa confianza.

Intermedioincident-responseplaybooksoccsirtplantilla

IR Playbook: Template Gratuito y Personalizable

Template de Incident Response Playbook gratuito y personalizable. Estructura completa de procedimientos de respuesta a incidentes, escalado, comunicacion, roles y checklist por tipo de incidente para equipos SOC y CSIRT.

MalwareIntel Research·9 de junio de 2026·11 min lectura

Serie: Handbooks y Guías Gratuitas — Parte 9

Por que necesitas un playbook

Cuando un incidente de seguridad ocurre a las 3 de la madrugada, la calidad de la respuesta depende de la preparacion previa. Un playbook bien estructurado transforma un momento de panico en un proceso ordenado.

Este articulo proporciona un template completo de IR Playbook que puedes adaptar a tu organizacion. Cada seccion es modular: usa las que necesites, modifica las que no encajen, anade las que falten.

Estructura del playbook

Seccion 1: informacion general

ORGANIZACION:    [Nombre de la empresa]
VERSION:         v1.0
FECHA:           [YYYY-MM-DD]
RESPONSABLE:     [CISO / Responsable de Seguridad]
CLASIFICACION:   Confidencial - Uso interno
REVISION:        Cada 6 meses o post-incidente

ALCANCE:
  Este playbook cubre la respuesta a incidentes de ciberseguridad
  que afecten a los sistemas de informacion de [organizacion].
  Aplica a todos los empleados, contratistas y terceros con acceso
  a los sistemas.

NORMATIVA APLICABLE:
  - ENS (Esquema Nacional de Seguridad)
  - NIS2 (directiva europea)
  - RGPD (proteccion de datos)
  - [Normativa sectorial especifica]

DOCUMENTOS RELACIONADOS:
  - Plan de Continuidad de Negocio
  - Politica de Seguridad de la Informacion
  - Registro de Activos Criticos
  - Contratos con proveedores de IR

Seccion 2: roles y responsabilidades

INCIDENT COMMANDER (IC):
  Quien: CISO o delegado designado
  Responsabilidades:
    - Declarar el nivel de severidad del incidente
    - Autorizar acciones de contencion que impacten produccion
    - Decidir la comunicacion externa (reguladores, clientes, prensa)
    - Convocar y disolver el equipo de respuesta
    - Aprobar el informe final post-incidente

ANALISTA DE RESPUESTA:
  Quien: Analista SOC N2/N3 de turno
  Responsabilidades:
    - Triaje inicial y clasificacion
    - Recopilar evidencia forense
    - Ejecutar acciones de contencion tecnica
    - Documentar timeline del incidente en tiempo real
    - Proponer acciones al IC

SOPORTE DE SISTEMAS:
  Quien: Administrador de sistemas / DevOps
  Responsabilidades:
    - Aislar sistemas afectados segun instrucciones
    - Proporcionar acceso a logs y backups
    - Ejecutar restauraciones autorizadas
    - Verificar integridad de sistemas post-recuperacion

COMUNICACION:
  Quien: Responsable de comunicacion / Legal
  Responsabilidades:
    - Redactar comunicaciones internas y externas
    - Coordinar con asesoria juridica (RGPD, notificacion a AEPD)
    - Gestionar comunicacion con clientes afectados
    - Documentar decisiones de comunicacion

CONTACTOS DE EMERGENCIA:
  IC principal:         [nombre] - [telefono] - [email]
  IC backup:            [nombre] - [telefono] - [email]
  Analista SOC turno:   [centralita SOC] - [email SOC]
  Administrador sys:    [nombre] - [telefono]
  Legal:                [nombre] - [telefono]
  Proveedor IR externo: [empresa] - [telefono 24x7] - [contrato num]
  CERT de referencia:   CCN-CERT / INCIBE-CERT - [telefono]

Seccion 3: clasificacion de incidentes

SEVERIDAD CRITICA (S1):
  Criterios:
    - Ransomware activo cifrando sistemas de produccion
    - Exfiltracion confirmada de datos regulados (PII, financieros)
    - Compromiso de cuentas privilegiadas (Domain Admin, root)
    - Sistemas criticos de negocio no disponibles
  Tiempo de respuesta: inmediato (15 minutos)
  Escalado: IC notificado en 15 min. Direccion en 1 hora
  Comunicacion: equipo completo convocado

SEVERIDAD ALTA (S2):
  Criterios:
    - Malware detectado en estaciones de trabajo (sin propagacion)
    - Acceso no autorizado detectado pero contenido
    - Phishing exitoso con credenciales comprometidas
    - Vulnerabilidad critica explotada en perimetro
  Tiempo de respuesta: 1 hora
  Escalado: IC notificado en 1 hora
  Comunicacion: analista + IC + soporte sistemas

SEVERIDAD MEDIA (S3):
  Criterios:
    - Escaneo de red o reconocimiento detectado
    - Phishing reportado (sin credenciales comprometidas)
    - Alerta de IDS/IPS sin confirmacion de compromiso
    - Politica de seguridad violada por usuario interno
  Tiempo de respuesta: 4 horas
  Escalado: analista gestiona, IC informado
  Comunicacion: analista + IC (si necesario)

SEVERIDAD BAJA (S4):
  Criterios:
    - Falso positivo confirmado tras investigacion
    - Actividad sospechosa sin impacto confirmado
    - Solicitud de informacion sobre seguridad
  Tiempo de respuesta: siguiente dia laborable
  Escalado: analista gestiona autonomamente
  Comunicacion: registro en sistema de tickets

Playbook por tipo de incidente

Ransomware

FASE 1: DETECCION Y TRIAJE (0-15 minutos)
  [ ] Confirmar la alerta: verificar que hay cifrado activo
  [ ] Identificar el ransomware (nota de rescate, extension de archivos)
  [ ] Determinar alcance inicial: cuantos sistemas afectados
  [ ] Declarar incidente S1
  [ ] Notificar al IC inmediatamente
  [ ] NO apagar los sistemas (puede perder evidencia en RAM)
  [ ] NO pagar el rescate sin decision del IC y legal

FASE 2: CONTENCION (15 min - 2 horas)
  [ ] Aislar sistemas afectados de la red (desconectar cable/WiFi)
  [ ] Si posible, aislar via EDR (contain host) sin apagar
  [ ] Bloquear IOCs conocidos en firewall/proxy (IPs C2, dominios)
  [ ] Deshabilitar cuentas comprometidas en AD
  [ ] Preservar evidencia: snapshot de VMs afectadas
  [ ] Capturar memoria RAM de al menos un sistema afectado
  [ ] Verificar que backups NO estan comprometidos (air-gapped)
  [ ] Evaluar si el cifrado sigue activo o se ha completado

FASE 3: ERRADICACION (2-48 horas)
  [ ] Identificar el vector de entrada inicial
  [ ] Buscar persistencia del atacante en sistemas no cifrados
  [ ] Verificar que no hay backdoors adicionales
  [ ] Limpiar/reimagear sistemas comprometidos
  [ ] Cambiar todas las contrasenas de cuentas privilegiadas
  [ ] Actualizar reglas de deteccion con IOCs del incidente

FASE 4: RECUPERACION (24-72 horas)
  [ ] Restaurar desde backups verificados (el mas reciente no comprometido)
  [ ] Restaurar en orden de criticidad de negocio
  [ ] Monitorizar intensivamente durante 72 horas post-restauracion
  [ ] Verificar integridad de datos restaurados
  [ ] Confirmar que servicios criticos funcionan correctamente

FASE 5: POST-INCIDENTE (1-2 semanas)
  [ ] Reunion de lecciones aprendidas (todos los involucrados)
  [ ] Informe final con timeline, impacto, coste y recomendaciones
  [ ] Actualizar playbook con lecciones aprendidas
  [ ] Notificar a AEPD si hay datos personales afectados (72h)
  [ ] Notificar al CCN-CERT si aplica (sector publico/critico)
  [ ] Evaluar mejoras de seguridad (segmentacion, backups, EDR)

Phishing con credenciales comprometidas

FASE 1: DETECCION Y TRIAJE (0-30 minutos)
  [ ] Confirmar que el usuario introdujo credenciales
  [ ] Identificar que credenciales se comprometieron (email, VPN, AD)
  [ ] Verificar si hay acceso no autorizado posterior
  [ ] Clasificar: S2 si hay acceso posterior, S3 si solo credenciales
  [ ] Bloquear el dominio de phishing en proxy/firewall

FASE 2: CONTENCION (30 min - 2 horas)
  [ ] Forzar cambio de contrasena de la cuenta comprometida
  [ ] Revocar sesiones activas y tokens OAuth
  [ ] Verificar si el usuario tiene MFA activado
  [ ] Buscar accesos desde IPs anomalas en los logs
  [ ] Verificar reglas de reenvio de email (los atacantes crean reglas)
  [ ] Escanear buzones enviados/eliminados por exfiltracion
  [ ] Si la cuenta tiene privilegios elevados: escalar a S1

FASE 3: INVESTIGACION (2-24 horas)
  [ ] Analizar el email de phishing: headers, URL, remitente
  [ ] Buscar si otros usuarios recibieron el mismo email
  [ ] Verificar si alguno mas introdujo credenciales
  [ ] Documentar IOCs: URL de phishing, IP del servidor, email remitente
  [ ] Reportar el dominio de phishing al registrador

FASE 4: RECUPERACION
  [ ] Confirmar que no hay acceso residual del atacante
  [ ] Activar MFA si no estaba activado
  [ ] Formar al usuario sobre como identificar phishing
  [ ] Actualizar filtros de email con los indicadores del ataque

Exfiltracion de datos

FASE 1: DETECCION Y TRIAJE (0-15 minutos)
  [ ] Confirmar la exfiltracion: tipo de datos, volumen, destino
  [ ] Clasificar datos afectados: PII, financieros, propiedad intelectual
  [ ] Declarar S1 si hay datos regulados (RGPD, ENS)
  [ ] Notificar al IC y a legal inmediatamente

FASE 2: CONTENCION (15 min - 2 horas)
  [ ] Bloquear las IPs/dominios de destino de la exfiltracion
  [ ] Aislar el sistema origen de la exfiltracion
  [ ] Preservar logs de DLP, proxy, firewall y endpoint
  [ ] Determinar si la exfiltracion fue automatizada o manual
  [ ] Identificar que cuentas se usaron para acceder a los datos

FASE 3: INVESTIGACION (2-48 horas)
  [ ] Cuantificar exactamente que datos se exfiltraron
  [ ] Determinar el metodo: email, cloud storage, USB, canal cifrado
  [ ] Identificar el actor: interno (empleado), externo (atacante), tercero
  [ ] Reconstruir la timeline completa: cuando empezo, cuanto duro
  [ ] Evaluar si los datos estan cifrados (en transito y en reposo)

FASE 4: LEGAL Y COMUNICACION
  [ ] Consultar con legal sobre obligaciones de notificacion
  [ ] AEPD: notificar en 72 horas si hay datos personales de la UE
  [ ] Clientes afectados: notificar segun contrato y regulacion
  [ ] CCN-CERT: si aplica por sector
  [ ] Valorar comunicacion publica (si hay riesgo de filtracion en prensa)

Template de documentacion de incidente

INFORME DE INCIDENTE [ID-YYYYMMDD-NNN]

RESUMEN EJECUTIVO:
  Fecha de deteccion:    [YYYY-MM-DD HH:MM UTC]
  Fecha de contencion:   [YYYY-MM-DD HH:MM UTC]
  Fecha de cierre:       [YYYY-MM-DD HH:MM UTC]
  Severidad:             [S1/S2/S3/S4]
  Tipo:                  [Ransomware/Phishing/Exfiltracion/...]
  Impacto de negocio:    [Descripcion breve]
  Sistemas afectados:    [Lista]
  Datos comprometidos:   [Si/No, descripcion]

TIMELINE:
  [HH:MM] - [Accion o evento]
  [HH:MM] - [Accion o evento]
  ...

VECTOR DE ENTRADA:
  [Como entro el atacante / como inicio el incidente]

ACCIONES DE CONTENCION:
  [Que se hizo para detener el incidente]

ACCIONES DE ERRADICACION:
  [Que se hizo para eliminar la amenaza]

ACCIONES DE RECUPERACION:
  [Que se hizo para restaurar operaciones]

IOCS:
  IPs:       [lista]
  Dominios:  [lista]
  Hashes:    [lista]
  Emails:    [lista]
  URLs:      [lista]

LECCIONES APRENDIDAS:
  Que funciono bien:      [lista]
  Que no funciono:        [lista]
  Que hay que mejorar:    [lista]
  Acciones correctivas:   [lista con responsable y fecha limite]

COSTE ESTIMADO:
  Horas de personal:      [numero]
  Impacto en negocio:     [estimacion]
  Coste de remediacion:   [estimacion]
  Servicios externos:     [si aplica]

Checklist de preservacion de evidencia

EVIDENCIA DIGITAL (prioridad de volatilidad):
  1. [ ] Memoria RAM (volatil, maxima prioridad)
  2. [ ] Conexiones de red activas (netstat, tcpdump)
  3. [ ] Procesos en ejecucion (tasklist, ps)
  4. [ ] Archivos temporales y cache
  5. [ ] Logs del sistema operativo
  6. [ ] Logs de aplicaciones
  7. [ ] Imagen de disco / snapshot de VM
  8. [ ] Logs de red (firewall, proxy, IDS)
  9. [ ] Logs del servicio de directorio (AD)
  10. [ ] Logs de correo electronico

CADENA DE CUSTODIA:
  Para cada evidencia:
  [ ] Hash SHA-256 del archivo/imagen calculado
  [ ] Fecha y hora de adquisicion registrada
  [ ] Persona que adquirio la evidencia registrada
  [ ] Metodo de adquisicion documentado
  [ ] Almacenamiento seguro (acceso restringido, cifrado)
  [ ] Registro de accesos a la evidencia

HERRAMIENTAS RECOMENDADAS:
  Memoria:    Winpmem, LiME (Linux), Rekall
  Disco:      FTK Imager, dd, dc3dd
  Red:        Wireshark, tcpdump, NetworkMiner
  Triage:     KAPE, Velociraptor, GRR
  Timeline:   Plaso/log2timeline, Timesketch

Comunicacion durante un incidente

Comunicacion interna

TEMPLATE EMAIL INICIAL (para equipo de respuesta):
  Asunto: [INCIDENTE S1] - [Tipo] - [Referencia]

  Se ha declarado un incidente de severidad [S1/S2].

  Resumen: [descripcion en 2-3 lineas]
  Sistemas afectados: [lista]
  Incident Commander: [nombre]
  Canal de comunicacion: [Slack/Teams canal dedicado]
  Proxima reunion: [hora]

  Acciones inmediatas asignadas:
  - [Persona]: [accion]
  - [Persona]: [accion]

  NO compartir informacion del incidente fuera de este grupo.

Comunicacion con reguladores

NOTIFICACION AEPD (si hay brecha de datos personales):
  Plazo: 72 horas desde deteccion
  Via: Sede electronica AEPD
  Contenido obligatorio:
    - Naturaleza de la brecha
    - Categorias y numero de afectados
    - Datos del DPO
    - Consecuencias probables
    - Medidas adoptadas y propuestas

NOTIFICACION CCN-CERT (sector publico / critico):
  Via: LUCIA (sistema de notificacion del CCN)
  Contenido: segun taxonomia de incidentes del CCN

Metricas de respuesta a incidentes

Metricas para medir la madurez del proceso:

MTTD (Mean Time To Detect):
  Tiempo medio desde la intrusion hasta la deteccion.
  Objetivo: segun regulacion y criticidad.

MTTR (Mean Time To Respond):
  Tiempo medio desde la deteccion hasta la contencion.
  Objetivo S1: 15 minutos. S2: 1 hora.

MTTC (Mean Time To Contain):
  Tiempo medio hasta que el incidente esta contenido.

MTTRE (Mean Time To Eradicate):
  Tiempo medio hasta la erradicacion completa.

Incidentes por tipo y severidad (mensual)
Tasa de falsos positivos
Numero de lecciones aprendidas implementadas
Tiempo medio de restauracion de servicio

Personalizacion del template

Este template es un punto de partida. Para adaptarlo a tu organizacion:

Sustituir los campos entre corchetes con datos reales.
Adaptar los niveles de severidad a tu contexto de negocio.
Anadir playbooks para tipos de incidente especificos de tu sector (ej: fraude bancario, compromiso de SCADA).
Integrar con tus herramientas (SOAR, SIEM, EDR).
Validar con un ejercicio de mesa (tabletop exercise) antes de usarlo en produccion.
Revisar y actualizar despues de cada incidente real.

Un playbook vivo, revisado y practicado es la diferencia entre una respuesta ordenada y un caos improvisado.