El Reglamento de Resiliencia Operativa Digital (DORA) se aplica a bancos, aseguradoras, entidades de pago, proveedores de criptoactivos y a sus proveedores críticos de TIC en toda la UE. A diferencia de un marco que se adopta de forma voluntaria, DORA es un reglamento con fecha: aplica desde el 17 de enero de 2025. La mayoría de los equipos de cumplimiento lo leen como un mandato de registro y notificación de incidentes. Mirando más de cerca, también es un mandato de evidencia, y es en esa mitad donde está la brecha.
Qué exige realmente el Artículo 9
El Artículo 9 de DORA exige a las entidades financieras implementar políticas y herramientas que garanticen la «autenticidad, integridad, disponibilidad y confidencialidad» de los datos, incluidos los de los logs y pistas de auditoría que se usan para reconstruir incidentes. La expectativa del supervisor no es que hayas conservado los registros. Es que puedas demostrar que son los originales, sin alterar, cuando un regulador o una autoridad de resolución lo pida.
Hay un supuesto silencioso en la mayoría de las implementaciones: que el sistema que produjo el log es también un testigo fiable de la integridad de ese log. La óptica de resiliencia de DORA rompe ese supuesto. Si el sistema de TIC está comprometido —el escenario exacto para el que existe DORA—, su propia certificación de que los logs están intactos vale muy poco.
Dónde se queda corto «registramos todo»
El registro exhaustivo es necesario y la mayoría de las entidades reguladas lo hace bien. La brecha aparece en los tres momentos que más le importan a un supervisor:
- Reconstrucción tras un incidente — DORA espera que reconstruyas la secuencia de eventos. Si los logs vivían dentro del sistema vulnerado, la reconstrucción depende de datos que un atacante pudo haber editado.
- Registros de terceros y proveedores de TIC — DORA alcanza a los proveedores críticos. Demostrar que el registro de un proveedor está intacto es mucho más fácil cuando ambas partes verifican contra una referencia externa compartida en lugar de intercambiar exportaciones de logs.
- Demostración independiente — un regulador no tiene por qué creer tu palabra de que los controles de retención e inmutabilidad funcionaron. La integridad que cualquiera puede verificar contra un anclaje externo convierte una afirmación en un hecho demostrable.
La fecha límite ya pasó, ¿por qué sigue siendo un detonante de compra?
Enero de 2025 fue la fecha de aplicación, no la meseta de cumplimiento. Las autoridades supervisoras dedicaron el primer año a mapear entidades y evaluar líneas base. El cambio en marcha ahora va de «¿tienes una política?» a «muéstranos la evidencia», y la segunda pregunta es la que la prueba de integridad responde directamente.
Las entidades que se mueven primero no son las que peor registran. Son aquellas a las que sus auditores y reguladores ya han empezado a hacerles la segunda pregunta y que prefieren responderla con un anclaje verificable antes que con una captura de pantalla de una política de retención.
Cómo encaja la prueba de integridad en el flujo de DORA
Añadir una capa de verificación no sustituye tu SIEM, tu canal de logs ni tu proceso de incidentes. Funciona en paralelo, sellando los registros que esos sistemas ya producen:
Cuando un supervisor te pide demostrar que un registro de auditoría dado es el original, presentas un paquete de prueba: el hash del registro, su posición en el árbol de Merkle y la referencia en la cadena pública donde se ancló la raíz en un momento conocido. Nada de eso exige que el regulador confíe en el sistema que generó el log, que es precisamente el punto de DORA.
Quién es el responsable dentro de la entidad
DORA trasladó el riesgo de TIC al órgano de dirección, así que quienes preguntan por la evidencia de integridad cada vez son menos los ingenieros:
- Responsable de Cumplimiento — gestiona la relación con el regulador y debe traducir «tenemos controles» en «aquí está la evidencia demostrable».
- CISO / riesgo de TIC — gestiona la postura de resiliencia y sabe que los logs autocertificados son el eslabón débil al reconstruir una brecha.
- Auditoría interna — gestiona la línea de aseguramiento y se beneficia cuando la integridad es verificable sin depender del sistema auditado.
El planteamiento honesto para una conversación sobre DORA
DORA no nombra blockchain, árboles de Merkle ni ninguna tecnología concreta —y deberías desconfiar de cualquier proveedor que afirme lo contrario—. Lo que DORA exige es integridad que puedas demostrar a un tercero independiente. Anclar registros a una cadena pública es una forma estructuralmente sólida de lograrlo, porque la prueba no depende del buen comportamiento continuado del sistema bajo examen. La pregunta para tu próxima revisión de DORA es simple: para cada pista de auditoría crítica, ¿podemos demostrar a un regulador que no ha cambiado, sin pedirle que confíe en el sistema que la produjo?
DORA no pregunta si conservaste los registros. Pregunta si puedes demostrar que son los originales — a alguien que no tiene motivo para confiar en el sistema que los produjo.