Art. 21(2)(b) NIS 2 + CIR §3.2

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 y Alemania lo incorpora en el §30(2)(2) BSIG. Para los proveedores digitales que abarca, el punto 3.2 del CIR nombra doce tipos de eventos y las reglas operativas.

Simon OrzelSimon Orzel·

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 punto 3.2 del CIR (UE) 2024/2690 completa el detalle para los proveedores digitales enumerados en el art. 1 CIR (DNS, TLD, nube, centros de datos, CDN, MSP, MSSP, mercados en línea, motores de búsqueda, redes sociales, servicios de confianza). Cuando proceda, los registros abarcan doce tipos de eventos; la entidad fija umbrales de alarma y su propio periodo de conservación, mantiene sincronizadas las fuentes horarias y opera la monitorización de forma redundante. Para las demás entidades este detalle no es una obligación legal; en Alemania solo los operadores de instalaciones críticas deben operar sistemas de detección de ataques (§ 31 Abs. 2 BSIG).

Alemania incorpora la medida en el §30(2)(2) BSIG. IT-Grundschutz ofrece OPS.1.1.5 'Protokollierung' y DER.1 'Detektion' como bloques de construcción; son recomendaciones, no una base legal. Esta página recorre la directiva, el reglamento de desarrollo de la UE y la transposición alemana en ese orden.

La fuente jurídica
Tres capas. La directiva (vinculante para todos los países de la UE). El reglamento de ejecución (legislación de la UE directamente aplicable para los tipos de entidad enumerados en su art. 1). La transposición nacional (en Alemania: BSIG).

Artículo 21(2)(b) de la Directiva NIS 2 (2022/2555)

La 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 herramientas para supervisar y registrar las actividades en sus sistemas de redes y de información a fin de detectar sucesos que puedan considerarse incidentes y dar una respuesta consecuente para mitigar su impacto.

Dado que se trata de un reglamento (no de una directiva), es legislación de la UE directamente vinculante para los tipos de entidad enumerados en su art. 1 (DNS, TLD, nube, centros de datos, CDN, MSP, MSSP, mercados en línea, motores de búsqueda, redes sociales, servicios de confianza). El punto 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)

La gestión de incidentes.

Alemania copia el texto de la UE palabra por palabra. IT-Grundschutz ofrece OPS.1.1.5 'Protokollierung' y DER.1 'Detektion von sicherheitsrelevanten Ereignissen' como bloques de construcción; son recomendaciones, no una base legal.

Las tres cosas que el punto 3.2 del CIR exige a los proveedores que abarca
Para los proveedores digitales que abarca el CIR, el punto 3.2 divide el registro en tres piezas operativas: la lista de eventos, el ciclo de alertas y la protección de los propios registros. Las demás entidades pueden usarlo como lista de comprobación.
§3.2.3

Registrar los doce tipos de eventos

Construya la lista de activos a registrar a partir de su evaluación de riesgos. 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.

§3.2.4

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.

§3.2.5 + §3.2.6

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.

Dos reglas que dan forma a todo lo demás
Dos ideas subyacen a todo el texto del §3.2. Le indican cómo leer la lista de doce eventos y las reglas de alerta sin perder el sentido.

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 punto 3.2.3(k) enumera la 'activación, detención y pausa de los distintos registros' como algo que debe registrarse.

Revisar los registros es el objetivo, no un extra opcional

Para los proveedores digitales que abarca el CIR, el punto 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. Conserve un registro de quién revisó qué alertas, cuándo y qué hizo al respecto.

Cómo lo gestionan en la práctica los reguladores nacionales
La UE fija la regla. Cada país la transpone. El punto 3.2 del CIR se aplica igual en todas partes, pero solo a los proveedores digitales que abarca. La mecánica local difiere un poco.
Alemania

BSI / IT-Grundschutz OPS.1.1.5 + DER.1

IT-Grundschutz ofrece OPS.1.1.5 'Protokollierung' (qué registrar, conservación, protección) y DER.1 'Detektion von sicherheitsrelevanten Ereignissen' (alertas y respuesta) como bloques de construcción; son recomendaciones, no una base legal.

Toda la UE

Guía técnica de implementación de ENISA

La TIG de ENISA ofrece orientaciones y ejemplos de pruebas para el punto 3.2, incluidos ejemplos de umbrales de alarma, e indica que el periodo de conservación se fija según las necesidades del negocio, la evaluación de riesgos y los requisitos legales. Su tabla de correspondencias vincula el 3.2 con ISO/IEC 27001:2022 A.5.28, A.8.15, A.8.16 y A.8.17; ENISA precisa que la correspondencia no es una medida de equivalencia.

Otros Estados miembros

Leyes nacionales de transposición

Cada Estado miembro tiene su propia transposición (Países Bajos: Cyberbeveiligingswet; Austria: NISG 2026; Bélgica: su ley NIS2). El punto 3.2 del CIR se aplica directamente en todos los Estados miembros, pero solo a los proveedores digitales enumerados en el art. 1 CIR. Lo que difiere: con qué autoridad nacional habla, y cómo se gestionan localmente la notificación y la supervisión.

Tres trampas
Tres suposiciones, contrastadas con el punto 3.2 del CIR.
  • Conservamos todos los registros para siempre, así que estamos cubiertos.

    Para los proveedores digitales que abarca el CIR, el punto 3.2.5 exige un periodo de conservación predefinido, no infinito. Para todos, 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. Para los proveedores digitales que abarca el CIR, el punto 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.

    Para los proveedores digitales que abarca el CIR, el punto 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, por lo que su actividad pertenece a los registros.

Un comienzo práctico

El comienzo más económico: construya la lista de activos a registrar a partir de su evaluación de riesgos, canalice los registros a un único lugar (un almacén de registros central o un pequeño SIEM), fije umbrales en los eventos que más importan y revíselos con regularidad. No necesita un SOC gestionado desde el primer día. Necesita a alguien que mire las alertas y sepa qué hacer.

Fuentes
  • 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 (versión 1.0, junio de 2025)

¿Le han encargado NIS2?

Le guiamos paso a paso. Usted rellena, nosotros explicamos cada punto con palabras sencillas y, al final, firma la dirección.

El recorrido NIS2: su camino paso a paso, con los primeros puntos hechos