Qué exige el artículo 21
El artículo 21 de la Directiva NIS2 es el punto en el que la directiva deja de definir quién está obligado y pasa a decir qué tienen que hacer esas organizaciones. El apartado 1 obliga a las entidades esenciales e importantes a adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos que afectan a los sistemas de redes y de información con los que operan o prestan sus servicios. Esas mismas medidas deben prevenir los incidentes, o reducir su impacto, tanto sobre quienes reciben esos servicios como sobre otros servicios que dependen de ellos.
La obligación se plantea como gestión de riesgos, no como una lista cerrada, y esa decisión condiciona todo el artículo. Las medidas deben tener en cuenta el estado de la técnica, las normas europeas e internacionales pertinentes cuando las haya y el coste de aplicación. Cuando el supervisor valora si son proporcionadas, la directiva le pide considerar la exposición de la entidad al riesgo, su tamaño, la probabilidad de los incidentes y su gravedad, incluido su impacto social y económico. En la práctica, dos organizaciones del mismo sector pueden llegar a conjuntos de controles bastante distintos y cumplir ambas, siempre que cada una pueda demostrar cómo su propio análisis de riesgos la llevó a sus decisiones.
La proporcionalidad no es una vía para librarse de la obligación. Un proveedor de servicios gestionados de 60 personas no tendrá el mismo programa que una empresa nacional de aguas, pero sigue teniendo que cubrir todos los ámbitos que enumera el artículo y explicar sus decisiones por escrito. Los considerandos lo dicen con claridad: las medidas deben ser proporcionadas para no imponer una carga excesiva, pero deben dar una visión completa de la seguridad de los sistemas, incluido el factor humano. Un supervisor que lee un análisis de riesgos espera ver por qué un control se consideró suficiente, no solo que existe.
El apartado 2 exige además un enfoque que abarque todos los peligros y proteja los sistemas y su entorno físico. El considerando 79 detalla qué incluye: robo, incendio, inundación, cortes de telecomunicaciones o de suministro eléctrico y accesos físicos no autorizados, además de los ciberataques. Un análisis de riesgos que solo piensa en atacantes se deja fuera la mitad de lo que pide la directiva. El apartado termina con diez ámbitos, de la a) a la j), que las medidas deben incluir como mínimo. Esos diez puntos son lo que la mayoría entiende por requisitos de NIS2, y cada uno es lo bastante amplio como para contener un programa de trabajo propio.
Quién tiene que aplicar las medidas
El artículo 21 se aplica a las entidades esenciales e importantes definidas en el artículo 3, por sector, por tamaño y mediante algunos casos especiales. Nuestra guía sobre entidades esenciales e importantes en NIS2 explica cómo una organización acaba en una categoría u otra. La distinción importa para la supervisión, pero no cambia el contenido de la obligación: las diez medidas son idénticas para ambas.
Lo que cambia es cómo las comprueba la autoridad. Las entidades esenciales están sujetas a una supervisión proactiva según el artículo 32, que incluye auditorías, inspecciones in situ y peticiones de evidencias antes de que ocurra nada. Las entidades importantes se supervisan a posteriori según el artículo 33, normalmente cuando un incidente, una denuncia u otros indicios apuntan a que no cumplen. Una entidad importante puede pasar mucho tiempo sin que el supervisor le pida nada, pero cuando llega la petición suele ser porque ya ha pasado algo, que es el peor momento para descubrir que las evidencias no existen.
Como NIS2 es una directiva, la obligación llega a cada empresa a través de la ley nacional que la transpone, y la autoridad competente, el registro y los procedimientos sancionadores son nacionales. El artículo 21 fija un mínimo, así que una ley nacional puede detallar o exigir más, pero todas las transposiciones tienen que incluir los diez ámbitos. Para las empresas españolas, nuestro artículo sobre NIS2 en España explica quién está obligado y cómo llegan las obligaciones. El considerando 83 añade algo fácil de pasar por alto: las obligaciones se aplican tanto si la entidad gestiona sus sistemas internamente como si los ha externalizado. Externalizar la informática traslada el trabajo, no la responsabilidad.
Las diez medidas mínimas del artículo 21.2
Es más fácil trabajar los diez puntos en cuatro grupos, porque las medidas de cada grupo dependen unas de otras y suelen llevarlas las mismas personas.
Gobierno, análisis de riesgos y eficacia: puntos a) y f)
El punto a) exige políticas de análisis de riesgos y de seguridad de los sistemas de información, y sostiene a los otros nueve. La entidad necesita un método documentado para identificar los riesgos de sus sistemas, valorar su probabilidad e impacto y decidir cómo se trata cada uno, con un responsable que responda de la decisión. También necesita una política de seguridad, aprobada por la dirección, que fije las reglas que sigue el resto del programa. Sin análisis de riesgos no hay forma de argumentar que una medida posterior es proporcionada, y por eso los supervisores suelen pedirlo lo primero.
El anexo del Reglamento de Ejecución (UE) 2024/2690, que se aplica directamente a determinados proveedores digitales, muestra el nivel de detalle que los reguladores consideran adecuado. Separa la política de seguridad, la definición de funciones y responsabilidades y un marco de gestión de riesgos con su propia política y su ciclo de revisión. Un registro de riesgos redactado una vez para un proyecto de certificación y nunca revisado no alcanza ese nivel, porque no puede demostrar que las medidas actuales responden a los riesgos actuales. La fecha de la última revisión es de lo primero que mira un supervisor.
El punto f) cierra el círculo al exigir políticas y procedimientos para evaluar si las medidas son eficaces. Es lo que convierte un conjunto de documentos en un programa gestionado. La evaluación puede combinar auditorías internas, pruebas técnicas como escaneos de vulnerabilidades y pruebas de intrusión, métricas seguidas en el tiempo y comprobaciones automáticas de que los controles siguen implantados. Lo que el supervisor quiere ver es la secuencia: el plan, los resultados y qué cambió a raíz de ellos. Nuestro artículo sobre la monitorización continua del cumplimiento explica cómo funciona lo último en la práctica.
Las organizaciones con un SGSI ISO 27001 ya hacen la mayor parte de este trabajo, porque los apartados de análisis de riesgos y de evaluación del desempeño piden lo mismo. Nuestra guía sobre cómo hacer el análisis de riesgos ISO 27001 explica el método. La diferencia en NIS2 es el destinatario: los resultados tienen que llegar ahora al órgano de dirección, que responde de ellos según el artículo 20.
Incidentes, continuidad y gestión de crisis: puntos b) y c)
El punto b) exige la gestión de incidentes, es decir, la capacidad de detectar, analizar, contener y recuperarse de los incidentes. Conecta directamente con el artículo 23, que fija tres plazos de notificación para un incidente significativo: una alerta temprana en las 24 horas siguientes a tener conocimiento de él, una notificación del incidente en 72 horas y un informe final en el plazo de un mes. Esos plazos son imposibles de cumplir sin una forma eficaz de detectar incidentes y decidir rápido si son significativos.
Por eso un procedimiento escrito es solo el principio. La medida necesita una fuente de alertas, como la detección en los equipos y la monitorización de registros, personas que revisen esas alertas, criterios de gravedad acordados de antemano, un circuito de decisión para notificar que diga quién puede tomar la decisión fuera de horario y registros de los incidentes anteriores y de lo que se aprendió de ellos. El fallo más habitual no es la falta de procedimiento, sino un procedimiento que nadie ha puesto nunca a prueba. Nuestro artículo sobre los plazos de notificación de incidentes en NIS2 y DORA detalla qué debe contener cada informe.
El punto c) abarca la continuidad de negocio, incluidas la gestión de copias de seguridad y la recuperación en caso de desastre, y la gestión de crisis. La pregunta que plantea es si la entidad puede seguir prestando su servicio, o restablecerlo, cuando sus sistemas no están disponibles. Para responderla hay que saber qué servicios son críticos, cuánto tiempo puede estar parado cada uno antes de que el impacto sea inaceptable y cómo se recuperará cada uno. El reglamento de ejecución espera un plan de continuidad y recuperación basado en ese análisis, con objetivos de recuperación para cada servicio crítico.
Las evidencias aquí son concretas y fáciles de comprobar, y por eso los huecos aparecen enseguida. El supervisor pedirá la política de copias de seguridad, registros que demuestren que se hicieron, los resultados de las pruebas de restauración y el acta de al menos un ejercicio de crisis. Las copias que nunca se han restaurado son el punto débil más frecuente, porque el fallo solo aparece el día que se necesitan. Un escenario de ransomware que también cifra las copias es el ejercicio con el que deberían empezar la mayoría de organizaciones.
Proveedores y desarrollo seguro: puntos d) y e)
El punto d) exige la seguridad de la cadena de suministro, es decir, los aspectos de seguridad de la relación entre la entidad y sus proveedores directos y prestadores de servicios. En la mayoría de las empresas eso incluye a los proveedores cloud, los de servicios gestionados de TI y de seguridad, los fabricantes de software y cualquiera con acceso a sistemas o datos. El considerando 85 explica por qué la directiva le dedica un punto propio: muchos incidentes graves han entrado a través de vulnerabilidades en productos y servicios de terceros, no por los sistemas de la propia víctima.
El apartado 3 indica cómo valorar qué medidas son adecuadas para cada proveedor. Las entidades deben tener en cuenta las vulnerabilidades específicas de cada proveedor directo, la calidad general de sus productos y sus prácticas de ciberseguridad, incluidos sus procedimientos de desarrollo seguro, además de los resultados de las evaluaciones coordinadas de riesgos de las cadenas de suministro críticas realizadas a escala de la UE según el artículo 22.1. Eso descarta enviar el mismo cuestionario a todos los proveedores y archivar las respuestas. Un proveedor de servicios gestionados con acceso de administración a producción necesita una revisión mucho más profunda que un proveedor de material de oficina, y la entidad debe poder explicar por qué consideró aceptable a cada proveedor crítico. El considerando 85 anima además a incluir requisitos de seguridad en los contratos, y el 86 pide especial diligencia al elegir un proveedor de servicios de seguridad gestionados, porque su nivel de acceso lo convierte en un objetivo atractivo en sí mismo. Nuestra guía sobre la gestión del riesgo de terceros en DORA y NIS2 explica cómo clasificar a los proveedores para que el esfuerzo vaya donde está el riesgo.
El punto e) abarca la seguridad en la adquisición, el desarrollo y el mantenimiento de los sistemas, incluida la gestión y divulgación de vulnerabilidades. Se aplica tanto si la entidad desarrolla software como si solo lo compra y configura, porque los parches, la configuración segura, el control de cambios y las pruebas entran aquí. Gestionar vulnerabilidades significa tener un proceso que encuentre las debilidades, las valore, las corrija en plazos definidos y deje constancia del resultado. Divulgarlas significa ofrecer a terceros una vía para comunicar una vulnerabilidad que hayan encontrado, como un contacto de seguridad publicado.
En las empresas con sistemas expuestos a internet, el punto de partida es saber qué está expuesto, y ese inventario suele estar menos completo de lo que se cree. Nuestro artículo sobre la superficie de ataque externa explica por qué. Las organizaciones que desarrollan su propio software necesitan además prácticas de desarrollo seguro y pruebas de seguridad antes de cada versión, que nuestra guía sobre pruebas de seguridad de aplicaciones explica en detalle.
Personas, accesos y salvaguardas técnicas: puntos g) a j)
El punto g) une la ciberhigiene básica con la formación en ciberseguridad. El considerando 89 enumera qué significa la higiene en la práctica: principios de confianza cero, actualizaciones de software, configuración de dispositivos, segmentación de redes, gestión de identidades y accesos y concienciación de los usuarios, incluida la formación sobre phishing e ingeniería social. Son los controles cotidianos que evitan la mayoría de los incidentes, y son lo primero que comprueba un supervisor porque son fáciles de verificar. Los registros de formación por sí solos son una evidencia débil; un programa más sólido muestra formación de acogida, repasos periódicos, formación específica para quien tiene accesos privilegiados y alguna medida de si el comportamiento cambió, como la evolución de los resultados de las simulaciones de phishing.
El punto h) exige políticas y procedimientos sobre el uso de la criptografía y, cuando proceda, del cifrado. La política debe indicar dónde se exige cifrado en reposo y en tránsito, qué algoritmos y longitudes de clave se aceptan y cómo se generan, guardan, rotan y revocan las claves. Los huecos habituales no están en los servicios cloud, que cifran por defecto, sino a su alrededor: portátiles sin cifrado de disco, copias de seguridad guardadas en almacenamiento sin cifrar, claves guardadas junto a los datos que protegen y certificados que caducan porque nadie es responsable de ellos. La política solo cuenta si describe lo que la organización hace en realidad.
El punto i) agrupa la seguridad de los recursos humanos, el control de acceso y la gestión de activos, tres disciplinas que fallan a la vez. El reglamento de ejecución trata cada una en detalle, desde los procedimientos de cambio y fin de la relación laboral hasta la política de control de acceso y la clasificación y el tratamiento de los activos. Lo que las une en la práctica es el proceso de salidas: si RR. HH., TI y los responsables de cada aplicación SaaS no comparten un único proceso, el personal que se va y los colaboradores externos conservan sus accesos durante meses. Un supervisor suele tomar muestras de las revisiones de accesos, del inventario de activos y de algunas bajas recientes para comprobar si sus cuentas se eliminaron a tiempo.
El punto j) exige, cuando proceda, autenticación multifactor o continua, comunicaciones de voz, vídeo y texto seguras y sistemas seguros de comunicaciones de emergencia dentro de la entidad. La autenticación multifactor en el correo, el acceso remoto, las cuentas de administración y las aplicaciones críticas es ya lo mínimo que se espera, y las excepciones necesitan un motivo documentado. La parte de comunicaciones de emergencia es la que más se olvida. Si la plataforma principal de correo y mensajería está comprometida durante un incidente, el equipo de respuesta necesita otra forma de coordinarse, acordada de antemano y probada en un ejercicio de crisis. Cuesta poco y cierra un hueco que de otro modo aparece en el peor momento.
Aprobación y responsabilidad de la dirección según el artículo 20
El artículo 20 convierte las medidas en una responsabilidad de la dirección y no en un proyecto de informática. Los órganos de dirección de las entidades esenciales e importantes deben aprobar las medidas de gestión de riesgos adoptadas para cumplir el artículo 21 y supervisar su aplicación, y pueden ser considerados responsables de los incumplimientos. Sus miembros deben además recibir formación para identificar riesgos y valorar las prácticas de gestión de la ciberseguridad, y se anima a las entidades a ofrecer una formación similar a su plantilla de forma periódica.
En la práctica, el consejo o el comité de dirección necesita tres cosas documentadas: una decisión que apruebe las medidas, informes periódicos sobre cómo funcionan y su propia formación. Un programa de seguridad que funciona por completo por debajo de la dirección deja a la entidad expuesta en el artículo 20 aunque todos los controles técnicos estén en su sitio, porque la directiva es explícita en que la aprobación y la supervisión corresponden a la dirección. También cambia la conversación dentro de la empresa: las peticiones de presupuesto, las excepciones y la aceptación de riesgos tienen que llegar ahora a quienes responden de ellas.
El formato más útil suele ser un informe trimestral breve: el estado de cada uno de los diez ámbitos, los huecos abiertos con responsables y fechas, los incidentes significativos y los casi incidentes, y las decisiones que debe tomar el órgano de dirección. Da a la dirección lo que exige el artículo 20 y al supervisor un rastro claro de la supervisión.
Más detalle para infraestructuras y proveedores digitales
El artículo 21.5 encargó a la Comisión adoptar actos de ejecución con requisitos técnicos y metodológicos para un grupo de entidades digitales, y el Reglamento de Ejecución (UE) 2024/2690 lo hace. Abarca a los proveedores de servicios de DNS, los registros de nombres de dominio de primer nivel, los proveedores de computación en nube y de centros de datos, los de redes de distribución de contenidos, los proveedores de servicios gestionados y de servicios de seguridad gestionados, los mercados en línea, los motores de búsqueda en línea, las plataformas de redes sociales y los prestadores de servicios de confianza. Su anexo convierte cada uno de los diez ámbitos en requisitos detallados.
Para esas entidades el reglamento se aplica directamente y deja mucho menos margen de interpretación que la directiva. Para las demás sigue siendo una referencia práctica, porque muestra el nivel de detalle que los reguladores consideran adecuado: un directorio de proveedores, un plan de continuidad y recuperación con un contenido definido, procedimientos para el fin de la relación laboral o un esquema de clasificación de activos. Los proveedores de servicios gestionados merecen especial atención. Muchas empresas europeas de TI y seguridad de tamaño medio entran en esa categoría sin haberse considerado nunca reguladas, y lo descubren cuando un cliente les pregunta por su posición en NIS2.
ISO 27001 como punto de partida
La mayor parte del artículo 21 encaja con un sistema de gestión de seguridad de la información ISO 27001, y los considerandos citan la serie ISO 27000 como referencia para el enfoque que abarca todos los peligros.
- Análisis de riesgos: Apartados 6.1 y 8.2
- Gestión de incidentes: Anexo A 5.24 a 5.28
- Continuidad: Anexo A 5.29, 5.30 y 8.13
- Proveedores: Anexo A 5.19 a 5.22
- Desarrollo y vulnerabilidades: Anexo A 8.8 y 8.25 a 8.29
- Evaluación de la eficacia: Apartado 9
- Formación: Anexo A 6.3
- Criptografía: Anexo A 8.24
- Accesos y activos: Anexo A 5.9, 5.15 a 5.18, y 6.1 a 6.5
- Autenticación: Anexo A 8.5
Una organización con un SGSI que funciona rara vez parte de cero, y lo sensato es ampliarlo en lugar de montar un programa NIS2 paralelo. Las diferencias son concretas. ISO 27001 no impone los plazos de notificación del artículo 23, así que el proceso de incidentes necesita un paso de notificación con responsables de decisión identificados. No crea la responsabilidad de la dirección, así que el gobierno tiene que subir al órgano de dirección. Y no registra a la entidad ante una autoridad nacional.
Un certificado tampoco sustituye al cumplimiento. NIS2 no exige ISO 27001, y un certificado no demuestra que se cumpla la ley nacional, aunque sí es una evidencia sólida de que la mayoría de las medidas existen y se mantienen. Lo práctico es un único conjunto de controles que sirva para todos los marcos que necesita la empresa, como explicamos en nuestro artículo sobre gestionar ISO 27001 y ENS como un programa único.
Qué pasa cuando falta una medida
El apartado 4 establece que una entidad que detecte que no cumple alguna medida del apartado 2 debe adoptar sin demora indebida todas las medidas correctoras necesarias, adecuadas y proporcionadas. Detectar un hueco no es en sí el problema; dejarlo abierto sí lo es. Un registro de carencias con responsables, fechas previstas y avances es justo la evidencia que espera este apartado, y convence mucho más a un supervisor que un programa que dice no tener ninguna carencia.
El artículo 34 fija las sanciones por infracciones de los artículos 21 y 23. Los Estados miembros deben prever multas máximas de al menos 10 millones de euros o el 2 % del volumen de negocios anual mundial total para las entidades esenciales, y de al menos 7 millones de euros o el 1,4 % para las importantes, la cifra que resulte mayor en cada caso. Las leyes nacionales fijan las cuantías definitivas y los procedimientos. Las multas no son la única herramienta: los supervisores pueden dictar instrucciones vinculantes, ordenar auditorías y ordenar a las entidades que informen a los destinatarios de sus servicios sobre una ciberamenaza significativa y las medidas de protección que pueden adoptar. En el caso de las entidades esenciales, también pueden suspender temporalmente certificaciones o autorizaciones.
Dónde encaja Qalea
El artículo 21 es más fácil de cumplir cuando los diez ámbitos funcionan como un único programa y no como diez proyectos separados. La plataforma de Qalea vincula NIS2 al mismo conjunto de controles que usa para ISO 27001, el ENS y DORA, así que cada control y su evidencia se registran una vez y sirven para todos los marcos que necesita la empresa. El equipo de Qalea guía el trabajo, desde el análisis de riesgos hasta los informes que necesita el órgano de dirección según el artículo 20, y las empresas que ya gestionan su programa en otra herramienta pueden traer el material que tienen.
Varias de las medidas dependen de un trabajo de seguridad que funciona cada día, no de documentos: la detección de incidentes, la gestión de vulnerabilidades, las pruebas de eficacia y la formación. Qalea las cubre con EDR, SIEM y un SOC para la monitorización, gestión de la superficie de ataque y pruebas de intrusión para la exposición, y formación en concienciación con simulaciones de phishing, de modo que las evidencias que pide un supervisor salen de controles que funcionan de verdad. Hay más sobre la directiva en nuestra página temática de NIS2.
