Compliance, Data Sovereignty and Data Residency
Resumen
Cumplimiento no significa tener un certificado colgado en la pared: significa poder demostrar, con evidencia, que los controles que protegen los datos existen, operan y cubren el alcance que la ley o el contrato exigen. En Google Cloud, esa evidencia se apoya en tres capas: controles técnicos que el cliente configura, compromisos y auditorías independientes del proveedor, y documentos contractuales que asignan responsabilidades. Un Digital Leader debe saber qué parte corresponde a Google, qué parte corresponde a su organización y qué artefacto demuestra cada afirmación.\n\nEste tema distingue tres conceptos que se confunden con frecuencia. Data residency se refiere a dónde se almacenan los datos en reposo. Data sovereignty es una noción más amplia: incluye la jurisdicción legal aplicable, el acceso del personal del proveedor, el control de las claves y la capacidad de operar bajo las leyes del país. Compliance es el proceso de demostrar que se cumplen requisitos regulatorios, sectoriales o contractuales. Una empresa puede tener residencia en la UE y aun así necesitar controles adicionales de soberanía; y puede tener todas las certificaciones del mundo y no cumplir un requisito específico de su cliente si no puede aportar la evidencia correcta.\n\nEl tema recorre las certificaciones y auditorías más relevantes, el papel de la transparencia y de los informes independientes, el funcionamiento de Compliance Reports Manager, el control de la ubicación con organization policies, Assured Workloads y sus control packages, y el modelo operativo para mantener evidencia viva. El enfoque es el que el examen evalúa: reconocer qué herramienta responde a un requisito de residencia, de auditoría o de acceso del personal, y no confundir una certificación del proveedor con una garantía automática para la carga de trabajo del cliente.\n\n## Objetivos de Aprendizaje\n\nAl terminar este contenido, serás capaz de:\n\n1. Diferenciar compliance, data residency y data sovereignty, y explicar por qué no son sinónimos.\n2. Identificar qué certificaciones y auditorías independientes respaldan la postura de Google Cloud y para qué sirve cada familia.\n3. Explicar el valor de los informes de transparencia y de Access Transparency para responder a una auditoría.\n4. Localizar y usar Compliance Reports Manager como fuente de certificados, informes SOC e ISO y autoevaluaciones.\n5. Diseñar un control de residencia con organization policies de ubicación de recursos y explicar sus límites.\n6. Explicar qué aporta Assured Workloads y cómo sus control packages aplican guardrails a carpetas y proyectos.\n7. Distinguir controles de residencia, de acceso del personal y de control de claves en un escenario de soberanía.\n8. Interpretar el modelo de responsabilidad compartida en cumplimiento: qué certifica Google y qué debe demostrar el cliente.\n9. Construir un mapa de controles, evidencias y dueños para un requisito regulatorio concreto.\n10. Evaluar el coste y la complejidad de una postura de soberanía frente al valor de negocio y el riesgo real.\n\n## Contenido Principal\n\n### Subtema 1: Compliance, residencia y soberanía no son lo mismo\n\nLa residencia de datos responde a una pregunta concreta: ¿en qué ubicación física se almacenan los datos en reposo? En Google Cloud se controla eligiendo regiones o multirregiones para los recursos y, en algunos servicios, mediante políticas de ubicación. La residencia es un requisito técnico y verificable: se puede demostrar con la configuración del recurso y con la documentación del servicio.\n\nLa soberanía de datos añade capas. Incluye la jurisdicción legal que aplica al dato, las obligaciones de acceso de las autoridades locales, las restricciones sobre quién puede acceder al dato (incluido el personal del proveedor), el control de las claves y la capacidad de operar sin dependencia de una entidad extranjera. Dos organizaciones pueden tener los mismos datos en la misma región y una de ellas necesitar requerimientos de soberanía que la otra no tiene, porque la ley aplicable o el contrato con el cliente son distintos.\n\nEl cumplimiento es el proceso de demostrar que se satisfacen los requisitos. No es un producto ni una certificación única: es un sistema de controles, evidencias y responsables. Google Cloud certifica y audita su infraestructura y sus servicios; el cliente sigue siendo responsable de configurar los controles, de usarlos de forma consistente y de documentar su propio cumplimiento. Esa división es la aplicación del modelo de responsabilidad compartida al mundo regulatorio.\n\n| Concepto | Pregunta que responde | Cómo se controla | Evidencia típica |\n|---|---|---|---|\n| Residencia | ¿Dónde están los datos en reposo? | Región o multirregión del recurso; organization policy de ubicación | Configuración del recurso, informe de ubicación |\n| Soberanía | ¿Qué ley y qué personas pueden acceder? | Residencia, control de claves, acceso del personal, controles soberanos | Contrato, configuración de claves, Access Transparency, Assured Workloads |\n| Compliance | ¿Se cumplen los requisitos? | Mapa de controles, auditoría, evidencia y revisión | Certificados, informes SOC/ISO, registros, políticas |\n\nEl error de negocio más común es prometer residencia cuando el cliente pidió soberanía, o prometer cumplimiento cuando solo se tiene una certificación del proveedor. La conversación correcta empieza por separar el requisito legal del requisito técnico y termina con la evidencia que un auditor aceptaría.\n\n### Subtema 2: Auditorías independientes, transparencia y evidencia
Google Cloud somete su infraestructura y sus servicios a auditorías y certificaciones de terceros. Las familias que un líder debe reconocer son las siguientes:\n\n- ISO/IEC 27001 certifica un sistema de gestión de seguridad de la información. Es la base de muchos requisitos corporativos y de licitaciones.\n- ISO/IEC 27017 añade controles específicos para servicios cloud, e ISO/IEC 27018 se centra en la protección de información personal en nubes públicas.\n- ISO/IEC 27701 extiende el sistema de gestión a la privacidad y al tratamiento de datos personales.\n- SOC 1, SOC 2 y SOC 3 son informes de auditoría sobre controles financieros y de confianza (seguridad, disponibilidad, integridad de procesamiento, confidencialidad y privacidad). SOC 2 es detallado y normalmente bajo acuerdo; SOC 3 es un resumen público.\n- PCI DSS aplica a datos de tarjetas de pago, HIPAA a información de salud en Estados Unidos y FedRAMP a servicios cloud para el gobierno federal de Estados Unidos. Existen además marcos regionales como BSI C5 en Alemania o MTCS en Singapur.\n\nUna certificación del proveedor no convierte automáticamente al cliente en cumplidor. Si una organización processa datos de tarjetas, necesita entender qué parte del estándar cubre Google Cloud y qué controles debe aplicar en su aplicación, su red y sus procesos. El mapa de responsabilidad compartida es el documento que traduce la certificación en obligaciones concretas para cada parte.\n\nLa transparencia es otro pilar de confianza. Los informes de transparencia de Google describen cómo las políticas y acciones de gobiernos y empresas afectan la privacidad, la seguridad y el acceso a la información. Access Transparency registra y muestra al cliente los accesos administrativos de personal de Google a sus datos o configuraciones cuando la ley lo permite. Access Approval permite al cliente aprobar o rechazar determinados accesos del personal de Google antes de que ocurran, según el servicio y la configuración. Para un auditor, estos registros son la diferencia entre una promesa y una evidencia.\n\n| Artefacto | Qué demuestra | Quién lo usa |\n|---|---|---|\n| Certificado ISO/IEC 27001 | Sistema de gestión de seguridad auditado | Compliance, licitaciones, clientes corporativos |\n| Informe SOC 2 | Controles de seguridad, disponibilidad, integridad, confidencialidad y privacidad | Auditoría, due diligence, equipos de riesgo |\n| Informe SOC 3 | Resumen público de los controles | Comunicación comercial y transparencia |\n| Informe de transparencia | Cómo se responde a solicitudes de datos | Legal, privacidad, dirección |\n| Access Transparency | Accesos del personal de Google a datos del cliente | Auditoría, seguridad, investigaciones |\n\n### Subtema 3: Compliance Reports Manager y el ciclo de evidencia\n\nCompliance Reports Manager es el punto de acceso bajo demanda a certificados, informes de auditoría, autoevaluaciones y documentación de cumplimiento de Google Cloud, sin coste adicional. Algunos recursos son públicos y otros requieren iniciar sesión con una cuenta de Google Cloud o Google Workspace; los marcados como confidenciales están sujetos al acuerdo con el cliente. El valor operativo es que el equipo de compliance no depende de una solicitud comercial para obtener el informe vigente: lo descarga, verifica la fecha y lo archiva con el resto de la evidencia.\n\nEl ciclo de evidencia tiene cuatro pasos. Primero se identifican los requisitos aplicables —ley, regulación sectorial, contrato con el cliente, política interna—. Después se mapea cada requisito a un control y a un dueño. Luego se recoge la evidencia: certificado del proveedor, configuración del recurso, log, captura de política, resultado de una prueba. Por último se revisa la vigencia: una auditoría de hace tres años no demuestra el estado actual, y un certificado que no cubre el servicio usado no aplica.\n\n| Paso | Pregunta | Artefacto |\n|---|---|---|\n| Identificar | ¿Qué norma o cláusula aplica? | Registro de requisitos |\n| Mapear | ¿Qué control lo satisface y quién es el dueño? | Matriz de controles |\n| Evidenciar | ¿Cómo demuestro que opera? | Certificado, log, configuración, prueba |\n| Revisar | ¿Sigue vigente y cubre el servicio? | Fecha, alcance, versión |\n\nUn error frecuente es archivar un certificado sin verificar su alcance. Un informe SOC 2 puede cubrir determinados servicios y no otros; una certificación ISO puede aplicar a la infraestructura común y no a un producto concreto. El equipo debe leer el alcance y la fecha, no solo el logo. La evidencia también debe estar accesible para quien la necesite en una auditoría: un documento que vive en el correo de una persona que se fue no es evidencia operativa.\n\n### Subtema 4: Residencia con organization policies y ubicación de recursos\n\nGoogle Cloud permite restringir la ubicación de recursos mediante una organization policy de ubicación de recursos (constraints/gcp.resourceLocations). La política se aplica en la organización, una carpeta o un proyecto y limita las ubicaciones que los recursos nuevos pueden usar. Es un control preventivo: en lugar de auditar después qué región eligió cada equipo, se impide crear recursos fuera de las ubicaciones permitidas. Su valor es especialmente alto en organizaciones con muchos proyectos y equipos, donde la revisión manual no escala.\n\nLa política tiene límites que conviene entender. No todos los recursos están cubiertos; algunos servicios tienen metadatos o componentes que no se restringen de la misma forma, y ciertos servicios globales no se pueden regionalizar. Además, la política se aplica a recursos nuevos: los existentes pueden requerir un plan de remediación. Y la residencia de los datos en reposo no cubre por sí sola el acceso del personal, el procesamiento en tránsito ni las claves. Por eso se combina con otras capas.\n\n| Necesidad | Control principal | Límite que hay que declarar |\n|---|---|---|\n| Solo crear recursos en la UE | Organization policy de resource locations | No cubre recursos ya existentes ni todos los servicios |\n| Mantener datos de un cliente en un país | Región o multirregión del servicio + política | No controla el acceso del personal por sí sola |\n| Restringir acceso del personal de Google | Access Approval, Assured Workloads, controles soberanos | Disponibilidad limitada por servicio y control package |\n| Controlar las claves | Cloud KMS, Cloud HSM, Cloud EKM | Cloud EKM depende de la disponibilidad del key manager externo |\n\nLa residencia se decide por servicio y por tipo de dato. No basta con decir que la empresa usa la región europe-west1: hay que verificar qué servicios almacenan datos, dónde los replican, qué ocurre con los backups, los logs y los metadatos, y si el servicio ofrece una garantía de ubicación. Un arquitecto de nube puede diseñar una aplicación en una región y descubrir que un servicio auxiliar es global. La conversación de compliance debe incluir el inventario de datos y el flujo entre servicios, no solo la región del recurso principal.\n\n### Subtema 5: Soberanía y Assured Workloads\n\nAssured Workloads permite crear carpetas con control packages que aplican guardrails de residencia, acceso del personal y claves a los proyectos y recursos que contienen. Está diseñado para organizaciones reguladas —servicios financieros, salud, gobierno— que necesitan una frontera soberana sin renunciar a la escala y a los servicios del cloud comercial. La carpeta de Assured Workloads hereda las políticas a los proyectos que se crean dentro, y la plataforma monitoriza desviaciones de la postura configurada.\n\nLos control packages se agrupan en tres familias. Las regional data boundaries restringen la ubicación de los recursos y, en algunos casos, añaden controles de acceso del personal. Las regulatory data boundaries aplican controles alineados con un marco regulatorio concreto. Los Sovereign Controls by Partners permiten que un socio local de confianza gestione claves, justificación de acceso y auditoría, con residencia y controles reforzados. La elección depende del requisito legal, no del deseo genérico de tener más controles.\n\n| Control package | Qué restringe | Cuándo tiene sentido | Coste de adopción |\n|---|---|---|---|\n| Regional data boundary | Ubicación de recursos y, según el caso, acceso del personal | Requisito de residencia en una región o país | Medio |\n| Regulatory data boundary | Controles alineados a un marco regulatorio | Sector regulado con requisitos específicos | Alto |\n| Sovereign Controls by Partners | Claves, acceso y auditoría gestionados por un socio local | Soberanía estricta con proveedor local | Muy alto |\n\nAssured Workloads no es un interruptor de cumplimiento. La organización sigue siendo responsable de la configuración de sus aplicaciones, de la clasificación de datos, de la gestión de identidades y de la evidencia de sus propios controles. Lo que aporta es una frontera técnica que reduce el riesgo de que un equipo cree recursos fuera del perímetro permitido y una monitorización que detecta cambios en la postura. Es una capa de defensa en profundidad para el requisito de soberanía, no una delegación total de la responsabilidad.\n\nLa soberanía también incluye el control de las claves. Un escenario de soberanía puede exigir que el material de la clave permanezca en un HSM controlado por una entidad local o en un key manager externo. Cloud EKM y Cloud HSM son las piezas técnicas; la parte legal y contractual se resuelve con el proveedor y con el socio. Un Digital Leader debe saber que la conversación de soberanía no se cierra solo con una región: incluye ley aplicable, personal, claves, cadena de subprocesadores y capacidad de salida.\n\n### Subtema 6: El modelo operativo de cumplimiento\n\nEl cumplimiento sostenible se organiza como un ciclo, no como un proyecto anual. La organización mantiene un inventario de requisitos, un mapa de controles con dueños, un repositorio de evidencias y un calendario de revisiones. Cuando cambia un servicio o se lanza un producto, el ciclo se reabre: se evalúa el nuevo alcance, se identifican controles nuevos y se actualiza la evidencia. La auditoría deja de ser una sorpresa y pasa a ser una revisión de algo que ya está documentado.\n\nLa responsabilidad compartida se traduce en una matriz de tres columnas: requisito, control de Google Cloud, control del cliente. Por ejemplo, para un requisito de cifrado en reposo, Google aporta el cifrado por defecto y el cliente aporta la decisión de usar CMEK, la gestión de permisos y la evidencia de configuración. Para un requisito de acceso, Google aporta Access Transparency y el cliente aporta la revisión de roles, la autenticación fuerte y la segregación de funciones. La matriz evita dos errores: atribuir a Google una obligación del cliente y duplicar controles que el proveedor ya cubre.\n\n#### Ejemplo Práctico\n\nEl siguiente ejemplo muestra cómo se restringe la ubicación de recursos y se revisa la evidencia de acceso. Los identificadores son ilustrativos.\n\nyaml\n# politica-ubicacion.yaml\nconstraint: constraints/gcp.resourceLocations\nlistPolicy:\n allowedValues:\n - in:eu-locations\n deniedValues:\n - in:us-locations\n\n\nbash\n# Aplicar la política a una organización\ngcloud resource-manager org-policies set-policy politica-ubicacion.yaml \\\n --organization=123456789012\n\n# Ver la política efectiva en un proyecto\ngcloud resource-manager org-policies describe \\\n constraints/gcp.resourceLocations \\\n --project=mi-proyecto-regulado\n\n# Revisar accesos administrativos y eventos de auditoría\ngcloud logging read 'logName:\"cloudaudit.googleapis.com/activity\"' \\\n --project=mi-proyecto-regulado \\\n --limit=20\n\n\nLa lectura de negocio es que la política impide crear recursos fuera de la UE sin depender de la disciplina de cada equipo, y el log de auditoría permite demostrar quién hizo qué. Para un requisito de soberanía más estricto, la política se combina con Assured Workloads y con controles de claves; la política sola no cubre el acceso del personal ni la jurisdicción.\n\nTemas relacionados: Security and Trust Principles in Google Cloud, Identity, Access Management and Compliance, Encryption, Key Management and Data Protection, Network Security, VPC and Perimeter Defense.\n\n## Errores Comunes\n\n1. Error: Tratar residencia y soberanía como sinónimos. → Solución: Separar la pregunta de ubicación física de la de jurisdicción, acceso del personal y control de claves; un requisito de residencia puede resolverse con una región, pero uno de soberanía exige capas adicionales.\n2. Error: Asumir que una certificación del proveedor cubre automáticamente el cumplimiento de la organización. → Solución: Leer el alcance y la fecha del informe, mapear cada requisito a controles de Google y controles propios, y documentar la evidencia del cliente.\n3. Error: Restringir la región de un recurso principal y olvidar logs, backups, metadatos o servicios auxiliares. → Solución: Inventariar todos los flujos y servicios que almacenan datos, verificar la garantía de ubicación de cada uno y aplicar la política de organización de forma preventiva.\n4. Error: Archivar certificados sin verificar que sigan vigentes ni que cubran el servicio usado. → Solución: Usar Compliance Reports Manager, comprobar fecha y alcance, y mantener un calendario de renovación y revisión.\n5. Error: Implementar un control package de soberanía sin adaptar la aplicación y los procesos. → Solución: Tratar Assured Workloads como una frontera que exige rediseñar ubicaciones, claves, acceso y soporte; probar la operación antes de mover cargas reguladas.\n\n## Puntos para el Examen\n\n> 🎯 Punto clave 1: Residencia es dónde están los datos en reposo; soberanía añade ley aplicable, acceso del personal y control de claves; compliance es demostrar que se cumplen los requisitos. Tres conceptos distintos.\n\n> 🎯 Punto clave 2: Compliance Reports Manager da acceso a certificados, informes SOC/ISO y autoevaluaciones de Google Cloud; el cliente debe leer el alcance y aportar su propia evidencia.\n\n> 🎯 Punto clave 3: Las organization policies de resource locations restringen la ubicación de recursos nuevos; no cubren por sí solas el acceso del personal ni todos los servicios.\n\n> 🎯 Punto clave 4: Assured Workloads aplica control packages a carpetas y proyectos para residencia, requisitos regulatorios y controles soberanos. Es una frontera técnica, no una delegación total de responsabilidad.\n\n> 🎯 Punto clave 5: Access Transparency y Access Approval aportan evidencia y control sobre accesos del personal de Google; son parte de la historia de transparencia que un auditor espera.\n\n## Recursos Externos\n\n- Google Cloud Trust Center — Transparencia, cumplimiento, privacidad y compromisos de Google Cloud.\n- Compliance Reports Manager — Acceso a certificados, informes SOC/ISO y autoevaluaciones.\n- Assured Workloads overview — Control packages, residencia, acceso del personal y monitorización.\n- Data residency — Cómo se controla la ubicación de los datos en reposo.\n- Google Cloud compliance resource center — Catálogo de certificaciones y marcos regulatorios.\n- Access Transparency — Registro de accesos administrativos del personal de Google.\n\n## Autoevaluación Rápida\n\n1. Pregunta: Un cliente exige que sus datos se almacenen en la UE y que el personal de Google no pueda acceder a ellos sin autorización. ¿Basta con elegir la región europe-west1?\n Respuesta: No. La región cubre la residencia en reposo, pero el requisito de acceso del personal exige controles adicionales como Access Approval, Assured Workloads con un control package adecuado o controles soberanos. La respuesta debe separar residencia de soberanía.\n\n2. Pregunta: ¿Qué diferencia hay entre un informe SOC 2 y un certificado ISO/IEC 27001?\n Respuesta: SOC 2 es un informe de auditoría sobre controles de confianza (seguridad, disponibilidad, integridad, confidencialidad y privacidad) emitido bajo un marco de la AICPA. ISO/IEC 27001 certifica un sistema de gestión de seguridad de la información. Ambos son evidencia, pero cubren alcances y marcos distintos; hay que leer qué servicios y periodos abarcan.\n\n3. Pregunta: ¿Para qué sirve una organization policy de resource locations y qué no resuelve?\n Respuesta: Restringe las ubicaciones donde se pueden crear recursos nuevos, aplicándose en organización, carpeta o proyecto. No resuelve por sí sola el acceso del personal, la jurisdicción, las claves ni los recursos ya existentes; se combina con otras capas.\n\n4. Pregunta: ¿Qué aporta Assured Workloads a una organización regulada?\n Respuesta: Aplica control packages a una carpeta para restringir residencia, acceso del personal y claves, y monitoriza desviaciones de la postura. Reduce el riesgo de configuraciones fuera del perímetro, pero no sustituye la responsabilidad del cliente sobre sus aplicaciones, identidades y evidencia.\n\n5. Pregunta: ¿Cómo se demuestra a un auditor que un control de acceso está operando?\n Respuesta: Con evidencia combinada: la política y los roles configurados, los logs de auditoría y de acceso, los registros de Access Transparency cuando aplican, y una revisión periódica documentada. Una captura de configuración sin logs ni revisión demuestra intención, no operación.\n\n