Durante gran parte de la última década, la recuperación ante desastres ocupó la columna de «sería deseable» en los presupuestos de infraestructura. Los reguladores han puesto fin a esa era. Las entidades financieras sujetas a DORA, los operadores sanitarios bajo NIS2 y los proveedores de energía regidos por marcos sectoriales específicos se enfrentan ahora a umbrales de recuperación definidos legalmente. Incumplirlos transforma la conversación: deja de ser un informe de incidente y pasa a ser una acción sancionadora.

Este artículo traza el panorama normativo, explica qué exigen realmente RTO y RPO a nivel de infraestructura y analiza por qué la geografía de tu proveedor cloud no es un factor secundario.

Qué significan RTO y RPO cuando los definen los reguladores

El Recovery Time Objective (RTO) es la duración máxima aceptable entre una interrupción del servicio y su restauración completa. El Recovery Point Objective (RPO) es la pérdida de datos máxima aceptable medida en tiempo: hasta qué punto puede retrotraerse el último punto de restauración limpio. Ambos son objetivos de ingeniería, pero bajo DORA y NIS2 se convierten en compromisos contractuales y regulatorios.

DORA, aplicable a las entidades financieras y sus proveedores TIC terceros críticos en toda la UE desde enero de 2025, exige que las empresas establezcan objetivos explícitos de RTO y RPO para cada función crítica, los prueben periódicamente y demuestren que su infraestructura cloud puede cumplirlos en la práctica. Las directrices de la Autoridad Bancaria Europea dejan claro que «mejores esfuerzos» no equivale a un objetivo documentado.

Un objetivo de recuperación que solo existe en un documento Word no es un objetivo de recuperación. Es un pasivo.

NIS2 extiende una lógica similar a las entidades esenciales e importantes en sectores como energía, transporte, agua, sanidad e infraestructura digital. Los estados miembros están transponiendo NIS2 al derecho nacional con calendarios distintos, pero la obligación central es coherente: las entidades deben implementar medidas técnicas y organizativas para gestionar incidentes, y esas medidas deben incluir procedimientos de copia de seguridad y recuperación probados, con objetivos definidos.

Obligaciones sectoriales que conviene conocer

Servicios financieros y DORA

Los requisitos de continuidad de negocio de DORA van más allá de los calendarios de copia de seguridad. El artículo 12 exige que las entidades financieras dispongan de políticas de continuidad de negocio TIC que cubran RTO y RPO para las funciones críticas o importantes, con escenarios de recuperación probados al menos una vez al año. De forma relevante, el reglamento exige que las capacidades de recuperación se validen frente a escenarios de interrupción realistas, no solo frente a ventanas de mantenimiento planificadas.

Para las cargas de trabajo alojadas en la nube, esto significa que la arquitectura de tu proveedor debe permitir la conmutación por error dentro del RTO definido. Si el RTO de una función de core bancario es de cuatro horas, un proveedor cloud que replica datos de forma asíncrona a un único sitio secundario en otro continente no puede cumplir ese objetivo de forma fiable, y la pista de auditoría lo reflejará.

Sanidad bajo NIS2 y marcos nacionales

Los operadores sanitarios afrontan una doble obligación: los requisitos de referencia de NIS2 más las normas sectoriales específicas de cada estado miembro. El marco del BSI alemán, las directrices de la ANSSI francesa y la norma neerlandesa NEN 7510 añaden especificidad adicional sobre la base de NIS2. El hilo conductor es que los sistemas de datos de pacientes deben contar con rutas de recuperación probadas, y los datos de copia de seguridad deben permanecer en jurisdicciones donde sea aplicable la legislación de protección de datos.

Energía e infraestructura crítica

Los operadores energéticos clasificados como entidades esenciales bajo NIS2 afrontan algunos de los plazos de notificación de incidentes más estrictos del reglamento: notificación inicial en un plazo de 24 horas desde que se tenga conocimiento de un incidente significativo, con informe completo posterior. Ese contador convierte la velocidad de recuperación en un factor de cumplimiento, no en una mera preferencia operativa. Los entornos de tecnología operacional (OT) en el sector energético añaden complejidad adicional, ya que los sistemas OT a menudo no toleran la latencia ni las rutas de red que aceptan las cargas de trabajo TI.

Por qué la geografía cloud determina tu postura de cumplimiento

Schrems II eliminó la base jurídica para transferir datos personales a Estados Unidos al amparo del marco Privacy Shield. Su sucesor, el Marco de Privacidad de Datos UE-EE. UU., enfrenta impugnaciones legales en curso, y la tensión subyacente, que la legislación de vigilancia estadounidense puede obligar a acceder a datos en manos de entidades de propiedad estadounidense independientemente de dónde se encuentren los servidores, no ha quedado resuelta por ningún acuerdo marco.

En el caso concreto de la recuperación ante desastres, esto genera un problema tangible. Si tu carga de trabajo principal se ejecuta en una región europea de un hiperescalador estadounidense y tu réplica de recuperación ante desastres también corre sobre la infraestructura de ese proveedor, ambas copias quedan dentro del alcance legal de la legislación estadounidense. Un evento de recuperación que fuerce la conmutación al sitio de DR no cambia esa exposición; puede concentrarla.

Una infraestructura cloud europea, propiedad de una entidad jurídica europea y operada por ella, sujeta exclusivamente al derecho europeo, cierra esa brecha. Los datos de copia de seguridad, el tráfico de replicación y los entornos de conmutación por error permanecen dentro de una jurisdicción donde se aplica el RGPD y donde ningún gobierno extranjero dispone de una vía legal para exigir acceso.

Diseño de una arquitectura cloud de recuperación ante desastres conforme a la normativa

Topología de replicación

La replicación síncrona entre sitios elimina el RPO a costa de latencia; es adecuada para bases de datos y registros de transacciones donde cualquier pérdida de datos es inaceptable. La replicación asíncrona tolera una pequeña ventana de RPO (habitualmente segundos o minutos) a cambio de menor latencia en las escrituras. La mayoría de las cargas de trabajo reguladas utilizan un enfoque por niveles: replicación síncrona para los datos más críticos, asíncrona para los sistemas secundarios y copia de seguridad en frío para datos de archivo.

La infraestructura europea multisitio es relevante aquí porque la latencia de replicación depende de la distancia física y la ruta de red. Dos sitios dentro de la misma región europea pueden mantener replicación síncrona para la mayoría de las cargas de trabajo de bases de datos. Dos sitios separados por un océano no pueden.

Cadencia de pruebas y evidencia

DORA exige pruebas anuales como mínimo, con mayor frecuencia para las funciones críticas. NIS2 no especifica una cadencia, pero requiere que las medidas sean «probadas y revisadas periódicamente». Ambos marcos exigen evidencia documentada: planes de prueba, resultados, deficiencias identificadas y acciones correctoras. Una prueba de recuperación que no deja rastro de auditoría tiene un valor regulatorio limitado.

Las pruebas de conmutación por error automatizadas, en las que las cargas de trabajo se transfieren periódicamente al sitio de DR en una ventana controlada y luego se revierten, generan la evidencia más sólida porque prueban la ruta de infraestructura real en lugar de una simulada. Las pruebas basadas únicamente en runbooks indican si la documentación está actualizada, pero no si la infraestructura se comportará como se documenta bajo carga.

Objetivos de RTO por nivel de carga de trabajo

  • Nivel 1 (crítico, regulado): RTO inferior a 4 horas, RPO inferior a 15 minutos. Requiere replicación síncrona o casi síncrona, conmutación por error automatizada y capacidad de reserva precalentada.
  • Nivel 2 (importante, crítico para el negocio): RTO de 4 a 24 horas, RPO inferior a 1 hora. Replicación asíncrona con procedimientos de conmutación por error con scripts.
  • Nivel 3 (estándar): RTO de 24 a 72 horas, RPO inferior a 24 horas. Copia de seguridad programada con ruta de recuperación desde copia de seguridad.

Clasificar las cargas de trabajo por niveles antes de diseñar la arquitectura evita sobredimensionar los sistemas de baja criticidad y, más importante, evita subdimensionar los que los reguladores examinarán primero.

El cumplimiento es el suelo, no el techo

Cumplir los requisitos de RTO y RPO de DORA, satisfacer las obligaciones de respuesta a incidentes de NIS2 y mantener los datos de copia de seguridad dentro de la jurisdicción legal europea son requisitos de referencia para los sectores regulados. Son también, cuando la arquitectura está bien diseñada, las condiciones bajo las cuales un evento de recuperación se convierte en una respuesta operativa gestionada en lugar de una crisis.

Las decisiones de infraestructura que satisfacen a los reguladores, replicación multisitio dentro de Europa, rutas de conmutación por error probadas, objetivos de recuperación documentados y residencia de datos jurídicamente inequívoca, son las mismas que hacen que la recuperación sea fiable. Esa alineación no es casual. La infraestructura cloud europea construida para la soberanía está construida exactamente para este tipo de responsabilidad.