Mapeo de evidencias de NIS2 con ISO 27001:2022 para 2026

El problema NIS2 de 2026 no es la concienciación, sino la prueba

Es lunes por la mañana, 08:35. María, la CISO recién nombrada de un proveedor B2B de servicios en la nube y servicios gestionados en rápido crecimiento, se incorpora a la reunión trimestral de riesgos del Consejo con una extensa evaluación de brechas NIS2 abierta en su portátil. La primera diapositiva parece tranquilizadora. Existen políticas. Existe una evaluación de riesgos. La respuesta a incidentes está documentada. Los proveedores están inventariados. Los escaneos de vulnerabilidades se ejecutan todos los meses.

Entonces, la presidenta formula la pregunta que cambia la reunión:

“¿Podemos demostrar que estas medidas funcionaron el trimestre pasado y podemos mostrar qué controles, propietarios y registros ISO 27001:2022 respaldan cada obligación NIS2?”

La sala queda en silencio.

El área jurídica sabe que la empresa entra en el ámbito de NIS2 porque presta servicios TIC gestionados y servicios en la nube a clientes de la UE. Cumplimiento sabe que el Article 21 exige medidas técnicas, operativas y organizativas de gestión del riesgo de ciberseguridad. Operaciones sabe que el equipo aplica parches en los sistemas, revisa proveedores y supervisa registros. Pero las evidencias están dispersas entre sistemas de tickets, exportaciones del SIEM, carpetas de políticas, hojas de cálculo, consolas en la nube, portales de proveedores y notas de reunión.

Nadie puede mostrar rápidamente una cadena defendible desde el Article 21 de NIS2 hasta el alcance, el riesgo, el control, la política, el propietario, el procedimiento, el registro operativo y el hallazgo de auditoría de ISO 27001:2022.

Ese es el verdadero reto de 2026.

Muchas organizaciones ya no se preguntan: “¿Estamos dentro del alcance de NIS2?”. Formulan una pregunta más exigente: “¿Podemos demostrar que nuestras medidas técnicas NIS2 realmente funcionan?”. La respuesta no puede ser una hoja de cálculo de mapeo puntual. Debe ser un modelo operativo vivo dentro del Sistema de Gestión de la Seguridad de la Información, donde las obligaciones legales se traducen en riesgos, políticas, controles, propietarios, evidencias y mejora continua.

El modelo de Clarysec utiliza ISO/IEC 27001:2022 como columna vertebral del sistema de gestión, el Article 21 de NIS2 como conjunto de obligaciones regulatorias, las cláusulas de políticas como reglamento operativo, Zenith Blueprint: hoja de ruta de 30 pasos para auditores como ruta de implantación, y Zenith Controls: guía de cumplimiento cruzado como mapa de cumplimiento cruzado para ISO 27001:2022, NIS2, DORA, GDPR, NIST CSF y aseguramiento de estilo COBIT.

Empieza por el alcance, porque la evidencia NIS2 comienza antes de los controles

Un fallo habitual en NIS2 consiste en saltar directamente a MFA, registro de eventos, respuesta a incidentes y gestión de vulnerabilidades antes de confirmar el alcance de la entidad, el alcance de los servicios y el alcance jurisdiccional.

NIS2 se aplica a entidades públicas y privadas cubiertas en sectores regulados que cumplen criterios de tamaño y actividad, con determinados tipos de entidad cubiertos con independencia de su tamaño. Las categorías digitales y TIC relevantes incluyen proveedores de servicios de computación en la nube, proveedores de servicios de centro de datos, proveedores de redes de distribución de contenidos, prestadores de servicios de confianza, proveedores de comunicaciones electrónicas públicas, proveedores de servicios gestionados, proveedores de servicios de seguridad gestionados, mercados en línea, motores de búsqueda en línea y plataformas de redes sociales.

Para proveedores de servicios en la nube, plataformas SaaS, MSP, MSSP y proveedores de infraestructura digital, este ejercicio de delimitación de alcance no es teórico. El Article 3 exige a los Estados miembros distinguir entre entidades esenciales e importantes. El Article 27 exige a ENISA mantener un registro para varios proveedores digitales y TIC, incluidos proveedores de servicios DNS, registros de nombres TLD, proveedores de servicios de registro de nombres de dominio, proveedores de servicios de computación en la nube, proveedores de servicios de centro de datos, proveedores de redes de distribución de contenidos, proveedores de servicios gestionados, proveedores de servicios de seguridad gestionados, mercados en línea, motores de búsqueda en línea y plataformas de redes sociales.

ISO 27001:2022 aporta la estructura adecuada. Las cláusulas 4.1 a 4.4 exigen que la organización comprenda las cuestiones externas e internas, las partes interesadas, los requisitos, las interfaces y las dependencias, y que después defina el alcance del SGSI. NIS2 debe incorporarse aquí, no quedar aislada en un memorando jurídico.

Un registro práctico de alcance NIS2 debe incluir:

• Análisis de la entidad jurídica y establecimiento en la UE
• Sector NIS2 y categoría de servicio
• Condición de entidad esencial o importante, cuando esté confirmada por la legislación nacional o por designación de la autoridad
• Relevancia para el registro de ENISA, cuando sea aplicable
• Servicios críticos prestados a clientes
• Redes y sistemas de información que soportan esos servicios
• Dependencias de proveedores de nube, centro de datos, telecomunicaciones, monitorización de seguridad, identidad y software
• Vínculos con DORA, GDPR, contratos con clientes y obligaciones sectoriales específicas
• Repositorios de evidencias, propietarios del sistema y cadencia de revisión

Aquí también debe separarse correctamente DORA. NIS2 reconoce que, cuando un acto jurídico sectorial específico de la UE impone obligaciones equivalentes de gestión del riesgo de ciberseguridad o de notificación de incidentes, ese régimen sectorial específico se aplica en lugar de las disposiciones correspondientes de NIS2. Para las entidades financieras cubiertas, DORA es generalmente el régimen operativo de ciberseguridad y notificación de incidentes TIC. DORA se aplica desde el 17 de enero de 2025 y cubre la gestión del riesgo TIC, la notificación de incidentes, las pruebas de resiliencia operativa digital, el riesgo de terceros TIC y la supervisión de proveedores terceros TIC críticos.

Por tanto, un grupo fintech puede tener tratamientos de cumplimiento distintos dentro de una misma estructura corporativa. La entidad de pagos puede estar principalmente sujeta a DORA. La filial MSP puede estar directamente sujeta a NIS2. Una plataforma compartida en la nube puede dar soporte a ambas. La respuesta madura no consiste en duplicar controles. Consiste en un único modelo de evidencias del SGSI que pueda servir a múltiples perspectivas regulatorias.

ISO 27001:2022 como sistema operativo de cumplimiento NIS2

El Article 21 de NIS2 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos sobre las redes y sistemas de información y para prevenir o minimizar el impacto de los incidentes sobre los destinatarios de los servicios y otros servicios.

ISO 27001:2022 es especialmente adecuada para operativizar ese requisito porque impone tres disciplinas.

Primero, gobierno. Las cláusulas 5.1 a 5.3 exigen compromiso de la alta dirección, alineación con la dirección estratégica, dotación de recursos, comunicación, asignación de responsabilidades y una política de seguridad de la información documentada. Esto se alinea directamente con el Article 20 de NIS2, que exige a los órganos de dirección aprobar las medidas de gestión del riesgo de ciberseguridad, supervisar su implantación y recibir formación.

Segundo, tratamiento de riesgos. Las cláusulas 6.1.1 a 6.1.3 exigen un proceso repetible de evaluación de riesgos, propietarios del riesgo, evaluación de riesgos, opciones de tratamiento, selección de controles, una Declaración de Aplicabilidad, un plan de tratamiento de riesgos y aprobación del riesgo residual.

Tercero, control operativo. La cláusula 8.1 exige a la organización planificar, implementar y controlar los procesos del SGSI, mantener información documentada, controlar cambios y gestionar procesos, productos y servicios proporcionados externamente que sean relevantes para el SGSI.

Esto convierte NIS2 de una lista de verificación legal en un modelo operativo de controles.

Cada fila necesita un propietario, una fuente de registros y un método de muestreo. Si faltan esos elementos, la organización tiene una aspiración de control, no un control.

La política es donde NIS2 se convierte en comportamiento operativo

Las políticas a menudo se tratan como plantillas. Para NIS2, eso es peligroso. Un regulador o auditor no quedará convencido por una carpeta de políticas si las políticas no asignan propiedad, definen registros, se vinculan a riesgos y generan evidencias.

La Política de Cumplimiento Legal y Normativo para organizaciones establece la base en la cláusula 6.2.1:

Todas las obligaciones legales y regulatorias deben mapearse con políticas, controles y propietarios específicos dentro del Sistema de Gestión de la Seguridad de la Información (SGSI).

Esa cláusula es el puente entre NIS2 y ISO 27001:2022. El Article 21 de NIS2 no se limita a figurar como requisito externo. Se descompone en obligaciones de política, se mapea a controles, se asigna a propietarios y se prueba mediante evidencias.

Para organizaciones más pequeñas, la Política de Cumplimiento Legal y Normativo para pymes mantiene el mismo concepto de forma ligera. La cláusula 5.1.1 exige:

El Director General debe mantener un Registro de Cumplimiento simple y estructurado que enumere:

La frase es deliberadamente práctica. Las pymes no necesitan una implementación GRC compleja para empezar. Necesitan un registro de cumplimiento que recoja obligación, aplicabilidad, propietario, política, evidencia y cadencia de revisión.

El tratamiento de riesgos convierte después la obligación en acción. La Política de gestión de riesgos para organizaciones, cláusula 6.4.2, establece:

El Responsable de Riesgos debe asegurar que los tratamientos sean realistas, estén acotados en el tiempo y estén mapeados con controles del Anexo A de ISO/IEC 27001.

Para pymes, la Política de gestión de riesgos - pyme, cláusula 5.1.2, proporciona el registro mínimo viable del riesgo:

Cada entrada de riesgo debe incluir: descripción, probabilidad, impacto, puntuación, propietario y plan de tratamiento.

Estas cláusulas importan porque NIS2 está explícitamente basada en riesgos y en la proporcionalidad. El Article 21 espera que las medidas reflejen el estado del arte, los estándares relevantes, el coste de implantación, la exposición al riesgo, el tamaño, la probabilidad y severidad de los incidentes, incluido el impacto social y económico. Un registro de riesgos sin propietarios ni planes de tratamiento no puede demostrar proporcionalidad.

La Política de Seguridad de la Información para organizaciones completa el principio de evidencias en la cláusula 6.6.1:

Todos los controles implantados deben ser auditables, estar respaldados por procedimientos documentados y contar con evidencias conservadas de su funcionamiento.

Esa es la diferencia entre tener un programa NIS2 y tener un programa de evidencias NIS2.

La ruta de Clarysec desde el mapeo hasta la operación

Zenith Blueprint es valioso porque refleja cómo piensan los auditores. No preguntan solo si un control existe. Preguntan por qué fue seleccionado, dónde está documentado, cómo opera, quién lo posee, qué evidencia lo demuestra y cómo lo mejora la organización.

En la fase de Gestión de riesgos, el paso 13 indica a los equipos que añadan trazabilidad entre riesgos, controles y cláusulas:

✓ Mapear controles con riesgos: en el plan de tratamiento de su Registro de Riesgos, ha enumerado determinados controles para cada riesgo. Puede añadir una columna “Referencia de control del Anexo A” a cada riesgo e indicar los números de control.

Para NIS2, esto significa que el registro de riesgos y la Declaración de Aplicabilidad deben mostrar por qué son aplicables controles como 8.8 Gestión de vulnerabilidades técnicas, 5.19 Seguridad de la información en las relaciones con proveedores y 5.24 Planificación y preparación de la gestión de incidentes.

El paso 14 de Zenith Blueprint hace explícito el mapeo regulatorio:

Para cada regulación, si es aplicable, puede crear una tabla de mapeo simple (podría ser un apéndice en un informe) que enumere los requisitos clave de seguridad de la regulación y los controles/políticas correspondientes de su SGSI.

Esto evita la fragmentación. La seguridad de los datos personales bajo GDPR, la notificación de incidentes NIS2, las pruebas de resiliencia TIC de DORA y los compromisos de seguridad con clientes pueden basarse todos en las mismas evidencias: revisiones de accesos, remediación de vulnerabilidades, registros de eventos, pruebas de copias de seguridad, revisiones de proveedores e informes de incidentes.

El paso 19 pasa del diseño a la operación:

Vincule cada uno de estos documentos con el control correspondiente en su SoA o manual del SGSI. Servirán como prueba de implantación y referencia interna.

El conjunto documental del paso 19 incluye seguridad de endpoints, gestión de accesos, autenticación, configuraciones de referencia seguras, registro y supervisión, gestión de parches, gestión de vulnerabilidades, planificación de capacidad e informes de operaciones de TI. Estos son exactamente los documentos operativos necesarios para que las medidas técnicas NIS2 sean auditables.

El paso 26 explica cómo deben recopilarse las evidencias de auditoría:

A medida que recopile evidencias, registre sus hallazgos. Indique dónde las cuestiones cumplen el requisito (hallazgos positivos) y dónde no lo hacen (posibles no conformidades u observaciones).

Para NIS2, esto significa muestrear evidencias antes de que un regulador, evaluador de cliente o auditor de certificación las solicite.

El papel de cumplimiento cruzado de Zenith Controls

Zenith Controls no es un marco de controles separado. Es la guía de cumplimiento cruzado de Clarysec para mapear los controles ISO/IEC 27001:2022 e ISO/IEC 27002:2022 con controles relacionados, expectativas de auditoría y marcos externos. Ayuda a los equipos a entender cómo un control ISO 27001:2022 puede respaldar NIS2, DORA, GDPR, NIST CSF 2.0 y aseguramiento de estilo COBIT.

Tres controles ISO 27001:2022 son especialmente importantes para el mapeo de evidencias NIS2.

El control 5.1 Políticas para la seguridad de la información es el punto de entrada porque el Article 21 de NIS2 incluye análisis de riesgos y políticas de seguridad de los sistemas de información. Si una medida técnica NIS2 no se refleja en una política, es difícil gobernarla y auditarla de forma coherente.

El control 5.36 Cumplimiento de políticas, normas y estándares de seguridad de la información es la prueba de realidad. Conecta los requisitos de política con la conformidad real respecto de reglas internas, estándares y obligaciones externas. En términos de NIS2, aquí es donde una organización pregunta si está haciendo lo que dice su mapeo del Article 21.

El control 8.8 Gestión de vulnerabilidades técnicas es una de las áreas de prueba más difíciles de 2026. La gestión de vulnerabilidades es directamente relevante para la adquisición, desarrollo, mantenimiento, gestión y divulgación de vulnerabilidades de forma segura. También respalda las pruebas y la remediación de DORA, la responsabilidad proactiva de seguridad bajo GDPR, los resultados Identify y Protect de NIST CSF, y el muestreo de auditoría ISO 27001.

Los estándares de apoyo pueden mejorar el diseño sin exigir certificaciones adicionales. ISO/IEC 27002:2022 proporciona orientación de implantación para los controles del Anexo A. ISO/IEC 27005 respalda la gestión de riesgos de seguridad de la información. ISO/IEC 27017 respalda la seguridad en la nube. ISO/IEC 27018 respalda la protección de la información de identificación personal en escenarios de encargados del tratamiento en nube pública. ISO 22301 respalda la continuidad del negocio. ISO/IEC 27035 respalda la gestión de incidentes. ISO/IEC 27036 respalda la seguridad en las relaciones con proveedores.

El objetivo no es acumular estándares por sí mismos. El objetivo es diseñar mejores evidencias.

Ejemplo práctico: crear un paquete de evidencias NIS2 de vulnerabilidades

Consideremos la plataforma SaaS de María. Presta servicio a clientes manufactureros de la UE y depende de servicios en la nube, componentes de código abierto, canalizaciones de CI/CD y monitorización gestionada. Su informe de brechas dice “gestión de vulnerabilidades implementada”, pero las evidencias están dispersas entre escáneres, Jira, GitHub, herramientas de configuración en la nube y tickets de cambio.

Puede construirse un paquete de evidencias preparado para NIS2 en un sprint focalizado.

Paso 1: Definir el escenario de riesgo

Riesgo: una vulnerabilidad explotable en una aplicación expuesta a internet, una dependencia o un componente en la nube causa indisponibilidad del servicio, acceso no autorizado o exposición de datos de clientes.

El registro de riesgos debe incluir descripción, probabilidad, impacto, puntuación, propietario y plan de tratamiento. El plan de tratamiento debe referenciar el control 8.8 Gestión de vulnerabilidades técnicas de ISO 27001:2022, además de controles relacionados de inventario de activos, desarrollo seguro, registro de eventos, control de acceso, gestión de proveedores y respuesta a incidentes.

Paso 2: Mapear el riesgo con el Article 21 de NIS2

El riesgo respalda los requisitos del Article 21 relativos a adquisición, desarrollo y mantenimiento seguros, gestión y divulgación de vulnerabilidades, análisis de riesgos, gestión de incidentes, seguridad de la cadena de suministro y evaluación de la eficacia de los controles.

Paso 3: Anclar las reglas operativas en la política

Utiliza un procedimiento de gestión de vulnerabilidades, un estándar de desarrollo seguro, requisitos de gestión de parches, una política de pruebas de seguridad y reglas de evidencias de auditoría.

La Política de pruebas de seguridad y red teaming para organizaciones, cláusula 6.1, establece:

Tipos de pruebas: el programa de pruebas de seguridad debe incluir, como mínimo: (a) escaneos de vulnerabilidades, consistentes en escaneos automatizados semanales o mensuales de redes y aplicaciones para identificar vulnerabilidades conocidas; (b) pruebas de penetración, consistentes en pruebas manuales en profundidad de sistemas o aplicaciones específicos por parte de evaluadores cualificados para identificar debilidades complejas; y (c) ejercicios de red teaming, consistentes en simulaciones basadas en escenarios de ataques reales, incluida la ingeniería social y otras tácticas, para probar las capacidades de detección y respuesta de la organización en su conjunto.

Esa cláusula crea una línea base defendible para las pruebas. También se alinea con la expectativa de DORA de realizar pruebas recurrentes y basadas en riesgos de resiliencia operativa digital para las entidades financieras cubiertas.

Paso 4: Definir los metadatos de las evidencias

La Política de Auditoría y Supervisión del Cumplimiento - pyme, cláusula 6.2.3, establece:

Los metadatos (por ejemplo, quién los recopiló, cuándo y desde qué sistema) deben documentarse.

Para evidencias de vulnerabilidades, el paquete debe recoger:

• Nombre y configuración del escáner
• Fecha y hora del escaneo
• Alcance de activos y exclusiones
• Hallazgos críticos y altos
• Número de ticket y propietario
• Decisión de parcheo o mitigación
• Decisión de aceptación del riesgo, cuando aplique
• Fecha de remediación
• Escaneo de validación
• Enlace al registro de cambio
• Propietario de la excepción y fecha de caducidad

Paso 5: Añadir evidencias de registro de eventos

La Política de registro y supervisión - pyme, cláusula 5.4.4, incluye registros del sistema como:

Registros del sistema: cambios de configuración, acciones administrativas, instalaciones de software, actividad de parcheo

Un ticket de parche por sí solo puede no demostrar que el cambio se produjo. Los registros de configuración, las acciones administrativas y los registros de instalación de software refuerzan la cadena de evidencias.

Paso 6: Ejecutar una auditoría de muestra

Selecciona cinco vulnerabilidades críticas o altas del trimestre anterior. Para cada elemento, verifica que el activo estuviera en el inventario, que el escáner detectara el hallazgo, que se abriera un ticket dentro del SLA, que se asignara un propietario, que la remediación coincidiera con la severidad y explotabilidad, que los registros muestren el cambio, que la validación confirme el cierre y que cualquier excepción cuente con aprobación del propietario del riesgo y fecha de caducidad.

Ese sprint produce un paquete de evidencias de vulnerabilidades preparado para NIS2 y una muestra de auditoría interna ISO 27001:2022.

La seguridad de proveedores es gobernanza del ecosistema

El Article 21 de NIS2 exige seguridad de la cadena de suministro, incluidos los aspectos de seguridad relativos a las relaciones con proveedores directos y proveedores de servicios. También espera que las organizaciones consideren las vulnerabilidades de proveedores, la calidad de los productos, las prácticas de ciberseguridad de los proveedores y las prácticas de desarrollo seguro.

Aquí es donde la primera versión del informe de brechas de María era más débil. Enumeraba proveedores, pero no demostraba diligencia debida, cláusulas contractuales de seguridad, supervisión ni preparación para la salida.

La Política de Seguridad de Terceros y Proveedores proporciona el anclaje de política. La implantación relacionada puede apoyarse en la Política de Desarrollo Seguro, la Política de Concienciación y Formación en Seguridad de la Información, la Política de gestión de vulnerabilidades y parches, la Política de Controles Criptográficos, la Política de Control de Acceso y la Política de Acceso Remoto.

Un único registro de evidencias de proveedores puede respaldar NIS2, DORA e ISO 27001:2022.

Esta tabla evita cuestionarios duplicados, registros duplicados y propiedad de controles contradictoria.

Un único flujo de trabajo de incidentes para NIS2, DORA y GDPR

El Article 23 de NIS2 exige notificar los incidentes significativos sin demora indebida. Establece una cronología por fases: alerta temprana dentro de las 24 horas desde el conocimiento, notificación del incidente dentro de las 72 horas con una evaluación inicial de severidad o impacto e indicadores de compromiso disponibles, actualizaciones intermedias si se solicitan y un informe final no más tarde de un mes después de la notificación del incidente.

DORA tiene un ciclo de vida similar para entidades financieras: detección, clasificación, registro de eventos, evaluación de severidad, escalado, comunicación con clientes, notificación a autoridades, análisis de causa raíz y remediación. GDPR añade el análisis de violación de seguridad de datos personales, incluidos los roles de responsable y encargado del tratamiento, el impacto en los interesados y el plazo de notificación de 72 horas cuando aplique.

El diseño correcto no son tres procesos de incidentes. Es un único flujo de trabajo de incidentes con ramas de decisión regulatorias.

La Política de respuesta a incidentes - pyme, cláusula 5.4.1, establece:

Todas las investigaciones de incidentes, hallazgos y acciones correctivas deben registrarse en un registro de incidentes mantenido por el Director General.

Un registro de incidentes sólido debe incluir:

El vínculo con GDPR no debe subestimarse. Las autoridades competentes de NIS2 pueden informar a las autoridades de control de GDPR cuando los fallos de gestión del riesgo de ciberseguridad o de notificación puedan implicar una violación de seguridad de datos personales. Por tanto, el SGSI debe hacer que la evaluación de privacidad forme parte del triaje de incidentes, no que sea una consideración posterior.

Cómo auditores y reguladores probarán tus evidencias NIS2

Una organización preparada para 2026 debe esperar que el mismo control se pruebe desde distintas perspectivas.

Un auditor ISO 27001:2022 comenzará por el SGSI. Preguntará si las obligaciones NIS2 están identificadas como requisitos de partes interesadas, si el alcance del SGSI cubre servicios y dependencias relevantes, si los riesgos se evalúan y tratan, si la Declaración de Aplicabilidad justifica los controles aplicables y si los registros demuestran el funcionamiento.

Una autoridad competente NIS2 se centrará en los resultados legales. Puede preguntar si se abordan todas las medidas del Article 21, si los controles son adecuados y proporcionados, si la dirección aprobó y supervisa las medidas, y si la notificación de incidentes puede cumplir los plazos exigidos.

Un supervisor DORA, para entidades financieras cubiertas, probará la gestión del riesgo TIC, la clasificación de incidentes, las pruebas de resiliencia, el riesgo de terceros, los acuerdos contractuales, el riesgo de concentración y las estrategias de salida.

Un revisor de GDPR comprobará si las medidas técnicas y organizativas protegen los datos personales, si la evaluación de violaciones de seguridad está integrada en la gestión de incidentes, si los roles de responsable y encargado del tratamiento están claros y si existen registros de responsabilidad proactiva.

Un evaluador de estilo NIST CSF 2.0 o COBIT 2019 se centrará en la gobernanza, la propiedad del riesgo, las métricas de desempeño, los resultados actuales y objetivo, la capacidad del proceso y la alineación con el apetito de riesgo de la organización.

La Política de Auditoría y Supervisión del Cumplimiento para organizaciones, cláusula 3.4, recoge el propósito de las evidencias:

Generar evidencias defendibles y una pista de auditoría en apoyo de requerimientos regulatorios, procedimientos legales o solicitudes de aseguramiento de clientes.

Ese es el estándar operativo hacia el que deben avanzar los equipos NIS2.

Responsabilidad de la dirección: el Consejo no puede delegar NIS2 y desentenderse

El Article 20 de NIS2 exige que los órganos de dirección de entidades esenciales e importantes aprueben las medidas de gestión del riesgo de ciberseguridad, supervisen su implantación y reciban formación. Los miembros de los órganos de dirección pueden ser considerados responsables de infracciones, conforme a las normas nacionales de responsabilidad.

Esto se alinea con los requisitos de liderazgo de ISO 27001:2022. La alta dirección debe asegurar que la política y los objetivos de seguridad de la información se alineen con la dirección estratégica, integrar los requisitos del SGSI en los procesos de la organización, proporcionar recursos, comunicar su importancia, asignar responsabilidades y promover la mejora continua.

Un Consejo no necesita exportaciones brutas de escáneres ni registros SIEM completos. Necesita aseguramiento apto para la toma de decisiones.

Un paquete trimestral de evidencias NIS2 para el Consejo debe incluir:

1. Cambios de alcance y estado regulatorio
2. Principales riesgos NIS2 y estado de tratamiento
3. Panel de eficacia de controles del Article 21
4. Incidentes significativos, cuasi incidentes y decisiones de notificación
5. Excepciones de riesgo de proveedores y de la nube
6. Hallazgos de auditoría interna, acciones correctivas y evidencias vencidas

Este paquete proporciona a la dirección la información necesaria para aprobar medidas, cuestionar excepciones y aceptar el riesgo residual.

El modelo operativo Clarysec para 2026

Operativizar las medidas técnicas NIS2 con ISO 27001:2022 requiere un modelo simple pero disciplinado:

• Delimitar el alcance de NIS2, DORA, GDPR y obligaciones contractuales dentro del SGSI
• Mapear obligaciones con riesgos, políticas, controles, propietarios y evidencias
• Utilizar la Declaración de Aplicabilidad como fuente fehaciente de controles
• Crear paquetes de evidencias para áreas de alto riesgo del Article 21
• Integrar la notificación de incidentes en un único flujo de trabajo regulatorio
• Tratar la seguridad de proveedores como un ciclo de vida, no como un cuestionario
• Ejecutar auditorías internas con muestras reales
• Informar sobre la eficacia de los controles a los órganos de dirección
• Mejorar a partir de incidentes, hallazgos de auditoría, pruebas y cambios regulatorios

Para María, el punto de inflexión fue darse cuenta de que no necesitaba un proyecto NIS2 separado. Necesitaba un motor de evidencias del SGSI más sólido.

Las políticas de Clarysec, Zenith Blueprint y Zenith Controls están diseñados para funcionar conjuntamente. Las políticas definen el comportamiento esperado y los registros. Zenith Blueprint proporciona la ruta de implantación y auditoría en 30 pasos. Zenith Controls ofrece el mapeo de cumplimiento cruzado para que NIS2, ISO 27001:2022, DORA, GDPR, NIST CSF y el aseguramiento de estilo COBIT puedan gestionarse como un único programa coherente.

Siguiente paso: construye tu mapa de evidencias de NIS2 a ISO 27001:2022

Si tu trabajo NIS2 aún vive en una hoja de cálculo de brechas, 2026 es el año para operativizarlo.

Empieza con una medida técnica de alto riesgo, como la gestión de vulnerabilidades, la gestión de incidentes o la seguridad de proveedores. Mapéala con riesgos ISO 27001:2022, políticas, controles del Anexo A, propietarios, procedimientos y evidencias. Después muestrea los registros del trimestre anterior y formula una pregunta exigente: ¿satisfaría esto a un regulador, a un evaluador de cliente y a un auditor ISO 27001:2022?

Clarysec puede ayudarte a construir esa respuesta utilizando la biblioteca de políticas, Zenith Blueprint y Zenith Controls.

El objetivo no es más documentación. El objetivo son evidencias defendibles y repetibles de que tus medidas técnicas NIS2 realmente funcionan.