Notificación de incidentes NIS2 en WordPress: 24 horas, 72 horas, un mes
El artículo 23 de la Directiva 2022/2555 establece cómo funciona en la práctica la notificación de incidentes. El artículo 21 cubre la gestión continua de riesgos; el artículo 23, la notificación de un incidente significativo. Las tres fases cuentan desde el momento en que la entidad tuvo conocimiento de un incidente significativo. Una alerta en bruto no es automáticamente un incidente notificable.
Este es un artículo de apoyo dentro del pilar NIS2 y DORA para WordPress.
Resumen
- El reloj empieza cuando se tiene conocimiento de un incidente significativo, no cuando termina el análisis de la causa.
- 24 horas: alerta temprana, presunta causa maliciosa, indicador transfronterizo.
- 72 horas: notificación completa con evaluación inicial e indicadores.
- Un mes: informe final con tipo de amenaza, medidas de mitigación e impacto transfronterizo.
- No toda alerta ni todo incidente de WordPress es notificable; hay que evaluar la significatividad y dejar constancia de la decisión.
Desde cuándo cuenta el plazo de notificación NIS2
La pregunta clave es cuándo tuvo la entidad conocimiento del incidente significativo. Que salte una alerta técnica no lo decide por sí solo. Aun así, la organización no puede aplazar a su antojo el momento del conocimiento con una cola sin atender o sin una vía de escalado.
En un sitio WordPress, esto suele significar:
- Una herramienta de monitorización (Wordfence, Sucuri, IDS del hosting, alerta de Cloudflare, pico de errores en Sentry) marca una anomalía.
- El ingeniero de guardia clasifica la alerta y evalúa el alcance.
- Si la evaluación supera el umbral de significatividad del artículo 23, apartado 3, se registra el momento en que se tuvo conocimiento del incidente y el plazo se calcula desde ahí.
El error que hay que evitar: un perfil júnior clasifica una oleada de credential stuffing a las 23:50, la despacha como “ruido normal” y la deja para la mañana. Si esa oleada era en realidad una filtración de credenciales con acceso confirmado a una cuenta, el reloj de 24 horas corre desde las 23:50. El regulador lo reconstruirá a partir de los registros.
¿Qué incluye la alerta temprana NIS2 en 24 horas?
Contenido exigido por el artículo 23, apartado 4, letra a):
- Si se sospecha que el incidente se debe a un acto ilícito o malicioso.
- Si el incidente puede tener impacto transfronterizo.
Es breve. La alerta temprana no es un análisis de causa, es una señal. El CSIRT o la autoridad competente necesita saber que está ocurriendo algo significativo; los detalles van en la notificación de 72 horas.
El papel de la agencia WordPress dentro de las 24 horas:
- Confirmar el alcance del incidente a partir de registros, alertas y análisis forense del panel de administración.
- Entregar al equipo de cumplimiento del cliente un borrador de una página de la alerta temprana, con el nombre del servicio afectado, la categoría sospechada (maliciosa u operativa) y el elemento transfronterizo (sitio multilingüe, clientela en toda Europa).
- Preservar las pruebas: registros del servidor, cronología de actualizaciones de plugins, historial de accesos de administración, registro de auditoría del hosting. Una instantánea de la base de datos, si es viable.
- Detener la hemorragia: rotación de credenciales, bloqueo de IP, aislamiento de plugins sospechosos, modo de solo lectura cuando el incidente afecta al checkout o a los pagos.
La alerta temprana no debe incluir especulaciones sobre la atribución. “Sospecha de origen malicioso” basta; ponerle nombre al actor es trabajo de especialistas forenses.
Qué incluye la notificación de incidente NIS2 a las 72 horas
Contenido exigido por el artículo 23, apartado 4, letra b):
- Una evaluación inicial del incidente, incluidas su gravedad y su impacto.
- Indicadores de compromiso, cuando estén disponibles.
El lenguaje de la gravedad importa. ENISA trabaja con tres niveles: bajo, medio y alto. Un incidente de WordPress que dejó el sitio fuera de línea menos de una hora sin fuga de datos es, como mucho, medio. Una filtración de credenciales confirmada con acceso a cuentas de clientes es alto. Un defacement de un sitio de marketing sin acceso adicional es bajo o medio.
La entrega de la agencia dentro de las 72 horas:
- Una cronología escrita del incidente con marcas de tiempo tomadas de los registros.
- Una evaluación de si se vieron afectados datos de clientes, datos de pago o datos de sesión.
- Indicadores de compromiso: IP de origen, user agents, hashes de archivos en caso de malware, archivos de plugins o del tema modificados, cuentas de administración sospechosas creadas durante el incidente.
- Una primera lista de medidas adoptadas: credenciales rotadas, plugin eliminado o actualizado, regla de WAF añadida, auditoría de cuentas de administración.
Aquí es donde la mayoría de los incidentes de WordPress recibe su nombre en los archivos del regulador. La notificación de 72 horas se compara después con el informe final.
Qué debe contener el informe final NIS2
Contenido exigido por el artículo 23, apartado 4, letra c):
- Una descripción detallada del incidente, su gravedad y su impacto.
- El tipo de amenaza o la causa raíz.
- Las medidas de mitigación aplicadas y en curso.
- El impacto transfronterizo, cuando proceda.
Antes de que acabe el mes, la agencia WordPress debería tener:
- Un análisis completo de la causa raíz. ¿Un plugin vulnerable? ¿Una filtración de credenciales? ¿Una mala configuración del servidor? ¿Un administrador comprometido por phishing?
- Pruebas de que la corrección inmediata funciona y es estable. Regla de WAF desplegada, plugin actualizado en producción, credenciales rotadas, MFA obligatorio, monitorización ajustada.
- Una lista de medidas a largo plazo. Actualización de la política de plugins, eliminación de dependencias sin mantenimiento, auditoría periódica de credenciales, formación de los editores que pueden ser vector de phishing.
- Un párrafo de confirmación que el cliente pueda trasladar al regulador.
Si el incidente sigue en curso cuando vence el informe final, el artículo 23, apartado 4, letra d), prevé un informe de situación y, después, un informe final en el plazo de un mes desde que se termina de gestionar el incidente. Si nuevas pruebas cambian la evaluación, el responsable de la notificación debe documentar el cambio y acordar los pasos siguientes con la autoridad competente; la directiva no describe una notificación independiente “sin medidas”.
¿Qué documentos de respuesta a incidentes necesita una agencia WordPress?
Seis artefactos que todo contrato WordPress regulado debería tener antes del primer incidente:
- Runbook de respuesta a incidentes con responsable designado, vía de escalado y plantillas para 24/72/30 días.
- Lista de contactos del CSIRT y de las autoridades para la jurisdicción del cliente y las jurisdicciones transfronterizas relevantes.
- Plantilla de comunicación para los clientes afectados cuando se confirma el acceso a datos.
- Política de preservación de pruebas: retención de registros, integridad de las copias de seguridad, notas de cadena de custodia.
- Biblioteca de lenguaje de notificación: formulaciones aprobadas de antemano para “sospecha de origen malicioso”, “sin exposición de datos de clientes”, “vulnerabilidad corregida”, “monitorización ajustada”. Ahorra 30 minutos dentro de la ventana de 24 horas.
- Calendario de simulacros: como mínimo un ejercicio de mesa por trimestre que recorra 24/72/30 sin un incidente real.
Esta caja de herramientas marca la diferencia entre una ventana de 24 horas que produce una alerta temprana tranquila de una página y otra que produce una llamada de pánico al departamento jurídico a las 03:00.
Cuándo un incidente es significativo según NIS2
Los tres niveles deberían tener entradas separadas. Un evento es un hecho observable, por ejemplo una serie de accesos fallidos, el disparo de una regla de WAF o un despliegue fallido. Un incidente compromete o puede comprometer la disponibilidad, la autenticidad, la integridad o la confidencialidad de datos o servicios. Para valorar la significatividad, el artículo 23, apartado 3, menciona, entre otros, una perturbación operativa grave o pérdidas financieras para la entidad y daños materiales o inmateriales considerables a otras personas.
El equipo de WordPress aporta los hechos. El responsable autorizado de la entidad toma la decisión jurídica y regulatoria. El registro de decisiones debería mostrar la primera alerta creíble, el momento en que la persona responsable tuvo conocimiento de ella, el impacto conocido en el servicio y en los clientes, las pruebas disponibles, la evaluación de significatividad, quién la aprobó y la próxima fecha de revisión. Se registran tanto la decisión de notificar como la decisión motivada de no hacerlo.
Un sitio multilingüe, usuarios en la UE o la sospecha de actividad maliciosa no prueban por sí solos la significatividad. Por otro lado, un compromiso aparentemente pequeño de un plugin puede ser significativo si interrumpe el servicio de la entidad o afecta a muchas cuentas de clientes. La transposición nacional, las orientaciones de la autoridad y el contexto sectorial pueden concretar el umbral, así que la vía correcta la confirma el departamento jurídico o de cumplimiento del cliente.
Qué pruebas necesita cada fase de la notificación NIS2
La alerta temprana necesita un identificador fijo, el nombre de la entidad y del servicio, el momento en que se tuvo conocimiento del incidente, la base actual de la significatividad, la sospecha de causa ilícita o maliciosa y el posible impacto transfronterizo. La incertidumbre se indica abiertamente. “En investigación” es mejor que una atribución sin pruebas.
Hasta las 72 horas se reúnen la cronología, los entornos y funciones afectados, la duración observada, el impacto en clientes y operaciones, los posibles tipos de datos, los indicadores de compromiso, el aislamiento realizado y la exposición actual. Cada hecho recibe el estado de confirmado, inferido o desconocido. La cronología principal usa UTC y conserva la zona horaria original junto a cada fuente.
El informe final añade el análisis de causa desarrollado, la gravedad y el impacto, el tipo de amenaza si se conoce, las medidas ejecutadas y previstas y los posibles efectos transfronterizos. Cada afirmación se vincula a un registro, un ticket, un cambio, una nota de investigación o una decisión identificada. Los originales de las pruebas se mantienen, en la medida de lo posible, en solo lectura, y la recogida, la exportación y la entrega quedan registradas. Este rastro aporta reproducibilidad, pero no significa que toda agencia haga informática forense formal.
Quién notifica el incidente NIS2 y quién responde de qué
El proveedor de monitorización o de hosting comunica la alerta y conserva los datos técnicos. Quien responde por WordPress limita el impacto en la aplicación y construye la cronología de los hechos. El incident commander vela por la coordinación, para que la corrección no destruya pruebas. El responsable del servicio evalúa el impacto operativo. El equipo de seguridad o de investigación dirige el análisis. El departamento jurídico, de cumplimiento o el enlace regulatorio decide el canal y envía la notificación. Comunicación gestiona los mensajes a clientes y al público, si hacen falta.
Cada función necesita un responsable y un suplente. Los contratos con proveedores fijan los contactos, el escalado fuera del horario laboral y el plazo de entrega de los registros. Un traspaso solo está completo cuando se confirma la recepción, se adjuntan los hechos y las incógnitas y se indica el siguiente plazo. La agencia no debería notificar a la autoridad en nombre del cliente sin un mandato inequívoco y un procedimiento acordado.
¿Cómo hacer un ejercicio de mesa de notificación de incidentes NIS2?
Un buen ejercicio de mesa empieza con una alerta ambigua, no con una intrusión confirmada. El equipo registra el momento del conocimiento, evalúa la significatividad, pide al proveedor las pruebas que faltan, prepara la alerta temprana y la actualiza para la fase de 72 horas. Más adelante aparece información nueva, por ejemplo una cuenta de cliente comprometida o un subcontratista en otro Estado. También conviene ensayar un informe de situación para un incidente que sigue activo pasado un mes.
Tras el ejercicio se mide el tiempo de clasificación, de decisión, de preservación de pruebas, de traspaso al área jurídica y de preparación del borrador. Los registros que faltan, los contactos desactualizados, un portal de la autoridad no disponible y los relojes contradictorios pasan a una lista de acciones con responsable y plazo. Después se vuelve a probar el traspaso que falló. La frecuencia de los ejercicios se deriva de la evaluación de riesgos de la entidad; un ritmo trimestral no es un requisito universal de la directiva.
¿Cómo revisar la notificación NIS2 antes de enviarla?
Cada borrador debería pasar una revisión breve a cargo de dos personas, sin bloquear el plazo. La persona técnica comprueba la cronología, los nombres de los sistemas, los indicadores y el estado del aislamiento. El responsable del servicio verifica el impacto operativo y en los clientes. El responsable de la notificación confirma el destinatario, la base, la decisión sobre la significatividad y la aprobación. La atribución, el volumen de datos y el alcance geográfico solo se presentan como confirmados cuando hay pruebas.
El número de versión, la hora de aprobación y el contenido efectivamente enviado se guardan en el expediente del incidente. Los adjuntos se revisan en busca de datos sensibles y secretos innecesarios. El acuse de recibo del portal o de la autoridad se archiva con la versión enviada. Las preguntas posteriores conservan el mismo identificador y alimentan la cronología común.
Que pueda hacer falta una corrección posterior no justifica retrasar la alerta temprana. Aun así, las afirmaciones anteriores no se sobrescriben sin dejar rastro. El registro muestra el cambio, el motivo y la nueva prueba. Un control de versiones riguroso permite actualizar la evaluación y, a la vez, conservar una imagen fiel de lo que se sabía en cada plazo.
Acceso no autorizado de administrador en WordPress y notificación NIS2
A las 09:10, el hosting comunica un acceso correcto de administrador de WordPress desde una red desconocida y, poco después, la instalación de un plugin. El equipo tiene un evento y una sospecha de seguridad creíble, pero todavía pocos datos para considerar el incidente significativo. La persona de guardia abre un único registro, preserva los registros del hosting y del sistema de identidades, bloquea la cuenta por la vía aprobada y pregunta al responsable del servicio por cambios en funciones disponibles para los clientes.
A las 09:35 se confirma que la cuenta pertenecía a un antiguo colaborador externo y que el plugin creó un endpoint de exportación no autorizado. El registro de exportación está incompleto. El incident commander anota los hechos nuevos, el momento de conocimiento más temprano que se puede defender y las preguntas: si se llamó al endpoint, qué registros eran accesibles, cuánto duró el acceso y si se usaron las mismas credenciales en otro entorno. Cumplimiento evalúa los criterios del artículo 23, apartado 3, por el impacto operativo y el daño posible. La mera presencia de código malicioso no se considera automáticamente el umbral de significatividad.
Si los registros del WAF y de la aplicación no muestran llamadas, ni interrupción del servicio, ni acceso fuera del entorno de pruebas, el responsable autorizado puede concluir, de forma motivada, que no se alcanzó el umbral. La monitorización continúa y queda registrada una evaluación paralela de protección de datos. Si más adelante aparecen peticiones en producción o cuentas de clientes, la decisión se reabre sin borrar la imagen anterior de las pruebas.
En la segunda variante, los registros confirman la llamada al endpoint en producción y una interrupción para los clientes durante el aislamiento. El equipo registra cuándo tuvo la entidad hechos suficientes para tener conocimiento de un incidente significativo, prepara la alerta temprana sin esperar a la atribución completa y mantiene el mismo registro de pruebas hasta la fase de 72 horas. El ejemplo muestra que el conocimiento es una decisión controlada basada en hechos, no una marca de tiempo elegida porque da un plazo cómodo.
¿Cómo documentar la cadena de custodia de los registros del incidente?
Cada entrega indica el identificador del incidente, el sistema de origen, el periodo cubierto, quién recogió los datos, la hora de recogida, la zona horaria original, la suma de integridad si se usa, el lugar de almacenamiento, las restricciones de acceso y el acuse de recibo. El destinatario anota además si el material basta para la decisión solicitada. Una captura de pantalla puede mostrar una alerta, pero para reconstruir el orden y el alcance suele hacer falta una exportación de registros o un registro del proveedor.
Si el proveedor no entrega los datos antes de una fase de notificación, el borrador describe qué se pidió, cuándo, a quién y cómo afecta la falta a la evaluación. Así, un registro ausente no se convierte en un supuesto oculto. La petición sigue abierta tras el envío, y un resultado relevante llega al responsable de la notificación, que decide si hay que actualizarla.
¿Cuándo está una empresa preparada para notificar incidentes NIS2?
La preparación puede darse por completada cuando existen una matriz de significatividad aprobada, responsables de decisión y suplentes, contactos actualizados de las autoridades, fuentes de prueba sincronizadas, plantillas probadas, una vía de escalado confirmada con el proveedor y un resultado de ejercicio fechado. Todas las fases usan el mismo identificador y la misma cronología, para no crear versiones de los hechos que compitan entre sí.
Este proceso no convierte cualquier incidente de seguridad en notificable, no toma por la entidad la decisión jurídica sobre la significatividad y no garantiza que la autoridad coincida con la evaluación inicial. Tampoco sustituye la evaluación paralela de una violación de datos personales conforme al RGPD ni las obligaciones sectoriales. Plazos y destinatarios distintos exigen vías de decisión coordinadas.
Para acotar una revisión de preparación, envíe un briefing por escrito con la entidad y el sector, las jurisdicciones, el papel de WordPress, las fuentes de monitorización, los proveedores, las funciones actuales ante incidentes, los canales de notificación y el historial de ejercicios. Una auditoría de cumplimiento UE para WordPress puede entonces ordenar el punto de decisión, las pruebas, los traspasos, las plantillas y el plan de ejercicios, sin presentar el resultado como una certificación jurídica.
¿Cómo proteger los registros de WordPress como prueba para NIS2?
El artículo 23 de NIS2 exige expresamente que el material enviado al CSIRT sea verificable y coherente en su cronología:
- Repositorios de registros inmutables (WORM): En un ataque avanzado, los atacantes intentan de inmediato borrar los archivos
access.loglocales y las tablas de la base de datos de WordPress. Enviar los eventos en tiempo real a un SIEM externo (por ejemplo Wazuh, Datadog o AWS CloudWatch) garantiza que los registros de autenticación y de llamadas a la API queden intactos. - Sumas de verificación criptográficas del material probatorio: Cada volcado de registros o copia de la base de datos que se entregue a los equipos de investigación debería llevar una suma SHA-256 calculada y anotada en el acta de entrega. Así se protege la organización frente a acusaciones de manipulación de datos.
Notificación NIS2 y notificación de la brecha a la autoridad de protección de datos
Cuando un incidente de ciberseguridad implica acceso no autorizado a datos personales:
- Plazos procesales distintos: El reloj de la alerta temprana NIS2 exige la primera notificación en 24 horas, mientras que el artículo 33 del RGPD prevé 72 horas para notificar la brecha a la autoridad de control de protección de datos (en Polonia, la UODO).
- Coherencia de las declaraciones ante los reguladores: Los equipos jurídico y técnico deben acordar juntos el contenido de ambos documentos. Declarar en el informe NIS2 una fuga de la base de datos de clientes y, al mismo tiempo, ocultar ese hecho a la autoridad de protección de datos expone a la dirección de la empresa a fuertes sanciones económicas y a responsabilidad personal.
¿Qué documentar antes de enviar el informe final NIS2?
Antes de la entrega formal del informe final (pasados 30 días), conviene reunir el paquete completo de documentación:
- Relación documentada de medidas correctivas: Un detalle de los tokens de sesión invalidados, las claves de autenticación (SALT) rotadas en
wp-config.phpy los scripts maliciosos eliminados. - Análisis de causa raíz (Root Cause Analysis): Un informe técnico independiente que explique el vector exacto de la intrusión (por ejemplo, una vulnerabilidad de SQL Injection en un plugin desactualizado o una filtración de credenciales en el equipo de un empleado).
- Acta de información a la dirección: Confirmación de que las conclusiones clave del incidente se han trasladado a la dirección de la empresa, lo que cumple directamente el requisito de responsabilidad personal de los órganos de dirección del artículo 20 de NIS2.
- Resumen: Un proceso maduro de respuesta a incidentes convierte una crisis de seguridad en una prueba de alta resiliencia operativa y de profesionalidad de toda la organización.
Una gestión rigurosa de la seguridad de la información y la supervisión continua de la infraestructura tecnológica aportan estabilidad al negocio y cumplimiento de normas europeas exigentes. La responsabilidad y la precisión protegen los activos y la reputación de la empresa en cada etapa.
La madurez en ciberseguridad es la base de un éxito duradero en el mercado europeo.
