⚖ 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 CombiJornada DIRIGENT

Medidas técnicas y organizativas (TOMs) – CombiJornada

Fecha: 22.09.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 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), 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: Redis se utiliza en desarrollo; en la Docker Compose de producción no hay actualmente ningún servicio Redis, la aplicación recurre a caching en memoria. Un servicio Redis en producción está planificado.
  • 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). Un bloqueo automático de cuenta o rate limiting ante intentos fallidos de inicio de sesión no está implementado actualmente y está planificado.

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.2 y 1.3 para transmisiones de datos (HTTPS para tráfico web). TLS 1.3 como versión mínima exclusiva es un objetivo. Las conexiones de base de datos dentro de la red Docker no están cifradas actualmente (sin sslmode=require); TLS para conexiones DB está planificado.
  • HSTS (HTTP Strict Transport Security): Activado para garantizar que las conexiones se realicen exclusivamente a través de HTTPS. HSTS con includeSubDomains.
  • 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 servidor web y servicios externos (AWS S3). Las conexiones internas de la red Docker (PostgreSQL) no están cifradas actualmente.
  • 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
  • Append-only mediante DB-Trigger: Los Audit-Logs están protegidos contra modificación mediante un trigger de base de datos (BEFORE UPDATE OR DELETE) que lanza una excepción a menos que el usuario actual sea retention_role. El almacenamiento técnico WORM o el encadenamiento criptográfico de hash no está implementado y está planificado.
  • 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: 4 años de plazo de conservación para datos de horario y auditoría (requisito legal español). Un job de supresión automatizado (purge) para los registros de auditoría tras el vencimiento no está implementado actualmente; la supresión puntual se garantiza de forma organizativa/a nivel de servidor, un job de retención dedicado está planificado.

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 (pg_dump, comprimidos). Los archivos de volcado locales se conservan de forma rotativa durante 30 días en el volumen del servidor cifrado con AES-256; además, los backups se replican diariamente en forma cifrada a nivel de archivo (AES-256-CBC) a un backend de almacenamiento offsite separado.
  • Conservación de backups: Plazos de conservación escalonados para los backups offsite — backups diarios 7 días, semanales 4 semanas, mensuales 6 meses.
  • Redis Cache: Redis se utiliza en desarrollo; en producción, la aplicación recurre a caching en memoria. 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: La separación de Tenants se realiza a nivel de aplicación mediante filtros gestoriaId / organizationId en los manejadores de API. PostgreSQL Row-Level-Security (RLS) no está implementado; la introducción de RLS está planificada.
  • 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.2 y 1.3 para transmisiones de datos (véase Control de transmisión).
  • Cifrado del lado del servidor en AWS S3: Los objetos S3 se almacenan con ACL: private. El cifrado del lado del servidor SSE-S3, el versionado de buckets, el access logging y Block Public Access no están configurados explícitamente a nivel de bucket y están planificados.
  • Hashing de contraseñas: Las contraseñas se hashean con bcrypt (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: Los backups offsite diarios se cifran con AES-256 antes de su transferencia al backend de almacenamiento separado.
  • Cifrado de Redis: Las conexiones Redis se cifran mediante TLS (cuando Redis se utiliza en producción; actualmente fallback en memoria).
  • 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
Lexware GmbHAlemania (DE)Facturación / contabilidadNinguna (UE)AVV conforme al art. 28 RGPD
Meta Platforms Ireland Ltd. (WhatsApp Business API)Irlanda (IE) / EE. UU. (US, matriz)Mensajería WhatsAppEU-US DPF + SCCAVV, EU-US Data Privacy Framework, SCC
OpenStreetMap FoundationReino Unido (UK)Visualización de mapas (location map)UK Adequacy / SCCAVV / SCC

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): Los objetos S3 se almacenan con ACL: private. El cifrado del lado del servidor SSE-S3 no está configurado explícitamente a nivel de bucket; la activación de SSE-S3 está planificada.

  • Bucket-Policies con Least Privilege: El acceso a los buckets S3 se realiza mediante IAM. El acceso público se evita a nivel de objeto mediante ACL: private. La configuración explícita de Block Public Access a nivel de bucket está planificada.

  • 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: S3-Access-Logging no está configurado explícitamente a nivel de bucket; su activación está planificada.

  • Versionado: El versionado de buckets S3 no está activado explícitamente; su activación está planificada para impedir la supresión o sobrescritura accidental de objetos.

  • Políticas de Lifecycle: Las políticas de Lifecycle de S3 para la supresión o archivado automático de objetos tras el vencimiento de los plazos de conservación no están configuradas actualmente a nivel de bucket y están planificadas.

  • 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 tras el vencimiento de los plazos de conservación (reglas automatizadas de lifecycle de S3 planificadas).

13. Historial de cambios

VersiónFechaCambios principales
1.008.08.2026Primera versión de las TOMs para CombiJornada
1.129.08.2026Alineación con código: estado de Redis en producción corregido, TLS 1.2/1.3 en lugar de 1.3-only, TLS de DB marcado como planificado, WORM reemplazado por DB-Trigger, RLS marcado como no implementado, cifrado de backups marcado como planificado, AWS S3 SSE/versionado/access logging marcados como planificados, Lexware/Meta/OSM añadidos como subencargados
1.222.09.2026Alineación con código (puntos restantes): hashing de contraseñas especificado como bcrypt (sin Argon2 en el código); afirmación de bloqueo eliminada (sin bloqueo/rate limiting implementado, planificado); retención de auditoría unificada a 4 años + job de purga ausente marcado como planificado; sección de backups elevada a la realidad offsite cifrada (AES-256, retención 7d/4s/6m); lifecycle de S3 marcado como planificado
1.322.09.2026Verificación de servidor: sección de backups precisada (volcados locales pg_dump 30 días rotativos en volumen AES-256 + replicación offsite cifrada por archivo AES-256-CBC 7d/4s/6m); sin cron MinIO/purga de auditoría en el servidor
1.222.09.2026Alineación con código (puntos restantes): hashing de contraseñas especificado como bcrypt (sin Argon2 en el código); afirmación de bloqueo eliminada (sin bloqueo/rate limiting implementado, planificado); retención de auditoría unificada a 4 años + job de purga ausente marcado como planificado; sección de backups elevada a la realidad offsite cifrada (AES-256, retención 7d/4s/6m); lifecycle de S3 marcado como planificado

© 2026 flowgeist – Ralf Carsjens · Todos los derechos reservados