Planes de respuesta a incidentes
Evaluación de su plan actual o desarrollo de uno nuevo — con procedimientos que alguien puede ejecutar a las 3 de la mañana, no un documento para auditoría.
- Para quién es
- Organizaciones sin plan formal, con un plan heredado que nadie ha probado, o que necesitan cumplir un requisito de su aseguradora, un regulador o un cliente corporativo.
- Duración típica
- 3 a 6 semanas
- Marcos de referencia
- NIST SP 800-61r3ISO/IEC 27035SANS PICERL
Existen dos clases de plan de respuesta a incidentes: el que se escribió para pasar una auditoría, y el que alguien puede abrir a las tres de la mañana de un domingo y saber qué hacer con él. Nosotros escribimos el segundo.
Cómo se reconoce un plan que no sirve
- Tiene más de sesenta páginas y ninguna lista de verificación accionable.
- Dice “notificar a las partes interesadas” sin nombres, teléfonos ni plazos.
- Asume que el correo corporativo y el chat interno funcionarán durante el incidente.
- No define quién tiene autoridad para desconectar producción sin pedir permiso.
- Nunca se ha probado.
- Está guardado en el servidor de archivos que el ransomware también cifra.
Qué incluye un plan que sí sirve
Manuales por escenario. Ransomware, compromiso de correo corporativo, exfiltración de datos, denegación de servicio, credenciales privilegiadas comprometidas, insider malicioso. Cada uno con sus primeros pasos definidos.
Autoridad de decisión explícita. Un incidente serio produce decisiones caras bajo presión de tiempo. Quién puede tomarlas se define antes, no durante.
Comunicación pre-aprobada. Plantillas para clientes, personal, prensa y reguladores, revisadas por su asesoría legal con anticipación. Redactar el primer comunicado durante la crisis produce siempre el peor comunicado posible.
Disparadores regulatorios. Cuándo hay obligación de notificar y en qué plazo, según la normativa que le aplique — incluida la protección de datos personales en Costa Rica y los regímenes extranjeros que alcancen a sus clientes.
Operación fuera de banda. Copias impresas, contactos en teléfonos personales, un canal de comunicación alterno acordado. Si el plan solo existe dentro de la red comprometida, no existe.
El plan y el ejercicio van juntos
Un plan nuevo sin probar es una hipótesis con buen formato. Por eso cerramos el desarrollo con un ejercicio de mesa: es donde aparecen los supuestos equivocados, mientras corregirlos todavía es barato.
Cómo lo ejecutamos
- 01
Diagnóstico
Si ya tiene un plan, lo evaluamos contra escenarios reales. La pregunta no es si el documento existe, sino si alguien podría ejecutarlo bajo presión.
- 02
Modelado de escenarios
Identificamos los incidentes más probables para su sector y tecnología. Un plan genérico falla precisamente en los detalles que importan.
- 03
Redacción de procedimientos
Playbooks accionables por escenario, con pasos concretos y decisiones predefinidas, no principios generales.
- 04
Definición de roles
Quién decide apagar producción. Quién habla con la prensa. Quién notifica al regulador y en qué plazo. Con suplentes, porque los incidentes no respetan las vacaciones.
- 05
Validación
Probamos el plan en un ejercicio de mesa antes de darlo por terminado. Un plan sin probar es una hipótesis.
Qué recibe
- Plan de respuesta a incidentes adaptado a su estructura, tamaño y tecnología
- Manuales de procedimiento (playbooks) para los escenarios más probables en su contexto
- Matriz de escalamiento con roles, responsables y suplentes definidos
- Árbol de contacto fuera de banda y plantillas de comunicación previamente aprobadas
- Criterios de clasificación de severidad y disparadores de notificación regulatoria