Hay una confusión que me encuentro constantemente en empresas españolas: creer que usar AWS te hace cumplir el RGPD. No es así. AWS cumple su parte. La tuya sigue siendo tuya entera.

Este artículo es la parte técnica del asunto. No sustituye a un asesor legal, y si tratas datos sensibles necesitas uno.

El reparto de responsabilidades

AWS actúa como encargado del tratamiento. Tú eres el responsable. Eso significa:

ResponsabilidadDe quién
Seguridad física de los centros de datosAWS
Parcheado del hipervisor y la red subyacenteAWS
Certificaciones ISO 27001, SOC 2, ENSAWS (de su infraestructura)
Qué datos personales metes y por quéTuya
Quién tiene acceso a esos datosTuya
Cifrado de lo que guardasTuya
Cuánto tiempo los conservas y cómo los borrasTuya
Poder demostrar todo lo anteriorTuya

La última fila es la que más gente ignora. El RGPD funciona por responsabilidad proactiva: no basta con cumplir, tienes que poder demostrar que cumples. Y eso se demuestra con configuración y con registros.

El Acuerdo de Tratamiento de Datos

AWS tiene un DPA (Data Processing Addendum) incorporado por defecto en sus condiciones de servicio desde hace años. No tienes que firmarlo aparte, pero sí deberías haberlo leído y tenerlo referenciado en tu registro de actividades de tratamiento.

Si un cliente o un auditor te lo pide y tú no sabes ni que existe, eso es una mala señal.

Regiones y transferencias internacionales

Este es el punto que más preguntas genera.

Elegir una región europea no es opcional si no quieres complicarte. eu-west-1 (Irlanda), eu-central-1 (Fráncfort) y eu-south-2 (España, en Aragón) mantienen los datos en reposo dentro de la UE.

Pero ojo con tres cosas que se escapan:

  1. Servicios globales. IAM, Route 53 y CloudFront no viven en una sola región. Normalmente no contienen datos personales de tus usuarios, pero conviene saberlo.
  2. Copias entre regiones. Si tienes replicación de S3 o copias de RDS hacia una región de EE. UU. “por si acaso”, acabas de crear una transferencia internacional que hay que documentar.
  3. Servicios de IA. Algunos modelos de Bedrock o servicios de análisis solo están disponibles en determinadas regiones. Antes de mandarles datos de clientes, comprueba dónde se procesan.

Desde el marco de adecuación UE-EE. UU. la situación es más manejable que en la era post-Schrems II, pero “más manejable” no significa “ignorable”: las transferencias hay que documentarlas igualmente.

Qué configurar en la cuenta

Estas son las medidas técnicas que un auditor va a esperar ver, y que además son las que de verdad reducen el riesgo:

Cifrado en reposo. Activa el cifrado por defecto de EBS en cada región. Cifra los buckets de S3 que contengan datos personales y las instancias RDS. Usa KMS con rotación activada.

Cifrado en tránsito. TLS en todo. Fuerza HTTPS en CloudFront y en los balanceadores; rechaza conexiones sin cifrar en RDS.

Mínimo privilegio. Que un desarrollador pueda hacer SELECT * sobre la tabla de clientes en producción es un problema de RGPD, no solo de seguridad.

Trazabilidad. CloudTrail activo en todas las regiones, con los logs en un bucket que las cuentas operativas no puedan borrar. Si mañana hay una brecha, tienes 72 horas para notificar a la AEPD, y sin registros no vas a poder decir qué pasó ni a cuántas personas afectó.

Retención y borrado. El derecho de supresión implica poder borrar de verdad. Reglas de ciclo de vida en S3, y un procedimiento escrito para borrar a una persona de tus bases de datos, de tus copias de seguridad y de tus logs. Las copias de seguridad son donde casi todo el mundo falla.

Datos personales en los logs. Este es el hallazgo silencioso. Aplicaciones que escriben correos, DNIs o direcciones en CloudWatch Logs con retención infinita. Eso es tratamiento de datos personales sin base ni límite temporal.

Errores que veo con frecuencia

  • Entornos de desarrollo con datos reales. Copiar la base de datos de producción a staging para “probar con datos de verdad” es una violación en toda regla.
  • Copias de seguridad eternas. Snapshots de hace tres años con datos de clientes que ejercieron su derecho de supresión el año pasado.
  • Buckets de logs sin ciclo de vida.
  • Nadie sabe qué buckets contienen datos personales. Si no puedes responder a eso en cinco minutos, no tienes control.

Un punto de partida razonable

  1. Inventaría dónde hay datos personales: qué buckets, qué bases de datos, qué logs.
  2. Comprueba que todo eso está en una región europea y cifrado.
  3. Revisa quién tiene acceso a cada uno de esos sitios.
  4. Pon retención a los logs. Todos.
  5. Escribe el procedimiento de borrado, incluyendo copias de seguridad.
  6. Verifica que CloudTrail está activo y protegido.

Con eso cubierto, la conversación con tu asesor legal es mucho más corta.

Preguntas frecuentes

¿Usar AWS me hace cumplir el RGPD? No. AWS cumple su parte como encargado del tratamiento. La configuración, el control de accesos, la retención y la capacidad de demostrarlo siguen siendo responsabilidad tuya como responsable del tratamiento.

¿Tengo que usar la región de España? No es obligatorio. Cualquier región de la UE mantiene los datos en reposo dentro del espacio europeo. La región de España puede tener sentido por latencia o por requisitos de contratación pública.

¿Puedo usar servicios de IA de AWS con datos de clientes? Depende del servicio y de la región donde se procese. Compruébalo antes, no después.

Trabaja conmigo: auditoría de seguridad en AWS.

Sigue leyendo: los 30 puntos que reviso en cada auditoría.

¿Sabrías decir hoy qué buckets contienen datos personales? Si la respuesta tarda más de cinco minutos, merece la pena una revisión. Te digo qué hay, dónde está y quién puede verlo. Ver la auditoría de seguridad