El artículo 21, apartado 1, de la Directiva (UE) 2022/2555 obliga a las entidades esenciales e importantes a tomar «las medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos que se planteen para la seguridad de las redes y sistemas de información». El artículo 21, apartado 2, enumera las diez categorías que esas medidas deben cubrir.
La expresión que hace el trabajo es basada en el riesgo. El considerando 79 de la directiva enmarca todo el capítulo como un ejercicio de gestión del riesgo: las medidas deben calibrarse al riesgo que afronta la entidad y sus servicios. El artefacto que operacionaliza esa calibración es el registro de riesgos.
La mayoría de las entidades en el ámbito de NIS2 ya llevan uno. La mayoría, en su forma actual, no pasan el test del regulador. La brecha rara vez es el volumen de riesgos registrados — es la ausencia de cinco campos concretos que el inspector espera encontrar. Esta es la guía de adaptación.
Campo 1 — Activo, anclado al perímetro NIS2
Cada entrada del registro necesita un activo — la cosa en riesgo. Para NIS2, el activo debe estar anclado al perímetro NIS2 de la entidad: las redes y sistemas de información que sostienen los servicios que la entidad presta como entidad esencial o importante.
Un riesgo sobre la flota de impresoras de oficina no está en el perímetro. Un riesgo sobre el SIEM que vigila la plataforma de pago en producción, sí. La distinción no es académica — es lo que permite al inspector cotejar el registro con la clasificación de la entidad bajo el artículo 3 y las reglas sectoriales de delimitación.
La adaptación: añada una columna «Perímetro NIS2» a su registro existente. Marque cada entrada como En perímetro, Fuera de perímetro o Adyacente (toca el perímetro pero no aloja datos del servicio). Los inspectores miran el subconjunto en perímetro; lo demás es informativo.
Campo 2 — Amenaza y vulnerabilidad, en pareja
NIS2 no nombra una metodología. El marco de gestión del riesgo publicado por ENISA, apoyado en ISO/IEC 27005 e ISO 31000, trata el riesgo como una pareja amenaza–vulnerabilidad: un actor de amenaza (o un evento natural) que podría explotar una vulnerabilidad concreta y producir daño.
Registrar «ransomware» como riesgo no basta. La entrada debe emparejarlo con la vulnerabilidad que explotaría — por ejemplo «ransomware que explota un appliance VPN de borde sin parchear» — porque el tratamiento difiere por completo de «ransomware entregado por phishing al personal de finanzas».
La adaptación: divida su columna única «riesgo» en dos columnas, amenaza y vulnerabilidad. Algunas entradas se contraerán limpiamente; otras se desplegarán en dos o tres. Ambos resultados son señales de que el registro ya es utilizable.
Campo 3 — Probabilidad × impacto, con método documentado
El artículo 21, apartado 2, letra a) exige expresamente «políticas de análisis de riesgos». Análisis implica método. El registro debe mostrar, para cada entrada, una probabilidad y un impacto estimados, derivados de un método documentado que no cambie entre entradas.
Tres métodos son aceptados por las autoridades nacionales competentes europeas:
- Una matriz cualitativa 5×5 (Muy baja → Muy alta en cada eje), con definiciones de bandas escritas una vez para todo el registro.
- Un método cuantitativo de 3 bandas para el impacto (pérdida financiera en bandas en €) combinado con probabilidad cualitativa.
- Un método alineado con FAIR para organizaciones con la madurez para sostenerlo.
Lo que no se acepta: una única columna de «criticidad» sin derivación. La adaptación: elija uno de los tres métodos, escriba sus definiciones en una página que viva al lado del registro, y vuelva a puntuar cada entrada existente con el método elegido. Sí, es tedioso. También es la acción atómica más pequeña que eleva el registro de «lista» a «análisis».
Campo 4 — Tratamiento, con responsable y fecha objetivo
El considerando 78 de la directiva enmarca la elección de medidas como proporcionada al riesgo. En términos de registro, esto es la decisión de tratamiento: Aceptar, Mitigar, Transferir o Evitar.
Para Mitigar — el caso más común — el registro debe consignar:
- la medida que se despliega (mapeada al artículo 21, apartado 2, ver campo 5),
- el responsable (un rol nominado, no un equipo),
- la fecha objetivo para que la medida esté en marcha,
- el riesgo residual esperado tras la medida (re-puntuado con el mismo método probabilidad × impacto).
Para Aceptar, la entrada debe mostrar la autoridad de aceptación — el rol nominado con la seniority para aceptar formalmente el riesgo residual en nombre de la entidad. Para la mayoría de los riesgos en perímetro NIS2, ese rol es el órgano de dirección mismo, conforme al artículo 20, apartado 1.
La adaptación: añada las columnas Tratamiento, Responsable, Fecha objetivo, Residual. Para entradas preexistentes sin tratamiento, márquelas Pendiente de revisión y póngalas en el orden del día del próximo comité de riesgos.
Campo 5 — Mapeo a las categorías del artículo 21, apartado 2
Es el campo que convierte un registro genérico en un registro NIS2. El artículo 21, apartado 2, enumera diez categorías de medidas:
- políticas de análisis de riesgos y de seguridad de los sistemas de información,
- gestión de incidentes,
- continuidad de negocio (copias de seguridad, recuperación ante desastres, gestión de crisis),
- seguridad de la cadena de suministro,
- seguridad en la adquisición, desarrollo y mantenimiento de las redes y sistemas de información,
- políticas y procedimientos de evaluación de la eficacia,
- prácticas básicas de ciberhigiene y formación en ciberseguridad,
- criptografía,
- seguridad de los recursos humanos, políticas de control de acceso, gestión de activos,
- autenticación multifactor, comunicaciones de voz/vídeo/texto seguras, comunicaciones de emergencia seguras.
Cada entrada del registro en el perímetro NIS2 debe mapearse a al menos una de esas categorías. El mapeo es lo que permite al inspector verificar, en una sola pasada, que el registro ejerce las diez categorías — y a la inversa, que ninguna queda muda.
La adaptación: añada una última columna «Categoría artículo 21(2)». Etiquete cada entrada en perímetro. Si una categoría tiene cero entradas, eso ya es un hallazgo a llevar al próximo comité de riesgos.
Cómo se ve cuando está bien hecho
En las notas de inspección publicadas por las autoridades nacionales competentes europeas, aparecen tres señales con regularidad:
- El registro tiene un historial de versiones fechado. Cada versión está firmada — típicamente cada trimestre — por el comité de seguridad, con información al órgano de dirección.
- Cada entrada en perímetro tiene los cinco campos anteriores, completados. Las celdas vacías son una bandera roja; «pendiente» con fecha objetivo es aceptable.
- El mapeo a las categorías del artículo 21, apartado 2 muestra una cobertura no nula de las diez. Un registro donde la categoría 7 (ciberhigiene básica) está vacía es, en términos regulatorios, un registro que en realidad no se ha hecho.
El registro no es el programa de seguridad. Es el documento que prueba que el programa existe, está calibrado al riesgo y está titularizado al nivel adecuado. La adaptación, bien hecha, le lleva a un equipo competente tres o cuatro semanas. La alternativa, hecha en el momento de la inspección, lleva un hallazgo regulatorio.
Fuentes
- Directiva (UE) 2022/2555, artículo 21, apartados 1 y 2 (medidas para la gestión de riesgos de ciberseguridad).
- Directiva (UE) 2022/2555, considerandos 78 y 79 (medidas basadas en el riesgo, proporcionadas).
- Directiva (UE) 2022/2555, artículo 20, apartado 1 (aprobación y supervisión por el órgano de dirección).
- ISO/IEC 27005 (gestión del riesgo de seguridad de la información) e ISO 31000 (gestión del riesgo — principios y directrices).
- ENISA, Risk Management Methodology y NIS2 Implementation Guidance.
- Directrices publicadas por las autoridades nacionales competentes: ANSSI (FR), BSI (DE), INCIBE (ES), ACN (IT), NCSC-IE (IE).
