Reglamento y normas técnicas: qué está en cada sitio
El propio Reglamento fija los principios. Los detalles figuran en normas técnicas de regulación y de ejecución, elaboradas por las autoridades europeas de supervisión y adoptadas por la Comisión Europea. Quien implanta DORA trabaja por tanto siempre con varios textos en paralelo. Los más importantes se refieren al marco de gestión del riesgo relacionado con las TIC y su variante simplificada, la clasificación de incidentes y ciberamenazas, el contenido, los formatos y los plazos de las notificaciones de incidentes, las pruebas de penetración basadas en amenazas, las plantillas del registro de información, la política sobre servicios TIC que respaldan funciones esenciales o importantes y la subcontratación.
En la práctica, esto significa: el Reglamento dice que usted debe clasificar un incidente. Solo la norma técnica indica los criterios, como los clientes afectados, la duración, la extensión geográfica, la pérdida de datos y el impacto económico, y establece a partir de cuándo un incidente se considera grave. Lo mismo ocurre con el registro: qué campos tiene y cómo se estructura se desprende de las plantillas de la norma técnica de ejecución.
A ello se suman directrices y preguntas y respuestas de las autoridades europeas de supervisión, así como publicaciones de la BaFin, por ejemplo sobre vías de notificación y ventanas de presentación. Estos textos cambian con más frecuencia que el Reglamento. En Sightadel, cada control está vinculado al artículo al que se refiere. Cuando una norma técnica fija detalles, el control indica la evidencia esperada. En caso de duda, compruebe la versión vigente con el supervisor.
El registro de información en la práctica
El registro es la parte de DORA que la mayoría de las empresas ha subestimado. No pide simplemente una lista de contratos, sino un inventario estructurado: qué servicio TIC recibe la empresa, de quién, con qué contrato, para qué función, si esa función es esencial o importante, dónde se tratan los datos, lo fácil que sería sustituir al proveedor y qué subcontratistas hay detrás en la cadena. El registro se lleva a nivel de cada entidad y, en los grupos, también de forma consolidada.
La BaFin solicita el registro una vez al año con una fecha de referencia. La presentación se hace a través de su plataforma de notificación y publicación en una ventana de tiempo fijada. Para la presentación de 2026, esa ventana fue en marzo. Un registro solo se considera presentado cuando supera las reglas de validación de las autoridades europeas de supervisión. La falta de identificadores de proveedores o los datos contradictorios sobre funciones provocan rechazos. Las autoridades europeas de supervisión utilizan también los registros para designar a los proveedores terceros esenciales de servicios TIC sujetos a la supervisión directa de la UE.
El trabajo real no está en rellenar, sino en recopilar. Los datos están repartidos entre contratos, compras, TI y las áreas de negocio. Quien solo actualiza el registro para la fecha de referencia empieza de cero cada año. Por eso Sightadel parte del módulo Proveedores: cada proveedor se mantiene con su contrato, funciones respaldadas, criticidad, ubicaciones y evidencias en cuanto se le contrata. Los nuevos contratos, las resoluciones y los cambios de subcontratistas se registran allí en el día a día, no en primavera.
Costes y esfuerzo interno
DORA cuesta sobre todo tiempo de personas que ya están muy ocupadas: seguridad de la información, gestión de la continuidad, compras, jurídico, auditoría interna y dirección. La licencia de Sightadel para DORA se factura mensualmente según la edición, con descuentos por varios frameworks y por pago anticipado. Todos los precios y una calculadora están en nuestra página de precios.
Los costes externos surgen en otro lugar y los factura directamente cada proveedor. Según la experiencia, los mayores factores son tres. Primero, las adaptaciones de contratos con proveedores, a menudo con asesoramiento jurídico. Segundo, el programa de pruebas, sobre todo si ha sido designado para TLPT: una prueba basada en amenazas, con análisis de amenazas, red team y trabajo de cierre, es un proyecto de varios meses. Tercero, la recopilación de datos para el registro cuando los archivos de contratos están incompletos.
Dónde se puede ahorrar: quien opera un SGSI conforme a ISO 27001 no tiene que reinventar la gestión de riesgos, el control de accesos, las copias de seguridad ni la gestión de incidentes. En Sightadel, las evidencias existentes se asignan a ambos frameworks. A propósito no damos una cifra de solapamiento, porque depende del alcance. El asesoramiento para los puntos difíciles, como la determinación de las funciones esenciales o importantes, lo contrata cuando lo necesite como paquete en la aplicación.
Responsabilidad de la dirección, sanciones y responsabilidad civil
DORA deja expresamente la responsabilidad del riesgo relacionado con las TIC en manos del órgano de dirección. Este define y aprueba el marco, establece las funciones, determina la tolerancia al riesgo relacionado con las TIC, aprueba las políticas de continuidad de negocio y de terceros, aporta el presupuesto y se forma periódicamente. Se puede delegar el trabajo, no la responsabilidad. Por eso, en las auditorías se pregunta qué ha acordado la dirección, cómo se le informa y qué formación han completado sus miembros de forma demostrable.
En Alemania, las infracciones las sanciona la BaFin conforme al derecho nacional de supervisión, que se adaptó para trasladar las disposiciones sancionadoras de DORA. Caben requerimientos, multas y, ante deficiencias graves, otras medidas de supervisión. Los proveedores terceros esenciales de servicios TIC están sujetos a la supervisión directa de un supervisor principal europeo, que formula recomendaciones y puede imponer multas coercitivas calculadas sobre el volumen de negocios diario mundial.
Además de la supervisión, cuenta el aspecto civil. Una caída no regulada de un proveedor, una notificación tardía o una copia de seguridad no probada pueden plantear reclamaciones de daños de los clientes y cuestiones de responsabilidad de la dirección. Cómo valorarlo en cada caso lo aclara con su asesoría jurídica. Sightadel no presta asesoramiento jurídico, pero se asegura de que acuerdos, formaciones y decisiones queden documentados con fecha y responsable.
Qué documentación espera el supervisor
El Reglamento no da una lista cerrada, pero del Reglamento y las normas técnicas se desprende un núcleo claro. Incluye el marco documentado de gestión del riesgo relacionado con las TIC con la estrategia de resiliencia operativa digital, políticas de seguridad de la información, de control de accesos y de cambios y de gestión de vulnerabilidades, una política de continuidad de negocio de las TIC con planes de respuesta y recuperación, políticas de copias de seguridad con evidencias de restauración probada, un proceso de gestión de incidentes con criterios de clasificación y registro de incidentes, el programa de pruebas con sus resultados, la estrategia sobre el riesgo de terceros proveedores de servicios TIC, el registro de información y estrategias de salida para los proveedores que respaldan funciones esenciales o importantes.
El marco debe revisarse al menos una vez al año, así como tras incidentes graves y tras conclusiones de pruebas o auditorías. Sobre esa revisión se elabora un informe que el supervisor puede solicitar. Igual de importantes son las pruebas de que los documentos se aplican: aprobaciones, registros de formación, actas de pruebas de restauración y hallazgos resueltos de pruebas y de la auditoría interna.
En Sightadel, cada uno de estos documentos está asignado a un control, con versión, aprobación y fecha de caducidad. Si caduca una evidencia, por ejemplo una prueba de restauración anual, aparece en el panel como punto abierto. Así, el estado no está completo solo en la fecha de la auditoría.
Planificar bien el programa de pruebas y la TLPT
Toda entidad financiera que no esté sujeta al marco simplificado necesita un programa basado en el riesgo para probar la resiliencia operativa digital. Según el entorno, incluye evaluaciones y análisis de vulnerabilidades, revisiones de código fuente, pruebas basadas en escenarios, pruebas de compatibilidad y de rendimiento, pruebas de extremo a extremo y pruebas de penetración. Los sistemas que respaldan funciones esenciales o importantes se prueban adecuadamente al menos una vez al año. Los probadores deben ser independientes, internos o externos.
Las pruebas de penetración basadas en amenazas, TLPT, solo afectan a las entidades designadas por el supervisor y, en ese caso, suelen realizarse cada tres años. Siguen una norma técnica propia que se orienta al marco europeo TIBER. Una TLPT se realiza sobre sistemas en producción e incluye un análisis de amenazas, un ataque encubierto de un red team y un análisis conjunto posterior. El supervisor acompaña la prueba y confirma al final su realización.
A menudo se subestima el tiempo posterior a la prueba. Los hallazgos deben evaluarse, priorizarse y resolverse con plazos, y el supervisor quiere ver el progreso. En Sightadel, cada hallazgo se convierte en un problema con responsable y fecha de vencimiento. La prueba la realizan probadores especializados; Sightadel registra la planificación, el resultado y la resolución.
Relación con NIS2, ISO 27001 y los requisitos anteriores de la BaFin
Para las entidades financieras, DORA es la norma especial frente a NIS2. Cumplen las obligaciones de ciberseguridad a través de DORA, no por partida doble. En grupos con sociedades fuera del sector financiero pueden aplicarse ambos regímenes a la vez. En ese caso conviene llevar medidas y evidencias una sola vez y asignarlas a ambos.
Las anteriores circulares de TI de la BaFin para bancos, aseguradoras, sociedades gestoras y entidades de pago han sido sustituidas por el Reglamento para las empresas incluidas en el ámbito de aplicación de DORA. La BaFin ha publicado indicaciones sobre cómo se relacionan los requisitos existentes, por ejemplo sobre la gestión de externalizaciones fuera de las TIC, con DORA. Qué partes siguen vigentes en su entidad debería aclararse antes del análisis de brechas.
ISO 27001 no es obligatoria, pero es una estructura probada. Un certificado demuestra que funciona un sistema de gestión que sostiene gran parte de DORA. Lo que DORA exige además es, sobre todo, el registro, los plazos de notificación, el contenido de los contratos y el programa de pruebas. Los informes de atestación como BSI C5 o SOC 2 de sus proveedores son pruebas valiosas al evaluarlos, pero no sustituyen su propia evaluación de riesgos.
