Registro y monitorización NIS 2 en virtud del artículo 21(2)(b)
El registro es la capa de visibilidad de la gestión de incidentes. El artículo 21(2)(b) es donde reside el deber, el §3.2 del CIR nombra los doce tipos de eventos y las reglas operativas, y Alemania incorpora la misma regla en el §30(2)(2) BSIG.
La versión breve
El registro y la monitorización no son un deber separado en NIS 2. Se sitúan dentro de la medida de gestión de incidentes del artículo 21(2)(b). La lógica es sencilla: si no puede ver lo que ocurre en su red, no puede detectar un incidente de seguridad, y no puede contenerlo.
El §3.2 del CIR (UE) 2024/2690 completa el detalle. Nombra doce tipos de eventos que debe registrar, fija las reglas para las alertas y la respuesta cualificada, establece un periodo de conservación definido y exige sistemas con sincronización horaria más una monitorización redundante. Ese es el mínimo para los sectores nombrados en el Anexo del CIR.
Alemania incorpora la misma regla en el §30(2)(2) BSIG. La base práctica es IT-Grundschutz OPS.1.1.5 'Protokollierung' y DER.1 'Detektion'. Esta página recorre la directiva, el reglamento de desarrollo de la UE y la transposición alemana en ese orden.
Artículo 21(2)(b) de la Directiva NIS 2 (2022/2555)
Gestión de incidentes.
Este es el punto (b) de la lista de diez medidas de ciberseguridad que toda entidad esencial e importante debe implantar. El §3 del CIR lo operativiza a continuación. El registro y la monitorización se sitúan dentro del §3.2.
CIR (UE) 2024/2690, Anexo §3.2.1
Las entidades pertinentes establecerán procedimientos y utilizarán instrumentos para monitorizar y registrar las actividades en sus redes y sistemas de información, de modo que los eventos que puedan considerarse incidentes de seguridad puedan detectarse y tratarse para contener su impacto.
Dado que se trata de un reglamento (no de una directiva), es legislación de la UE directamente vinculante. El §3.2 se desglosa después en siete subpuntos que cubren los tipos de eventos a registrar, las alertas, la conservación, la sincronización horaria y la redundancia. No se necesita transposición nacional.
§30(2)(2) BSIG (Alemania)
Gestión de incidentes.
Alemania copia el texto de la UE palabra por palabra. El 'cómo' práctico llega a través de IT-Grundschutz: OPS.1.1.5 'Protokollierung' para el diseño del registro, y DER.1 'Detektion' para la parte de alertas y respuesta.
Registrar los doce tipos de eventos
Construya la lista frente a su inventario de activos. Cuando proceda, capture: el tráfico de red entrante y saliente, los cambios de usuarios y privilegios, el acceso a sistemas y aplicaciones, los eventos de autenticación, toda la actividad privilegiada y de administración, el acceso a archivos de configuración o de copia de seguridad críticos, los registros de herramientas de seguridad (AV, IDS, cortafuegos), el uso de recursos del sistema, el acceso físico, el uso de equipos de red, la activación o pausa de los propios registros y los eventos del entorno.
Revisión, alarma, respuesta cualificada
Recopilar registros no basta. Revíselos con una cadencia periódica en busca de tendencias inusuales o no deseadas. Cuando proceda, fije umbrales. Cuando se supere un umbral, dispare una alarma automática. Y asegúrese de que alguien cualificado responde efectivamente a tiempo. El almacenamiento sin revisión no constituye registro en virtud del §3.2.
Proteger, conservar, sincronizar la hora, redundancia
Los propios registros son prueba. Consérvelos durante un periodo de conservación definido, protéjalos frente al acceso y los cambios no autorizados, sincronice la hora de todos los sistemas para que los eventos puedan correlacionarse y ejecute el sistema de monitorización de forma redundante. La monitorización del sistema de monitorización es a su vez independiente de los sistemas que monitoriza.
Los registros son un activo, no un subproducto
El §3.2.5 trata los registros como datos críticos. Periodo de conservación definido, protección frente a manipulación, protección frente al acceso no autorizado. Si un atacante puede eliminar los registros que muestran lo que hizo, el deber de registro no se cumple. Por eso también el §3.2.3(k) enumera explícitamente la 'activación, desactivación o pausa' de los registros como un evento que debe registrar.
Revisar los registros es un deber, no algo opcional
El §3.2.4 exige revisiones periódicas en busca de tendencias inusuales, umbrales cuando proceda, alarmas automáticas al superarse un umbral y una respuesta cualificada en tiempo. Un SIEM que nadie mira no cumple esto. Un auditor preguntará quién revisó qué alertas, cuándo, y qué hizo al respecto.
BSI / IT-Grundschutz OPS.1.1.5 + DER.1
El BSI señala IT-Grundschutz como la vía práctica. OPS.1.1.5 'Protokollierung' es donde reside el diseño del registro (qué registrar, conservación, protección). DER.1 'Detektion' cubre la parte de alertas y respuesta (cadencia de revisión, reglas del SIEM, gestión cualificada). Ambos en conjunto se corresponden con el §3.2 del CIR.
Guía técnica de implementación de ENISA
La TIG de ENISA ofrece ejemplos concretos de prueba para el §3.2: plantillas de política de registro, umbrales de alerta de muestra, valores por defecto de conservación y una correspondencia con el Anexo A de ISO/IEC 27001:2022 (A.8.15 Registro, A.8.16 Actividades de monitorización). Si ya opera con ISO 27001, reutiliza la mayoría de los controles.
Leyes nacionales de transposición
Cada Estado miembro tiene su propia transposición (Países Bajos: Cyberbeveiligingswet, Austria: NISG, Bélgica: NIS2-Wet). El deber del §3.2 es el mismo porque el CIR es directamente aplicable. Lo que difiere: con qué autoridad nacional habla, y cómo se gestionan localmente los canales de notificación y las cadencias de auditoría.
Conservamos todos los registros para siempre, así que estamos cubiertos.
El §3.2.5 exige un periodo de conservación definido, no infinito. Conservarlo todo para siempre es un problema de protección de datos (Art. 5(1)(e) GDPR, limitación del plazo de conservación) y un problema de coste. Decida una ventana de conservación por tipo de registro, póngala por escrito, justifíquela frente a su panorama de riesgos y aténgase a ella.
El SIEM lo tiene, así que estamos bien.
Cerca, pero no del todo. El §3.2.4 no exige solo almacenamiento. Exige revisión periódica, umbrales cuando proceda, alarmas automáticas al superarse y una persona cualificada que efectivamente responda. Un SIEM que funciona sin reglas, o con reglas que nadie ajusta, incumple el §3.2.4.
Registramos la actividad de los usuarios pero no la de los administradores.
El §3.2.3(e) es explícito: todo acceso privilegiado a sistemas y aplicaciones más las actividades de las cuentas de administración. Los administradores son los usuarios de mayor impacto en su red. No registrarlos es la brecha que un auditor encuentra primero.
Lo que vemos en la práctica: la mayoría de las empresas del Mittelstand tienen registros del cortafuegos y registros de Active Directory. Rara vez cubren sistemáticamente los doce tipos de eventos del §3.2.3. El acceso privilegiado, los cambios en archivos de configuración y el acceso físico son las tres brechas habituales.
La solución más económica: construya la lista del §3.2.3 frente a su inventario de activos (RSK 2.2), canalice todo a un único lugar (un almacén de registros central o un pequeño SIEM), fije umbrales en los eventos de alto valor y revise semanalmente. No necesita un SOC gestionado desde el primer día. Necesita a alguien que mire las alertas y sepa qué hacer.
El módulo INC cubre la estrategia de registro del §3.2: qué tipos de eventos registra, frente a qué activos, con qué ventana de conservación. Lo escribe una vez, lo firma, y se convierte en su política de registro lista para auditoría.
El módulo EFF cubre la parte de revisión del §3.2.4: umbrales de alarma, cadencia de revisión, prueba de respuesta cualificada. Las firmas y el registro de auditoría muestran a un auditor que alguien miró las alertas y actuó sobre ellas. Sin montones de hojas de cálculo. Sin una segunda herramienta.
- Directiva (UE) 2022/2555 (NIS 2), artículo 21(2)(b) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Reglamento de Ejecución (UE) 2024/2690 de la Comisión (CIR), Anexo §3.2 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Ley del BSI (BSIG), §30(2)(2) en su redacción dada por la Ley de Implementación de NIS2 y de Refuerzo de la Ciberseguridad
- IT-Grundschutz Kompendium, OPS.1.1.5 'Protokollierung' y DER.1 'Detektion' — bsi.bund.de/grundschutz
- Guía técnica de implementación de ENISA para el CIR (UE) 2024/2690 (a fecha de mayo de 2026)