TOMs – CombiJornada

Version 1.2 · Stand: 08.08.2026

flowgeist ZERO flowgeist KITA flowgeist TOOL CombiJornada DIRIGENT

Technical and Organizational Measures (TOMs) – CombiJornada

Status: 29.08.2026 Version: 1.3 Scope: Art. 32 GDPR, Art. 28(3)(c) GDPR

1. Access Control

Measures to ensure that only authorized persons obtain physical access to data processing facilities:

Data center: Hosting with Hetzner Online GmbH (Falkenstein, Germany). The data center is ISO 27001-certified.
Physical access control: Access to the data center exclusively for authorized personnel via multi-stage authentication (chip card + PIN/biometrics).
Video surveillance: 24/7 video surveillance of the data center areas, retention of recordings in accordance with legal requirements.
Visitor logging: All visitors are registered (name, company, time, escort).
Fire and intrusion protection: Smoke detectors, gas extinguishing system, intrusion alarm system with alarm forwarding to security service.
Power supply: Redundant power supply (UPS + diesel emergency generator) for at least 24 hours of autonomy.
Climate control: Redundant climate control with monitoring of temperature and humidity.

Since flowgeist as a SaaS provider operates the infrastructure at Hetzner, physical access control is primarily the responsibility of the data center operator. flowgeist restricts physical access to its own systems to authorized employees.

2. Access Control

Measures to ensure that only authorized persons obtain access to data processing systems and can process data:

Authentication: NextAuth + JWT (JSON Web Tokens) for the application layer. Passwords are stored as hash (bcrypt), never in plaintext.
Multi-Factor Authentication (MFA): MFA is optionally available and recommended for administrators.
Role-Based Access Control (RBAC): Role-based access control with defined roles (Administrator, HR personnel, Employee self-service). Each role has only the permissions necessary for its tasks (Least Privilege principle).
System-level access: SSH access to servers exclusively via SSH keys (no password login). Access only for authorized administrators.
Database access: PostgreSQL access via authenticated connections with separate database users and role-based permissions.
Redis access: Redis is used in development; in the production Docker Compose, no Redis service is currently included, and the application falls back to in-memory caching. A Redis service in production is planned.
Access logging: All accesses to systems and data are logged (login time, user, action, IP address).
Session management: JWT-based sessions with defined validity period and automatic timeout on inactivity.
Password policy: Minimum length 12 characters, complexity requirements (upper/lower case letters, numbers, special characters). An automatic account lockout or rate limiting on failed login attempts is currently not implemented and is planned.

3. Transfer Control

Measures to ensure that personal data cannot be unauthorized read, copied, altered, or removed during electronic transmission:

Transport encryption: TLS 1.2 and 1.3 for data transmissions (HTTPS for web traffic). TLS 1.3 as the exclusive minimum version is targeted. Database connections within the Docker network are currently unencrypted (no sslmode=require); TLS for DB connections is planned.
HSTS (HTTP Strict Transport Security): Enabled to ensure that connections are made exclusively via HTTPS. HSTS with includeSubDomains.
Certificates: Let’s Encrypt TLS certificates with automatic renewal (90-day certificates).
Forward Secrecy: TLS configuration with Perfect Forward Secrecy (ECDHE), so that recorded connections cannot be subsequently decrypted.
Internal communication: Encrypted connections between web server and external services (AWS S3). Internal Docker network connections (PostgreSQL) are currently unencrypted.
API security: All API endpoints require authentication (JWT) and are accessible exclusively via HTTPS.
S3 transfer: Data transfer to AWS S3 takes place exclusively via HTTPS (TLS).

4. Input Control

Measures to ensure that it can be subsequently verified whether and by whom personal data has been entered into, altered, or removed from data processing systems:

Audit Trail: Logging of all security-relevant actions in the CombiJornada platform:
- Login/logout events (time, user, IP address)
- Creation, modification, and deletion of working time data
- Changes to shift and roster plans
- Approval/rejection actions on vacation requests
- Changes to user roles and permissions
- Export and report actions
Append-only via DB trigger: Audit logs are protected against modification by a database trigger (BEFORE UPDATE OR DELETE) that raises an exception unless the current user is retention_role. Technical WORM storage or cryptographic hash chaining is not implemented and is planned.
Logging of administrative actions: All administrative actions (user management, configuration changes) are logged.
Retention of audit logs: 4-year retention period for time and audit data (Spanish legal requirement). An automated deletion job (purge) for audit logs after expiry is currently not implemented; timely deletion is ensured server-side/organizationally, a dedicated retention job is planned.

5. Order Control

Measures to ensure that personal data processed on behalf of the Controller is processed only in accordance with the Controller’s instructions:

Instruction binding: All employees of flowgeist who are entrusted with the processing of personal data are subject to instruction binding in accordance with Art. 28(3)(a) GDPR.
Contractual arrangements: DPA with all Sub-processors (Hetzner, Stripe, AWS S3) in accordance with Art. 28(4) GDPR.
Technical separation: Data from different clients (tenants) is technically separated (multi-tenant isolation, see Separation Control).
Record of processing activities: Maintenance of a record of processing activities in accordance with Art. 30 GDPR.
Training: Regular training of employees on data protection and information security.
Sub-processor control: Regular review of Sub-processors for compliance with the DPA requirements.

6. Availability Control

Measures to ensure that personal data is protected against accidental destruction or loss:

Daily backups: Daily automatic backups of the PostgreSQL database (pg_dump, compressed). Local dump files are retained on a 30-day rolling basis on the AES-256-encrypted server volume; in addition, the backups are replicated daily in file-level encrypted form (AES-256-CBC) to a separate offsite storage backend.
Backup retention: Tiered retention periods for offsite backups — daily backups 7 days, weekly 4 weeks, monthly 6 months.
Redis cache: Redis is used in development; in production, the application falls back to in-memory caching. Redis data is reproducible from the PostgreSQL database and therefore not critical for data integrity.
Backup verification: Regular verification of backup integrity (restore tests on a quarterly basis).
Redundancy: Redundant system architecture with automatic failover in case of individual component failure.
Monitoring: 24/7 monitoring of system availability with automatic alerting in case of disruptions.
Disaster recovery: Documented disaster recovery procedure with defined Recovery Point Objective (RPO ≤ 24h) and Recovery Time Objective (RTO ≤ 4h).
AWS S3 availability: AWS S3 offers built-in redundancy (99.999999999% / 11x9 data durability) and versioning.
Power and network redundancy: Redundant power supply and network connections in the data center.

7. Separation Control

Measures to ensure that data collected for different purposes is processed separately:

Multi-tenant architecture: The CombiJornada platform implements strict multi-tenant isolation. Data from different clients (tenants) is logically and technically separated.
Database isolation: Tenant separation is performed at the application level via gestoriaId / organizationId filters in the API handlers. PostgreSQL Row-Level Security (RLS) is not implemented; the introduction of RLS is planned.
Redis namespace isolation: Redis caches use namespace separation (namespace prefixing per tenant) to exclude any mixing of cache data between tenants.
AWS S3 separation: File storage in AWS S3 is done with tenant-specific bucket prefixes and bucket policies that restrict access to the respective tenant.
Role-based data access: Within a tenant, data access is controlled via RBAC (e.g., employees see only their own working time data, HR personnel see all).
Separation of production and development environments: Strict separation of production, staging, and development environments. No personal data in development or test environments.
Log separation: Audit logs are stored separately from application data and are accessible only to authorized administrators.

8. Encryption

Measures to protect personal data through encryption:

Database encryption (at-rest): PostgreSQL database with AES-256 encryption at volume level (LUKS / Hetzner Volume Encryption).
Transport encryption (in-transit): TLS 1.2 and 1.3 for data transmissions (see Transfer Control).
AWS S3 server-side encryption: S3 objects are stored with ACL: private. SSE-S3 server-side encryption, bucket versioning, access logging, and Block Public Access are not explicitly configured at the bucket level and are planned.
Password hashing: Passwords are hashed with bcrypt (with salt and sufficient cost factor). No plaintext storage.
JWT signing: JSON Web Tokens are cryptographically signed (HMAC-SHA256 or RS256) to prevent manipulation.
Backup encryption: The daily offsite backups are encrypted with AES-256 before being transferred to the separate storage backend.
Redis encryption: Redis connections are encrypted via TLS (when Redis is used in production; currently in-memory fallback).
Key management: Cryptographic keys are securely managed (separate storage, access restrictions, regular rotation).

9. Pseudonymization

Measures for the pseudonymization of personal data:

Tenant-IDs: Data is assigned pseudonymously via Tenant-IDs, so that direct assignment to a client is only possible with additional information.
User-IDs: Internal user identifiers (UUIDs) are used instead of plaintext names in logs and caches, wherever technically possible.
Audit logs: In audit logs, pseudonymized identifiers are used wherever possible. The mapping table is stored separately and access-protected.
Reporting: In aggregated reports, data is presented pseudonymously where this is sufficient for the purpose.
Limitation: Due to the nature of the platform (working time and shift planning), complete pseudonymization is not possible, as the assignment of working times to specific employees is functionally required (Art. 34 Estatuto de los Trabajadores).

10. Regular Review

Measures for the regular review and assessment of the effectiveness of the TOMs:

Review interval: The TOMs are reviewed at least annually and adjusted as needed.
Security audits: Regular security audits of the platform (at least annually), including penetration testing by external service providers.
Incident management: Documented procedure for handling security incidents (Incident Response Plan) with defined escalation levels and reporting obligations.
Vulnerability management: Continuous monitoring of security vulnerabilities (CVE databases) and timely installation of security updates.
Patch management: Automated and manual patch processes for operating system, runtime environment (Next.js 15, React 19, Node.js), and dependencies.
Dependency checking: Regular review of npm dependencies for known vulnerabilities (npm audit / Dependabot).
Employee training: Annual training of all employees on data protection (GDPR, LOPDGDD) and information security.
Certification: Pursuing ISO 27001 certification; Hetzner data center already ISO 27001-certified.
Documentation: All reviews and audits are documented and made available to the supervisory authority upon request.

11. Sub-processors

The following Sub-processors are engaged within the CombiJornada platform:

Sub-processor	Headquarters	Service	Third country transfer	Protective measures
Hetzner Online GmbH	Germany (Falkenstein)	Hosting, PostgreSQL 16, Redis, backup	None (EU)	ISO 27001-certified data center, DPA
Stripe Payments Europe, Ltd.	Ireland (IE) / USA (US parent company)	Payment processing	EU-US DPF + SCC	DPA, EU-US Data Privacy Framework, SCC
AWS S3 (Amazon Web Services, Inc.)	USA / EU	File storage (documents, PDFs)	EU-US DPF + SCC	DPA, EU-US Data Privacy Framework, SCC
Lexware GmbH	Germany (DE)	Invoicing / accounting	None (EU)	DPA in accordance with Art. 28 GDPR
Meta Platforms Ireland Ltd. (WhatsApp Business API)	Ireland (IE) / USA (US parent company)	WhatsApp messaging	EU-US DPF + SCC	DPA, EU-US Data Privacy Framework, SCC
OpenStreetMap Foundation	United Kingdom (UK)	Map display (location map)	UK Adequacy / SCC	DPA / SCC

DPA agreements in accordance with Art. 28(4) GDPR have been concluded with all Sub-processors. The Sub-processors are regularly reviewed for compliance with the data protection requirements.

12. AWS S3 Specifics

The use of AWS S3 for file storage requires special protective measures due to the Third country transfer (USA):

Server-side encryption (SSE-S3, AES-256): S3 objects are stored with ACL: private. SSE-S3 server-side encryption is not explicitly configured at the bucket level; enabling SSE-S3 is planned.
Bucket policies with Least Privilege: Access to S3 buckets is via IAM. Public access is prevented at the object level via ACL: private. Explicit Block Public Access configuration at the bucket level is planned.
Region configuration: The AWS region eu-central-1 (Frankfurt, Germany) is preferred for data storage to ensure data processing within the EU. US regions are used only when specifically needed (e.g., for specific services). In such cases, the transfer takes place on the basis of the EU-US Data Privacy Framework (DPF) and Standard Contractual Clauses (SCC).
Access logging: S3 access logging is not explicitly configured at the bucket level; enabling it is planned.
Versioning: S3 bucket versioning is not explicitly enabled; enabling it is planned to prevent accidental deletion or overwriting of objects.
Lifecycle policies: S3 lifecycle policies for the automatic deletion or archiving of objects after expiry of the retention periods are currently not configured at bucket level and are planned.
Transfer Impact Assessment (TIA): A TIA in accordance with Art. 46 GDPR has been conducted for the use of AWS S3 in US regions. The TIA is updated at least annually and reviewed upon changes in the legal situation (in particular the EU-US Data Privacy Framework).
Data minimization: Only the files necessary for the respective purpose are stored in AWS S3. Personal data in documents (e.g., employment contracts) is deleted after expiry of the retention periods (automated S3 lifecycle rules planned).

13. Change History

Version	Date	Material changes
1.0	08.08.2026	Initial version of the TOMs for CombiJornada
1.1	29.08.2026	Code alignment: Redis production status corrected, TLS 1.2/1.3 instead of 1.3-only, DB TLS marked as planned, WORM replaced by DB trigger, RLS marked as not implemented, backup encryption marked as planned, AWS S3 SSE/versioning/access logging marked as planned, Lexware/Meta/OSM added as sub-processors
1.2	22.09.2026	Code alignment (remaining items): password hashing specified as bcrypt (no Argon2 in code); lockout claim removed (no lockout/rate limiting implemented, planned); audit retention unified at 4 years + missing purge job marked as planned; backup section raised to encrypted offsite reality (AES-256, retention 7d/4w/6m); S3 lifecycle marked as planned
1.3	22.09.2026	Server verification: backup section specified (local pg_dump dumps 30-day rolling on AES-256 volume + file-encrypted AES-256-CBC offsite replication 7d/4w/6m); no MinIO/audit purge cron on server
1.2	22.09.2026	Code alignment (remaining items): password hashing specified as bcrypt (no Argon2 in code); lockout claim removed (no lockout/rate limiting implemented, planned); audit retention unified at 4 years + missing purge job marked as planned; backup section raised to encrypted offsite reality (AES-256, retention 7d/4w/6m); S3 lifecycle marked as planned