Gobernanza de regiones en la nube para el RGPD de la UE, NIS2 y DORA

A las 08:17 de un martes por la mañana, María, CISO de una fintech europea en rápido crecimiento, recibe el mensaje que todo cliente regulado de servicios en la nube acaba temiendo.

El equipo de compras reenvía una breve notificación del proveedor:

“Nuestro proveedor de analítica en la nube está trasladando la telemetría de clientes de la UE a una nueva región por motivos de rendimiento. Indican que no hay impacto en la seguridad. ¿Podemos aprobarlo?”

Antes de que María pueda responder, llega una segunda notificación del proveedor principal de servicios en la nube. En 90 días, el proveedor “optimizará su modelo global de soporte” mediante el enrutamiento de tickets de soporte de nivel 2 a través de un nuevo subencargado. Una revisión rápida muestra que el subencargado tiene su sede en un país sin decisión de adecuación conforme al RGPD de la UE.

A las 09:00, legal, privacidad, resiliencia, compras, ingeniería de nube y cumplimiento financiero ya están en el hilo. El DPO pregunta si se necesita una evaluación de impacto de transferencia. El responsable de resiliencia pregunta si la nueva región afecta al plan de recuperación de un servicio crítico. El responsable de cumplimiento financiero pregunta si el proveedor aparece en el registro de terceros TIC de DORA. El equipo de nube revisa el plano de datos de producción y constata que el problema va mucho más allá de la analítica. Las copias de seguridad, los registros operativos, los tickets de soporte, las exportaciones al lago de datos, el acceso de emergencia con privilegios y el acceso de subcontratistas pueden estar todos dentro del alcance.

Este es el verdadero problema de gobernanza de la nube en 2026.

La mayoría de las organizaciones tienen una política de uso de la nube. Muchas tienen un registro de proveedores. Algunas tienen una evaluación de transferencias del RGPD de la UE. Menos organizaciones pueden responder, con evidencias, a la pregunta de auditoría más difícil:

¿Dónde residen exactamente los datos regulados y el tratamiento TIC crítico, quién puede acceder desde dónde, qué ocurre durante una conmutación por error y qué control contractual impide que el proveedor cambie la respuesta sin aprobación?

Eso es la gobernanza de regiones en la nube. No es una casilla legal aislada. Es un sistema de control vivo que atraviesa ISO/IEC 27001:2022, los controles de nube y proveedores de ISO/IEC 27002:2022, la responsabilidad proactiva del RGPD de la UE, la resiliencia de servicios de NIS2 y la supervisión de terceros TIC de DORA.

La residencia de los datos ya es un control operativo

Durante años, el “alojamiento solo en la UE” se trató como una cláusula en un contrato de encargo del tratamiento. Eso ya no basta. Un programa moderno de residencia de datos en la nube y gobernanza de regiones debe cubrir, como mínimo, seis capas operativas:

1. Regiones principales de almacenamiento y computación de producción.
2. Regiones de copias de seguridad, archivo y recuperación ante desastres.
3. Ubicaciones de datos de registro, supervisión, SIEM y observabilidad.
4. Acceso de soporte, incluida la administración remota y el acceso de emergencia con privilegios.
5. Subencargados y subcontratistas, incluidos servicios gestionados y componentes de marketplace.
6. Rutas de transferencia de datos entre entornos, interfaces de programación de aplicaciones, plataformas de analítica y herramientas de soporte al cliente.

El RGPD de la UE hace que esto sea inevitable porque los datos personales pueden incluir identificadores en línea, direcciones IP, identificadores de cuentas de clientes, registros de usuarios, identificadores de dispositivos, metadatos operativos y registros de soporte. El tratamiento también se define de forma amplia e incluye almacenamiento, acceso, uso, comunicación, supresión y destrucción. “Solo enviamos registros” no es una excepción segura si esos registros contienen identificadores.

El Article 5 del RGPD de la UE también incluye el principio de responsabilidad proactiva. Los responsables del tratamiento no solo deben cumplir los principios de licitud, lealtad, transparencia, limitación de la finalidad, minimización de datos, limitación del plazo de conservación, integridad y confidencialidad. También deben poder demostrar el cumplimiento. La gobernanza de regiones en la nube es una de las formas en que esa demostración se vuelve operativa.

NIS2 amplía el problema desde la privacidad hacia la resiliencia. Conforme al Article 21, las entidades esenciales e importantes deben implantar medidas técnicas, operativas y organizativas adecuadas para gestionar los riesgos que afectan a los sistemas de redes y de información utilizados para las operaciones o la prestación de servicios. Las medidas enumeradas incluyen seguridad de la cadena de suministro, continuidad de negocio, gestión de copias de seguridad, recuperación ante desastres, gestión de crisis, control de acceso, gestión de activos, cifrado y evaluación de la eficacia. Si una decisión sobre una región en la nube afecta a la disponibilidad o la recuperación de un servicio dentro del alcance, no es solo una cuestión de protección de datos. Es una cuestión de resiliencia.

Para las entidades financieras, DORA eleva aún más el estándar. DORA es aplicable desde el 17 de enero de 2025 y establece requisitos de gestión del riesgo TIC, notificación de incidentes, pruebas de resiliencia operativa digital, gestión del riesgo de terceros TIC y acuerdos contractuales. El Article 28 exige que las entidades financieras gestionen el riesgo de terceros TIC como parte integrante del marco de gestión del riesgo TIC, mantengan registros de acuerdos contractuales, evalúen el riesgo de concentración y planifiquen salidas para funciones críticas o importantes. El Article 30 espera claridad contractual sobre las ubicaciones de los servicios y del tratamiento de datos, derechos de auditoría y acceso, soporte ante incidentes, subcontratación, recuperación, devolución y transición de salida.

DORA actúa como régimen sectorial específico para entidades financieras, mientras que NIS2 sigue siendo relevante en la cadena de suministro más amplia, especialmente para proveedores de servicios de computación en la nube, proveedores de centros de datos y proveedores de servicios gestionados. Por tanto, un único subencargado no evaluado puede provocar un efecto dominó sobre la resiliencia financiera, la seguridad de la cadena de suministro y las obligaciones de privacidad.

En términos sencillos, si una organización regulada no puede gobernar dónde se produce su tratamiento en la nube, no puede gobernar de forma creíble el riesgo de terceros TIC.

Usar ISO 27001 como ancla del sistema de gestión

ISO/IEC 27001:2022 proporciona la estructura para convertir la confusión sobre la residencia en un sistema de gestión controlado.

Las cláusulas 4.1 a 4.4 exigen que la organización defina el SGSI en su contexto, incluidos factores internos y externos, requisitos de las partes interesadas, obligaciones legales, regulatorias y contractuales, interfaces y dependencias con otras organizaciones. Para la gobernanza de regiones en la nube, el alcance del SGSI debe incluir explícitamente servicios en la nube, tratamiento TIC externalizado, dependencias de servicios críticos y flujos de datos regulados.

Las cláusulas 5.1 a 5.3 hacen responsable al liderazgo. La alta dirección debe alinear la política y los objetivos de seguridad de la información con la dirección estratégica, proporcionar recursos, asignar responsabilidades y asegurarse de que se informe sobre el desempeño del SGSI. Aquí es donde la residencia en la nube se convierte en un asunto de dirección y consejo, especialmente para entidades NIS2 cuyos órganos de dirección deben aprobar y supervisar medidas de gestión de riesgos de ciberseguridad, y para entidades financieras DORA en las que el órgano de dirección es responsable de la gobernanza del riesgo TIC.

Las cláusulas 6.1.1 a 6.1.3 proporcionan el motor de riesgo. La organización necesita un proceso repetible de evaluación de riesgos, propietarios del riesgo, criterios de impacto y probabilidad, opciones de tratamiento, controles seleccionados, una Declaración de Aplicabilidad y aceptación del riesgo residual. Un cambio de región en la nube no debe aprobarse mediante un correo informal. Debe desencadenar una evaluación de riesgos o una revisión de cambios cuando afecte a datos regulados, funciones críticas, proveedores o supuestos de continuidad.

La cláusula 8.1 convierte la planificación en control operativo. Los procesos deben implantarse, controlarse, documentarse, modificarse de forma gestionada y extenderse a los productos y servicios suministrados externamente que sean relevantes para el SGSI. Las cláusulas 8.2 y 8.3 exigen reevaluación y tratamiento a intervalos planificados o cuando se produzcan cambios significativos. La migración de una región en la nube, la replicación de copias de seguridad, una nueva plataforma de registro o el cambio de un subencargado de soporte son todos candidatos a reevaluación.

El conjunto de controles de ISO/IEC 27002:2022 proporciona después la familia práctica de controles. Los controles más relevantes incluyen:

• 5.9 Inventario de información y otros activos asociados.
• 5.14 Transferencia de información.
• 5.15 Control de acceso.
• 5.19 Seguridad de la información en las relaciones con proveedores.
• 5.20 Tratamiento de la seguridad de la información en los acuerdos con proveedores.
• 5.22 Supervisión, revisión y gestión de cambios de los servicios de proveedores.
• 5.23 Seguridad de la información para el uso de servicios en la nube.
• 5.29 Seguridad de la información durante interrupciones.
• 5.30 Preparación de las TIC para la continuidad de negocio.
• 5.31 Requisitos legales, estatutarios, regulatorios y contractuales.
• 5.34 Privacidad y protección de información de identificación personal (PII).
• 5.36 Cumplimiento de políticas, reglas y normas de seguridad de la información.
• 8.11 Enmascaramiento de datos.
• 8.12 Prevención de fuga de datos.
• 8.13 Copia de seguridad de la información.
• 8.15 Registro de eventos.
• 8.16 Actividades de supervisión.
• 8.20 Seguridad de redes.
• 8.24 Uso de criptografía.
• 8.25 Ciclo de vida de desarrollo seguro.
• 8.27 Arquitectura segura de sistemas y principios de ingeniería.
• 8.32 Gestión de cambios.

Zenith Controls: The Cross-Compliance Guide de Clarysec Zenith Controls trata el control 5.23 de ISO/IEC 27002:2022, Seguridad de la información para el uso de servicios en la nube, como un control preventivo que respalda la confidencialidad, la integridad y la disponibilidad, con capacidad operativa en seguridad de las relaciones con proveedores y en los dominios de seguridad de gobernanza, ecosistema y protección. La guía vincula 5.23 con 5.19 relaciones con proveedores, 5.14 transferencia de información, 5.9 inventario de activos, 8.11 y 8.12 enmascaramiento de datos y prevención de fuga de datos, 8.20 seguridad de redes y 8.25 ciclo de vida de desarrollo seguro.

Una observación clave de Zenith Controls es:

“Los proveedores de servicios en la nube (CSP) funcionan como proveedores críticos y, por tanto, se aplican todos los controles relativos a selección de proveedores, contratación y gestión del riesgo conforme a 5.19. Sin embargo, 5.23 va más allá al abordar riesgos específicos de la nube, como la multitenencia, la transparencia de la ubicación de los datos y los modelos de responsabilidad compartida.”

Esa frase recoge el cambio de gobernanza. Un proveedor de nube no es un proveedor más. A menudo es el lugar donde reside el tratamiento regulado.

Las trampas ocultas de la residencia: copias de seguridad, registros, soporte y subencargados

La mayoría de los fallos de residencia de datos no empiezan en la base de datos de producción. Empiezan en sistemas de apoyo que nunca se incluyeron adecuadamente en la revisión del flujo de datos.

Las copias de seguridad son el ejemplo clásico. Una plataforma SaaS puede ejecutarse en Frankfurt o Dublín, mientras que las copias de seguridad automatizadas se replican en otro lugar por motivos de resiliencia o coste. Si la copia de seguridad contiene datos personales, registros de clientes, registros de autenticación o historial de transacciones reguladas, la región de copia de seguridad importa. Conforme al Article 21 de NIS2, la gestión de copias de seguridad y la recuperación ante desastres forman parte de la configuración de referencia de seguridad. Conforme a DORA, la continuidad de funciones críticas o importantes y las estrategias de salida probadas exigen conocer las ubicaciones de recuperación y las dependencias de recuperación.

Los registros son otro punto débil. Los equipos de seguridad centralizan la telemetría en servicios SIEM, de observabilidad y de lago de datos. Esos registros pueden incluir direcciones IP, identificadores de usuario, acciones de administradores, metadatos de pago, intentos de autenticación fallidos, identificadores de cuentas de clientes o datos de traza de soporte. Si los registros pasan a un servicio global de supervisión, la organización puede haber creado una transferencia transfronteriza sin advertirlo.

La Política de registro y supervisión para pymes de Clarysec Logging and Monitoring Policy - SME aborda directamente las evidencias de proveedores:

“Los contratos deben exigir a los proveedores conservar los registros durante al menos 12 meses y proporcionar acceso previa solicitud”

Esta cita procede de la sección “Requisitos de gobernanza”, cláusula de política 5.5.1.3. Para la gobernanza de residencia de datos, la misma revisión contractual debe confirmar dónde se conservan esos registros, quién puede acceder a ellos y si las evidencias de registro están disponibles durante una investigación de incidente o un requerimiento regulatorio.

El acceso de soporte es más sutil. Un proveedor puede alojar datos en la UE, mientras que ingenieros de soporte fuera de la UE pueden acceder a entornos de clientes, instantáneas de bases de datos, paquetes de diagnóstico o adjuntos de tickets. Que esto sea aceptable depende de los datos implicados, el mecanismo de transferencia, el rol, las salvaguardas contractuales, los controles de acceso y el registro de eventos. La arquitectura puede ser regional, mientras que el modelo de acceso humano es global.

Los subencargados crean el último punto ciego. Tu proveedor directo puede depender de infraestructura en la nube, redes de distribución de contenido, bases de datos gestionadas, plataformas de tickets, servicios de analítica, equipos de soporte offshore o proveedores de seguridad. El Article 29 de DORA exige evaluar los riesgos de subcontratación, los proveedores de terceros países, las restricciones de recuperación de datos, el cumplimiento en materia de protección de datos y las cadenas de subcontratación complejas. El Article 21 de NIS2 exige que las entidades consideren las prácticas de ciberseguridad de los proveedores directos y proveedores de servicios. El RGPD de la UE exige que los encargados gestionen los subencargados de forma que se preserve la capacidad del responsable del tratamiento para cumplir.

La Política de seguridad de terceros y proveedores para pymes de Clarysec Third-Party and Supplier Security Policy - SME lo convierte en algo práctico:

“Cuando los proveedores deban almacenar datos fuera de las instalaciones, la empresa debe obtener garantías sobre protección de datos, seguridad física y ubicación geográfica del almacenamiento (por ejemplo, alojamiento solo en la UE cuando lo exija el RGPD de la UE).”

Esto procede de la sección “Requisitos de implantación de la política”, cláusula de política 6.2.4. La misma política también exige:

“Restricciones a la subcontratación adicional sin aprobación”

Esta cita procede de la sección “Requisitos de gobernanza”, cláusula de política 5.3.5. En conjunto, estas cláusulas convierten la residencia en un flujo de trabajo de gestión de proveedores, no en una preferencia de compras.

Convertir la política en gobernanza exigible de regiones en la nube

La gobernanza de regiones en la nube debe ser exigible, revisable y auditable.

Para pymes, la Política de uso de la nube para pymes Cloud Usage Policy - SME establece la base:

“Las prácticas de residencia de datos y privacidad cumplen los requisitos legales aplicables (por ejemplo, RGPD de la UE)”

Esto procede de la sección “Requisitos de gobernanza”, cláusula de política 5.2.3. La misma política exige que los registros de gobernanza de la nube incluyan:

“El país o la región donde se almacenan los datos”

Esta cita procede de la sección “Requisitos de gobernanza”, cláusula de política 5.3.4.

Para organizaciones de mayor tamaño, la Política de uso de la nube Cloud Usage Policy es más explícita sobre la exigibilidad contractual:

“Los requisitos de residencia de datos deben hacerse exigibles contractualmente (por ejemplo, almacenamiento solo en la UE para datos regulados por el RGPD de la UE).”

Esto procede de la sección “Requisitos de implantación de la política”, cláusula de política 6.6.2. También establece:

“Las transferencias transfronterizas de datos deben cumplir el capítulo V del RGPD de la UE y, cuando proceda, el Article 28 de DORA.”

Esto procede de la sección “Requisitos de implantación de la política”, cláusula de política 6.6.3.

La versión empresarial también presta atención a:

“Garantías de residencia de datos y titularidad de los datos”

Esta cita procede de la sección “Funciones y responsabilidades”, cláusula de política 4.5.1.2.

La Política de seguridad de terceros y proveedores Third party and supplier security policy añade la capa contractual al exigir:

“Requisitos de manejo de datos, incluida la ubicación del almacenamiento, los controles de acceso y las cláusulas de devolución o destrucción”

Esta cita procede de la sección “Requisitos de gobernanza”, cláusula de política 5.3.2.

Por último, la Política de cumplimiento legal y normativo Legal and Regulatory Compliance Policy identifica cambios que deben desencadenar una revisión de cumplimiento, incluidos:

“Cambios en los mecanismos de transferencia de datos, subencargados o flujos transfronterizos de datos”

Esto procede de la sección “Requisitos de gobernanza”, cláusula de política 5.3.1.1.

Estos documentos no deben funcionar como archivos separados. En un SGSI maduro, se convierten en un único modelo operativo: inventario de nube, registro de flujos de datos, registro de proveedores, matriz contractual, evaluación de riesgos, revisión de transferencias, aprobación de cambios y paquete de evidencias de auditoría.

Construir un registro de gobernanza de regiones en la nube

Un registro práctico convierte la residencia en la nube de una suposición en evidencia. Empieza con un servicio crítico orientado al cliente, especialmente uno que probablemente esté dentro del alcance de NIS2, de la diligencia debida de clientes DORA o del escrutinio del RGPD de la UE.

Conecta ahora el registro con la implantación.

En Zenith Blueprint: hoja de ruta de 30 pasos para auditores de Clarysec Zenith Blueprint, la fase Controles en acción, paso 23, se centra en los controles organizativos 5.19 a 5.37, incluidos los acuerdos con proveedores y la gobernanza de servicios en la nube. El Blueprint advierte que los acuerdos con proveedores deben cubrir algo más que la confidencialidad genérica:

“En muchos sectores, los acuerdos con proveedores también definen la titularidad de los datos y la jurisdicción. ¿Dónde se tratan los datos? ¿Quién conserva el control? ¿Existen restricciones de transferencia? ¿Hay controles específicos de la nube, como segmentación de datos, titularidad de claves o limitaciones geográficas? Estos elementos no son solo legales; son cuestiones operativas de seguridad, especialmente en sectores regulados.”

La misma fase y el mismo paso abordan la gestión de cambios de proveedores:

“La mayoría de las relaciones con proveedores empiezan con buenas intenciones. Una revisión exhaustiva, expectativas claras, acuerdos firmados (véase 5.20), quizá incluso una lista de verificación de seguridad. Pero ¿qué ocurre un año después, cuando el proveedor propone trasladar tus datos a una nueva región en la nube?”

Ese es el problema del martes por la mañana de María. El registro ofrece al CISO una forma de responder antes de aprobar el traslado.

Zenith Blueprint también aclara el significado de gobernanza del control de nube 5.23:

“Un bucket de almacenamiento mal configurado, un panel expuesto públicamente o permisos excesivos en una configuración de IAM en la nube no son fallos de la nube. Son fallos de gobernanza.”

En la fase Controles en acción, paso 22, el Blueprint aborda la transferencia de información y afirma:

“Si se transfieren datos personales a través de fronteras, el método debe cumplir las obligaciones de privacidad y legales, no solo las preferencias internas.”

Esa línea importa a los equipos de nube. El cifrado, las interfaces de programación de aplicaciones seguras y la conectividad privada son necesarios, pero no sustituyen la gobernanza legal y regulatoria de las transferencias.

Ejecutar el primer taller de evidencias de 90 minutos

No empieces mapeando toda la organización. Empieza con un servicio crítico y ejecuta un taller focalizado con ingeniería de nube, compras, legal, privacidad, resiliencia y operaciones de seguridad.

Primero, enumera todos los componentes en la nube o de proveedor que almacenan, tratan, transmiten, respaldan, supervisan o dan soporte al servicio. Incluye sistemas menores, como supervisión de disponibilidad, adjuntos de tickets, seguimiento de errores, herramientas de compartición de pantalla para soporte y exportaciones de diagnóstico.

Segundo, marca cada categoría de datos. Si el equipo dice “solo metadatos”, cuestiona la suposición. Los metadatos también pueden ser datos personales o datos confidenciales de clientes.

Tercero, verifica la región con evidencias. Utiliza la configuración de la consola de nube, políticas de copia de seguridad, ajustes de tenancy de SIEM, anexos del DPA, listas de subencargados, condiciones contractuales, documentación de acceso de soporte e informes de auditoría del CSP. No te bases solo en garantías comerciales.

Cuarto, registra las brechas en el registro de riesgos del SGSI. Algunos ejemplos son “región de replicación de copias de seguridad no restringida contractualmente”, “acceso de soporte desde tercer país sin flujo de aprobación documentado”, “registros SIEM conservados globalmente”, “la lista de subencargados no identifica la región de alojamiento” o “el registro DORA no distingue la dependencia de una función crítica o importante”.

Quinto, decide el tratamiento. Los tratamientos pueden incluir modificación contractual, bloqueo de región, notificación al cliente, cifrado con claves gestionadas por el cliente, tokenización, minimización de registros, aprobación de un nuevo proveedor, actualización de la estrategia de salida o aceptación del riesgo residual por parte del propietario del riesgo.

Sexto, conserva las evidencias. Los auditores no solo preguntarán qué decidiste. Preguntarán cómo sabes que se implantó.

Mapear un conjunto de evidencias a ISO, el RGPD de la UE, NIS2, DORA y NIST CSF 2.0

Un programa sólido de gobernanza de regiones en la nube evita duplicar trabajo de cumplimiento. La misma evidencia puede respaldar múltiples obligaciones si se estructura correctamente.

NIST CSF 2.0 es útil como capa de integración. Su función GOVERN se alinea con obligaciones legales, regulatorias, contractuales y de privacidad, apetito de riesgo, responsabilidad proactiva, políticas y supervisión. Su categoría GV.SC de cadena de suministro encaja bien con las expectativas de terceros TIC de DORA, los requisitos de cadena de suministro de NIS2 y los controles de proveedores de ISO.

COBIT 2019 y una perspectiva de auditoría ISACA suelen probar los mismos hechos a través de objetivos de gobernanza: titularidad, derechos de decisión, optimización del riesgo, desempeño de proveedores, realización de beneficios y aseguramiento. Un revisor con enfoque COBIT puede no empezar preguntando “¿qué región en la nube está configurada?” Puede empezar por “¿quién tiene autoridad para aprobar un cambio de región, cómo se escala el riesgo y cómo sabe la dirección que los proveedores de nube permanecen dentro de la tolerancia?”

Por eso el modelo de Clarysec captura propietarios, puntos de aprobación, evidencias contractuales e informes a la dirección, no solo ajustes técnicos.

Prepararse para las preguntas del auditor

La gobernanza de regiones en la nube es un ejemplo perfecto de cómo distintos auditores observan el mismo control desde ángulos diferentes.

Un auditor de ISO/IEC 27001:2022 empezará por el alcance, los requisitos de las partes interesadas, la evaluación de riesgos y la Declaración de Aplicabilidad. Preguntará si se han identificado los requisitos legales, regulatorios y contractuales, si se incluyen controles de nube y de proveedores, si se evaluaron los riesgos, si los controles están implantados y si se conservan evidencias. Puede muestrear un servicio en la nube y solicitar la revisión de incorporación, cláusulas contractuales, configuración de región, revisión de supervisión y aprobación de cambios.

Una autoridad de protección de datos o un revisor del RGPD de la UE se centrará en los datos personales. Preguntará qué datos personales se tratan, dónde se almacenan, desde dónde se accede, qué encargados y subencargados intervienen, si los mecanismos de transferencia están documentados, si se necesita una evaluación de impacto de transferencia y si existen medidas técnicas y organizativas adecuadas. Los registros, los datos de soporte y las copias de seguridad suelen recibir atención porque las organizaciones los subestiman.

Un auditor NIS2 o una autoridad competente se centrará en los servicios dentro del alcance. Revisará la responsabilidad de la dirección conforme al Article 20, las medidas de gestión de riesgos conforme al Article 21, la continuidad, la gestión de copias de seguridad, la recuperación ante desastres, la gestión de incidentes, la seguridad de la cadena de suministro, el control de acceso, la gestión de activos y la evaluación de la eficacia.

Un supervisor DORA o un equipo de auditoría interna buscará gobernanza del riesgo TIC, supervisión por el órgano de dirección, el registro de información de acuerdos con terceros TIC, mapeo de funciones críticas o importantes, riesgo de concentración, riesgo de subcontratación, ubicaciones de tratamiento de datos, derechos de auditoría, soporte a la notificación de incidentes, pruebas de continuidad y planes de salida. DORA es claro: la externalización no transfiere la responsabilidad.

Zenith Controls ayuda a los responsables de seguridad a prepararse para estos estilos de auditoría porque referencia de forma cruzada las relaciones entre controles. Para el control 5.20 de ISO/IEC 27002:2022, Tratamiento de la seguridad de la información en los acuerdos con proveedores, Zenith Controls lo vincula con 5.19 relaciones con proveedores, 5.14 transferencia de información, 5.22 supervisión de proveedores, 5.11 devolución de activos y 5.36 cumplimiento de políticas, reglas y normas. Para el control 5.22, Supervisión, revisión y gestión de cambios de los servicios de proveedores, vincula la supervisión continua de proveedores con 5.29 seguridad durante interrupciones, 8.8 gestión de vulnerabilidades técnicas, 5.15 control de acceso, 8.27 arquitectura segura de sistemas y principios de ingeniería, y 5.36 cumplimiento.

Esa visión transversal de controles importa porque un cambio de región nunca es solo un cambio de región. Puede modificar el riesgo de proveedor, el riesgo de transferencia, el riesgo de acceso, el riesgo de continuidad, las evidencias de respuesta a incidentes y el cumplimiento contractual.

Usar esta lista de verificación para CISO de 2026 antes de aprobar un cambio en la nube

Usa esta lista de verificación antes de aprobar cualquier nueva región en la nube, ruta de tratamiento transfronterizo, ubicación de copia de seguridad, plataforma de registro, modelo de soporte o cambio de proveedor TIC crítico.

Si la respuesta a cualquier pregunta es “lo asumimos”, el control no es lo bastante maduro para operaciones reguladas.

La hoja de ruta de remediación

La ruta de remediación es práctica cuando está anclada en el SGSI.

1. Confirmar que el alcance del SGSI incluye servicios en la nube, dependencias TIC críticas y tratamiento de datos regulados.
2. Construir el registro de gobernanza de regiones en la nube para servicios prioritarios.
3. Mapear cada servicio con categorías de datos, regiones, ubicaciones de copia de seguridad, acceso de soporte y subencargados.
4. Revisar los acuerdos con proveedores respecto de ubicación de almacenamiento, transferencia, auditoría, incidentes, subcontratación, devolución y cláusulas de destrucción.
5. Actualizar el registro de riesgos por brechas, riesgos de concentración y transferencias no documentadas.
6. Alinear el registro de terceros TIC de DORA y el mapeo de dependencias de servicios NIS2 cuando proceda.
7. Validar la aplicación técnica, incluidos bloqueos de región, políticas de copia de seguridad, ajustes de registro, cifrado, controles de acceso y gestión de claves.
8. Preparar un paquete de evidencias de auditoría con capturas de pantalla, contratos, registros de riesgo, aprobaciones, actas de revisión y resultados de pruebas.
9. Establecer un desencadenante de cambio para nuevas regiones, subencargados, mecanismos de transferencia o cambios de servicio de proveedores críticos.
10. Informar a la dirección sobre el riesgo de residencia en la nube, las excepciones y las decisiones de riesgo residual.

Esto no es cumplimiento teórico. Es la diferencia entre un parque en la nube capaz de resistir el escrutinio de auditoría y otro que depende de garantías verbales.

El caso de negocio: soberanía, resiliencia y confianza

La alta dirección a veces ve la gobernanza de residencia de datos como una restricción a la agilidad de la nube. En la práctica, una gobernanza madura de regiones mejora la agilidad porque los equipos conocen las reglas antes de comprar, construir o migrar.

Un equipo de producto puede lanzar antes cuando las regiones aprobadas están claras. Compras puede negociar más rápido cuando las cláusulas obligatorias ya están definidas. Legal puede evaluar transferencias más rápido cuando los flujos de datos están documentados. Operaciones de seguridad puede investigar más rápido cuando se conocen las ubicaciones de los registros y los derechos de acceso. El consejo puede tomar decisiones de riesgo más rápido cuando el riesgo de concentración, el impacto en continuidad y la aceptación del riesgo residual son visibles.

Para los clientes, especialmente los clientes regulados, esto se convierte en una señal de confianza. Un proveedor SaaS que puede explicar dónde residen los datos, cómo se gobiernan las copias de seguridad, cómo se controla el acceso de soporte, cómo se aprueban los subencargados y cómo se revisan los cambios de región superará a un proveedor que solo dice “usamos un proveedor líder de nube”.

En 2026, esa diferencia importa. NIS2 ha llevado la gobernanza de ciberseguridad a entidades esenciales e importantes en toda la UE. DORA ha convertido la supervisión de terceros TIC en una disciplina formal del sector financiero. La responsabilidad proactiva del RGPD de la UE sigue siendo central. ISO/IEC 27001:2022 proporciona el sistema de gestión que lo mantiene unido.

Próximos pasos con Clarysec

Si tu organización no puede responder dónde residen los datos regulados y el tratamiento TIC crítico en producción, copias de seguridad, registros, acceso de soporte y subcontratistas, ahora es el momento de cerrar la brecha.

Clarysec puede ayudarte a construir un paquete de evidencias de gobernanza de regiones en la nube utilizando:

• Zenith Blueprint: hoja de ruta de 30 pasos para auditores Zenith Blueprint para una implantación ISO por fases y preparación para auditorías.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls para mapear los controles de nube y de proveedores de ISO/IEC 27002:2022 con evidencias operativas y expectativas entre marcos.
• Política de uso de la nube Cloud Usage Policy y Política de uso de la nube para pymes Cloud Usage Policy - SME para requisitos de residencia de datos en la nube.
• Política de seguridad de terceros y proveedores Third party and supplier security policy y Política de seguridad de terceros y proveedores para pymes Third-Party and Supplier Security Policy - SME para contratos con proveedores, subcontratación y garantías de almacenamiento geográfico.
• Política de registro y supervisión para pymes Logging and Monitoring Policy - SME para conservación de registros y evidencias de proveedores.
• Política de cumplimiento legal y normativo Legal and Regulatory Compliance Policy para desencadenantes de revisión de cumplimiento en torno a mecanismos de transferencia, subencargados y flujos transfronterizos de datos.

Empieza con un servicio crítico, un proveedor de nube y un registro. En pocos talleres, puedes pasar de las suposiciones a las evidencias, y del cumplimiento fragmentado a una resiliencia en la nube gobernada.

Descarga el kit de herramientas de Clarysec, solicita una demo o reserva una evaluación de gobernanza de regiones en la nube para convertir tus compromisos de residencia en la nube en pruebas preparadas para auditoría.