Medidas técnicas y organizativas (TOMs) – flowgeist ZERO
Fecha: 29.08.2026
Versión: 1.3
Ámbito de aplicación: Art. 32 RGPD, Art. 28 apdo. 3 let. c RGPD
1. Control de acceso físico
Medidas para impedir el acceso no autorizado a las instalaciones donde se operan los sistemas de tratamiento de datos:
- Centro de datos: Hosting en Hetzner Online GmbH, centro de datos Falkenstein, Alemania
- Personal de seguridad: Personal de seguridad in situ 24/7 para el control de acceso físico
- Control de acceso: Acceso al centro de datos exclusivamente para personal autorizado con autenticación multifactor (tarjeta chip + PIN/biometría)
- Registro de visitantes: Registro completo de todas las personas que acceden al centro de datos, incluyendo fecha, hora, duración y persona acompañante
- Videovigilancia: Vigilancia CCTV de las áreas exteriores y accesos del centro de datos
- Registro de accesos: Registro electrónico de todos los eventos de acceso con marca de tiempo e identificación de persona
- Suministro eléctrico de emergencia: Suministro eléctrico ininterrumpido (SAI) y generadores diésel de emergencia para toda la operación del centro de datos
- Climatización: Climatización redundante para garantizar las condiciones de operación
- Protección contra incendios: Sistemas de alerta temprana y sistemas automáticos de extinción de incendios
2. Control de acceso lógico
Medidas para impedir el uso no autorizado de los sistemas de tratamiento de datos:
- Autenticación multifactor (MFA/TOTP): MFA está disponible como opción; los usuarios pueden activar MFA mediante Time-based One-Time Password (TOTP). Una MFA obligatoria para roles administrativos está planificada.
- Role-Based Access Control (RBAC): Concepto de acceso basado en roles que regula el acceso a datos y funciones según el rol asignado
- Principio de Least Privilege: Cada usuario y sistema recibe únicamente los permisos mínimos necesarios para el cumplimiento de sus tareas
- JWT (JSON Web Token): Access-Tokens con una validez de 15 minutos; tras su expiración se requiere una nueva autenticación o renovación del token
- Rotación de Refresh-Tokens: Renovación periódica de los Refresh-Tokens en cada uso para minimizar el riesgo de abuso; cada Refresh-Token solo puede utilizarse una vez
- Hashing de contraseñas Argon2id: Almacenamiento seguro de contraseñas mediante Argon2id con los siguientes parámetros:
- Memoria (m): 64 MiB
- Iteraciones (t): 3
- Paralelismo (p): 4
- Políticas de contraseñas: Longitud mínima de 12 caracteres. Los requisitos de complejidad (caracteres especiales, mayúsculas/minúsculas) y la verificación contra contraseñas comprometidas conocidas (HIBP/Pwned Passwords) están planificados.
- Gestión de sesiones: Gestión segura de sesiones de usuario con timeout automático por inactividad. Las cookies de sesión se establecen como HttpOnly y (en producción) Secure; la política SameSite es configurable por despliegue (por defecto: lax)
- Registro de accesos: Registro de todos los intentos de inicio de sesión (exitosos y fallidos) así como de todos los accesos administrativos
3. Control de transmisión
Medidas para impedir la lectura, copia, modificación o supresión no autorizada de datos personales durante la transmisión:
- TLS 1.2/1.3: Cifrado de la transmisión de datos entre cliente y servidor mediante Transport Layer Security (TLS) versiones 1.2 y 1.3. TLS 1.3 como versión mínima exclusiva es un objetivo.
- HSTS (HTTP Strict Transport Security): Exigencia de transmisión cifrada a través de HTTPS. HSTS se establece a nivel de aplicación (Helmet); HSTS a nivel de nginx con directiva Preload está planificado.
- Certificados TLS Let’s Encrypt: Emisión y renovación automáticas de certificados TLS a través de Let’s Encrypt
- Auto-rotación: Rotación automática de los certificados TLS antes de su expiración para garantizar un funcionamiento ininterrumpido
- Perfect Forward Secrecy (PFS): Uso de Cipher-Suites con Perfect Forward Secrecy, de modo que el compromiso de la clave privada no afecte a la confidencialidad de conexiones pasadas
- Cifrado de conexiones internas: Cifrado de la comunicación entre servicios internos. TLS para conexiones de base de datos (sslmode=require) está planificado.
- Comunicación API segura: Todos los endpoints de API requieren autenticación y transmisión cifrada
4. Control de entrada
Medidas para garantizar que pueda verificarse y determinarse a posteriori si y por quién se han introducido, modificado o eliminado datos personales en los sistemas de tratamiento de datos:
- Audit-Trail conforme a ISO 27001 A.12.4: Registro completo de todos los eventos relevantes para la seguridad y cambios de datos
- Append-only por convención: Los Audit-Logs se mantienen append-only por convención (solo operaciones CREATE). El almacenamiento técnico WORM, la cadena de hash o la inmutabilidad a nivel de base de datos están planificados.
- Contenido del log: Cada entrada de Audit-Log contiene al menos los siguientes campos:
- Timestamp (UTC, formato ISO 8601)
- User-ID (identifica al usuario actuante)
- Tenant-ID (identifica la asignación relacionada con el inquilino)
- Acción (tipo de operación realizada, p. ej. CREATE, READ, UPDATE, DELETE)
- Recurso (objeto de datos o endpoint afectado)
- Dirección IP (dirección IP de origen de la solicitud)
- User-Agent (en eventos de autenticación; no se almacena en el registro de auditoría de dominio)
- Registro centralizado: Recopilación de todos los logs en un sistema central y protegido de logs
- Registro de acciones de administración: Registro por separado de todas las actividades administrativas y cambios del sistema
5. Control de encargo
Medidas para garantizar que los datos personales tratados por encargo solo puedan tratarse conforme a las instrucciones del Responsable del tratamiento:
- Tratamiento únicamente en el marco del AVV: El tratamiento de datos personales se realiza exclusivamente sobre la base del contrato de encargado del tratamiento celebrado (art. 28 RGPD)
- Vinculación a las instrucciones: Todas las operaciones de tratamiento se realizan según instrucción documentada del Responsable del tratamiento
- Sin transmisión sin autorización: La transmisión de datos a terceros se realiza exclusivamente con autorización previa del Responsable del tratamiento y sobre la base de un contrato de subencargado del tratamiento
- Documentación de instrucciones: Todas las instrucciones del Responsable del tratamiento se documentan y archivan de forma trazable
- Separación de encargos: Los datos de diferentes clientes se tratan estrictamente separados (véase Control de separación)
- Vinculación contractual de los subencargados del tratamiento: Con todos los subencargados del tratamiento se celebran AVV conforme al art. 28 apdo. 2 a 4 RGPD
6. Control de disponibilidad
Medidas para garantizar la disponibilidad de los sistemas y servicios de tratamiento de datos:
- Backups diarios: Diariamente se crean dumps de PostgreSQL cifrados (AES-256-CBC, PBKDF2) que además se replican cifrados en un almacenamiento externo offsite. Complementariamente existen snapshots de infraestructura de Hetzner.
- Hetzner Cloud Backup: Uso del servicio Hetzner Cloud Backup para snapshots a nivel de infraestructura
- Cifrado AES-256 at rest: Cifrado del almacenamiento de bases de datos y volúmenes at rest. Los dumps de backup se crean cifrados con AES-256 y se replican offsite.
- Conservación escalonada: Los backups offsite se conservan de forma escalonada (7 días diarios, 4 semanas semanales, 6 meses mensuales); los snapshots locales rotativos 7 días (a nivel de infraestructura)
- RTO (Recovery Time Objective): 8 horas – tiempo objetivo de recuperación tras un evento de fallo
- RPO (Recovery Point Objective): 24 horas – pérdida máxima de datos en caso de recuperación (corresponde al intervalo de backup diario)
- Aviso de riesgo: Un RPO de 24 horas significa que, en caso de fallo total, los datos pueden tener hasta 24 horas de antigüedad. Para datos críticos, el Responsable del tratamiento debería considerar medidas de respaldo adicionales.
- Componentes de sistema redundantes: Uso de componentes redundantes de servidor y red para minimizar los Single Points of Failure
- Monitoring: Monitoring continuo de la disponibilidad del sistema y del rendimiento con alertas automáticas ante incidencias
- Planes de emergencia: Planes de emergencia y recuperación documentados para diferentes escenarios de fallo
7. Control de separación
Medidas para garantizar que los datos personales tratados para diferentes finalidades puedan tratarse separadamente:
- Arquitectura Multi-Tenant: La plataforma soporta múltiples inquilinos (Tenants) con estricta separación de los conjuntos de datos
- Aislamiento de inquilino a nivel de base de datos: Los datos de diferentes inquilinos se aíslan a nivel de base de datos; un inquilino no puede acceder a los datos de otro inquilino
- JWT-Claims tenant-scoped: Los JSON Web Tokens contienen claims relacionados con el inquilino (tenant-scoped) que restringen estrictamente el acceso a los datos del propio inquilino
- Separación lógica: Los datos de diferentes finalidades de tratamiento se almacenan y gestionan separados lógicamente
- Separación de entornos de producción y pruebas: Estricta separación entre entornos de producción y de pruebas/desarrollo; en entornos de pruebas no se tratan datos personales reales
- Control de acceso relacionado con el inquilino: Los roles y permisos RBAC están configurados por inquilino; los accesos entre inquilinos están técnicamente excluidos
8. Cifrado
Medidas para garantizar la confidencialidad e integridad de los datos personales mediante cifrado:
- AES-256 at rest: Cifrado de todos los datos almacenados (bases de datos, backups, sistemas de archivos) con Advanced Encryption Standard (AES) con una longitud de clave de 256 bits
- TLS 1.2/1.3 in transit: Cifrado de todas las transmisiones de datos con Transport Layer Security (TLS) versiones 1.2 y 1.3. TLS 1.3 como versión mínima exclusiva es un objetivo.
- Gestión de claves: Gestión y rotación seguras de las claves de cifrado; las claves se almacenan separadas de los datos cifrados
- Enmascaramiento de IBAN: El IBAN se almacena enmascarado (solo visibles los últimos 4 dígitos); el titular de la cuenta se almacena cifrado con AES-256-GCM. Sin almacenamiento de datos completos de tarjetas de crédito.
- Hashing de contraseñas: Las contraseñas se almacenan hasheadas con Argon2id (m=64MiB, t=3, p=4); las contraseñas en texto plano no se almacenan en ningún momento
- Cifrado de backups: Los dumps de backup se crean cifrados con AES-256 y se replican cifrados en un almacenamiento externo offsite. Las pruebas de restauración se realizan periódicamente y se documentan.
9. Seudonimización
Medidas para la seudonimización de datos personales:
- Anonimización de datos de contacto de referrals: Los datos personales de contacto (correo electrónico, nombre, teléfono) en registros de referral de alto riesgo se sustituyen por un hash SHA-256 tras 30 días mediante un job de anonimización automatizado. En los registros de auditoría no se almacenan direcciones de correo electrónico — los usuarios se referencian mediante IDs internos
- Nombres eliminados/hasheados tras el plazo de conservación: Tras el vencimiento del respectivo plazo de conservación, los nombres y otros rasgos identificativos se eliminan o se sustituyen por valores hash
- Stripe-Webhook-Logs: Los Stripe-Webhook-Logs almacenan los datos técnicos del evento (incluido el payload de Stripe) para trazabilidad y análisis de errores. La seudonimización automatizada de los datos personales contenidos tras 30 días no está implementada actualmente y está planificada
- Referenciación basada en tokens: Los datos de pago se referencian a través de Stripe-Kunden-IDs; los datos de pago reales permanecen en Stripe y no se almacenan en texto plano en flowgeist
- Tenant-ID como seudónimo: En logs y registros se utiliza la Tenant-ID para la identificación de inquilinos, que no permite una inferencia directa sobre personas físicas
10. Revisión periódica
Medidas para la revisión y evaluación periódicas de la eficacia de las medidas técnicas y organizativas:
- TOM-Review anual: Revisión y actualización exhaustivas anuales de las medidas técnicas y organizativas por parte del Responsable del tratamiento
- Tests de penetración cada 24 meses: Realización de tests de penetración por auditores internos o externos con una periodicidad bienal para la identificación de vulnerabilidades
- Escaneos de vulnerabilidades trimestrales: Escaneos automatizados trimestrales de vulnerabilidades de sistemas y aplicaciones para la detección temprana de brechas de seguridad
- ISO 27001 objetivo: La introducción de un Sistema de Gestión de Seguridad de la Información (SGSI) conforme a ISO/IEC 27001 es un objetivo; las medidas actuales ya se orientan a los requisitos de ISO 27001
- Security Patch Management: Instalación periódica y puntual de actualizaciones de seguridad y parches para todos los componentes del sistema
- Incident Response Plan: Plan de emergencia documentado y practicado periódicamente para incidentes de seguridad
- Sensibilización de empleados: Formación y sensibilización periódicas de los empleados en materia de seguridad de la información y protección de datos
- Revisión de subencargados del tratamiento: Revisión periódica de las medidas adoptadas por los subencargados del tratamiento
11. Subencargados del tratamiento
Los siguientes subencargados del tratamiento se utilizan en el marco del tratamiento de datos personales:
| Subencargado del tratamiento | Sede / País | Servicio | Transferencia a países terceros | Garantías |
|---|
| Hetzner Online GmbH | Falkenstein, Alemania (DE) | Hosting, infraestructura de servidores, backups | Sin transferencia a países terceros | AVV conforme al art. 28 RGPD |
| Stripe Payments Europe, Ltd. | Irlanda (IE) / EE. UU. (US) | Procesamiento de pagos | EU-US DPF + SCC | AVV conforme al art. 28 RGPD; certificación DPF |
| Mailjet (Sinch Mailjet SAS) | Francia (FR) | Envío de correos electrónicos (correos transaccionales) | Sin transferencia a terceros países | AVV conforme al art. 28 RGPD |
| Mistral AI | Francia (FR) | Generación de textos por IA para campos de cumplimiento | Sin transferencia a países terceros | AVV conforme al art. 28 RGPD |
| Lexware GmbH | Alemania (DE) | Contabilidad, facturación | Sin transferencia a países terceros | AVV conforme al art. 28 RGPD |
| Nextcloud GmbH | Alemania (DE) | DMS / almacenamiento de documentos WebDAV (app de retención para archivos de informes AI Act) | Sin transferencia a países terceros | AVV conforme al art. 28 RGPD |
| Umami | UE (hosting) | Analítica web (respetuosa con la privacidad, sin cookies) | Sin transferencia a países terceros | AVV conforme al art. 28 RGPD |
Con todos los subencargados del tratamiento mencionados se han celebrado contratos de encargado del tratamiento conforme al art. 28 apdo. 2 a 4 RGPD que garantizan el cumplimiento de los requisitos del RGPD.
12. Historial de cambios
| Versión | Fecha | Cambios principales |
|---|
| 1.0 | 02.05.2026 | Primera versión |
| 1.1 | 23.06.2026 | Finalización; incorporación de subencargados del tratamiento |
| 1.2 | 08.08.2026 | Adaptación específica para flowgeist ZERO; ampliación de medidas de seudonimización y Audit-Trail |
| 1.3 | 29.08.2026 | Alineación con código: MFA marcada como opcional, política de contraseñas corregida, TLS 1.2/1.3 en lugar de 1.3-only, enmascaramiento de IBAN en lugar de cifrado, WORM marcado como convencional, nota de backup sobre snapshots de infraestructura, Nextcloud y Umami añadidos como subencargados |
| 1.4 | 22.09.2026 | Revisión de código: proveedor de correo Postmark → Mailjet (UE, Francia) — la transferencia a terceros países para correo ya no aplica; sección de backups actualizada a la replicación offsite AES-256 implementada |
| 1.5 | 22.09.2026 | Revisión de código (puntos restantes): afirmación de hash de correo sustituida por la implementación real (anonimización SHA-256 de datos de contacto de referrals tras 30 días; los registros de auditoría referencian IDs internos); seudonimización de Stripe webhooks marcada como planificada; campo User-Agent precisado a eventos de autenticación; flags de cookies documentados como configurables por despliegue |