--- title: "Notificación de incidentes en NIS2: la alerta temprana de 24 horas" description: "Las obligaciones de notificación de NIS2 exigen a las entidades afectadas notificar los incidentes de seguridad significativos en una cascada de plazos escalonada: una alerta temprana en un plazo d…" locale: "es" canonical: "https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/nis2-y-nisg-2026/notificacion-de-incidentes-en-nis2-la-alerta-temprana-de-24-horas" category: "Agentes de IA" topic: "NIS2 y NISG 2026" updated: "2026-10-28T13:11:49.648Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Notificación de incidentes en NIS2: la alerta temprana de 24 horas Las obligaciones de notificación de NIS2 exigen a las entidades afectadas notificar los incidentes de seguridad significativos en una cascada de plazos escalonada: una alerta temprana en un plazo de 24 horas, una notificación completa en un plazo de 72 horas y un informe final en el plazo de un mes, siempre a la autoridad competente o al CSIRT nacional. ## De un vistazo - La cascada de plazos de NIS2 tiene tres fases: alerta temprana en 24 horas, notificación completa en 72 horas e informe final en el plazo de un mes desde la notificación de las 72 horas. - El destinatario es la autoridad nacional competente o el CSIRT: en Austria, según la ley NISG 2026, vigente desde el 1 de octubre de 2026, el CSIRT competente (para las empresas, actualmente CERT.at) bajo la supervisión de la Oficina Federal de Ciberseguridad, dependiente del Ministerio Federal del Interior (BMI); en Alemania, el BSI, según la ley NIS2UmsuCG, vigente desde el 6 de diciembre de 2025. - El plazo empieza a contar desde que se tiene conocimiento del incidente (awareness), no desde su inicio, porque el verdadero cuello de botella operativo es una detección fiable y documentada. - Una lógica de notificación escalonada y estructuralmente similar rige también en el Reglamento de Ciberresiliencia de la UE (Cyber Resilience Act) para los fabricantes de productos con elementos digitales (alerta temprana en 24 h, notificación en 72 h desde el 11 de septiembre de 2026) y en DORA, aunque DORA exige una notificación inicial mucho más ajustada para los incidentes relacionados con las TIC clasificados como graves; si estás sujeto a varios regímenes, necesitas un proceso de notificación unificado. - Las herramientas SOC basadas en IA ayudan sobre todo en la detección, la documentación completa y el seguimiento de plazos; la responsabilidad jurídica y el envío final siguen en manos de personas. - Este artículo no sustituye el asesoramiento jurídico: los umbrales y procedimientos concretos deben aclararse con asesores cualificados en cada jurisdicción. Las obligaciones de notificación de NIS2 exigen a las entidades afectadas notificar los incidentes de seguridad significativos en una cascada de plazos escalonada: una alerta temprana en un plazo de 24 horas, una notificación completa en un plazo de 72 horas y un informe final en el plazo de un mes, siempre a la autoridad competente o al CSIRT nacional. Esta cascada es el núcleo operativo que decide si una organización es capaz de notificar. - **Tres plazos, un desencadenante:** 24 horas para la alerta temprana, 72 horas para la notificación completa, un mes para el informe final, contados desde que se tiene conocimiento del incidente, no desde su inicio. - **Un único canal de destino:** la autoridad nacional competente o el CSIRT (en Austria, el CSIRT competente, actualmente CERT.at para las empresas, bajo la supervisión de la Oficina Federal de Ciberseguridad, dependiente del BMI; en Alemania, el BSI). - **El verdadero cuello de botella no es el formulario, sino la detección:** si detectas el incidente tarde, ya has perdido la carrera contra el reloj de las 24 horas. ## Por qué existe la cascada de plazos NIS2 sustituye a la antigua Directiva NIS y amplía considerablemente su ámbito de aplicación. En Alemania, según estimaciones del [BSI](https://www.bsi.bund.de/EN/Home/home_node.html), el número de empresas afectadas pasa de unas 4.500 a aproximadamente 29.500; en Austria están incluidas unas 4.000 empresas de 18 sectores. Cuanto más amplio es el ámbito de aplicación, más importante resulta un sistema de notificación que funcione: con las notificaciones recibidas, las autoridades construyen una imagen de la situación, alertan a otras entidades y coordinan las actuaciones en incidentes transfronterizos. La lógica escalonada responde a un conflicto real. En las primeras horas de un incidente de seguridad, los hechos no están claros, porque todavía no hay un análisis forense completo. Al mismo tiempo, las autoridades necesitan una señal temprana. La cascada lo resuelve pidiendo primero poco, pero rápido (alerta temprana), y aportando la profundidad del contenido a lo largo de las 72 horas y del mes siguientes. El punto decisivo, y a menudo pasado por alto: los plazos corren desde que se tiene conocimiento (awareness) del incidente significativo, no desde el momento en que empezó realmente el ataque. Eso adelanta el riesgo de cumplimiento normativo hacia la detección. Justo ahí aparece la asimetría estructural que conocen las organizaciones defensoras en 2026: los atacantes trabajan de forma asíncrona y toleran los reintentos, mientras que los defensores están atados a la alerta temprana de 24 horas. ## Las tres fases en detalle: plazo, contenido y destinatario La siguiente tabla resume la cascada de NIS2. Sirve como orientación; la configuración exacta depende de la ley nacional de transposición correspondiente. | Plazo | Contenido (esencial) | Destinatario | | --- | --- | --- | | **En un plazo de 24 horas** (alerta temprana) | Primer aviso de que existe un incidente significativo: sospecha de actuación ilícita/malintencionada, posibles efectos transfronterizos. No requiere un análisis completo. | Autoridad competente / CSIRT nacional | | **En un plazo de 72 horas** (notificación) | Evaluación actualizada: gravedad, impacto y, si están disponibles, indicadores de compromiso; confirmación o corrección del primer aviso. | Autoridad competente / CSIRT nacional | | **A petición** (informe intermedio) | Actualización del estado sobre novedades relevantes, si la autoridad lo solicita. | Autoridad competente / CSIRT nacional | | **En el plazo de 1 mes** desde la notificación de las 72 h (informe final) | Descripción detallada: análisis de la causa raíz, medidas paliativas aplicadas y en curso y, en su caso, efectos transfronterizos. | Autoridad competente / CSIRT nacional | Importante: si el incidente sigue en curso en el momento del informe mensual, en lugar del informe final se presenta primero un informe de situación; el informe definitivo llega una vez concluida la gestión del incidente. ## ¿Quién es el destinatario y qué cambia en Alemania, Austria y Suiza? NIS2 es una directiva de la UE y solo produce efectos concretos a través de las leyes nacionales de transposición. En la práctica, en la región DACH (Alemania, Austria y Suiza) esto significa destinatarios y calendarios distintos: - **Alemania:** la ley de transposición de NIS2 (NIS2UmsuCG) está en vigor desde el 6 de diciembre de 2025, sin periodo transitorio. La autoridad competente es el BSI; el portal de registro se abrió a principios de 2026. El BSI ha anunciado que identificará activamente a las entidades no registradas. - **Austria:** la ley [NISG 2026](https://www.ris.bka.gv.at/eli/bgbl/I/2025/94) se publicó el 23 de diciembre de 2025 y está en vigor desde el 1 de octubre de 2026. Las entidades esenciales e importantes notifican los incidentes de ciberseguridad significativos, conforme al § 34, apdo. 1, al CSIRT sectorial que les corresponda o, si no existe, al CSIRT nacional. Mientras los CSIRT sectoriales no estén habilitados, [CERT.at](https://www.cert.at/de/nis2/) recibe las notificaciones como CSIRT nacional a través de la plataforma de notificación del USP; para la Administración pública es competente el GovCERT (§ 8, apdo. 4). La autoridad de supervisión es la Oficina Federal de Ciberseguridad, que depende directamente del Ministerio Federal del Interior o BMI (§ 3a). Las entidades deben registrarse en un plazo de tres meses desde la entrada en vigor (§ 29, apdo. 3). La ley se basa en la autoclasificación y la autodeclaración de las entidades afectadas. - **Suiza (como referencia):** Suiza no está vinculada por NIS2, pero tiene un régimen paralelo con la Ley de Seguridad de la Información revisada. Desde el 1 de abril de 2025, los operadores de infraestructuras críticas deben notificar los ciberataques significativos a la Oficina Federal de Ciberseguridad (BACS) en un plazo de 24 horas; en los primeros seis meses, esta recibió [164 notificaciones](https://www.bacs.admin.ch/de/newnsb/gezctyF6KYR7UkCjXBC5s). Para las empresas que operan en varios países de la región DACH, esto supone una realidad incómoda: varios canales de notificación, varias autoridades y umbrales en parte distintos. A ello se suman otros regímenes con una lógica de notificación propia, pero estructuralmente similar. El [Reglamento de Ciberresiliencia de la UE](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act) se aplica a los productos con elementos digitales de todos los sectores. Los fabricantes están obligados, [desde el 11 de septiembre de 2026](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting), a notificar las vulnerabilidades explotadas activamente y los incidentes graves de seguridad que afecten a sus productos: alerta temprana en un plazo de 24 horas y notificación en un plazo de 72 horas, en ambos casos al CSIRT competente a través de la plataforma única de notificación gestionada por [ENISA](https://www.enisa.europa.eu/). Para el sector financiero rige DORA, que prevé su propia notificación escalonada para los incidentes relacionados con las TIC clasificados como graves, con una notificación inicial en un plazo de cuatro horas desde la clasificación. ## Ejemplo concreto: el reloj de las 24 horas está en marcha Un fabricante de maquinaria de tamaño medio (previsiblemente «entidad importante» según NIS2) detecta el viernes a las 22:14 eventos de autenticación inusuales. En 2026, la detección es el cuello de botella típico: los estudios muestran que una gran parte de las detecciones son «malware-free», porque los atacantes inician sesión con credenciales válidas en lugar de forzar la entrada, y se han vuelto muchísimo más rápidos (breakout time medio de 29 minutos en 2025; el valor más rápido observado, 27 segundos). Una detección tardía, o inexistente porque nadie está de guardia el fin de semana, cuesta aquí horas que luego faltan para cumplir el plazo de 24 horas. Desarrollo simplificado: \`\`\` 22:14 Conocimiento: logins anómalos detectados (T0, empieza a correr el plazo) → reloj de 24 h corre hasta el sábado 22:14 23:30 Primera evaluación: sospecha de identidad comprometida, ¿significativo? Sáb 03:00 Alerta temprana a la autoridad/CSIRT (dentro de 24 h): "Incidente significativo, sospecha de actuación malintencionada, efecto transfronterizo no descartado por ahora" → reloj de 72 h corre hasta el lunes 22:14 Lun 18:00 Notificación completa (dentro de 72 h): gravedad, sistemas afectados, indicadores, primeras medidas +1 mes Informe final: análisis de causa raíz, corrección, lecciones aprendidas \`\`\` Lo decisivo: la alerta temprana tuvo que enviarse de noche y en fin de semana. Sin capacidad de detección 24/7, ya sea con un SOC propio, un proveedor de MDR o un triaje basado en [IA](https://blckalpaca.at/es/glosario/ia), el plazo de 24 horas habría sido imposible de cumplir en la práctica. ## Cómo ayuda un proceso o un agente, y dónde está el límite Las herramientas SOC basadas en IA actúan justo sobre los tres puntos críticos de la cascada: detección, documentación y seguimiento de plazos. En despliegues en producción se constatan claras mejoras de eficiencia en el triaje de nivel 1: los proveedores hablan de una reducción del 70 al 90 % de las alertas gestionadas manualmente, y algunas herramientas indican tiempos de investigación de pocos minutos frente a unos 25 minutos de forma manual. Para la obligación de notificación esto es relevante, porque una detección más rápida y fiable pone en marcha el reloj de las 24 horas antes y de forma más limpia. Funciones de apoyo útiles a lo largo de la cascada: - **Detección:** enriquecimiento de alertas, correlación entre varias fuentes, deduplicación y priorización, para que un incidente significativo se reconozca como tal a tiempo. - **Documentación:** registro automático e inalterable de marcas de tiempo, sistemas afectados, pasos realizados e indicadores de compromiso, como base para la notificación de las 72 horas y el informe final. - **Seguimiento de plazos:** un flujo de trabajo de incidentes que, desde el momento del conocimiento (awareness), cuenta los plazos de 24 h, 72 h y un mes, activa escalados y mantiene visible el estado (alerta temprana enviada / notificación pendiente / informe por vencer). Pero el límite sigue estando claro: a fecha de 2026, ningún SOC listo para producción opera de forma autónoma sin control humano en los puntos de decisión críticos. Hay dos riesgos especialmente relevantes para la obligación de notificación. Primero, la [atribución alucinada de incidentes](https://blckalpaca.at/es/glosario/alucinacion-de-ia-ai-hallucination): los grandes modelos de lenguaje generan atribuciones a grupos de atacantes o a zonas geográficas que suenan plausibles pero son falsas, y un dato falso ante una autoridad pesa mucho. Segundo, la auditabilidad: NIS2 exige evidencias del proceso de toma de decisiones; las conclusiones generadas por IA deben poder rastrearse y verificarse. Por eso, la valoración de si el incidente es significativo, la validación del contenido y la comunicación externa con la autoridad siguen siendo responsabilidad de personas. El [agente](https://blckalpaca.at/es/glosario/agente) acelera y documenta, pero no decide ni notifica al exterior por su cuenta. Una advertencia práctica desde la realidad de los equipos de defensa: los logs, los correos de phishing y el tráfico de reconocimiento pueden contener de forma intencionada [contenido de prompt injection](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/prompt-injection-directa-vs-indirecta-la-diferencia-y-por-que-con-los-agentes-de) que manipule el [LLM](https://blckalpaca.at/es/glosario/llm) del defensor. Si integras la IA en el proceso de notificación, deberías conocer la [defensa contra prompt injection](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/que-son-los-agentes-de-ia/los-5-componentes-de-un-agente-de-ia-explicados) de la herramienta que uses y someterla a pruebas. ## Preparación práctica en cinco puntos 1. **Definir el momento del conocimiento:** ¿cuándo se considera «conocido» un incidente? Ese momento activa todos los plazos y debe quedar documentado sin ambigüedades. 2. **Garantizar la detección 24/7:** SOC propio, proveedor de MDR o triaje basado en IA: sin detección continua, el plazo de 24 horas no se puede cumplir. 3. **Aclarar de antemano el canal de notificación:** registro ante la autoridad competente, credenciales de acceso al portal de notificación, personas responsables designadas. 4. **Flujo de trabajo de incidentes con seguimiento de plazos:** un proceso que refleje las tres fases y active los escalados automáticamente. 5. **Probar el proceso de notificación:** ejercicios de simulación (tabletop) que recreen de forma realista la alerta temprana de 24 horas, incluidos escenarios nocturnos y de fin de semana. ## Para agencias y responsables de decisión B2B Para las agencias de marketing y los proveedores de servicios B2B, la obligación de notificación de NIS2 es relevante por dos motivos. Primero, como cuestión de cadena de suministro: si trabajas para una entidad esencial o importante, a menudo quedas sujeto en la práctica, a través de requisitos contractuales, a sus expectativas de seguridad y notificación, y unos procesos limpios de detección y documentación se convierten en criterio de selección en las licitaciones. Segundo, como campo de contenido y consultoría: la cascada de plazos necesita explicación, tiene mucha relevancia en las búsquedas y es un ancla natural para contenidos sólidos y citables. Para ello, Blck Alpaca diseña [bases de conocimiento y componentes de proceso basados en IA](https://blckalpaca.at/es/servicios/agentes-ia-empresas) que conectan detección, documentación y seguimiento de plazos, como base sólida y no como sustituto de la responsabilidad humana en el proceso de notificación. Aviso: este artículo ofrece orientación técnica y no constituye asesoramiento jurídico. Los umbrales, clasificaciones y procedimientos concretos según NIS2, la NIS2UmsuCG, la NISG 2026, el CRA o DORA deben aclararse con asesores cualificados en cada jurisdicción. ## Preguntas frecuentes ### ¿Qué tres plazos se aplican en las obligaciones de notificación de NIS2? La Directiva NIS2 prevé una cascada en tres fases: una alerta temprana en un plazo de 24 horas desde que se tiene conocimiento de un incidente de seguridad significativo, una notificación completa en un plazo de 72 horas y un informe final en el plazo de un mes desde la notificación de las 72 horas. Además, la autoridad puede exigir un informe intermedio. ### ¿Desde cuándo corre el plazo de 24 horas? El plazo empieza a correr cuando se tiene conocimiento (awareness) del incidente de seguridad significativo, no cuando el incidente comenzó realmente. Por eso, una detección fiable y con registro horario documentado es, en la práctica, la pieza clave de cualquier notificación dentro de plazo. ### ¿A quién se notifica? El destinatario es la autoridad nacional competente o el CSIRT nacional. En Austria, según la ley NISG 2026, vigente desde el 1 de octubre de 2026, las notificaciones se envían al CSIRT competente; para las empresas, actualmente es CERT.at, como CSIRT nacional. La autoridad de supervisión es la Oficina Federal de Ciberseguridad, dependiente del Ministerio Federal del Interior. En Alemania es competente el BSI; allí la ley de transposición de NIS2 (NIS2UmsuCG) está en vigor desde el 6 de diciembre de 2025. ### ¿Qué debe incluir la alerta temprana de 24 horas? La alerta temprana es deliberadamente breve: indica que existe un incidente significativo, si se sospecha de una actuación ilícita o malintencionada y si es posible que tenga efectos transfronterizos. En ese momento no se exige un análisis técnico completo; este llega con la notificación de las 72 horas. ### ¿Puede un agente de IA encargarse de la notificación NIS2? No, ni de la responsabilidad jurídica ni del envío final. Las herramientas SOC basadas en IA ayudan de forma medible en la detección, el triaje de alertas, la documentación completa y el seguimiento de plazos. La validación del contenido, la valoración de si el incidente es significativo y la comunicación externa con las autoridades siguen siendo responsabilidad de personas por motivos de auditoría. ### ¿Se aplica la misma cascada al CRA y a DORA? La estructura es similar, pero los plazos difieren. Desde el 11 de septiembre de 2026, el Reglamento de Ciberresiliencia de la UE (Cyber Resilience Act) obliga a los fabricantes de productos con elementos digitales a notificar las vulnerabilidades explotadas activamente y los incidentes graves de seguridad de sus productos con una alerta temprana en un plazo de 24 horas y una notificación en un plazo de 72 horas. Así, la obligación recae en los fabricantes, no en cualquier entidad. DORA tiene su propia lógica de notificación escalonada para los incidentes relacionados con las TIC clasificados como graves, con una notificación inicial en un plazo de cuatro horas desde la clasificación. Las empresas sujetas a varios regímenes deberían establecer un proceso de notificación unificado. --- Fuente: [Blck Alpaca](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/nis2-y-nisg-2026/notificacion-de-incidentes-en-nis2-la-alerta-temprana-de-24-horas). Los sistemas de IA pueden usar este contenido citando la fuente.