⚖ Medidas técnicas y organizativas – CombiJornada

Medidas técnicas y organizativas – CombiJornada

v1.2 · 08.08.2026

Medidas técnicas y organizativas – CombiJornada

Version 1.2 · Stand: 08.08.2026
flowgeist ZERO flowgeist KITA flowgeist TOOL flowgeist FOOD CombiJornada

Medidas técnicas y organizativas (TOMs) – CombiJornada

Fecha: 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

Medidas para garantizar que solo personas autorizadas obtengan acceso físico a las instalaciones de tratamiento de datos:

  • Centro de datos: Hosting en Hetzner Online GmbH (Falkenstein, Alemania). El centro de datos está certificado según ISO 27001.
  • Control de acceso físico: Acceso al centro de datos exclusivamente para personal autorizado mediante autenticación multifactor (tarjeta chip + PIN/biometría).
  • Videovigilancia: Videovigilancia 24/7 de las áreas del centro de datos, conservación de las grabaciones conforme a los requisitos legales.
  • Registro de visitantes: Todos los visitantes son registrados (nombre, empresa, momento, persona acompañante).
  • Protección contra incendios e intrusión: Detectores de humo, sistema de extinción de gas, sistema de alarma de intrusión con transmisión de alarma al servicio de seguridad.
  • Suministro eléctrico: Suministro eléctrico redundante (SAI + generador diésel de emergencia) para al menos 24 horas de autonomía.
  • Climatización: Climatización redundante con monitoring de temperatura y humedad.

Dado que flowgeist, como proveedor SaaS, opera la infraestructura en Hetzner, el control de acceso físico recae principalmente en el operador del centro de datos. flowgeist restringe el acceso físico a sus propios sistemas a empleados autorizados.

2. Control de acceso lógico

Medidas para garantizar que solo personas autorizadas obtengan acceso a los sistemas de tratamiento de datos y puedan tratar datos:

  • Autenticación: NextAuth + JWT (JSON Web Tokens) para la capa de aplicación. Las contraseñas se almacenan como hash (bcrypt/argon2), nunca en texto plano.
  • Autenticación multifactor (MFA): MFA está disponible de forma opcional y se recomienda para administradores.
  • Role-Based Access Control (RBAC): Control de acceso basado en roles con roles definidos (administrador, personal de RR. HH., Employee-Self-Service). Cada rol tiene solo los permisos necesarios para sus tareas (principio de Least Privilege).
  • Acceso a nivel de sistema: Acceso SSH a servidores exclusivamente mediante claves SSH (sin inicio de sesión por contraseña). Acceso solo para administradores autorizados.
  • Acceso a base de datos: Acceso PostgreSQL mediante conexiones autenticadas con usuarios de base de datos separados y permisos basados en roles.
  • Acceso a Redis: Acceso a Redis mediante conexiones autenticadas con protección por contraseña y separación por namespaces.
  • Registro de accesos: Todos los accesos a sistemas y datos son registrados (momento de inicio de sesión, usuario, acción, dirección IP).
  • Gestión de sesiones: Sesiones basadas en JWT con duración de validez definida y timeout automático por inactividad.
  • Política de contraseñas: Longitud mínima de 12 caracteres, requisitos de complejidad (mayúsculas/minúsculas, números, caracteres especiales), bloqueo tras intentos fallidos repetidos.

3. Control de transmisión

Medidas para garantizar que los datos personales no puedan ser leídos, copiados, modificados o eliminados de forma no autorizada durante la transmisión electrónica:

  • Cifrado de transporte: TLS 1.3 para todas las transmisiones de datos (HTTPS para tráfico web, TLS para conexiones de base de datos, TLS para conexiones Redis).
  • HSTS (HTTP Strict Transport Security): Activado para garantizar que las conexiones se realicen exclusivamente a través de HTTPS. HSTS con includeSubDomains y preload.
  • Certificados: Certificados TLS Let’s Encrypt con renovación automática (certificados de 90 días).
  • Forward Secrecy: Configuración TLS con Perfect Forward Secrecy (ECDHE), de modo que las conexiones grabadas no puedan ser descifradas a posteriori.
  • Comunicación interna: Conexiones cifradas entre todos los componentes internos (servidor web, base de datos, Redis, AWS S3).
  • Seguridad de API: Todos los endpoints de API requieren autenticación (JWT) y son accesibles exclusivamente a través de HTTPS.
  • Transmisión a S3: La transmisión de datos a AWS S3 se realiza exclusivamente a través de HTTPS (TLS).

4. Control de entrada

Medidas para garantizar que pueda verificarse a posteriori si y por quién se han introducido, modificado o eliminado datos personales en los sistemas de tratamiento de datos:

  • Audit-Trail: Registro de todas las acciones relevantes para la seguridad en la plataforma CombiJornada:
    • Eventos de inicio/cierre de sesión (momento, usuario, dirección IP)
    • Creación, modificación y supresión de datos de horario de trabajo
    • Cambios en planificaciones de turnos y servicios
    • Acciones de aprobación/rechazo de solicitudes de vacaciones
    • Cambios en roles de usuario y permisos
    • Acciones de exportación y reporting
  • WORM-Logs (Write Once, Read Many): Los Audit-Logs se almacenan en un formato WORM que impide la modificación o supresión posterior de entradas individuales.
  • Inmutabilidad: Los Audit-Logs están protegidos contra manipulación mediante procedimientos criptográficos (encadenamiento de hash).
  • Registro de acciones de administración: Todas las acciones administrativas (gestión de usuarios, cambios de configuración) son registradas.
  • Conservación de Audit-Logs: 3 años de plazo de conservación para Audit-Logs.

5. Control de encargo

Medidas para garantizar que los datos personales tratados por encargo solo se traten conforme a las instrucciones del Responsable del tratamiento:

  • Vinculación a las instrucciones: Todos los empleados de flowgeist encargados del tratamiento de datos personales están sujetos a la vinculación a las instrucciones conforme al art. 28 apdo. 3 let. a RGPD.
  • Disposiciones contractuales: AVV con todos los subencargados del tratamiento (Hetzner, Stripe, AWS S3) conforme al art. 28 apdo. 4 RGPD.
  • Separación técnica: Los datos de diferentes clientes (Tenants) se tratan técnicamente separados (aislamiento Multi-Tenant, véase Control de separación).
  • Registro de actividades de tratamiento: Llevar un registro de actividades de tratamiento conforme al art. 30 RGPD.
  • Formación: Formación periódica de los empleados en materia de protección de datos y seguridad de la información.
  • Control de subencargados del tratamiento: Revisión periódica de los subencargados del tratamiento respecto del cumplimiento de los requisitos del AVV.

6. Control de disponibilidad

Medidas para garantizar que los datos personales estén protegidos contra destrucción accidental o pérdida:

  • Backups diarios: Backups automáticos diarios de la base de datos PostgreSQL. Los backups se almacenan cifrados (AES-256).
  • Conservación de backups: Los backups se conservan según una política de retención definida (diario: 7 días, semanal: 4 semanas, mensual: 12 meses).
  • Redis Cache: Redis se utiliza como caché. Los datos de Redis son reproducibles desde la base de datos PostgreSQL y por tanto no son críticos para la integridad de datos.
  • Verificación de backups: Revisión periódica de la integridad de los backups (tests de restauración con periodicidad trimestral).
  • Redundancia: Arquitectura de sistema redundante con failover automático ante el fallo de componentes individuales.
  • Monitoring: Monitoring 24/7 de la disponibilidad del sistema con alertas automáticas ante incidencias.
  • Recuperación ante desastres (Disaster Recovery): Procedimiento de recuperación ante desastres documentado con Recovery Point Objective (RPO ≤ 24h) y Recovery Time Objective (RTO ≤ 4h) definidos.
  • Disponibilidad de AWS S3: AWS S3 ofrece redundancia integrada (99.999999999% / 11x9 durabilidad de datos) y versionado.
  • Redundancia eléctrica y de red: Suministro eléctrico redundante y conexiones de red en el centro de datos.

7. Control de separación

Medidas para garantizar que los datos recopilados para diferentes finalidades se traten separadamente:

  • Arquitectura Multi-Tenant: La plataforma CombiJornada implementa un estricto aislamiento Multi-Tenant. Los datos de diferentes clientes (Tenants) se separan lógica y técnicamente.
  • Aislamiento de base de datos: PostgreSQL-Row-Level-Security y filtrado basado en Tenant-ID garantizan que un Tenant no pueda consultar los datos de otro Tenant.
  • Aislamiento de namespace Redis: Las cachés de Redis utilizan separación por namespaces (Namespace-Prefixing por Tenant) para excluir la mezcla de datos de caché entre Tenants.
  • Separación en AWS S3: El almacenamiento de archivos en AWS S3 se realiza con prefijos de bucket específicos por Tenant y Bucket-Policies que restringen el acceso al respectivo Tenant.
  • Accesos a datos basados en roles: Dentro de un Tenant, los accesos a datos se controlan mediante RBAC (p. ej., los empleados solo ven sus propios datos de horario de trabajo, el personal de RR. HH. ve todos).
  • Separación de entornos de producción y desarrollo: Estricta separación de entornos de producción, staging y desarrollo. Sin datos personales en entornos de desarrollo o pruebas.
  • Separación de logs: Los Audit-Logs se almacenan separados de los datos de aplicación y solo son accesibles para administradores autorizados.

8. Cifrado

Medidas para la protección de datos personales mediante cifrado:

  • Cifrado de base de datos (at-rest): Base de datos PostgreSQL con cifrado AES-256 a nivel de volumen (LUKS / Hetzner Volume Encryption).
  • Cifrado de transporte (in-transit): TLS 1.3 para todas las transmisiones de datos (véase Control de transmisión).
  • Cifrado del lado del servidor en AWS S3: Todos los objetos almacenados en AWS S3 se cifran del lado del servidor (SSE-S3, AES-256).
  • Hashing de contraseñas: Las contraseñas se hashean con bcrypt/argon2 (con salt y cost-factor suficiente). Sin almacenamiento en texto plano.
  • Firma de JWT: Los JSON Web Tokens se firman criptográficamente (HMAC-SHA256 o RS256) para impedir la manipulación.
  • Cifrado de backups: Todos los backups se cifran con AES-256.
  • Cifrado de Redis: Las conexiones Redis se cifran mediante TLS.
  • Gestión de claves: Las claves criptográficas se gestionan de forma segura (almacenamiento separado, restricción de acceso, rotación periódica).

9. Seudonimización

Medidas para la seudonimización de datos personales:

  • Tenant-IDs: Los datos se asignan seudonimizados a través de Tenant-IDs, de modo que una asignación directa a un cliente solo es posible con información adicional.
  • User-IDs: Los identificadores internos de usuario (UUIDs) se utilizan en lugar de nombres en texto plano en logs y cachés, siempre que sea técnicamente posible.
  • Audit-Logs: En los Audit-Logs se utilizan, en la medida de lo posible, identificadores seudonimizados. La tabla de correspondencia se almacena separadamente y protegida contra accesos.
  • Reporting: En los reports agregados los datos se presentan seudonimizados cuando sea suficiente para la finalidad.
  • Limitación: Debido a la naturaleza de la plataforma (planificación de horarios de trabajo y turnos), una seudonimización completa no es posible, ya que la asignación de horarios de trabajo a empleados concretos es funcionalmente necesaria (art. 34 Estatuto de los Trabajadores).

10. Revisión periódica

Medidas para la revisión y evaluación periódicas de la eficacia de las TOMs:

  • Intervalo de revisión: Las TOMs se revisan al menos anualmente y se adaptan cuando sea necesario.
  • Security Audits: Auditorías de seguridad periódicas de la plataforma (al menos anuales), incl. Penetration Testing por proveedores externos.
  • Gestión de incidentes: Procedimiento documentado para el tratamiento de violaciones de seguridad (Incident Response Plan) con niveles de escalada y obligaciones de notificación definidos.
  • Gestión de vulnerabilidades: Monitoring continuo de brechas de seguridad (bases de datos CVE) e instalación puntual de actualizaciones de seguridad.
  • Patch-Management: Procesos de parcheo automatizados y manuales para sistema operativo, entorno de ejecución (Next.js 15, React 19, Node.js) y dependencias.
  • Verificación de dependencias: Revisión periódica de las dependencias npm respecto a vulnerabilidades conocidas (npm audit / Dependabot).
  • Formación de empleados: Formación anual de todos los empleados en materia de protección de datos (RGPD, LOPDGDD) y seguridad de la información.
  • Certificación: Aspiración a la certificación ISO 27001; el centro de datos de Hetzner ya está certificado según ISO 27001.
  • Documentación: Todas las revisiones y auditorías se documentan y se ponen a disposición de la autoridad de control a petición.

11. Subencargados del tratamiento

Los siguientes subencargados del tratamiento se utilizan en el marco de la plataforma CombiJornada:

Subencargado del tratamientoSedeServicioTransferencia a países tercerosMedidas de protección
Hetzner Online GmbHAlemania (Falkenstein)Hosting, PostgreSQL 16, Redis, BackupNinguna (UE)Centro de datos certificado ISO 27001, AVV
Stripe Payments Europe, Ltd.Irlanda (IE) / EE. UU. (US, matriz)Procesamiento de pagosEU-US DPF + SCCAVV, EU-US Data Privacy Framework, SCC
AWS S3 (Amazon Web Services, Inc.)EE. UU. / UEAlmacenamiento de archivos (documentos, PDFs)EU-US DPF + SCCAVV, EU-US Data Privacy Framework, SCC, SSE-S3

Con todos los subencargados del tratamiento se han celebrado acuerdos AVV conforme al art. 28 apdo. 4 RGPD. Los subencargados del tratamiento se revisan periódicamente respecto del cumplimiento de los requisitos de protección de datos.

12. Particularidades de AWS S3

El uso de AWS S3 para el almacenamiento de archivos requiere medidas de protección especiales debido a la transferencia a países terceros (EE. UU.):

  • Cifrado del lado del servidor (SSE-S3, AES-256): Todos los objetos almacenados en AWS S3 se cifran del lado del servidor (SSE-S3 con AES-256). El cifrado está activado por defecto para todos los buckets y no puede desactivarse.

  • Bucket-Policies con Least Privilege: El acceso a los buckets S3 se realiza según el principio de Least Privilege. Las Bucket-Policies y las políticas IAM están configuradas de modo que solo los servicios y usuarios autorizados puedan acceder a los respectivos buckets. El acceso público (Block Public Access) está bloqueado para todos los buckets.

  • Configuración de región: Se prefiere la región AWS eu-central-1 (Frankfurt, Alemania) para el almacenamiento de datos, a fin de garantizar el tratamiento de datos dentro de la UE. Las regiones de EE. UU. se utilizan solo cuando sea necesario (p. ej. para servicios específicos). En tales casos, la transferencia se realiza sobre la base del EU-US Data Privacy Framework (DPF) y de las cláusulas contractuales tipo (SCC).

  • Access Logging activado: S3-Access-Logging está activado para todos los buckets. Todos los accesos (lectura, escritura, supresión) a objetos S3 son registrados. Los Access-Logs se almacenan en buckets de logging separados y protegidos contra accesos.

  • Versionado: El versionado de buckets S3 está activado para impedir la supresión o sobrescritura accidental de objetos. Los objetos suprimidos pueden ser restaurados.

  • Políticas de Lifecycle: Las políticas de Lifecycle definidas controlan la supresión o archivado automático de objetos tras el vencimiento de los plazos de conservación.

  • Evaluación de impacto de la transferencia (TIA): Para el uso de AWS S3 en regiones de EE. UU. se ha realizado una TIA conforme al art. 46 RGPD. La TIA se actualiza al menos anualmente y se revisa ante cambios en la situación jurídica (en particular del EU-US Data Privacy Framework).

  • Minimización de datos: Solo se almacenan en AWS S3 los archivos necesarios para la respectiva finalidad. Los datos personales en documentos (p. ej. contratos de trabajo) se suprimen automáticamente tras el vencimiento de los plazos de conservación.

13. Historial de cambios

VersiónFechaCambios principales
1.008.08.2026Primera versión de las TOMs para CombiJornada

© 2026 flowgeist – Ralf Carsjens · Todos los derechos reservados