Medidas técnicas y organizativas (TOMs) – flowgeist FOOD

Estado: 08.08.2026 Versión: 1.0 Ámbito de aplicación: Art. 32 RGPD, Art. 28 Abs. 3 lit. c RGPD

---

1. Control de acceso físico

El control de acceso físico a la infraestructura de servidores y a los locales comerciales de flowgeist se asegura mediante las siguientes medidas:

(1) Centro de datos (Hetzner Online GmbH, Falkenstein)

• Control de acceso físico por parte del centro de datos según la certificación ISO 27001 de Hetzner
• Control de acceso físico en varios niveles (tarjeta, biometría, esclusa de personas)
• Videovigilancia de las zonas de acceso y salas de servidores
• Personal de seguridad in situ 24/7
• Registro de todos los accesos

(2) Locales comerciales de flowgeist

• Acceso a los locales comerciales solo para personas autorizadas
• Sistema de cierre con registro
• Sin infraestructura de servidores física en los locales comerciales (solo en la nube)

(3) Dispositivos

• Acceso a los dispositivos de trabajo (portátiles, teléfonos móviles) protegido por contraseña/biometría
• Cifrado de disco duro (BitLocker / FileVault) en todos los dispositivos de trabajo
• Bloqueo automático de pantalla tras inactividad (5 minutos)

---

2. Control de acceso lógico

El control de acceso lógico asegura que solo personas autorizadas tengan acceso a datos personales y que los derechos de acceso se asignen según el principio de necesidad de conocimiento.

(1) Autenticación

• Autenticación mediante JWT (JSON Web Tokens) con rotación de refresh-token
• Apple Sign-In y Google Sign-In como métodos de autenticación
• Sin autenticación basada en contraseña (evitación de riesgos de contraseña)
• MFA (autenticación multifactor) opcional para accesos administrativos

(2) Control de acceso basado en roles (RBAC)

• Asignación de derechos de acceso según el modelo Role-Based Access Control (RBAC)
• Diferenciación entre rol de usuario y rol de administrador
• Principio de mínimo privilegio: cada rol recibe solo los derechos mínimamente necesarios
• Revisión regular de los derechos de acceso (al menos anualmente)

(3) Accesos administrativos

• Acceso al entorno de producción solo a través de conexiones cifradas (SSH con autenticación basada en claves)
• MFA para todos los accesos administrativos
• Registro de todos los accesos administrativos (pista de auditoría)
• Separación de entornos de desarrollo, staging y producción

(4) Aislamiento de usuarios

• Cada usuario solo tiene acceso a sus propios datos
• Las consultas a la base de datos están aisladas por usuario (multi-tenant con Row-Level-Security en PostgreSQL)
• No es posible el acceso entre usuarios

---

3. Control de transmisión

El control de transmisión asegura que los datos personales estén protegidos durante la transmisión contra el acceso no autorizado, alteración y divulgación.

(1) Cifrado de transporte

• TLS 1.3 para todas las transmisiones de datos (cliente-servidor, servidor-servidor)
• Desactivación de versiones anteriores de TLS (TLS 1.0, 1.1, 1.2 desactivados)
• Perfect Forward Secrecy (PFS) mediante intercambio de claves ECDHE

(2) HSTS (HTTP Strict Transport Security)

• HSTS activado para todas las conexiones a la aplicación flowgeist FOOD
• Include-Subdomains y lista Preload activadas
• Versión mínima de TLS 1.3

(3) Certificados

• Certificados TLS a través de Let’s Encrypt
• Renovación automática de certificados (ciclo de 90 días)
• Certificate Pinning en la aplicación nativa (iOS/Android)

(4) Seguridad de API

• Todos los endpoints de API a través de TLS 1.3
• Autenticación requerida para todas las llamadas a la API (JWT)
• Rate-Limiting para protección contra ataques de fuerza bruta
• Restricciones CORS (Cross-Origin Resource Sharing)

---

4. Control de entrada

El control de entrada asegura que todas las entradas y cambios en datos personales se registren de forma trazable.

(1) Pista de auditoría

• Registro completo de todos los accesos y cambios en datos personales
• Registro de: ID de usuario, marca de tiempo, acción (Create, Read, Update, Delete), categoría de datos afectada, dirección IP
• Los registros de auditoría se almacenan en una base de datos separada y de solo lectura

(2) Registros WORM (Write Once, Read Many)

• Los registros de auditoría se almacenan como registros WORM (escribibles una vez, de ahí solo legibles)
• Protección contra manipulación mediante procedimientos criptográficos (Hash-Chain)
• Los registros no pueden ser modificados ni eliminados posteriormente

(3) Registro reforzado para datos de salud

• Registro adicional para todos los accesos a datos de salud (Art. 9 RGPD)
• Registros de auditoría separados para datos del Art. 9 con mayor nivel de detalle
• Alertas ante patrones de acceso inusuales a datos de salud

(4) Conservación

• Los registros de auditoría se conservan durante 3 años
• Los registros WORM se eliminan automáticamente tras el vencimiento del plazo de conservación

---

5. Control de encargo

El control de encargo asegura que los datos tratados por encargo solo se traten conforme a las instrucciones del responsable.

(1) Vinculación a instrucciones

• Todos los procesos de tratamiento se realizan exclusivamente según instrucciones documentadas
• Las instrucciones se documentan por escrito y se archivan
• Ningún tratamiento fuera de las instrucciones dadas

(2) Subencargados del tratamiento

• Encargo de subencargados del tratamiento solo con consentimiento previo
• AVV con todos los subencargados del tratamiento conforme al Art. 28 Abs. 4 RGPD
• Revisión regular de los subencargados del tratamiento sobre el cumplimiento de las TOMs

(3) Separación de entornos

• Separación estricta de entornos de desarrollo, staging y producción
• Sin datos productivos en entornos de desarrollo o prueba
• Datos de prueba anonimizados o sintéticos para desarrollo

(4) Documentación

• Documentación completa de todos los procesos de tratamiento
• Registro de actividades de tratamiento conforme al Art. 30 RGPD mantenido y actualizado

---

6. Control de disponibilidad

El control de disponibilidad asegura que los datos personales estén protegidos contra destrucción accidental o pérdida y que se garantice la disponibilidad de la aplicación.

(1) Copias de seguridad

• Copias de seguridad completas diarias de la base de datos PostgreSQL 16
• Copias de seguridad incrementales cada hora
• Conservación de copias de seguridad: 30 días (copias diarias), 12 semanas (copias semanales)
• Verificación de copias de seguridad mediante pruebas de restauración regulares (mensuales)

(2) Copias de seguridad cifradas

• Todas las copias de seguridad se cifran con AES-256
• Las claves de copia de seguridad se almacenan separadas de los datos de copia de seguridad (Key Management)
• Las copias de seguridad se almacenan en un centro de datos / almacenamiento separado

(3) MinIO Object Storage

• Los datos de fotos se almacenan en MinIO Object Storage
• MinIO con Server-Side Encryption (compatible con SSE-S3, AES-256)
• Versionado de buckets activado (protección contra eliminación accidental)
• Lifecycle-Policies para limpieza automática

(4) Redis Cache

• Redis como caché en memoria para gestión de sesiones y rendimiento
• Redis Persistence activado (AOF - Append Only File)
• Los datos de Redis no contienen datos de salud (solo datos de sesión/caché)
• Failover automático en caso de fallo de Redis

(5) Alta disponibilidad

• Infraestructura de servidores redundante en Hetzner
• Load-Balancing para servidores de aplicaciones
• Failover automático en caso de fallo de servidor
• Monitoring y alerting 24/7

(6) Recuperación ante desastres

• Plan de recuperación ante desastres documentado
• Recovery Time Objective (RTO): 4 horas
• Recovery Point Objective (RPO): 1 hora
• Pruebas regulares de recuperación ante desastres (semestrales)

---

7. Control de separación

El control de separación asegura que los datos tratados para diferentes fines puedan tratarse de forma separada.

(1) Multi-Tenant (aislamiento de usuarios)

• Aislamiento estricto de los datos de usuarios individuales (arquitectura multi-tenant)
• Row-Level-Security (RLS) en PostgreSQL 16 a nivel de tabla
• Cada consulta a la base de datos está restringida por usuario
• No es posible el acceso entre usuarios

(2) Aislamiento de buckets MinIO

• Los datos de fotos se almacenan en buckets MinIO separados por usuario
• Las políticas de bucket impiden el acceso a buckets ajenos
• Acceso solo a través de llamadas a la API autenticadas y autorizadas

(3) Separación por categorías de datos

• Los datos de salud (Art. 9 RGPD) se almacenan en esquemas de base de datos separados
• Cifrado adicional a nivel de aplicación para campos de datos de salud
• Separación de registros de auditoría y datos de producción (base de datos separada)
• Separación de datos de desarrollo, staging y producción

(4) Separación de registros

• Los registros de auditoría se almacenan separados de los registros de aplicación
• El seguimiento de errores Sentry no recibe datos de salud (minimización de PII)
• Los registros del sistema no contienen datos personales maestros

---

8. Cifrado

El cifrado asegura que los datos personales estén protegidos tanto durante la transmisión como en reposo (at rest).

(1) Cifrado de transporte

• TLS 1.3 para todas las transmisiones de datos
• Perfect Forward Secrecy (PFS)
• HSTS activado
• Certificados a través de Let’s Encrypt con renovación automática

(2) Cifrado en reposo – Base de datos

• PostgreSQL 16 con Transparent Data Encryption (TDE) o Volume-Level Encryption
• Cifrado AES-256 para volúmenes de base de datos
• Copias de seguridad de base de datos cifradas con AES-256

(3) Cifrado en reposo – MinIO Object Storage

• MinIO Server-Side Encryption (SSE) con AES-256
• Los datos de fotos se almacenan cifrados
• Versionado de buckets y Lifecycle-Policies

(4) Cifrado en reposo – Redis

• Datos de Redis almacenados en volumen cifrado
• Redis no contiene datos de salud (solo datos de sesión/caché)

(5) Gestión de claves

• Gestión centralizada de claves (Key Management System)
• Rotación regular de claves (al menos anualmente)
• Separación de claves y datos cifrados
• Acceso a claves solo por administradores autorizados (MFA)

(6) Hashing de contraseñas

• Argon2id como procedimiento de hashing para contraseñas (en caso de utilizarse procedimientos basados en contraseña)
• Parámetros: memory cost, time cost y parallelism según las recomendaciones actuales de OWASP

---

9. Seudonimización

La seudonimización asegura que los datos personales ya no puedan atribuirse a una persona interesada específica sin recurrir a información adicional.

(1) Autenticación basada en token

• Autenticación basada en JWT sin almacenamiento de contraseñas en texto plano
• Token de Apple/Google Sign-In como seudónimo
• Sin vinculación directa entre token de autenticación y datos maestros

(2) Seguimiento de errores Sentry

• Minimización de PII: Sentry no recibe datos personales maestros ni datos de salud
• Los informes de errores contienen solo datos minimizados y seudonimizados
• Las direcciones IP se enmascaran o eliminan antes de la transmisión a Sentry

(3) Registros de auditoría

• Los registros de auditoría utilizan IDs de usuario (seudónimos) en lugar de nombres en texto plano
• La asignación de ID de usuario a datos maestros solo es posible por administradores autorizados

(4) Separación de datos

• Los datos de salud se almacenan separados de los datos maestros
• Vinculación solo a través de IDs seudonimizados
• Cifrado adicional a nivel de aplicación para datos de salud

---

10. Verificación regular

La verificación regular asegura que la eficacia de las medidas técnicas y organizativas se evalúe y mejore continuamente.

(1) Ciclo de verificación

• Revisión anual de las TOMs sobre actualidad y eficacia
• Revisión tras cambios sustanciales en la arquitectura del sistema
• Revisión tras incidentes de seguridad

(2) Auditorías de seguridad

• Auditorías de seguridad regulares (al menos anualmente)
• Penetration Testing por proveedores externos (anualmente)
• Vulnerability Scanning (automatizado, semanalmente)

(3) Gestión de parches

• Actualizaciones y parches regulares para todos los componentes del sistema
• Los parches de seguridad se priorizan y se aplican sin demora
• Monitoring de Security-Advisories (bases de datos CVE)

(4) Respuesta a incidentes

• Plan de respuesta a incidentes documentado
• Los incidentes de seguridad se clasifican y se tratan según su gravedad
• Post-Incident-Review tras cada incidente de seguridad
• Documentación y reporte conforme al Art. 33 RGPD

(5) Formación de empleados

• Formaciones regulares de protección de datos y seguridad para todos los empleados
• Awareness-Training para ingeniería social y phishing
• Formación ante cambios sustanciales en la arquitectura del sistema

(6) Alineación con ISO 27001

• Las TOMs están alineadas con los requisitos de ISO 27001
• Mejora continua en el sentido del ciclo PDCA (Plan-Do-Check-Act)

---

11. Subencargados del tratamiento

Los siguientes subencargados del tratamiento se emplean en el marco de la aplicación flowgeist FOOD:

Subencargado del tratamiento	Ubicación	Fin	Transferencia a terceros países	Mecanismo de protección
Hetzner Online GmbH	Falkenstein, Alemania (DE)	Hosting, PostgreSQL 16, MinIO Object Storage, Redis Cache	Ninguna (UE)	Certificación ISO 27001, AVV
Mistral AI SAS	Francia (FR)	Mistral Vision API para análisis de alimentos basado en fotos	Ninguna (solo UE)	Estado miembro de la UE, RGPD directamente aplicable, AVV
Sentry (Functional Software, Inc.)	EE. UU. (US)	Seguimiento de errores, diagnóstico de errores	EU-US DPF + SCC	EU-US Data Privacy Framework + Cláusulas Contractuales Tipo, minimización de PII

(1) Hetzner Online GmbH

• Centro de datos certificado ISO 27001 en Falkenstein, Alemania
• Todas las bases de datos, Object Storage y caché se operan aquí
• Sin transferencia a terceros países
• AVV conforme al Art. 28 Abs. 4 RGPD celebrado

(2) Mistral AI SAS

• Mistral Vision API para el análisis de alimentos basado en fotos
• Sede en Francia (Estado miembro de la UE), sin transferencia a terceros países
• El RGPD es directamente aplicable
• AVV conforme al Art. 28 Abs. 4 RGPD celebrado
• Los datos de fotos se eliminan tras el análisis (sin almacenamiento permanente en Mistral)

(3) Sentry (Functional Software, Inc.)

• Seguimiento de errores para diagnóstico y corrección de errores
• Sede en EE. UU. (tercer país)
• Mecanismos de protección: EU-US Data Privacy Framework (DPF) + Cláusulas Contractuales Tipo (SCC)
• Minimización de PII: No se transmiten datos de salud (Art. 9 RGPD) ni datos personales maestros a Sentry
• AVV conforme al Art. 28 Abs. 4 RGPD celebrado

---

12. Particularidades para datos de salud (Art. 9 RGPD)

Debido al tratamiento de datos de salud en el sentido del Art. 9 Abs. 1 RGPD (alergias, intolerancias, objetivos nutricionales, datos de nutrición relacionados con la salud), se aplican medidas de protección reforzadas:

(1) Cifrado adicional a nivel de aplicación para campos de datos de salud

• Los datos de salud se cifran a nivel de aplicación adicionalmente al cifrado de la base de datos (Field-Level Encryption)
• Procedimiento utilizado: AES-256-GCM
• Las claves se almacenan separadas de los datos cifrados (Envelope Encryption)
• Descifrado solo en el proceso de aplicación con contexto autorizado

(2) Registros de auditoría reforzados para acceso a datos del Art. 9

• Sistema de registro de auditoría separado para todos los accesos a datos de salud
• Registro de: ID de usuario, marca de tiempo (precisión de milisegundos), acción, campo, dirección IP, ID de sesión
• Alertas en tiempo real ante patrones de acceso inusuales (p. ej., exportación masiva, acceso fuera del horario de uso)
• Registros de auditoría como registros WORM (protegidos contra manipulación)
• Conservación: 3 años

(3) Registro de consentimiento con marca de tiempo y posibilidad de retirada

• Cada consentimiento para el tratamiento de datos de salud se registra completamente:
  • Marca de tiempo del consentimiento
  • Versión de la declaración de consentimiento
  • Dirección IP en el momento del consentimiento
  • ID de usuario
  • Alcance del consentimiento (qué categorías de datos)
• La retirada del consentimiento es posible en cualquier momento (en la aplicación y por correo electrónico)
• La retirada también se registra (marca de tiempo, dirección IP)
• Tras la retirada se procede a la eliminación inmediata de los datos de salud afectados

(4) Separación de datos

• Los datos de salud se almacenan en esquemas de base de datos separados
• Separación estricta entre datos maestros y datos de salud
• Vinculación solo a través de IDs seudonimizados

(5) Sin transferencia a terceros países

• Los datos de salud se tratan exclusivamente en Alemania (Hetzner) y Francia (Mistral AI, UE)
• Sin transmisión de datos de salud a Sentry (EE. UU.) u otros terceros países
• El seguimiento de errores Sentry está configurado para filtrar los datos de salud (Data Scrubbing)

(6) Limitación de acceso

• Acceso a datos de salud solo por roles autorizados (principio de mínimo privilegio)
• Sin acceso administrativo a datos de salud descifrados sin autorización explícita
• Los accesos de emergencia se registran separadamente y requieren justificación

---

13. Historial de cambios

Versión	Fecha	Cambios principales
1.0	08.08.2026	Primera versión de las TOMs para flowgeist FOOD