TOMs – CombiJornada

Version 1.2 · Stand: 08.08.2026

flowgeist ZERO flowgeist KITA flowgeist TOOL CombiJornada DIRIGENT

Technische und organisatorische Maßnahmen (TOMs) – CombiJornada

Stand: 22.09.2026 Version: 1.3 Geltungsbereich: Art. 32 DSGVO, Art. 28 Abs. 3 lit. c DSGVO

1. Zutrittskontrolle

Maßnahmen zur Sicherstellung, dass nur befugte Personen physischen Zugang zu den Datenverarbeitungsanlagen erhalten:

Rechenzentrum: Hosting bei Hetzner Online GmbH (Falkenstein, Deutschland). Das Rechenzentrum ist ISO 27001-zertifiziert.
Physische Zugangskontrolle: Zutritt zum Rechenzentrum ausschließlich für autorisiertes Personal über mehrstufige Authentifizierung (Chipkarte + PIN/Biometrie).
Videoüberwachung: 24/7-Videoüberwachung der Rechenzentrumsbereiche, Aufbewahrung der Aufzeichnungen gemäß gesetzlichen Vorgaben.
Besucherprotokollierung: Alle Besucher werden registriert (Name, Unternehmen, Zeitpunkt, Begleitperson).
Brand- und Einbruchschutz: Rauchmelder, Gaslöschanlage, Einbruchmeldeanlage mit Alarmweiterleitung an Sicherheitsdienst.
Stromversorgung: Redundante Stromversorgung (USV + Diesel-Notstromaggregat) für mindestens 24 Stunden Autonomie.
Klimatisierung: Redundante Klimatisierung mit Überwachung von Temperatur und Luftfeuchtigkeit.

Da flowgeist als SaaS-Anbieter die Infrastruktur bei Hetzner betreibt, obliegt die physische Zutrittskontrolle primär dem Rechenzentrumsbetreiber. flowgeist beschränkt den physischen Zugriff auf eigene Systeme auf autorisierte Mitarbeiter.

2. Zugriffskontrolle

Maßnahmen zur Sicherstellung, dass nur befugte Personen Zugang zu Datenverarbeitungssystemen erhalten und Daten verarbeiten können:

Authentifizierung: NextAuth + JWT (JSON Web Tokens) für die Anwendungsebene. Passwörter werden als Hash (bcrypt) gespeichert, niemals im Klartext.
Multi-Faktor-Authentifizierung (MFA): MFA ist optional verfügbar und wird für Administratoren empfohlen.
Role-Based Access Control (RBAC): Rollenbasierte Zugriffskontrolle mit definierten Rollen (Administrator, HR-Personal, Mitarbeiter-Self-Service). Jede Rolle hat nur die für ihre Aufgaben notwendigen Berechtigungen (Least-Privilege-Prinzip).
Zugriff auf Systemebene: SSH-Zugriff auf Server ausschließlich über SSH-Schlüssel (kein Passwort-Login). Zugriff nur für autorisierte Administratoren.
Datenbankzugriff: PostgreSQL-Zugriff über authentifizierte Verbindungen mit separaten Datenbankbenutzern und rollenbasierten Berechtigungen.
Redis-Zugriff: Redis wird in der Entwicklung eingesetzt; in der Produktions-Docker-Compose ist derzeit kein Redis-Service enthalten, die Anwendung fällt auf In-Memory-Caching zurück. Ein Redis-Service in Produktion ist geplant.
Zugriffsprotokollierung: Alle Zugriffe auf Systeme und Daten werden protokolliert (Login-Zeitpunkt, Benutzer, Aktion, IP-Adresse).
Session-Management: JWT-basierte Sessions mit festgelegter Gültigkeitsdauer und automatischem Timeout bei Inaktivität.
Passwortrichtlinie: Mindestlänge 12 Zeichen, Anforderungen an Komplexität (Groß-/Kleinbuchstaben, Zahlen, Sonderzeichen). Ein automatisches Account-Lockout bzw. Rate-Limiting bei Anmeldefehlversuchen ist derzeit nicht implementiert und geplant.

3. Übertragungskontrolle

Maßnahmen zur Sicherstellung, dass personenbezogene Daten bei elektronischer Übertragung nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können:

Transportverschlüsselung: TLS 1.2 und 1.3 für Datenübertragungen (HTTPS für Web-Traffic). TLS 1.3 als ausschließliche Mindestversion ist angestrebt. Datenbankverbindungen innerhalb des Docker-Netzwerks sind derzeit unverschlüsselt (kein sslmode=require); TLS für DB-Verbindungen ist geplant.
HSTS (HTTP Strict Transport Security): Aktiviert, um sicherzustellen, dass Verbindungen ausschließlich über HTTPS erfolgen. HSTS mit includeSubDomains.
Zertifikate: Let’s Encrypt TLS-Zertifikate mit automatischer Erneuerung (90-Tage-Zertifikate).
Forward Secrecy: TLS-Konfiguration mit Perfect Forward Secrecy (ECDHE), sodass aufgezeichnete Verbindungen nicht nachträglich entschlüsselt werden können.
Interne Kommunikation: Verschlüsselte Verbindungen zwischen Web-Server und externen Diensten (AWS S3). Interne Docker-Netzwerk-Verbindungen (PostgreSQL) sind derzeit unverschlüsselt.
API-Sicherheit: Alle API-Endpunkte erfordern Authentifizierung (JWT) und sind ausschließlich über HTTPS erreichbar.
S3-Übertragung: Datenübertragung zu AWS S3 erfolgt ausschließlich über HTTPS (TLS).

4. Eingabekontrolle

Maßnahmen zur Sicherstellung, dass nachträglich überprüft werden kann, ob und von wem personenbezogene Daten in Datenverarbeitungssysteme eingegeben, verändert oder entfernt worden sind:

Audit-Trail: Protokollierung aller sicherheitsrelevanten Aktionen in der CombiJornada-Plattform:
- Login-/Logout-Ereignisse (Zeitpunkt, Benutzer, IP-Adresse)
- Erstellung, Änderung und Löschung von Arbeitszeitdaten
- Änderungen an Schicht- und Dienstplänen
- Genehmigungs-/Ablehnungsaktionen bei Urlaubsanträgen
- Änderungen an Benutzerrollen und Berechtigungen
- Export- und Report-Aktionen
Append-only durch DB-Trigger: Audit-Logs sind durch einen Datenbank-Trigger (BEFORE UPDATE OR DELETE) vor Änderung geschützt, der Ausnahmen nur für eine retention_role zulässt. Eine technische WORM-Speicherung oder kryptographische Hash-Verkettung ist nicht implementiert und geplant.
Protokollierung von Administrationsaktionen: Alle administrativen Aktionen (Benutzerverwaltung, Konfigurationsänderungen) werden protokolliert.
Aufbewahrung der Audit-Logs: 4 Jahre Aufbewahrungsfrist für Zeit- und Audit-Daten (gesetzliche Anforderung Spanien). Ein automatisierter Löschjob (Purge) für Audit-Logs nach Fristablauf ist derzeit nicht implementiert; die fristgerechte Löschung wird server-seitig/organisatorisch sichergestellt, ein dedizierter Retention-Job ist geplant.

5. Auftragskontrolle

Maßnahmen zur Sicherstellung, dass personenbezogene Daten, die im Auftrag verarbeitet werden, nur entsprechend den Weisungen des Verantwortlichen verarbeitet werden:

Weisungsbindung: Alle Mitarbeiter von flowgeist, die mit der Verarbeitung personenbezogener Daten betraut sind, unterliegen der Weisungsbindung gemäß Art. 28 Abs. 3 lit. a DSGVO.
Vertragliche Regelungen: AVV mit allen Unter-Auftragsverarbeitern (Hetzner, Stripe, AWS S3) gemäß Art. 28 Abs. 4 DSGVO.
Technische Trennung: Daten verschiedener Kunden (Tenants) werden technisch getrennt (Multi-Tenant-Isolation, siehe Trennungskontrolle).
Datenverarbeitungsregister: Führung eines Verzeichnisses von Verarbeitungstätigkeiten gemäß Art. 30 DSGVO.
Schulung: Regelmäßige Schulung der Mitarbeiter zu Datenschutz und Informationssicherheit.
Unter-Auftragsverarbeiter-Kontrolle: Regelmäßige Überprüfung der Unter-Auftragsverarbeiter auf Einhaltung der AVV-Vorgaben.

6. Verfügbarkeitskontrolle

Maßnahmen zur Sicherstellung, dass personenbezogene Daten vor zufälliger Zerstörung oder Verlust geschützt sind:

Tägliche Backups: Tägliche automatische Backups der PostgreSQL-Datenbank (pg_dump, komprimiert). Lokale Dump-Dateien werden 30 Tage rollierend auf dem AES-256-verschlüsselten Server-Volume aufbewahrt; zusätzlich werden die Backups täglich dateibasiert verschlüsselt (AES-256-CBC) auf ein separates Offsite-Storage-Backend repliziert.
Backup-Aufbewahrung: Gestaffelte Aufbewahrungsfristen für die Offsite-Backups — tägliche Backups 7 Tage, wöchentliche 4 Wochen, monatliche 6 Monate.
Redis Cache: Redis wird in der Entwicklung eingesetzt; in Produktion fällt die Anwendung auf In-Memory-Caching zurück. Redis-Daten sind reproduzierbar aus der PostgreSQL-Datenbank und daher nicht kritisch für die Datenintegrität.
Backup-Prüfung: Regelmäßige Überprüfung der Backup-Integrität (Restore-Tests in quartälem Abstand).
Redundanz: Redundante Systemarchitektur mit automatischem Failover bei Ausfall einzelner Komponenten.
Monitoring: 24/7-Monitoring der Systemverfügbarkeit mit automatischen Alarmierungen bei Störungen.
Notfallwiederherstellung (Disaster Recovery): Dokumentiertes Disaster-Recovery-Verfahren mit definiertem Recovery Point Objective (RPO ≤ 24h) und Recovery Time Objective (RTO ≤ 4h).
AWS S3-Verfügbarkeit: AWS S3 bietet eine eingebaute Redundanz (99.999999999% / 11x9 Datenbeständigkeit) und Versionierung.
Strom- und Netzwerkredundanz: Redundante Stromversorgung und Netzwerkanbindungen im Rechenzentrum.

7. Trennungskontrolle

Maßnahmen zur Sicherstellung, dass zu unterschiedlichen Zwecken erhobene Daten getrennt verarbeitet werden:

Multi-Tenant-Architektur: Die CombiJornada-Plattform implementiert eine strikte Multi-Tenant-Isolation. Daten verschiedener Kunden (Tenants) werden logisch und technisch getrennt.
Datenbank-Isolation: Tenant-Trennung erfolgt auf Anwendungsebene über gestoriaId / organizationId-Filter in den API-Handlern. PostgreSQL Row-Level-Security (RLS) ist nicht implementiert; die Einführung von RLS ist geplant.
Redis-Namespace-Isolation: Redis-Caches nutzen namensräumliche Trennung (Namespace-Prefixing pro Tenant), um eine Vermischung von Cache-Daten zwischen Tenants auszuschließen.
AWS S3-Trennung: Datei-Storage in AWS S3 erfolgt mit Tenant-spezifischen Bucket-Prefixen und Bucket-Policies, die den Zugriff auf den jeweiligen Tenant einschränken.
Rollenbasierte Datenzugriffe: Innerhalb eines Tenants werden Datenzugriffe über RBAC gesteuert (z. B. Mitarbeiter sehen nur eigene Arbeitszeitdaten, HR-Personal sieht alle).
Trennung von Produktions- und Entwicklungsumgebung: Strikte Trennung von Produktions-, Staging- und Entwicklungsumgebungen. Keine personenbezogenen Daten in Entwicklungs- oder Testumgebungen.
Log-Trennung: Audit-Logs werden getrennt von Anwendungsdaten gespeichert und sind nur für autorisierte Administratoren zugänglich.

8. Verschlüsselung

Maßnahmen zum Schutz personenbezogener Daten durch Verschlüsselung:

Datenbank-Verschlüsselung (at-rest): PostgreSQL-Datenbank mit AES-256-Verschlüsselung auf Datenträgerebene (LUKS / Hetzner Volume Encryption).
Transportverschlüsselung (in-transit): TLS 1.2 und 1.3 für Datenübertragungen (siehe Übertragungskontrolle).
AWS S3 server-side encryption: S3-Objekte werden mit ACL: private gespeichert. SSE-S3 serverseitige Verschlüsselung, Bucket-Versionierung, Access-Logging und Block-Public-Access sind auf Bucket-Ebene nicht explizit konfiguriert und geplant.
Passwort-Hashing: Passwörter werden mit bcrypt gehasht (mit Salt und ausreichendem Cost-Factor). Keine Klartext-Speicherung.
JWT-Signierung: JSON Web Tokens werden kryptographisch signiert (HMAC-SHA256 oder RS256), um Manipulation zu verhindern.
Backup-Verschlüsselung: Die täglichen Offsite-Backups werden vor der Übertragung auf das separate Storage-Backend mit AES-256 verschlüsselt.
Redis-Verschlüsselung: Redis-Verbindungen werden über TLS verschlüsselt (sofern Redis in Produktion eingesetzt wird; derzeit In-Memory-Fallback).
Schlüsselverwaltung: Kryptographische Schlüssel werden sicher verwaltet (separate Speicherung, Zugriffsbeschränkung, regelmäßige Rotation).

9. Pseudonymisierung

Maßnahmen zur Pseudonymisierung personenbezogener Daten:

Tenant-IDs: Daten werden über Tenant-IDs pseudonymisiert zugeordnet, sodass eine direkte Zuordnung zu einem Kunden nur mit zusätzlichen Informationen möglich ist.
User-IDs: Interne Benutzerkennungen (UUIDs) werden anstelle von Klartext-Namen in Logs und Caches verwendet, wo immer dies technisch möglich ist.
Audit-Logs: In Audit-Logs werden, soweit möglich, pseudonymisierte Identifikatoren verwendet. Die Zuordnungstabelle ist separat und zugriffsgeschützt gespeichert.
Reporting: In aggregierten Reports werden Daten pseudonymisiert dargestellten, wo dies für den Zweck ausreicht.
Einschränkung: Aufgrund der Natur der Plattform (Arbeitszeit- und Schichtplanung) ist eine vollständige Pseudonymisierung nicht möglich, da die Zuordnung von Arbeitszeiten zu konkreten Mitarbeitern funktional erforderlich ist (Art. 34 Estatuto de los Trabajadores).

10. Regelmäßige Überprüfung

Maßnahmen zur regelmäßigen Überprüfung und Bewertung der Wirksamkeit der TOMs:

Überprüfungsintervall: Die TOMs werden mindestens jährlich überprüft und bei Bedarf angepasst.
Security Audits: Regelmäßige Sicherheits-Audits der Plattform (mindestens jährlich), inkl. Penetration Testing durch externe Dienstleister.
Verletzungsmanagement: Dokumentiertes Verfahren zum Umgang mit Sicherheitsverletzungen (Incident Response Plan) mit definierten Eskalationsstufen und Meldepflichten.
Schwachstellenmanagement: Kontinuierliches Monitoring von Sicherheitslücken (CVE-Datenbanken) und zeitnahe Installation von Sicherheits-Updates.
Patch-Management: Automatisierte und manuelle Patch-Prozesse für Betriebssystem, Laufzeitumgebung (Next.js 15, React 19, Node.js) und Abhängigkeiten.
Abhängigkeitsprüfung: Regelmäßige Überprüfung von npm-Abhängigkeiten auf bekannte Schwachstellen (npm audit / Dependabot).
Mitarbeiterschulung: Jährliche Schulung aller Mitarbeiter zu Datenschutz (DSGVO, LOPDGDD) und Informationssicherheit.
Zertifizierung: Streben nach ISO 27001-Zertifizierung; Hetzner-Rechenzentrum bereits ISO 27001-zertifiziert.
Dokumentation: Alle Überprüfungen und Audits werden dokumentiert und der Aufsichtsbehörde auf Anfrage zur Verfügung gestellt.

11. Unter-Auftragsverarbeiter

Die folgenden Unter-Auftragsverarbeiter werden im Rahmen der CombiJornada-Plattform eingesetzt:

Unter-Auftragsverarbeiter	Sitz	Leistung	Drittstaaten-Transfer	Schutzmaßnahmen
Hetzner Online GmbH	Deutschland (Falkenstein)	Hosting, PostgreSQL 16, Redis, Backup	Keine (EU)	ISO 27001-zertifiziertes Rechenzentrum, AVV
Stripe Payments Europe, Ltd.	Irland (IE) / USA (US-Konzernmutter)	Zahlungsabwicklung	EU-US DPF + SCC	AVV, EU-US Data Privacy Framework, SCC
AWS S3 (Amazon Web Services, Inc.)	USA / EU	Datei-Storage (Dokumente, PDFs)	EU-US DPF + SCC	AVV, EU-US Data Privacy Framework, SCC
Lexware GmbH	Deutschland (DE)	Rechnungsstellung / Buchhaltung	Keine (EU)	AVV gemäß Art. 28 DSGVO
Meta Platforms Ireland Ltd. (WhatsApp Business API)	Irland (IE) / USA (US-Konzernmutter)	WhatsApp-Messaging	EU-US DPF + SCC	AVV, EU-US Data Privacy Framework, SCC
OpenStreetMap Foundation	Vereinigtes Königreich (UK)	Kartenanzeige (Location-Map)	UK Adequacy / SCC	AVV / SCC

Mit allen Unter-Auftragsverarbeitern sind AVV-Vereinbarungen gemäß Art. 28 Abs. 4 DSGVO abgeschlossen. Die Unter-Auftragsverarbeiter werden regelmäßig auf Einhaltung der datenschutzrechtlichen Vorgaben überprüft.

12. AWS S3 Besonderheiten

Die Nutzung von AWS S3 für Datei-Storage erfordert besondere Schutzmaßnahmen aufgrund der Drittstaaten-Übermittlung (USA):

Server-side encryption (SSE-S3, AES-256): S3-Objekte werden mit ACL: private gespeichert. SSE-S3 serverseitige Verschlüsselung ist auf Bucket-Ebene nicht explizit konfiguriert; die Aktivierung von SSE-S3 ist geplant.
Bucket-Policies mit Least Privilege: Zugriff auf S3-Buckets erfolgt über IAM. Der öffentliche Zugriff wird über ACL: private auf Objektebene verhindert. Explizite Block Public Access-Konfiguration auf Bucket-Ebene ist geplant.
Region-Konfiguration: Bevorzugt wird die AWS-Region eu-central-1 (Frankfurt, Deutschland) für die Speicherung von Daten, um die Datenverarbeitung innerhalb der EU zu gewährleisten. US-Regionen werden nur bei konkretem Bedarf (z. B. für spezifische Services) genutzt. In solchen Fällen erfolgt die Übermittlung auf Grundlage des EU-US Data Privacy Framework (DPF) und der Standardvertragsklauseln (SCC).
Access Logging: S3-Access-Logging ist auf Bucket-Ebene nicht explizit konfiguriert; die Aktivierung ist geplant.
Versionierung: S3-Bucket-Versionierung ist nicht explizit aktiviert; die Aktivierung ist geplant, um versehentliches Löschen oder Überschreiben von Objekten zu verhindern.
Lifecycle-Richtlinien: S3-Lifecycle-Richtlinien für die automatische Löschung oder Archivierung von Objekten nach Ablauf der Aufbewahrungsfristen sind derzeit nicht auf Bucket-Ebene konfiguriert und geplant.
Transfer-Impact-Assessment (TIA): Für die Nutzung von AWS S3 in US-Regionen wurde eine TIA gemäß Art. 46 DSGVO durchgeführt. Die TIA wird mindestens jährlich aktualisiert und bei Änderungen der Rechtslage (insbesondere des EU-US Data Privacy Framework) überprüft.
Datenminimierung: Es werden nur die für den jeweiligen Zweck notwendigen Dateien in AWS S3 gespeichert. Personenbezogene Daten in Dokumenten (z. B. Arbeitsverträge) werden nach Ablauf der Aufbewahrungsfristen gelöscht (automatisierte S3-Lifecycle-Regeln geplant).

13. Änderungshistorie

Version	Datum	Wesentliche Änderungen
1.0	08.08.2026	Erstfassung der TOMs für CombiJornada
1.1	29.08.2026	Code-Abgleich: Redis-Produktivstatus korrigiert, TLS 1.2/1.3 statt 1.3-only, DB-TLS als geplant gekennzeichnet, WORM durch DB-Trigger ersetzt, RLS als nicht implementiert gekennzeichnet, Backup-Verschlüsselung als geplant gekennzeichnet, AWS S3 SSE/Versioning/Access-Logging als geplant gekennzeichnet, Lexware/Meta/OSM als Unter-Auftragsverarbeiter ergänzt
1.2	22.09.2026	Code-Abgleich (Rest): Passwort-Hashing auf bcrypt konkretisiert (kein Argon2 im Code); Lockout-Claim entfernt (kein Lockout/Rate-Limiting implementiert, geplant); Audit-Retention vereinheitlicht auf 4 Jahre + fehlender Purge-Job als geplant gekennzeichnet; Backup-Block auf verschlüsselte Offsite-Realität gehoben (AES-256, Retention 7d/4w/6m); S3-Lifecycle als geplant gekennzeichnet
1.3	22.09.2026	Server-Verifikation: Backup-Block präzisiert (lokale pg_dump-Dumps 30 Tage rollierend auf AES-256-Volume + dateiverschlüsselte AES-256-CBC-Offsite-Replikation 7d/4w/6m); kein MinIO-/Audit-Purge-Cron auf Server
1.2	22.09.2026	Code-Abgleich (Rest): Passwort-Hashing auf bcrypt konkretisiert (kein Argon2 im Code); Lockout-Claim entfernt (kein Lockout/Rate-Limiting implementiert, geplant); Audit-Retention vereinheitlicht auf 4 Jahre + fehlender Purge-Job als geplant gekennzeichnet; Backup-Block auf verschlüsselte Offsite-Realität gehoben (AES-256, Retention 7d/4w/6m); S3-Lifecycle als geplant gekennzeichnet