El NIST jubiló en abril de 2025 la publicación que durante trece años marcó cómo responder a un incidente: la revisión 3 de la SP 800-61 ocupó su lugar. Aun así, muchas guías en español continúan enseñando el ciclo de vida del texto retirado, flechas incluidas. Redactar hoy un plan de respuesta a incidentes calcando ese esquema equivale a apoyarlo en una referencia que su autor ya descartó.
Además, el plan dejó de ser un asunto puramente técnico: NIS2, DORA, el ENS y el RGPD le han colgado relojes, con avisos obligatorios que empiezan a contar a las cuatro horas. Los casos, mientras tanto, siguen subiendo: INCIBE gestionó 122.223 incidentes en 2025, su máximo histórico y un 26 % más que en 2024, con pymes y autónomos detrás de seis de cada diez expedientes.
Lo de abajo es, norma por norma, lo que ese documento debe traer decidido antes de que suene el primer aviso.
¿Qué es un plan de respuesta a incidentes y qué no es?
El plan de respuesta a incidentes deja establecido de antemano, para el día en que la organización sufra un ciberincidente, quién decide, quién ejecuta lo decidido y a quién le toca comunicarlo, por ese orden. Existe para no improvisar. Las decisiones que en plena crisis costarían horas de reuniones ya están tomadas, escritas y firmadas.
A menudo se mezcla con sus documentos vecinos. El plan de continuidad de negocio se ocupa de que la empresa siga funcionando mientras dura el incidente, que es otra tarea. La comunicación de crisis, que tratamos al escribir sobre las primeras 24 horas de comunicación, tiene su documento aparte, y es el plan de respuesta el que debería activarlo. Y una colección de guiones de actuación (playbooks) sueltos se queda corta, porque cada guion baja al detalle técnico de un escenario concreto, mientras que el plan ordena responsables y tiempos del conjunto.
El modelo de referencia ha cambiado: del ciclo de fases al riesgo
Desde 2012, la revisión 2 de la SP 800-61 organizaba la respuesta como un ciclo: preparación; detección y análisis; contención, erradicación y recuperación; lecciones aprendidas. El esquema puebla miles de planes, presentaciones y temarios, y para describir un incidente aislado funciona.
La revisión 3 deja atrás ese ciclo y apoya la respuesta en las seis funciones del CSF 2.0, el marco de ciberseguridad del propio NIST: gobernar, identificar, proteger, detectar, responder y recuperar. La consecuencia es que la preparación pasa a funcionar como gobierno permanente, y lo aprendido en cada incidente tiene que llegar a la gestión de riesgos global en lugar de morir en el acta de la reunión posterior.
Dicho de otro modo, un PDF de fases que duerme entre incidente e incidente pertenece al modelo retirado. Lo que hoy se espera es un proceso vivo, con dueño, con revisiones fechadas y conectado al análisis de riesgos.
Qué contiene un plan que funciona
Suele sobrar papel y faltar concreción: las piezas necesarias son pocas. Estas son las que deben quedar cerradas de antemano:
- El alcance y la definición de incidente: qué activa el plan y qué se queda en avería o en alerta descartada.
- Los roles con nombres, suplentes y teléfonos fuera del directorio corporativo: dirección del incidente, decisión ejecutiva, técnica, legal y comunicación.
- Los criterios de clasificación por peligrosidad e impacto, como los de la guía CCN-STIC 817, para que la palabra «crítico» signifique lo mismo a las tres de la tarde y a las tres de la madrugada.
- La matriz de notificación: qué autoridad, qué plazo, qué canal y quién rellena el formulario, norma por norma.
- Los guiones de actuación de los escenarios probables del negocio: ransomware, compromiso de correo, fuga de datos, proveedor comprometido.
- Las reglas de preservación de evidencias antes de restaurar, para que el análisis forense posterior siga siendo posible y las pruebas valgan ante un juez o una aseguradora.
- El criterio de escalado a terceros: en qué punto entran el proveedor de respuesta, el ciberseguro y las fuerzas de seguridad.
También el formato cuenta. Guarda la copia de referencia fuera del dominio corporativo, en un sitio que siga accesible con los sistemas caídos. Y que no pase de veinte o veinticinco páginas. Nadie va a leerse sesenta con la producción parada.
Los relojes normativos: quién obliga a notificar y cuándo
Aquí el plan pasa de recomendación a obligación con multa detrás. Para una empresa privada en España, hoy rigen estos plazos:
- NIS2 (artículo 23), para entidades esenciales e importantes: alerta temprana en 24 horas desde que se conoce el incidente significativo, notificación completa en 72 horas e informe final en un mes.
- DORA, para entidades financieras: notificación inicial en las 4 horas siguientes a clasificar el incidente como grave y, como máximo, 24 horas desde que se conoce; informe intermedio a las 72 horas de la notificación inicial y final en un mes, según el Reglamento de Ejecución (UE) 2025/302 y la guía del Banco de España.
- ENS (Real Decreto 311/2022), para el sector público y sus proveedores: notificación al CCN-CERT de los incidentes de impacto significativo, a través de la plataforma LUCIA y con la taxonomía de la CCN-STIC 817.
- RGPD (artículo 33): 72 horas a la AEPD cuando la brecha afecta a datos personales, con obligación añadida de avisar a los interesados si el riesgo es alto.
- Cyber Resilience Act, para fabricantes de productos con elementos digitales: 24 horas para el primer aviso de una vulnerabilidad explotada, como contamos al analizar la notificación exprés del CRA.
Varios de esos plazos pueden dispararse a la vez. Un ransomware con robo de datos en una entidad financiera activa DORA y RGPD de golpe, y NIS2 si hay infraestructura esencial por medio: un único incidente con tres reguladores esperando, cada uno con su formulario y su plazo. Por eso el plan debe fijar por escrito quién atiende cada ventana; resolverlo sobre la marcha significa poner a la gente de sistemas a rellenar formularios en lugar de contener el incidente.
En Hard2bit trabajamos a la vez el frente técnico y el regulatorio: los servicios de adecuación a NIS2 y DORA incluyen justamente esa matriz de notificación y su encaje dentro del plan de respuesta.
¿Cómo se prueba un plan sin esperar a sufrir un incidente?
Mientras no se prueba, el plan es una hipótesis. El mínimo exigible es un ejercicio de mesa al año: dos horas, un escenario creíble y en la sala quienes decidirían llegado el caso, dirección incluida. De ahí salen los huecos: el suplente que dejó la empresa, el contrato de proveedor caducado, el plazo de notificación que cada uno creía vigilado por otro.
Subiendo un escalón está el simulacro técnico: restaurar una copia de seguridad completa, aislar un segmento de red y cronometrar cuánto pasa entre la primera alerta y la primera decisión ejecutiva. Esas dos medidas, el tiempo hasta decidir y el tiempo hasta notificar, retratan el plan mejor que la mayoría de auditorías de papel.
Falta decidir quién descuelga el teléfono. Sin guardia interna, esa capacidad se contrata por adelantado. Con un contrato de respuesta con tiempos de activación pactados (retainer), el equipo forense y de respuesta (DFIR) llega al incidente conociendo ya tu red, y no la descubre con la crisis en marcha.
Los fallos que más se repiten al revisar planes ajenos
En Hard2bit llevamos desde 2013 respondiendo incidentes y revisando planes, y el repertorio de fallos apenas varía. Encabeza la lista la plantilla descargada tal cual, con roles que la organización no tiene. Siguen los contactos caducados: verificar la lista lleva dos minutos y aun así es lo que antes falla en la mayoría de los planes que pasan por nuestras manos con más de un año encima. También asoma el plan almacenado únicamente en el servidor de ficheros que el ransomware terminará cifrando. Y la decisión de pagar o no un rescate casi nunca se ha hablado con dirección antes de tener que tomarla con la empresa detenida.
Hay otro fallo que hace menos ruido: depender de una sola persona. Cuando toda la respuesta vive en la cabeza del responsable de sistemas, lo que la organización tiene no es un plan; es un empleado sin derecho a vacaciones. Dejar las suplencias por escrito y ensayar sin el titular evita ese punto único de fallo a un coste mínimo.
Por dónde empezar
Partiendo de cero, un orden sensato es empezar por acotar qué cuenta como incidente en tu negocio, nombrar los cinco roles con sus suplentes, montar la matriz de notificación que te toque y redactar los dos guiones de actuación más probables. Eso basta para convocar el primer ejercicio de mesa, y de lo que destape saldrá el resto del plan. Y si prefieres que ese primer ejercicio lo diseñe quien ha gestionado crisis de este tipo, nuestro equipo de respuesta a incidentes lo prepara y lo prueba contigo.
Este artículo es informativo y refleja el marco normativo y las referencias técnicas vigentes a 26 de agosto de 2026: NIST SP 800-61r3, la Directiva NIS2, el Reglamento DORA con su normativa de desarrollo, el RD 311/2022 (ENS) y el RGPD. Plazos y obligaciones pueden variar según sector, tamaño y transposición nacional aplicable; contrasta tu caso concreto con asesoramiento especializado antes de decidir en materia de cumplimiento.
