¿Qué Es la Soberanía de Datos? Significado, Requisitos y Riesgos en la Nube

Para las organizaciones que operan en varios países, la soberanía de datos ha dejado de ser una cuestión secundaria y se ha convertido en un factor clave de planificación. Normas como el RGPD de la UE establecen cómo se pueden tratar y transferir los datos personales a otros países, y para las empresas con operaciones globales eso se convierte en un verdadero obstáculo al tomar decisiones sobre la nube. Además, plantea requisitos de soberanía de los datos que la mayoría de los equipos todavía no ha definido.

Esa fricción se hace evidente en el momento en que una carga de trabajo sensible se traslada a la nube. «¿Dónde se almacenarán los datos?» parece ser la primera pregunta obvia. Pero, al analizarlo más detenidamente, surgen otras: ¿Dónde se guardan las copias de seguridad? ¿Quién tiene acceso de administrador? ¿Qué empresa se encarga del soporte técnico? ¿Qué ocurre durante la recuperación?

Incluso la documentación de los propios proveedores de nube deja ver lo complicado que es todo esto.  Microsoft señala que ciertos datos de Azure Communication Services, el servicio que sostiene el chat y las llamadas dentro de las aplicaciones, pueden permanecer en una zona geográfica concreta, pero que el procesamiento, el tránsito o los datos de eventos relacionados pueden no respetar ese límite. AWS , por su parte, aconseja a los clientes analizar por separado las copias de seguridad y la retención a la hora de evaluar la residencia de los datos.

La ubicación, por sí sola, no responde a la pregunta. Quién puede acceder a tus datos, a qué jurisdicción están sujetos y cómo funciona realmente la infraestructura son los factores que, juntos, determinan cuánto control mantienes. Ese es precisamente el razonamiento detrás del enfoque de Ilkari. La soberanía no es una casilla que se marca una sola vez. Se construye con el tiempo, con sistemas resilientes, informes claros y decisiones de infraestructura pensadas a largo plazo.

El Marco de Soberanía en la Nube de 2026 de la Comisión Europea plantea una idea similar, pero a mayor escala. Evalúa a los proveedores en función de 48 criterios repartidos en ocho objetivos, lo que indica que la soberanía se ha convertido en algo que se mide, y no solo en algo que se reivindica. A continuación, analizamos qué significa realmente la soberanía de datos, cómo se definen sus requisitos y qué conviene comprobar antes de confiar información sensible a un proveedor.

¿Qué es la soberanía de datos o data sovereignty?

La soberanía de datos, o data sovereignty, es el principio según el cual los datos están sujetos a los requisitos legales, de gobernanza y operativos del país, estado o región en el que se almacenan o tratan. En la práctica, implica saber quién puede acceder a los datos, qué organizaciones gestionan la infraestructura, qué gobierno tiene jurisdicción sobre ellos y qué protecciones contractuales son realmente exigibles. En sectores regulados, como la sanidad, las finanzas o el sector público, estas cuestiones pesan todavía más.

La jurisdicción varía en función de la región en la que se almacenen y traten los datos. Si se almacenan y tratan datos personales en un Estado miembro de la UE, se aplica el RGPD, junto con el resto de la legislación de la UE. Si se hace lo mismo en Estados Unidos, en cambio, hay que lidiar con un mosaico diferente de normas federales y estatales. Las organizaciones multinacionales rara vez operan bajo una única jurisdicción. La mayoría tiene que gestionar varias a la vez.

Imaginemos una empresa de servicios financieros sujeta a regulación que traslada los registros de sus clientes a una plataforma de nube pública. Confirmar la ubicación del almacenamiento es solo el primer paso. La empresa también necesita saber dónde se guardan las copias de seguridad, quiénes son las personas del proveedor que pueden acceder a los datos de producción, qué jurisdicción legal rige en caso de litigio, quién controla las claves de cifrado y a qué está obligado contractualmente el proveedor si un gobierno solicita acceso a los datos.

Por eso no se debe confundir la soberanía de los datos con el mero hecho de almacenar los datos en una ubicación concreta. 

Soberanía de los datos y términos relacionados: residencia, localización y soberanía digital

A menudo se confunde la soberanía de los datos con la residencia de los datos, la localización de los datos y la soberanía digital. Los cuatro términos hacen referencia al control, ya sea sobre los propios datos o sobre los sistemas que los gestionan, pero no son intercambiables. En realidad, cada uno de ellos se refiere a algo distinto. Si se tratan como si fueran lo mismo, la ubicación empieza a parecer la única respuesta. Para una empresa que debe tomar decisiones sobre infraestructura, esa suposición conlleva un coste real. La ubicación es solo un factor más dentro de un panorama mucho más amplio.

Residencia de los datos

La residencia de los datos es el concepto más sencillo de los cuatro. Se refiere únicamente a la ubicación física o geográfica en la que se almacenan o procesan los datos, y nada más. Sin embargo, al cruzar una frontera con esos datos, pueden aplicarse nuevos requisitos legales casi de inmediato. Por eso, la residencia forma parte de una cuestión más amplia relacionada con la soberanía, aunque no la resuelve por completo. Esa es la diferencia clave entre soberanía de datos y residencia de datos: la residencia no dice nada sobre quién puede acceder a los datos, quién gestiona la infraestructura ni qué gobierno tiene realmente autoridad sobre ellos.

Localización de datos

La localización de datos va aún más allá. No se trata solo de dónde se almacenan los datos. Es un requisito legal o normativo que obliga a que determinados datos permanezcan dentro de un país o una región concretos.

Una organización podría estar obligada legalmente, por ejemplo, a conservar una determinada categoría de datos dentro de su país de origen, sin posibilidad de enviarlos al extranjero para su almacenamiento o tratamiento. Lo que se restringe exactamente, y con qué rigor, depende de la legislación específica que regule ese tipo concreto de datos.

Soberanía digital

La soberanía digital es un concepto mucho más amplio que la soberanía de los datos. Plantea si un Estado, una organización o un individuo ejerce un control auténtico e independiente sobre todo su entorno digital, no solo sobre los datos, sino también sobre la infraestructura, el software, la tecnología y las operaciones cotidianas.

Esa perspectiva más amplia también implica prestar atención al grado de dependencia de una organización respecto a los proveedores de tecnología externos. El propio marco de la Comisión Europea funciona también de esta manera, sopesando varias dimensiones de la soberanía en lugar de reducirlo todo a la ubicación física de los datos. En la práctica, esto influye en decisiones reales, como el grado de dependencia de una empresa respecto a un único proveedor extranjero de servicios en la nube, o si realmente podría prescindir de él en caso de necesidad.

Nube soberana

La «nube soberana» es el resultado de convertir el control en una decisión real sobre la infraestructura, en lugar de limitarse a un mero objetivo normativo. Se trata de una infraestructura en la nube diseñada específicamente para que las organizaciones tengan un mayor control sobre sus datos: quién puede acceder a ellos, cómo se llevan a cabo las operaciones y qué jurisdicción es la que rige en última instancia.

Elegir un proveedor de servicios en la nube soberana es una vía práctica para cumplir los requisitos de soberanía de datos. Sin embargo, esto por sí solo no garantiza el cumplimiento normativo. Los contratos subyacentes, los controles de acceso y las prácticas operativas cotidianas siguen teniendo la misma importancia. 

Por qué es importante la soberanía de datos en la nube

Los entornos en la nube pueden complicar la soberanía de los datos, sobre todo porque una sola carga de trabajo puede afectar a varias ubicaciones, servicios y organizaciones a la vez. Aunque la elección de una región en la nube pueda determinar dónde se almacenan algunos datos, las copias de seguridad, los registros, los metadatos, el acceso al servicio de asistencia y los sistemas de recuperación ante desastres pueden funcionar dentro de límites geográficos u operativos totalmente distintos. Por lo tanto, la ubicación de la carga de trabajo principal rara vez ofrece una visión completa de la soberanía.

Estos retos son, en parte, la razón por la que han surgido nuevos enfoques de la nube que ofrecen a las organizaciones un mayor control sobre cómo y dónde se ejecutan realmente sus cargas de trabajo. La nube soberana es uno de esos enfoques.

La nube soberana es una vía para lograr ese control, pero elegirla no garantiza por sí sola que cubra lo que necesita una carga de trabajo concreta. Eso depende de la carga de trabajo, de su perfil de riesgo y de los requisitos de soberanía de la organización.

Por lo tanto, optar por una nube soberana no exime a una organización de comprender cómo funciona realmente el entorno. Para comprobar si un entorno en la nube cumple realmente con sus requisitos de soberanía, hay cinco aspectos que conviene examinar: dónde operan realmente los servicios, dónde se almacenan los datos primarios y secundarios, quién tiene acceso y control, qué entidades operan o dan soporte al servicio, y qué ocurre con los datos durante la recuperación y a lo largo de su ciclo de vida.

Regiones en la nube, zonas de disponibilidad y ubicaciones de servicio

En primer lugar: ¿dónde se ejecutan realmente los servicios que componen la carga de trabajo? La selección de una región en la nube puede fijar la ubicación de algunos recursos, pero cada servicio puede tener sus propios límites geográficos o compromisos de ubicación. AWS, por ejemplo, divide su infraestructura en «regiones» más amplias y, a su vez, en «zonas de disponibilidad» más pequeñas dentro de cada una de ellas, instalaciones físicamente separadas que conllevan sus propias implicaciones en cuanto a ubicación y resiliencia. Por lo tanto, en lugar de dar por sentado que la elección de una región determina dónde opera toda la carga de trabajo, las organizaciones deben comprobar los compromisos de ubicación servicio por servicio.

Copias de seguridad, réplicas, registros, metadatos y telemetría

Siguiente pregunta: ¿dónde se almacenan todos los datos relevantes, no solo la copia principal? Una carga de trabajo no solo produce datos de producción. A lo largo del proceso, también genera copias de seguridad, instantáneas, réplicas, registros de auditoría, archivos, telemetría y metadatos de servicio. Estas copias secundarias y estos datos operativos suelen pertenecer a servicios diferentes o estar sujetos a compromisos de los proveedores totalmente distintos. Comprender dónde se encuentran y cómo se tratan es esencial para trazar la huella real de datos de una carga de trabajo.

Control de acceso, usuarios con privilegios y claves de cifrado

Quién puede acceder o controlar realmente el entorno es tan importante como su ubicación. Las organizaciones deben saber quiénes son los usuarios con privilegios, qué personal del proveedor tiene acceso y qué servicios automatizados pueden acceder a los sistemas pertinentes o administrarlos.

El cifrado ayuda a limitar la exposición, y el hecho de que una organización posea las claves de cifrado le otorga mayor control sobre quién puede desbloquear los datos protegidos. Sin embargo, ninguno de estos aspectos sustituye la necesidad de comprender realmente quién tiene acceso, qué puede hacer con esos datos y cómo se controla dicho acceso.

Entidades del proveedor, equipos de soporte y subcontratistas

También conviene determinar con exactitud qué entidades jurídicas participan en la gestión y el mantenimiento del servicio. A menudo, el proveedor contratante no es el único implicado. Las empresas de soporte y los subcontratistas suelen operar desde jurisdicciones totalmente diferentes.

Una evaluación adecuada de la soberanía debería identificar quiénes son estas entidades, dónde tienen su sede y en qué condiciones pueden acceder a los sistemas o a los datos. El hecho de almacenar los datos a nivel local no garantiza que todas las personas implicadas en la gestión del servicio sean también locales.

Resiliencia, recuperación ante desastres y ciclo de vida de los datos

Por último, está la cuestión de qué ocurre con los datos una vez que se ha realizado una copia de seguridad, se ha recuperado, se ha migrado o, finalmente, se ha eliminado una carga de trabajo. Las medidas de resiliencia pueden introducir discretamente nuevas ubicaciones que nunca entran en juego durante la producción normal.

La conmutación por error, por ejemplo, podría trasladar una carga de trabajo a una jurisdicción completamente diferente. Las políticas de retención, los procesos de restauración, el borrado seguro y la migración pueden modificar la ubicación de los datos a lo largo de todo su ciclo de vida. Estas medidas merecen el mismo escrutinio en materia de soberanía que el que se aplica al entorno principal.

Normativa sobre soberanía de datos y diferencias por región

No existe una norma universal en materia de soberanía de los datos. Los requisitos varían considerablemente en función de la jurisdicción, el sector y el tipo de datos de que se trate. Por lo tanto, las organizaciones deben determinar qué normas concretas se aplican a su propia carga de trabajo, en lugar de dar por sentado que existe una norma única válida para todos los casos.

Europa y el Reino Unido

En Europa y en el Reino Unido, hay dos marcos normativos que regulan la mayor parte de estas cuestiones: el RGPD de la UE y el RGPD del Reino Unido. Ambos regulan el tratamiento de los datos personales, incluidas las transferencias. Sin embargo, desde el Brexit, ambos marcos han ido distanciándose. Aunque en un principio se trataba de la misma normativa, ahora el Reino Unido aplica sus propias normas de transferencia y sus propias directrices reguladoras, distintas de las de la UE.

También pueden influir otras normativas, dependiendo de la organización y de la carga de trabajo. La Leyde Datos de la UE es un ejemplo de ello: regula aspectos como el cambio entre servicios de tratamiento de datos, así como las garantías contra el acceso ilícito de gobiernos de terceros países a datos no personales.

El centro de datos de Ilkari en Croacia opera dentro del marco regulatorio de la UE, así que el RGPD y la Ley de Datos le son directamente aplicables. Es una situación estructuralmente distinta a operar fuera de la UE y depender de una decisión de adecuación o de cláusulas contractuales tipo para transferir datos. Las normas sectoriales siguen aplicándose con independencia de dónde esté la infraestructura.

América Latina

No existe un equivalente al RGPD en toda Latinoamérica. Los requisitos varían de un país a otro, y cualquier organización que opere en toda la región debe consultar por su cuenta la normativa vigente en cada jurisdicción.

Tomemos como ejemplo a Colombia. Su marco general de protección de datos se basa en la Ley 1581 de 2012, supervisada por la Superintendencia de Industria y Comercio (SIC), que también emite directrices sobre las transferencias internacionales. Brasil sigue un camino diferente. Su marco es la Lei Geral de Proteção de Dados Pessoais, conocida como LGPD, y la Autoridad Nacional de Protección de Datos, la ANPD, publicó en agosto de 2024 la Resolución n.º 19, con normas específicas sobre transferencias internacionales. Dos países, dos sistemas muy diferentes. Esa es precisamente la cuestión: englobar todo esto bajo el término «soberanía de datos en Latinoamérica» pasa por alto las diferencias en la forma en que cada país aborda realmente el tema. La realidad varía de un país a otro.

Ilkari gestiona infraestructura de centros de datos en Colombia, por lo que para nosotros esto no es solo teoría. Hemos visto de primera mano cómo estas diferencias regionales afectan a las organizaciones que operan tanto en Latinoamérica como en Europa. No todos los servicios se prestan desde todas las ubicaciones, pero la tendencia subyacente se mantiene: un requisito de soberanía que es importante en Bogotá a menudo no se parece en nada al que es importante en Bruselas.

Sectores regulados

Las normas generales de protección de datos se aplican de forma generalizada, pero en determinados sectores existen requisitos adicionales. La Ley de Resiliencia Operativa Digital de la UE, o DORA, es un claro ejemplo de ello. En ella se establecen requisitos de resiliencia operativa específicos para las entidades financieras, incluyendo la forma en que deben gestionar a sus proveedores de servicios en la nube.

Normas como esta requieren una evaluación propia, independiente de la legislación general en materia de protección de datos. Y conviene ser prudente a la hora de dar por sentado que son aplicables en otros ámbitos. Una obligación que se aplica en un sector o en una jurisdicción no se aplica automáticamente en otro lugar. Las organizaciones deben comprobar siempre el marco normativo concreto antes de dar por sentado que algo es extrapolable.

Transferencias transfronterizas de datos

Las normas sobre transferencias transfronterizas son fundamentales para la soberanía de los datos. Determinan cuándo los datos pueden salir legalmente de una jurisdicción determinada, o simplemente ser consultados desde fuera de ella.

El RGPD de la UE aborda esta cuestión en el capítulo V, principalmente a través de dos mecanismos. El artículo 45 se refiere a las decisiones de adecuación, en las que la Comisión Europea determina que las normas de protección de datos de un país se ajustan a las de la propia UE. Cuando no existe tal decisión, el artículo 46 establece medidas de salvaguardia, normalmente cláusulas contractuales tipo. El Comité Europeo de Protección de Datos (EDPB) añade un requisito más: las organizaciones que recurran al artículo 46 también pueden tener que comprobar las condiciones del país de destino e incorporar medidas de protección adicionales si fuera necesario.

El Reino Unido cuenta con su propio régimen de transferencia de datos, independiente del de la UE. La Oficina del Comisionado de Información (ICO) destaca un aspecto que puede pasar fácilmente desapercibido: incluso el acceso remoto desde fuera del Reino Unido puede considerarse una transferencia, no solo el envío de datos al extranjero.

Cuestiones y conceptos erróneos habituales sobre la soberanía de los datos en la nube

La mayoría de los problemas relacionados con la soberanía de los datos se reducen a lo mismo: lo que una organización necesita realmente no se ajusta al funcionamiento diario de su entorno en la nube. Es posible que los datos en sí estén almacenados en la región adecuada. Sin embargo, las copias de seguridad, las condiciones de acceso, las operaciones del proveedor o los procesos de recuperación pueden involucrar silenciosamente a otras jurisdicciones sin que nadie se dé cuenta. La nube no es realmente el problema en este caso. El problema es la brecha entre lo que exige la soberanía y la forma en que un servicio está realmente configurado, gestionado y regulado.

Problemas habituales de soberanía en la nube

Estos problemas rara vez se deben a un único error grave. Suelen deberse a que el control se distribuye entre más elementos de lo que la gente espera: los datos principales, sus copias, quién tiene acceso a ellos y quién lo gestiona todo entre bastidores.

Movimiento y ciclo de vida de los datos: una cosa es saber dónde se almacenan los datos primarios. Sin embargo, lograr ese mismo nivel de detalle en las copias de seguridad, las réplicas, los registros, la telemetría, las cachés y los archivos supone un reto totalmente distinto. Si no se tiene en cuenta esto, algunas partes del ciclo de vida de los datos pueden quedar fuera de los límites que la organización creía haber controlado.

Acceso y control de privilegios: los administradores, el personal de soporte de los proveedores, los subcontratistas y los servicios automatizados casi nunca comparten el mismo nivel de acceso. Lo que las organizaciones necesitan realmente es un esquema claro: quién puede acceder a los sistemas sensibles, en qué condiciones y cómo se realiza el seguimiento de ese acceso una vez concedido. Las directrices conjuntas de la NSA y la CISA sobre la gestión de identidades y accesos en la nube abordan precisamente este tema con mayor profundidad.

Jurisdicción y operaciones de los proveedores: el hecho de almacenar los datos de forma local no dice nada sobre las jurisdicciones bajo las que operan el resto de las partes implicadas en el servicio. La entidad contratante, la organización de soporte y los subcontratistas pueden tener cada uno sus propias implicaciones legales y operativas. Vale la pena averiguar cuáles son realmente esas implicaciones antes de dar por sentado que el almacenamiento local resuelve la cuestión.

Configuración y resiliencia: un proveedor puede prometer controles regionales o de soberanía sobre el papel. Que esos controles se cumplan realmente depende de cómo estén configurados los servicios en la práctica. La selección de servicios, los ajustes de copia de seguridad y las medidas de conmutación por error pueden acabar enviando datos fuera de los límites previstos sin que nadie se dé cuenta.

Contratos, pruebas y portabilidad: la solidez de una promesa de soberanía depende de la solidez del contrato y de las pruebas que la respalden. Esto implica comprender de qué es realmente responsable el proveedor, qué información de auditoría está realmente disponible y qué ocurre con los propios datos una vez que se migran, se exportan o se eliminan al finalizar la relación. El registro STAR de la Cloud Security Alliance es un espacio en el que se aborda directamente esta cuestión de las pruebas, ya que se basa en que los proveedores publiquen precisamente este tipo de documentación.

Mitos habituales sobre la soberanía en la nube

La mayor parte de la confusión en este ámbito sigue un mismo patrón: pensar que un único factor, ya sea la ubicación, el cifrado o un certificado, basta para demostrar que la soberanía está garantizada. Rara vez es así.

«El almacenamiento local implica automáticamente la soberanía de los datos». Mantener los datos dentro de un país concreto resuelve la cuestión de la ubicación, pero eso es solo una parte. Las condiciones de acceso, las operaciones de los proveedores, las copias secundarias y las jurisdicciones implicadas pueden seguir mermando el control real que tiene una organización.

«Basta con elegir una región en la nube». Una región no define automáticamente los límites de todos los servicios. La propia documentación de Microsoft lo deja claro. Los datos almacenados, el procesamiento y los datos de eventos relacionados pueden regirse cada uno por normas geográficas diferentes.

«El cifrado por sí solo garantiza la soberanía». Es cierto que el cifrado reduce la exposición, pero no resuelve por sí solo todas las cuestiones relacionadas con la soberanía. Sigue quedando la cuestión de quién controla las claves de cifrado, quién puede acceder a los sistemas y a los datos, y qué disposiciones legales y operativas subyacen a todo ello.

«La certificación demuestra que se cumplen todos los requisitos de soberanía». Las certificaciones son pruebas útiles de que se han evaluado determinados controles o sistemas de gestión. Sin embargo, por sí solas, no demuestran que una carga de trabajo concreta cumpla todos los requisitos legales, operativos o jurisdiccionales a los que está sujeta.

«El cumplimiento normativo es responsabilidad exclusiva del proveedor». La mayoría de los principales servicios en la nube funcionan según modelos de responsabilidad compartida, lo que significa que los clientes pueden seguir siendo responsables de aspectos como la configuración del servicio, las políticas de identidad y acceso, y la ubicación de las cargas de trabajo. El reparto exacto depende del servicio y del modelo en cuestión.

«La infraestructura dedicada es, por definición, más soberana que la compartida». El modelo de tenencia por sí solo no resuelve la cuestión. Tanto un proveedor de nube soberana compartida como uno dedicado pueden cumplir los mismos requisitos de soberanía si el acceso, la jurisdicción y las operaciones se gestionan adecuadamente, y ambos pueden quedarse cortos si no es así. Lo que importa es cómo se gestiona realmente el entorno, no solo si es compartido o dedicado.

La ubicación de los datos no debería considerarse el único criterio para evaluar la soberanía.

Cómo elaborar una estrategia de soberanía de datos

Una estrategia de soberanía de datos debería comenzar por definir las necesidades de soberanía de las cargas de trabajo y los datos que una organización realmente necesita proteger, y no partiendo de un proveedor o una tecnología concretos. Las diferentes cargas de trabajo plantean necesidades distintas en función de su grado de confidencialidad, de las obligaciones legales que les son aplicables y del nivel de riesgo empresarial que entrañan. El objetivo es establecer primero esos requisitos y, solo entonces, empezar a definir los controles y la infraestructura que realmente puedan satisfacerlos.

1. Identificar los datos, los sistemas y los responsables

Empieza por determinar qué cargas de trabajo, sistemas y categorías de datos entran realmente dentro del ámbito de aplicación. Anota su finalidad empresarial y asigna claramente la responsabilidad, de modo que exista una rendición de cuentas real para lo que venga después. Esto significa que debe haber un responsable para cada carga de trabajo y, en el caso de las organizaciones más grandes, alguien que se encargue de la estrategia global de soberanía, con la autoridad suficiente para resolver conflictos cuando las prioridades legales, de seguridad y empresariales no coincidan.

2. Trazar el ciclo de vida de los datos

Realiza un seguimiento de dónde se crean, almacenan, procesan, transfieren y, finalmente, eliminan los datos. No se trata únicamente de la copia principal, sino que también debe abarcar los datos y procesos secundarios, como las copias de seguridad, los registros, los archivos y la restauración.

3. Definir las obligaciones

Averigua qué es lo que realmente se aplica a cada carga de trabajo y procura diferenciar las obligaciones legales y normativas de los compromisos contractuales, las políticas internas y las decisiones de la organización en materia de riesgos.

Esa distinción es más importante de lo que podría parecer. Una obligación legal no es opcional; una política o una decisión sobre el riesgo es una elección que toma la organización sobre el grado de control que desea, incluso cuando la ley no lo exige. Si se mantienen bien diferenciados, más adelante quedará claro qué controles son innegociables y cuáles responden a decisiones que la organización ha elegido tomar.

4. Evaluar el riesgo de soberanía

¿Qué significan esos requisitos, en la práctica, para una carga de trabajo concreta? Hay que tener en cuenta su grado de sensibilidad, en qué medida depende de ella la empresa y qué consecuencias tendría realmente si los datos acabaran almacenándose, consultándose, procesándose o recuperándose fuera de los límites en los que se supone que deben permanecer.

5. Evaluar la situación actual e identificar las deficiencias

Antes de diseñar nada nuevo, revisa lo que ya existe. Compara los controles, la infraestructura y los acuerdos con los proveedores existentes con los requisitos y riesgos que acabas de identificar, y averigua exactamente dónde se encuentran las verdaderas carencias. De ese modo, el siguiente paso consistirá en subsanar las carencias reales, en lugar de volver a crear controles que ya cumplen su función.

6. Definir los controles necesarios

AAhora convierte todo eso, es decir, los requisitos, los riesgos y las deficiencias, en controles concretos que puedas señalar. Dependiendo de la carga de trabajo, eso podría implicar la gestión de identidades y accesos, restricciones al acceso con privilegios, cifrado, custodia de claves, límites al acceso de los proveedores para la asistencia técnica, supervisión o procedimientos de eliminación.

7. Seleccionar la infraestructura y el enfoque de nube

La infraestructura solo entra en juego una vez que se han definido los requisitos y los controles, no antes. Nube pública, privada, híbrida, soberana o coubicación: cada opción se evalúa en función de lo que realmente se necesita en cuanto a ubicación, acceso, jurisdicción, resiliencia y portabilidad.

8. Gestionar, evaluar y reevaluar

La soberanía de datos no queda definida en el momento en que una carga de trabajo entra en funcionamiento. Los cambios en los proveedores, los servicios, las regiones, los subencargados del tratamiento, la normativa o los acuerdos de recuperación pueden alterar la situación de una organización en materia de soberanía sin previo aviso.

Alguien debe encargarse de las revisiones periódicas, los procedimientos ante incidentes, las pruebas de recuperación ante desastres y la planificación de salida. No se trata de una tarea que se haga una sola vez.

Cómo evaluar la soberanía de datos de un proveedor de nube o de infraestructura

A un proveedor de servicios en la nube o de infraestructura hay que evaluarlo en función de las pruebas que aporte, sus contratos y las condiciones operativas reales. La palabra «soberano» en una ficha técnica, por sí sola, no dice gran cosa. Antes de decidir si un servicio cumple sus requisitos, los compradores deben saber exactamente qué puede demostrar el proveedor sobre la ubicación de los datos, el acceso, las entidades jurídicas, la recuperación y las responsabilidades del cliente.

Estas son algunas de las cuestiones que conviene plantear durante las revisiones de arquitectura, de compras y de riesgos:

• ¿Dónde se almacenan los datos? No te limites a hacer esta pregunta una sola vez. Hazla por separado para los datos de producción, las copias de seguridad, las réplicas, los registros, la telemetría, los metadatos, las instantáneas y los archivos.
• ¿Qué entidades jurídicas intervienen? Identifica quién es realmente responsable de la contratación, las operaciones y la asistencia, y a continuación determina qué jurisdicciones son aplicables a cada una de ellas.
• ¿Quién puede acceder al entorno? Esto incluye a los administradores con privilegios, al personal de soporte técnico del proveedor, a los servicios automatizados y a los equipos de respuesta ante incidentes, y no solo al acceso obvio de primera línea.
• ¿Quién controla las claves de cifrado? Cuando esto sea relevante para la carga de trabajo, analiza en profundidad la generación, la custodia, el almacenamiento, la rotación, la recuperación, la revocación y la destrucción de las claves.
• ¿Qué pruebas hay que lo respalden realmente? Comprueba los compromisos contractuales, la información de auditoría, la documentación de los servicios, los registros de acceso y cualquier certificación pertinente.
• ¿Qué ocurre en caso de fallo o durante la recuperación? Confirma dónde se producen realmente la conmutación por error y la recuperación ante desastres, y comprueba si su activación modifica el límite de soberanía de la carga de trabajo.
• ¿Cómo funciona realmente la salida? Aclara cómo se exportan, migran y eliminan los datos, y si los formatos o interfaces propietarios dificultarían la salida más de lo necesario.
• ¿Qué sigue siendo responsabilidad del cliente? La responsabilidad compartida implica que los controles del proveedor nunca sustituyen por completo las decisiones de configuración, las políticas de identidad o la gobernanza del propio cliente.

La verdadera transparencia es algo más que una respuesta convincente a una llamada comercial. Significa poder señalar ubicaciones de datos documentadas, límites de acceso claramente definidos, un modelo de asistencia específico, un diseño de resiliencia probado y un proceso de salida concreto, todo ello a disposición del comprador para que lo verifique, y no solo para que se fíe.

Conclusión

La soberanía de los datos va más allá de elegir la región en la nube o el centro de datos adecuados.. Las organizaciones deben analizar detenidamente dónde se almacenan y procesan realmente los datos, quién puede acceder a ellos, qué jurisdicciones y operadores de infraestructura intervienen, y cómo se cumplen esos requisitos durante las copias de seguridad, la recuperación y todas las demás etapas del ciclo de vida de los datos.

Además, nada de eso es inmutable. La aparición de nuevos servicios, proveedores, ubicaciones o prácticas operativas puede alterar la posición de soberanía de una organización sin previo aviso. Precisamente por eso, la gobernanza no puede detenerse una vez que una carga de trabajo entra en funcionamiento.

La verdadera prueba es sencilla: ¿puede una organización demostrar realmente que se cumplen sus requisitos de soberanía, no solo en el momento del lanzamiento, sino a lo largo del tiempo? La soberanía se reduce a mantener los controles y las pruebas adecuados, no a elegir una infraestructura que, sin más, lleve la palabra «soberana» en la etiqueta.

• Soberanía de datos
• Soberanía digital