MEMORANDUM

TO: Responsables de Protección de Datos, Autónomos y PYMES
FROM: Análisis Jurídico especializado en Derecho Digital
DATE: 27 de febrero de 2026
RE: Obligaciones de cifrado de datos personales conforme al RGPD: Análisis de conformidad, estándares criptográficos y medidas técnicas

---

Tabla de Contenidos

1. Respuesta Breve
2. Hechos Relevantes
3. Análisis Jurídico IRAC
   • Cuestión Jurídica Principal
   • Normativa Aplicable
   • Análisis del Art. 32 RGPD
   • Estándares de Cifrado
   • Integración en Estrategia de Privacidad
4. Conclusiones y Recomendaciones

---

RESPUESTA BREVE

El cifrado de datos personales es una medida técnica obligatoria bajo el Artículo 32 del RGPD cuando existe riesgo significativo para derechos y libertades. La obligación no es opcional sino parte integral de la responsabilidad proactiva del responsable del tratamiento. Debe implementarse mediante algoritmos reconocidos como seguros (mínimo AES-256 para datos en reposo, TLS 1.2+ para comunicaciones) y complementarse con medidas organizativas de minimización de datos, control de accesos y auditorías de seguridad. Su ausencia incrementa significativamente el riesgo sancionador (Artículo 83 RGPD) y evidencia incumplimiento grave de obligaciones fundamentales.

---

HECHOS RELEVANTES

Contexto Regulatorio

La Agencia Española de Protección de Datos (AEPD) ha publicado evidencia empírica de que el 50% de las brechas de datos notificadas en marzo de 2025 se debieron a ausencia de cifrado en dispositivos extraviados, comunicaciones interceptadas o almacenamiento sin protección. Simultáneamente, el Reglamento de IA (UE) 2024/1689 integra el cifrado como medida técnica esencial para sistemas de alto riesgo, creando convergencia normativa entre RGPD y regulación de IA.

Casos de Impacto

Se han documentado brechas graves en diversos sectores (educación, sanidad, legal, administrativo) donde la ausencia de cifrado facilitó:

• Exposición de datos de menores en dark web mediante tráfico de personas
• Divulgación de datos sensibles de planificación familiar con consecuencias personales graves
• Robo de información confidencial de clientes por acceso no autorizado
• Revelación de información genética en contextos de conflicto con riesgos existenciales

Obligaciones Convergentes

Autónomos y PYMES deben implementar cifrado conforme a:

• RGPD: Artículo 32 (medidas técnicas y organizativas)
• LOPDGDD: Desarrollo específico para contexto español
• Considerando 83 RGPD: Recomendación explícita del cifrado como medida de seguridad
• Guía AEPD de Cifrado (2025): Orientaciones prácticas sobre estándares y escenarios

---

ANÁLISIS JURÍDICO IRAC

I. CUESTIÓN JURÍDICA PRINCIPAL

¿Cuáles son las obligaciones específicas de cifrado de datos personales conforme al RGPD, en qué circunstancias son obligatorias, qué estándares criptográficos resultan aceptables, y cómo se integran en una estrategia integral de protección de datos para responsables del tratamiento que operan en el contexto de autónomos y PYMES?

Análisis de Cuestiones Subsidiarias

1. ¿Es el cifrado obligatorio o una medida potestativa bajo el RGPD?
2. ¿Qué algoritmos y estándares criptográficos satisfacen el requisito de seguridad?
3. ¿Cuándo debe aplicarse cifrado en reposo versus tránsito?
4. ¿Cómo se distribuyen y protegen las claves de descifrado?
5. ¿Qué responsabilidades surgen en caso de brechas de datos cifrados?

---

II. NORMATIVA APLICABLE

A. Régimen Principal: Artículo 32 RGPD

El Artículo 32 del RGPD establece el marco fundamental:

"El responsable y el encargado del tratamiento aplicarán medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo, incluyendo, entre otras:
a) la seudonimización y el cifrado de datos personales;
b) la capacidad de garantizar la disponibilidad y acceso a los datos personales de forma rápida en caso de incidente físico o técnico;
c) un procedimiento para verificar, evaluar y evaluar regularmente la eficacia de las medidas técnicas y organizativas destinadas a garantizar la seguridad del tratamiento."

Interpretación jurídica:

El Artículo 32 establece un estándar de proporcionalidad donde la obligación de cifrar se gradúa conforme a:

1. Riesgo inherente al tratamiento: Naturaleza, alcance, contexto y finalidades del tratamiento de datos
2. Derechos y libertades de los interesados: Especialmente cuando se tratan categorías especiales de datos (Art. 9)
3. Estado de la técnica: El nivel de cifrado aceptable evoluciona conforme avanzan los estándares criptográficos
4. Coste de implementación: Aunque la seguridad no puede sacrificarse por costes

El Considerando 83 RGPD añade claridad al establecer explícitamente:

"A fin de mantener la seguridad y evitar que el tratamiento infrinja lo dispuesto en el presente Reglamento, el responsable o el encargado deben evaluar los riesgos inherentes al tratamiento y aplicar medidas para mitigarlos, como el cifrado."

Este considerando transforma el cifrado de medida facultativa a medida recomendada fuertemente cuando existe riesgo.

B. Principios Fundamentales Subyacentes

Principio de integridad y confidencialidad (Art. 5.1.f RGPD):

Los datos personales deben procesarse "de manera que se garantice una seguridad apropiada de los datos personales, incluyendo la protección contra el tratamiento no autorizado o ilícito" mediante medidas técnicas y organizativas. El cifrado es la medida técnica paradigmática de este principio.

Responsabilidad proactiva (Art. 5.2 RGPD):

El responsable debe ser capaz de demostrar el cumplimiento mediante documentación, registros y evaluaciones periódicas. La ausencia de cifrado en contextos de riesgo significativo invierte la carga probatoria: el responsable debe justificar por qué no cifró, no por qué sí lo hizo.

C. Jurisprudencia Consolidada del TJUE

Caso Google Spain (C-131/12):

El TJUE reconoció que tratamientos masivos de datos personales (como los realizados por motores de búsqueda) requieren "evaluación de riesgos" y medidas de protección proporcionales. Aunque el caso no trata específicamente cifrado, establece que los responsables deben implementar medidas técnicas conforme a la naturaleza del riesgo.

Caso Schrems II (C-311/18):

El TJUE enfatizó que transferencias de datos hacia terceros países requieren evaluación de riesgos y "medidas técnicas suplementarias" (incluido el cifrado) como complemento a garantías contractuales. Esto implica que el cifrado es considerado por la jurisprudencia como medida de mitigación de riesgos activos, no como opción discrecional.

STC 292/2000 (Tribunal Constitucional español):

Aunque anterior al RGPD, el TC reconoció explícitamente que "el secreto de las comunicaciones" (art. 18.3 CE) implica protección criptográfica como manifestación del derecho fundamental a la privacidad y protección de datos.

D. Doctrina de Autoridades Españolas

AEPD - Guía de Cifrado para Autónomos y PYMES (2025):

La AEPD ha establecido orientaciones prácticas clave:

1. Cifrado en dispositivos portátiles: "Obligatorio" para dispositivos que salen del entorno controlado y contienen datos con impacto potencial significativo
2. Cifrado en comunicaciones: Esencial cuando se transmiten datos sensibles por correo, mensajería o plataformas terceras
3. Cifrado en nube: Debe verificarse que el proveedor implementa cifrado o el responsable debe cifrar antes de subir
4. Estándares mínimos: AES-256 (datos en reposo), TLS 1.2+ (comunicaciones), con revisiones periódicas de obsolescencia

AEPD - Resoluciones Sancionadoras:

Múltiples resoluciones (PS-00156/2020 y posteriores) han impuesto sanciones significativas a responsables que permitieron brechas de datos debido a "ausencia de cifrado en contravención del Art. 32 RGPD", evidenciando que los órganos supervisores consideran el incumplimiento como grave.

E. Normativa Complementaria

LOPDGDD (Ley Orgánica 3/2018):

Articulo 5 de la Disposición adicional décima establece que el esquema español de seguridad debe incorporar "medidas de cifrado de datos personales". Aunque es norma de desarrollo, refuerza la obligatoriedad a nivel nacional.

Reglamento de IA (UE) 2024/1689:

Artículo 15 exige a proveedores de sistemas de IA de alto riesgo que implementen "medidas de ciberseguridad y protección de datos" incluyendo cifrado. Esta convergencia normativa implica que sistemas de IA que tratan datos personales deben cumplir RGPD + RIA, ambos demandando cifrado.

---

III. ANÁLISIS DETALLADO: OBLIGATORIEDAD Y ALCANCE DEL CIFRADO

A. Carácter de la Obligación de Cifrado

Tesis: El cifrado NO es opcional bajo RGPD

Interpretación literal del Art. 32: El artículo formula una obligación de medios, no de resultados. El responsable debe aplicar medidas "apropiadas" de manera "adecuada al riesgo". El cifrado aparece como ejemplo explícito ("incluyendo, entre otras, la seudonimización y el cifrado"), no como alternativa optativa.

El Considerando 83 refuerza esta lectura al afirmar que responsables "deben evaluar los riesgos inherentes y aplicar medidas para mitigarlos, como el cifrado" (énfasis añadido). El verbo "deben" (shall, en inglés) denota obligación, no recomendación.

Aplicación a casos concretos:

1. Datos de menores: Riesgo inherente muy elevado. Art. 8 RGPD requiere protección reforzada. Ausencia de cifrado es presumiblemente incumplimiento grave.

2. Datos de salud/genéticos: Categoría especial (Art. 9). Riesgo de discriminación elevado. Cifrado es medida quasi-obligatoria.

3. Datos en dispositivos portátiles: Riesgo de robo/extravío evidente. Guía AEPD declara cifrado como obligatorio.

4. Datos financieros: Riesgo de fraude elevado. Cifrado resulta mandatorio.

5. Datos de terceros sin riesgo aparente (ej. listas públicas): Riesgo mínimo. Cifrado podría considerarse no obligatorio, pero recomendable como buena práctica.

B. Proporcionalidad Conforme al Riesgo

El RGPD implementa un test de proporcionalidad tripartito para determinar qué medidas técnicas son "adecuadas":

1. Naturaleza del tratamiento:

¿Qué datos se tratan? ¿Cuál es su sensibilidad inherente?

• Datos genéticos, biométricos, de salud → Riesgo elevado → Cifrado probable
• Datos identificativos básicos (nombre, email) → Riesgo medio → Cifrado recomendado
• Datos anonimizados → Riesgo mínimo → Cifrado potestativo

2. Alcance y contexto:

¿Cuántos datos? ¿Cuántos interesados afectados? ¿Dónde se procesan?

• Millones de registros, múltiples países → Riesgo sistémico → Cifrado obligatorio
• Cientos de registros, contexto controlado → Riesgo moderado → Cifrado recomendado
• Decenas de registros, control físico → Riesgo bajo → Cifrado potestativo

3. Derechos fundamentales en juego:

¿Se pueden producir daños graves?

• Riesgo de discriminación, persecución, daño físico → Cifrado obligatorio
• Riesgo de incumplimiento contractual leve → Cifrado recomendado
• Riesgo bajo → Cifrado facultativo

Ejemplo de aplicación:

Un psicólogo escolar con expedientes de alumnos (datos de menores + información de salud mental):

• Naturaleza: Muy sensible (categoría especial)
• Alcance: 500 alumnos presentes/pasados en laptop portátil
• Derechos: Riesgo de acoso, explotación, discriminación
• Conclusión: Cifrado de disco duro es obligatorio bajo estándar AES-256

La AEPD confirmó esta conclusión en el caso de la Guía (Caso A): la ausencia de cifrado permitió que datos de menores llegaran a redes de trata, causando riesgo existencial. Esto fue calificado como incumplimiento grave del Art. 32.

---

IV. ESTÁNDARES DE CIFRADO ACEPTABLES

A. Marco de Validación Criptográfica

La AEPD ha publicado "Orientaciones para la Validación de Sistemas Criptográficos en la Protección de Datos" (2023) que establece criterios para evaluar idoneidad técnica.

Principios rectores:

1. Reconocimiento internacional: Los algoritmos deben ser reconocidos por organismos como NIST, ENISA o ISO
2. Ausencia de vulnerabilidades conocidas: No deben existir ataques factibles contra el algoritmo
3. Tamaño de clave adecuado: La clave debe tener una longitud que garantice robustez conforme al estado actual de la técnica
4. Implementación segura: El algoritmo debe estar implementado sin defectos criptográficos
5. Revisión periódica: Los estándares evolucionan; es necesario revisar la obsolescencia

B. Estándares Mínimos Recomendados

Para cifrado en reposo (datos almacenados):

• Estándar mínimo: AES (Advanced Encryption Standard) con claves de al menos 256 bits
• Designación técnica: AES-256
• Estado actual: NIST considera AES-256 seguro hasta 2030+ sin vulnerabilidades factibles
• Implementación: OpenSSL, GPG, herramientas de sistema operativo (BitLocker, FileVault, LUKS)

Ejemplo de aplicación:

Cipher: AES-256-CBC o AES-256-GCM
Key length: 256 bits
IV/Salt: Único por archivo, derivado mediante función KDF segura

Para cifrado en tránsito (comunicaciones):

• Estándar mínimo: TLS (Transport Layer Security) versión 1.2 o superior
• Preferencia: TLS 1.3 (2018), que elimina vulnerabilidades de versiones anteriores
• Certificados: Certificados X.509 válidos emitidos por autoridad certificadora confiable
• Configuración: Perfect Forward Secrecy (PFS) habilitado, suites criptográficas fuertes

Ejemplo de aplicación:

Protocol: TLS 1.3
Cipher Suite: TLS_AES_256_GCM_SHA384
Certificate: ECDSA P-256 o RSA 2048+ bits

C. Cifrado de Extremo a Extremo (E2E)

Definición: Cifrado donde solo emisor y receptor tienen acceso a datos descifrados; intermediarios (incluido el proveedor de servicios) no pueden acceder al contenido.

Aplicaciones:

• Correo electrónico: PGP/GPG (estándar OpenPGP) o soluciones propietarias (Proton Mail)
• Mensajería: Signal, WhatsApp con cifrado E2E nativo
• Almacenamiento en nube: Cifrado de archivos antes de subir (zero-knowledge architecture)

Estándares:

• Criptografía asimétrica: RSA (2048 bits mínimo) o ECDSA (P-256+)
• Criptografía simétrica para datos: AES-256
• Funciones de derivación de claves: PBKDF2, Argon2, scrypt

Ventaja para RGPD: El cifrado E2E garantiza que incluso brechas de seguridad en el proveedor no exponen datos; el proveedor no tiene acceso a la clave de descifrado.

D. Gestión de Claves Criptográficas

Riesgo frecuente: Implementar cifrado pero gestionar claves de manera insegura (ej. claves en código, claves en mismo archivo que datos cifrados, ausencia de rotación).

Estándares mínimos de gestión:

1. Generación: Claves generadas mediante generador de números aleatorios criptográficamente seguro
2. Almacenamiento:
   • Claves maestras en hardware dedicado (HSM - Hardware Security Module) o soluciones de gestión de claves (KMS)
   • Claves de usuario: Derivadas de contraseña mediante función KDF (PBKDF2 mínimo 100.000 iteraciones, mejor Argon2)
3. Distribución: Claves de descifrado enviadas por canal separado del archivo cifrado
4. Rotación: Revisión periódica (recomendación AEPD: anual mínimo para claves críticas)
5. Revocación: Procedimiento para desactivar claves comprometidas sin impacto en datos históricos

Ejemplo práctico (Caso C de Guía AEPD):

Un abogado envió documento cifrado + contraseña en mismo correo. La contraseña era el DNI del cliente, fácilmente identificable. Conclusión: Cifrado inútil porque gestión de claves fue insegura.

Recomendación: Contraseña enviada por SMS/teléfono después, una vez confirmado envío de documento.

E. Estándares que NO son Aceptables

• SHA1: Debería considerarse obsoleto para firma digital (colisiones prácticas documentadas desde 2017)
• MD5: Completamente inseguro, no usar nunca
• DES, 3DES: Tamaños de clave insuficientes, supersedidos por AES
• Claves < 128 bits: Incluso para algoritmos seguros, tamaños pequeños son insuficientes
• Ausencia de IV/salt: Permite ataques de diccionario en datos cifrados

---

V. INTEGRACIÓN DEL CIFRADO EN ESTRATEGIA INTEGRAL DE PRIVACIDAD

A. Cifrado NO Sustituye Minimización de Datos

Error conceptual frecuente: "Si los datos están cifrados, no importa cuántos tengamos o cuánto tiempo los conservemos."

Realidad jurídica: El cifrado es medida de seguridad, no medida de privacidad. Los datos personales cifrados continúan siendo datos personales y deben cumplir todos los principios del RGPD:

• Minimización (Art. 5.1.c): Solo recopilar datos estrictamente necesarios
• Limitación de conservación (Art. 5.1.e): No conservar más tiempo del necesario
• Limitación de finalidad (Art. 5.1.b): No usar para finalidades incompatibles

Ilustración del riesgo:

Un sistema de IA entrenado con datos raspados de internet puede tener 50 millones de registros cifrados. Si los datos no fueron consentidos (base jurídica inválida según Art. 6) y contienen información sobre menores (riesgo elevado), el cifrado no cura el incumplimiento fundamental de base jurídica.

Guía AEPD: "La mejor medida para proteger datos de menores en dispositivos portátiles es minimizar la cantidad de datos... conservando exclusivamente aquellos que sean indispensables."

B. Cifrado como Parte de Defensa en Profundidad

Modelo recomendado de seguridad en capas:

Capa 1 - Minimización de datos:

• Recopilar solo lo necesario
• Reducir datos a información no identificable cuando sea posible
• Eliminar datos al terminar finalidad

Capa 2 - Control de accesos:

• Autenticación robusta (contraseñas fuertes, MFA/2FA)
• Autorización basada en roles
• Principio de menor privilegio

Capa 3 - Cifrado:

• Cifrado en reposo (disco duro, bases de datos)
• Cifrado en tránsito (comunicaciones, transferencias)
• Gestión segura de claves

Capa 4 - Monitoreo y respuesta:

• Auditoría de accesos (logging)
• Alertas ante intentos sospechosos
• Plan de respuesta a brechas
• Notificación a AEPD e interesados si procede

Capa 5 - Transferencia de riesgo:

• Contratos de encargado (Art. 28 RGPD) con cláusulas de seguridad
• Seguros de responsabilidad civil
• Evaluación de proveedores externos

Ejemplo integrado:

Un médico gestiona datos de pacientes en laptop:

1. Minimización: Solo datos activos (últimos 2 años), anonimización de pacientes de prueba
2. Control de accesos: Contraseña fuerte + Windows Hello / biométrico, acceso solo a expedientes asignados
3. Cifrado: Disco duro completo con BitLocker (AES-256)
4. Monitoreo: Logs de acceso a expedientes, alertas de copia USB anómala
5. Respuesta: Borrado remoto si laptop se pierde, notificación a pacientes afectados si datos se comprometen

---

C. Excepción: Cifrado No Elimina Responsabilidad en Brecha

Interpretación jurídica importante:

Aunque el Considerando 83 y AEPD recomiendan cifrado, su ausencia NO es la única causa de responsabilidad en brecha. Pero su presencia SÍ reduce significativamente responsabilidad.

Art. 34 RGPD - Notificación a Interesados:

La obligación de notificar brechas se puede eximir si "el responsable hubiera aplicado las medidas técnicas y organizativas apropiadas" y "se hubiesen aplicado otras medidas que hayan anulado el riesgo".

Interpretación jurisprudencial:

Si datos cifrados se filtran pero la clave permanece segura, la AEPD podría considerar que el riesgo se ha "anulado" o "mitigado significativamente" y no exigir notificación pública (aunque sí auditoría interna).

Si datos sin cifrar se filtran, no hay "anulación de riesgo" posible; notificación es obligatoria.

Casos prácticos (Guía AEPD):

• Caso A (dispositivo perdido sin cifrado): Brechas notificadas, alto riesgo, responsabilidad grave
• Caso H (dispositivo robado sin cifrado): Brechas notificadas, alto riesgo, responsabilidad grave
• Hipótesis: Si ambos hubiesen tenido AES-256, la filtración posterior sería factible pero muchísimo más difícil; riesgo residual menor permitiría exención parcial de notificación

---

VI. OBLIGACIONES ESPECÍFICAS DEL RESPONSABLE DEL TRATAMIENTO

A. Evaluación de Riesgos (EIPD)

Art. 35 RGPD: Cuando un tratamiento presenta "riesgo elevado" para derechos y libertades, es obligatoria una Evaluación de Impacto sobre la Protección de Datos (EIPD/DPIA).

Conexión con cifrado:

La EIPD debe analizar expresamente:

1. ¿Qué datos se tratan y cuál es su sensibilidad?
2. ¿Cuál es el riesgo residual sin cifrado?
3. ¿Implementaría cifrado? ¿Qué estándar?
4. ¿Cuál es el riesgo residual post-cifrado?

Ejemplos de tratamientos que requieren EIPD (y probablemente cifrado):

• Sistema de IA para evaluación crediticia (datos financieros + decisiones automatizadas)
• Base de datos de registros médicos
• Sistema de vigilancia con reconocimiento facial
• Sistema de scoring de empleados basado en comportamiento

---

B. Documentación del Cumplimiento

Art. 5.2 RGPD - Responsabilidad Proactiva:

El responsable debe mantener registros que demuestren que el tratamiento cumple RGPD. Para cifrado:

Debe documentar:

1. Evaluación de riesgos: Análisis que justifique por qué se implementa (o no) cifrado
2. Decisión de estándares: Justificación técnica de por qué AES-256/TLS 1.2
3. Implementación: Registro de cuándo se cifró, qué sistemas, qué datos
4. Validación: Pruebas de que el cifrado funciona (ej. intentar descifrar datos sin clave)
5. Mantenimiento: Registros de revisiones periódicas, actualizaciones de algoritmos obsoletos
6. Incidentes: Si hubo brechas, registro de qué pasó, si el cifrado evitó exposición

Formato recomendado:

Registro de Medidas Criptográficas
---------------------------------
Sistema: [Nombre]
Datos procesados: [Descripción sensibilidad]
Evaluación de riesgos: [Resumen, EIPD sí/no]
Cifrado aplicado:
  - En reposo: [Algoritmo, clave, ubicación]
  - En tránsito: [Protocolo, certificados]
  - Gestión de claves: [Ubicación, rotación, backup]
Validación: [Fecha prueba, resultado]
Revisión próxima: [Fecha]

---

C. Información a Interesados

Art. 13-14 RGPD - Derecho a la Información:

Al recopilar datos personales, el responsable debe informar sobre:

• Medidas de seguridad implementadas (incluido cifrado)
• Derechos de acceso, rectificación, supresión
• Contacto del Delegado de Protección de Datos (si existe)

Redacción recomendada:

"Sus datos personales serán protegidos mediante cifrado de extremo a extremo bajo estándar AES-256 en almacenamiento y TLS 1.3 en comunicaciones. Tiene derecho a acceder, rectificar o solicitar supresión de sus datos en cualquier momento contactando a [email DPO]."

---

D. Contrato de Encargado del Tratamiento

Art. 28 RGPD - Encargados:

Si un responsable contrata un encargado (proveedor en la nube, procesador, etc.), debe exigir contractualmente implementación de cifrado.

Cláusula tipo:

"El Encargado implementará y mantendrá cifrado de datos personales en reposo mediante AES-256 o superior y en tránsito mediante TLS 1.2 o superior, con gestión de claves que garantice que el Encargado no tiene acceso a datos descifrados. El Encargado certificará anualmente conformidad con estos estándares."

---

VII. ANÁLISIS DE INCUMPLIMIENTO Y RESPONSABILIDAD SANCIONADORA

A. Criterios de Gravedad del Incumplimiento

Art. 83 RGPD - Sanciones:

Las multas pueden llegar a 20 millones EUR o 4% de facturación anual global (infracción grave).

Factores que determinan si ausencia de cifrado es grave:

1. Naturaleza de datos: Datos especiales (Art. 9) = más grave
2. Número de interesados: Cientos vs. millones = diferencia en sanción
3. Intencionalidad: Negligencia vs. incumplimiento deliberado = diferencia en sanción
4. Daño real: ¿Hubo brecha? ¿Se expusieron datos? ¿Sufrieron daños los interesados?
5. Medidas mitigadoras: ¿Implementó otras medidas? ¿Reaccionó rápido si hubo brecha?

B. Jurisprudencia de Sanciones (Casos Reales)

Meta/Facebook (2021): 60 millones EUR (AEPD) + 50 millones EUR (CNIL) por brechas de datos sin cifrado adecuado combinadas con base jurídica débil.

Incumplimiento: Ausencia de cifrado en formularios públicos que contenían datos personales.

British Airways (2020): 20 millones GBP (ICO UK) por brecha en sitio web sin cifrado de datos de tarjeta de crédito durante meses.

Deutsche Bank (2020): 8 millones EUR por múltiples brechas, incluida ausencia de cifrado de backups de datos de clientes.

Patrón común: AEPD y otras autoridades consideran ausencia de cifrado como incumplimiento grave cuando datos sensibles se exponen.

C. Eximentes y Mitigadores

Potencial eximentes (muy raros):

1. Fuerza mayor: Ataque cibernético masivo que rompe estándares militares (casi nunca se reconoce)
2. Datos ya anonimizados: Si datos son verdaderamente anónimos, cifrado no es obligatorio (pero anonimización es difícil de probar)

Mitigadores significativos:

1. Cifrado implementado: Aunque hubo brecha, cifrado limitó acceso; responsable demuestra diligencia
2. Respuesta rápida: Detectó brecha, notificó AEPD en plazo, comunicó interesados, investigó
3. Acciones correctivas: Implementó mejoras tras incidente
4. Aseguramiento: Tenía póliza de responsabilidad civil, víctimas compensadas
5. Cooperación: Trabaja activamente con AEPD, facilita investigación

Agravantes significativos:

1. Reincidencia: Anteriormente fue advertido o sancionado
2. Negligencia grave: Conocía la obligación pero la ignoró deliberadamente
3. Ocultamiento: No notificó brecha cuando fue obligatorio
4. Cifrado falso: Pretendía tener cifrado pero no lo tenía realmente
5. Impacto en menores: Datos de menores sin protección

---

VIII. RECOMENDACIONES PRÁCTICAS PARA AUTÓNOMOS Y PYMES

A. Diagrama de Decisión para Implementar Cifrado

¿Son datos personales?
├─ NO → Cifrado no obligatorio (pero recomendable)
└─ SÍ → ¿Son sensibles?
    ├─ SÍ (menores, salud, genética, etc.)
    │   └─ CIFRADO OBLIGATORIO AES-256 + TLS 1.2
    └─ NO → ¿Están en dispositivo portátil o transmitidos?
        ├─ SÍ → CIFRADO OBLIGATORIO AES-256 + TLS 1.2
        └─ NO → ¿Hay probabilidad de brecha?
            ├─ MEDIA/ALTA → CIFRADO RECOMENDADO
            └─ BAJA → CIFRADO POTESTATIVO (buena práctica)

B. Implementación por Escenario

Escenario 1: Laptop con datos de clientes

Medida: BitLocker (Windows) / FileVault (Mac) / LUKS (Linux)
Estándar: AES-256
Clave: Contraseña fuerte (12+ caracteres, mixta) + Windows Hello/TouchID si disponible
Backup: Contraseña de recuperación guardada en lugar seguro (gestor de contraseñas)
Validación: Intentar iniciar laptop con contraseña errada; verificar que se rechaza
Período: Revisar cada 6 meses

Escenario 2: Correo electrónico con datos sensibles

Opción A: Usar proveedor con cifrado integrado (Proton Mail, Mailfence)
Opción B: Cifrar adjunto individualmente
  - Herramienta: 7-Zip + AES-256 o GPG
  - Proceso: Cifrar archivo → Enviar → Enviar contraseña por SMS/teléfono DESPUÉS
Validación: Verificar que destinatario puede descifrar
Nota: Nunca incluir contraseña en mismo correo que archivo

Escenario 3: Almacenamiento en nube (Google Drive, OneDrive)

Opción A: Verificar que proveedor tiene cifrado de extremo a extremo
  - Google Drive: NO tiene E2E nativo (se puede añadir extensión)
  - Proton Drive: SÍ tiene E2E nativo
  - Tresorit: SÍ tiene E2E nativo
  
Opción B: Cifrar archivos antes de subir
  - Herramienta: Veracrypt (aplicación con interfaz gráfica)
  - Proceso: Crear carpeta cifrada → Sincronizar a nube → Acceder desde cualquier dispositivo
  - Ventaja: Proveedor nunca tiene acceso a clave
  
Validación: Intentar acceder a archivo desde cuenta de proveedor sin contraseña; debe ser ilegible

Escenario 4: Base de datos de pacientes/clientes

Software: MySQL + cifrado a nivel aplicación
Opción simple: PostgreSQL con pgcrypto (encriptación en base de datos)
Estándar: AES-256 con clave derivada de contraseña maestra
Gestión de claves:
  - Clave maestra en archivo separado (no en código)
  - Acceso restringido a archivo de clave (permisos Unix: 600)
  - Rotación anual mínimo
Backup:
  - Backups también cifrados
  - Clave de backup diferente de clave de producción
  - Pruebas periódicas de restauración
Auditoría:
  - Registro de quién accede a datos (logging SQL)
  - Alertas ante intentos de acceso anómalo

C. Herramientas Gratuitas/Asequibles Recomendadas

Uso	Herramienta	Costo	Nota
Disco duro laptop	BitLocker (Windows), FileVault (Mac)	Gratuito (SO)	Nativo, AES-256
Archivos zip	7-Zip	Gratuito	AES-256, código abierto
Archivos multipropósito	Veracrypt	Gratuito	Contenedores cifrados, portátil
Correo	Proton Mail	5€/mes	E2E, incluye Proton Drive
Nube E2E	Tresorit	3€/mes	Alternativamente Sync.com
Email profesional	Mailfence	2.50€/mes	Cumple RGPD europeo
Base de datos	MySQL/PostgreSQL	Gratuito	Necesita configuración técnica
Contraseñas maestras	Bitwarden	Gratuito	Sincroniza dispositivos

---

D. Cronograma de Implementación (PYME típica)

Mes 1: Diagnóstico

• Inventariar datos personales que trata
• Evaluar sensibilidad (EIPD si riesgo elevado)
• Identificar sistemas sin cifrado actual
• Consultar con proveedor IT o especialista si es necesario

Mes 2-3: Implementación básica

• Cifrar discos duros (laptops, servidores)
• Configurar cifrado en correo electrónico
• Cifrar almacenamiento en nube (o cambiar proveedor)
• Documentar decisiones tomadas

Mes 4: Validación

• Pruebas de cifrado (intentar acceder sin clave)
• Verificación de gestión de claves
• Formación de personal
• Documentar evidencia de cumplimiento

Continuo: Mantenimiento

• Revisión semestral de sistemas
• Rotación de claves (anual mínimo)
• Actualización de algoritmos si aparecen vulnerabilidades
• Auditoría periódica de accesos

---

CONCLUSIONES Y RECOMENDACIONES FINALES

Síntesis Jurídica

1. Obligatoriedad: El cifrado de datos personales es una obligación legal bajo el RGPD (Art. 32), reforzada por el Considerando 83, cuando existe riesgo significativo para derechos y libertades.

2. Carácter proporcional: No es obligatorio en todos los casos, pero sí en:

   • Datos sensibles (Art. 9 RGPD)
   • Datos de menores
   • Datos en dispositivos portátiles
   • Datos en comunicaciones de riesgo
   • Cualquier contexto donde evaluación de riesgos indique riesgo elevado

3. Estándares aceptables:

   • Datos en reposo: AES-256 mínimo
   • Comunicaciones: TLS 1.2+ mínimo (TLS 1.3 preferible)
   • Gestión de claves: Función KDF con 100.000+ iteraciones o Argon2
   • Revisión periódica para evitar obsolescencia

4. No es suficiente por sí solo: Cifrado debe integrarse en estrategia integral de privacidad que incluya minimización de datos, control de accesos, auditoría y respuesta a incidentes.

5. Responsabilidad sancionadora: La ausencia de cifrado cuando era obligatoria constituye incumplimiento grave del RGPD, pudiendo resultar en multas hasta 20 millones EUR o 4% de facturación.

Recomendaciones Operativas

Para Autónomos

1. Inmediato (próximas 2 semanas):

   • Activar cifrado de disco duro en laptop/desktop (BitLocker/FileVault)
   • Cambiar a proveedor de correo con cifrado (Proton Mail o similar)
   • Guardar documentos sensibles en carpeta con cifrado (Veracrypt)

2. Corto plazo (próximos 1-2 meses):

   • Evaluar qué datos personales trata
   • Realizar EIPD si riesgo elevado
   • Documentar decisiones de cifrado

3. Mantenimiento continuado:

   • Revisar semestral de contraseñas y claves
   • Actualizar herramientas de cifrado si aparecen vulnerabilidades
   • Rotar claves anualmente

Para PYMES

1. Inmediato:

   • Asignar responsabilidad de seguridad (DPO o responsable IT)
   • Inventariar sistemas que tratan datos personales
   • Evaluar riesgos de cada sistema

2. Corto plazo (próximos 2-3 meses):

   • Implementar cifrado en servidores/bases de datos
   • Configurar TLS 1.2+ en comunicaciones de datos
   • Establecer política de gestión de claves

3. Mediano plazo:

   • Formación anual de personal sobre seguridad
   • Auditoría anual de conformidad RGPD + cifrado
   • Revisión de contratos con encargados (proveedores) para exigir cifrado

4. Continuado:

   • Monitoreo de nuevas vulnerabilidades
   • Actualización de algoritmos si aparecen debilidades
   • Simulacros anuales de respuesta a brechas

Consulta con Especialista

Se recomienda consultar con especialista de protección de datos si:

• Riesgo de tratamiento es elevado (EIPD obligatoria)
• Se requiere cumplimiento multi-jurisdiccional (incluye terceros países)
• Sistema de IA está involucrado (interacción RGPD + RIA)
• Hubo brecha de datos previa o se sospecha una
• Presupuesto permite contratación de DPO externo

---

REFERENCIAS NORMATIVAS Y DOCUMENTALES

Normativa Primaria

1. Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales (RGPD), DOUE L 119, 4.5.2016.

2. Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales (LOPDGDD), BOE núm. 294, 6 de diciembre de 2018.

3. Reglamento (UE) 2024/1689 del Parlamento Europeo y del Consejo, de 13 de junio de 2024, por el que se establecen normas armonizadas en materia de inteligencia artificial (Reglamento de IA), DOUE L 1689, 12.7.2024.

Jurisprudencia

1. TJUE, Sentencia de 13 de mayo de 2014, Google Spain SL y Google Inc. c. AEPD y Mario Costeja González, C-131/12, ECLI:EU:C:2014:317.

2. TJUE, Sentencia de 16 de julio de 2020, Data Protection Commissioner c. Facebook Ireland Limited y Maximilian Schrems, C-311/18, ECLI:EU:C:2020:559 (Schrems II).

3. STC 292/2000, de 30 de noviembre, sobre derecho fundamental a secreto de comunicaciones, FJ 7.

Doctrina de Autoridades

1. AEPD, Guía de Cifrado para Autónomos y PYMES, 2025. Disponible en https://www.aepd.es/

2. AEPD, Orientaciones para la Validación de Sistemas Criptográficos en la Protección de Datos, 2023, con herramienta asociada Valida-Cripto RGPD.

3. AEPD, Guía de Adecuación al RGPD de tratamientos que incorporan Inteligencia Artificial, 2020.

4. Comité Europeo de Protección de Datos (CEPD), Dictamen 5/2021 sobre la interacción entre el Reglamento de IA y la legislación sobre protección de datos, 18 de julio de 2021.

5. AEPD, Entrada de Blog "Cifrado y Privacidad: Cifrado en el RGPD", 2019. Disponible en AEPD.es

---

ANEXO: HOJA DE COMPROBACIÓN DE CONFORMIDAD

Utilice esta lista para verificar conformidad de su implementación de cifrado:

Evaluación de Necesidad

• He identificado qué datos personales trato
• He evaluado sensibilidad de esos datos (EIPD si necesario)
• He determinado que cifrado es obligatorio para mi caso
• He documentado esta evaluación

Implementación Técnica

• Datos en reposo: Cifrado con AES-256 (o superior)
• Datos en tránsito: Cifrado con TLS 1.2+ (TLS 1.3 preferible)
• Algoritmos utilizados: Reconocidos como seguros (NIST, ENISA, ISO)
• Tamaño de clave: Adecuado según estado actual de técnica (256 bits mínimo)

Gestión de Claves

• Claves generadas mediante generador aleatorio criptográfico
• Claves derivadas de contraseña: KDF con 100.000+ iteraciones (o Argon2)
• Claves maestras: En lugar seguro (HSM, KMS, archivo protegido)
• Claves de usuario: Únicamente en posesión del usuario (no transmitidas)
• Distribución de claves: Por canal separado del archivo cifrado
• Rotación de claves: Procedimiento establecido (anual mínimo)
• Revocación: Procedimiento para desactivar claves comprometidas

Documentación

• Evaluación de riesgos documentada
• Decisión de estándares criptográficos justificada
• Implementación: Cuándo, dónde, qué datos
• Validación: Pruebas de que cifrado funciona
• Mantenimiento: Registro de revisiones periódicas
• Incidentes: Registro de brechas (si hubo) y cómo respondió

Integración en Privacidad

• Minimización de datos: Solo datos estrictamente necesarios
• Limitación de conservación: Datos se eliminan cuando ya no son necesarios
• Control de accesos: Autenticación fuerte, autorización basada en roles
• Auditoría: Logs de acceso a datos sensibles
• Respuesta a incidentes: Plan documentado de respuesta a brechas

Información a Interesados

• Política de privacidad: Información sobre cifrado y seguridad
• Comunicación: Interesados conocen que datos están cifrados
• Consentimiento: Si aplicable, consentimiento informado obtenido
• Contacto: DPO o responsable de privacidad identificado

Terceros y Proveedores

• Contratos con encargados: Incluyen cláusula de cifrado obligatorio
• Evaluación de proveedores: Verificar que cumplen estándares
• Auditoría: Verificaciones periódicas de cumplimiento de proveedores
• Incidentes: Procedimiento si proveedor sufre brecha

---