ISO 27001 como eje vertebrador de evidencias para NIS2 y DORA

La colisión de cumplimiento del lunes por la mañana
A las 08:12 del lunes, María, directora de seguridad de la información (CISO) de un procesador de pagos europeo, recibe tres mensajes que parecen no tener relación entre sí.
El responsable de auditoría interna solicita evidencias de que la Declaración de Aplicabilidad de ISO 27001:2022 está actualizada. El equipo jurídico reenvía el cuestionario de un socio bancario sobre la supervisión del riesgo de terceros de TIC conforme a DORA. El director de operaciones pregunta si el mismo procedimiento operativo de incidentes puede respaldar las expectativas de notificación de NIS2 para una unidad de negocio de la UE recientemente adquirida.
A las 09:00, la pizarra del despacho de María está cubierta de acrónimos: ISO 27001, NIS2, DORA, GDPR, NIST, COBIT 2019. Su organización tiene controles. Tiene gestión de accesos, copias de seguridad, cuestionarios de proveedores, cifrado, respuesta a incidentes, aprobaciones de políticas, revisiones por la dirección y registros de formación. Lo que no tiene es un único eje de evidencias preparado para auditorías que explique por qué existen esos controles, qué riesgos tratan, qué regulaciones respaldan, quién es su responsable y dónde reside la prueba.
Este problema es cada vez más habitual en Europa. NIS2 impulsa la gestión de riesgos de ciberseguridad, la gobernanza, la gestión de incidentes y la resiliencia de la cadena de suministro. DORA añade requisitos detallados de gestión del riesgo de las TIC, pruebas de resiliencia, notificación de incidentes y supervisión de terceros de TIC para entidades financieras. GDPR sigue exigiendo responsabilidad proactiva, seguridad del tratamiento, gobernanza de encargados del tratamiento y evaluación de brechas de datos personales.
La respuesta equivocada es crear tres programas de cumplimiento paralelos. Eso genera controles duplicados, evidencias incoherentes y equipos agotados.
La respuesta más sólida es utilizar ISO 27001:2022 como eje vertebrador de controles. No como un certificado en la pared, sino como el sistema operativo para el riesgo, las políticas, la gobernanza de proveedores, la respuesta a incidentes, el mapeo de cumplimiento y las evidencias de auditoría.
El modelo práctico de Clarysec es sencillo: utilizar el SGSI de ISO 27001:2022 como sistema organizador, utilizar la Declaración de Aplicabilidad como puente, utilizar las políticas como reglas operativas exigibles y utilizar Zenith Controls: la guía de cumplimiento cruzado como brújula de cumplimiento cruzado. Construir una vez, mapear con rigor y demostrar de forma continua.
Por qué ISO 27001:2022 funciona como eje de cumplimiento
NIS2 y DORA tienen alcances, mecanismos legales y modelos de supervisión diferentes. NIS2 se aplica a entidades esenciales e importantes de distintos sectores. DORA se aplica a entidades financieras y establece requisitos detallados de resiliencia operativa digital. GDPR se centra en el tratamiento de datos personales y la responsabilidad proactiva.
Sin embargo, las preguntas operativas que subyacen a estos marcos se solapan:
- ¿La ciberseguridad se rige por políticas aprobadas por la dirección?
- ¿Se identifican, evalúan y tratan los riesgos de seguridad de la información y de TIC?
- ¿Los controles se seleccionan en función del riesgo, el contexto de la organización y las obligaciones legales?
- ¿Los proveedores se gestionan mediante diligencia debida, contratos, supervisión y controles de salida?
- ¿El personal puede reconocer y notificar eventos de seguridad de forma temprana?
- ¿Los incidentes pueden clasificarse inicialmente, escalarse, investigarse y evaluarse para determinar la necesidad de notificación regulatoria?
- ¿La organización puede recuperar evidencias rápidamente durante una auditoría, revisión de cliente o requerimiento supervisor?
ISO 27001:2022 proporciona a la dirección un sistema de gestión para responder a esas preguntas de forma coherente. ISO/IEC 27007:2022 trata la Declaración de Aplicabilidad como una lista auditable de controles de seguridad de la información seleccionados, incluidos controles del Anexo A de ISO 27001:2022, de otras normas o medidas específicas de la organización, con una justificación documentada de inclusión o exclusión. ISO/IEC 27006-1:2024 refuerza que la SoA y la documentación relacionada del SGSI constituyen una base esencial de evidencias para demostrar qué controles son necesarios, cómo se asignan las responsabilidades y cómo se implantan y comunican las políticas.
Eso convierte a la SoA en mucho más que una hoja de cálculo. Se transforma en el contrato de control entre riesgos, cumplimiento, operaciones, jurídico, compras, auditoría y el consejo de administración.
La [P01] Política de Seguridad de la Información de Clarysec ancla este requisito de gobernanza:
La organización deberá implantar y mantener un Sistema de Gestión de la Seguridad de la Información (SGSI) de conformidad con las cláusulas 4 a 10 de ISO/IEC 27001:2022.
De la sección “Requisitos de implementación de la política”, cláusula 6.1.1 de la política.
Esto importa porque las solicitudes de evidencias de NIS2 y DORA rara vez llegan en lenguaje ISO. Un regulador, cliente o comité del consejo de administración puede pedir prueba de gestión de riesgos de ciberseguridad, gobernanza de TIC, supervisión de dependencias de terceros, escalado de incidentes o pruebas de resiliencia operativa. El SGSI de ISO 27001:2022 da estructura a esas respuestas.
La SoA es el puente, no un ejercicio documental
En Zenith Blueprint: hoja de ruta de 30 pasos para auditores, fase de gestión de riesgos, paso 13, Clarysec presenta la SoA como el mecanismo clave de trazabilidad entre el tratamiento de riesgos y los controles implantados:
La SoA es, en la práctica, un documento puente: vincula su evaluación y tratamiento de riesgos con los controles reales que tiene implantados.
Esa frase es el núcleo del cumplimiento cruzado. Un control sin trazabilidad se convierte en un artefacto aislado. Un control vinculado a un riesgo, una obligación legal, una política, un responsable, un registro de evidencias y un resultado de prueba queda preparado para auditorías.
El paso 13 también recomienda añadir referencias de controles a los escenarios de riesgo, por ejemplo, vincular un escenario de brecha de seguridad de una base de datos de clientes con control de acceso, criptografía, gestión de vulnerabilidades, respuesta a incidentes y controles de proveedores. También recomienda indicar cuándo los controles respaldan requisitos externos como GDPR, NIS2 o DORA.
La [P06] Política de gestión de riesgos de Clarysec hace explícita esta regla operativa:
Las decisiones de control derivadas del proceso de tratamiento de riesgos deberán reflejarse en la SoA.
De la sección “Requisitos de implementación de la política”, cláusula 6.5.1 de la política.
Para organizaciones más pequeñas, la Política de gestión de riesgos - SME aplica la misma lógica:
Garantiza que la gestión de riesgos sea un componente activo de la planificación, la ejecución de proyectos, la selección de proveedores y la respuesta a incidentes, en alineación con ISO 27001, ISO 31000 y los requisitos regulatorios aplicables.
De la sección “Propósito”, cláusula 1.2 de la política.
Si un tratamiento de riesgo de terceros de DORA, una medida de gestión de incidentes de NIS2 o un requisito de seguridad de encargados del tratamiento de GDPR no se refleja en la SoA o en el registro de cumplimiento relacionado, es posible que la organización esté realizando el trabajo. Pero tendrá dificultades para demostrarlo de forma coherente.
Un mapeo práctico de ISO 27001:2022 para NIS2 y DORA
El siguiente mapeo no constituye asesoramiento jurídico. Es un modelo práctico de evidencias para CISOs, responsables de cumplimiento, auditores internos y responsables de negocio que necesitan alinear evidencias de ISO 27001:2022 con las expectativas de NIS2 y DORA.
ENISA, en colaboración con la Comisión Europea y el Grupo de Cooperación NIS, ha proporcionado orientación consultiva de referencias cruzadas que ayuda a alinear los requisitos de ciberseguridad de la UE con normas internacionales y nacionales, incluida ISO 27001. Esa orientación no es jurídicamente vinculante y debe complementarse con instrucciones de las autoridades nacionales, normas sectoriales y revisión jurídica. No obstante, respalda un enfoque de mapeo defendible.
| Pregunta de cumplimiento | Evidencia del eje ISO 27001:2022 | Relevancia para NIS2 | Relevancia para DORA | Artefacto de evidencia de Clarysec |
|---|---|---|---|---|
| ¿La ciberseguridad se rige por políticas aprobadas por la dirección? | Política de seguridad de la información, alcance del SGSI, roles, registros de revisión por la dirección, SoA | Expectativas de gestión de riesgos de ciberseguridad y gobernanza | Gobernanza de TIC y marco de gestión del riesgo de las TIC | Política de Seguridad de la Información, SoA, paquete de revisión por la dirección |
| ¿Los riesgos se evalúan y tratan? | Registro de riesgos, Plan de Tratamiento de Riesgos, justificaciones de la SoA, aprobaciones de riesgo residual | Medidas de ciberseguridad basadas en riesgos conforme al Article 21 | Identificación, protección, prevención, detección, respuesta y recuperación de riesgos de TIC | Registro de riesgos, Plan de Tratamiento de Riesgos, SoA_Builder.xlsx |
| ¿Los proveedores están controlados? | Política de proveedores, registros de diligencia debida, contratos, derechos de auditoría, cláusulas de notificación de brechas de seguridad | Ciberseguridad de la cadena de suministro conforme al Article 21(2)(d) | Gestión del riesgo de terceros de TIC conforme a los Articles 28 to 30 | Política de seguridad de terceros y proveedores, registro de proveedores |
| ¿Los incidentes se detectan, escalan y notifican? | Plan de respuesta a incidentes, canal de notificación, registros de clasificación inicial, ejercicios de mesa, lecciones aprendidas | Gestión y notificación de incidentes significativos conforme al Article 23 | Gestión y notificación de incidentes relacionados con las TIC conforme a los Articles 17 to 19 | Política de Respuesta a Incidentes, tickets de incidentes, informe de ejercicio |
| ¿Las evidencias están centralizadas y son auditables? | Programa de auditoría interna, repositorio de evidencias, registro de cumplimiento, acciones correctivas | Preparación de evidencias ante supervisión | Preparación ante inspecciones regulatorias y supervisoras | Política de Auditoría y Supervisión del Cumplimiento, carpeta central de auditoría |
El mapeo funciona porque no crea controles duplicados para cada regulación. Utiliza ISO 27001:2022 como eje de controles y añade etiquetas regulatorias, responsabilidad y expectativas de evidencia.
Tres controles de ISO 27001:2022 que desbloquean el eje de evidencias
Varios controles son relevantes para NIS2 y DORA, pero tres controles de ISO/IEC 27002:2022 se convierten con frecuencia en el eje del modelo de evidencias: 5.1, 5.19 y 5.24. Un cuarto control, 6.8, suele determinar si la notificación de incidentes funciona en la práctica.
| Control de ISO/IEC 27002:2022 | Por qué importa | Valor para el cumplimiento cruzado |
|---|---|---|
| 5.1 Políticas de seguridad de la información | Establece la dirección de seguridad aprobada por la dirección y la responsabilidad proactiva | Respalda la gobernanza de NIS2, la gobernanza de TIC de DORA, la responsabilidad proactiva de GDPR y las evidencias de política de ISO 27001 |
| 5.19 Seguridad de la información en las relaciones con proveedores | Define las expectativas de seguridad de proveedores durante la incorporación, la supervisión y la gestión de la relación | Respalda la ciberseguridad de la cadena de suministro de NIS2, el riesgo de terceros de TIC de DORA y la supervisión de encargados del tratamiento de GDPR |
| 5.24 Planificación y preparación de la gestión de incidentes de seguridad de la información | Crea el marco de gestión de incidentes, roles, vías de escalado y actividades de preparación | Respalda la gestión de incidentes de NIS2, la notificación de incidentes relacionados con las TIC de DORA y la evaluación de brechas de GDPR |
| 6.8 Notificación de eventos de seguridad de la información | Garantiza que el personal pueda notificar rápidamente eventos sospechosos a través de canales claros | Respalda la detección temprana, el escalado, la evaluación de notificación y la calidad de las evidencias de incidentes |
En Zenith Controls, el control 5.1 de ISO/IEC 27002:2022, Políticas de seguridad de la información, se caracteriza como un control preventivo que respalda la confidencialidad, la integridad y la disponibilidad, con la gobernanza y la gestión de políticas como capacidades operativas esenciales. El mapeo cruzado explica que los Articles 5(2), 24 y 32 de GDPR exigen responsabilidad proactiva, responsabilidad y seguridad del tratamiento. También mapea el mismo control con las expectativas de gestión de riesgos de ciberseguridad y gobernanza de NIS2, y con los requisitos de gobernanza de TIC y marco de gestión de riesgos de DORA.
Por eso la política de seguridad de la información no es una política más. Un evaluador de NIS2 puede leerla como evidencia de gobernanza. Un supervisor de DORA puede leerla como evidencia del marco de riesgos de TIC. Un revisor de GDPR puede leerla como evidencia de responsabilidad proactiva. Un auditor de ISO 27001:2022 puede leerla como parte de la estructura de políticas del SGSI.
El control 5.19, Seguridad de la información en las relaciones con proveedores, es donde convergen compras, jurídico, seguridad, privacidad y resiliencia. Zenith Controls lo mapea con las obligaciones de encargados del tratamiento de GDPR, la ciberseguridad de la cadena de suministro de NIS2 y la gestión del riesgo de terceros de TIC de DORA. Para DORA, esta evidencia se refuerza aún más cuando se apoya en los controles 5.20, Tratamiento de la seguridad de la información en los acuerdos con proveedores, 5.21, Gestión de la seguridad de la información en la cadena de suministro de TIC, y 5.23, Seguridad de la información para el uso de servicios en la nube.
El control 5.24, Planificación y preparación de la gestión de incidentes de seguridad de la información, es el motor operativo de la preparación ante incidentes. Zenith Controls lo mapea con la gestión y notificación de incidentes de NIS2, la notificación de brechas de datos personales de GDPR y la gestión y notificación de incidentes relacionados con las TIC de DORA. Su evidencia no es solo una política de respuesta a incidentes. Incluye canales de notificación, criterios de clasificación inicial, registros de escalado, evaluaciones legales de notificación, ejercicios de mesa, tickets de incidentes y lecciones aprendidas.
El control 6.8, Notificación de eventos de seguridad de la información, cierra la brecha entre el plan escrito y el comportamiento humano. Si el personal no sabe cómo notificar sospechas de phishing, fuga de datos, indisponibilidades de proveedores o actividad sospechosa en sistemas, la organización puede perder un tiempo crítico antes de que siquiera comiencen las evaluaciones legales o regulatorias de notificación.
Un incidente de proveedor, una cadena coordinada de evidencias
Imagine que un proveedor de analítica en la nube utilizado por el procesador de pagos de María detecta acceso no autorizado a un portal de soporte. El proveedor aloja datos seudonimizados de uso de clientes y respalda un flujo de trabajo de informes crítico para las operaciones de la organización. El incidente puede afectar a datos personales, resiliencia de TIC regulada y disponibilidad del servicio.
Un programa de cumplimiento fragmentado abre tres líneas de trabajo separadas: una evaluación de brecha de GDPR, una revisión de incidente de TIC de DORA y un ticket de proveedor de ISO 27001. Cada equipo solicita evidencias similares en un formato distinto. Compras busca el contrato. Jurídico pregunta si el proveedor es un encargado del tratamiento. Seguridad pregunta si el incidente cumple los umbrales de notificación. Cumplimiento inicia una nueva hoja de cálculo.
Un eje maduro de ISO 27001:2022 abre una única cadena coordinada de evidencias.
Primero, el evento se registra conforme al proceso de respuesta a incidentes. El notificante utiliza un canal definido, el equipo de seguridad clasifica inicialmente el evento y jurídico evalúa las obligaciones de notificación. La [P30] Política de Respuesta a Incidentes de Clarysec exige que los incidentes con datos regulados sean evaluados por Jurídico y el delegado de protección de datos (DPO):
Si un incidente da lugar a una exposición confirmada o probable de datos personales u otros datos regulados, Jurídico y el DPO deberán evaluar la aplicabilidad de:
De la sección “Requisitos de implementación de la política”, cláusula 6.4.1 de la política.
Para organizaciones más pequeñas, Política de Respuesta a Incidentes - SME asigna el mismo punto práctico de decisión:
Cuando estén implicados datos de clientes, el Director General deberá evaluar las obligaciones legales de notificación en función de la aplicabilidad de GDPR, NIS2 o DORA.
De la sección “Tratamiento de riesgos y excepciones”, cláusula 7.4.1 de la política.
En segundo lugar, se revisa la relación con el proveedor. ¿El proveedor estaba clasificado como crítico? ¿El contrato incluía obligaciones de notificación de brechas de seguridad, derechos de auditoría, responsabilidades de protección de datos, expectativas de continuidad del servicio y disposiciones de salida? La Política de seguridad de terceros y proveedores de Clarysec establece esa expectativa:
Incorporar requisitos de seguridad normalizados en todos los contratos con proveedores, incluidas obligaciones de notificación de brechas de seguridad, derechos de auditoría y responsabilidades de protección de datos.
De la sección “Objetivos”, cláusula 3.2 de la política.
Para pymes, Política de seguridad de terceros y proveedores - SME explicita el propósito de cumplimiento cruzado:
Respaldar el cumplimiento de las obligaciones de ISO/IEC 27001:2022, GDPR, NIS2 y DORA relacionadas con la gobernanza de proveedores.
De la sección “Objetivos”, cláusula 3.6 de la política.
En tercer lugar, el registro de riesgos, el plan de tratamiento y la SoA se actualizan si el incidente revela una deficiencia. Tal vez el contrato del proveedor carezca de un plazo específico de notificación regulatoria. Tal vez la frecuencia de supervisión de proveedores sea demasiado baja para un proveedor crítico de TIC. Tal vez el plan de respuesta a incidentes no distinga con claridad los criterios de brecha de datos personales de los criterios de interrupción del servicio de TIC.
El objetivo no es crear un nuevo universo de cumplimiento. El objetivo es actualizar una cadena integrada de evidencias para que los mismos registros puedan responder a múltiples preguntas de auditoría.
Convertir la SoA en un mapa de evidencias para NIS2 y DORA
Una SoA estándar suele responder bien a las preguntas ISO: qué controles son aplicables, por qué se seleccionan y si están implantados. Para convertirla en un mapa práctico de evidencias para NIS2 y DORA, enriquézcala con campos regulatorios y de evidencias operativas.
Abra SoA_Builder.xlsx del Audit Ready Toolkit citado en Zenith Blueprint, fase de auditoría, revisión y mejora, paso 24. El paso 24 explica que los auditores suelen muestrear un control de la SoA y preguntar por qué se implantó. La columna de justificación y el riesgo o requisito vinculado deben responder a esa pregunta.
Añada estas columnas:
| Nueva columna de la SoA | Propósito | Entrada de ejemplo |
|---|---|---|
| Impulsor regulatorio | Muestra si el control respalda NIS2, DORA, GDPR, contratos con clientes o resiliencia | NIS2, DORA, GDPR |
| ID de riesgo mapeado | Vincula el control con el registro de riesgos | R-017 Indisponibilidad de proveedor que afecta a informes regulados |
| Responsable de la evidencia | Identifica quién mantiene la prueba | Responsable de Operaciones de Seguridad |
| Evidencia principal | Define el artefacto que los auditores deben inspeccionar primero | Plan de respuesta a incidentes y registro de tickets de incidentes |
| Evidencia operativa | Muestra que el control funciona a lo largo del tiempo | Informe de ejercicio de mesa, prueba de notificación de brecha por proveedor |
| Estado de auditoría | Supervisa la preparación | Probado, deficiencia abierta, acción correctiva pendiente |
Aplíquelo ahora al conjunto de controles principal.
| Control de ISO/IEC 27002:2022 | Impulsor regulatorio | Evidencia principal | Evidencia operativa | Conclusión del auditor |
|---|---|---|---|---|
| 5.1 Políticas de seguridad de la información | NIS2, DORA, GDPR | Política de seguridad de la información aprobada, alcance del SGSI, asignación de roles | Registro de revisión de política, acuse de recibo de formación, actas de revisión por la dirección | Existe gobernanza, la dirección ha aprobado la orientación y la responsabilidad proactiva está documentada |
| 5.19 Seguridad de la información en las relaciones con proveedores | NIS2, DORA, GDPR | Política de proveedores, registro de proveedores, clasificación de proveedores | Revisiones de diligencia debida, evaluaciones de criticidad, revisiones contractuales, evidencia de derecho de auditoría | El riesgo de terceros se gobierna durante la incorporación, la contratación, la supervisión y la salida |
| 5.20 Tratamiento de la seguridad de la información en los acuerdos con proveedores | NIS2, DORA, GDPR | Cláusulas contractuales estándar, anexo de seguridad, condiciones de tratamiento de datos | Muestreo de contratos, aprobaciones de excepciones de cláusulas, registros de revisión jurídica | Los requisitos de seguridad están incorporados en los acuerdos con proveedores |
| 5.23 Seguridad de la información para el uso de servicios en la nube | DORA, NIS2, GDPR | Estándar de seguridad en la nube, evaluación de riesgos en la nube, aprobación de arquitectura | Revisión de proveedor en la nube, revisión de riesgo de concentración, prueba de incidente en la nube | El riesgo de servicios en la nube se identifica, gobierna, supervisa y prueba |
| 5.24 Planificación y preparación de la gestión de incidentes de seguridad de la información | NIS2, DORA, GDPR | Política de respuesta a incidentes, matriz de escalado, árbol de decisión de notificación | Tickets de incidentes, informes de ejercicios de mesa, lecciones aprendidas, evaluaciones de notificación | Los incidentes pueden detectarse, clasificarse inicialmente, escalarse y evaluarse para notificación regulatoria |
| 6.8 Notificación de eventos de seguridad de la información | NIS2, DORA, GDPR | Canal de notificación, material de concienciación, procedimiento de notificación de eventos | Informes de phishing, registros de línea directa, registros de simulación, entrevistas al personal | El personal sabe cómo notificar rápidamente sospechas de eventos de seguridad |
A continuación, ejecute un trazado de muestra. Seleccione un incidente de proveedor del último año y sígalo desde el ticket de incidente hasta el contrato del proveedor, desde la clasificación del proveedor hasta el registro de riesgos, desde el tratamiento de riesgos hasta la SoA y desde la SoA hasta la revisión por la dirección.
Si la cadena se rompe, no es un fracaso. Es una acción correctiva precisa antes de que un auditor, cliente, regulador o comité del consejo de administración detecte la deficiencia.
La evidencia centralizada es el acelerador ignorado
Muchas organizaciones tienen controles adecuados, pero una recuperación débil de evidencias. La prueba está dispersa entre correo electrónico, sistemas de tickets, carpetas de SharePoint, repositorios contractuales, plataformas de RR. HH., herramientas GRC y portales de proveedores. Durante la temporada de auditorías, el equipo de cumplimiento dedica semanas a perseguir capturas de pantalla.
Eso no es preparación para auditorías. Es recuperación ante auditoría.
La [P33S] Política de Auditoría y Supervisión del Cumplimiento - SME de Clarysec establece:
Todas las evidencias deberán almacenarse en una carpeta centralizada de auditoría.
De la sección “Requisitos de implementación de la política”, cláusula 6.2.1 de la política.
Una carpeta centralizada de auditoría no significa un vertedero sin control. Significa un repositorio estructurado y alineado con el SGSI, la SoA, el registro de riesgos, el plan de auditoría y el registro de cumplimiento.
| Carpeta | Contenido | Uso para cumplimiento cruzado |
|---|---|---|
| 01 Gobernanza | Alcance del SGSI, política de seguridad de la información, asignación de roles, actas de revisión por la dirección | Gobernanza de NIS2, gobernanza de TIC de DORA, responsabilidad proactiva de GDPR |
| 02 Riesgos y SoA | Registro de riesgos, plan de tratamiento de riesgos, SoA, aprobaciones de riesgo residual | Gestión de riesgos de NIS2, gestión del riesgo de las TIC de DORA |
| 03 Proveedores | Registro de proveedores, diligencia debida, contratos, calificaciones de criticidad, registros de revisión | Cadena de suministro de NIS2, riesgo de terceros de TIC de DORA, encargados del tratamiento de GDPR |
| 04 Incidentes | Tickets de incidentes, evaluaciones de brechas, decisiones de notificación, ejercicios de mesa | Notificación de NIS2, gestión de incidentes de DORA, notificación de brechas de GDPR |
| 05 Auditoría y mejora | Informes de auditoría interna, acciones correctivas, muestreo de evidencias, seguimiento por la dirección | Preparación para auditorías de ISO 27001:2022, preparación ante supervisión |
La Política de Cumplimiento Legal y Normativo - SME de Clarysec aborda directamente el problema del mapeo:
Cuando una regulación se aplique a múltiples áreas (por ejemplo, GDPR se aplica a conservación, seguridad y privacidad), esto deberá mapearse claramente en el Registro de Cumplimiento y en los materiales de formación.
De la sección “Requisitos de gobernanza”, cláusula 5.2.2 de la política.
Así es exactamente como ISO 27001:2022 se convierte en el eje de controles para NIS2 y DORA. No se depende del conocimiento tribal. Se mapean las regulaciones en procesos, políticas, controles, evidencias y formación.
La notificación de incidentes empieza con las personas, no con los portales
Una debilidad común de auditoría aparece cuando el plan de respuesta a incidentes parece sólido, pero los empleados no saben cuándo ni cómo notificar. Esto es peligroso para NIS2, DORA y GDPR porque los plazos de evaluación regulatoria dependen de la detección, el escalado y la clasificación.
En Zenith Blueprint, fase de controles en acción, paso 16, Clarysec destaca la notificación de incidentes impulsada por el personal conforme al control 6.8 de ISO/IEC 27002:2022. La guía indica que la respuesta a incidentes empieza con las personas. Las organizaciones deben crear un canal de notificación claro, sencillo y accesible, como una dirección de correo monitorizada, un portal interno, una línea directa o una categoría de ticket. También recomienda formación de concienciación, una cultura de notificación sin culpabilización, confidencialidad, notificación de bajo umbral y simulaciones periódicas.
El impacto en el cumplimiento cruzado es directo. Zenith Blueprint vincula esta capacidad de notificación del personal con GDPR Article 33, NIS2 Article 23 y DORA Article 17. Si los empleados dudan al notificar actividad sospechosa, la organización puede perder tiempo crítico antes de que los equipos jurídicos, de seguridad o regulatorios puedan evaluar las obligaciones de notificación.
Una prueba práctica del control es sencilla:
- Pregunte a cinco empleados cómo notificar un correo electrónico sospechoso de phishing.
- Compruebe si el canal de notificación está monitorizado.
- Confirme si el sistema de tickets tiene una categoría de incidente de seguridad.
- Revise la última simulación o ejercicio de mesa.
- Verifique que las lecciones aprendidas se revisaron en la revisión por la dirección.
Si alguna respuesta no está clara, actualice la hoja de instrucciones de incidentes, el material de formación, el canal de notificación y la referencia de evidencias en la SoA.
Cómo inspeccionan distintos auditores el mismo eje
Las evidencias de cumplimiento cruzado deben resistir distintos enfoques de auditoría. El mismo control puede probarse de manera diferente según el mandato del revisor.
| Enfoque del auditor | Pregunta probable | Evidencias esperadas | Fallo habitual |
|---|---|---|---|
| Auditor de ISO 27001:2022 | ¿Por qué es aplicable este control y opera conforme a lo descrito? | Justificación de la SoA, vínculo con el tratamiento de riesgos, política, registros operativos, resultados de auditoría interna | El control existe, pero la justificación de la SoA es vaga o está desactualizada |
| Evaluador orientado a NIS2 | ¿Puede demostrar medidas de ciberseguridad basadas en riesgos y coordinación de incidentes? | Registro de riesgos, política de gobernanza, plan de incidentes, flujo de trabajo de notificación, evidencias de riesgo de proveedores | El mapeo de NIS2 existe en una presentación, pero no en evidencias operativas |
| Supervisor orientado a DORA | ¿Puede probar la gestión del riesgo de las TIC, la clasificación de incidentes, las pruebas y la supervisión de terceros? | Registro de riesgos de TIC, criticidad de proveedores, clasificación de incidentes, pruebas de resiliencia, cláusulas contractuales | Los registros de proveedores no distinguen proveedores críticos de TIC de proveedores ordinarios |
| Revisor orientado a GDPR | ¿Puede demostrar responsabilidad proactiva, seguridad del tratamiento, controles de encargados del tratamiento y evaluación de brechas? | Mapeo de protección de datos, cláusulas de encargados, registros de evaluación de brechas, evidencias de acceso y cifrado | Los controles de seguridad están implantados, pero no vinculados a riesgos sobre datos personales |
| Auditor orientado a NIST | ¿Puede mostrar gobernanza, identificación del riesgo, protección, detección, respuesta y recuperación? | Gobernanza de políticas, registros de activos y riesgos, registros de detección, evidencias de incidentes y recuperación | Existen evidencias técnicas, pero la responsabilidad de gobernanza es débil |
| Auditor de COBIT 2019 o estilo ISACA | ¿Están definidos los objetivos de gobernanza, responsabilidades, supervisión del desempeño y actividades de aseguramiento? | RACI, responsabilidad de controles, informes de dirección, plan de auditoría, métricas, acciones correctivas | Los controles son técnicos, pero no se gobiernan mediante responsabilidad medible |
Aquí es donde Zenith Controls aporta valor más allá de una simple tabla de mapeo. Ayuda a traducir los controles de ISO/IEC 27002:2022 a perspectivas relevantes para auditoría, incluidos atributos de control, relaciones regulatorias y expectativas de evidencia. Para el control 5.1, los atributos respaldan la gobernanza, la gestión de políticas, la responsabilidad proactiva y los objetivos de seguridad. Para el control 5.24, los atributos respaldan conceptos de respuesta y recuperación, preparación ante incidentes y acción correctiva. Para el control 5.19, los atributos de la relación con proveedores conectan gobernanza, riesgo del ecosistema, protección y supervisión de terceros.
Qué debe ver el consejo de administración
El consejo de administración no necesita cada línea de la SoA. Sí necesita la historia que cuenta la SoA.
Un paquete sólido para el consejo de administración sobre la alineación de ISO 27001:2022, NIS2 y DORA debe incluir:
- Alcance del SGSI y servicios de negocio cubiertos.
- Principales riesgos de seguridad de la información y de TIC.
- Resumen de controles aplicables por dominio.
- Estado del mapeo de NIS2, DORA y GDPR.
- Proveedores críticos y riesgos de concentración.
- Métricas de notificación de incidentes y resultados de ejercicios de mesa.
- Acciones correctivas abiertas y tratamientos de riesgos vencidos.
- Decisiones necesarias sobre aceptación del riesgo, presupuesto, responsabilidad y recursos.
Esto convierte el cumplimiento en evidencia de gobernanza. También se alinea con el propósito del control 5.1 en Zenith Controls, donde las políticas de seguridad de la información respaldan la dirección a nivel ejecutivo, la responsabilidad proactiva y los objetivos de seguridad.
Errores habituales que deben evitarse
El primer error es asumir que la certificación ISO 27001:2022 demuestra automáticamente el cumplimiento de NIS2 o DORA. No lo hace. ISO 27001:2022 proporciona un sistema de gestión sólido y un eje de controles, pero aún se necesitan delimitación regulatoria, análisis jurídico, interpretación sectorial, flujos de trabajo de notificación y conocimiento de las expectativas de las autoridades nacionales.
El segundo error es tratar la SoA como estática. La SoA debe evolucionar cuando surgen nuevos proveedores, sistemas, incidentes, regulaciones, servicios o riesgos. Zenith Blueprint, paso 24, recomienda verificar de forma cruzada la SoA con el registro de riesgos y el plan de tratamiento, asegurando que cada control seleccionado tenga una justificación basada en un riesgo mapeado, un requisito legal o una necesidad de negocio.
El tercer error es mapear a un nivel demasiado alto. Una diapositiva que dice “ISO 27001 mapea con DORA” no es evidencia de auditoría. Una entrada específica de la SoA que vincula la seguridad de la relación con proveedores con un riesgo de proveedor crítico de TIC, una cláusula contractual, un registro de revisión de proveedor y una expectativa de supervisión de terceros de DORA es mucho más sólida.
El cuarto error es no centralizar las evidencias. Si el responsable de cumplimiento dedica dos semanas a recopilar capturas de pantalla antes de cada auditoría, la organización tiene un problema de recuperación.
El quinto error es ignorar los controles sobre las personas. La notificación de incidentes, la incorporación de proveedores, las revisiones de acceso, la aceptación de políticas y el escalado dependen del comportamiento humano. Un proceso impecable que nadie sigue se derrumbará bajo el muestreo de auditoría.
El modelo operativo de Clarysec para el cumplimiento cruzado
El método de Clarysec conecta la narrativa de cumplimiento desde la estrategia hasta las evidencias:
- En Zenith Blueprint, fase de gestión de riesgos, paso 13, se mapean controles con riesgos y se construye la SoA como documento puente.
- En Zenith Blueprint, fase de gestión de riesgos, paso 14, se referencian de forma cruzada los requisitos de GDPR, NIS2 y DORA con políticas y controles.
- En Zenith Blueprint, fase de controles en acción, paso 16, se operacionaliza la notificación de incidentes impulsada por las personas para que el escalado comience pronto.
- En Zenith Blueprint, fase de auditoría, revisión y mejora, paso 24, se finaliza y prueba la SoA, se verifica de forma cruzada con el plan de tratamiento de riesgos y se prepara como uno de los primeros documentos que solicitará un auditor.
Este método está respaldado por políticas de Clarysec que convierten los principios en reglas operativas: gobernanza de la seguridad de la información, tratamiento de riesgos, seguridad de proveedores, respuesta a incidentes, mapeo legal y regulatorio, y almacenamiento de evidencias.
El resultado no es solo preparación para ISO 27001:2022. Es un sistema reutilizable de evidencias de cumplimiento para NIS2, DORA, GDPR, aseguramiento de clientes, auditoría interna y supervisión del consejo de administración.
Próximos pasos: construir una vez, demostrar muchas veces
Si su organización se enfrenta a NIS2, DORA, GDPR, auditorías de clientes o presión de certificación ISO 27001:2022, empiece por el eje vertebrador.
- Revise su SoA y añada columnas de impulsores regulatorios para NIS2, DORA y GDPR.
- Contraste la SoA con su registro de riesgos y su plan de tratamiento de riesgos.
- Mapee los proveedores críticos con controles de seguridad de proveedores, cláusulas contractuales y evidencias de supervisión.
- Pruebe su flujo de trabajo de notificación de incidentes con un ejercicio de mesa.
- Centralice las evidencias de auditoría por control, regulación, responsable y estado de prueba.
- Utilice Zenith Controls para traducir los controles de ISO/IEC 27002:2022 en evidencias de cumplimiento cruzado.
- Utilice Zenith Blueprint para pasar del tratamiento de riesgos a una validación de la SoA preparada para auditorías.
- Despliegue el conjunto de políticas de Clarysec, incluida la Política de Seguridad de la Información, la Política de gestión de riesgos, la Política de seguridad de terceros y proveedores y la Política de Respuesta a Incidentes, para acelerar la implementación.
El camino más rápido no consiste en más listas de verificación desconectadas. Consiste en un SGSI integrado, una SoA trazable, un modelo centralizado de evidencias y un ritmo operativo único de cumplimiento cruzado.
Clarysec puede ayudarle a convertir ISO 27001:2022 de un proyecto de certificación en un eje práctico de controles para NIS2 y DORA. Descargue Zenith Blueprint, explore Zenith Controls o reserve una evaluación de Clarysec para construir un modelo de evidencias preparado para auditorías antes de que el próximo regulador, cliente o comité del consejo de administración pida pruebas.
Frequently Asked Questions
About the Author

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


