La resiliencia se pone a prueba: cumplir con la normativa DORA de la UE ya no es suficiente
La resiliencia digital ha pasado de ser un concepto aspiracional para convertirse en un requisito medible. Los datos son contundentes. La mayoría de las empresas no podrían sobrevivir a tres días de inactividad y, sin embargo, el 96% de las organizaciones de servicios financieros reconocen que todavía no cumplen plenamente con DORA (Ley de Resiliencia Operativa Digital).
DORA ES una normativa de la Unión Europea diseñada para reforzar la capacidad de las entidades financieras para resistir, responder y recuperarse de interrupciones relacionadas con las TIC, incluidos ciberataques, fallos de sistemas y caídas de proveedores externos.
La brecha entre lo que se espera y lo que realmente puede ejecutarse sigue ampliándose. Los reguladores ya están actuando para trasladar el foco desde la intención hacia los resultados, y es precisamente ahí donde comienzan los problemas.
La recuperación, bajo escrutinio
Con normativas como DORA ya no basta con disponer de planes de recuperación; las organizaciones deben demostrar, con pruebas, que funcionan cuando más se necesitan. DORA exige pruebas periódicas de los planes de respuesta y recuperación (incluyendo simulaciones realistas de ciberataques). Los objetivos de punto de recuperación (RPO) y de tiempo de recuperación (RTO) deben validarse en condiciones reales.
Sin embargo, la definición de “condiciones reales” sigue siendo bastante ambigua. En el peor de los escenarios, por ejemplo, si un atacante lograra acceder a credenciales administrativas del máximo nivel, las consecuencias podrían ser catastróficas. En muchos casos, lo que está documentado no resistiría un escenario de crisis real que amenace la continuidad del negocio.
Las copias de seguridad, el verdadero objetivo
En la mayoría de los ataques de ransomware, las copias de seguridad son uno de los primeros objetivos. La razón es clara. Al impedir la recuperación, los atacantes aumentan las probabilidades de recibir un pago. Y lo que es peor, pagar un rescate no garantiza por sí mismo la recuperación de los datos.
En cualquier caso, un ataque de ransomware no es solo un problema de TI. La producción puede detenerse, pueden perderse ingresos, verse afectados los servicios al cliente y las cadenas de suministro, y el daño reputacional puede escalar rápidamente. En este contexto, la capacidad de recuperación marca la diferencia entre un incidente controlado y una crisis que afecte a toda la organización. Este es un punto crítico que muchas empresas todavía subestiman.
Casi todas las organizaciones cuentan con algún tipo de sistema de backup. Sin embargo, las soluciones basadas en tecnologías heredadas pueden generar una falsa sensación de seguridad. Incluso pueden parecer suficientes durante una auditoría, pero en condiciones reales (especialmente durante un ataque grave) suelen fallar. El problema no es solo técnico, sino estructural.
La inmutabilidad ya no es opcional
En teoría, un backup inmutable no puede sobrescribirse, manipularse ni eliminarse. Sin embargo, con frecuencia existen excepciones y lagunas, especialmente cuando la inmutabilidad es una función añadida y no un componente nativo de la arquitectura de backup.
Algunos sistemas solo aplican la inmutabilidad una vez que el backup ya ha sido escrito, impiden el cifrado de extremo a extremo o permiten que cualquier usuario con privilegios elevados pueda realizar un restablecimiento de fábrica. Estas limitaciones crean ventanas de oportunidad que los atacantes pueden explotar. Disponer de backups con Inmutabilidad Absoluta significa que nadie, incluidos los administradores con privilegios, puede modificar o eliminar los datos una vez escritos.
No se trata únicamente de un requisito técnico, sino estructural. Los sistemas que dependen de accesos privilegiados para gestionar la inmutabilidad introducen un único punto de fallo. En un entorno comprometido, esto basta para hacer imposible la recuperación. Las organizaciones deberían apostar por arquitecturas de almacenamiento que impidan por diseño (y no solo mediante políticas) el acceso a acciones destructivas, y cuya seguridad pueda verificarse mediante pruebas independientes de terceros.
Cuando la complejidad se convierte en un multiplicador del riesgo
A medida que aumentan las exigencias regulatorias, también suele crecer la complejidad operativa. Las grandes organizaciones pueden absorber este impacto mediante equipos y herramientas especializadas, pero para muchas otras, añadir más sistemas, controles y procesos incrementa el riesgo de errores de configuración, brechas operativas y fallos.
Además, esta complejidad dificulta demostrar la resiliencia. Más herramientas implican más administración, más documentación y más recursos necesarios para realizar pruebas periódicas y auditables. La arquitectura de backup adecuada debería reducir esa carga: lo suficientemente sencilla para operar, lo suficientemente segura para resistir amenazas reales y lo suficientemente potente para soportar pruebas sin interrumpir las operaciones.
De la teoría a la práctica
El verdadero desafío ya no es únicamente cumplir con la normativa, sino demostrar que los procesos de recuperación pueden ofrecer restauraciones rápidas, resistir pruebas periódicas y auditables y mantener su rendimiento bajo presión. Porque, en última instancia, la resiliencia no se mide en auditorías, sino en la capacidad de recuperarse cuando todo falla.
Actualmente, muchas organizaciones siguen atrapadas en una paradoja: cuanto más intentan cumplir con las normativas, más complejas se vuelven y menos preparadas están para responder. Reducir la brecha entre lo que las organizaciones prometen en su documentación de compliance y lo que sus equipos y sistemas realmente pueden ofrecer bajo presión es, sin duda, el mayor desafío de la resiliencia en la era DORA.
Por Miguel Tena, Field Sales Engineer, Object First
«La capacidad de recuperación marca la diferencia entre un incidente controlado y una crisis que afecte a toda la organización. Este es un punto crítico que muchas empresas todavía subestiman» (Miguel Tena, Object First)




