Supervisión continua del cumplimiento para NIS2 y DORA

La pregunta del viernes por la tarde que todo CISO debe poder responder

A las 16:40 de un viernes, el CISO de una plataforma de pagos basada en la nube recibe tres mensajes en menos de diez minutos.

El primero es del director financiero: “Nuestro socio bancario quiere evidencias actualizadas de que cumplimos las expectativas de DORA en materia de riesgo de terceros de TIC y notificación de incidentes.”

El segundo es del asesor jurídico principal: “Nuestro servicio de seguridad gestionada podría situarnos dentro del alcance de la transposición nacional de NIS2. ¿Podemos demostrar la supervisión de la dirección y la eficacia de los controles?”

El tercero es del responsable de ingeniería: “Hemos aplicado el parche de la vulnerabilidad crítica, pero la cola de trabajo muestra 38 hallazgos medios vencidos. ¿Tenemos que escalarlo?”

Ese es el momento en que el cumplimiento anual deja de sostenerse.

Un PDF de política, un registro de riesgos actualizado por última vez antes de la auditoría anterior y una carpeta de capturas de pantalla no son suficientes para NIS2 y DORA. Estos regímenes esperan una gobernanza viva, supervisión de la dirección, flujos de trabajo de incidentes, visibilidad sobre proveedores, pruebas de resiliencia, acciones correctivas y eficacia de controles demostrable.

Para muchos CISO, la presión no es teórica. La transposición de NIS2 en los Estados miembros de la UE ha desplazado la ciberseguridad desde un programa técnico hacia una cuestión de responsabilidad proactiva de la dirección. DORA es aplicable desde el 17 de enero de 2025 y proporciona a las entidades financieras un marco sectorial de resiliencia operativa para el riesgo de TIC, la notificación de incidentes, las pruebas y el riesgo de terceros. Los proveedores de servicios en la nube, SaaS, servicios gestionados, seguridad gestionada, centros de datos, distribución de contenidos, servicios de confianza y comunicaciones electrónicas públicas también pueden afrontar obligaciones directas o indirectas según el alcance, el tamaño, el sector, la clasificación nacional y los contratos con clientes.

La pregunta práctica ya no es: “¿Tenemos un control?”

Es: “¿Quién es el propietario del control, qué métrica demuestra que funciona, con qué frecuencia recopilamos evidencias y qué ocurre cuando la métrica falla?”

Ese es el núcleo de la supervisión continua del cumplimiento para NIS2 y DORA. En las implantaciones de Clarysec, utilizamos ISO/IEC 27001:2022 como columna vertebral del sistema de gestión, ISO/IEC 27002:2022 como lenguaje de controles, Zenith Blueprint: hoja de ruta de 30 pasos para auditores como secuencia de implantación y Zenith Controls: la guía de cumplimiento transversal como brújula de cumplimiento transversal que conecta las evidencias de ISO/IEC 27001:2022 con NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 y las expectativas de auditoría.

Por qué NIS2 y DORA hacen insuficiente el cumplimiento periódico

NIS2 y DORA difieren en estructura jurídica, modelo de supervisión y alcance, pero generan la misma presión operativa. La ciberseguridad y la resiliencia de las TIC deben gobernarse de forma continua.

NIS2 exige que las entidades esenciales e importantes apliquen medidas técnicas, operativas y organizativas adecuadas y proporcionadas mediante un enfoque basado en todos los riesgos. Estas medidas incluyen análisis de riesgos, políticas de seguridad de los sistemas de información, gestión de incidentes, continuidad del negocio, gestión de crisis, seguridad de la cadena de suministro, adquisición y desarrollo seguros, gestión de vulnerabilidades, 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 multifactor cuando proceda. Los órganos de dirección deben aprobar las medidas de gestión del riesgo de ciberseguridad, supervisar su implantación y recibir formación.

DORA lo hace aún más explícito para las entidades financieras. Exige disposiciones internas de gobernanza y control para el riesgo de TIC, un marco documentado de gestión del riesgo de las TIC, responsabilidad del órgano de dirección, gestión y notificación de incidentes relacionados con las TIC, pruebas de resiliencia operativa digital, gestión del riesgo de terceros de TIC, seguimiento de auditorías, formación y mecanismos de comunicación. DORA también deja claro que las entidades financieras siguen siendo responsables del cumplimiento cuando utilizan proveedores terceros de servicios de TIC.

Esto crea una nueva realidad de cumplimiento. Un CISO no puede esperar hasta el mes de la auditoría para descubrir que:

• se omitieron revisiones de acceso privilegiado durante dos trimestres;
• los planes de salida de proveedores estaban documentados, pero nunca se probaron;
• los criterios de clasificación de severidad de incidentes no se corresponden con los umbrales regulatorios de notificación;
• las copias de seguridad están configuradas, pero faltan evidencias de restauración;
• la dirección nunca revisó los tratamientos de riesgos vencidos;
• los contratos de servicios en la nube carecen de derechos de auditoría, visibilidad sobre subcontratistas o cláusulas de notificación de incidentes.

El antiguo modelo basado en proyectos genera ciclos de pánico. Los equipos se movilizan antes de una auditoría, recopilan capturas de pantalla, actualizan fechas de políticas y esperan que las evidencias cuenten una historia coherente. NIS2 y DORA están diseñados para hacer fracasar ese enfoque. Se centran en la responsabilidad proactiva, la proporcionalidad, la resiliencia y las evidencias de funcionamiento.

ISO/IEC 27001:2022 proporciona el sistema operativo para resolver este problema. Sus cláusulas exigen que las organizaciones comprendan el contexto, las partes interesadas, los requisitos legales y contractuales, el alcance, el liderazgo, los roles, la evaluación de riesgos, el tratamiento de riesgos, la Declaración de Aplicabilidad, la planificación operacional, la evaluación del desempeño, la auditoría interna, la revisión por la dirección, la gestión de no conformidades y la mejora continua. Esta estructura es idónea para combinar NIS2, DORA, GDPR, aseguramiento de clientes y riesgo interno en un único modelo de supervisión continua.

El cumplimiento continuo no consiste en añadir más paneles. Consiste en una cadencia de evidencias gobernada.

Construir el motor de cumplimiento sobre ISO/IEC 27001:2022

Muchas organizaciones entienden erróneamente ISO/IEC 27001:2022 como un mero marco de certificación. En la práctica, es un sistema de gestión de riesgos para hacer que la gobernanza de la seguridad sea repetible, medible y auditable.

Esto importa porque NIS2 y DORA no son listas de verificación aisladas. Requieren un modelo operativo capaz de absorber requisitos legales, traducirlos en controles, asignar responsabilidad, supervisar el desempeño y mejorar cuando se detectan deficiencias.

Las cláusulas fundacionales de ISO/IEC 27001:2022 proporcionan ese modelo:

Para una FinTech, un proveedor SaaS, un servicio de seguridad gestionada o un proveedor de TIC de entidades financieras, esta estructura evita proyectos de cumplimiento duplicados. Un único SGSI puede mapear las obligaciones a controles una sola vez y reutilizar después las evidencias en NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019, certificación ISO/IEC 27001:2022 y revisiones de aseguramiento de clientes.

Empezar por la responsabilidad sobre los controles, no por las herramientas

El primer patrón de fallo en el cumplimiento continuo es implantar primero la herramienta. Una empresa compra una plataforma GRC, importa cientos de requisitos, asigna todo a “Seguridad” y lo denomina supervisión continua. Seis meses después, el panel está en rojo, ingeniería cuestiona las evidencias de vulnerabilidades, el área jurídica afirma que los documentos de proveedores están incompletos y la dirección no puede ver con claridad el riesgo residual.

ISO/IEC 27001:2022 evita esto al exigir que las responsabilidades y autoridades se asignen y comuniquen. NIS2 y DORA refuerzan la misma expectativa mediante responsabilidad de la dirección, roles definidos y supervisión.

La Política de funciones y responsabilidades de gobernanza - pyme de Clarysec establece:

Cada función con responsabilidad de seguridad debe registrarse en un registro central y acusarse recibo por escrito.

Esa cláusula es más importante que la mayoría de los paneles. Si las pruebas de copias de seguridad, la remediación de vulnerabilidades, la diligencia debida de proveedores, la clasificación de incidentes y la revisión de acceso privilegiado no tienen propietarios nominativos, no existe una cadencia de evidencias fiable.

La Política de Seguridad de la Información lo hace operativo para entornos corporativos:

Recopilar y conservar evidencias de auditoría para auditorías y revisiones de controles.

También exige a los propietarios de controles que:

Informen al responsable del SGSI sobre el desempeño del control y cualquier deficiencia o problema.

En Zenith Controls, este tema se mapea directamente con los controles ISO/IEC 27002:2022 5.2 Roles y responsabilidades de seguridad de la información, 5.35 Revisión independiente de la seguridad de la información y 5.36 Cumplimiento de políticas, normas y estándares de seguridad de la información.

Zenith Blueprint ofrece un punto de partida práctico en la fase de Fundamentos y liderazgo del SGSI, paso 4: Roles y responsabilidades en el SGSI. Recomienda nombramiento formal, actualización de descripciones de puesto, alineación con KPI, comunicación a toda la organización y responsabilidad por departamento.

Un registro de nombramiento típico puede indicar:

“Con efecto inmediato, queda nombrado responsable de seguridad de la información, con responsabilidad de supervisar y coordinar el SGSI, incluida la gestión de riesgos, la implantación de controles y la supervisión del cumplimiento.”

Ese nombramiento no es burocracia. Es evidencia de auditoría para el liderazgo y la asignación de roles en ISO/IEC 27001:2022. También respalda la supervisión de la dirección conforme a NIS2 y la gobernanza de DORA. Reguladores, auditores de certificación y clientes bancarios quieren comprobar que la responsabilidad no está implícita. Está asignada, reconocida, dotada de recursos y supervisada.

Un registro práctico de responsabilidad sobre los controles debe incluir estos campos:

Este registro se convierte en el puente entre la política y la prueba.

Definir KPI y KRI que demuestren la eficacia de los controles

Una vez que existen propietarios, estos necesitan saber qué significa “correcto”. La supervisión continua del cumplimiento funciona con indicadores significativos, no con intenciones generales.

“Mejorar la aplicación de parches” no es un KPI. “Revisar proveedores periódicamente” no es evidencia. “Mantener la resiliencia” no es un control medible.

Clarysec separa claramente los dos tipos de indicadores:

• KPI, indicador clave de rendimiento, mide si el proceso funciona según lo esperado.
• KRI, indicador clave de riesgo, señala el aumento del riesgo o el incumplimiento de un umbral que requiere escalado.

La Política de gestión de riesgos corporativa establece:

Los KRI (indicadores clave de riesgo) y las métricas de seguridad deberán definirse para los riesgos críticos y supervisarse mensualmente.

También exige lógica de escalado:

Los desencadenantes de escalado deberán incorporarse a la lógica de supervisión (por ejemplo, cuando el riesgo residual aumente más de un nivel o se incumplan los plazos de tratamiento).

Para organizaciones más pequeñas, la Política de gestión de riesgos - pyme de Clarysec adopta un enfoque proporcionado:

El avance en la mitigación del riesgo debe revisarse trimestralmente.

También permite métricas ligeras:

Pueden supervisarse métricas informales (por ejemplo, número de riesgos abiertos, acciones vencidas, nuevos incidentes).

Esa proporcionalidad importa. Un banco multinacional y un proveedor FinTech de 60 personas no necesitan la misma telemetría, pero ambos necesitan responsabilidad asignada, medición repetible, umbrales de escalado y evidencias de acciones correctivas.

Un modelo práctico de KPI y KRI para NIS2 y DORA tiene este aspecto:

Estas métricas respaldan más que la certificación ISO/IEC 27001:2022. También apoyan las medidas de gestión del riesgo de ciberseguridad de NIS2, la preparación para la notificación de incidentes NIS2, la gestión del riesgo de las TIC de DORA, el riesgo de terceros de DORA, la responsabilidad proactiva de GDPR, los resultados de gobernanza de NIST CSF 2.0 y la gestión del desempeño al estilo COBIT.

Establecer una cadencia de evidencias antes de que la auditoría la solicite

Muchas organizaciones recopilan evidencias de forma aleatoria. Una captura de pantalla aparece en un canal de Teams. Un ticket de Jira se enlaza en un correo electrónico. Un cuestionario de proveedor se almacena en compras. Una prueba de copia de seguridad se describe verbalmente. Durante la semana de auditoría, el responsable del SGSI se convierte en investigador forense.

El cumplimiento continuo requiere una cadencia planificada y una higiene de evidencias limpia.

La Política de Auditoría y Supervisión del Cumplimiento - pyme de Clarysec establece:

Cada auditoría debe incluir un alcance definido, objetivos, personal responsable y evidencias requeridas.

También indica:

Las evidencias deben conservarse durante al menos dos años, o más tiempo cuando lo exijan la certificación o los acuerdos con clientes.

Para organizaciones corporativas, la Política de Auditoría y Supervisión del Cumplimiento añade expectativas de automatización:

Deberán desplegarse herramientas automatizadas para supervisar el cumplimiento de configuraciones, la gestión de vulnerabilidades, el estado de parches y el acceso privilegiado.

La automatización debe ser selectiva. Los controles de alto riesgo y alta frecuencia no deben depender de capturas de pantalla manuales. El mejor modelo de evidencias combina telemetría automatizada, atestaciones de propietarios, registros de excepciones, registros de tickets, resultados de pruebas y actas de revisión por la dirección.

La convención de nomenclatura también importa. Las evidencias deben poder recuperarse sin esfuerzos extraordinarios. Por ejemplo:

• informe semanal de vulnerabilidades: YYYY-MM-DD_Vulnerability-SLA_ControlOwner
• revisión mensual de acceso privilegiado: YYYY-MM_IAM-Privileged-Review_Attestation
• revisión trimestral de proveedores: YYYY-QX_Critical-Supplier-Review
• paquete de incidente: INC-YYYY-###_Timeline-Classification-RCA-CAPA

Aquí es donde la política se vuelve operativa. La conservación de evidencias no es una tarea de archivo. Forma parte del control.

Mapear un único elemento de evidencia con muchas obligaciones

El cumplimiento continuo adquiere fuerza cuando un único elemento de evidencia satisface múltiples marcos. Por eso Zenith Controls es central en el enfoque de cumplimiento transversal de Clarysec.

Considere la gestión de incidentes. Conforme a NIS2, los incidentes significativos requieren notificación por etapas, incluida una alerta temprana dentro de las 24 horas desde que se tenga conocimiento, notificación dentro de las 72 horas e informe final dentro de un mes, sujeto a la transposición nacional y a los hechos del incidente. DORA exige a las entidades financieras gestionar, clasificar, escalar y notificar incidentes graves relacionados con las TIC mediante procesos y plantillas exigidos. GDPR exige a los responsables del tratamiento evaluar y gestionar brechas de seguridad de los datos personales cuando se vea afectada la confidencialidad, integridad o disponibilidad de datos personales.

Un único paquete de evidencias de incidente puede respaldar los tres si incluye:

• cronología del incidente y hora de toma de conocimiento;
• justificación de la clasificación;
• servicios y jurisdicciones afectados;
• impacto en clientes, transacciones o usuarios;
• evaluación de impacto sobre datos personales;
• análisis de causa raíz;
• acciones de mitigación y recuperación;
• comunicaciones y notificaciones;
• registro de escalado a la dirección;
• entrada de acción correctiva.

La misma lógica de cumplimiento transversal se aplica al riesgo de proveedores. NIS2 exige seguridad de la cadena de suministro y atención a las relaciones directas con proveedores y proveedores de servicios. DORA exige estrategia de riesgo de terceros de TIC, registros, diligencia debida precontractual, cláusulas contractuales, derechos de auditoría, niveles de servicio, estrategias de salida y supervisión del riesgo de concentración. NIST CSF 2.0 trata el riesgo de la cadena de suministro como una disciplina de gobernanza del ciclo de vida. ISO/IEC 27001:2022 integra estos requisitos en el alcance, los requisitos de las partes interesadas, el tratamiento de riesgos y el control operacional de procesos prestados externamente.

Una matriz práctica de evidencias ayuda a los propietarios de controles a comprender por qué importan las evidencias:

Este enfoque evita trabajo de cumplimiento duplicado. La organización recopila un conjunto sólido de evidencias y lo mapea después con múltiples obligaciones.

El modelo de supervisión de Clarysec, de la obligación al propietario y a la evidencia

Un modelo de supervisión robusto sigue una secuencia simple.

Primero, definir la obligación. Por ejemplo, DORA exige gestionar el riesgo de terceros de TIC como parte de la gestión del riesgo de las TIC, con registros, diligencia debida, requisitos contractuales, derechos de auditoría y estrategias de salida para funciones críticas o importantes. NIS2 exige seguridad de la cadena de suministro y acciones correctivas adecuadas.

Segundo, traducir la obligación en requisitos del SGSI ISO/IEC 27001:2022. Esto incluye requisitos de partes interesadas, alcance, evaluación de riesgos, tratamiento de riesgos, Declaración de Aplicabilidad, control operacional, supervisión, auditoría interna, revisión por la dirección y mejora.

Tercero, seleccionar controles operativos. En Zenith Controls, los controles básicos de gobernanza para el cumplimiento continuo incluyen los controles ISO/IEC 27002:2022 5.2, 5.35 y 5.36. Los controles de apoyo suelen incluir 5.19 Seguridad de la información en las relaciones con proveedores, 5.21 Gestión de la seguridad de la información en la cadena de suministro de TIC, 5.22 Supervisión, revisión y gestión de cambios de los servicios de proveedores, 5.23 Seguridad de la información para el uso de servicios en la nube, 5.24 Planificación y preparación de la gestión de incidentes de seguridad de la información, 5.26 Respuesta a incidentes de seguridad de la información, 5.30 Preparación de las TIC para la continuidad del negocio, 5.31 Requisitos legales, estatutarios, regulatorios y contractuales, 8.8 Gestión de vulnerabilidades técnicas, 8.13 Copia de seguridad de la información, 8.15 Registro de eventos, 8.16 Actividades de supervisión y 8.9 Gestión de configuraciones.

Cuarto, asignar el propietario y la cadencia. El riesgo de proveedores puede implicar a compras, legal, seguridad y al propietario del servicio de negocio, pero un único propietario responsable debe mantener el registro e informar las excepciones.

Quinto, definir KPI, KRI y evidencias. Los KPI de proveedores pueden incluir el porcentaje de proveedores críticos de TIC con diligencia debida completada, el porcentaje con cláusulas contractuales aprobadas, el número sin planes de salida probados y el número de revisiones de proveedores vencidas. Los KRI pueden incluir hallazgos de alto riesgo de proveedores no resueltos, riesgo de concentración por encima de la tolerancia o ausencia de derechos de auditoría para un servicio que soporta una función crítica o importante.

Sexto, informar y escalar. Los paneles mensuales del SGSI no deben limitarse a mostrar estados en verde. Deben identificar evidencias vencidas, movimiento del riesgo, plazos de tratamiento incumplidos y decisiones de dirección requeridas.

Séptimo, auditar y mejorar. Las deficiencias de evidencias se convierten en acciones correctivas, no en excusas.

Esto se alinea con la fase de Auditoría, revisión y mejora de Zenith Blueprint. El paso 25, Programa de auditoría interna, recomienda cubrir procesos y controles relevantes del SGSI durante el ciclo de auditoría, con una auditoría anual de alcance completo y comprobaciones aleatorias trimestrales más pequeñas para áreas de alto riesgo cuando proceda. El paso 28, Revisión por la dirección, exige entradas como cambios en los requisitos, resultados de seguimiento y medición, resultados de auditoría, incidentes, no conformidades, oportunidades de mejora y necesidades de recursos. El paso 29, Mejora continua, utiliza el registro CAPA para capturar la descripción del problema, la causa raíz, la acción correctiva, el propietario responsable, la fecha objetivo y el estado.

Eso es el cumplimiento continuo en la práctica.

Un escenario práctico: vulnerabilidad crítica en una API pública

A las 02:15, se dispara una alerta SIEM. Un escaneo de vulnerabilidades ha identificado una vulnerabilidad crítica de ejecución remota de código en una pasarela de interfaces de programación de aplicaciones expuesta públicamente que soporta un servicio de pagos regulado.

El modelo de supervisión continua debe responder sin esperar a una reunión.

Primero, el inventario de activos clasifica la pasarela como crítica. Se inicia el contador del KPI de gestión de vulnerabilidades. Se incrementa el KRI de vulnerabilidades críticas sin parchear. Si el activo está expuesto a internet y el exploit está activo, se activa inmediatamente el umbral de escalado.

Segundo, el ticket se enruta al equipo DevOps de guardia. El responsable de DevOps, como propietario del control de gestión de vulnerabilidades, recibe una notificación automatizada. El responsable del SOC supervisa si existen indicadores de explotación. El responsable del SGSI supervisa si se cumplen los criterios de incidente.

Tercero, las evidencias se recopilan como subproducto del flujo de trabajo. La alerta SIEM, el escaneo de vulnerabilidades, la clasificación del activo, las marcas temporales del ticket, el chat de respuesta, el registro del parche, el escaneo de validación y la aprobación de cierre se adjuntan al paquete de evidencias.

Cuarto, el equipo evalúa si el evento es solo una vulnerabilidad, un evento de seguridad o un incidente. Si existe impacto en el servicio, indicadores de compromiso, impacto en clientes o exposición de datos personales, el flujo de trabajo de incidentes activa las evaluaciones de notificación de NIS2, DORA, GDPR y contractuales.

Quinto, la dirección recibe un informe conciso. Si la vulnerabilidad fue remediada dentro de cuatro horas, la evidencia respalda la eficacia del control. Si incumplió el SLA, el registro CAPA documenta la causa raíz, la acción correctiva, el propietario, la fecha objetivo y el estado.

Este único evento genera evidencias útiles para gestión de vulnerabilidades, preparación ante incidentes, supervisión, acceso a activos críticos, revisión por la dirección y mejora continua.

Cómo auditores y reguladores probarán el mismo modelo de supervisión

Un programa maduro de cumplimiento continuo debe resistir distintas perspectivas de auditoría. Las evidencias no cambian, pero las preguntas sí.

Para el control ISO/IEC 27002:2022 5.35 Revisión independiente de la seguridad de la información, un auditor ISO/IEC 27001:2022 se centrará en el plan de auditoría interna, el alcance, la competencia, los hallazgos y las acciones correctivas. Un regulador NIS2 o DORA se centrará en si la dirección comprendió los hallazgos, financió la remediación y redujo el riesgo sistémico. Un evaluador NIST CSF 2.0 puede mapear la revisión con la función GOVERN, incluida la supervisión y el ajuste del desempeño.

El mismo conjunto de evidencias sirve a todos ellos si está completo, actualizado y conectado con la propiedad.

Errores comunes que debilitan el cumplimiento continuo

El primer error es tratar NIS2 y DORA como proyectos separados. Eso crea registros duplicados, métricas contradictorias y propietarios de controles agotados. Utilice ISO/IEC 27001:2022 como columna vertebral del SGSI y mapee las obligaciones mediante una única biblioteca de controles.

El segundo error es asignar controles a equipos en lugar de a personas. “TI es propietario de las copias de seguridad” no es suficiente. Un propietario nominativo debe atestar, informar excepciones y escalar riesgos.

El tercer error es recopilar evidencias sin evaluar la eficacia. Una captura de pantalla de copia de seguridad correcta no demuestra la capacidad de recuperación. Una prueba de restauración sí. Un cuestionario de proveedor no demuestra la resiliencia de terceros. Las cláusulas contractuales, los derechos de auditoría, las condiciones de notificación de incidentes, los informes de desempeño y la planificación de salida generan evidencias más sólidas.

El cuarto error es medir actividad en lugar de riesgo. Contar vulnerabilidades es útil. Supervisar vulnerabilidades críticas vencidas en sistemas expuestos a internet es mejor. Contar proveedores es útil. Supervisar proveedores críticos sin planes de salida es mejor.

El quinto error es una disciplina débil de acciones correctivas. El paso 29 de Zenith Blueprint deja claro que los hallazgos necesitan descripción del problema, causa raíz, acción correctiva, propietario responsable, fecha objetivo y estado. Si el registro CAPA no se revisa, el cumplimiento continuo se convierte en acumulación continua de debilidades conocidas.

Qué debería ver la dirección cada mes

Los órganos de dirección bajo NIS2 y DORA no necesitan exportaciones brutas de escáneres. Necesitan una visión del riesgo cibernético y de TIC con calidad suficiente para decidir.

Un panel mensual para el consejo o la dirección debe incluir:

• principales riesgos cibernéticos y de TIC con evolución del riesgo residual;
• tratamientos de riesgos vencidos y plazos incumplidos;
• incidentes significativos, posibles incidentes graves relacionados con las TIC y lecciones aprendidas;
• excepciones de riesgo de proveedores críticos;
• desempeño de SLA de vulnerabilidades para activos críticos;
• estado de pruebas de copia de seguridad y recuperación;
• excepciones de revisión de acceso privilegiado;
• tasa de finalización de evidencias de cumplimiento;
• hallazgos de auditoría y estado CAPA;
• decisiones de recursos requeridas.

Esto apoya directamente la revisión por la dirección de ISO/IEC 27001:2022 y las expectativas de gobernanza de NIS2 y DORA. También se alinea con NIST CSF 2.0, donde la alta dirección establece prioridades, responsabilidad proactiva, recursos y apetito de riesgo, mientras que los responsables traducen esas prioridades en perfiles objetivo y planes de acción.

Construya esta semana su ritmo de evidencias para NIS2 y DORA

No necesita abarcarlo todo desde el primer día. Una primera semana útil puede ser sencilla.

Día 1, cree un registro de propietarios de controles para cinco dominios: gobernanza y gestión de riesgos, gestión y notificación de incidentes, gestión de vulnerabilidades y parches, riesgo de proveedores y servicios en la nube, y continuidad del negocio y recuperación.

Día 2, defina un KPI y un KRI para cada dominio. Manténgalos específicos, medibles y vinculados al apetito de riesgo.

Día 3, mapee cada elemento de evidencia con NIS2, DORA, ISO/IEC 27001:2022, GDPR y el valor de aseguramiento para clientes.

Día 4, establezca la cadencia de evidencias, ubicación de almacenamiento, convención de nomenclatura, regla de conservación y revisor.

Día 5, ejecute un escalado mediante un ejercicio de mesa. Utilice un escenario de indisponibilidad de servicios en la nube o de vulnerabilidad crítica. Confirme la clasificación, la evaluación de notificación regulatoria, la comunicación a clientes, el almacenamiento de evidencias y la creación de CAPA.

Si su organización todavía gestiona NIS2 y DORA mediante hojas de cálculo, talleres anuales y carpetas de evidencias dispersas, ahora es el momento de pasar a un ritmo operativo supervisado.

Empiece con tres acciones:

1. Construya un registro de propietarios de controles para sus dominios de mayor riesgo.
2. Defina un KPI, un KRI, un elemento de evidencia y una cadencia por control.
3. Realice una revisión de evidencias de 30 minutos y abra elementos CAPA para cualquier ausencia.

Clarysec puede ayudarle a acelerar el cambio con Zenith Blueprint para la secuenciación de la implantación, Zenith Controls para el mapeo de cumplimiento transversal y la biblioteca de políticas de Clarysec, incluidas la Política de Seguridad de la Información, la Política de gestión de riesgos, la Política de Auditoría y Supervisión del Cumplimiento, Política de funciones y responsabilidades de gobernanza - pyme, Política de gestión de riesgos - pyme y Política de Auditoría y Supervisión del Cumplimiento - pyme.

El objetivo no es más documentación de cumplimiento. El objetivo es responder a la pregunta del viernes por la tarde con confianza:

“Sí, sabemos quién es el propietario del control, conocemos el KPI, tenemos las evidencias, conocemos las excepciones y la dirección ha revisado el riesgo.”

Contacte con Clarysec para construir un modelo de supervisión continua del cumplimiento preparado para auditorías, listo para el consejo y lo bastante resiliente para NIS2, DORA y la próxima regulación que venga.