⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

Responsabilidad del consejo de administración con arreglo a NIS2: evidencias ISO 27001

Igor Petreski
14 min read
Diagrama sobre la responsabilidad del consejo de administración con arreglo a NIS2 y las evidencias de gobernanza ISO 27001

El correo llegó a la bandeja de entrada de María a las 08:15 de un lunes por la mañana. Como CISO de un proveedor europeo de servicios en la nube en rápido crecimiento, estaba acostumbrada a los mensajes urgentes, pero este era distinto.

El director financiero había reenviado un cuestionario de seguridad de un cliente al director general, al secretario del consejo de administración y a María. El asunto era breve: “Se requieren evidencias de responsabilidad del órgano de administración con arreglo a NIS2 antes de la renovación”.

El cliente no pedía otro informe de pruebas de penetración. Quería saber si el consejo de administración había aprobado las medidas de gestión de riesgos de ciberseguridad, cómo se supervisaba la implantación, si la alta dirección había recibido formación sobre riesgo cibernético, cómo se escalaban los incidentes significativos y cómo se revisaban los riesgos de proveedores a nivel directivo. El director general añadió una línea: “María, ¿cuál es nuestra exposición y cómo demostramos diligencia debida? El consejo lo necesita la semana que viene”.

Ese es el momento en que NIS2 se vuelve real para muchos proveedores SaaS, de servicios en la nube, MSP, MSSP, centros de datos, fintech e infraestructuras digitales. La Directiva (UE) 2022/2555 no trata la ciberseguridad como un problema del departamento técnico. Convierte el riesgo cibernético en una cuestión de responsabilidad del órgano de administración.

NIS2 Article 20 exige que los órganos de administración de entidades esenciales e importantes aprueben las medidas de gestión de riesgos de ciberseguridad, supervisen su implantación y reciban formación. También permite a los Estados miembros establecer responsabilidad por infracciones. Article 21 define después la base práctica: análisis de riesgos, políticas de seguridad, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, adquisición y desarrollo seguros, evaluación de la eficacia, higiene cibernética, formación, criptografía, seguridad de recursos humanos, control de acceso, gestión de activos y autenticación.

Para las organizaciones que ya utilizan ISO/IEC 27001:2022, la estructura resulta familiar. La diferencia está en la audiencia y en la carga probatoria. La pregunta ya no es solo: “¿Tenemos controles de seguridad?”. Es: “¿Puede el consejo de administración demostrar que aprobó, entendió, financió, revisó, cuestionó y mejoró esos controles?”.

Ahí es donde ISO/IEC 27001:2022 se convierte en un sistema de gobernanza defendible. El enfoque de Clarysec consiste en utilizar ISO/IEC 27001:2022 como base de evidencias, Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint como hoja de ruta de implantación, las políticas de Clarysec como artefactos preparados para el consejo de administración y Zenith Controls: The Cross-Compliance Guide Zenith Controls como guía de mapeo entre marcos para NIS2, DORA, RGPD de la UE, NIST CSF 2.0, COBIT 2019 y expectativas de auditoría.

Por qué la responsabilidad del consejo de administración con arreglo a NIS2 cambia la conversación sobre ciberseguridad

NIS2 no pide a los administradores que se conviertan en ingenieros de cortafuegos. Les exige gobernar. Esa distinción importa.

Un CISO puede mostrar informes de vulnerabilidades, cobertura de MFA, paneles de protección de endpoints y puntuaciones de postura en la nube. Son señales operativas útiles, pero no demuestran automáticamente la supervisión del órgano de administración. Un regulador, un cliente empresarial, un auditor de certificación o un evaluador del sector financiero buscará una cadena de evidencias de gobernanza:

  1. La organización evaluó si NIS2 le aplica y documentó la base de dicha conclusión.
  2. El consejo de administración o la alta dirección aprobó el marco de gestión de riesgos de ciberseguridad.
  3. Se definieron el apetito de riesgo y los umbrales de tolerancia.
  4. Los riesgos cibernéticos altos se escalaron y revisaron.
  5. Se aprobaron las decisiones de tratamiento de riesgos, incluido el riesgo residual aceptado.
  6. Los procedimientos de notificación de incidentes reflejan las obligaciones de 24 horas, 72 horas e informe final cuando resulten aplicables.
  7. Las dependencias de proveedores y de servicios en la nube están mapeadas y sujetas a gobernanza.
  8. La revisión por la dirección incluye hallazgos de auditoría, tendencias de incidentes, métricas y acciones de mejora.
  9. La alta dirección recibió formación adecuada a su responsabilidad.
  10. Las decisiones, excepciones y escalados son trazables.

Aquí es donde fallan muchos manuales de seguridad tradicionales. Comprar una herramienta “conforme con NIS2” no demuestra supervisión del consejo de administración. Firmar una política y archivarla no evidencia implantación. Delegar íntegramente la ciberseguridad en el CISO no satisface el deber de supervisión del órgano de administración.

ISO/IEC 27001:2022 resuelve este problema porque plantea la seguridad de la información como un sistema de gestión estratégico, basado en riesgos e integrado en los procesos de la organización. Sus cláusulas sobre contexto, partes interesadas, obligaciones legales, alcance, liderazgo, evaluación de riesgos, tratamiento de riesgos, control operacional, evaluación del desempeño, auditoría interna, revisión por la dirección y mejora continua crean la estructura que un consejo de administración necesita para demostrar diligencia debida.

Zenith Blueprint lo hace operativo en la fase ISMS Foundation & Leadership, Step 3:

“La cláusula 5.1 trata sobre liderazgo y compromiso. ISO 27001 exige que la alta dirección demuestre liderazgo respaldando el SGSI, proporcionando recursos, promoviendo la concienciación, asegurando que se asignen roles, integrando el SGSI en los procesos de negocio y apoyando la mejora continua”.

Ese es el modelo operativo que subyace a NIS2 Article 20. El consejo de administración no necesita aprobar cada ticket técnico, pero sí debe aprobar el modelo de gobernanza, comprender los riesgos materiales, asegurar los recursos y supervisar la implantación.

El paquete de evidencias para el consejo de administración que NIS2 exige en la práctica

Un error habitual es tratar las evidencias de NIS2 como una nota jurídica acompañada de una carpeta de políticas. Eso rara vez satisface a un evaluador riguroso. La responsabilidad del consejo de administración requiere prueba de gobernanza activa, no documentación pasiva.

Un paquete sólido de evidencias NIS2 para el consejo de administración debe conectar las obligaciones legales con las decisiones del consejo, los controles y los ciclos de revisión.

Artefacto de evidenciaPregunta de responsabilidad del consejo de administración que respondeAnclaje ISO/IEC 27001:2022Fuente de Clarysec
Evaluación de aplicabilidad de NIS2¿Somos una entidad esencial, importante, indirectamente expuesta o fuera de alcance?Cláusulas 4.1 a 4.4Zenith Blueprint, Step 1 y Step 2
Alcance del SGSI y mapa de dependencias¿Qué servicios, ubicaciones, proveedores, interfaces y procesos están sujetos a gobernanza?Cláusulas 4.1 a 4.4Zenith Blueprint, fase de fundamentos del SGSI
Registro de riesgos cibernéticos¿Cuáles son nuestros principales riesgos cibernéticos y quién es su propietario?Cláusulas 6.1.1 y 6.1.2Política de gestión de riesgos
Plan de tratamiento de riesgos y SoA¿Qué controles se seleccionan, por qué y quién aprobó el riesgo residual?Cláusula 6.1.3Zenith Blueprint, Step 13
Actas del consejo de administración y registro de decisiones¿La dirección aprobó, cuestionó y supervisó las medidas?Cláusulas 5.1, 5.3, 9.3Política de funciones y responsabilidades de gobernanza
Procedimiento de escalado y notificación de incidentes¿Podemos cumplir los plazos escalonados de notificación de NIS2?Cláusulas 8.1, 9.1, controles de incidentes del Anexo AToolkit de respuesta a incidentes y revisión por la dirección
Cuadro de mando de riesgos de proveedores¿Los proveedores críticos y las dependencias de servicios en la nube están sujetos a gobernanza?Cláusula 8.1 y controles de proveedores del Anexo AMapeo cruzado de Zenith Controls
Registro de formación de la alta dirección¿Los miembros del órgano de administración recibieron formación adecuada?Cláusula 7.2 y controles de concienciaciónPolítica de Concienciación y Formación en Seguridad de la Información
Resultados de auditoría interna y revisión por la dirección¿La implantación se comprueba de forma independiente y se mejora?Cláusulas 9.2, 9.3, 10.1Política de Auditoría y Supervisión del Cumplimiento - SME

La fortaleza de este paquete está en la trazabilidad. Cada artefacto responde a una pregunta de gobernanza y apunta a un mecanismo de ISO/IEC 27001:2022. Eso proporciona al CISO, al director general y al consejo de administración una narrativa defendible: la ciberseguridad no es una colección de herramientas, sino un sistema gobernado.

Convertir las políticas en responsabilidad a nivel del consejo de administración

En el escenario inicial, el director general de María podría verse tentado a responder al cliente con un certificado ISO y algunas políticas. Eso no basta para la responsabilidad del órgano de administración con arreglo a NIS2. La organización necesita evidencias de que la responsabilidad está asignada, las decisiones se registran y los riesgos se escalan de forma objetiva.

Las políticas de Clarysec están diseñadas para crear esa trazabilidad.

Para organizaciones más pequeñas, Information Security Policy-sme Information Security Policy - SME, cláusula 4.1.1, establece que la alta dirección:

“Conserva la responsabilidad global sobre la seguridad de la información”.

Esta frase importa. Evita un antipatrón frecuente en el que fundadores, directores generales o equipos ejecutivos delegan informalmente toda la responsabilidad de seguridad en TI sin conservar una supervisión significativa.

Para organizaciones de mayor tamaño, Risk Management Policy Risk Management Policy, cláusula 4.1.1, establece que el liderazgo:

“Aprueba el marco de gestión del riesgo y define el apetito de riesgo aceptable y los umbrales de tolerancia”.

Eso constituye evidencia preparada para el consejo de administración en relación con NIS2 Article 20. Una declaración de apetito de riesgo, umbrales de tolerancia y un modelo formal de autoridad de riesgo muestran cómo funcionan en la práctica la aprobación y el escalado.

La cláusula 5.6 de la misma política añade:

“La Matriz de Autoridad de Riesgo deberá definir claramente los umbrales de escalado a la alta dirección o al consejo de administración”.

Este es uno de los artefactos más importantes para la gobernanza NIS2. Sin umbrales de escalado, el consejo de administración solo ve aquello que alguien decide escalar. Con umbrales, el riesgo residual alto, las vulnerabilidades críticas no resueltas, la concentración significativa de proveedores, los incidentes graves, los hallazgos de auditoría y las excepciones por encima de la tolerancia pasan automáticamente a la supervisión ejecutiva.

La Governance Roles and Responsibilities Policy Governance Roles and Responsibilities Policy refuerza la cadena de evidencias:

“La gobernanza deberá apoyar la integración con otras disciplinas (p. ej., riesgos, legal, TI, recursos humanos), y las decisiones del SGSI deberán ser trazables hasta su fuente (p. ej., registros de auditoría, registros de revisión, actas de reunión)”.

Para pymes, Governance Roles and Responsibilities Policy-sme Governance Roles and Responsibilities Policy - SME establece:

“Todas las decisiones, excepciones y escalados significativos de seguridad deben registrarse y ser trazables”.

Esas cláusulas convierten la supervisión del consejo de administración de una conversación en una pista de auditoría.

La cadena de evidencias ISO/IEC 27001:2022 para NIS2 Article 20

Un consejo de administración puede llevar NIS2 Article 20 a la práctica mediante una cadena clara de evidencias basada en ISO/IEC 27001:2022.

Primero, establecer el contexto y el alcance. ISO/IEC 27001:2022 exige que la organización determine cuestiones internas y externas, partes interesadas, requisitos legales, regulatorios y contractuales, límites del SGSI, interfaces, dependencias y procesos que interactúan. Para un proveedor SaaS o de servicios en la nube, el alcance del SGSI debe identificar expresamente los servicios de la UE, los entornos en la nube, las operaciones de soporte, los proveedores críticos, los segmentos de clientes regulados y la exposición a NIS2.

Segundo, demostrar liderazgo. ISO/IEC 27001:2022 exige que la alta dirección alinee los objetivos de seguridad con la dirección estratégica, integre los requisitos del SGSI en los procesos de la organización, proporcione recursos, comunique la importancia, asigne responsabilidades y promueva la mejora continua. Para NIS2, esto se convierte en evidencia de que el órgano de administración aprobó y supervisó las medidas de gestión de riesgos de ciberseguridad.

Tercero, ejecutar una evaluación y un tratamiento de riesgos repetibles. ISO/IEC 27001:2022 exige criterios de riesgo, identificación de riesgos, propietarios del riesgo, análisis de probabilidad y consecuencias, opciones de tratamiento, selección de controles, comparación con el Anexo A, una Declaración de Aplicabilidad, un plan de tratamiento de riesgos y la aprobación del riesgo residual.

Zenith Blueprint, fase de gestión de riesgos, Step 13, explicita el punto de aprobación:

“Aprobación por la dirección: las decisiones de tratamiento de riesgos y la SoA deben ser revisadas y aprobadas por la alta dirección. La dirección debe recibir información sobre los riesgos clave y los tratamientos propuestos, los riesgos propuestos para aceptación y los controles previstos para su implantación”.

Para NIS2, esa sesión informativa no debe ser puntual. El paquete del consejo de administración debe mostrar los principales riesgos actuales, tendencias, avance del tratamiento, riesgo residual aceptado, acciones vencidas, exposición a proveedores críticos, temas recurrentes de incidentes y métricas clave de eficacia.

Cuarto, operar y conservar evidencias. La cláusula 8.1 de ISO/IEC 27001:2022 exige planificación y control operacional. Los controles del Anexo A respaldan la seguridad de proveedores, la gobernanza de la nube, la respuesta a incidentes, la continuidad del negocio, la gestión de vulnerabilidades, las copias de seguridad, el registro de eventos, la supervisión, el desarrollo seguro, la seguridad de aplicaciones, la arquitectura, las pruebas, la externalización, la segregación y la gestión de cambios.

Quinto, evaluar y mejorar. La auditoría interna, la medición, la revisión por la dirección, las acciones correctivas y la mejora continua convierten un catálogo de controles en un sistema gobernado.

La Information Security Policy empresarial Information Security Policy incorpora esta expectativa de revisión por la dirección:

“Las actividades de revisión por la dirección (conforme a ISO/IEC 27001 Cláusula 9.3) deberán realizarse al menos anualmente e incluirán:”.

El valor no está únicamente en que se celebre una reunión. El valor está en que la revisión genera evidencias: entradas, decisiones, acciones, responsables, fechas límite y seguimiento.

La Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy - SME, cláusula 5.4.3, cierra el ciclo:

“Los hallazgos de auditoría y las actualizaciones de estado deben incluirse en el proceso de revisión por la dirección del SGSI”.

Esa es la diferencia entre “tuvimos una auditoría” y “la dirección revisó los resultados de la auditoría y dirigió la remediación”.

Mapeo de cumplimiento cruzado: NIS2, DORA, RGPD de la UE, NIST CSF 2.0 y COBIT 2019

NIS2 rara vez llega sola. Un proveedor en la nube puede tratar datos personales con arreglo al RGPD de la UE. Un cliente fintech puede imponer requisitos de proveedores derivados de DORA. Un cliente empresarial estadounidense puede pedir alineamiento con NIST CSF 2.0. Un comité de auditoría del consejo de administración puede hablar el lenguaje de COBIT 2019.

La respuesta no es crear carpetas de cumplimiento separadas. La respuesta es utilizar ISO/IEC 27001:2022 como sistema central de evidencias.

Zenith Controls ayuda a los equipos a consolidar mediante el mapeo del control 5.4 de ISO/IEC 27002:2022, Responsabilidades de la dirección, entre normas, regulaciones y métodos de auditoría.

En Zenith Controls, la entrada del control 5.4 de ISO/IEC 27002:2022 “Responsabilidades de la dirección” clasifica el tipo de control como “Preventivo”, lo vincula con la confidencialidad, integridad y disponibilidad, y lo sitúa bajo una capacidad operativa centrada en la gobernanza.

Esto importa porque NIS2 Article 20 es gobernanza preventiva. La aprobación y supervisión por el liderazgo reducen la probabilidad de que el riesgo cibernético se vuelva invisible, carezca de financiación o no se gestione.

Zenith Controls también vincula las responsabilidades de la dirección con controles relacionados de ISO/IEC 27002:2022: 5.1 Políticas para la seguridad de la información, 5.2 Funciones y responsabilidades de seguridad de la información, 5.35 Revisión independiente de la seguridad de la información, 5.36 Cumplimiento de políticas, reglas y normas de seguridad de la información, y 5.8 Seguridad en la gestión de proyectos. La responsabilidad del consejo de administración no puede sostenerse de forma aislada. Necesita políticas, roles, aseguramiento, supervisión del cumplimiento e integración a nivel de proyecto.

La matriz de correspondencia más amplia resulta especialmente útil para la información ejecutiva.

Tema de requisitoNIS2DORARGPD de la UENIST CSF 2.0COBIT 2019Foco de evidencias de Clarysec
Responsabilidad de la direcciónArticle 20 aprobación, supervisión, formación, responsabilidadArticles 5 y 6 responsabilidad del órgano de administración y marco de gestión del riesgo de las TICArticle 5(2) responsabilidad proactiva y Article 24 responsabilidadGOVERN, especialmente GV.RR, GV.RM y GV.OVEDM03 optimización del riesgoActas del consejo de administración, mandatos de rol, registros de formación
Medidas de gestión de riesgosArticle 21 medidas técnicas, operativas y organizativasMarco de gestión del riesgo de las TICArticle 32 seguridad del tratamientoGOVERN, IDENTIFY, PROTECTAPO13 seguridad gestionadaRegistro de riesgos, plan de tratamiento, SoA
Notificación de incidentesArticle 23 alerta temprana, notificación de incidentes, informe finalArticles 17 a 20 notificación de incidentes graves relacionados con las TICArticles 33 y 34 notificación de brechas de datos personales cuando procedaRESPOND y RECOVERDSS02 gestión de solicitudes de servicio e incidentesMatriz de escalado, playbooks, simulaciones
Gobernanza de proveedoresArticle 21(2)(d) seguridad de la cadena de suministroArticles 28 a 30 riesgo de terceros TICObligaciones de encargados del tratamiento y de seguridadGV.SC gestión del riesgo de ciberseguridad en la cadena de suministroAPO10 proveedores gestionadosRegistro de proveedores, diligencia debida, controles contractuales
Eficacia y aseguramientoArticle 21(2)(f) políticas y procedimientos para evaluar la eficaciaArticle 6 revisión del marco de gestión del riesgo de las TIC y expectativas de auditoríaArticle 32(1)(d) pruebas y evaluación periódicasGV.OV supervisión, ID.RA evaluación de riesgos, DE.CM monitorización continuaMEA01 y MEA03 monitorización y cumplimientoAuditoría interna, revisión por la dirección, acciones correctivas

DORA merece especial atención. NIS2 Article 4 reconoce que los actos jurídicos sectoriales de la UE pueden desplazar disposiciones solapadas de NIS2 cuando se apliquen medidas equivalentes de gestión de riesgos de ciberseguridad o notificación de incidentes. DORA es el ejemplo clave para las entidades financieras. Es aplicable desde el 17 de enero de 2025 y crea un marco uniforme para la gestión del riesgo de las TIC, notificación de incidentes, pruebas de resiliencia, gestión del riesgo de terceros y supervisión en los servicios financieros.

Un proveedor SaaS o en la nube puede no estar regulado directamente como un banco, pero DORA puede llegar igualmente a través de contratos con clientes. Las entidades financieras deben gestionar el riesgo de terceros TIC, mantener registros de contratos de servicios TIC, realizar diligencia debida, evaluar el riesgo de concentración, incluir derechos de auditoría e inspección, definir derechos de terminación y mantener estrategias de salida. Eso significa que los proveedores que prestan servicio a clientes financieros deben esperar solicitudes de evidencias muy similares a las preguntas de gobernanza del consejo de administración con arreglo a NIS2.

El RGPD de la UE añade responsabilidad proactiva respecto de los datos personales. Article 5(2) exige que los responsables del tratamiento sean responsables y puedan demostrar el cumplimiento. Article 32 exige seguridad del tratamiento, incluidas pruebas, valoraciones y evaluaciones periódicas de la eficacia de las medidas técnicas y organizativas. Cuando se vean afectados datos personales, los flujos de trabajo de incidentes deben integrar la evaluación de brechas del RGPD de la UE con el escalado de incidentes significativos de NIS2.

NIST CSF 2.0 añade un lenguaje apto para ejecutivos mediante la función GOVERN. Enfatiza el contexto organizativo, la estrategia de gestión de riesgos, los roles y responsabilidades, la política, la supervisión y la gestión del riesgo de ciberseguridad de la cadena de suministro. COBIT 2019 añade un vocabulario de gobernanza familiar para los comités de auditoría, especialmente mediante EDM03 para la optimización del riesgo y los objetivos MEA para monitorización y aseguramiento.

Un sprint de 90 días para evidencias NIS2 del consejo de administración

Un sprint práctico de evidencias puede ayudar a las organizaciones a avanzar con rapidez sin crear una burocracia paralela.

Días 1 a 30: Establecer la responsabilidad

Empiece con un registro de responsabilidad NIS2 que documente:

  • Análisis de clasificación de la entidad, incluida la justificación de entidad esencial, importante, exposición indirecta o fuera de alcance.
  • Servicios dentro del alcance, como SaaS, nube, servicios gestionados, centro de datos, DNS, servicios de confianza o servicios relacionados con comunicaciones.
  • Estados miembros de la UE en los que se prestan servicios.
  • Sectores de clientes afectados, especialmente servicios financieros, sanidad, transporte, energía, administración pública e infraestructura digital.
  • Obligaciones aplicables, incluidas NIS2 Article 20, Article 21 y Article 23.
  • Obligaciones relacionadas de DORA, RGPD de la UE, contratos de clientes y ciberseguros.
  • Propietario de gestión y frecuencia de información al consejo de administración.

Vincule esto al contexto de ISO/IEC 27001:2022, las partes interesadas, el registro de obligaciones y el alcance del SGSI. Después, actualice la Matriz de Autoridad de Riesgo utilizando el requisito de la Política de gestión de riesgos de definir umbrales de escalado para la alta dirección o el consejo de administración.

Entre los desencadenantes útiles de escalado se incluyen el riesgo residual por encima del apetito de riesgo, vulnerabilidades críticas no aceptadas que superan el SLA, riesgo de concentración de proveedores, hallazgos de auditoría altos no resueltos, incidentes que puedan activar la notificación con arreglo a NIS2, excepciones a requisitos de MFA, copias de seguridad, registro de eventos, cifrado o respuesta a incidentes, y cambios materiales en la arquitectura de nube.

Días 31 a 60: Aprobar el tratamiento de riesgos

Utilice Zenith Blueprint Step 13 para preparar un paquete de decisión del consejo de administración relativo al plan de tratamiento de riesgos y la Declaración de Aplicabilidad. El paquete debe incluir:

  • Los 10 principales riesgos cibernéticos.
  • Opción de tratamiento propuesta para cada riesgo.
  • Grupos de controles seleccionados.
  • Riesgo residual tras el tratamiento.
  • Riesgos propuestos para aceptación.
  • Decisiones presupuestarias o de recursos necesarias.
  • Dependencias de proveedores, legal, recursos humanos, producto y TI.
  • Decisión de la dirección solicitada.

El resultado debe ser una aprobación firmada o reflejada en acta. Una presentación por sí sola no es suficiente.

Mapee también las medidas de NIS2 Article 21 con las cláusulas de ISO/IEC 27001:2022 y los controles del Anexo A. Esto permite a la organización demostrar que NIS2 se gestiona a través del SGSI y no mediante una lista de verificación desconectada.

Días 61 a 90: Probar la notificación de incidentes y revisar evidencias

NIS2 Article 23 exige notificación escalonada de incidentes significativos: alerta temprana en un plazo de 24 horas, notificación del incidente en 72 horas, actualizaciones intermedias cuando se requieran o soliciten, e informe final no más tarde de un mes desde la notificación.

Realice un ejercicio de simulación con el patrocinador del consejo de administración, el director general, el CISO, legal, comunicaciones, éxito del cliente y operaciones. Use un escenario realista, como una configuración incorrecta en la nube que expone metadatos de clientes, interrumpe la disponibilidad del servicio y afecta a un cliente regulado.

Pruebe quién decide si el incidente puede ser significativo, quién contacta con asesores jurídicos, quién notifica a las autoridades competentes o al CSIRT cuando sea necesario, quién aprueba las comunicaciones a clientes, cómo se preservan las evidencias, cómo se evalúan en paralelo las obligaciones de brecha del RGPD de la UE y cómo se informa al consejo de administración durante las primeras 24 horas.

Después, celebre una revisión formal por la dirección. Zenith Blueprint, fase Audit, Review & Improvement, Step 28, explica por qué:

“La revisión por la dirección no es solo una presentación; consiste en tomar decisiones”.

Esa revisión debe incluir hallazgos de auditoría, avance del tratamiento de riesgos, preparación ante incidentes, riesgos de proveedores, métricas, decisiones, acciones asignadas y responsables de seguimiento.

La reunión de revisión por la dirección que sí funciona

Muchas revisiones por la dirección fallan porque se estructuran como actualizaciones de estado. Una revisión por la dirección preparada para NIS2 debe ser una reunión de decisión.

La agenda debe incluir:

  1. Cambios en requisitos de NIS2, DORA, RGPD de la UE, contractuales y de clientes.
  2. Cambios en el contexto de la organización, servicios, adquisiciones, proveedores, arquitectura de nube y segmentos de clientes regulados.
  3. Estado de los principales riesgos de seguridad de la información y riesgo residual frente al apetito de riesgo.
  4. Avance del plan de tratamiento de riesgos y acciones vencidas.
  5. Tendencias de incidentes, eventos significativos, cuasi incidentes y preparación para la notificación.
  6. Riesgos de proveedores y dependencias TIC, incluidas preocupaciones de concentración y salida.
  7. Resultados de auditorías internas, auditorías externas, evaluaciones de clientes y pruebas de penetración.
  8. Concienciación en seguridad y finalización de la formación ejecutiva.
  9. Métricas de control de acceso, gestión de vulnerabilidades, copias de seguridad, registro de eventos, supervisión, desarrollo seguro y pruebas de continuidad.
  10. Decisiones requeridas, incluidas aceptación del riesgo, presupuesto, dotación de personal, excepciones a la política, remediación de proveedores y mejoras de controles.

La formación ejecutiva es especialmente importante. NIS2 Article 20 exige que los miembros del órgano de administración reciban formación. Information Security Awareness and Training Policy Information Security Awareness and Training Policy, cláusula 5.1.2.4, incluye explícitamente temas de formación ejecutiva:

“Alta dirección (p. ej., gobernanza, aceptación del riesgo, obligaciones legales)”.

La formación cibernética ejecutiva debe centrarse en derechos de decisión, responsabilidad, escalado, apetito de riesgo, gobernanza de crisis, notificación de incidentes y obligaciones regulatorias. No debe limitarse a la concienciación sobre phishing.

Cómo probarán los auditores y clientes la supervisión del consejo de administración

Distintos evaluadores utilizarán lenguajes diferentes, pero comprobarán la misma cuestión subyacente: ¿está gobernada la ciberseguridad?

Zenith Controls es valioso porque incluye mapeos de metodología de auditoría. Para responsabilidades de la dirección, referencia los principios y la realización de auditorías de ISO/IEC 19011:2018, las prácticas de auditoría del SGSI de ISO/IEC 27007:2020, la cláusula 5.1 de ISO/IEC 27001:2022, COBIT 2019 EDM01 y EDM03, ISACA ITAF Section 1401, y NIST SP 800-53A PM-1 y PM-2. Para la revisión independiente, lo mapea con las cláusulas 9.2 y 9.3 de ISO/IEC 27001:2022, la planificación de auditoría y las prácticas de evidencias de ISO/IEC 27007, ISACA ITAF Section 2400 y métodos de evaluación de NIST. Para el cumplimiento de políticas, lo mapea con las cláusulas 9.1, 9.2 y 10.1 de ISO/IEC 27001:2022, la recopilación de evidencias de ISO/IEC 19011, COBIT 2019 MEA01 y la evaluación de monitorización continua de NIST.

Enfoque del auditorQué preguntaráEvidencias esperadasFallo común
Auditor ISO/IEC 27001:2022¿Cómo demuestra la alta dirección liderazgo, aprueba el tratamiento de riesgos y revisa el desempeño del SGSI?Aprobaciones de políticas, registro de riesgos, aprobación de la SoA, actas de revisión por la dirección, resultados de auditoría internaExiste revisión por la dirección, pero sin decisiones ni seguimiento de acciones
Evaluador centrado en NIS2¿Aprobó el órgano de administración las medidas de ciberseguridad y supervisó su implantación?Actas del consejo de administración, matriz de escalado, registros de formación ejecutiva, mapeo de referencia de Article 21Medidas de seguridad aprobadas solo por el CISO, sin trazabilidad al consejo de administración
Evaluador NIST CSF 2.0¿Están los resultados de gobernanza, el apetito de riesgo, los roles, los recursos, la supervisión y el riesgo de la cadena de suministro integrados en la gestión de riesgos empresariales?Perfiles actuales y objetivo, plan de brechas, informes al liderazgo, métricasNIST se usa como lista de verificación sin propiedad de gobernanza
Auditor COBIT 2019 o ISACA¿La gobernanza evalúa, dirige y monitoriza la gestión del riesgo cibernético?Mandatos de gobernanza, apetito de riesgo, informes de gestión, resultados de aseguramientoEl consejo de administración recibe métricas técnicas, pero sin contexto de decisión sobre riesgos
Cliente DORA o evaluador del sector financiero¿Los riesgos TIC, incidentes, resiliencia y dependencias de terceros están gobernados y documentados?Mapa de dependencias TIC, registro de proveedores, diligencia debida, derechos de auditoría, ciclo de vida de incidentesEl riesgo de proveedores se basa solo en cuestionarios, sin análisis de concentración ni salida
Auditor del RGPD de la UE o evaluador de privacidad¿Puede la organización demostrar seguridad y responsabilidad proactiva sobre el tratamiento de datos personales?Mapas de datos, modelo de base jurídica, proceso de evaluación de brechas, controles de seguridadLas evidencias de privacidad y seguridad están separadas y son incoherentes

La lección es sencilla. La responsabilidad del consejo de administración no se demuestra solo con asistencia a reuniones. Se demuestra mediante decisiones informadas, aprobaciones documentadas, priorización basada en riesgos, asignación de recursos y seguimiento.

Errores comunes que rompen la cadena de evidencias

Las organizaciones que tienen dificultades con la responsabilidad del órgano de administración con arreglo a NIS2 suelen caer en patrones previsibles.

Primero, confunden la operación técnica de controles con la gobernanza. La cobertura de MFA, las alertas SIEM, el despliegue de EDR y las tasas de éxito de copias de seguridad importan, pero el consejo de administración necesita contexto de riesgo, decisiones de tratamiento y aseguramiento de que los controles funcionan.

Segundo, aprueban políticas, pero no el tratamiento de riesgos. Una política de seguridad firmada no demuestra que el consejo de administración haya aprobado medidas de ciberseguridad proporcionadas. El plan de tratamiento de riesgos y la SoA son evidencias más sólidas porque conectan riesgos, controles, riesgo residual y aprobación por la dirección.

Tercero, carecen de umbrales de escalado. Sin una Matriz de Autoridad de Riesgo, el escalado depende de personas concretas. La gobernanza NIS2 necesita desencadenantes objetivos.

Cuarto, separan la respuesta a incidentes de la notificación regulatoria. Los flujos de trabajo de notificación de NIS2, DORA y RGPD de la UE deben integrarse antes de una crisis.

Quinto, ignoran la gobernanza de proveedores. NIS2 Article 21 incluye la seguridad de la cadena de suministro y consideraciones sobre vulnerabilidades de proveedores. Los clientes impulsados por DORA pueden esperar una gobernanza de terceros TIC más profunda, incluida diligencia debida, derechos de auditoría, riesgo de concentración, derechos de terminación y estrategias de salida.

Sexto, no forman a la alta dirección. La formación cibernética ejecutiva no es un adorno opcional con arreglo a NIS2. Forma parte de la cadena de evidencias de gobernanza.

Cómo se ve una práctica adecuada

Después de 90 días, una carpeta creíble de evidencias NIS2 para el consejo de administración debe contener:

  • Evaluación de aplicabilidad.
  • Alcance del SGSI y registro de obligaciones.
  • Declaración de compromiso del liderazgo.
  • Apetito de riesgo y umbrales de tolerancia.
  • Matriz de Autoridad de Riesgo.
  • Registro de riesgos cibernéticos.
  • Plan de tratamiento de riesgos.
  • Declaración de Aplicabilidad.
  • Actas de aprobación del consejo de administración.
  • Registros de formación ejecutiva.
  • Informe de ejercicio de simulación de incidentes.
  • Cuadro de mando de riesgos de proveedores.
  • Informe de auditoría interna.
  • Actas de revisión por la dirección y herramienta de seguimiento de acciones.

Esta carpeta responde al cuestionario del cliente que María recibió el lunes por la mañana. Más importante aún, ayuda al consejo de administración a gobernar el riesgo cibernético antes de que un incidente, una auditoría o un regulador pongan a prueba públicamente a la organización.

Convierta la responsabilidad del consejo de administración con arreglo a NIS2 en gobernanza preparada para auditorías

NIS2 ha cambiado la conversación sobre ciberseguridad. Los órganos de administración deben aprobar las medidas de gestión de riesgos de ciberseguridad, supervisar su implantación y recibir formación. Article 21 exige un conjunto integrado de medidas técnicas, operativas y organizativas. Article 23 comprime la notificación de incidentes en un calendario escalonado que exige preparación antes de la crisis.

ISO/IEC 27001:2022 aporta el sistema de gestión. Clarysec aporta la hoja de ruta de implantación, el lenguaje de políticas, los mapeos de cumplimiento cruzado y el modelo de evidencias de auditoría.

Si su consejo de administración pregunta: “¿Qué tenemos que aprobar y cómo demostramos la supervisión?”, empiece con tres acciones:

  1. Utilice Zenith Blueprint Step 3, Step 13 y Step 28 para estructurar el compromiso del liderazgo, la aprobación del tratamiento de riesgos y la revisión por la dirección.
  2. Utilice políticas de Clarysec como Risk Management Policy, Governance Roles and Responsibilities Policy, Information Security Policy y sus equivalentes para pymes para formalizar la responsabilidad proactiva y la trazabilidad.
  3. Utilice Zenith Controls para mapear la supervisión del consejo de administración con arreglo a NIS2 con ISO/IEC 27001:2022, ISO/IEC 27002:2022, DORA, RGPD de la UE, NIST CSF 2.0, COBIT 2019 y las expectativas de metodología de auditoría.

Clarysec puede ayudarle a crear el paquete del consejo de administración, actualizar la cadena de evidencias del SGSI, preparar la revisión por la dirección y convertir la responsabilidad NIS2 en un proceso repetible de gobernanza del riesgo cibernético que auditores, clientes y alta dirección puedan comprender. Descargue los toolkits relevantes de Clarysec o solicite una evaluación para convertir la responsabilidad del consejo de administración en evidencias preparadas para auditorías.

Frequently Asked Questions

About the Author

Igor Petreski

Igor Petreski

Compliance Systems Architect, Clarysec LLC

Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

Share this article

Related Articles

Evidencias de DORA TLPT con controles de ISO 27001

Evidencias de DORA TLPT con controles de ISO 27001

Guía práctica para entidades financieras que necesitan conectar DORA TLPT, pruebas de resiliencia, controles de ISO 27001, aseguramiento de proveedores, evidencias de recuperación e informes al Consejo de Administración en una única cadena de evidencias preparada para auditoría.