Respuesta a incidentes en WordPress según NIS2: playbook de alerta temprana en 24 horas
El artículo 23 de la Directiva 2022/2555 comprime la primera fase de la respuesta a incidentes en tres plazos: 24 horas, 72 horas y un mes. El plazo de 24 horas pilla por sorpresa a quienes gestionan WordPress, porque empieza cuando se tiene conocimiento del incidente, no cuando se ha resuelto. Y en un sitio WordPress típico ese conocimiento llega antes por un mensaje de Slack que por un panel de SOC.
Este es un artículo de apoyo del pilar sobre NIS2 y DORA en WordPress.
TL;DR
- 24 horas desde el conocimiento: alerta temprana al CSIRT.
- 72 horas desde el conocimiento: notificación con evaluación inicial.
- 1 mes después de la notificación de las 72 horas: informe final con causa y corrección.
- El “conocimiento” es el detonante, no una alerta del SIEM.
- Seis señales de WordPress que para mí significan “el reloj corre”.
- Plantillas en los idiomas nacionales en este playbook.
Qué dice exactamente el artículo 23
El artículo 23, apartado 1, establece la obligación: notificar al CSIRT o a la autoridad competente todo incidente que tenga un impacto significativo en la prestación de los servicios. El artículo 23, apartado 3, define “significativo”: capaz de causar una perturbación operativa grave de los servicios o pérdidas económicas para la entidad, o perjuicios materiales o inmateriales a otras personas físicas o jurídicas.
El artículo 23, apartado 4, divide la línea temporal:
- (a) Sin demora indebida y, en todo caso, en un plazo de 24 horas desde que se tuvo conocimiento del incidente significativo: una alerta temprana que indique si se sospecha que el incidente tiene una causa ilícita o maliciosa y si puede tener efectos transfronterizos.
- (b) Sin demora indebida y, en todo caso, en un plazo de 72 horas: una notificación que actualice la alerta temprana e incluya una evaluación inicial de la gravedad, el impacto y los indicadores de compromiso.
- (c) A petición del CSIRT o de la autoridad competente: un informe intermedio sobre la situación.
- (d) A más tardar un mes después de la notificación de la letra b): un informe final con descripción detallada, tipo de amenaza o causa raíz, medidas correctoras aplicadas y posibles efectos transfronterizos.
El reloj empieza cuando se tiene conocimiento de un incidente significativo. La Directiva no define ese momento, y el considerando 102 solo repite los plazos. Este playbook registra el conocimiento cuando una persona cualificada de la entidad concluye con suficiente certeza que se ha producido un incidente significativo, y anota quién lo concluyó y con qué pruebas. Esto pesa mucho en WordPress, porque el conocimiento suele llegar por el correo de un cliente, un servicio externo de monitorización o un escáner de vulnerabilidades, no por un SOC interno.
Cuándo un incidente es significativo según el Reglamento de Ejecución 2024/2690
El artículo 23, apartado 3, de la Directiva da el criterio general. Para algunos tipos de entidad, la Comisión lo concretó. El Reglamento de Ejecución (UE) 2024/2690 se aplica a los proveedores de servicios de DNS, los registros de nombres de dominio de primer nivel, los proveedores de servicios de computación en nube, los proveedores de servicios de centros de datos, los proveedores de redes de distribución de contenidos, los proveedores de servicios gestionados, los proveedores de servicios de seguridad gestionados, los proveedores de mercados en línea, de motores de búsqueda en línea y de plataformas de servicios de redes sociales, y los prestadores de servicios de confianza (artículo 1). Una agencia WordPress que presta a sus clientes alojamiento, mantenimiento y monitorización puede entrar en la categoría de proveedor de servicios gestionados. Si entra o no depende de la clasificación según los anexos de la Directiva y el Derecho nacional, no de este playbook.
Para esas entidades, el artículo 3, apartado 1, del Reglamento considera significativo un incidente cuando se cumple al menos uno de estos criterios:
- 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, si esta cifra es inferior;
- la exfiltración de secretos comerciales en el sentido de la Directiva (UE) 2016/943;
- la muerte de una persona física o daños considerables para su salud;
- un acceso logrado, presuntamente malicioso y no autorizado a los sistemas de redes y de información, capaz de causar una perturbación operativa grave;
- los umbrales propios de cada tipo de entidad de los artículos 5 a 14.
Para los proveedores de servicios gestionados y de servicios de seguridad gestionados, el artículo 10 fija esos umbrales: el servicio está totalmente indisponible durante más de 30 minutos; la disponibilidad está limitada para más del 5 % de sus usuarios en la Unión, o para más de 1 millón de usuarios si esta cifra es menor, durante más de una hora; o la integridad, la confidencialidad o la autenticidad de los datos relacionados con el servicio se ven comprometidas por una acción presuntamente maliciosa, o con un impacto en más del 5 % de los usuarios o en más de 1 millón de usuarios si esta cifra es menor.
Dos reglas cambian el triaje en un parque WordPress. El artículo 3, apartado 2, excluye las interrupciones programadas del servicio y las consecuencias previstas del mantenimiento programado, así que una ventana de mantenimiento anunciada no es un incidente significativo según este criterio. El artículo 4 añade los incidentes recurrentes: los incidentes que por separado no son significativos se consideran en conjunto un único incidente significativo cuando se han producido al menos dos veces en seis meses, tienen la misma causa aparente y en conjunto cumplen el criterio de pérdida económica. El punto 3.4.2, letra b), del anexo pide revisar trimestralmente si existen incidentes recurrentes. En WordPress, la reinfección repetida por el mismo plugin sin parchear es el patrón que esa revisión debe detectar.
Las entidades que no figuran en el artículo 1 siguen aplicando el criterio del artículo 23, apartado 3, tal como se haya transpuesto al Derecho nacional.
Cómo reconocer una intrusión en un sitio WordPress
Estos hallazgos obligan a abrir un registro y valorar de inmediato si el incidente es significativo. No ponen en marcha automáticamente el plazo de NIS2. El artículo 23 se aplica cuando una entidad sujeta a la norma tiene conocimiento de que el incidente es significativo según las reglas aplicables.
1. Defacement en una página de cara al cliente. Defacements indexados, página de inicio sustituida, páginas de producto sustituidas. La visibilidad facilita valorar la gravedad: el daño a la confianza del cliente es un hecho.
2. Cuenta de administrador comprometida con inicio de sesión confirmado. Una cuenta de administrador nueva, una cuenta de administrador existente con accesos desde un rango de IP o un país poco habitual, una cuenta de administrador que modifica otras cuentas. Lo detectan los plugins de audit log (WP Activity Log, Stream, Wordfence audit log).
3. Instalación de un plugin malicioso o subida de un tema. Un archivo de plugin en wp-content/plugins/ que ha llegado fuera del canal habitual de actualizaciones, o con PHP que llama a eval, base64_decode, gzinflate o assert sobre datos del usuario. Lo detecta la monitorización de integridad de archivos o un análisis de Wordfence.
4. Inyección en la base de datos con escritura confirmada. Una SQL injection que ha conseguido insertar o modificar filas. Se confirma con un diff del audit log o con manipulaciones en wp_users o wp_options. Señal clásica: la opción siteurl apunta de repente a un dominio ajeno.
5. Exportación no autorizada de datos personales. Una exportación de WordPress, una llamada a la REST API que devuelve la lista de usuarios, una respuesta grande de wp-json/wp/v2/users desde una IP inesperada. El artículo 33 del RGPD puede aplicarse en paralelo al artículo 23 de NIS2.
6. Ransomware o cifrado del sistema de archivos en producción o en las copias de seguridad. Archivos con extensiones nuevas, .html con la nota de rescate en los directorios de subidas, archivos de copia de seguridad cifrados. Es una señal de gravedad alta, pero el alcance y el carácter significativo siguen requiriendo una decisión documentada.
Para cada uno de estos hallazgos, el runbook de la agencia dice: anotar la hora del conocimiento en el ticket de IR, nombrar al responsable, poner en marcha el plazo de 24 horas y avisar al CISO de la entidad o a su equivalente en la primera hora. La agencia no notifica al CSIRT; lo hace la entidad. La agencia aporta el contenido técnico.
Plantilla de alerta temprana NIS2 en 24 horas
La alerta temprana es breve a propósito. La plantilla que entrego al equipo de cumplimiento de la entidad:
Entidad: [razón social]
Sector: [clasificación del Anexo I o II]
Identificador nacional: [NIF o número de registro]
Resumen del incidente
Fecha y hora del conocimiento: [ISO-8601 con zona horaria]
Origen de la detección: [audit log / aviso de cliente / escáner externo / notificación del proveedor de hosting]
Servicio afectado: [sitio WordPress público en https://example.com, portal de clientes, etc.]
Clasificación inicial
Causa presunta: [maliciosa / accidental / en análisis]
Efectos transfronterizos: [sí / no / en análisis]
Indicios de efectos transfronterizos: [si la respuesta es sí, qué apunta a ello]
Evaluación inicial del impacto
Disponibilidad del servicio: [operativo / degradado / no disponible]
Acceso confirmado a datos: [ninguno / sospecha / confirmado]
Número de personas potencialmente afectadas: [cifra si se conoce, si no "en análisis"]
Primera respuesta
Medidas de contención: [rotación de credenciales, eliminación del plugin, bloqueo de IP, etc.]
Análisis forense en curso: [sí / no, con el nombre del proveedor si es externo]
Próxima actualización: [hora de la notificación de 72 horas o de un informe intermedio anterior]
Contacto
Nombre y cargo: [CISO, responsable de TI, etc.]
Correo y teléfono: [línea directa]Esto es la alerta temprana, no la notificación. La notificación de 72 horas la amplía con la evaluación de la gravedad, los indicadores de compromiso y una valoración más clara de los efectos transfronterizos.
Qué incluye la notificación de incidente NIS2 a las 72 horas
En un plazo de 72 horas desde el conocimiento, la notificación añade:
- Evaluación de la gravedad. Número de usuarios afectados, distribución geográfica, estimación de las pérdidas económicas, tiempo estimado de recuperación.
- Indicadores de compromiso. Direcciones IP, hashes de archivos, URL, cadenas User-Agent maliciosas, firmas del ataque. El artículo 23, apartado 4, letra b), los pide cuando estén disponibles.
- Evaluación de los efectos transfronterizos. Confirmados o descartados, con justificación.
- Estado de la contención. Qué está controlado y qué sigue abierto.
- Necesidades de cooperación. Si la entidad necesita apoyo del CSIRT o de otras autoridades.
En WordPress, el bloque de indicadores suele incluir: IP de los atacantes sacadas de los access logs, rutas de los archivos maliciosos en wp-content/, hashes de esos archivos, cadenas User-Agent observadas durante la explotación y el HTTP request body conservado por el WAF.
Qué elementos debe incluir el informe final NIS2 tras un incidente
Artículo 23, apartado 4, letra d): informe final a más tardar un mes después de la notificación. Contenido:
- Descripción detallada del incidente.
- Tipo de amenaza o causa raíz.
- Medidas correctoras aplicadas y en curso.
- Efectos transfronterizos, cuando proceda.
En los incidentes de WordPress, la sección de la causa suele acabar en una de estas: un plugin desactualizado con un CVE conocido, credenciales de administrador débiles sin MFA, un wp-config.php expuesto desde un archivo de copia de seguridad, RCE a través de una función del tema, compromiso de la cadena de suministro en el canal de actualizaciones, una mala configuración del servidor. La sección de medidas correctoras vincula la causa con la medida del artículo 21, apartado 2 que debería haberla evitado y actualiza el registro de riesgos de la entidad.
Qué más exige el artículo 23 de NIS2 además de los tres informes
Los plazos de 24 horas, 72 horas y un mes son lo que todo el mundo recuerda. El mismo artículo contiene más obligaciones y una protección:
- Incidentes en curso. Según el artículo 23, apartado 4, letra e), si el incidente sigue en curso cuando vence el informe final, la entidad presenta en ese momento un informe de situación y el informe final en el plazo de un mes desde que termina la gestión del incidente.
- La respuesta del CSIRT. El artículo 23, apartado 5, obliga al CSIRT o a la autoridad competente a responder sin demora indebida y, cuando sea posible, en un plazo de 24 horas desde la recepción de la alerta temprana, con una primera valoración y, si la entidad lo pide, orientaciones sobre medidas de mitigación. Si se sospecha que el incidente es de carácter delictivo, también orienta sobre cómo comunicarlo a las fuerzas y cuerpos de seguridad.
- Destinatarios del servicio. Cuando proceda, la entidad informa sin demora indebida a los destinatarios de sus servicios de los incidentes significativos que puedan afectar negativamente a la prestación de esos servicios (artículo 23, apartado 1). Según el artículo 23, apartado 2, los destinatarios que puedan verse afectados por una ciberamenaza significativa reciben las medidas o soluciones que pueden aplicar. En una tienda o un portal de clientes en WordPress, ese es el mensaje a clientes redactado de antemano.
- Prestadores de servicios de confianza. Como excepción a la letra b), un prestador de servicios de confianza notifica los incidentes significativos que afecten a sus servicios de confianza en un plazo de 24 horas desde que tiene conocimiento, no de 72.
- Responsabilidad. El artículo 23, apartado 1, establece que el mero hecho de notificar no aumenta la responsabilidad de la entidad notificante.
- Información al público. Según el artículo 23, apartado 7, el CSIRT o la autoridad competente puede, tras consultar a la entidad, informar al público o exigir a la entidad que lo haga, cuando sea necesario para prevenir o gestionar el incidente o cuando la divulgación sea de interés público por otro motivo.
- Cuasiincidentes. El artículo 6, punto 5, los define como hechos que podrían haber comprometido la disponibilidad, la autenticidad, la integridad o la confidencialidad de datos o servicios, pero que se evitaron o no llegaron a producirse. El artículo 30 permite a las entidades esenciales e importantes notificar de forma voluntaria incidentes, ciberamenazas y cuasiincidentes. Un intento de explotación bloqueado contra un plugin de WordPress no es una notificación obligatoria, pero puede ir por esa vía.
Dónde notificar un incidente NIS2 en España y en la UE
Cada Estado miembro designa al menos un CSIRT y una autoridad competente. La lista actualizada se mantiene en el portal de ENISA. Los destinos más habituales para las entidades con las que trabajo:
- España. A 24 de octubre de 2026 la NIS2 sigue sin transponer y rige el Real Decreto-ley 12/2018. Los incidentes se notifican a través del CSIRT de referencia (artículo 19), que es el CCN-CERT para las entidades del sector público de la Ley 40/2015 y el INCIBE-CERT para las demás (artículo 11). El anteproyecto de 2025 prevé un Centro Nacional de Ciberseguridad como autoridad nacional competente única.
- Alemania. Bundesamt für Sicherheit in der Informationstechnik (BSI) y CERT-Bund.
- Noruega. No es Estado miembro de la UE. La Directiva tiene como destinatarios a los Estados miembros (artículo 46), así que las obligaciones de notificación noruegas derivan del Derecho noruego; las reglas vigentes se consultan en el NSM.
- Portugal. CERT.PT, dependiente del CNCS (Centro Nacional de Cibersegurança).
Para las entidades que operan en varias jurisdicciones, ENISA mantiene una lista de puntos de contacto únicos (SPOC) para la coordinación transfronteriza.
Actualización, . Cuando un ataque va más allá de tu propia web, hay una dirección más que conviene tener. Wordfence puso en marcha el 26 de octubre de 2026 su Threat Response Team, el equipo que se encarga del periodo entre la primera señal de una amenaza nueva y su estabilización, normalmente las primeras 72 horas (anuncio de Wordfence). Recibe avisos en [email protected] en tres casos: un plugin o tema explotado activamente, un ataque a la cadena de suministro, como una actualización de plugin o tema manipulada, o una campaña contra muchas webs WordPress a la vez. Wordfence pide qué estás viendo y desde cuándo, el plugin o tema afectado con su versión, indicadores (archivos sospechosos, cuentas de administrador desconocidas, direcciones IP, entradas de registro) y un contacto. Son los mismos datos que reúnes para la alerta temprana de la plantilla de arriba, así que un solo paquete de pruebas sirve para los dos avisos. Las direcciones IP de los registros son datos personales según el RGPD: envía las direcciones de los atacantes, no los registros de visitas de tus clientes. Este aviso no sustituye al artículo 23: INCIBE-CERT recibe la alerta temprana en 24 horas, haga lo que haga el proveedor de seguridad.
Cómo preparar un plan de respuesta a incidentes en WordPress
El plazo de 24 horas es implacable con las entidades que solo se preparan después de tener conocimiento del incidente. Antes de cualquier incidente:
- Guardias con nombre y apellidos. Dos personas, titular y suplente, con sus teléfonos en el runbook de IR.
- Árbol de escalado hasta el CISO de la entidad. La agencia no envía la alerta temprana; lo hace la entidad, así que el camino de “la agencia lo ve” a “la entidad decide” tiene que durar menos de una hora.
- Plantillas de comunicación preparadas de antemano. Aviso a clientes, aviso interno, aviso al regulador. Las tres en los idiomas que correspondan.
- Capacidad de hacer un snapshot de la instancia WordPress de producción. Antes de cualquier cambio de contención, conserve el sistema de archivos y la base de datos para el análisis forense.
- Relación con un proveedor forense, contratada con antelación. El análisis forense del artículo 23 en 72 horas exige un proveedor que coja el teléfono, no una petición de presupuesto.
- Copia de seguridad externa en modo inmutable. Sin ella, un ransomware puede hacer imposible el informe final al destruir las pruebas.
El precio de preparar esta capacidad es individual y depende del tamaño del parque WordPress; no es una línea de la factura del hosting.
Requisitos de gestión de incidentes del Reglamento de Ejecución 2024/2690
La sección 3 del anexo del Reglamento de Ejecución 2024/2690 fija los requisitos de gestión de incidentes del artículo 21, apartado 2, letra b), de la Directiva para las entidades de su artículo 1. Llevados a un parque WordPress, estos puntos cambian el trabajo diario:
- Política de gestión de incidentes (3.1). Funciones, responsabilidades y procedimientos para detectar, analizar, contener, recuperarse, documentar y notificar incidentes, con un sistema de categorización, planes de comunicación para el escalado y la notificación, y los documentos usados en la respuesta: manuales, diagramas de escalado, listas de contactos y plantillas (3.1.2). La plantilla de alerta temprana de arriba es uno de esos documentos. La política se prueba y revisa a intervalos planificados y después de incidentes significativos (3.1.3).
- Registro (3.2.3). Cuando proceda, los registros cubren la creación, modificación o supresión de usuarios y la ampliación de permisos, los eventos de autenticación, todo acceso privilegiado y la actividad de las cuentas administrativas, y el acceso a archivos críticos de configuración y de copia de seguridad o sus cambios. En WordPress: cambios de usuarios y roles, inicios de sesión de administradores y cambios en
wp-config.php,.htaccessy los archivos de copia. - Registros protegidos (3.2.5). Los registros se conservan durante un periodo predefinido y se protegen frente a accesos o cambios no autorizados. Un registro que solo está en el servidor WordPress comprometido puede modificarlo el atacante, así que es difícil considerarlo protegido.
- Hora sincronizada (3.2.6). Los sistemas usan fuentes de hora sincronizadas para poder correlacionar registros. Sin ellas, la hora del conocimiento de la alerta temprana no se puede cotejar con los registros del servidor web, del WAF y de la base de datos.
- Notificación de eventos (3.3). Un mecanismo sencillo permite a empleados, proveedores y clientes comunicar eventos sospechosos, y se informa de él a proveedores y clientes cuando proceda.
- Respuesta (3.5). Contención, erradicación y recuperación; planes de comunicación con el CSIRT o la autoridad competente; registro de las actividades de respuesta con las pruebas; pruebas de los procedimientos a intervalos planificados.
- Revisión posterior al incidente (3.6). Cuando proceda, una revisión tras la recuperación identifica la causa raíz y termina en lecciones aprendidas documentadas. El informe final del artículo 23, apartado 4, letra d), y esa revisión se apoyan en las mismas pruebas.
Cómo hacer el triaje de un incidente en WordPress y conservar pruebas
Ante una señal creíble, el equipo abre un único registro principal del incidente. Anota la observación original, la hora con zona horaria, el origen, el entorno y la persona que lo lleva. Valora la autenticidad y el impacto en la confidencialidad, la integridad y la disponibilidad, y solo después si pueden cumplirse los criterios de incidente significativo. Los niveles operativos, como evento, incidente grave y crisis, ordenan los recursos, pero no sustituyen al artículo 23 ni a la ley nacional. El acceso confirmado, las cuentas, los componentes, los recorridos de clientes, el tiempo, el alcance, los proveedores y el grado de certeza se van actualizando. Lo que se desconoce sigue marcado como desconocido.
La contención y la conservación de pruebas avanzan en paralelo. Antes de reconstruir o eliminar código sospechoso, y si es seguro hacerlo, se guarda un snapshot o una copia de los archivos, el estado de la base de datos, el identificador del despliegue, las sesiones, los administradores y los logs. Los originales se conservan, los archivos reciben sumas de comprobación y las copias de trabajo se mantienen separadas. Cada cambio, incluida la rotación de credenciales, las reglas del WAF, la eliminación de plugins, la restauración y el DNS, entra en la línea temporal. La seguridad tiene prioridad cuando conservar una prueba prolonga el daño; si falta la prueba, hay que justificarlo.
Junto a la línea temporal técnica se lleva un registro cronológico de decisiones con hechos, supuestos, alternativas, responsable y fecha de revisión. Lo técnico, la dirección, lo jurídico y la privacidad, y la comunicación con los clientes tienen flujos separados que coordina el responsable de coordinación. La agencia entrega los componentes, la hora de detección, las referencias a las pruebas, el estado de la contención, el acceso sospechoso y la estimación de recuperación. La entidad decide y notifica, salvo que una autorización expresa establezca otra cosa.
Cómo probar el plan de respuesta a incidentes
El ejercicio debería reunir al proveedor de hosting, la agencia, el líder del incidente, privacidad y comunicación. Va de la alerta a las pruebas y la valoración del carácter significativo, hasta el traspaso al regulador, la aprobación de la restauración y los mensajes a los clientes. Para darlo por bueno hace falta respuesta de la guardia, un registro correcto, recogida de pruebas sin accesos improvisados, traspaso a quien decide, plantillas actualizadas, un punto de restauración limpio y un responsable y un plazo para cada mejora.
Tras la restauración quedan la línea temporal, el registro de decisiones, el índice de pruebas, las copias de las notificaciones, la lista de activos, el análisis de causa, la prueba de la restauración, la comunicación y la verificación de las correcciones. Una protección provisional se sustituye por un control permanente o por una decisión formal sobre el riesgo residual.
Para preparar el plan o ensayarlo, envíe una descripción por escrito a través de la auditoría de cumplimiento UE para WordPress. Indique la entidad, las jurisdicciones, los entornos WordPress, el hosting, los recorridos clave, el registro de logs, las copias de seguridad, los contactos, los ejercicios anteriores y las carencias. No envíe en un primer momento credenciales, datos personales ni pruebas en bruto del compromiso. El trabajo mejora la preparación y las pruebas, pero no es un dictamen jurídico, una garantía ni una conclusión automática sobre la obligación de notificar.
