Cómo escribir un plan de respuesta a incidentes (con plantilla)

TL;DR

Un plan de respuesta a incidentes es un manual documentado y probado que le dice a tu organización exactamente quién hace qué cuando ocurre un incidente de ciberseguridad. Esta guía recorre las seis fases del framework NIST SP 800-61, proporciona una plantilla lista para usar en cada fase, define roles y responsabilidades del equipo IR e incluye escenarios de ejercicios de simulación para validar el plan antes de que llegue una crisis real. Las organizaciones con un plan IR probado reducen el coste medio de una brecha de datos en $2.66 millones.

Eran las 2:17 AM de un martes cuando Reyes, el director de IT de una empresa de logística de 400 personas, recibió una llamada del supervisor del turno nocturno del almacén. Cada pantalla del centro de distribución mostraba el mismo mensaje: "Tus archivos están cifrados. Paga 4.2 BTC en 72 horas o tus datos serán publicados." Reyes cogió su portátil y condujo hasta la oficina. Al llegar, descubrió que el ransomware se había propagado a 340 endpoints y cifrado tres servidores de archivos, incluido el que ejecutaba su base de datos de seguimiento de envíos.

Llamó a su CEO. Su CEO llamó al abogado de la empresa. El abogado preguntó quién era el responsable de respuesta a incidentes. Silencio. Nadie tenía ese título porque nadie había escrito ese plan. Durante las siguientes 96 horas, la empresa perdió $1.8 millones en envíos retrasados, pagó $40,000 a una firma forense que cobró tarifas de emergencia y descubrió que los atacantes habían estado dentro de su red durante 47 días antes de desplegar el ransomware. No tenían evidencia forense preservada, ni plantillas de comunicación para clientes, ni procedimiento de recuperación documentado. Reconstruyeron todo desde cero.

Esta historia se repite en todas las industrias cada semana. Según el IBM Cost of a Data Breach Report 2025, las organizaciones con un plan de respuesta a incidentes probado reducen el coste medio de una brecha en $2.66 millones comparado con aquellas sin uno. El plan no es un lujo. Es la inversión con mayor retorno en tu programa de seguridad.

Qué contiene realmente un plan de respuesta a incidentes

Un plan de respuesta a incidentes no es un archivador que se queda en una estantería acumulando polvo. Es un documento operativo vivo que responde cinco preguntas antes de que alguien necesite hacerlas: ¿Qué constituye un incidente? ¿Quién responde? ¿Qué hacen primero? ¿A quién llaman? ¿Y cómo se recupera la organización?

El framework NIST SP 800-61 Rev 2 organiza todo el ciclo de vida del incidente en seis fases. Cada fase tiene objetivos específicos, entradas requeridas y salidas definidas. Las secciones de plantilla a continuación dan a tu equipo un punto de partida para cada una.

Fase 1: Preparación

La preparación es todo lo que ocurre antes de que suceda un incidente. Aquí es donde la mayoría de las organizaciones fallan, no porque la omitan por completo, sino porque la hacen una vez y nunca la revisan. Un plan escrito hace dos años con números de teléfono de empleados que ya no trabajan en la empresa es peor que no tener plan porque crea falsa confianza.

Sección de plantilla para tu plan IR:

• Inventario de activos: Lista todos los sistemas críticos clasificados por impacto en el negocio. Incluye el propietario del sistema, el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) para cada uno.
• Preparación de herramientas: Confirma que tu SIEM está ingiriendo logs de todas las fuentes críticas. Verifica que las herramientas de imagen forense están licenciadas, instaladas y probadas. Asegúrate de que tu equipo tiene acceso offline al plan IR en sí (copias impresas o un dispositivo aislado).
• Árbol de comunicación: Construye una lista de contactos con contactos primarios y de respaldo para cada rol IR. Incluye números de teléfono personales, no solo correo electrónico laboral. Prueba el árbol trimestralmente.
• Checklist legal y regulatorio: Documenta qué regulaciones aplican a tu organización (GDPR, HIPAA, PCI DSS, leyes de notificación de brechas estatales). Lista los plazos de notificación y los contactos regulatorios exactos.

La fase de preparación también incluye formación. Cada miembro del equipo IR debe entender su rol sin necesidad de leer el plan por primera vez durante un incidente activo. El SANS Institute recomienda revisiones trimestrales del plan y al menos dos ejercicios de simulación al año.

Fase 2: Detección y Análisis

La detección es el momento en que te das cuenta de que algo va mal. El análisis es el proceso de confirmar si es un incidente genuino o un falso positivo, y determinar su alcance, severidad y tipo.

La mayoría de las organizaciones detectan incidentes a través de uno de cuatro canales: alertas automatizadas de su SIEM o plataforma de detección y respuesta de endpoints, informes de empleados que notan comportamiento inusual, notificaciones de terceros como fuerzas del orden o investigadores de seguridad, y feeds de inteligencia de amenazas que cruzan indicadores de compromiso con telemetría interna.

Sección de plantilla para tu plan IR:

• Criterios de triaje de alertas: Define niveles de severidad (Crítica, Alta, Media, Baja) con ejemplos específicos. Un solo intento de inicio de sesión fallido es informativo. Quinientos intentos fallidos desde la misma IP origen dirigidos a una cuenta de administrador en 10 minutos es crítico.
• Checklist de validación: Antes de declarar un incidente, el analista debe confirmar que la alerta no es un falso positivo, identificar los sistemas y datos afectados, determinar el vector de ataque si es posible, y evaluar si la actividad está en curso.
• Matriz de clasificación de incidentes: Mapea tipos de incidentes (ransomware, exfiltración de datos, amenaza interna, DDoS, compromiso de phishing) a su nivel de severidad y el playbook de respuesta correspondiente.
• Protocolo de preservación de evidencia: El primer respondedor debe capturar datos volátiles (procesos en ejecución, conexiones de red, memoria) antes de tomar cualquier acción de contención que pueda alterarlos. Documenta la cadena de custodia desde el primer momento.

El tiempo medio para identificar y contener una brecha es de 258 días para organizaciones sin plan y 184 días para las que tienen uno. Esa diferencia de 74 días existe porque los equipos sin preparación pierden tiempo averiguando quién debería hacer qué en lugar de hacerlo realmente.

Fase 3: Contención

La contención evita que el incidente se propague mientras preserva la evidencia para la investigación. NIST distingue entre contención a corto plazo (acciones inmediatas para detener la hemorragia) y contención a largo plazo (medidas sostenibles que te permiten investigar sin mayor exposición).

Sección de plantilla para tu plan IR:

• Contención a corto plazo: Aísla los sistemas afectados de la red deshabilitando puertos del switch o moviéndolos a una VLAN de cuarentena. Bloquea IPs y dominios maliciosos conocidos en el firewall. Deshabilita cuentas de usuario comprometidas. Estas acciones deben ocurrir en la primera hora.
• Contención a largo plazo: Aplica reglas temporales de segmentación de red. Configura monitoreo mejorado en sistemas adyacentes a los comprometidos. Redirige el DNS para dominios afectados. Construye sistemas limpios en paralelo si la recuperación requerirá una reconstrucción completa.
• Matriz de decisión de contención: Para cada tipo de incidente, define acciones de contención preaprobadas que el equipo IR puede ejecutar sin esperar aprobación ejecutiva. Un analista SOC a las 3 AM no debería necesitar llamar al CEO para aislar una estación de trabajo que está cifrando activamente carpetas compartidas.

La contención también es donde las consideraciones legales se vuelven urgentes. Si tu organización está sujeta a leyes de notificación de brechas, el reloj puede comenzar a correr en el momento en que confirmas que se accedió a datos personales. Tu asesor legal debe ser notificado durante la contención, no después de la recuperación.

Fase 4: Erradicación

La erradicación elimina la amenaza de tu entorno por completo. Esto significa eliminar malware, cerrar la vulnerabilidad que explotó el atacante, eliminar puertas traseras y mecanismos de persistencia, y revocar cualquier credencial que el atacante pueda haber capturado.

Sección de plantilla para tu plan IR:

• Identificación de causa raíz: Determina exactamente cómo el atacante obtuvo acceso inicial. ¿Fue un correo de phishing? ¿Un aparato VPN sin parche? ¿Una credencial de proveedor comprometida? Si no identificas la causa raíz, el atacante volverá por la misma puerta.
• Procedimientos de eliminación de malware: Ejecuta escaneos de endpoints con firmas actualizadas. Comprueba tareas programadas, modificaciones de registro, elementos de inicio y cron jobs que el atacante pueda haber plantado. Verifica que no hay callbacks de comando y control desde ningún sistema.
• Protocolo de restablecimiento de credenciales: Restablece contraseñas de todas las cuentas que tuvieron acceso a sistemas comprometidos. Revoca y reemite claves API, certificados y tokens de acceso. Fuerza la reinscripción de autenticación multifactor en cuentas afectadas.
• Remediación de vulnerabilidades: Parchea la vulnerabilidad que fue explotada. Si no hay parche disponible, implementa un control compensatorio (segmentación de red adicional, monitoreo mejorado o deshabilitación del servicio afectado).

Fase 5: Recuperación

La recuperación devuelve los sistemas afectados a operaciones normales. El principio crítico aquí es que la recuperación debe ser verificada, no asumida. Un sistema que parece limpio puede seguir albergando una puerta trasera profundamente embebida.

Sección de plantilla para tu plan IR:

• Prioridad de restauración de sistemas: Restaura sistemas en orden de criticidad para el negocio, siguiendo los valores RTO definidos en la Fase 1. Verifica la integridad de cada sistema antes de reconectarlo a la red de producción.
• Restauración de datos: Restaura desde backups tomados antes de que comenzara el compromiso. Verifica la integridad de los backups con comparaciones de hash antes de restaurar. Si el atacante estuvo en tu entorno durante semanas, tus backups más recientes también pueden estar comprometidos.
• Pruebas de validación: Ejecuta escaneos de vulnerabilidades contra los sistemas restaurados. Monitorea el tráfico de red en busca de anomalías durante las primeras 48 horas después de la restauración. Confirma que todos los indicadores de compromiso de la investigación están ausentes.
• Reconexión gradual: No reconectes todo a la vez. Lleva los sistemas de vuelta en línea por etapas, monitoreando cada etapa en busca de signos de reinfección antes de proceder a la siguiente.

Fase 6: Actividad Post-Incidente

La actividad post-incidente es la fase que separa a las organizaciones que mejoran de las que repiten los mismos errores. NIST la llama la fase más importante porque impulsa la mejora continua de toda la capacidad de respuesta a incidentes.

Sección de plantilla para tu plan IR:

• Reunión de revisión post-incidente: Realiza un debriefing estructurado dentro de los 5 días hábiles posteriores al cierre del incidente. Incluye a todas las personas que participaron en la respuesta. Usa un formato sin culpas que se centre en brechas del proceso, no en errores individuales.
• Reconstrucción de la línea temporal: Construye una línea temporal completa desde el compromiso inicial hasta la detección, contención, erradicación y recuperación. Identifica dónde ocurrieron retrasos y por qué.
• Informe de lecciones aprendidas: Documenta qué funcionó, qué falló y qué necesita cambiar. Asigna acciones específicas con responsables y plazos. Los hallazgos típicos incluyen brechas de detección, fallos de comunicación, herramientas faltantes y autoridad poco clara.
• Actualizaciones del plan: Revisa el plan de respuesta a incidentes basándote en los hallazgos en un plazo de 30 días. Actualiza playbooks, listas de contactos y procedimientos. Comunica los cambios a todo el equipo IR.
• Métricas a rastrear: Tiempo medio de detección (MTTD), tiempo medio de contención (MTTC), tiempo medio de recuperación (MTTR), impacto total en el negocio en horas y dinero, y número de sistemas afectados.

Roles y responsabilidades

Un plan sin propiedad clara es una sugerencia, no un procedimiento. Define estos roles antes de que un incidente te obligue a improvisar.

Líder IR (Comandante de Incidente): Coordina toda la respuesta. Toma decisiones de contención y escalación. Sirve como punto único de autoridad durante el incidente. Esta persona no realiza análisis técnico; dirige el tráfico y elimina obstáculos.

Analistas de seguridad: Realizan la investigación técnica y el análisis forense. Operan el SIEM, revisan logs, analizan muestras de malware e identifican indicadores de compromiso. En un centro de operaciones de seguridad, estos son típicamente los primeros respondedores que clasifican alertas y escalan incidentes confirmados.

Líder de operaciones IT: Gestiona el aislamiento de sistemas, la restauración de backups y los cambios de infraestructura requeridos durante la contención y recuperación. Se coordina con el Líder IR sobre qué sistemas desconectar y en qué orden.

Coordinador de comunicaciones: Maneja todas las comunicaciones internas y externas. Redacta notificaciones a empleados, divulgaciones a clientes, declaraciones de prensa y documentos regulatorios. Cada declaración externa debe ser revisada por el asesor legal antes de su publicación.

Asesor legal: Determina obligaciones de notificación, gestiona el privilegio abogado-cliente sobre hallazgos forenses, coordina con las fuerzas del orden si hay actividad criminal involucrada y asesora sobre cumplimiento regulatorio durante toda la respuesta.

Patrocinador ejecutivo: Un líder de nivel C (típicamente el CISO o CTO) que autoriza decisiones con impacto en el negocio como apagar sistemas que generan ingresos, contratar firmas forenses externas o aprobar negociaciones de rescate.

Consejos para ejercicios de simulación

Un plan que nunca has probado es un plan que no tienes. Los ejercicios de simulación revelan brechas que leer el documento nunca revelará: el número de contacto que va al buzón de voz, el paso de contención que requiere una herramienta que nadie ha instalado, la ruta de escalación que omite a un tomador de decisiones clave.

Cómo ejecutar un ejercicio de simulación efectivo:

1. Elige un escenario realista. Básalo en incidentes que realmente han ocurrido en tu industria. Un ataque de ransomware que comienza con un correo de phishing y se propaga mediante movimiento lateral es un buen primer escenario. Para ejercicios posteriores, prueba compromiso de cadena de suministro, amenaza interna o configuración incorrecta de nube que lleva a exposición de datos.

2. Prepara el escenario con inyecciones. Divide el escenario en etapas, cada una introducida con nueva información (una "inyección"). Etapa 1: "Un empleado reporta que su pantalla está bloqueada con un mensaje de rescate." Etapa 2: "Tres estaciones de trabajo más en la misma subred ahora muestran el mismo mensaje." Etapa 3: "Tu servidor de backups no es accesible." Cada inyección obliga al equipo a reevaluar y adaptarse.

3. Asigna roles reales. Los participantes deben responder desde su rol IR designado, no como observadores. Si tu coordinador de comunicaciones está en la sala, debe describir exactamente qué mensaje enviaría, a quién y a través de qué canal.

4. Limita el tiempo del ejercicio. De 60 a 90 minutos es ideal. Más largo pierde enfoque. Más corto no genera suficiente presión para revelar brechas reales.

5. Haz el debriefing inmediatamente. Captura los hallazgos mientras están frescos. Haz tres preguntas: ¿Qué funcionó bien? ¿Qué falló? ¿Qué cambiaremos en el plan antes del próximo ejercicio?

Los CISA Tabletop Exercise Packages proporcionan escenarios gratuitos listos para ejecutar para organizaciones que quieren ejercicios estructurados sin construirlos desde cero.

El 76% de las organizaciones experimentaron al menos un ataque de ransomware en 2025, pero solo el 37% tenía un plan de respuesta a incidentes completamente probado. Los ejercicios de simulación realizados trimestralmente mejoran los tiempos reales de respuesta entre un 25 y un 40%, según la SANS 2025 Incident Response Survey. La inversión es unas pocas horas por trimestre. El retorno se mide en días de inactividad prevenidos y millones en costes de brecha evitados.

Del documento a la capacidad

Un plan de respuesta a incidentes no es una casilla de cumplimiento. Es la diferencia entre una contención coordinada de 4 horas y un caos de 96 horas que cuesta millones. La empresa de logística del inicio de este artículo finalmente escribió su plan. Les tomó dos semanas. Pasaron otra tarde ejecutando su primer ejercicio de simulación, que reveló que su proceso de restauración de backups tenía un hueco de 6 horas que nadie había notado.

El mejor momento para escribir tu plan de respuesta a incidentes fue antes de tu último incidente de seguridad. El segundo mejor momento es hoy. Empieza con las seis fases NIST. Completa las secciones de plantilla para tu entorno específico. Asigna roles a personas reales con números de teléfono reales. Luego pruébalo. Revísalo. Pruébalo de nuevo. El plan nunca está terminado porque tu entorno, tus amenazas y tu equipo siempre están cambiando.

Toda organización recibe un golpe eventualmente. La pregunta no es si enfrentarás un incidente de ciberseguridad. La pregunta es si responderás con un plan probado o con pánico.