EDIH, EEN, Interreg: la plataforma de los programas europeos.Saber más

Análisis

CRA, NIS2, DORA: tres normas, un solo dispositivo de ciberresiliencia

El reglamento de productos (CRA), la directiva de sectores críticos (NIS2) y el reglamento financiero (DORA) recaen sobre los mismos equipos de seguridad y cumplimiento, con tres calendarios y tres canales de notificación distintos. Las organizaciones que avanzan son las que los gestionan desde un único diagnóstico.

29 de julio de 2026 · 4 min de lectura

Todos los artículos
Michael Aim

Michael Aim

Fundador y CEO

Tres normas, los mismos equipos

Europa ha construido su ciberresiliencia en tres piezas. NIS2 se dirige a las entidades esenciales e importantes de dieciocho sectores críticos: una directiva, por tanto sujeta a transposición nacional, cuya versión francesa se hace esperar hasta el punto de que la Comisión llevó a Francia ante el Tribunal de Justicia el 9 de julio. DORA se dirige a las entidades financieras, bancos, aseguradoras, gestoras: un reglamento, aplicable tal cual desde el 17 de enero de 2025, supervisado en Francia por la ACPR. El CRA se dirige a los productos: cualquier equipo o software con elementos digitales comercializado en el mercado europeo, con un primer plazo vinculante el 11 de septiembre de 2026, la notificación de vulnerabilidades activamente explotadas, y la Comisión acaba de publicar su primera guía de aplicación.

Vistos desde Bruselas, tres ámbitos distintos. Vistos desde dentro de un grupo, las mismas personas: el responsable de seguridad, el equipo de cumplimiento, la dirección de riesgos, a menudo los mismos proveedores. Un banco que desarrolla sus propias aplicaciones queda sujeto a DORA por su dispositivo, al CRA por sus productos, y su grupo puede tener filiales bajo NIS2. La normativa prevé además esta articulación: para las entidades financieras, DORA prevalece sobre NIS2, como norma sectorial específica. Aun así, hay que saber con precisión quién, dentro del grupo, depende de qué texto.

Lo que las tres normas exigen en común

Despojadas de su vocabulario propio, las tres normas exigen la misma base. Una gobernanza identificada: los órganos de dirección son responsables, de forma personal en NIS2 y DORA, de aprobar y supervisar el dispositivo. Una gestión de riesgos TIC documentada: identificar los activos, evaluar las amenazas, corregir las desviaciones. Un proceso de gestión de incidentes: detectar, calificar, notificar, extraer lecciones. Y un control de terceros: la cadena de suministro en NIS2, el registro de proveedores TIC en DORA, entregado a los supervisores desde abril de 2025, la cadena de componentes en el CRA.

Las diferencias reales están en los plazos y en los canales. Un incidente grave se notifica a la ANSSI bajo NIS2 (alerta temprana en 24 horas, notificación en 72 horas), al supervisor financiero bajo DORA según sus propios modelos armonizados, a ENISA bajo el CRA en caso de vulnerabilidad de producto activamente explotada, en 24 horas. Tres formularios, tres relojes, un solo incidente real.

La trampa de los tres proyectos paralelos

El tratamiento en silos produce aquí sus efectos más concretos. Tres proyectos de cumplimiento generan tres inventarios de activos que divergen entre sí, tres mapas de riesgos con escalas incompatibles, tres procedimientos de notificación de los que nadie sabe cuál se aplica a las dos de la madrugada cuando el incidente es real y los tres relojes corren a la vez.

Es la prueba que no perdona: un incidente significativo en una entidad financiera que también desarrolla software puede desencadenar simultáneamente una notificación DORA al supervisor y una notificación CRA a ENISA, mientras las filiales del grupo se preguntan por sus obligaciones bajo NIS2. Las organizaciones que han ensayado este escenario sobre un dispositivo unificado lo resuelven; las demás lo descubren sufriéndolo.

Una base común, tres lecturas normativas

La respuesta metodológica es la misma que describíamos para la acumulación normativa en general: separar la base, que se mide una sola vez, de las lecturas normativas, que se desglosan por texto. Un diagnóstico de madurez de ciberresiliencia evalúa las capacidades comunes, gobernanza, riesgos, incidentes, terceros, pruebas, sobre una escala homogénea; cada criterio se vincula a las normas a las que sirve, y los tres marcos de cumplimiento se leen como tres proyecciones de un mismo diagnóstico de partida.

Este cruce hace visibles las sinergias útiles: un proceso de incidentes unificado, con sus umbrales de calificación y su directorio de canales, hace avanzar las tres normas de golpe. Un registro de terceros bien construido sirve a DORA hoy y a la cadena de suministro de NIS2 mañana. Y un lenguaje de riesgo común, el de ISO 27005, por ejemplo, evita que cada texto reinvente su propia escala de gravedad.

Por dónde empezar antes del 11 de septiembre

El plazo del CRA del 11 de septiembre es el detonante adecuado, porque está cerca, es vinculante y es operativo. Tres pasos en orden: aclarar quién, dentro del grupo, depende de qué texto, entidad por entidad y producto por producto. Unificar el proceso de notificación, un único procedimiento interno, tres canales de salida, responsables identificados y localizables. Después, medir la madurez de la base y convertir las brechas en un plan de acción con fechas, priorizando lo que sirve a las tres normas a la vez.

El calendario no se detendrá ahí: las obligaciones principales del CRA llegan en diciembre de 2027, la ley de Resiliencia francesa terminará por aprobarse, DORA sigue elevando sus exigencias sobre las pruebas. Las organizaciones que gestionen este trío desde un diagnóstico único absorberán cada nuevo peldaño. Las demás volverán a empezar el proyecto en cada plazo.