Ultima revision
14 de junio de 2026

La fecha clave fue el 17 de octubre de 2024. Ese día venció el plazo para que los Estados miembros transpongan la Directiva (UE) 2022/2555, más conocida como NIS2. Y, sin embargo, a estas alturas la conversación en demasiadas empresas sigue anclada en una pregunta casi entrañable: “¿Nos aplica?”.
La respuesta, en una buena parte de los casos, es sí. Y no porque Bruselas haya decidido fastidiar a medio tejido empresarial europeo, sino porque la NIS2 se diseñó precisamente para corregir una debilidad muy concreta de su predecesora: el perímetro era demasiado estrecho, demasiado desigual entre países y demasiado complaciente con la idea de que la ciberseguridad podía quedarse en el sótano del departamento técnico.
Eso se ha acabado. La NIS2 mete a más sectores, endurece los requisitos mínimos de gestión del riesgo, obliga a la alta dirección a aprobar y supervisar medidas de ciberseguridad, y fija plazos de notificación de incidentes que ya no permiten la clásica coreografía corporativa de “vamos a ver internamente qué ha pasado y luego, si eso, ya informamos”. No. Primero se activa el reloj. Luego ya vendrán los powerpoints.
La página de la Comisión Europea dedicada a la NIS2 no trae una sorpresa de última hora. No es una filtración ni una interpretación revolucionaria. Pero sí importa por otra razón: consolida el mensaje político y operativo de Bruselas sobre qué espera de los Estados y de las organizaciones afectadas. Y, viendo el ritmo de transposición en varios países, ese recordatorio no sobra precisamente.
La NIS2 sustituye a la Directiva (UE) 2016/1148, la vieja NIS. La lógica del cambio es sencilla: la superficie de riesgo creció, la dependencia digital se disparó y el modelo anterior dejó demasiadas grietas. La nueva directiva amplía el alcance sectorial y trata de armonizar un mínimo común más exigente para toda la UE.
La pieza legal relevante aquí no es una sola obligación aislada, sino la arquitectura completa. El artículo 2 define el ámbito de aplicación; los anexos I y II detallan los sectores de “alta criticidad” y “otros sectores críticos”; el artículo 3 distingue entre entidades esenciales e importantes; el artículo 21 fija las medidas de gestión de riesgos de ciberseguridad; el artículo 23 regula la notificación de incidentes significativos; y los artículos 32 a 34 levantan el listón sancionador y supervisor.
¿Dónde está el giro más serio? En tres sitios.
Primero, en el alcance. NIS2 cubre sectores como energía, transporte, banca, infraestructuras de mercados financieros, salud, agua potable, aguas residuales, infraestructura digital, administración pública y espacio, entre otros del anexo I. A eso suma sectores del anexo II como servicios postales y de mensajería, gestión de residuos, químicos, alimentación, fabricación de determinados productos, proveedores digitales y organizaciones de investigación. Si tu empresa opera ahí y supera ciertos umbrales, no estás ante una recomendación elegante. Estás dentro.
Segundo, en la gobernanza. El artículo 20 obliga a los órganos de dirección a aprobar las medidas de gestión del riesgo, supervisar su aplicación y formarse en ciberseguridad. Esto es bastante más que pedir al consejo que “tome nota”. Significa que la responsabilidad ya no puede externalizarse al CISO como si fuera una avería técnica más. La ciberseguridad entra en la sala donde se aprueban presupuestos, apetito de riesgo y continuidad de negocio. Como debía haber ocurrido hace años, dicho sea de paso.
Tercero, en la disciplina de respuesta. El artículo 23 establece un esquema de notificación escalonada: alerta temprana en un plazo de 24 horas desde que la entidad tenga conocimiento de un incidente significativo; notificación del incidente en 72 horas; e informe final, a más tardar, un mes después. Si la empresa aún no tiene claro quién decide que algo es “significativo”, quién activa a legal, quién llama al regulador sectorial o al CSIRT y qué datos mínimos puede aportar en menos de un día, el problema no es jurídico. Es de preparación operativa.
La NIS original permitió que muchos directivos pensaran en la ciberregulación como algo para utilities, telecoms y poco más. La NIS2 rompe esa comodidad. Y lo hace con una combinación de sectores ampliados y una regla de tamaño que, salvo excepciones, toma como referencia a entidades medianas y grandes.
La Comisión Europea resume esa lógica de forma bastante clara: la directiva se aplica, por norma general, a entidades medianas y grandes que operen en los sectores cubiertos. Eso remite a la Recomendación 2003/361/CE sobre tamaño empresarial: mediana empresa suele implicar menos de 250 empleados y volumen de negocios anual no superior a 50 millones de euros o balance general anual no superior a 43 millones; gran empresa, por encima. Pero el matiz clave está en que NIS2 prevé excepciones. Algunas entidades quedan cubiertas con independencia de su tamaño si prestan servicios especialmente críticos o si así lo decide un Estado miembro.
Aquí es donde muchas organizaciones se engañan solas. No basta con mirar el número de empleados y respirar tranquilos. Hay que revisar actividad, posición en la cadena de suministro, dependencia sectorial y calificación nacional. Una empresa de infraestructura digital, un proveedor gestionado, un DNS, un trust service provider o un actor con un papel singular en un ecosistema crítico puede encontrarse dentro aunque no encaje en la caricatura del “gran operador nacional”.
Además, la NIS2 no vive en una urna. Interactúa con otras normas europeas y nacionales. Una entidad financiera, por ejemplo, puede estar bajo DORA y, al mismo tiempo, formar parte del universo NIS2 según cómo el Estado miembro articule la supervisión sectorial y las exclusiones. El artículo 4 de NIS2 trata la relación con actos sectoriales de la UE que establezcan requisitos equivalentes. En teoría, eso evita duplicidades absurdas. En la práctica, obliga a hacer lectura fina. Y ya sabemos cuánto gusta eso a algunas organizaciones: lo justo hasta que llega la inspección.
La NIS2 distingue entre entidades esenciales e importantes en el artículo 3. La diferencia importa porque condiciona el enfoque supervisor y el riesgo sancionador. Las entidades esenciales, en general, están sujetas a una supervisión más dura, incluida la supervisión ex ante; las importantes tienden más a la supervisión ex post, aunque eso no las convierte en invisibles.
Las entidades esenciales incluyen, entre otras, ciertos operadores de sectores del anexo I y entidades concretas como proveedores de redes públicas de comunicaciones electrónicas o servicios de confianza cualificados, dependiendo de cómo encajen en el texto. Las importantes abarcan buena parte del resto de entidades dentro de los sectores de los anexos I y II que cumplan los criterios de tamaño y actividad.
Conviene no simplificarlo demasiado porque la clasificación exacta depende del texto legal y de la transposición nacional. Pero hay una consecuencia práctica inmediata: si aún no has hecho un análisis formal de encaje para determinar si tu organización es esencial o importante, vas tarde. Y si lo has dejado en una nota interna sin validación jurídica ni traducción a controles, eso no es un programa de cumplimiento; es una coartada de corto recorrido.
La Comisión y ENISA llevan tiempo insistiendo en que la identificación de entidades es una pieza central del sistema. Los Estados miembros deben elaborar listas de entidades esenciales e importantes. Eso, a su vez, obliga a las empresas a entender qué autoridad competente les tocará, qué canal de notificación usarán y qué evidencias de cumplimiento deben poder enseñar.
Si hay un precepto que separa a las organizaciones que han entendido la NIS2 de las que siguen en fase decorativa, ese es el artículo 21. Ahí se fijan las medidas de gestión de riesgos de ciberseguridad. No son un menú opcional. Son el núcleo operativo de la directiva.
El artículo 21.2 enumera, entre otras, políticas de análisis de riesgos y seguridad de sistemas de información; gestión de incidentes; continuidad de negocio, como gestión de copias de seguridad y recuperación ante desastres, y gestión de crisis; seguridad de la cadena de suministro, incluidas las relaciones entre cada entidad y sus proveedores directos o prestadores de servicios; seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas de información, incluida la gestión y divulgación de vulnerabilidades; políticas y procedimientos para evaluar la eficacia de las medidas de gestión del riesgo; prácticas básicas de ciberhigiene y formación; políticas y procedimientos relativos al uso de criptografía y, cuando proceda, cifrado; seguridad de recursos humanos, control de acceso y gestión de activos; y uso de soluciones de autenticación multifactor o continua, comunicaciones seguras y sistemas seguros de comunicación de voz, vídeo y texto de emergencia, cuando proceda.
Eso suena largo porque lo es. Pero lo relevante no es la longitud de la lista, sino el cambio de estándar. NIS2 ya no se conforma con exigir “medidas técnicas y organizativas apropiadas” en abstracto, la frase favorita de media regulación tecnológica europea. Aquí da un desglose concreto de dominios de control. No prescribe una tecnología cerrada ni un framework único, pero deja poco espacio para la ambigüedad.
Y aquí aparece una tensión interesante. Muchas empresas creen que cumplir NIS2 consiste en alinear un puñado de políticas, reforzar el procedimiento de notificación y hacer una sesión de formación al consejo. Eso puede servir para una presentación al comité de auditoría. No sirve para demostrar madurez real si luego no existe gestión de activos fiable, clasificación de servicios críticos, mapeo de dependencias, backup segregado probado, inventario de proveedores críticos, proceso formal de vulnerabilidades o ejercicios de crisis.
La directiva no exige expresamente “zero trust”, “XDR” ni ninguna de las etiquetas favoritas del mercado. Exige algo más incómodo: coherencia verificable entre riesgo, controles, supervisión y respuesta. Menos marketing, más trazabilidad.
El reloj de la NIS2 arranca en cuanto la entidad tenga conocimiento de un incidente significativo. Y eso abre varias preguntas que en la práctica son endiabladamente complicadas.
La primera: ¿qué significa “tener conocimiento”? El texto no pretende que la empresa disponga de una investigación forense cerrada en 24 horas. La alerta temprana del artículo 23 sirve precisamente para advertir de que hay un incidente potencialmente significativo y, cuando sea posible, indicar si se sospecha que ha sido causado por actos ilícitos o malintencionados o si puede tener impacto transfronterizo. Dicho de otra forma: no se espera perfección, pero sí rapidez y un mínimo de criterio.
La segunda: ¿qué convierte un incidente en “significativo”? El artículo 23 conecta esa significatividad con incidentes que hayan causado o puedan causar perturbación operativa grave de los servicios o pérdidas financieras para la entidad afectada, o que hayan afectado o puedan afectar a otras personas físicas o jurídicas causando perjuicios materiales o inmateriales considerables. No es una fórmula matemática universal. Requiere umbrales internos, playbooks y capacidad de decisión bajo presión.
La tercera: ¿quién notifica y a quién? La NIS2 prevé notificación a la autoridad competente o al CSIRT según la arquitectura nacional. Eso significa que un grupo paneuropeo no puede permitirse una única plantilla global y esperar que funcione igual en todos los países. Hará falta coordinación central, sí, pero también adaptación local. Bienvenidos a la armonización europea: suficiente para aumentar el listón, no tanta como para ahorrarte el trabajo fino.
La cuarta: ¿cómo encaja con GDPR? Si el incidente implica una violación de seguridad de datos personales, entra en juego el artículo 33 del RGPD, que exige notificar a la autoridad de control en 72 horas desde que el responsable tenga constancia, salvo que sea improbable que la brecha entrañe riesgo para los derechos y libertades de las personas. En ciertos incidentes tendrás dos relojes, dos autoridades, dos lógicas de evaluación y la misma necesidad de no contradecirte entre una notificación y otra. Si esto aún se gestiona en silos entre seguridad, privacidad, legal y comunicación, la organización se está preparando para tropezar con cierta elegancia burocrática.
Uno de los avances más relevantes de la NIS2 está en su tratamiento de la cadena de suministro. El artículo 21.2.d obliga a abordar la seguridad de la cadena de suministro y la relación con proveedores directos y prestadores de servicios. No es casual. Europa ha visto ya demasiados incidentes donde el punto de entrada no era la víctima principal, sino un tercero con privilegios, software integrado o acceso operativo.
Esto tiene una consecuencia muy concreta para compras, vendor management y legal. El cuestionario de due diligence estándar, ese que a veces parece diseñado para confirmar que el proveedor sabe pronunciar “ISO 27001”, ya no basta. Harán falta cláusulas contractuales con obligaciones de seguridad proporcionales, requisitos de notificación de incidentes, derechos de auditoría o al menos de obtención de evidencias, control de subencargados o subprocesadores cuando haya datos personales, y una clasificación de terceros por criticidad real, no por volumen de gasto.
Aquí la relación con DORA es particularmente útil para el sector financiero. DORA, en sus artículos 28 a 30, entra mucho más a fondo en la gestión del riesgo de terceros ICT. NIS2 no replica ese nivel de detalle contractual y supervisor, pero sí marca una expectativa inequívoca: no puedes declarar “riesgo transferido al proveedor” y quedarte tan ancho. El regulador europeo lleva tiempo diciendo lo mismo con distintos acentos: externalizar una función no externaliza la responsabilidad.
Para entidades fuera del perímetro financiero, esa lección llega con menos glamour regulatorio y bastante más fricción operativa. Porque obliga a sentar en la misma mesa a seguridad, procurement, jurídico y negocio. Y ya sabemos que si nadie tiene mandato claro, la cadena de suministro acaba convertida en una hermosa colección de PDFs desactualizados.
El artículo 20 de la NIS2 no es un guiño simbólico a la gobernanza. Es una señal de que Bruselas quiere cortar una patología muy extendida: consejos de administración que tratan la ciberseguridad como un asunto técnico salvo el día después del incidente.
La directiva exige que los órganos de dirección aprueben las medidas de gestión del riesgo, supervisen su aplicación y puedan ser considerados responsables por infracciones cometidas por las entidades. Además, deben seguir formación para adquirir conocimientos y competencias suficientes que les permitan identificar riesgos y evaluar prácticas de gestión del riesgo.
Esto cambia dos cosas. Una jurídica y otra política.
La jurídica es obvia: la responsabilidad deja huella en actas, comités, decisiones de inversión, apetito de riesgo y supervisión. Si una autoridad pregunta por qué no se implantó MFA en accesos críticos, por qué no se probaron copias aisladas o por qué un proveedor estratégico no tenía requisitos de notificación, la respuesta “eso lo llevaba el equipo técnico” vale cada vez menos.
La política es más incómoda: la ciberseguridad compite por presupuesto con otras prioridades del negocio, pero NIS2 obliga a que esa competencia se decida de forma explícita. Si la dirección elige asumir una exposición, tendrá que poder justificarla. Y si ni siquiera sabe cuál es la exposición, peor todavía.
En entidades financieras, esta lógica encaja con una tendencia ya consolidada en DORA, en directrices EBA/EIOPA/ESMA sobre outsourcing y gobernanza, y en expectativas supervisoras del BCE. En sectores menos acostumbrados a este escrutinio, la NIS2 puede ser la primera norma que convierte la conversación sobre ciberresiliencia en una obligación de consejo y no en un informe trimestral decorativo.
Todo el mundo pregunta por las multas. Es comprensible. Pero si te obsesionas solo con la cifra, te pierdes la mitad del cuadro.
El artículo 34 fija topes administrativos para determinadas infracciones. Para entidades esenciales, las sanciones pueden alcanzar al menos 10 millones de euros o el 2% del volumen de negocios anual total mundial del ejercicio anterior de la empresa, si esta cifra es superior. Para entidades importantes, al menos 7 millones de euros o el 1,4% del volumen de negocios anual total mundial, la cifra que sea superior.
Son números relevantes. No tanto como los del RGPD en su escalón máximo, pero suficientes para que el consejo escuche. Aun así, el riesgo práctico más frecuente no es la multa hollywoodiense. Es la supervisión sostenida: requerimientos de información, órdenes de subsanación, auditorías de seguridad, instrucciones vinculantes, seguimiento de incumplimientos y, en algunos casos, impacto reputacional o contractual cuando el mercado descubre que la organización no controla sus servicios críticos.
Los artículos 32 y 33 detallan medidas supervisoras y de ejecución que incluyen, para entidades esenciales, inspecciones in situ, supervisión ex ante y otras herramientas. No hace falta llegar a la sanción máxima para que el coste de incumplir sea muy real. Basta con una autoridad competente que pida evidencias que la empresa no tiene, o que sí tiene, pero repartidas en tres sistemas, dos filiales y un excel con vocación suicida.
La Comisión Europea puede explicar la NIS2. Lo que no puede hacer es transponerla por los Estados miembros. Y ahí está uno de los grandes problemas de 2025: la aplicación real depende en buena medida de cómo cada país complete el cuadro institucional, defina autoridades competentes, articule registros de entidades, concrete procedimientos y coordine el encaje con normas sectoriales.
Eso no significa que las empresas puedan esperar a tener la ley nacional perfecta, comentada y consolidada. El núcleo de obligaciones de NIS2 ya es suficientemente claro como para trabajar. Pero sí significa que el programa de cumplimiento debe prever variaciones nacionales. No enormes, pero sí relevantes.
España es un caso particularmente sensible porque combina un ecosistema regulatorio ya cargado —ENS, RGPD y LOPDGDD, DORA para el sector financiero, regulación sectorial crítica, esquemas de notificación— con la necesidad de adaptar la transposición de NIS2 sin duplicar ni desordenar más de la cuenta. El reto no es solo aprobar una ley; es hacer que las empresas entiendan a qué autoridad responden, qué incidentes notifican por qué canal y cómo se coordinan ciberseguridad, protección de datos y continuidad operativa.
La empresa que opere en varios países de la UE tendrá un problema adicional: la tentación de esperar a que todo quede “homogéneo”. No va a ocurrir del todo. Habrá convergencia, sí; uniformidad plena, no. Así que conviene trabajar con un baseline europeo robusto y después adaptar localmente procedimientos, matrices de notificación y gobierno documental.
Para banca, seguros, mercados y buena parte del universo fintech, la pregunta natural es si DORA desplaza a la NIS2. La respuesta corta: en parte sí, pero no de forma simplista.
El artículo 4 de NIS2 prevé que cuando actos jurídicos sectoriales de la UE exijan a entidades de sectores cubiertos adoptar medidas de gestión del riesgo de ciberseguridad o notificar incidentes significativos, y esos requisitos sean al menos equivalentes a los de NIS2, se aplicarán esas disposiciones sectoriales. DORA es el ejemplo más obvio en finanzas. Sus obligaciones sobre gestión del riesgo ICT, clasificación y notificación de incidentes, pruebas de resiliencia y terceros ICT son más detalladas en muchos puntos.
Eso no convierte a las entidades financieras en ajenas a la lógica NIS2. Primero, porque forman parte de la infraestructura crítica que la directiva pretende reforzar como política pública europea. Segundo, porque grupos empresariales con actividades mixtas pueden tener entidades o filiales fuera del perímetro DORA y dentro de NIS2. Tercero, porque la coordinación entre autoridades no siempre elimina la necesidad interna de mantener un lenguaje común de resiliencia, incidentes y cadena de suministro.
Para una entidad financiera española, el enfoque sensato no es discutir qué sigla “manda” en abstracto, sino mapear obligaciones equivalentes y divergentes. DORA, por ejemplo, es más granular en terceros ICT críticos y en testing; NIS2 enfatiza la estructura general de seguridad nacional y cooperación entre autoridades. El peor enfoque posible sería crear dos programas paralelos: uno “para DORA” y otro “por si acaso para NIS2”. Eso solo multiplica costes y contradicciones.
Lo inteligente es construir un único marco de control que cubra gobierno, activos, incidentes, continuidad, proveedores, formación y reporting; luego, sobre ese baseline, ajustar evidencias y procedimientos a cada norma y supervisor. Menos compartimentos, más trazabilidad.
La fase de “sensibilización” ya ha durado bastante. Si tu organización entra o puede entrar en NIS2, hay cinco frentes donde el trabajo no admite mucha demora.
El primero es el análisis de aplicabilidad. No un ejercicio improvisado, sino una evaluación formal de sector, tamaño, servicios, presencia transfronteriza y posible clasificación como entidad esencial o importante. Ese análisis debe quedar documentado y validado por legal/compliance con participación de negocio y seguridad.
El segundo es el gap assessment contra el artículo 21. Aquí conviene ir dominio por dominio: políticas de riesgo, inventario de activos y servicios esenciales, detección y gestión de incidentes, continuidad y recuperación, gestión de crisis, seguridad de la cadena de suministro, vulnerabilidades, criptografía, control de acceso, MFA, formación, evaluación de eficacia. Si no puedes vincular cada dominio a controles reales, responsables, evidencias y frecuencia de revisión, todavía estás en fase de intención.
El tercero es el gobierno de incidentes. La organización necesita criterios claros de severidad, playbooks de escalado, matriz de notificación multirregulatoria y un proceso para emitir una alerta temprana en 24 horas sin esperar a tener todas las respuestas. Eso implica coordinación entre SOC, CISO, legal, DPO, comunicación, continuidad y alta dirección.
El cuarto es la cadena de suministro. Identificar terceros críticos, revisar contratos, exigir capacidades mínimas, definir obligaciones de notificación y establecer una cadencia de reevaluación. El proveedor “estratégico” no puede seguir siendo simplemente el que factura mucho.
El quinto es el consejo. Formación específica, reporting útil y decisiones trazables. Si la alta dirección firma políticas que no entiende o recibe métricas que no conectan con el riesgo operativo, NIS2 se convertirá en un ejercicio ceremonial. Y el regulador, con razón, no está para ceremonias.
Hay una fantasía corporativa muy resistente: pensar que una directiva nueva se resuelve con un proyecto finito, un paquete de políticas revisadas y un cierre formal en comité. Ojalá. NIS2 no es eso. Es un cambio permanente en la expectativa regulatoria sobre resiliencia operacional y ciberseguridad.
La prueba está en su propio diseño. Habla de gestión de riesgos, supervisión, formación del órgano de dirección, notificación, cooperación, cadena de suministro y continuidad. Todo eso es dinámico. Cambia con las amenazas, con los sistemas, con los proveedores y con la evolución del negocio. Una empresa puede “llegar” al primer umbral de cumplimiento y seguir estando mal preparada seis meses después si no mantiene disciplina operativa.
Además, NIS2 se inserta en un ciclo regulatorio europeo mucho más amplio. DORA en finanzas, CER para resiliencia de entidades críticas, el Cyber Resilience Act para seguridad de productos con elementos digitales, el RGPD para brechas de datos, eIDAS 2.0 para servicios de confianza e identidad digital. La dirección del viaje es evidente: más responsabilidad demostrable, menos tolerancia a la improvisación y mucha menos paciencia con el argumento de que la ciberseguridad era “demasiado técnica” para el negocio.
La directiva tiene sus zonas grises. La armonización no será absoluta. La coexistencia con marcos sectoriales exigirá cirugía fina. Y el éxito dependerá mucho de cómo actúen las autoridades nacionales, de la capacidad de ENISA para apoyar coherencia y de que la supervisión no derive en puro formalismo documental. Todo eso es cierto.
También es cierto lo contrario: la NIS2 corrige defectos evidentes del régimen anterior y coloca la ciberresiliencia en el sitio donde debía estar, que es la gobernanza de servicios esenciales y críticos. No se limita a pedir más controles técnicos. Pide responsabilidad, trazabilidad y capacidad de respuesta bajo presión. Ahí está el salto.
Para algunas organizaciones, la NIS2 será la primera vez que unan en un mismo programa ciberseguridad, continuidad, gestión de terceros, consejo de administración y reporting regulatorio. Para otras, especialmente en sectores más maduros, será una aceleración de obligaciones que ya se intuían. En ambos casos, la pregunta útil ya no es si la directiva es ambiciosa. Lo es. La pregunta es mucho más práctica: ¿tu entidad puede demostrar hoy, con evidencias y no con promesas, que sabe prevenir, detectar, responder y recuperarse?
Si la respuesta es dudosa, el plazo político ya pasó. Ahora empieza el trabajo incómodo. Que, curiosamente, es el único que sirve.
Guía de referencia
Todo sobre NIS2: artículos, obligaciones y plazos
Resumen semanal gratis
Suscríbete al resumen semanal y te avisamos de cada cambio en NIS2: entidades esenciales/importantes, notificación de incidentes y medidas mínimas.
¿Necesitas la checklist ya? Empieza un GAP Assessment NIS2 o descarga plantillas en el Marketplace.
NIS2 (Directiva UE 2022/2555) distingue entre entidades "esenciales" e "importantes" en sectores como energía, transporte, banca, salud, infraestructura digital y administración pública, generalmente medianas y grandes empresas.
Se exige una alerta temprana en un máximo de 24 horas, una notificación de incidente en 72 horas y un informe final en el plazo de un mes (art. 23).
NIS2 es una directiva, por lo que cada Estado miembro la transpone a su legislación nacional. Las obligaciones concretas y la autoridad competente dependen de la transposición de cada país.
Recursos oficiales
Descarga políticas, checklists y frameworks de cumplimiento elaborados por expertos en regulación NIS2.