Guía 2026 del registro de obligaciones de cumplimiento en ciberseguridad

María, la CISO de una plataforma fintech en rápido crecimiento, tenía veinte minutos antes del cierre del paquete trimestral para el consejo de administración. El mensaje del director general era breve e incómodo:

“María, necesito una sola diapositiva que demuestre que tenemos bajo control nuestras obligaciones legales de ciberseguridad para 2026. No solo ISO 27001. Me refiero a todo. NIS2, DORA, GDPR, nuestros contratos con clientes. ¿Cumplimos? ¿Dónde está la prueba? ¿Quién es responsable?”

A las 08:15 llegaron tres solicitudes más. Legal quería saber si la empresa era una entidad importante conforme a las normas de transposición de NIS2 de un Estado miembro. El DPD quería saber si una exportación sospechosa de una base de datos debía tratarse como una violación de datos personales conforme a GDPR, un incidente grave relacionado con las TIC conforme a DORA, ambas cosas o ninguna. Compras quería aprobar un proveedor de analítica antifraude que trataría datos personales de la UE, daría soporte a un servicio crítico y utilizaría un subencargado en la nube fuera de la UE.

Ninguna de estas preguntas es inusual en 2026. Lo peligroso es que la organización no pueda responderlas desde una única fuente de verdad mantenida.

La mayoría de las empresas tienen políticas. Muchas tienen registros de riesgos, expedientes de proveedores, registros de privacidad, procedimientos de respuesta a incidentes y una Declaración de aplicabilidad. La brecha aparece cuando un miembro del consejo de administración, un auditor, un regulador o un cliente importante formula una pregunta sencilla:

“Muéstreme cada obligación legal, regulatoria y contractual de ciberseguridad aplicable, quién es responsable de ella, con qué frecuencia se revisa, qué control la implementa, qué evidencia la demuestra y cómo se elevan las excepciones a la dirección.”

Eso es el registro de obligaciones de cumplimiento en ciberseguridad.

Para los CISO, responsables de cumplimiento, auditores y propietarios de procesos, este registro ya no es una hoja de cálculo administrativa. Es el mecanismo operativo que conecta las obligaciones nacionales de NIS2, las expectativas supervisoras de DORA, la responsabilidad proactiva de GDPR, los requisitos de ISO/IEC 27001:2022, los contratos con clientes y las políticas internas en un sistema de gobernanza operativo.

Clarysec trata el registro como un artefacto vivo del SGSI, no como un anexo legal. En la Política de Cumplimiento Legal y Normativo, la función de cumplimiento:

“Mantiene el Registro de Obligaciones de Cumplimiento, que enumera todas las leyes, normas, certificaciones y cláusulas contractuales aplicables.”
De la Política de Cumplimiento Legal y Normativo, roles y responsabilidades, cláusula 4.2.1.

La palabra importante es “mantiene”. Un registro creado para la certificación e ignorado hasta la siguiente auditoría no es un mecanismo de cumplimiento. Es evidencia de optimismo histórico.

Qué debe hacer un registro de obligaciones de cumplimiento en ciberseguridad en 2026

Un registro de obligaciones útil cumple cinco funciones.

Primero, identifica obligaciones. Estas incluyen leyes, reglamentos, normas, certificaciones y cláusulas contractuales. En 2026, las fuentes habituales incluyen NIS2 para entidades esenciales e importantes, DORA para entidades financieras cubiertas y proveedores terceros de servicios TIC, GDPR para responsables y encargados del tratamiento que gestionan datos personales de la UE, requisitos de ISO/IEC 27001:2022 para el SGSI, compromisos de seguridad en la nube, cláusulas de notificación de incidentes de clientes, reglas de externalización y requisitos de seguridad de proveedores.

Segundo, clasifica la aplicabilidad. NIS2 puede aplicarse porque la organización pertenece a un sector del Anexo I o del Anexo II, proporciona infraestructura digital, actúa como proveedor de servicios gestionados, presta servicios de computación en la nube o entra en una categoría independiente del tamaño, como DNS, TLD o servicios de confianza. DORA puede aplicarse porque la organización es una entidad financiera o un proveedor tercero de servicios TIC que da soporte a entidades financieras. GDPR puede aplicarse porque la organización trata datos personales de la UE, ofrece servicios a personas en la UE o supervisa comportamientos en la UE.

Tercero, mapea las obligaciones con controles, políticas, procesos y sistemas internos. Aquí es donde el registro se vuelve operativo. Las medidas de gestión de riesgos del Article 21 de NIS2 se mapean con evaluación de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, desarrollo seguro, revisiones de la eficacia del control, formación, criptografía, control de acceso, gestión de activos y autenticación multifactor (MFA) cuando proceda. DORA se mapea con responsabilidad proactiva del órgano de administración, gestión del riesgo de las TIC, clasificación de incidentes, pruebas de resiliencia, registros de terceros y estrategias de salida. GDPR se mapea con registros de actividades de tratamiento, base jurídica, minimización de datos, conservación, seguridad del tratamiento, evaluación de violaciones de seguridad y evidencias de responsabilidad proactiva.

Cuarto, asigna responsables y cadencia de revisión. Sin responsabilidad asignada, el cumplimiento se convierte en un tema de reunión. Con responsabilidad asignada, se convierte en un proceso gestionado.

Quinto, define evidencias. El registro debe responder qué artefacto demuestra que esta obligación se cumple hoy. Las evidencias pueden incluir actas del consejo de administración, registros de evaluación de riesgos, tickets de incidentes, diligencia debida de proveedores, cláusulas contractuales, configuraciones de cifrado, informes de vulnerabilidades, revisiones de acceso, registros de pruebas de copias de seguridad, avisos de privacidad, EIPD, evaluaciones de violaciones de seguridad y hallazgos de auditoría interna.

La política de Clarysec hace explícita esta trazabilidad:

“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).”
De la Política de Cumplimiento Legal y Normativo, requisitos de implementación de la política, cláusula 6.2.1.

También define la evidencia como parte del mismo mecanismo:

“Artefactos o registros requeridos para demostrar el cumplimiento (por ejemplo, registros de auditoría, ajustes de configuración del cifrado, documentación del consentimiento)”
De la Política de Cumplimiento Legal y Normativo, requisitos de implementación de la política, cláusula 6.2.2.3.

Esta es la diferencia entre concienciación sobre el cumplimiento y aseguramiento del cumplimiento.

Por qué ISO/IEC 27001:2022 es la columna vertebral

ISO/IEC 27001:2022 se trata a menudo como un objetivo de certificación, pero para la gestión de obligaciones su valor es mayor. Da al registro un encaje dentro del sistema de gestión.

Las cláusulas 4.1 a 4.4 exigen que la organización comprenda las cuestiones internas y externas, identifique las partes interesadas y determine los requisitos legales, regulatorios y contractuales pertinentes para el SGSI. Las cláusulas 5.1 a 5.3 exigen compromiso de liderazgo, alineación de políticas, recursos y responsabilidades asignadas. Las cláusulas 6.1 a 6.2 exigen evaluación de riesgos, tratamiento de riesgos, la Declaración de aplicabilidad y objetivos medibles informados por los requisitos aplicables. Las cláusulas 8, 9 y 10 crean el ciclo operativo: implementar controles, reevaluar riesgos, supervisar el desempeño, realizar auditorías internas, revisar a nivel de dirección y corregir no conformidades.

En Zenith Blueprint: hoja de ruta de 30 pasos para auditores, Clarysec sitúa esto al inicio de la fase de fundamentos y liderazgo del SGSI, paso 2: necesidades de las partes interesadas y alcance del SGSI. El Blueprint recomienda a los equipos identificar los requisitos de las partes interesadas revisando requisitos legales y regulatorios, extrayendo cláusulas contractuales de seguridad, entrevistando a partes interesadas y considerando las normas del sector esperadas por los socios.

“La cláusula 4.2 no exige un documento específico, pero en la práctica resulta útil crear una tabla de análisis de partes interesadas. Puede ser una tabla sencilla con columnas: Parte interesada, Necesidades/Expectativas, Cómo lo abordamos.”
De Zenith Blueprint, fase de fundamentos y liderazgo del SGSI, paso 2.

Ese análisis de partes interesadas se convierte en la entrada previa al registro de obligaciones. Después, el registro se convierte en el puente hacia el tratamiento de riesgos.

En la fase de gestión de riesgos, paso 13, Zenith Blueprint indica a los equipos que mapeen controles con riesgos, cláusulas y regulaciones externas:

“Referencie regulaciones de forma cruzada: si ciertos controles se implementan específicamente para cumplir GDPR, NIS2 o DORA, puede indicarlo en el Registro de Riesgos (como parte de la justificación del impacto del riesgo) o en las notas de la SoA.”
De Zenith Blueprint, fase de gestión de riesgos, paso 13: planificación del tratamiento de riesgos y Declaración de aplicabilidad.

Esa es la trazabilidad que buscan los auditores. Si GDPR impulsa controles de cifrado, conservación y evaluación de violaciones de seguridad, indíquelo. Si NIS2 impulsa el escalado de notificación de incidentes y medidas de seguridad de proveedores, indíquelo. Si DORA impulsa registros de riesgo de terceros TIC y pruebas de salida, indíquelo.

Los tres anclajes de control de ISO/IEC 27002:2022

El control central de ISO/IEC 27002:2022 para la gestión de obligaciones es 5.31, requisitos legales, estatutarios, regulatorios y contractuales. Zenith Controls: guía de cumplimiento cruzado de Clarysec clasifica 5.31 como un control preventivo vinculado a confidencialidad, integridad y disponibilidad, alineado con el concepto de ciberseguridad Identificar y operativo en la capacidad Legal y Cumplimiento en los dominios de gobernanza, ecosistema y protección.

La narrativa de Zenith Controls es directa:

“La seguridad no existe en el vacío. Opera dentro de una red de obligaciones, algunas definidas por la ley, otras por contrato y otras por regulación sectorial.”
De Zenith Controls, tratamiento del control 5.31 de ISO/IEC 27002:2022.

El control 5.31 no funciona solo. Dos controles de apoyo son esenciales.

El control 5.2, roles y responsabilidades de seguridad de la información, garantiza que las obligaciones no se asignen a “la organización” o a “TI” en abstracto. El mapeo de Zenith Controls vincula 5.2 con propiedad de políticas, supervisión del cumplimiento, gestión de incidentes, concienciación, revisión independiente, gestión de evidencias y gobernanza de acceso privilegiado.

El control 5.36, cumplimiento de políticas, reglas y normas de seguridad de la información, cierra el ciclo. Garantiza que los requisitos documentados se sigan, supervisen, notifiquen y corrijan. El mapeo de Zenith Controls vincula 5.36 con políticas de seguridad de la información, proceso disciplinario, revisión independiente, roles y responsabilidades, evaluación de eventos, registro de eventos, supervisión y registros protegidos.

En conjunto, estos controles responden a las preguntas clave del auditor.

Para organizaciones más pequeñas, la misma estructura puede ser más ligera. La Política de Cumplimiento Legal y Normativo - pyme de Clarysec establece:

“El Director General debe mantener un Registro de Cumplimiento sencillo y estructurado que enumere:”
De la Política de Cumplimiento Legal y Normativo - pyme, requisitos de gobernanza, cláusula 5.1.1.

También exige una revisión rutinaria:

“El Registro de Cumplimiento debe revisarse trimestralmente y actualizarse cuando:”
De la Política de Cumplimiento Legal y Normativo - pyme, requisitos de gobernanza, cláusula 5.1.2.

Para las pymes, el registro puede empezar de forma sencilla. Aun así, necesita responsables, cadencia y evidencia.

Construya el registro en torno a obligaciones, no a marcos

El error más habitual es crear un seguimiento para NIS2, otro para DORA, otro para GDPR, otro para ISO/IEC 27001:2022 y otro para contratos con clientes. Eso genera solicitudes de evidencias duplicadas, responsables contradictorios y equipos agotados.

Un enfoque mejor es mapear obligaciones con controles. Una capacidad de seguridad puede satisfacer varios impulsores legales si el registro preserva las diferencias de activador, alcance, plazo y autoridad.

Por ejemplo, la respuesta a incidentes da soporte a la notificación de incidentes significativos de NIS2, la notificación de incidentes graves relacionados con las TIC de DORA y la evaluación de violaciones de datos personales de GDPR. La diligencia debida de proveedores da soporte a la seguridad de la cadena de suministro de NIS2, al riesgo de terceros TIC de DORA y a la gobernanza de encargados del tratamiento de GDPR. El registro de eventos y la supervisión dan soporte a la detección de incidentes, la eficacia del control y la responsabilidad proactiva. Los inventarios de activos y datos dan soporte a la evaluación de riesgos de NIS2, DORA, GDPR e ISO/IEC 27001:2022.

El objetivo no es ocultar las diferencias legales. El objetivo es evitar implementar la misma capacidad tres veces.

Un modelo práctico de registro que puede implementar esta semana

Un registro de obligaciones al estilo de Clarysec debe ser lo bastante sencillo para mantenerse y lo bastante detallado para superar un muestreo de auditoría. Los campos mínimos son:

1. ID de obligación.
2. Fuente, como NIS2, DORA, GDPR, ISO/IEC 27001:2022, contrato de cliente o política interna.
3. Referencia específica de artículo, cláusula o contrato.
4. Resumen del requisito.
5. Justificación de aplicabilidad.
6. Proceso o servicio de la organización afectado.
7. Escenario de riesgo en caso de incumplimiento.
8. Mapeo de controles, incluidos controles ISO/IEC 27002:2022 y referencias a políticas internas.
9. Propietario del control.
10. Propietario de la evidencia.
11. Cadencia de revisión.
12. Ubicación de la evidencia.
13. Excepciones o deficiencias abiertas.
14. Indicador de escalado a revisión por la dirección.
15. Fecha de última revisión y fecha de próxima revisión.
16. Estado.

A continuación se muestra un ejemplo práctico para un proveedor fintech SaaS que opera en la UE.

Observe que cada fila es accionable. No se limita a decir “cumplir DORA”. Identifica el requisito, el mapeo interno, el responsable, el ritmo de revisión y la evidencia.

La Política de funciones y responsabilidades de gobernanza - pyme de Clarysec refuerza esta disciplina de propiedad:

“Las responsabilidades de gobernanza (por ejemplo, revisión de políticas, aprobación de excepciones, supervisión de proveedores) deben asignarse a personas o roles específicos.”
De la Política de funciones y responsabilidades de gobernanza - pyme, requisitos de gobernanza, cláusula 5.3.

En entornos empresariales, el mismo concepto debe reflejarse en una matriz RACI, un registro de propiedad de controles y un paquete de informes para la dirección.

Ejemplo de notificación de incidentes: un procedimiento, múltiples obligaciones

Un proveedor SaaS determina que puede estar dentro del alcance de NIS2 porque presta actividades en la nube o de servicios gestionados en la UE y cumple criterios relevantes de tamaño o sector. La organización ya tiene un plan de respuesta a incidentes, pero no ha mapeado la notificación de NIS2 en los procedimientos de escalado.

La entrada del registro debe capturar la obligación con precisión:

• Fuente: NIS2 Article 23.
• Requisito: notificar al CSIRT o a la autoridad competente, sin demora indebida, los incidentes significativos, con alerta temprana en un plazo de 24 horas, notificación en un plazo de 72 horas e informe final en un plazo de un mes.
• Aplicabilidad: potencialmente aplicable por la categoría del servicio y las operaciones en Estados miembros.
• Riesgo si no se cumple: incumplimiento regulatorio, retraso en la notificación a partes interesadas, pérdida de confianza de clientes.

Después, mapéela con controles. Los controles 5.24 a 5.28 de ISO/IEC 27002:2022 cubren planificación de la gestión de incidentes, evaluación, respuesta, aprendizaje y recopilación de evidencias. El control 5.31 cubre el seguimiento de obligaciones legales. El control 5.2 cubre la asignación de roles. El control 5.36 cubre la supervisión de si el proceso se sigue.

La responsabilidad debe ser explícita. El responsable de incidentes es propietario de la clasificación y el escalado. Legal o Cumplimiento es propietario de la interpretación regulatoria y de la autorización de la notificación. Comunicaciones es propietario de la comunicación con clientes. El propietario de la evidencia mantiene el expediente del incidente.

La evidencia debe incluir el registro de clasificación del incidente, la cronología, hora de conocimiento, hora de triaje, hora de escalado, decisión de notificación, presentación al regulador si aplica, decisión de comunicación al cliente, lecciones aprendidas y acciones correctivas.

Un ejercicio de simulación convierte entonces el registro en realidad. Use un escenario en el que una configuración incorrecta en la nube cause una posible exposición de datos de clientes y una interrupción del servicio. Compruebe si el equipo puede identificar el reloj de 24 horas de NIS2, determinar si se requiere una evaluación de violación de seguridad conforme a GDPR, clasificar el posible impacto de DORA si se ven afectados servicios financieros y producir un expediente de evidencias completo.

Así es como el registro de obligaciones se convierte en un control. Cambia el comportamiento operativo.

La gestión de evidencias es donde las auditorías suelen fallar

Muchas organizaciones pueden mostrar un registro. Menos pueden demostrar que la evidencia está completa, vigente, protegida y vinculada.

La Política de Auditoría y Supervisión del Cumplimiento - pyme de Clarysec establece el requisito básico:

“Todas las evidencias deben almacenarse en una carpeta de auditoría centralizada.”
De la Política de Auditoría y Supervisión del Cumplimiento - pyme, requisitos de implementación de la política, cláusula 6.2.1.

Esa frase resuelve un fallo de auditoría habitual. Las evidencias dispersas entre correo electrónico, tickets de Jira, carpetas de SharePoint, portales de proveedores y unidades personales no están preparadas para auditoría. La carpeta centralizada no tiene que ser una única carpeta literal para todos los archivos, pero debe existir un repositorio o índice de evidencias controlado que indique al auditor dónde reside el artefacto fehaciente.

Para cada obligación, la evidencia debe nombrarse de forma coherente, mapearse con el ID de obligación y el ID de control, tener un propietario nominal o un rol propietario, estar protegida frente a modificaciones no autorizadas, conservarse conforme a requisitos legales y contractuales, revisarse con una cadencia definida y vincularse a excepciones y acciones correctivas.

El tratamiento del control 5.31 en Zenith Controls vincula los requisitos legales con la conservación de registros mediante el control 5.33, la privacidad y protección de la información de identificación personal mediante el control 5.34, la revisión independiente mediante el control 5.35 y el cumplimiento interno mediante el control 5.36. Esto importa porque la evidencia puede contener por sí misma información regulada, como datos personales, indicadores forenses, registros de acceso privilegiado o datos confidenciales de clientes.

La perspectiva de auditoría: cómo probarán el registro distintos revisores

Un registro sólido resiste múltiples perspectivas de auditoría.

Un auditor de ISO/IEC 27001:2022 empezará por el contexto, las partes interesadas, el alcance, el tratamiento de riesgos, la Declaración de aplicabilidad, la supervisión, la auditoría interna y la revisión por la dirección. Para el control 5.31, el auditor esperará ver que los requisitos legales y contractuales aplicables están identificados, se mantienen actualizados y se reflejan en los controles. Para el control 5.2, verificará si las responsabilidades están asignadas y se comprenden. Para el control 5.36, buscará supervisión, no conformidades y acciones correctivas.

Un evaluador alineado con NIST se centrará en los resultados de gobernanza. NIST Cybersecurity Framework 2.0 GOVERN incluye GV.OC-03, que espera que los requisitos legales, regulatorios y contractuales relativos a la ciberseguridad, incluidas las obligaciones de privacidad y libertades civiles, se comprendan y gestionen. El evaluador puede solicitar un perfil organizativo, un análisis de deficiencias y un plan de acción priorizado, y después muestrear si las obligaciones se traducen en gestión de activos, control de acceso, protección de datos, registro de eventos, respuesta y recuperación.

Un auditor de COBIT 2019 o ISACA observará los objetivos de gobernanza y gestión. MEA03, gestionar el cumplimiento de requisitos externos, es especialmente relevante. El auditor puede comprobar si los requisitos externos se identifican mediante MEA03.01, si las respuestas se optimizan mediante MEA03.02, si el cumplimiento se confirma mediante MEA03.03 y si se obtiene aseguramiento mediante MEA03.04.

Un auditor basado en ISACA ITAF enfatizará evidencias suficientes y apropiadas. Puede seleccionar un requisito de notificación de violaciones de seguridad de GDPR, un requisito de registro de proveedores de DORA y un requisito de notificación de incidentes de NIS2, y luego solicitar la pista de evidencias de extremo a extremo.

Un evaluador técnico puede validar el control 5.36 mediante evidencias de configuración. Si el registro indica que NIS2 y los contratos con clientes exigen MFA para el acceso privilegiado, puede revisar los ajustes del proveedor de identidad. Si indica que GDPR y los contratos exigen cifrado, puede inspeccionar el cifrado de bases de datos, los registros de gestión de claves y los diagramas de flujo de datos. Si DORA exige supervisión de servicios TIC de terceros, puede inspeccionar revisiones de servicio, informes de SLA y registros de pruebas de salida.

El registro necesita evidencias de gobernanza y evidencias técnicas.

La revisión por la dirección cierra el ciclo de responsabilidad proactiva

Un registro de obligaciones de cumplimiento no debe ser propiedad silenciosa de Cumplimiento. Debe llegar a la revisión por la dirección porque NIS2, DORA, GDPR e ISO/IEC 27001:2022 se basan en la responsabilidad proactiva.

NIS2 exige que los órganos de administración aprueben las medidas de gestión de riesgos de ciberseguridad y supervisen su implementación. DORA atribuye al órgano de administración la responsabilidad última de la gestión del riesgo de las TIC. GDPR exige que los responsables del tratamiento demuestren el cumplimiento. ISO/IEC 27001:2022 exige que la revisión por la dirección considere cambios en el contexto, necesidades de las partes interesadas, resultados de auditoría, resultados de supervisión, resultados de evaluación de riesgos, estado del tratamiento y oportunidades de mejora.

La Política de Seguridad de la Información de Clarysec se alinea con esta expectativa:

“Las actividades de revisión por la dirección (conforme a ISO/IEC 27001 Cláusula 9.3) se realizarán al menos anualmente e incluirán:”
De la Política de Seguridad de la Información, requisitos de gobernanza, cláusula 5.3.

La política de auditoría para pymes añade el vínculo operativo:

“Los hallazgos de auditoría y las actualizaciones de estado deben incluirse en el proceso de revisión por la dirección del SGSI.”
De la Política de Auditoría y Supervisión del Cumplimiento - pyme, requisitos de gobernanza, cláusula 5.4.3.

La revisión por la dirección no necesita cada fila. Necesita tendencias, decisiones de riesgo, excepciones, recursos y responsabilidad proactiva.

Esto convierte el registro de un expediente de cumplimiento en una herramienta de liderazgo.

Patrones comunes de fallo y cómo evitarlos

El primer patrón de fallo es que Legal es propietario de la ley, Seguridad es propietaria de los controles y nadie es propietario del mapeo. Clarysec lo evita exigiendo que las obligaciones se mapeen con políticas, controles y propietarios dentro del SGSI.

El segundo es hacer seguimiento de marcos en lugar de obligaciones. Una entrada de registro que dice “DORA” no es accionable. Una entrada que dice “DORA Article 28, gestión del riesgo de terceros TIC, exige diligencia debida, disposiciones contractuales, supervisión y estrategias de salida” sí es accionable.

El tercero es la ausencia de cadencia. La revisión trimestral es una base práctica para muchas organizaciones, con actualizaciones motivadas por eventos ante nuevos servicios, nuevos países, nuevos proveedores, incidentes, auditorías y cambios contractuales.

El cuarto es una evidencia que existe pero no se puede encontrar. El principio de carpeta de auditoría centralizada aborda esto directamente.

El quinto son excepciones informales. Si un control no puede cumplir temporalmente una obligación, la excepción debe documentarse, someterse a evaluación de riesgos, aprobarse, limitarse en el tiempo y revisarse.

El sexto es una revisión por la dirección ceremonial. El registro debe impulsar decisiones sobre presupuesto, personal, remediación de proveedores, negociación contractual, aceptación del riesgo y acciones correctivas.

Cómo Clarysec convierte el registro en un mecanismo operativo

El enfoque de 30 pasos de Clarysec hace práctica la gestión de obligaciones.

En Zenith Blueprint, el paso 2 identifica las necesidades de las partes interesadas y los requisitos aplicables. El paso 13 mapea controles con riesgos, cláusulas y la Declaración de aplicabilidad. El paso 23 aborda los controles organizativos, incluido el requisito de crear y mantener un registro de requisitos legales y regulatorios.

El Blueprint establece:

“Trabaje con Legal, Cumplimiento o asesores jurídicos externos para crear un registro de leyes, regulaciones y obligaciones contractuales aplicables relacionadas con la seguridad de la información (5.31). Debe incluir leyes de protección de datos (por ejemplo, GDPR), requisitos sectoriales específicos y mandatos de certificación. Asegúrese de que el equipo del SGSI sepa dónde consultarlo y de que los cambios se revisen al menos trimestralmente.”
De Zenith Blueprint, fase de controles en acción, paso 23.

Las políticas de Clarysec proporcionan las reglas de gobernanza: mantener el registro, asignar responsabilidades, centralizar evidencias, revisar hallazgos e incluir el estado en la revisión por la dirección.

Zenith Controls proporciona la brújula de cumplimiento cruzado. Para el control 5.31, mapea la gestión de obligaciones con la responsabilidad proactiva de GDPR, las obligaciones de ciberseguridad de NIS2, la gestión del riesgo de las TIC de DORA, la gobernanza de NIST CSF, la gestión de programas y la monitorización continua de NIST SP 800-53, y la supervisión del cumplimiento externo de COBIT 2019. Para el control 5.2, conecta la responsabilidad por roles con GDPR, NIS2, DORA, NIST y COBIT. Para el control 5.36, conecta la supervisión del cumplimiento de políticas con la responsabilidad proactiva de GDPR, la higiene cibernética y las expectativas de control de acceso de NIS2, la resiliencia operativa de DORA, la monitorización continua de NIST y la supervisión de conformidad de COBIT.

El valor es simple: un registro, una arquitectura de controles, muchos resultados de cumplimiento.

Próximos pasos: prepare su registro de obligaciones para auditoría

Las organizaciones que gestionen bien el cumplimiento de 2026 no serán las que tengan más hojas de cálculo. Serán las que tengan trazabilidad: de obligación a responsable, de responsable a control, de control a evidencia, de evidencia a revisión, de revisión a mejora.

Empiece con estas acciones:

1. Cree o actualice su registro de obligaciones de cumplimiento en ciberseguridad.
2. Añada NIS2, DORA, GDPR, ISO/IEC 27001:2022 y las principales obligaciones contractuales de clientes.
3. Mapee cada obligación con políticas, controles ISO/IEC 27002:2022, responsables, cadencia de revisión y evidencias.
4. Identifique deficiencias, excepciones y evidencias caducadas.
5. Añada el estado del registro a la próxima revisión por la dirección del SGSI.
6. Use Zenith Blueprint de Clarysec para situar el registro dentro de la hoja de ruta de 30 pasos del SGSI.
7. Use Zenith Controls para mapear de forma cruzada las obligaciones con las expectativas de ISO, NIST, COBIT, GDPR, NIS2 y DORA.
8. Use la Política de Cumplimiento Legal y Normativo, la Política de Cumplimiento Legal y Normativo - pyme, la Política de funciones y responsabilidades de gobernanza - pyme, la Política de Auditoría y Supervisión del Cumplimiento - pyme y la Política de Seguridad de la Información de Clarysec para formalizar la responsabilidad, la revisión, el almacenamiento de evidencias y la rendición de cuentas de la dirección.

Clarysec puede ayudarle a incorporar esa trazabilidad en su SGSI antes de que el auditor, regulador, miembro del consejo de administración o cliente la solicite. Descargue las plantillas de políticas de Clarysec pertinentes, mapee sus diez primeras obligaciones esta semana y convierta el cumplimiento, de una carrera de última hora, en un sistema operativo.