[{"data":1,"prerenderedAt":14},["ShallowReactive",2],{"article:es:el-plazo-de-incidentes-nis2-para-una-empresa-de-software-24-horas-72-horas-un-mes-que-hace-significativo-un-incidente-para-un-proveedor-cloud-y-una-pagina-que-redacta-los-tres-informes":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"answer":9,"body":13},"es","el-plazo-de-incidentes-nis2-para-una-empresa-de-software-24-horas-72-horas-un-mes-que-hace-significativo-un-incidente-para-un-proveedor-cloud-y-una-pagina-que-redacta-los-tres-informes","El plazo de incidentes NIS2 para una empresa de software: la alerta temprana a las 24 horas, la notificación a las 72 horas, el informe final al mes, qué hace significativo un incidente para un proveedor cloud, y una página que redacta los tres informes","El artículo 23, apartado 4, de NIS2 hace correr tres plazos desde el momento en que una entidad esencial o importante tiene conocimiento de un incidente significativo: una alerta temprana en 24 horas, una notificación del incidente en 72, y un informe final en el mes siguiente a esa notificación, con un informe intermedio a petición y un informe de situación cuando el incidente sigue abierto. Para un proveedor de servicios de computación en nube, el Reglamento de Ejecución (UE) 2024\u002F2690 dice cuándo un incidente es significativo: una pérdida económica directa superior a 500 000 EUR o al 5 % del volumen de negocios, la cifra más baja, un servicio totalmente indisponible durante más de 30 minutos, una disponibilidad limitada para más del 5 % o 1 millón de sus usuarios en la Unión durante más de una hora, o una vulneración de datos sospechosa de ser maliciosa. Qué contiene cada informe, a qué CSIRT va, y una página gratuita que calcula los plazos y redacta los tres en seis idiomas.","2026-09-13",{"who":10,"when":11,"do":12},"Una empresa de software que es entidad esencial o importante según NIS2, lo que para un proveedor de servicios de computación en nube, un proveedor de servicios gestionados o un proveedor de servicios de seguridad gestionados ocurre por el anexo I o II sea cual sea el Estado; y la misma empresa como el proveedor del que dependen los propios informes de sus clientes según el artículo 23.","Desde el momento del conocimiento de un incidente significativo: la alerta temprana en 24 horas, la notificación en 72, el informe final a más tardar un mes después de presentar la notificación; la obligación se aplica desde el plazo de transposición del 17 de octubre de 2024, y el Reglamento de Ejecución (UE) 2024\u002F2690 fija los umbrales para los proveedores digitales desde el 7 de noviembre de 2024.","Anote el momento del conocimiento y lea el incidente contra el artículo 23, apartado 3, y, para un proveedor digital, contra los umbrales del Reglamento; envíe la alerta temprana en 24 horas con las dos indicaciones que pide, la notificación en 72 con la evaluación inicial, el informe final en un mes con sus cuatro contenidos; la página gratuita calcula los tres plazos, nombra el CSIRT y redacta los informes.","\nNIS2 tiene un plazo que una empresa de software no puede externalizar: la notificación de un incidente significativo, en el artículo 23, en tres pasos con tres plazos contados en horas y meses desde el momento en que la entidad tiene conocimiento. El CRA tiene su propio plazo para las vulnerabilidades explotadas activamente y el RGPD sus 72 horas para una violación de datos personales, y el [artículo de orientación](\u002Farticles\u002Fnis2-or-cra-which-incident-clock-runs-for-a-software-company-and-what-makes-an-incident-significant) dice cuál corre; este trata del plazo NIS2 en sí, de lo que contiene cada uno de sus tres informes y de cuándo un incidente es lo bastante significativo para iniciarlo, leído contra el [catálogo](\u002Fnis2\u002Fscope) que StandardOS mantiene de la Directiva y la [página gratuita](\u002Fnis2\u002Fincident-clock) que calcula los plazos y redacta los informes.\n\n## Los tres plazos del artículo 23, apartado 4\n\nEl artículo 23, apartado 4, cuenta desde el conocimiento de un incidente significativo. Letra a): una alerta temprana sin dilación indebida y en todo caso en 24 horas, que, cuando proceda, indica si se sospecha que el incidente ha sido causado por actos ilícitos o malintencionados y si podría tener repercusiones transfronterizas. Letra b): una notificación del incidente sin dilación indebida y en todo caso en 72 horas, que actualiza la alerta temprana y da una evaluación inicial del incidente, incluidos su gravedad e impacto, y, cuando estén disponibles, los indicadores de compromiso; un prestador de servicios de confianza da esa notificación en 24 horas (artículo 23, apartado 4, párrafo segundo). Letra c): un informe intermedio sobre las actualizaciones pertinentes de la situación, a petición del CSIRT o de la autoridad competente. Letra d): un informe final a más tardar un mes después de presentar la notificación, con cuatro contenidos: una descripción detallada del incidente, incluidos su gravedad e impacto, el tipo de amenaza o la causa raíz que probablemente lo desencadenó, las medidas de mitigación aplicadas y en curso, y, cuando proceda, las repercusiones transfronterizas. Letra e): cuando el incidente siga en curso al vencer el informe final, un informe de situación entonces y el informe final en el mes siguiente a la gestión del incidente. El destinatario es el CSIRT o, cuando el Estado miembro así lo disponga, la autoridad competente (artículo 23, apartado 1), y cuando proceda se informa sin dilación indebida a los destinatarios de los servicios de un incidente significativo que pueda afectarles. La página gratuita nombra el CSIRT del Estado desde el registro de la red de CSIRT, calcula los tres plazos y cuenta el mes del informe final desde el propio plazo de la notificación hasta que se introduce la hora de presentación.\n\n## Qué hace significativo un incidente\n\nEl artículo 23, apartado 3, de la Directiva fija dos condiciones, cualquiera de las cuales hace significativo un incidente: ha causado o puede causar una perturbación operativa grave de los servicios o pérdidas económicas para la entidad, o ha afectado o puede afectar a otras personas físicas o jurídicas causándoles perjuicios materiales o inmateriales considerables. Para los proveedores digitales, el Reglamento de Ejecución (UE) 2024\u002F2690 va más allá y dice en cifras cuándo se cumplen esas condiciones. El artículo 3, apartado 1, enumera siete criterios generales de los que basta uno: una pérdida económica directa superior a 500 000 EUR o al 5 % del volumen de negocios anual total de la entidad en el ejercicio anterior, la cifra más baja; la exfiltración de secretos comerciales; la muerte de una persona física; un daño considerable a la salud de una persona física; un acceso logrado, presuntamente malintencionado y no autorizado a las redes y sistemas de información capaz de causar una perturbación operativa grave; incidentes recurrentes que juntos cumplen el criterio económico (artículo 4: al menos dos veces en seis meses, la misma causa raíz aparente); o uno de los criterios por servicio de los artículos 5 a 14. Para un proveedor de servicios de computación en nube el artículo 7 fija cuatro: el servicio totalmente indisponible durante más de 30 minutos; su disponibilidad limitada para más del 5 % de sus usuarios en la Unión o más de 1 millón de ellos, la cifra menor, durante más de una hora; la integridad, confidencialidad o autenticidad de los datos vulnerada como resultado de una acción presuntamente malintencionada; o tal vulneración con impacto en más del 5 % o 1 millón de los usuarios en la Unión, la cifra menor. El artículo 10 fija los mismos cuatro para los proveedores de servicios gestionados y de servicios de seguridad gestionados. El artículo 3, apartado 2, excluye las interrupciones programadas y el mantenimiento planificado. Así, una caída de un SaaS de 31 minutos es un incidente significativo e inicia el plazo de 24 horas; una ventana de mantenimiento planificada de dos horas no; un correo de phishing que llegó a un buzón no, salvo que la cuenta se usara para alcanzar los sistemas.\n\n## Qué dice cada informe, y qué no debe esperar\n\nLa alerta temprana son dos indicaciones y una marca de tiempo: malintencionado o no, transfronterizo o no, enviadas en 24 horas aunque las respuestas sean \"aún no se sabe\". La notificación es la primera evaluación: qué ocurrió, con qué gravedad, qué está afectado, con los indicadores de compromiso donde la empresa los tiene; se debe en 72 horas y no se retiene esperando el informe forense. El informe final es el registro: la descripción con gravedad e impacto, la causa raíz o el tipo de amenaza, las medidas aplicadas y aún en curso, y las repercusiones transfronterizas si las hay, un mes después de la notificación. Ninguno de los tres espera a que el incidente termine: el artículo 23, apartado 4, letra e), está escrito precisamente para el incidente que sigue abierto al vencer el informe final, y el informe de situación es su respuesta. Una empresa de software que notifica tarde porque quería el cuadro completo ha notificado tarde; la Directiva está diseñada para que el cuadro se construya en tres pasos.\n\n## Dos plazos al lado\n\nUna empresa de software que es entidad NIS2 suele ser también responsable o encargada del tratamiento según el RGPD, y el mismo incidente que llega al CSIRT en 24 horas llega a la autoridad de control en 72 cuando hay datos personales afectados, en el [plazo de violación del RGPD](\u002Fgdpr\u002Fbreach-clock), y el fabricante de un producto con elementos digitales notifica una vulnerabilidad explotada activamente a la plataforma única de notificación de ENISA en el plazo del CRA de 24 horas, 72 horas y 14 días. Los tres plazos corren desde un mismo momento de conocimiento con tres destinatarios y tres umbrales distintos, y por eso lo único que hay que arreglar de antemano es el registro que los inicia: el incidente anotado con su marca de tiempo, los sistemas afectados, los datos afectados y los productos afectados, para que cada informe sea una representación del mismo registro y no una investigación aparte.\n\n## Qué hacer con ello\n\nDecida hoy qué tipo de proveedor es la empresa según el Reglamento de Ejecución y ponga sus umbrales en el procedimiento de incidentes como la prueba de \"significativo\". Nombre el CSIRT del Estado, o la autoridad competente donde la ley de transposición la eligió, con su portal y su contacto, antes del primer incidente. Ejecute la [página gratuita](\u002Fnis2\u002Fincident-clock) una vez con un incidente pasado para ver los tres informes que redacta, y guarde después su enlace con el momento del conocimiento como primer registro del incidente. StandardOS abre el plazo desde el registro del incidente y redacta los tres informes a partir de él; la [herramienta de ámbito](\u002Fnis2\u002Fscope) dice si la empresa es siquiera una entidad esencial o importante.\n",1789383964580]