Preparación para el Reglamento de Cibersolidaridad de la UE con ISO 27001

El incidente de las 03:17 que convierte la cooperación de la UE en un problema de auditoría

A las 03:17 de un martes por la mañana, María, CISO de InnovateCloud, mira fijamente una pantalla llena de alertas. Su empresa es un proveedor europeo de SaaS de tamaño medio que presta servicio a clientes logísticos en Alemania, Francia y Polonia. La primera alerta parece un acceso privilegiado sospechoso en un entorno de producción. Diez minutos después, el proveedor de servicios gestionados de seguridad informa de actividad similar que afecta a otros dos clientes. A las 04:00, el SOC observa llamadas a API desde infraestructura asociada previamente con fases de preparación de ransomware.

InnovateCloud no era el objetivo original. Un proveedor de infraestructura esencial parece estar dentro del radio de impacto. Sin embargo, el impacto ahora es problema de María.

Uno de los clientes afectados es un banco alemán que exige respuestas conforme a DORA. Otro es un proveedor crítico del sector energético ya clasificado conforme a normas nacionales NIS2. El entorno puede contener datos personales, pero la exfiltración de datos aún no está confirmada. El equipo de seguridad quiere contener la amenaza de inmediato. El área jurídica quiere saber si ha empezado a correr el plazo de 24 horas para la alerta temprana NIS2. La responsable de privacidad pregunta si podría ser necesaria una notificación de brecha conforme al RGPD de la UE. El consejo de administración quiere saber si la indisponibilidad podría extenderse a varios Estados miembros.

En 2026, esto ya no es solo una crisis interna.

El Reglamento de Cibersolidaridad de la UE cambia la realidad operativa de los incidentes cibernéticos a gran escala y transfronterizos. Introduce mecanismos de detección, preparación y respuesta a escala de la UE, incluidos el Sistema Europeo de Alerta de Ciberseguridad, el Mecanismo de Emergencia de Ciberseguridad y la Reserva de Ciberseguridad de la UE. Aunque una organización nunca solicite ayuda directamente a la reserva, sus evidencias, contactos con autoridades, contratos con proveedores, cronologías de incidentes y comunicaciones con clientes pueden pasar a formar parte de una cadena de respuesta europea más amplia.

La brecha aparece rápidamente. Muchas organizaciones disponen de herramientas, tickets y políticas, pero no de evidencias que resistan el escrutinio regulatorio. Pueden afirmar «contactamos con el regulador», pero no demostrar quién estaba autorizado, qué umbral activó el contacto, qué se comunicó, si los registros se preservaron, si un proveedor estaba obligado contractualmente a prestar apoyo o si un informe final puede reconstruirse a partir de decisiones contemporáneas.

La respuesta no es otro «expediente del Reglamento de Cibersolidaridad» aislado. La respuesta es un Sistema de Gestión de la Seguridad de la Información conforme a ISO/IEC 27001:2022 que produzca evidencias una sola vez y las reutilice frente a las expectativas de NIS2, DORA, RGPD de la UE, NIST CSF 2.0 y COBIT 2019.

Esa evidencia empieza antes del incidente.

Por qué el Reglamento de Cibersolidaridad de la UE eleva el estándar de evidencia

El Reglamento de Cibersolidaridad está diseñado para la detección, la preparación y la respuesta ante crisis cibernéticas a escala de la UE. Su efecto práctico para CISO, auditores y responsables de cumplimiento es claro: la coordinación de incidentes a gran escala exige evidencias más rápidas, más limpias, más coherentes y más fáciles de compartir con partes interesadas de confianza.

Cuando es posible un impacto transfronterizo, una organización puede tener que coordinarse con CSIRT nacionales, autoridades competentes, reguladores sectoriales, autoridades de protección de datos, supervisores financieros, fuerzas y cuerpos de seguridad, clientes, encargados del tratamiento, proveedores y equipos externos de respuesta a incidentes. La Reserva de Ciberseguridad de la UE añade otra dimensión, porque proveedores privados previamente evaluados pueden apoyar la preparación, la respuesta y la recuperación. Esto hace aún más importantes la gobernanza de proveedores, la autoridad legal, el tratamiento de datos y la preservación de evidencias.

Las entidades privadas se sitúan en el centro de esta realidad. Los proveedores de nube, centros de datos, proveedores de servicios gestionados, proveedores de servicios gestionados de seguridad, operadores de infraestructura digital, fintechs y plataformas SaaS suelen conservar la telemetría, los registros, los datos de impacto en clientes y los hechos técnicos que las autoridades necesitan para comprender un incidente grave.

NIS2 ya apunta en esta dirección. Se aplica a muchas entidades medianas y grandes de los sectores del anexo I y el anexo II que prestan servicios o realizan actividades en la UE. También alcanza a determinadas entidades con independencia de su tamaño, incluidos los prestadores de servicios de confianza, proveedores de servicios DNS, registros de dominios de primer nivel y prestadores de servicios de registro de nombres de dominio. El anexo I incluye infraestructura digital, como servicios de computación en la nube, servicios de centros de datos, redes de distribución de contenidos, proveedores DNS, prestadores de servicios de confianza y registros TLD. También incluye la gestión de servicios TIC B2B, incluidos proveedores de servicios gestionados y proveedores de servicios gestionados de seguridad. El anexo II incluye proveedores digitales, como mercados en línea, motores de búsqueda en línea y plataformas de servicios de redes sociales.

DORA añade una segunda capa para el sector financiero. Desde el 17 de enero de 2025, se aplica a una amplia gama de entidades financieras, incluidas entidades de crédito, entidades de pago, entidades de dinero electrónico, empresas de servicios de inversión, proveedores de servicios de criptoactivos, centros de negociación, empresas de seguros y reaseguros, agencias de calificación crediticia, proveedores de servicios de financiación participativa y otros. También crea expectativas significativas para los proveedores terceros de servicios TIC, porque las entidades financieras siguen siendo responsables de los servicios TIC externalizados.

Por tanto, un incidente fintech en 2026 puede coordinarse a través de canales de supervisión DORA, mientras que el proveedor SaaS o el MSSP que da soporte a esa fintech puede estar sujeto a NIS2. El mismo evento técnico puede generar deberes de notificación, expectativas de evidencia y obligaciones contractuales diferentes para distintos actores.

ISO/IEC 27001:2022 proporciona a las organizaciones el sistema operativo para gestionar esta complejidad. Las cláusulas 4.1 a 4.4 exigen que la organización defina el SGSI en su contexto de negocio, identifique a las partes interesadas y sus requisitos legales, regulatorios y contractuales, defina límites y dependencias, y establezca el sistema de gestión. Las cláusulas 5.1 a 5.3 hacen que la alta dirección asuma la responsabilidad de la política, los recursos, la integración y la asignación de roles. Las cláusulas 6.1.1 a 6.1.3 exigen una evaluación de riesgos repetible, tratamiento de riesgos y una Declaración de Aplicabilidad. La cláusula 8.1 exige control operacional, incluido el control de procesos, productos y servicios suministrados externamente.

Este es el núcleo de la preparación frente al Reglamento de Cibersolidaridad: demostrar que la respuesta ante crisis se gestiona, se prueba y es auditable, no improvisada.

El modelo de evidencias de Clarysec: un incidente, muchas obligaciones

Un incidente transfronterizo no espera a que los equipos jurídicos lo clasifiquen. Las evidencias deben capturarse desde la primera alerta y después canalizarse hacia las rutas adecuadas de notificación y coordinación.

El enfoque de Clarysec conecta tres activos:

1. Zenith Blueprint: hoja de ruta de 30 pasos para auditores Zenith Blueprint, que convierte la implantación de ISO/IEC 27001:2022 en un recorrido secuenciado y preparado para auditorías.
2. Zenith Controls: guía de cumplimiento cruzado Zenith Controls, que mapea los controles de ISO/IEC 27002:2022 con controles relacionados, atributos, capacidades operativas, dominios de seguridad y expectativas de evidencias entre marcos.
3. Plantillas de políticas de Clarysec para respuesta a incidentes, recopilación de evidencias, seguridad de proveedores, registro de eventos, supervisión y continuidad del negocio, adaptadas a entornos empresariales y de pymes.

En Zenith Blueprint, fase Controles en acción, el paso 22 aborda el control 5.5 de ISO/IEC 27002:2022, Contacto con autoridades. Indica:

El control 5.5 garantiza que una organización esté preparada para interactuar con autoridades externas cuando sea necesario, no de forma reactiva ni bajo presión, sino mediante canales predefinidos, estructurados y bien comprendidos.

La misma sección plantea la pregunta que todo CISO debe responder antes de la crisis:

si su organización fuera objetivo de un ciberataque, estuviera implicada en una brecha de seguridad de los datos o fuera objeto de investigación, ¿quién llamaría a las autoridades? ¿Cómo sabría qué decir? ¿En qué condiciones se iniciaría ese contacto?

Eso no es papeleo administrativo. En un entorno del Reglamento de Cibersolidaridad, es la diferencia entre una alerta temprana ordenada y mensajes contradictorios entre jurisdicciones.

Zenith Controls trata el control 5.5 de ISO/IEC 27002:2022, Contacto con autoridades, como preventivo y correctivo, conectado con confidencialidad, integridad y disponibilidad, y alineado con los conceptos de Identificar, Proteger, Responder y Recuperar. Vincula 5.5 con la planificación y preparación de la gestión de incidentes, la notificación de eventos, la inteligencia de amenazas, grupos de interés especial y la respuesta a incidentes.

La misma guía trata el control 5.24 de ISO/IEC 27002:2022, planificación y preparación de la gestión de incidentes de seguridad de la información, como un control correctivo conectado con Responder y Recuperar. Sus vínculos con la evaluación de eventos, la respuesta a incidentes, las lecciones aprendidas, el registro de eventos, la supervisión, la seguridad durante interrupciones y la continuidad muestran lo que los auditores suelen probar: si el plan conecta detección, clasificación, escalado, evidencias, recuperación y aprendizaje.

Para el tratamiento de evidencias, el control 5.28 de ISO/IEC 27002:2022, Recopilación de evidencias, es especialmente importante. Zenith Controls lo conecta con respuesta a incidentes, registro de eventos, supervisión y notificación de eventos. En un incidente transfronterizo grave, aquí es donde la investigación técnica se vuelve defendible.

Mapeo de la preparación frente al Reglamento de Cibersolidaridad con evidencias ISO 27001

El Reglamento de Cibersolidaridad de la UE crea un entorno de preparación y coordinación. ISO/IEC 27001:2022 proporciona el motor de evidencias. NIS2, DORA y RGPD de la UE definen muchas expectativas específicas de notificación, gobernanza y protección.

Observe lo que no aparece: un silo de cumplimiento separado. Las mismas evidencias que respaldan la certificación ISO/IEC 27001:2022 pueden respaldar la responsabilidad de la dirección en NIS2, la gestión del riesgo TIC en DORA, la responsabilidad proactiva de seguridad del RGPD de la UE, los resultados de comunicación de NIST CSF y las expectativas de aseguramiento de COBIT 2019.

NIS2: el reloj de notificación empieza cuando comienza la toma de conocimiento

NIS2 es central para la preparación de 2026 porque define un flujo de trabajo de notificación de incidentes por fases.

El artículo 23 exige que las entidades esenciales e importantes notifiquen a su CSIRT o autoridad competente, sin dilación indebida, los incidentes significativos que afecten a la prestación de servicios. La alerta temprana debe presentarse sin dilación indebida y, en todo caso, en un plazo máximo de 24 horas desde que se tenga conocimiento del incidente significativo. Debe indicar, cuando proceda, si se sospecha de actos maliciosos o ilícitos y si es posible un impacto transfronterizo.

A continuación, debe presentarse una notificación del incidente sin dilación indebida y, en todo caso, en un plazo máximo de 72 horas desde la toma de conocimiento, actualizando la alerta temprana y proporcionando una evaluación inicial de la gravedad, el impacto y los indicadores de compromiso disponibles. El informe final debe presentarse en el plazo de un mes desde la notificación del incidente, con la gravedad, el impacto, el tipo probable de amenaza o la causa raíz, las medidas de mitigación y el impacto transfronterizo.

Por eso la respuesta a incidentes no puede empezar con un documento en blanco.

La Política de Respuesta a Incidentes empresarial Política de Respuesta a Incidentes establece:

NIS2 artículo 23 (notificación en las 24 horas siguientes a la toma de conocimiento del incidente)

La Política de Respuesta a Incidentes - pyme Política de Respuesta a Incidentes - pyme traslada la misma lógica temporal a una gobernanza práctica:

«Los plazos de respuesta, incluida la recuperación de datos y las obligaciones de notificación, deben documentarse y alinearse con los requisitos legales, como el requisito del RGPD de la UE de notificar las brechas de datos personales en un plazo de 72 horas.»

De Política de Respuesta a Incidentes - pyme, sección «Requisitos de gobernanza», cláusula 5.3.2.

También incorpora la evaluación multirrégimen al proceso de incidentes:

«Cuando estén implicados datos de clientes, el Director General debe evaluar las obligaciones legales de notificación en función de la aplicabilidad del RGPD de la UE, NIS2 o DORA.»

De Política de Respuesta a Incidentes - pyme, sección «Tratamiento de riesgos y excepciones», cláusula 7.4.1.

En un escenario del Reglamento de Cibersolidaridad, «es posible un impacto transfronterizo» adquiere importancia operativa. La alerta temprana puede no contener todos los hechos, pero la organización debe poder demostrar por qué sospechó o no sospechó un impacto transfronterizo con base en las evidencias disponibles.

El registro de incidentes debe capturar:

• Cuándo la organización tomó conocimiento.
• Quién declaró el evento como incidente potencial.
• Qué servicios, países, clientes o sectores pudieron verse afectados.
• Si se sospechaba actividad maliciosa o ilícita.
• Qué indicadores de compromiso estaban disponibles.
• Qué ruta de contacto con autoridades se utilizó.
• Si se requerían comunicaciones a clientes.
• Qué evidencias se preservaron antes de la remediación mayor.

El mejor momento para diseñar estos campos es antes de las 03:17.

DORA: cuando el cliente está regulado pero el proveedor conserva los registros

DORA cambia la conversación con los proveedores. Las entidades financieras deben gestionar el riesgo de terceros TIC como parte de su marco de gestión del riesgo TIC. Externalizar servicios TIC no transfiere la responsabilidad regulatoria fuera de la entidad financiera.

DORA exige estrategias de riesgo de terceros TIC, registros de contratos de servicios TIC, diligencia debida, planificación de auditorías e inspecciones, derechos de terminación y estrategias de salida probadas para servicios TIC críticos o importantes. El artículo 30 exige claridad contractual, incluidas descripciones de servicios, ubicaciones, tratamiento de datos, confidencialidad, integridad, disponibilidad, niveles de servicio, asistencia durante incidentes TIC, cooperación con autoridades y derechos de terminación. Para funciones críticas o importantes se aplican términos más estrictos.

Volvamos al incidente de María. El banco alemán está regulado por DORA. InnovateCloud presta servicios SaaS. El MSSP detecta actividad sospechosa. El proveedor de infraestructura en la nube conserva algunos de los registros de auditoría clave. Un subcontratista opera parte de la canalización de telemetría. El banco sigue siendo responsable, pero no puede clasificar y notificar correctamente sin evidencias de proveedores.

Clarysec aborda esto mediante clasificación de proveedores y evidencias contractuales. La Política de seguridad de terceros y proveedores empresarial Política de seguridad de terceros y proveedores exige:

Los contratos con proveedores deben incluir:

La Política de seguridad de terceros y proveedores - pyme Política de seguridad de terceros y proveedores - pyme utiliza la misma lógica de cumplimiento en un modelo operativo más ligero:

Los contratos deben incluir cláusulas obligatorias que cubran:

El valor está en el anexo que sigue a esas palabras: deberes de notificación de incidentes, acceso a registros, derechos de auditoría, confidencialidad, ubicación de datos, controles de subcontratistas, cooperación con autoridades, apoyo a la recuperación y obligaciones de salida.

Zenith Blueprint, fase Controles en acción, paso 23, proporciona la ruta de implantación:

Compile una lista completa de proveedores y prestadores de servicios actuales (5.19), y clasifíquelos en función del acceso a sistemas, datos o control operacional. Para cada proveedor clasificado, verifique que las expectativas de seguridad estén claramente incorporadas en los contratos (5.20), incluidas confidencialidad, acceso, notificación de incidentes y obligaciones de cumplimiento.

Continúa con el riesgo aguas abajo:

Para cada proveedor crítico, identifique si utiliza subcontratistas (subencargados) que puedan acceder a sus datos o sistemas. Documente cómo sus requisitos de seguridad de la información se trasladan a estas partes, ya sea mediante las condiciones contractuales de su proveedor o mediante sus propias cláusulas directas.

Esto también es preparación para la Reserva de Ciberseguridad. Si un proveedor externo de respuesta entra en su entorno durante una emergencia, debe conocer la base jurídica, el alcance del acceso, las reglas de evidencias, las obligaciones de tratamiento de datos, la ruta de coordinación con autoridades y las condiciones de salida. DORA lo hace explícito para las entidades financieras. NIS2 lo hace relevante para entidades esenciales e importantes. ISO/IEC 27001:2022 lo hace auditable.

RGPD de la UE: la pregunta sobre la brecha dentro de la crisis cibernética

No todo incidente de ciberseguridad es una brecha de datos personales, pero todo incidente grave debe evaluarse considerando esa posibilidad.

El RGPD de la UE se aplica al tratamiento en el contexto de un establecimiento en la UE, y también a responsables del tratamiento o encargados del tratamiento no establecidos en la UE que ofrezcan bienes o servicios a personas en la UE o supervisen su comportamiento en la UE. Define datos personales, tratamiento, responsable del tratamiento, encargado del tratamiento y brecha de datos personales. Sus principios incluyen integridad, confidencialidad y responsabilidad proactiva, lo que significa que los responsables del tratamiento deben poder demostrar el cumplimiento.

Durante el incidente de las 03:17, el equipo de María debe preguntarse:

• ¿Se accedió a datos personales, se divulgaron, alteraron, perdieron o destruyeron?
• ¿InnovateCloud actúa como responsable del tratamiento, encargado del tratamiento o ambos respecto de los datos afectados?
• ¿Están implicadas categorías especiales de datos personales?
• ¿Qué clientes o personas están afectados?
• ¿Son suficientes los registros para evaluar el alcance?
• ¿Las obligaciones de notificación del RGPD de la UE se ejecutan en paralelo con las obligaciones NIS2 o DORA?

Por eso la coordinación de privacidad debe formar parte del escalado de incidentes, no de una revisión jurídica tardía después de reconstruir sistemas y rotar registros.

La Política de registro y supervisión - pyme Política de registro y supervisión - pyme establece:

Las alertas de alta prioridad deben escalarse al Director General y al Coordinador de Privacidad en un plazo de 24 horas

Esa cláusula es sencilla, pero resuelve un patrón de fallo real. Los responsables de privacidad necesitan evidencias mientras aún están suficientemente recientes para determinar si se produjo una brecha de datos personales y si las personas están en riesgo.

Construir un paquete de evidencias de incidente transfronterizo de 24 horas

Un ejercicio práctico de preparación debe simular las primeras 24 horas de un incidente transfronterizo. El objetivo no es notificar en exceso. El objetivo es demostrar que la organización puede reunir hechos, tomar decisiones defendibles y mantener comunicaciones coherentes.

Escenario

Su MSSP detecta acceso privilegiado sospechoso desde una región inusual contra su entorno de producción. La misma infraestructura de origen aparece en alertas que afectan a dos clientes en dos Estados miembros. Un cliente es una entidad financiera. El entorno afectado contiene datos personales, pero la exfiltración de datos no está confirmada.

Paso 1: Abrir el registro de incidentes

Cree el ticket de incidente utilizando campos de clasificación aprobados. Incluya hora de toma de conocimiento, fuente de detección, activos afectados, servicios afectados, países potencialmente afectados, actividad maliciosa sospechada, gravedad inicial y responsable de la gestión del incidente.

Vincule esto con los controles 5.24, 5.25 y 5.26 de ISO/IEC 27002:2022, y con los controles A.5.24, A.5.25 y A.5.26 del anexo A de ISO/IEC 27001:2022.

Paso 2: Activar el flujo de decisión sobre autoridades

Utilice la matriz de contacto con autoridades exigida por el paso 22 de Zenith Blueprint. Identifique qué autoridades pueden ser relevantes: CSIRT nacional, autoridad de protección de datos, regulador financiero, fuerzas y cuerpos de seguridad y regulador sectorial.

Registre la decisión y su justificación. Si no se emite una alerta temprana NIS2, capture el motivo. Si es posible un impacto transfronterizo, registre las evidencias que respaldan esa conclusión.

Paso 3: Preservar evidencias antes de la remediación mayor

La Política de recopilación de evidencias y análisis forense empresarial Política de recopilación de evidencias y análisis forense establece:

Todas las evidencias recopiladas deberán identificarse de forma única, etiquetarse y almacenarse en un repositorio seguro con:

La Política de recopilación de evidencias y análisis forense - pyme Política de recopilación de evidencias y análisis forense - pyme aplica la misma disciplina de forma más sencilla:

«Cada elemento de evidencia digital debe registrarse con:»

De Política de recopilación de evidencias y análisis forense - pyme, sección «Requisitos de gobernanza», cláusula 5.2.1.

Para el ejercicio de mesa, recopile entradas de evidencia de muestra: exportación de alertas SIEM, registros del proveedor de identidad, registros de sesiones privilegiadas, instantánea de endpoint, registros de cortafuegos, registros de auditoría en la nube, notas de impacto en clientes y aprobaciones de comunicaciones.

Paso 4: Activar la asistencia de proveedores

Revise el registro de proveedores. Identifique el MSSP, el proveedor de nube y los subcontratistas críticos. Confirme cláusulas de apoyo en incidentes, contactos de escalado, períodos de conservación de registros, formato de evidencias y obligaciones de cooperación con autoridades.

Esto respalda directamente los requisitos de riesgo de terceros TIC de DORA y las expectativas de seguridad de la cadena de suministro de NIS2.

Paso 5: Redactar tres comunicaciones

Redacte tres comunicaciones a partir de la misma base de hechos:

Paso 6: Cerrar con lecciones aprendidas

Actualice el Registro de Riesgos, la Declaración de Aplicabilidad, el registro de proveedores y el plan de respuesta a incidentes. Si el ejercicio revela registros ausentes, contactos con autoridades poco claros o cláusulas débiles con proveedores, genere acciones correctivas.

Zenith Blueprint, fase Controles en acción, paso 23, instruye a las organizaciones para validar las capacidades de incidentes de este modo:

Seleccione un evento reciente o realice un ejercicio de mesa para validar su plan. Capture y registre todas las decisiones, roles y comunicaciones (5.26), y actualice el plan con lecciones aprendidas (5.27). Confirme que existen procedimientos para preservar evidencias forenses (5.28), incluidas instantáneas de registros, copias de seguridad y aislamiento seguro de los sistemas afectados.

Ese párrafo es una agenda de ejercicio preparada para auditorías.

Registro de eventos: la diferencia entre coordinación y especulación

La coordinación de incidentes transfronterizos falla cuando todos tienen opiniones y nadie tiene marcas temporales.

Zenith Blueprint, fase Controles en acción, paso 19, lo expresa con claridad:

El registro de eventos es el sistema circulatorio de cualquier entorno de TI seguro. Sin él, los incidentes permanecen invisibles, la responsabilidad proactiva se diluye y las relaciones de causa y efecto desaparecen.

Continúa:

En esencia, el registro de eventos trata de trazabilidad. Cuando algo sale mal, ya sea un intento de inicio de sesión fallido, la eliminación de archivos críticos o un script no autorizado ejecutándose en un servidor, los registros proporcionan el hilo forense que ayuda a desentrañar qué ocurrió realmente.

Para NIS2, los registros respaldan la notificación de incidente de 72 horas con gravedad inicial, impacto e indicadores de compromiso. Para DORA, los registros respaldan la clasificación de incidentes graves relacionados con las TIC, el análisis de causa raíz, el impacto operacional y la responsabilidad proactiva de terceros. Para el RGPD de la UE, los registros respaldan la evaluación de si se accedió a datos personales o se divulgaron. En un contexto del Reglamento de Cibersolidaridad, los registros respaldan una conciencia situacional compartida sin obligar a los intervinientes a basarse en especulación.

Si la respuesta a alguna pregunta es «no estoy seguro», el asunto pertenece al Plan de Tratamiento de Riesgos.

Continuidad del negocio y operaciones de crisis seguras

La conversación sobre el Reglamento de Cibersolidaridad se centra naturalmente en la respuesta a incidentes, pero la resiliencia también significa mantener seguros los servicios críticos durante una interrupción.

El artículo 21 de NIS2 exige un enfoque basado en todos los riesgos que cubra gestión de incidentes, continuidad del negocio, gestión de copias de seguridad, recuperación ante desastres, gestión de crisis, seguridad de la cadena de suministro, gestión de vulnerabilidades, evaluación de la eficacia, higiene cibernética, criptografía, seguridad de recursos humanos, control de acceso, gestión de activos, autenticación multifactor, comunicaciones seguras y comunicaciones de emergencia protegidas cuando proceda.

DORA exige igualmente gobernanza, gestión del riesgo TIC, gestión de incidentes, pruebas de resiliencia, gestión del riesgo de terceros, continuidad y recuperación. Las entidades más pequeñas pueden tener requisitos simplificados, pero siguen necesitando gestión del riesgo TIC documentada, supervisión, sistemas resilientes, gestión de incidentes, identificación de dependencias de terceros, copias de seguridad, restauración, pruebas, aprendizaje posterior al incidente y formación.

La Política de Continuidad del Negocio y Recuperación ante Desastres empresarial Política de Continuidad del Negocio y Recuperación ante Desastres parte de un requisito sencillo:

Los planes deberán cubrir:

Detrás de esa frase se encuentran las evidencias de continuidad que los auditores esperan: prioridades de recuperación, objetivos de tiempo de recuperación, objetivos de punto de recuperación, calendarios de copias de seguridad, pruebas de restauración, roles de crisis, comunicaciones alternativas, dependencias de proveedores y acciones de mejora posteriores al ejercicio.

Los controles 5.29 y 5.30 de ISO/IEC 27002:2022 son centrales aquí. El control 5.29 aborda la seguridad de la información durante interrupciones. El control 5.30 aborda la preparación TIC para la continuidad del negocio. En Zenith Controls, la planificación de incidentes bajo 5.24 se vincula con la seguridad durante interrupciones y la planificación más amplia de la continuidad. Esto es especialmente relevante cuando los canales normales no están disponibles, los sistemas de identidad están degradados o los equipos de crisis deben coordinarse con autoridades mediante comunicaciones de emergencia protegidas.

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

Un CISO no necesita cinco programas de incidentes separados. Necesita un modelo de evidencias que pueda observarse desde cinco perspectivas.

El método de perfiles actuales y objetivo de NIST CSF 2.0 es especialmente útil para organizaciones que aún no son suficientemente maduras para una plataforma GRC integrada completa. Anima a las organizaciones a delimitar un perfil, recopilar insumos como políticas, prioridades de riesgo empresarial, análisis de impacto en las operaciones de la organización, requisitos, normas, procedimientos, salvaguardas y roles, y después analizar brechas y crear un plan de acción priorizado. Esto se aproxima a un sprint práctico de preparación frente al Reglamento de Cibersolidaridad: evidencias actuales, obligaciones objetivo, plan de brechas, propietarios, fechas y pista de auditoría.

Los auditores de COBIT 2019 y estilo ISACA suelen preguntar si los objetivos de gobernanza tienen propietario, se miden y se supervisan. No se conformarán con «el SOC se encarga». Preguntarán cómo los órganos de dirección aprueban medidas de riesgo, cómo se informa del desempeño, cómo se gobierna el riesgo de terceros, cómo se aceptan las excepciones y cómo se realiza el seguimiento de las acciones correctivas.

Cómo probarán los auditores el mismo incidente

El mismo incidente de las 03:17 genera preguntas de auditoría distintas según el mandato del evaluador.

Un auditor de ISO/IEC 27001:2022 comenzará por el SGSI. Preguntará si el proceso de incidentes está dentro del alcance, si los requisitos de las partes interesadas incluyen NIS2, DORA, RGPD de la UE y contratos, si la evaluación de riesgos consideró escenarios transfronterizos y de proveedores, si los controles del anexo A fueron seleccionados en la Declaración de Aplicabilidad y si los registros operativos demuestran que se siguió el proceso.

Una autoridad o evaluador centrado en NIS2 se enfocará en la responsabilidad de la dirección, las medidas de gestión de riesgos del artículo 21 y la notificación del artículo 23. Puede preguntar cuándo tomó conocimiento la organización, por qué el incidente fue o no significativo, cómo se evaluó el impacto transfronterizo, si se informó a los clientes y si se adoptaron medidas correctivas sin dilación indebida.

Un supervisor DORA o un equipo de auditoría interna preguntará si el incidente afectó a funciones críticas o importantes, si los proveedores terceros TIC apoyaron la respuesta, si la entidad financiera mantuvo la responsabilidad, si el registro de información era exacto, si el incidente se clasificó correctamente y si las lecciones aprendidas retroalimentaron las pruebas de resiliencia y la supervisión de proveedores.

Un auditor del RGPD de la UE o una autoridad de protección de datos preguntará si la organización tenía evidencias suficientes para determinar si se vulneraron datos personales, si los roles de responsable del tratamiento y encargado del tratamiento estaban claros, si los interesados estaban en riesgo, si los controles de confidencialidad e integridad eran adecuados y si se mantuvieron registros de responsabilidad proactiva.

Un evaluador de NIST CSF 2.0 traducirá el evento en resultados de Govern, Identify, Protect, Detect, Respond y Recover. Buscará expectativas de partes interesadas, obligaciones legales, apetito de riesgo, gobernanza de proveedores, registro de eventos, supervisión, ejecución de la respuesta, comunicaciones y validación de la recuperación.

Un auditor de COBIT 2019 o ISACA se centrará en la eficacia del sistema de gobernanza y gestión: propiedad, derechos de decisión, métricas, aceptación del riesgo, desempeño de procesos, aseguramiento y mejora continua.

Aquí es donde Zenith Controls resulta útil como brújula de cumplimiento cruzado. No cambia el nombre de los controles oficiales ni crea un marco de control paralelo. Muestra cómo controles de ISO/IEC 27002:2022 como 5.5, 5.24 y 5.28 se conectan con capacidades operativas, controles relacionados y evidencias relevantes para auditoría.

Qué deben hacer ahora los CISO para la preparación de 2026

Si se está preparando para la realidad operativa del Reglamento de Cibersolidaridad de la UE, empiece por las evidencias, no por los lemas.

Primero, actualice el contexto de su SGSI y el análisis de partes interesadas. Identifique si su organización, clientes o proveedores están sujetos a NIS2, DORA o RGPD de la UE. Incluya presencia por Estado miembro, clasificación sectorial, clientes críticos, dependencias de servicios TIC y contactos con autoridades.

Segundo, realice un ejercicio de mesa de incidente transfronterizo. Utilice un escenario que incluya un proveedor, más de un Estado miembro, posible exposición de datos personales y un cliente financiero regulado. Limite temporalmente las primeras 24 horas.

Tercero, revise los contratos con proveedores. Confirme deberes de notificación, acceso a registros, apoyo forense, cooperación con autoridades, traslado de requisitos a subcontratistas, ubicación de datos, derechos de auditoría, apoyo a la continuidad y derechos de terminación.

Cuarto, pruebe la recopilación de evidencias. Exporte registros, preserve instantáneas, etiquete evidencias, registre la cadena de custodia y valide el acceso al repositorio. Si su política dice que las evidencias se identifican de forma única y se almacenan de manera segura, demuéstrelo.

Quinto, alinee las comunicaciones de incidentes. Su alerta temprana NIS2, el escalado DORA, la evaluación de brecha del RGPD de la UE y el aviso al cliente no deben contradecirse. Pueden tener propósitos legales diferentes, pero deben proceder de la misma base de hechos.

Sexto, haga que el consejo de administración forme parte del ejercicio. NIS2 y DORA elevan la responsabilidad de la dirección. Las cláusulas de liderazgo de ISO/IEC 27001:2022 hacen que esto sea auditable. Un consejo de administración que nunca ha visto un plazo de notificación cibernética de 24 horas no está preparado para una crisis transfronteriza.

Próximos pasos con Clarysec

El futuro de la ciberseguridad de la UE se basa en la colaboración y la confianza demostrada. Las organizaciones que traten NIS2 y DORA como listas de verificación aisladas tendrán dificultades durante incidentes transfronterizos. Las organizaciones que construyan sistemas operativos ISO/IEC 27001:2022 respaldados por evidencias podrán responder con confianza a reguladores, clientes, auditores e intervinientes de crisis.

Clarysec ayuda a CISO, responsables de cumplimiento, auditores y propietarios de negocio a convertir la regulación cibernética de la UE en evidencias operativas preparadas para auditorías mediante:

• Zenith Blueprint: hoja de ruta de 30 pasos para auditores para la implantación estructurada de ISO/IEC 27001:2022 y la secuenciación de auditorías.
• Zenith Controls: guía de cumplimiento cruzado para mapear controles de incidentes, autoridades, proveedores, evidencias, registro de eventos y continuidad entre marcos.
• Plantillas de políticas de Clarysec, incluidas Política de Respuesta a Incidentes, Política de recopilación de evidencias y análisis forense, Política de seguridad de terceros y proveedores, Política de Continuidad del Negocio y Recuperación ante Desastres, además de versiones para pymes cuando la proporcionalidad importa.

El mejor momento para prepararse para la coordinación de incidentes transfronterizos es antes de la alerta de las 03:17. El segundo mejor momento es hoy.

Empiece con una revisión de preparación de Clarysec, descargue el kit de políticas correspondiente o solicite una demostración de cómo Zenith Blueprint y Zenith Controls pueden ayudar a que su SGSI produzca las evidencias que exigirá la ciberresiliencia de 2026.