Medidas técnicas y organizativas – flowgeist ZERO

Version 1.2 · Stand: 08.08.2026

flowgeist ZERO flowgeist KITA flowgeist TOOL flowgeist FOOD CombiJornada

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

Fecha: 08.08.2026 Versión: 1.2 Á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): Todos los accesos administrativos y de usuario requieren autenticación multifactor mediante Time-based One-Time Password (TOTP)
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, requisitos de complejidad, verificación contra contraseñas comprometidas conocidas
Gestión de sesiones: Gestión segura de sesiones de usuario con timeout automático por inactividad
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.3: Cifrado de toda la transmisión de datos entre cliente y servidor mediante Transport Layer Security (TLS) versión 1.3; las versiones anteriores de TLS no son compatibles
HSTS (HTTP Strict Transport Security): Exigencia de transmisión cifrada a través de HTTPS; cabecera HSTS con directiva Preload
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 y bases de datos
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
WORM-Logs (Write Once, Read Many): Registro a prueba de manipulaciones que impide la modificación o supresión posterior de entradas de log
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 (identificación del cliente del sistema solicitante)
Inmutabilidad: Los Audit-Logs no pueden ser modificados por usuarios o administradores
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: Copia de seguridad automática diaria de todas las bases de datos y datos del sistema a las 03:00 UTC
Hetzner Cloud Backup: Uso del servicio Hetzner Cloud Backup para backups automatizados y cifrados
Cifrado AES-256 at rest: Todos los backups se almacenan cifrados con AES-256
7 días rotativos: Los backups se conservan durante un período de 7 días y se sobrescriben de forma rotativa
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.3 in transit: Cifrado de todas las transmisiones de datos con Transport Layer Security (TLS) versión 1.3
Gestión de claves: Gestión y rotación seguras de las claves de cifrado; las claves se almacenan separadas de los datos cifrados
Cifrado de IBAN: El IBAN se almacena cifrado en la base de datos; 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: Todos los backups se cifran con AES-256, tanto en el almacenamiento como en la transferencia

9. Seudonimización

Medidas para la seudonimización de datos personales:

Hash SHA-256 de correo electrónico con salt en Audit-Logs: En los Audit-Logs las direcciones de correo electrónico no se almacenan en texto plano, sino como hash SHA-256 con salt, para reducir la identificabilidad
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
Seudonimización de Stripe-Webhook-Logs: Los Stripe-Webhook-Logs con PII (Personally Identifiable Information) se seudonimizan tras 30 días; la información relacionada con personas se sustituye por identificadores seudónimos
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
Postmark / ActiveCampaign	EE. UU. (US)	Envío de correos electrónicos (correos transaccionales)	EU-US DPF + SCC	AVV conforme al art. 28 RGPD; certificación DPF
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

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