Medidas técnicas y organizativas (TOMs) – flowgeist KITA
Versión: 08.08.2026
Versión: 1.0
Ámbito de aplicación: Art. 32 RGPD, Art. 28 Apdo. 3 let. c RGPD
1. Control de acceso físico
El control de acceso físico a los servidores y sistemas de TI en los que se tratan datos personales está garantizado por el proveedor de alojamiento Hetzner Online GmbH.
Medidas:
- Centro de datos de Falkenstein: Los servidores se operan en el centro de datos de Falkenstein (Alemania) de Hetzner Online GmbH.
- Personal de seguridad 24/7: El centro de datos cuenta con personal de seguridad las 24 horas del día.
- Control de acceso: El acceso al centro de datos está protegido por controles de acceso de múltiples etapas (tarjeta chip, PIN, procedimientos biométricos).
- Registro de visitantes: Todos los accesos y visitas se registran y son trazables.
- Videovigilancia: Las áreas exteriores e interiores del centro de datos están bajo videovigilancia.
- Registro de accesos: Todos los accesos a áreas sensibles se registran de forma completa y se archivan.
2. Control de acceso
El control de acceso garantiza que solo las personas autorizadas tengan acceso a datos personales y que los permisos se concedan según el principio de asignación mínima de privilegios (Least Privilege).
Medidas:
- MFA/TOTP: La autenticación multifactor (Multi-Factor Authentication) mediante contraseña de un solo uso basada en tiempo (TOTP) es obligatoria para todas las cuentas de usuario.
- RBAC (Role-Based Access Control): El control de acceso se realiza basado en roles. A cada rol de usuario se le asignan derechos definidos que comprenden únicamente los permisos necesarios para el cumplimiento de las tareas.
- Least Privilege: Los permisos se conceden según el principio de asignación mínima de privilegios. Los usuarios reciben únicamente los derechos de acceso estrictamente necesarios para el ejercicio de su actividad.
- JWT (JSON Web Token): Los tokens de acceso tienen una validez de 15 minutos. Tras su vencimiento se emite un nuevo token mediante la rotación de refresh-tokens.
- Refresh-Token-Rotation: En cada renovación de token se emite un nuevo refresh-token, invalidándose el anterior. Esto minimiza el riesgo de uso indebido de tokens.
- Argon2id: Las contraseñas se cifran con el algoritmo Argon2id. Los parámetros son: m=64MiB (memoria), t=3 (iteraciones), p=4 (paralelismo). Esto ofrece una alta protección contra ataques de fuerza bruta y tablas rainbow.
- Bloqueo tras intentos fallidos: Tras un número definido de intentos de inicio de sesión fallidos, la cuenta se bloquea temporalmente.
3. Control de transmisión
El control de transmisión garantiza que los datos personales estén protegidos durante la transmisión contra accesos no autorizados, manipulación y pérdida.
Medidas:
- TLS 1.3: Todas las transmisiones de datos entre cliente y servidor se realizan cifradas mediante TLS 1.3 (Transport Layer Security). Las versiones de protocolo más antiguas (TLS 1.1 e inferior) no son compatibles.
- HSTS (HTTP Strict Transport Security): El servidor envía cabeceras HSTS para garantizar que los navegadores se comuniquen exclusivamente a través de conexiones HTTPS.
- Let’s Encrypt con rotación automática: Los certificados SSL/TLS se emiten a través de Let’s Encrypt y se rotan automáticamente para garantizar un cifrado continuo.
- Certificate Pinning: Cuando sea aplicable, se emplea Certificate Pinning para prevenir ataques de intermediario (Man-in-the-Middle).
4. Control de entrada
El control de entrada garantiza que todas las entradas y modificaciones de datos personales se registren de forma trazable, para poder esclarecer la causa en caso de una violación de la protección de datos.
Medidas:
- Audit-Trail (ISO 27001 A.12.4): Todos los accesos y modificaciones relevantes para la seguridad se registran de forma completa conforme a la norma ISO 27001, medida de control A.12.4 (registro de eventos).
- WORM-Logs (Write Once, Read Many): Los registros de auditoría se almacenan como WORM-Logs, es decir, no pueden ser modificados ni eliminados después de su escritura. Esto garantiza la integridad e inmutabilidad de los datos de registro.
- Contenido del registro: Cada entrada de registro contiene al menos la siguiente información:
- Timestamp (marca de tiempo de la acción)
- User-ID (identificación del usuario)
- Tenant-ID (identificación del cliente/titular de la guardería)
- Acción (operación realizada, p. ej., CREATE, READ, UPDATE, DELETE)
- Recurso (objeto de datos afectado)
- Dirección IP (del cliente solicitante)
- User-Agent (identificación del navegador/cliente)
- Conservación de registros: Los registros de auditoría se conservan durante 3 años y posteriormente se suprimen.
5. Control de encargo
El control de encargo garantiza que los datos personales se traten únicamente en el marco de las instrucciones emitidas y de este contrato de encargado del tratamiento.
Medidas:
- Tratamiento únicamente en el marco del AVV: El tratamiento de datos personales se realiza exclusivamente siguiendo las instrucciones del Responsable del tratamiento y en el marco del contrato de encargado del tratamiento celebrado.
- Sin transmisión sin autorización: No se produce ninguna transmisión de datos a terceros sin la autorización previa del Responsable del tratamiento.
- Documentación de instrucciones: Todas las instrucciones del Responsable del tratamiento se documentan y archivan de forma trazable.
- Vinculación contractual del personal: Todas las personas encargadas del tratamiento están obligadas contractualmente a mantener la confidencialidad.
6. Control de disponibilidad
El control de disponibilidad garantiza que los datos personales estén protegidos contra destrucción accidental o pérdida y que la plataforma esté disponible en todo momento.
Medidas:
- Copias de seguridad diarias: Se realizan copias de seguridad completas diariamente a las 03:00 UTC (Hetzner Cloud Backup).
- AES-256 at rest: Las copias de seguridad se almacenan cifradas con AES-256 (Advanced Encryption Standard).
- Rotación de 7 días: Las copias de seguridad se conservan de forma rotativa durante 7 días, es decir, siempre están disponibles las copias de seguridad de los últimos 7 días para su restauración.
- RTO 8h (Recovery Time Objective): El tiempo de restauración tras un fallo es de 8 horas como máximo.
- RPO 24h (Recovery Point Objective): La pérdida máxima de datos en caso de fallo es de 24 horas como máximo (corresponde a la última copia de seguridad exitosa).
- Redis como caché en memoria: Redis se emplea como caché en memoria y no es persistente. No se almacenan datos personales de forma permanente en Redis. En caso de fallo de Redis, únicamente se pierden datos de caché, que pueden reconstruirse a partir de la base de datos PostgreSQL.
7. Control de separación
El control de separación garantiza que los datos personales de diferentes clientes (titulares de guardería) se traten estrictamente separados.
Medidas:
- Multi-Tenant con aislamiento de tenant a nivel de base de datos: Los datos de diferentes clientes (titulares de guardería) se separan estrictamente a nivel de base de datos. Cada cliente tiene un área de datos aislada, a la que otros clientes no tienen acceso.
- JWT-Claims tenant-scoped: Los tokens de acceso JWT contienen claims específicos de tenant que garantizan que un usuario solo pueda acceder a los datos de su cliente.
- Aislamiento de namespace Redis por tenant: En la caché Redis, los datos de diferentes clientes se separan mediante aislamiento de namespace. Cada cliente tiene su propio namespace, protegido contra el acceso de otros clientes.
- Verificación de tenant en cada consulta: Cada consulta de base de datos y cada acceso a caché se verifica respecto a la pertenencia al cliente.
8. Cifrado
El cifrado garantiza que los datos personales estén protegidos tanto durante la transmisión como en reposo.
Medidas:
- AES-256 at rest: Todos los datos almacenados, incluidas las copias de seguridad, se cifran con AES-256 (Advanced Encryption Standard, longitud de clave de 256 bits).
- TLS 1.3 in transit: Todas las transmisiones de datos se realizan cifradas mediante TLS 1.3 (Transport Layer Security).
- Cifrado de aplicación para datos de salud: Los datos de salud (Art. 9 RGPD) se cifran adicionalmente al cifrado de base de datos a nivel de aplicación (véase también la sección 12).
9. Seudonimización
La seudonimización garantiza que los datos personales en los registros de auditoría y en el almacenamiento a largo plazo se traten de forma que, sin información adicional, ya no puedan atribuirse a una persona afectada específica.
Medidas:
- Hash SHA-256 de correo electrónico con salt en registros de auditoría: En los registros de auditoría, las direcciones de correo electrónico no se almacenan en texto claro, sino como hash SHA-256 con salt. Esto permite la trazabilidad de acciones sin almacenar la dirección de correo electrónico en texto claro.
- Nombres eliminados/cifrados tras el plazo de conservación: Tras el vencimiento de los plazos legales de conservación, los nombres y otros rasgos identificativos se eliminan o se sustituyen por valores hash, en caso de que sea necesario un almacenamiento adicional con fines estadísticos o de prueba.
10. Revisión regular
La revisión regular garantiza que las medidas técnicas y organizativas se adapten continuamente al estado actual de la técnica y a nuevas situaciones de amenaza.
Medidas:
- Revisión anual de TOMs: Las medidas técnicas y organizativas se revisan anualmente y se adaptan cuando sea necesario.
- Pruebas de penetración cada 24 meses: Se realizan regularmente pruebas de penetración para identificar y subsanar vulnerabilidades en la plataforma. Las pruebas se realizan cada 24 meses.
- Escaneos de vulnerabilidades trimestralmente: Trimestralmente se realizan escaneos de vulnerabilidades automatizados para detectar vulnerabilidades conocidas en dependencias y componentes del sistema.
- ISO 27001 previsto: Se persigue la certificación según ISO 27001. Las medidas ya están alineadas con los requisitos de ISO 27001.
11. Subencargados del tratamiento
Como subencargado del tratamiento en el sentido del Art. 28 Apdo. 2 RGPD se emplea exclusivamente a:
- Hetzner Online GmbH, Industriestr. 12-14, 09224 Chemnitz, Alemania (centro de datos de Falkenstein)
No se emplean otros subencargados del tratamiento. No se produce ninguna transferencia de datos a terceros países en el sentido de los Art. 44 y siguientes del RGPD. Todos los procesos de tratamiento se realizan exclusivamente en Alemania.
Redis se opera como caché en memoria localmente en el servidor y no constituye un subencargado del tratamiento, ya que no se transmiten datos personales de forma permanente a Redis y Redis es parte integral de la infraestructura del servidor.
12. Particularidades en datos de menores y datos de salud
Debido al tratamiento de categorías especiales de datos personales conforme al Art. 9 RGPD (datos de salud) y al tratamiento de datos de personas menores de edad (menores), se adoptan medidas adicionales que van más allá de las TOMs estándar.
Medidas:
- Control de acceso reforzado para datos de salud: El acceso a los datos de salud se realiza a través de un módulo RBAC (Role-Based Access Control) separado. Solo los usuarios con el permiso específico «Acceso a datos de salud» pueden acceder a estos datos. Los permisos estándar para la gestión de guardería no son suficientes.
- Nivel adicional de registro de auditoría para el acceso a datos del Art. 9: Cada acceso a datos de salud se registra en un nivel adicional de registro de auditoría. Este registro incluye, además de la información estándar de registro:
- Finalidad del acceso (tratamiento, emergencia, documentación)
- Tipo de acción (lectura, modificación, exportación)
- Justificación (consentimiento disponible, situación de emergencia)
- Cifrado de los campos de datos de salud a nivel de aplicación: Los datos de salud se cifran adicionalmente al cifrado de base de datos (AES-256 at rest) a nivel de aplicación. Esto significa que los campos que contienen datos de salud se cifran con una clave separada antes de su escritura en la base de datos. En caso de acceso directo no autorizado a la base de datos, los datos de salud no serían legibles incluso conociendo la clave de cifrado de la base de datos.
13. Historial de cambios
| Versión | Fecha | Cambios principales |
|---|
| 1.0 | 08.08.2026 | Versión inicial |