Artículo 32 GDPR: Medidas Técnicas de Seguridad

Todo el mundo habla del GDPR en términos de banners de cookies, políticas de privacidad y consentimiento explícito. Y sí, todo eso importa. Pero hay un artículo que la mayoría de equipos técnicos ignoran hasta que es demasiado tarde: el Artículo 32. Es el artículo que define cómo debes proteger los datos personales a nivel técnico y organizativo. No qué consentimiento pides, sino qué medidas de seguridad tienes implementadas para que esos datos no acaben donde no deben.

La pregunta incómoda: si mañana la AEPD te pide que demuestres qué medidas técnicas concretas tienes para proteger los datos personales que tratas, ¿puedes responder con evidencia? No con un documento genérico. Con evidencia técnica real: configuraciones, logs, políticas activas, resultados de tests.

Si la respuesta es "no estoy seguro", este artículo es para ti.

---

Qué dice el Artículo 32 del GDPR

El Artículo 32 del Reglamento General de Protección de Datos (RGPD/GDPR) establece que el responsable y el encargado del tratamiento deben implementar medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo. En concreto, exige cuatro capacidades:

1. Seudonimización y cifrado de datos personales.
2. Confidencialidad, integridad, disponibilidad y resiliencia permanentes de los sistemas y servicios de tratamiento.
3. Capacidad de restaurar la disponibilidad y el acceso a los datos personales de forma rápida en caso de incidente físico o técnico.
4. Proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas.

Un matiz que mucha gente pasa por alto: el artículo dice que las medidas deben ser "apropiadas al riesgo". No exige seguridad máxima en todos los casos. Exige proporcionalidad. Una startup que trata emails de contacto no necesita el mismo nivel de protección que un hospital que trata historiales clínicos. Pero ambos necesitan medidas concretas, documentadas y demostrables.

Lo que el Artículo 32 no te dice es qué tecnologías usar. Te da los objetivos. La implementación depende de tu stack. Y si tu infraestructura está en la nube, las medidas concretas son bastante claras.

---

Medidas técnicas concretas para empresas cloud

Vamos a traducir los requisitos abstractos del Artículo 32 en implementaciones técnicas específicas para entornos AWS, GCP y similares.

Cifrado (seudonimización y cifrado de datos personales)

Cifrado en reposo. Cada base de datos, cada volumen de almacenamiento y cada bucket que contenga datos personales debe estar cifrado. En la práctica: cifrado de volúmenes EBS, instancias RDS, buckets S3 con SSE-S3 o SSE-KMS, discos persistentes de GCE con CMEK o claves gestionadas por Google. Activarlo suele ser un checkbox. No activarlo es una deficiencia demostrable ante una auditoría.

Cifrado en tránsito. TLS 1.2 como mínimo en todos los endpoints que manejan datos personales. Cabeceras HSTS configuradas para forzar HTTPS. Certificados válidos y monitorizados. Si tienes un endpoint HTTP sin TLS que transmite datos personales, tienes un problema de Artículo 32.

Gestión de claves. Usar AWS KMS o GCP KMS con políticas de rotación automática. Las claves de cifrado no deben estar hardcodeadas en el código ni almacenadas junto a los datos que protegen. Documenta quién tiene acceso a las claves y con qué permisos.

Cifrado a nivel de campo. Para datos especialmente sensibles (datos de salud, datos financieros, identificadores nacionales), considera cifrado a nivel de campo en la base de datos. No todo necesita este nivel, pero si tratas datos de categorías especiales, la proporcionalidad del Artículo 32 lo puede exigir.

Confidencialidad (control de acceso)

Principio de mínimo privilegio en IAM. Cada usuario, cada service account, cada rol debe tener exclusivamente los permisos que necesita para su función. Nada más. En AWS, eso significa policies IAM granulares, no AdministratorAccess para todo el equipo. En GCP, roles predefinidos en lugar de Owner para service accounts.

MFA obligatorio. Autenticación multifactor para todos los accesos a la consola cloud, sin excepciones. Un usuario IAM con acceso a consola y sin MFA es una vulnerabilidad directa. Si ese usuario reutiliza una contraseña comprometida, el atacante entra sin obstáculos.

Control de acceso basado en roles (RBAC). Define roles claros (desarrollador, operaciones, seguridad, lectura) con permisos asociados. No permisos individuales por usuario. Los roles se auditan, los permisos individuales se olvidan.

Acceso a servicios internos. VPN o modelo zero-trust para acceder a recursos internos. Los paneles de administración, bases de datos y herramientas internas no deben ser accesibles directamente desde internet. Si tu panel de Grafana está abierto al mundo con autenticación básica, el Artículo 32 tiene algo que decirte.

Auditoría de acceso a datos. Registro de quién accede a qué datos personales, cuándo y por qué. No basta con controlar el acceso: necesitas poder demostrar que lo controlas.

Integridad (trazabilidad y detección de cambios)

Logging de actividad. CloudTrail en todas las regiones de AWS. Cloud Audit Logs en GCP. Activados, centralizados y protegidos. Sin logs de actividad no puedes detectar accesos no autorizados ni reconstruir qué pasó tras un incidente.

Logs inmutables. Los logs deben almacenarse en formato write-once. En AWS, esto se consigue con S3 Object Lock o CloudTrail Lake. Si un atacante puede borrar los logs después de comprometer una cuenta, los logs no sirven de nada.

Monitorización de integridad de ficheros. Para sistemas que almacenan datos personales en disco, herramientas de file integrity monitoring (FIM) que detecten cambios no autorizados en ficheros críticos de configuración o datos.

Infraestructura como código (IaC). Tu infraestructura definida en Terraform, CloudFormation o Pulumi, versionada en Git. Cualquier cambio en la configuración queda registrado con autor, fecha y motivo. Es trazabilidad de integridad aplicada a la infraestructura.

Disponibilidad y resiliencia

Despliegues multi-AZ. Los servicios que tratan datos personales deben estar desplegados en múltiples zonas de disponibilidad. Una caída de zona no debería significar pérdida de acceso a datos personales. En AWS: RDS Multi-AZ, Auto Scaling Groups distribuidos. En GCP: instancias regionales, Cloud SQL con alta disponibilidad.

Backups automatizados con restauración probada. No basta con tener backups. Necesitas backups automáticos con retención definida (mínimo 30 días es una referencia razonable) y, lo que es más importante, haber probado la restauración. Un backup que nunca se ha restaurado es una promesa sin verificar. El Artículo 32 exige capacidad de restauración, no intención de restauración.

Plan de disaster recovery documentado y probado. RTO y RPO definidos para cada servicio que trata datos personales. El plan debe haberse ejecutado en un simulacro, no solo escrito en un documento.

Auto-scaling para servicios críticos. Si un pico de tráfico legítimo tumba tu servicio y los datos personales dejan de estar disponibles, eso es un problema de disponibilidad bajo el Artículo 32. Auto-scaling no es solo rendimiento: es resiliencia.

Evaluación periódica (testing continuo)

Escaneo de vulnerabilidades continuo. No trimestral. No semestral. Continuo. Las vulnerabilidades aparecen cada día. Un escaneo que ejecutas una vez al trimestre te deja ciego durante 89 días. Herramientas de vulnerability scanning automatizado que evalúen tu superficie de ataque de forma permanente.

Pentesting externo. Al menos una vez al año. Un pentest externo realizado por un tercero independiente que intente comprometer tus sistemas como lo haría un atacante real. El Artículo 32 exige evaluación de la eficacia de las medidas, y un pentest es la forma más directa de hacerlo.

Revisiones de configuración de seguridad. Auditorías periódicas de las configuraciones de tus recursos cloud contra baselines reconocidos (CIS Benchmarks, por ejemplo). Esto es exactamente lo que hace un CSPM: evaluación continua de configuración.

Simulacros de respuesta a incidentes. ¿Tu equipo sabe qué hacer si se detecta una brecha de datos personales? ¿Quién notifica a la AEPD dentro de las 72 horas que exige el Artículo 33? Si no has probado tu plan de respuesta, no sabes si funciona.

---

Checklist práctico: Artículo 32 para startups y PYMEs

Si quieres una referencia rápida para evaluar tu postura de seguridad frente al Artículo 32, este checklist cubre los puntos esenciales. No es exhaustivo (depende de tu contexto de riesgo), pero si no cumples estos mínimos, tienes trabajo pendiente. Si gestionas seguridad sin equipo dedicado, mira cómo abordamos esto en Vulnerabbit para PYMEs: cubre los controles técnicos que el Artículo 32 considera "estado del arte" sin necesidad de un CISO.

Cifrado

• Cifrado en reposo activado en todas las bases de datos (RDS, Cloud SQL, Firestore)
• Cifrado en reposo activado en todo el almacenamiento (S3, GCS, EBS)
• TLS 1.2+ en todos los endpoints que transmiten datos personales
• Cabeceras HSTS configuradas en todos los dominios
• Claves de cifrado gestionadas con KMS (no hardcodeadas)
• Política de rotación de claves activa y documentada

Control de acceso

• MFA obligatorio para todos los accesos a consola cloud
• Política IAM de mínimo privilegio documentada y aplicada
• Roles RBAC definidos y asignados (no permisos individuales ad-hoc)
• Sin service accounts con permisos de administrador o Owner innecesarios
• Acceso a bases de datos y servicios internos restringido por VPN o zero-trust
• Access keys rotadas en los últimos 90 días

Logging e integridad

• CloudTrail / Cloud Audit Logs activos en todas las regiones y proyectos
• Logs almacenados en formato inmutable (write-once)
• Logs centralizados en una ubicación separada del entorno de producción
• Retención de logs mínima de 12 meses
• Infraestructura definida como código y versionada en Git

Disponibilidad y resiliencia

• Backups automáticos activos con retención mínima de 30 días
• Restauración de backups probada en los últimos 6 meses
• Servicios críticos desplegados en múltiples zonas de disponibilidad
• Plan de disaster recovery documentado con RTO y RPO definidos
• Simulacro de DR ejecutado en los últimos 12 meses

Evaluación y testing

• Escaneo de vulnerabilidades continuo activo
• Pentest externo realizado en los últimos 12 meses
• Revisión de configuraciones de seguridad cloud automatizada (CSPM)
• Plan de respuesta a incidentes documentado y comunicado al equipo
• Simulacro de respuesta a incidentes realizado en los últimos 12 meses
• Registro de actividades de tratamiento actualizado (Artículo 30 RGPD)

Si marcas menos de la mitad de esta lista, tu exposición al Artículo 32 es significativa. La buena noticia: la mayoría de estos puntos se pueden resolver en semanas, no meses.

---

Qué herramientas cubren qué medidas

El Artículo 32 no se cubre con una sola herramienta. Cada requisito mapea a un tipo de solución diferente. Esta es la relación:

CSPM (Cloud Security Posture Management) cubre la mayor superficie. Verifica cifrado en reposo y en tránsito, configuración IAM, políticas de logging, configuración de red, acceso a bases de datos. Si hablamos de los requisitos del Artículo 32, CSPM toca confidencialidad, integridad y gran parte del cifrado. Es la herramienta que más controles cubre de forma automatizada y continua.

ASM (Attack Surface Management) complementa la visión desde fuera. Descubre tu superficie expuesta a internet: subdominios, servicios accesibles, certificados SSL caducados o débiles, puertos abiertos que no deberían estarlo. Cubre confidencialidad desde la perspectiva del atacante. Si tienes un servicio con datos personales expuesto sin que lo sepas, ASM lo encuentra.

DAST y pentesting cubren la evaluación periódica. Un pentest externo valida que las medidas que tienes implementadas funcionan realmente contra un atacante. DAST (Dynamic Application Security Testing) automatiza parte de ese proceso para aplicaciones web. El Artículo 32 exige verificar la eficacia de las medidas, y esto es exactamente lo que hacen.

Herramientas de backup y DR cubren disponibilidad y resiliencia. AWS Backup, GCP Backup and DR, o soluciones de terceros. Lo importante no es solo tenerlas activas, sino probar la restauración y documentar los resultados.

Ninguna herramienta individual cubre el Artículo 32 completo. Pero una plataforma que combine CSPM, ASM y evaluación de vulnerabilidades cubre la mayoría de los requisitos técnicos de forma continua.

---

Artículo 32 vs ISO 27001

Si ya estás trabajando en la certificación ISO 27001, buena noticia: el solapamiento con el Artículo 32 es enorme. Los controles tecnológicos del Anexo A de ISO 27001:2022 (sección 8) cubren cifrado, control de acceso, logging, gestión de vulnerabilidades, backup y continuidad de negocio. Implementar esos 34 controles técnicos te deja en una posición sólida frente al Artículo 32.

La diferencia fundamental: el GDPR es ley. Su incumplimiento conlleva sanciones económicas directas. ISO 27001 es un estándar certificable voluntario. Ambos requieren evidencia demostrable de las medidas implementadas, pero las consecuencias de no cumplir son diferentes.

En la práctica, muchas empresas usan ISO 27001 como framework de implementación y el GDPR como obligación legal. Son compatibles y complementarios. Si implementas los controles técnicos de ISO 27001 con foco en datos personales, cumples la mayor parte del Artículo 32 automáticamente.

Otra normativa relevante para empresas en España es NIS2, que también exige medidas técnicas de seguridad y cuyo solapamiento con el Artículo 32 y con ISO 27001 es significativo.

---

Sanciones por incumplimiento del Artículo 32

Las sanciones por incumplimiento del Artículo 32 son reales y se aplican. El Artículo 83(4) del GDPR establece multas de hasta 10 millones de euros o el 2% de la facturación global anual (lo que sea mayor) por infracción de las obligaciones de seguridad del Artículo 32. Es el tramo inferior de sanciones del GDPR (el superior, para violaciones de principios y derechos, llega a 20 millones o 4% de facturación).

La AEPD (Agencia Española de Protección de Datos) ha impuesto sanciones a empresas españolas por carecer de medidas técnicas adecuadas. No hablamos de brechas sofisticadas: hablamos de bases de datos sin cifrar, accesos sin autenticación multifactor, ausencia de logs de actividad. Deficiencias que se detectan en minutos con las herramientas correctas.

El riesgo no es solo la multa. Una sanción por el Artículo 32 queda publicada. Es un impacto reputacional para cualquier empresa que gestione datos de clientes, especialmente en sectores regulados como fintech, healthtech o edtech.

---

Conclusión: la mayoría de medidas no son caras

Lo que hace especial al Artículo 32 es que la mayoría de las medidas técnicas que exige no son costosas de implementar. Cifrado en reposo es un checkbox en tu proveedor cloud. MFA es gratuito. CloudTrail se activa en una configuración. TLS es estándar. Backups automáticos son una opción nativa.

Lo difícil no es implementar. Lo difícil es saber qué te falta, mantenerlo de forma continua y poder demostrarlo con evidencia cuando alguien pregunte. Ahí es donde la diferencia entre "creemos que estamos bien" y "podemos demostrarlo" se vuelve relevante.

Si quieres saber en qué punto estás, puedes empezar con un escaneo gratuito de tu superficie de ataque. Te da una primera foto de lo que es visible desde fuera: certificados, puertos, servicios expuestos. Desde ahí, un CSPM continuo te cubre la configuración interna de tu cloud.

El Artículo 32 no pide perfección. Pide proporcionalidad, diligencia y evidencia. Con las herramientas correctas, cubrir esos tres puntos no es complicado.