El plan de respuesta a incidentes que un equipo pequeño sí usa
Plan de respuesta a incidentes de ciberseguridad para Pymes: qué cabe en una página, quién toma cada decisión y un simulacro de 90 minutos para probarlo.
Sergio
CEO, DGTL
Son las 2 de la mañana de un martes. Tu ingeniero de guardia ve una nota de rescate en todas las pantallas y un plazo de 48 horas. ¿Quién decide si producción se apaga? ¿Quién llama al abogado, a la aseguradora, a tu cliente más grande? Si la respuesta es "el que esté despierto en el chat del equipo", no tienes un plan de respuesta a incidentes.
No eres el único. La Cyber Security Breaches Survey 2025/2026 del gobierno británico, que Ipsos hizo para DSIT y el Home Office, encuestó a 2,112 empresas del Reino Unido, casi todas por teléfono. Solo el 25% tenía un plan formal de respuesta a incidentes. Entre las empresas medianas (50 a 249 empleados), el 57%. Las 44 entrevistas de seguimiento del estudio encontraron planes en su mayoría sin probar o incompletos. Una pequeña empresa lo resumió sin rodeos: tienen el plan en el manual del personal, pero nunca lo han probado.
La solución para un equipo de 20 a 500 personas no es una carpeta de 40 páginas. Es un plan de una página y un simulacro de mesa de 90 minutos.
¿Por qué una empresa B2B pequeña necesita un plan de respuesta a incidentes?
Porque el ransomware no necesita que seas grande. El Data Breach Investigations Report 2026 de Verizon analizó más de 22,000 brechas confirmadas entre noviembre de 2024 y octubre de 2025 y encontró ransomware en el 48%, frente al 44% del informe anterior. En los casos de ransomware donde se conocía el tamaño de la víctima, cerca del 96% eran Pymes. Verizon cuenta como Pyme a cualquier organización con menos de 1,000 empleados, una categoría más amplia que una startup de 60 personas, y describe grupos que atacan de forma indiscriminada y caen sobre quien tenga credenciales comprometidas o dispositivos perimetrales sin parchear.
Los incidentes, además, duran más de lo que suponen casi todos los planes. La guía de respuesta a incidentes de NIST, la SP 800-61 Rev. 3 (abril de 2025), reemplazó un modelo de ciclo de vida pensado para una época en que la respuesta y la recuperación solían cerrarse en uno o dos días. Hoy, según NIST, recuperarse suele tomar semanas o meses. Un plan que se queda en el diagnóstico técnico deja fuera la mayor parte del incidente.
¿Qué debe incluir un plan de respuesta a incidentes de una página?
La hoja informativa Incident Response Plan Basics de CISA (enero de 2024) fija el mínimo: un documento escrito, aprobado por la alta dirección, que aclara roles, guía las actividades clave e indica a quién vas a necesitar. Basta con seis secciones.
- Quién lo dirige. Nombra a un gerente de incidentes y a un suplente. Según CISA, esa persona lidera, gestiona la comunicación, delega y "no realiza ninguna tarea técnica". También vigila el reloj, porque bajo presión la gente pierde la noción del tiempo. En una empresa de 40 personas, elige al COO, no al CTO, que va a hacer falta frente al teclado. Suma a un responsable técnico y a uno de comunicación.
- Quién toma las decisiones grandes. Dejar producción fuera de línea, forzar el cambio de todas las credenciales, pagar o no un rescate. NIST señala que la dirección puede tener la autoridad sobre acciones de alto impacto, como apagar o reconstruir servicios críticos. Deja por escrito quién decide solo y a quién hay que consultar antes. Sobre el rescate, un dato: el 69% de las víctimas de ransomware en los datos de Verizon no pagó.
- Quién llama a quién. CISA recomienda revisar el plan con un abogado y elegir por adelantado una firma externa de investigación. Si tienes un seguro cibernético, lee hoy la cláusula de aviso de siniestro y revisa qué firmas cubre la póliza. Suma a tus proveedores críticos: Verizon encontró participación de terceros en el 48% de las brechas. Nombres y teléfonos, no cargos.
- Quién habla con los clientes. El responsable de comunicación tiene listo un comunicado inicial, redactado de antemano, y la lista de cuentas cuyos contratos o DPAs incluyen obligaciones de notificación. Los plazos dependen de dónde operas y de lo que firmaste, y esa lista la lleva tu abogado. Un ejemplo: según el GDPR (UE), el encargado del tratamiento debe notificar al responsable "sin dilación indebida" las violaciones de la seguridad de los datos personales de las que tenga conocimiento. Si tu empresa está sujeta al GDPR es una pregunta para tu abogado.
- Qué se conserva. Logs, imágenes de disco y una línea de tiempo de quién hizo qué. NIST pide preservar la integridad y la procedencia de los registros de la investigación, y trata los datos del incidente como evidencia aunque nadie vaya a juicio. Borrar y reconstruir a toda prisa destruye justo lo que necesitas para entender qué pasó.
- Qué se apaga. Los kill switches, escritos como pasos: revocar sesiones, rotar API keys y credenciales cloud, desactivar cuentas comprometidas, aislar equipos, restaurar desde backups probados. NIST agrega: revisa los backups en busca de señales de compromiso antes de restaurar.
Y después, imprímelo. CISA lo dice al pie de la letra: durante un incidente, el correo, el chat y el almacenamiento de documentos pueden estar caídos.
¿Cómo se hace un primer simulacro de mesa?
Un simulacro de mesa (tabletop) es un juego de roles con moderador: alguien presenta un escenario por etapas y el equipo discute cómo respondería. CISA publica más de 100 paquetes de ejercicios con objetivos, escenarios y preguntas de discusión listos para adaptar, entre ellos ransomware, amenaza interna y compromiso de la cadena de suministro, en documentos de Word editables.
El paquete de ransomware de CISA dura cerca de tres horas: 20 minutos de introducción, dos módulos de 60 minutos con una pausa y 20 minutos de cierre (hotwash). En un primer simulacro, lo reduciríamos a 90 minutos y haríamos solo el segundo módulo, el que pone a prueba el plan:
- Etapa 1 (10 minutos). Fuera de horario, el monitoreo detecta tráfico DNS inusual y una gran salida de datos desde equipos de Recursos Humanos. ¿A quién se alerta y quién declara el incidente?
- Etapa 2 (25 minutos). Notas de rescate en todas las pantallas, pago exigido en 48 horas. ¿Quién decide el apagado y el pago? ¿Quién llama al abogado y a la aseguradora?
- Etapa 3 (20 minutos). Un investigador avisa que un grupo criminal ofrece tus datos a la venta. ¿Qué conservas y qué les dices a los clientes?
- Etapa 4 (15 minutos). Llaman periodistas. ¿Quién responde y con qué mensaje?
- Cierre (20 minutos). Qué falló, quién se encarga de cada arreglo y para cuándo.
Mantenlo sin culpables, como indica el paquete de CISA, con alguien que tome notas sin participar. Invita a todas las personas que nombra el plan, incluida la persona que maneja tus cuentas más grandes. El resultado que importa: de tres a cinco arreglos, cada uno con responsable y fecha.
¿Cada cuánto hay que actualizar el plan?
CISA recomienda revisarlo cada trimestre, un ritmo razonable para una empresa que despliega cada semana. Y también después de cada incidente real y de cada simulacro, en una retrospectiva sin culpables: los incidentes "casi siempre son el resultado de una falla del sistema en general", en palabras de CISA. Un nuevo proveedor cloud, un cliente corporativo con obligaciones de notificación o la salida de alguien de la lista de contactos también deberían disparar una actualización.
Si te estás preparando para SOC 2, la respuesta a incidentes es uno de los controles que comparte con ISO 27001. Escribe el plan una sola vez y guarda las notas de cada simulacro: un historial con fechas es más fácil de mostrar que de reconstruir.
¿Quién es dueño del plan?
Parece un documento de seguridad, pero involucra a tres prácticas. Build se encarga de la mitad técnica: logs centralizados que sobrevivan al incidente, backups con pruebas de restauración y los runbooks de los kill switches. Advisory, muchas veces a través de un CISO fraccional, es dueño del plan, de quién decide qué y de lo que escucha la junta directiva. Sales lo siente primero, porque el responsable de comunicación necesita la lista de cuentas y los términos de cada contrato. Secure es donde las tres se encuentran, y por eso haríamos el simulacro con las tres en la sala. La dimensión Secure del DGTL Readiness Index incluye la madurez en respuesta a incidentes. Conoce nuestra metodología.
Relacionados: SOC 2 sin dolor → · SOC 2 o ISO 27001 → · CTO, CMO y CISO fraccional →