Hace un año repasé en este blog los retos de adecuación a las normas NIS2, CRA, CER y DORA. Desde entonces he hablado de ellas con partners y clientes en el roadshow NIS2 & DORA de Ingram Micro, en Madrid, Barcelona, Málaga y, este octubre, en Bilbao. La pregunta que más se repite en el turno de preguntas no es «¿qué dice cada norma?», sino «¿cómo cumplo todas a la vez sin montar cinco proyectos distintos?».
En 2026 la lista se ha alargado con el Reglamento de Inteligencia Artificial (AI Act), y varias fechas se han movido. Este artículo actualiza el calendario y propone una respuesta práctica a esa pregunta: tratar el cumplimiento como un único sistema de gobierno, riesgo y cumplimiento (GRC), con un mapa de controles común para todas las normas.
Qué ha cambiado desde 2025
En un año, tres normas han empezado a exigir cosas nuevas y dos siguen esperando su ley española. DORA se aplica desde enero de 2025; la notificación de vulnerabilidades del CRA, desde septiembre de 2026; y las reglas de transparencia del AI Act, desde agosto de 2026. NIS2 y CER, en cambio, siguen sin transponer en España, y el alto riesgo del AI Act se ha aplazado a 2027 y 2028. A eso se suma la disolución de las Cortes el 6 de octubre, con elecciones generales el 29 de noviembre: los proyectos de ley españoles sobre entidades críticas y sobre inteligencia artificial han decaído y vuelven a la casilla de salida.
Calendario de NIS2, DORA, CER, CRA y AI Act: hitos de 2024 a 2028. La línea discontinua marca noviembre de 2026.
La línea discontinua marca el dia de hoy: todo lo que queda a su izquierda ya debería estar resuelto.
Norma por norma
Cada norma mira el riesgo digital desde un ángulo distinto: la entidad, el producto, el sector financiero, la infraestructura física o el algoritmo.
NIS2: la ciberseguridad de la organización
La Directiva (UE) 2022/2555 obliga a las entidades esenciales e importantes de 18 sectores a gestionar sus riesgos de ciberseguridad y a notificar los incidentes significativos: alerta temprana en 24 horas, notificación en 72 horas e informe final en un mes. Exige que los órganos de dirección aprueben las medidas, se formen y respondan de su cumplimiento.
En España seguimos sin ley. El anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad se aprobó en primera vuelta en enero de 2025, pero nunca llegó a remitirse a las Cortes como proyecto de ley, y en julio de 2026 la Comisión Europea llevó a España ante el Tribunal de Justicia de la UE por no transponer la directiva. Tras la disolución de las Cortes, su futuro depende del Gobierno que salga de las elecciones. Mientras tanto siguen vigentes el Real Decreto-ley 12/2018 y el Esquema Nacional de Seguridad, y muchas empresas españolas ya reciben exigencias NIS2 por contrato de clientes de otros países que sí la han transpuesto. Pero el terreno no está vacío.
Que no haya ley no significa que no haya obligaciones. El Reglamento de Ejecución (UE) 2024/2690, de 17 de octubre de 2024, desarrolla NIS2 para once tipos de proveedores digitales: servicios DNS, registros de dominios de primer nivel, computación en nube, centros de datos, redes de distribución de contenidos, servicios gestionados y de seguridad gestionada, mercados en línea, motores de búsqueda, redes sociales y prestadores de servicios de confianza. Al ser un reglamento, es directamente aplicable y no necesita transposición, como ya comenté a propósito del roadshow de Ingram Micro.
Su anexo detalla, en trece secciones, las medidas técnicas y metodológicas que se esperan: política de seguridad, gestión de riesgos, gestión de incidentes, continuidad, cadena de suministro, control de accesos o criptografía, entre otras. También fija cuándo un incidente es significativo, por ejemplo una pérdida económica directa superior a 500.000 euros o al 5 % de la facturación anual, o un servicio en la nube indisponible más de 30 minutos. Para cualquier otra empresa es, además, la mejor guía disponible de lo que un supervisor considerará «medidas adecuadas» cuando llegue la ley española.
CRA: la seguridad del producto
El Reglamento (UE) 2024/2847, de ciberresiliencia, se dirige a fabricantes, importadores y distribuidores de productos con elementos digitales, del software al dispositivo conectado. Exige seguridad desde el diseño, gestión de vulnerabilidades durante todo el ciclo de vida, actualizaciones de seguridad y una lista de componentes (SBOM).
Desde el 11 de septiembre de 2026 ya hay que notificar las vulnerabilidades explotadas activamente y los incidentes graves que afecten a un producto: alerta en 24 horas, notificación en 72 horas e informe final, a través de la plataforma única de notificación de ENISA. El resto de obligaciones, incluido el marcado CE con requisitos de ciberseguridad, se aplica desde el 11 de diciembre de 2027.
DORA: la resiliencia operativa del sector financiero
El Reglamento (UE) 2022/2554 se aplica desde el 17 de enero de 2025 a bancos, aseguradoras, gestoras, entidades de pago y proveedores de criptoactivos. Pide un marco de gestión del riesgo TIC aprobado por el consejo, notificación de incidentes graves, pruebas de resiliencia (incluidas pruebas de penetración basadas en amenazas para las entidades más relevantes) y un control estricto de los proveedores TIC, con registro de información de todos los contratos.
En noviembre de 2025 las autoridades europeas de supervisión publicaron la primera lista de proveedores TIC críticos, que pasan a supervisión europea directa. Para el resto de proveedores de la banca, DORA llega por contrato: cláusulas obligatorias, derecho de auditoría y planes de salida.
CER: la resiliencia física de las entidades críticas
La Directiva (UE) 2022/2557 amplía la protección de infraestructuras críticas a toda amenaza que pueda interrumpir un servicio esencial: catástrofes naturales, sabotaje, terrorismo, crisis sanitarias o fallos en la cadena de suministro. Las entidades designadas como críticas deben evaluar sus riesgos, aprobar un plan de resiliencia y notificar los incidentes en 24 horas.
El Gobierno llevó al Congreso en marzo de 2026 el proyecto de Ley de Protección y Resiliencia de Entidades Críticas, que designaba a la Secretaría de Estado de Seguridad como autoridad competente y convertía el CNPIC en CNPREC. Preveía nueve meses para la evaluación de riesgos tras la designación, seis para el plan de resiliencia y multas de hasta 10 millones de euros o el 2 % de la facturación mundial. La parte de ciberseguridad de estas entidades se remitía a NIS2. El proyecto decayó con la disolución de las Cortes y tendrá que aprobarse y presentarse de nuevo en la próxima legislatura. Mientras tanto sigue vigente la Ley 8/2011 de protección de infraestructuras críticas, y el plazo europeo para identificar a las entidades críticas, julio de 2026, ya ha vencido.
AI Act: el riesgo del algoritmo
El Reglamento (UE) 2024/1689 clasifica los sistemas de IA por nivel de riesgo. Las prácticas prohibidas y la obligación de alfabetización en IA rigen desde febrero de 2025; las obligaciones de los modelos de uso general, desde agosto de 2025; y las de transparencia del artículo 50 (avisar de que se habla con una IA, marcar el contenido sintético), desde el 2 de agosto de 2026.
El paquete ómnibus digital, publicado en julio de 2026 como Reglamento (UE) 2026/1744, aplazó las obligaciones de los sistemas de alto riesgo: al 2 de diciembre de 2027 los del anexo III (empleo, solvencia crediticia, educación, biometría, servicios esenciales) y al 2 de agosto de 2028 los integrados en productos regulados. El aplazamiento da aire, pero no cambia lo que hay que preparar: inventario de sistemas, gestión de riesgos, gobernanza de datos, supervisión humana, registros y ciberseguridad del propio sistema. En España, la autoridad de supervisión es la AESIA. El Proyecto de Ley Orgánica para el buen uso y la gobernanza de la inteligencia artificial, que debía completar el reparto de autoridades y el régimen sancionador nacional, estaba en el Congreso desde junio de 2026 y también decayó con la disolución. El reglamento europeo se sigue aplicando directamente, pero sin esa ley el régimen sancionador español queda incompleto.
Lo que tienen en común
Leídas juntas, las cinco normas piden casi lo mismo con distinto vocabulario. Hay seis piezas que se repiten:
- Responsabilidad de la dirección. NIS2 y DORA exigen que el consejo apruebe y supervise las medidas; CER pide una función de seguridad y resiliencia asignada; el AI Act exige un sistema de gestión de la calidad y responsables identificados.
- Gestión de riesgos documentada. Todas parten de un análisis de riesgos periódico, con medidas proporcionales y revisiones regulares.
- Notificación de incidentes con reloj. NIS2, CRA y CER coinciden en las 24 horas para el primer aviso; DORA pide la notificación inicial en 4 horas desde que el incidente se clasifica como grave, y el AI Act exige comunicar los incidentes graves de los sistemas de alto riesgo.
- Cadena de suministro. NIS2 pide evaluar a los proveedores, DORA regula sus contratos, el CRA obliga a controlar los componentes de terceros y el AI Act reparte obligaciones entre proveedor y responsable del despliegue.
- Continuidad y recuperación. Copias de seguridad, planes de continuidad y pruebas periódicas aparecen en NIS2, DORA y CER.
- Evidencias. Todas esperan que se pueda demostrar el cumplimiento ante un supervisor, un auditor o un cliente: políticas aprobadas, registros fechados, informes de pruebas y trazas de decisión.
La sexta pieza es la que más se olvida. Cumplir y no poder demostrarlo, a efectos prácticos, es no cumplir.
El GRC como hilo conductor
Si las seis piezas se repiten, lo razonable es construirlas una vez. Eso es un sistema de gobierno, riesgo y cumplimiento (GRC): un único marco en el que la dirección fija responsabilidades, se mantiene un solo registro de riesgos y cada control se asocia a todas las obligaciones que satisface.
En la práctica, un GRC bien planteado se apoya en cuatro elementos:
- Un mapa de controles común. Se parte de un marco de referencia ya conocido (ISO/IEC 27001 o el Esquema Nacional de Seguridad) y se marca, control a control, a qué artículo de NIS2, DORA, CRA, CER o AI Act responde. Un mismo control de gestión de vulnerabilidades, por ejemplo, sirve a NIS2, al CRA y a DORA.
- Normas de gestión complementarias. ISO 22301 para la continuidad, que alimenta DORA y CER, e ISO/IEC 42001 para los sistemas de gestión de la IA, que encaja con el AI Act.
- Un procedimiento único de incidentes. Una sola clasificación y un solo flujo que, según el tipo de incidente, dispare la notificación a INCIBE-CERT o CCN-CERT, al Banco de España o la CNMV, a la plataforma de ENISA o al CNPREC, con sus plazos.
- Una gestión de proveedores integrada. Un único inventario de terceros, con las cláusulas de DORA, las exigencias de seguridad de NIS2 y los requisitos de producto del CRA en el mismo expediente.
Las herramientas GRC del mercado automatizan buena parte de este trabajo: catálogos de controles con correspondencias entre normas, recogida de evidencias, cuadros de mando para la dirección y seguimiento de planes de acción. Pero la herramienta no sustituye al diseño: primero hay que decidir qué normas aplican y con qué alcance, y después elegir cómo gestionarlo.
La pieza que no aparece en ninguna norma: la criptografía poscuántica
Ninguna de las cinco normas menciona la criptografía poscuántica, pero todas exigen medidas acordes con el estado de la técnica. NIS2 pide políticas sobre el uso de la criptografía y el cifrado, y la sección 9 del anexo del Reglamento de Ejecución 2024/2690 exige una política criptográfica con gestión de claves; DORA, controles criptográficos que se revisen ante la evolución de las amenazas; el CRA, cifrado de los datos con mecanismos actualizados. Un algoritmo que un ordenador cuántico podrá romper dejará de ser estado de la técnica mucho antes de que ese ordenador exista, porque lo que hoy se cifra o se firma puede capturarse ahora y descifrarse o falsificarse después.
El calendario ya lo ha puesto la propia Unión Europea. La hoja de ruta coordinada para la transición a la criptografía poscuántica, publicada en junio de 2025, pide que a finales de 2026 estén hechos los inventarios de activos criptográficos, incluida la cadena de suministro; que en 2030 estén protegidos los casos de uso de alto riesgo; y que en 2035 la transición esté completa para los de riesgo medio. Los algoritmos de referencia, ML-KEM y ML-DSA, están normalizados por el NIST desde agosto de 2024.
Para un sistema GRC esto se traduce en tres tareas concretas: añadir al inventario de activos un inventario criptográfico (qué algoritmos, claves y certificados se usan y dónde), incluir la amenaza cuántica en el registro de riesgos, y exigir criptoagilidad a los proveedores, es decir, la capacidad de cambiar de algoritmo sin rediseñar el sistema. Un fabricante que hoy prepara el marcado CE de su producto para el CRA haría bien en contar con que ese producto seguirá en el mercado en 2030.
Las cinco normas de un vistazo
| Norma | Qué protege | A quién obliga | Primer aviso de incidente | Situación a noviembre de 2026 |
|---|---|---|---|---|
| NIS2 | Redes y sistemas de información | Entidades esenciales e importantes de 18 sectores | 24 horas | Anteproyecto nunca remitido a las Cortes; España, ante el TJUE |
| CRA | Productos con elementos digitales | Fabricantes, importadores y distribuidores | 24 horas | Notificación obligatoria desde el 11-09-2026; resto, desde el 11-12-2027 |
| DORA | Resiliencia operativa TIC | Entidades financieras y proveedores TIC críticos | 4 horas tras clasificarlo como grave (máximo 24 horas) | Aplicable desde el 17-01-2025 |
| CER | Continuidad de servicios esenciales ante cualquier amenaza | Entidades designadas como críticas | 24 horas | Proyecto de ley decaído al disolverse las Cortes; sigue la Ley 8/2011 |
| AI Act | Derechos y seguridad frente a sistemas de IA | Proveedores y responsables del despliegue de IA | Incidentes graves de sistemas de alto riesgo | Transparencia desde el 02-08-2026; alto riesgo, 2027 y 2028; ley orgánica española decaída |
Una hoja de ruta en seis pasos
- Determinar qué normas aplican. Por sector, tamaño, productos que se fabrican o distribuyen, uso de IA y relación con clientes financieros o entidades críticas. Muchas empresas descubren que les afectan tres o cuatro, aunque sea por contrato.
- Nombrar un responsable y llevarlo al consejo. La dirección tiene que aprobar el marco y recibir informes periódicos.
- Hacer un análisis de brechas único contra el mapa de controles común, no uno por norma.
- Priorizar por plazos ya vencidos. DORA y la notificación del CRA ya se aplican; la transparencia del AI Act, también.
- Unificar incidentes y proveedores en un solo procedimiento y un solo inventario.
- Preparar las evidencias desde el principio, con fecha cierta y conservación a largo plazo.
En este último punto los servicios de confianza del Reglamento eIDAS aportan algo que ninguna hoja de cálculo ofrece: la firma y el sello electrónico acreditan quién aprobó una política o emitió un informe, el sello de tiempo cualificado prueba cuándo, y la conservación cualificada mantiene ese valor probatorio durante años. Un registro de incidentes o un informe de pruebas de resiliencia sellado en el momento en que se genera es mucho más difícil de discutir ante un supervisor. Y conviene que esas firmas y sellos sigan siendo válidos cuando llegue la criptografía poscuántica, otra razón para planificar la criptoagilidad.
Ninguna organización tiene que recorrer este camino sola. En el roadshow de Ingram Micro lo hemos visto en cada parada: fabricantes como HPE, SonicWall, Hornetsecurity, Barracuda o Bitdefender aportan la tecnología de protección, copia y recuperación, y la red de partners de Ingram Micro la integra en soluciones adaptadas a cada cliente. El cumplimiento normativo es, al final, una buena excusa para hacer bien lo que habría que hacer de todos modos.
Cómo puede ayudar EADTrust
En EADTrust llevamos años cumpliendo como prestador cualificado de servicios de confianza bajo eIDAS, con certificaciones en el Esquema Nacional de Seguridad (categoría alta), ISO/IEC 27001, ISO/IEC 20000-1 e ISO 22301, y esa experiencia es la que ponemos al servicio de otras organizaciones. Nuestra división de servicios profesionales acompaña a las empresas en todo el recorrido descrito en este artículo: el análisis de brechas unificado frente a NIS2, DORA, CRA, CER y AI Act, la implantación de las medidas y la preparación de evidencias con firma, sello y sello de tiempo cualificados. También ayudamos a hacer el inventario criptográfico y a planificar la migración a la criptografía poscuántica, un trabajo que ya hacemos con grandes clientes, y ofrecemos formación in company en computación cuántica y criptografía poscuántica.
Cuando el reto tiene tanto de jurídico como de técnico, nuestro trabajo puede completar el asesoramiento de Garrigues, accionista de EADTrust y referente en alinear las exigencias legales con las tecnológicas: el despacho interpreta la norma y nosotros la convertimos en controles, procedimientos y evidencias que funcionan. Si quiere un primer diagnóstico, puede escribirnos a info@eadtrust.com o llamarnos al 91 716 05 55 o al 902 365 612.
Fuentes
- Directiva (UE) 2022/2555 (NIS2)
- Reglamento (UE) 2024/2847 (CRA) y obligaciones de notificación del CRA
- Reglamento (UE) 2022/2554 (DORA) y designación de proveedores TIC críticos
- Directiva (UE) 2022/2557 (CER) y proyecto de Ley de Protección y Resiliencia de Entidades Críticas
- Reglamento (UE) 2024/1689 (AI Act) y ómnibus digital de IA
- Estado de la transposición de NIS2 en España
- Obligaciones de notificación del CRA desde el 11 de septiembre de 2026 (McCann FitzGerald)
- Real Decreto 806/2026 de disolución de las Cortes (LegalToday)
- La ley española de IA decae con la disolución de las Cortes (Bufete Castañeda)
- Hoja de ruta coordinada de la UE para la transición a la criptografía poscuántica (PQShield)
- Reglamento de Ejecución (UE) 2024/2690 (BOE) y resumen de su alcance (nisd2.eu)
