Toda nube falla tarde o temprano. La pregunta que los reguladores hacen ahora no es si tu infraestructura puede evitar un fallo, sino si la diseñaste para sobrevivir a uno. DORA entró en aplicación el 17 de enero de 2025. NIS2 derogó su predecesora en octubre de 2024. Juntos, estos dos marcos convierten la arquitectura de resiliencia en la nube en una obligación legal para entidades financieras, operadores sanitarios, proveedores de energía e infraestructuras críticas en toda Europa. Las decisiones de ingeniería que tu equipo tome sobre el aislamiento de dominios de fallo y la arquitectura de recuperación son ahora elementos de cumplimiento a nivel de consejo de administración.

Este artículo aborda los principios estructurales del diseño tolerante a fallos en la nube, lo que las regulaciones exigen realmente a nivel técnico y dónde las empresas europeas reguladas cometen errores de forma sistemática.

Qué exigen realmente las regulaciones

El artículo 11 de DORA exige que toda entidad financiera establezca, mantenga y pruebe periódicamente una política de continuidad de negocio TIC. El artículo 12 amplía eso con planes de recuperación específicos que detallan cómo se reanudan las operaciones tras una interrupción TIC. De forma determinante, cada entidad debe definir sus propios objetivos de tiempo de recuperación y punto de recuperación, calibrados según un Análisis de Impacto en el Negocio. DORA no prescribe un umbral numérico universal: la obligación es que los objetivos existan, estén documentados, sean proporcionales a la criticidad de cada función y se prueben al menos anualmente, incluidos los escenarios de conmutación entre la infraestructura principal y la capacidad redundante.

El artículo 21(2)(c) de NIS2 exige que las entidades cubiertas implementen medidas que abarquen la continuidad de negocio, la gestión de copias de seguridad, la recuperación ante desastres y la gestión de crisis. Esa única frase se expande en más de 20 requisitos técnicos específicos en el Reglamento de Ejecución de la Comisión 2024/2690. ENISA publicó 170 páginas de orientación operativa en junio de 2025 traduciendo esos requisitos en prácticas respaldadas por evidencia. Uno de los mandatos más claros: las copias de seguridad de datos críticos deben mantenerse física y geográficamente separadas de los sistemas de producción, de modo que un desastre que afecte al sitio principal no destruya simultáneamente la capacidad de recuperación.

La resiliencia no es una opción de configuración. Es una propiedad arquitectónica, y debe diseñarse antes de que la primera carga de trabajo entre en producción, no incorporarse a posteriori cuando el primer informe de incidente llega al escritorio de un regulador.

Aislamiento de dominios de fallo: la base del diseño de infraestructura cloud regulada

El error más frecuente en el diseño de alta disponibilidad cloud en Europa es confundir redundancia con resiliencia. Ejecutar dos instancias del mismo servicio en la misma zona de disponibilidad, sobre el mismo clúster físico subyacente y con la misma ruta de red hacia internet es redundancia sobre el papel y un único punto de fallo en la práctica. El aislamiento de dominios de fallo significa separar las cargas de trabajo de modo que un fallo en un dominio no pueda propagarse a otro.

Hay tres capas donde esta separación importa en entornos regulados.

Dominios de fallo físicos

El cómputo, el almacenamiento y la red deben distribuirse entre instalaciones físicamente distintas con alimentación eléctrica, refrigeración y conectividad de upstream independientes. Para las entidades bajo el ámbito de DORA, esto significa que la infraestructura TIC principal y la redundante no pueden compartir un mismo edificio físico ni una misma alimentación eléctrica. Para las entidades bajo el ámbito de NIS2, las copias de seguridad geográficamente separadas son un requisito explícito, no una buena práctica. Aquí es donde los centros de datos carrier-neutral con rutas de upstream independientes tienen relevancia operativa, no solo en una lista de verificación de cumplimiento.

Operamos cuatro centros de datos de producción: MAD1 en Madrid, MUC1 en Múnich, HEL1 en Helsinki y AMS1 en Ámsterdam. Cada uno es carrier-neutral y está conectado a 44 puntos de presencia en Europa y Oriente Medio. Un cliente que ejecuta cargas de trabajo reguladas en MAD1 y MUC1 obtiene una separación geográfica de dominios de fallo real, con peering directo a AWS, Azure y GCP en ambos sitios, de modo que las rutas de recuperación híbridas y multi-cloud no introducen un nuevo punto único de fallo en la capa de interconexión.

Dominios de fallo de red

La contención del radio de explosión en la capa de red requiere más que VLANs. Las cargas de trabajo reguladas necesitan segmentación de red que imponga límites de política entre entornos: los planos de producción, DR, backup y gestión no deben compartir dominios de enrutamiento. El tráfico este-oeste entre dominios de fallo debe atravesar puntos de control específicos, sin depender de la confianza implícita dentro de un tejido de red compartido. En la práctica, esto significa diseñar la topología de red antes de desplegar, no añadir grupos de seguridad de forma reactiva tras un hallazgo de auditoría.

Dominios de fallo de datos

Los objetivos de punto de recuperación solo son significativos si tu arquitectura de backup los hace cumplir. La replicación síncrona entre dominios de fallo ofrece un RPO casi nulo, pero añade latencia a cada escritura. La replicación asíncrona con un retardo definido proporciona un RPO predecible a menor coste, pero exige documentar honestamente qué pérdida de datos es aceptable para cada clase de función. El BIA que exige DORA no es un ejercicio de papeleo: es el documento que justifica qué funciones requieren replicación síncrona y cuáles toleran un retardo de 15 minutos.

Las pruebas son la obligación que la mayoría de los equipos subestima

Tanto DORA como NIS2 tratan los planes de continuidad no probados como planes no conformes. El artículo 11 de DORA exige explícitamente escenarios de conmutación entre infraestructura principal y redundante como parte de las pruebas anuales. El manual de ENISA de junio de 2025 para pruebas de estrés cibernético proporciona la metodología para simulaciones de incidentes a gran escala, incluidos escenarios transfronterizos, como estándar esperado para las entidades cubiertas por NIS2.

En la práctica, esto significa que tus runbooks deben poder ejecutarse bajo presión por alguien que no los escribió. Los procedimientos de recuperación que solo existen en la cabeza del ingeniero que diseñó el sistema no son procedimientos: son conocimiento tribal con fecha de caducidad. La cadencia de pruebas que exige DORA también implica que tu infraestructura debe soportar pruebas de failover no destructivas sin interrumpir la producción, lo cual tiene implicaciones directas en cómo arquitecturas tu entorno de DR desde el primer día.

La designación CTPP y lo que implica para la dependencia cloud

En noviembre de 2025, 19 proveedores fueron designados como Proveedores Terceros de TIC Críticos bajo DORA, la primera lista oficial bajo la regulación. Todos los grandes hyperscalers habían publicado sus adendas DORA antes de esa designación. Lo que la designación implica en la práctica es que estos proveedores se enfrentan ahora a exámenes coordinados por Equipos de Examen Conjunto, y sus obligaciones de continuidad de negocio, incluidos los objetivos de RTO y RPO para los servicios que prestan, están sujetas a supervisión directa a nivel de la UE.

Para las entidades financieras, esto es relevante en dos sentidos. Eleva el listón de lo que los hyperscalers deben documentar y demostrar. Pero también significa que el riesgo de concentración, ejecutar funciones críticas exclusivamente en un único CTPP designado, es ahora un factor de riesgo documentado que los supervisores examinarán. Distribuir cargas de trabajo entre un proveedor de infraestructura soberana europea y despliegues en hyperscalers no es solo un argumento de soberanía: es una mitigación del riesgo de concentración que debe formar parte de tu marco de riesgo DORA.

Cómo es realmente una arquitectura resiliente

No existe un único plano, porque los objetivos de RTO y RPO son específicos de cada función y están determinados por el BIA. Pero las propiedades estructurales de un diseño cloud tolerante a fallos y conforme a la normativa son consistentes en todos los sectores regulados:

  • Separación geográfica entre los sitios principal y de recuperación, con infraestructura física independiente en cada uno.
  • Conectividad de upstream independiente en cada sitio, carrier-neutral, de modo que el fallo de un único ISP no aísle ambos entornos.
  • Segmentación de red aplicada en la capa de enrutamiento, no solo en la capa de firewall, con planos de gestión separados para producción y DR.
  • Estrategia de replicación por niveles que asigna replicación síncrona o asíncrona según el RPO definido para cada clase de función en el BIA.
  • Failover automatizado con anulación manual: la automatización reduce el tiempo de recuperación, pero los reguladores esperan puntos de decisión humana en el proceso para funciones críticas.
  • Runbooks probados con evidencia documentada de los ejercicios de conmutación anuales, almacenados de forma separada de los sistemas que describen.
  • Aislamiento de backups aplicado a nivel de infraestructura, no solo de política, de modo que un evento de ransomware que afecte a producción no pueda alcanzar el almacenamiento de copias de seguridad.

La arquitectura que satisface el artículo 11 de DORA, el artículo 21 de NIS2 y el modelo de amenazas de un equipo de seguridad competente no es exótica. Es ingeniería disciplinada aplicada de forma consistente, en cada capa, antes de que la primera carga de trabajo entre en producción. El coste de incorporarla a posteriori tras un incidente, o tras una revisión supervisora, es sistemáticamente mayor que construirla correctamente desde el principio.