Datos de salud (Artículo 9 RGPD) detectados sin base jurídica adecuada
NutriTrack Pro procesa datos de categoría especial (diagnósticos nutricionales, IMC, intolerancias) sin consentimiento explícito separado ni contrato de encargo de tratamiento (DPA) firmado con las clínicas. Esto constituye la brecha de mayor riesgo regulatorio. No se recomienda el lanzamiento público hasta su resolución.
1 · Mapeo de categorías de datos y bases jurídicas
| Categoría de dato | Ejemplos concretos | Nivel RGPD | Base jurídica actual | Base recomendada | Estado |
|---|---|---|---|---|---|
| Identificación básica pacientes | Nombre, email, teléfono, fecha nacimiento | Estándar | Contrato implícito | Contrato (Art. 6.1.b) | ⚠ Documentar |
| Datos de salud | Peso, IMC, diagnósticos, intolerancias, historial mediciones | Art. 9 — Especial | ❌ Sin documentar | Consentimiento explícito (Art. 9.2.a) | ✕ Crítico |
| Datos de uso de app | Sesiones, registros alimentos, check-ins, frecuencia | Estándar | Interés legítimo implícito | Interés legítimo (Art. 6.1.f) + LIA | ⚠ Documentar |
| Datos de pago — clínicas | Nombre empresa, CIF, IBAN, facturación | Estándar B2B | Contrato B2B | Contrato (Art. 6.1.b) + obligación legal (Art. 6.1.c) | ✓ Adecuado |
| Cookies y analytics | Google Analytics, comportamiento navegación, IP | Estándar | ❌ Sin consentimiento | Consentimiento (Art. 6.1.a) + ePrivacy | ✕ Crítico |
| Datos de menores | Pacientes pediátricos (< 14 años) | Menores | ❌ Sin protocolo | Consentimiento parental verificado | ✕ Crítico |
2 · Bases jurídicas aplicables (Art. 6)
Art. 6.1.a — Aplicar a
Consentimiento
Cookies analytics y marketing · Newsletters y comunicaciones · Datos de salud (Art. 9.2.a — forma cualificada)
Requiere: opt-in activo, granular por finalidad, revocable fácilmente, documentado con timestamp + IP.
Requiere: opt-in activo, granular por finalidad, revocable fácilmente, documentado con timestamp + IP.
Art. 6.1.b — Aplicar a
Ejecución de contrato
Cuenta de usuario del dietista · Contrato SaaS con clínicas · Datos básicos de pacientes necesarios para el servicio
Requiere: DPA firmado con cada clínica (clínica = responsable, NutriTrack = encargado).
Requiere: DPA firmado con cada clínica (clínica = responsable, NutriTrack = encargado).
Art. 6.1.c — Aplicar a
Obligación legal
Registros contables y facturación (Ley 58/2003 General Tributaria — 4 años) · Registros laborales (si aplica)
Estos datos NO pueden borrarse ante DSAR de erasure mientras dure la obligación legal.
Estos datos NO pueden borrarse ante DSAR de erasure mientras dure la obligación legal.
Art. 6.1.f — Aplicar a
Interés legítimo
Analytics de uso agregado (mejora del servicio) · Detección de fraude · Seguridad del sistema
Requiere: Legitimate Interest Assessment (LIA) documentada. No aplicable a datos Art. 9.
Requiere: Legitimate Interest Assessment (LIA) documentada. No aplicable a datos Art. 9.
3 · Gap analysis — Estado actual vs. RGPD
Sin DPA con clínicas
ART. 28 RGPD
Las clínicas son responsables del tratamiento de datos de sus pacientes. NutriTrack actúa como encargado. Sin contrato de encargo de tratamiento firmado, toda la relación es ilegal bajo RGPD.
Datos salud sin consentimiento explícito
ART. 9 RGPD
Los datos de IMC, diagnósticos y historial nutricional son categoría especial. Requieren consentimiento explícito separado ("Acepto que NutriTrack procese mis datos de salud para..."), no vale consentimiento genérico.
Google Analytics sin banner de consentimiento
ART. 6.1.a + LSSI
Actualmente se carga GA en todas las páginas sin solicitar consentimiento. Esto viola RGPD y la LSSI española. Multas de la AEPD por este motivo superan los 150.000€ en casos similares.
Sin Registro de Actividades (ROPA)
ART. 30 RGPD
Obligatorio para organizaciones que tratan datos a gran escala o datos especiales. Debe documentar finalidades, categorías, destinatarios, plazos de supresión y medidas de seguridad.
Sin DPIA para datos de salud
ART. 35 RGPD
El tratamiento a gran escala de datos de salud requiere Evaluación de Impacto (DPIA) antes de iniciar el tratamiento. Debe identificar y mitigar riesgos específicos del sistema.
Política de privacidad incompleta
ART. 13-14 RGPD
Faltan: plazos de retención por categoría, base jurídica explícita para cada finalidad, información sobre transferencias a Google (para GA), y datos de contacto del DPD si procede.
Sin procedimiento de respuesta a DSAR
ART. 15-22 RGPD
No existe canal formal para que pacientes ejerzan sus derechos (acceso, rectificación, borrado, portabilidad). El plazo de respuesta es 30 días. Sin proceso documentado hay riesgo de incumplimiento.
Transferencias internacionales — Cumple
ART. 46 RGPD
La infraestructura está en AWS eu-west-1 (Irlanda). AWS cuenta con SCCs actualizadas post-Schrems II. No hay transferencias a terceros países sin garantías. Punto positivo.
4 · Derechos de los interesados — Estado de implementación
Art. 15 RGPD
Derecho de acceso
⏱ Plazo: 30 días
No implementado
Crear endpoint /api/dsar/access que exporte todos los datos del usuario en JSON. Añadir formulario en ajustes de cuenta.
Art. 16 RGPD
Derecho de rectificación
⏱ Plazo: 30 días
No implementado
La app permite editar perfil, pero no hay proceso formal para corrección de datos erróneos con confirmación.
Art. 17 RGPD
Derecho al olvido
⏱ Plazo: 30 días
No implementado
Implementar soft-delete + hard-delete programado a 30 días. Excepciones: datos fiscales (7 años). Necesita cascada a backups.
Art. 18 RGPD
Limitación del tratamiento
⏱ Plazo: 30 días
No implementado
Añadir flag processing_restricted a nivel de usuario. El sistema debe bloquear tratamientos no esenciales cuando está activo.
Art. 20 RGPD
Portabilidad de datos
⏱ Plazo: 30 días
No implementado
Exportar historial completo en CSV o JSON estructurado. Incluir: mediciones, registros alimentarios, objetivos. No incluye datos anonimizados de analytics.
Art. 21 RGPD
Derecho de oposición
⏱ Plazo: inmediato
Parcial
Existe opción de "darse de baja de emails", pero no cubre oposición al tratamiento por interés legítimo. Ampliar gestión de preferencias.
5 · Políticas de retención recomendadas
6 · Protocolo notificación de brechas (Art. 33-34)
🔍
H+0
Detección brecha
📞
H+1
Notificar DPD y equipo de seguridad
📋
H+4
Documentar alcance y categorías afectadas
🛡️
H+12
Contención y medidas inmediatas
🏛️
H+72
Notificación a AEPD (si riesgo) — LÍMITE LEGAL
📬
Según severidad
Notificación a afectados (si alto riesgo)
7 · Checklist priorizada para el equipo de desarrollo
🚨
Prioridad 1 — Antes de beta (2 semanas)!
Firmar DPA con cada clínica — Plantilla DPA RGPD Art. 28, cláusulas de subencargados (AWS, Stripe), obligaciones de notificación de brecha.
P1
!
Implementar consentimiento explícito Art. 9 — Pantalla separada al registrar paciente con finalidad de salud, granular, revocable. Guardar timestamp + IP + versión.
P1
!
Banner de consentimiento de cookies — Bloquear GA hasta consentimiento. Usar CMPKit o Cookiebot. Separar necesarias / analytics / marketing.
P1
!
Actualizar política de privacidad — Añadir: plazos retención, bases jurídicas, transferencia a Google, derechos ejercibles con canal de contacto.
P1
⚠️
Prioridad 2 — Antes del lanzamiento (4 semanas)!
Crear flujo DSAR completo — Formulario en "Mi cuenta", proceso interno de 30 días, exportación JSON, soft-delete + confirmación de borrado.
P2
!
Elaborar ROPA (Art. 30) — Registro de actividades de tratamiento con todas las categorías, finalidades, bases jurídicas y plazos. Formato Excel o herramienta DPA.
P2
!
DPIA para datos de salud — Evaluación de impacto siguiendo metodología AEPD. Documentar riesgos y controles. Puede requerir consultar AEPD.
P2
!
Implementar retención automática — Job cron semanal que aplique políticas de retención. Anonymize analytics > 13 meses. Notificar antes de borrar cuentas inactivas.
P2
✅
Prioridad 3 — Mejora continua (post-lanzamiento)~
Auditoría anual de cumplimiento — Revisar ROPA, contratos DPA activos, consentimientos caducados y terceros subencargados.
P3
~
Cifrado de PII en base de datos — Separar datos identificadores (cifrados) de datos de comportamiento (pseudonimizados). Rotación de claves anual.
P3
~
Formación del equipo en RGPD — Sesión de 2h para devs y customer success. Actualizar onboarding de empleados. Designar coordinador de privacidad.
P3
✓
Infraestructura en UE — Cumple — AWS eu-west-1, SCCs activas. No requiere acción inmediata.
OK
✓
TLS en tránsito — Cumple — Certificados Let's Encrypt activos, HSTS habilitado, no se transmiten datos en claro.
OK
✓
Contratos con proveedores UE — Cumple — Stripe (SCCs), AWS (SCCs), SendGrid (SCCs). Revisar anualmente.
OK