Technische und organisatorische Maßnahmen (TOM) – WorkLogx
Stand: 29.10.2026 · Version 2026-10-29
Dieses Dokument beschreibt die technischen und organisatorischen Maßnahmen für WorkLogx gemäß Art. 32 DSGVO und dient als detaillierte Ausgestaltung zu Anlage 2 des Auftragsverarbeitungsvertrags (AVV).
Legende
- VERIFIED – im Repository, in der laufenden öffentlichen Infrastruktur oder in geprüfter Anbieterdokumentation nachweisbar
- OWNER POLICY REQUIRED – organisatorische Verpflichtung; nicht allein durch Code nachweisbar
- RECOMMENDED – vorgeschlagene Betriebsmaßnahme; nicht als bereits umgesetzt behauptet
1. Verantwortliche Stelle / Anbieter
Monadion GmbH
Schönbrunner Straße 181/1
1120 Wien
Österreich
Datenschutzkontakt: [email protected]
Support: [email protected]
Soweit Monadion personenbezogene Mandantendaten im Auftrag von Kunden verarbeitet, gilt der WorkLogx-AVV. Die aktuelle Unterauftragsverarbeiterliste: /subprocessors.
2. Infrastruktur
VERIFIED (Stand Audit 29.10.2026):
| Komponente | Anbieter / Hinweis | Region / Land |
|---|---|---|
Application Server (app.worklogx.com, api.worklogx.com) | Hetzner Cloud | Öffentliche IP gehört zu Hetzner-Netz CLOUD-FSN1, Land DE (RIPE) |
| PostgreSQL | Auf Monadion-Hetzner-Infrastruktur (Docker/Coolify-Deployments laut Deploy-Templates) | Mit App-Server auf derselben Hetzner-Umgebung betrieben; keine separate DB-Region in diesem Repository dokumentiert |
| Object Storage | Hetzner Object Storage | Region `fsn1` (Bucket-Namenskonvention / Storage-Konfiguration; z. B. *-fsn1) |
| Coolify | Deployment-/Orchestrierungsschicht auf dem Hetzner-Host | Ort = Host FSN1 (DE); Coolify-UI-Backup-Einstellungen in diesem Audit nicht aus Coolify ausgelesen (Coolify nicht erreichbar) |
| Cloudflare | DNS für WorkLogx-Hostnamen; Marketing-Website proxied; app/api derzeit DNS only | Keine EU-only-Zusage ohne Regional Services |
Nicht behauptet: Verschlüsselung at rest der Volumes/Buckets, solange dies nicht aus aktiver Provider-Konfiguration oder Vertragsextrakt in diesem Repository belegt ist.
3. Zutritts-/Zugangsschutz
VERIFIED (anwendungsseitig):
- Öffentliche API/App nur über HTTPS-Endpunkte erreichbar (Live-Check
https://app.worklogx.com,https://api.worklogx.com). - Interne Bridge-/Service-Routen sind für öffentliche Hostnamen zu sperren (
deploy/ingress/); Anwendung prüft Bridge-/Service-Credentials zusätzlich. - Plattformadministration nur über Operator-Allow-List (
FIELDOPS_OPERATORS), nicht über MandantenrolleADMIN.
OWNER POLICY REQUIRED: physischer Zutritt zum Hosting-Standort liegt beim Infrastrukturanbieter (Hetzner); Monadion-Zugänge zu Coolify/Hetzner-Console auf autorisierte Personen beschränken.
4. Authentifizierung
VERIFIED:
- Firebase Authentication für Benutzeridentitäten (Login, Tokens).
- Office-Second-Factor in Produktionsprofil erzwungen (
security.office-second-factor-enforced: trueinapplication-prod.yml). - Platform Admin erfordert Operator-Allow-List und Second-Factor-Claim (
PlatformAdminGuard). - Rollenmodell:
ADMIN,OPERATIONS,EMPLOYEE(keinOWNER).
5. Berechtigungsmanagement
VERIFIED:
- Berechtigungen über
WorklogxPermission/ Authorization-Service. - Deny-by-default: unbekannte/fehlende Berechtigungen werden abgelehnt (
WorklogxAuthorizationService). - Feature-Gates an Billing/Entitlements gekoppelt.
- Tenant-fremde Zugriffe werden mit Gründen wie
WRONG_TENANTabgewiesen.
6. Mandantentrennung
VERIFIED:
- Organisationsbezogene Membership und Permission-Prüfung.
- Storage-Objektpfade mit Präfix
org/{organizationId}/und Reconciliation gegen dieses Präfix (StorageReconciliationService). - Tenant-Security-Matrix und Isolationstests dokumentiert (
docs/testing/TENANT_SECURITY_MATRIX.md). - TEST vs PRODUCTION über
WORKLOGX_ENVIRONMENTgetrennt; Startup-Fail-Safes gegen klare TEST-Ressourcen in PRODUCTION (docs/environment-separation.md).
7. Transportverschlüsselung
VERIFIED:
- Öffentliche Endpunkte werden per HTTPS betrieben (Live-Check).
- Session-Cookies in Prod mit
secure: truekonfigurierbar/gesetzt (application-prod.yml). - Stripe-Webhooks und vergleichbare Integrationen mit Signaturprüfung im Anwendungscode.
Nicht behauptet: TLS-Terminierungsimplementation im Detail (liegt am Reverse Proxy / Coolify / Edge).
8. Schutz von Secrets
VERIFIED:
- Secrets über Umgebungsvariablen (Coolify/ENV), nicht über Platform-Admin-Business-Config (
docs/platform-admin-env-migration.md). - Integrationstoken-Verschlüsselung (AES) über
FORM_API_ENCRYPTION_KEY/TokenEncryptionService; in PRODUCTION Startverweigerung ohne Key. - Webhook-Secrets verschlüsselt gespeichert (
WebhookSecretCipher). - Keine Secrets in Git-Templates (Beispiele ohne Werte).
9. Logging & Audit
VERIFIED:
- Sicherheitsrelevante Audit-Events (
SecurityAuditWriter/SecurityAuditEvent). - Platform-Admin-Aktionen auditierbar.
- Technische Fehlerprotokollierung; optionales Sentry nur wenn
SENTRY_DSNgesetzt (Deploy-Template: standardmäßig unset → nicht als aktiver Prod-TOM-Dienst geführt).
RETENTION GAP: Keine codierte Löschfrist für Security-Audit-Events und Server-/Access-Logs in diesem Repository.
10. Datensicherung / Wiederherstellung
CURRENT (Audit)
| Bereich | Status | Evidence |
|---|---|---|
| PostgreSQL-Backup | UNKNOWN / nicht im Repo dokumentiert | Keine pg_dump-/Coolify-Backup-Policy in deploy/ oder docs/; Coolify-UI in diesem Audit nicht geprüft |
| Server-Snapshots | UNKNOWN | Keine Hetzner-Snapshot-Policy im Repository |
| Object-Storage-Backup/Versioning | UNKNOWN / kein App-Backup | Soft-Delete + Purge (Retention) ist kein Backup; Object-Store-Versioning nicht im Repo konfiguriert |
| RPO / RTO | nicht definiert | — |
| Restore-Test | nicht dokumentiert | — |
RECOMMENDED (noch umzusetzen – nicht als Ist-Zustand)
Datenbank
- Tägliches PostgreSQL-Backup (Coolify Scheduled Backup oder äquivalent)
- Retention 30 Tage
- Ziel möglichst getrennt vom Primärvolumen (z. B. separates Backup-Ziel / Object Storage)
- Verschlüsselter Transport zum Backup-Ziel
- Zugriff nur für autorisierte Monadion-Operatoren
- Quartalsweiser Restore-Test (dokumentiert)
Server
- Hetzner Snapshots/Backups als sekundärer Wiederherstellungsmechanismus
- Kein Ersatz für DB-Backup
Object Storage
- Primär: Anbieter-Durability + App-Retention/Purge
- Zusätzliches Cross-Bucket-Backup nur nach Risikoentscheidung; derzeit nicht behauptet
Bis zur Umsetzung bleibt AVV §17.7 / Backup-Retention offen.
11. Löschung & Retention
VERIFIED technische Fristen:
| Gegenstand | Frist | Quelle |
|---|---|---|
| Gelöschte Speicherobjekte (Purge) | standardmäßig 30 Tage | storage.retentionDays / Platform Settings Default |
| Export-Archive | standardmäßig 7 Tage | storage.exportExpiryDays |
| Smart-Builder temporäre Verarbeitungen | 7 Tage (7d) | WORKLOGX_AI_FORM_BUILDER_RETENTION Default |
| Validation-Runs (historisch/stale) | 60 Tage | ValidationRunRetentionScheduler.RETENTION_DAYS |
| Vertragsende Export-Übergangsfrist | 30 Tage | AVV / AGB / Datenschutz (vertraglich) |
RETENTION GAPS (keine willkürliche Code-Setzung):
- Security-Audit-Events
- Server-/Access-/Coolify-Logs
- Billing-/Stripe-Historie (Anbieter + lokale Spiegel)
- Abwesenheitsdaten (fachliche Aufbewahrung)
- Released/frozen Submissions (Immutability; Löschung nur nach Vertragsende/Weisung)
- Backups (sobald eingerichtet)
OWNER POLICY REQUIRED: rechtliche Aufbewahrungsentscheidungen für Billing, Abwesenheiten und freigegebene Nachweise festlegen.
12. Storage Security
VERIFIED:
- Organisationsbezogene Quotas und Add-ons (
StorageQuotaService). - Soft-Delete mit späterem Purge (
StorageRetentionJob). - Reconciliation Ledger ↔ Bucket-Präfix (
StorageReconciliationService). - Upload-Limits (Multipart/App-Limits in
application*.yml, z. B. Foto/Video-Obergrenzen). - Presigned Download-URLs mit konfigurierbarer TTL.
13. AI Processing Security
VERIFIED:
- KI nur bei Freischaltung/Nutzung der jeweiligen Funktion.
- API-Aufrufe setzen, soweit implementiert,
store: false(keine Behauptung „kein Training“ allein daraus). - Keine automatische Übernahme von KI-Ergebnissen als alleinige Personalentscheidung (Produkt-/AGB-Aussage).
- Provider und Rolle: siehe /subprocessors.
14. Incident Management
CURRENT: Kein separates Incident-Response-Runbook im Repository gefunden (außer datenschutzrechtlichen AVV-Pflichten zur Meldung).
RECOMMENDED Minimalprozess (OWNER POLICY REQUIRED):
1. Vorfall erkennen
2. Eindämmen
3. Beweise sichern
4. Betroffene Organisationen/Daten bewerten
5. Kunden unverzüglich informieren, soweit erforderlich
6. Unterstützung zu Art. 33/34 DSGVO
7. Beheben
8. Nachbereitung
Keine garantierten Reaktionszeiten.
15. TEST/PROD Separation
VERIFIED:
WORKLOGX_ENVIRONMENT=TEST|PRODUCTION- Getrennte Firebase-Projekte, Buckets, Operator-UIDs, Stripe-Umgebungen vorgesehen
- PRODUCTION-Startup schlägt fehl bei klaren TEST-Ressourcen (Bucket/URL/CORS/Stripe-Test)
16. Subprocessors
Aktuelle Klassifikation und Regionen: /subprocessors.
17. Review of TOMs
Dieses Dokument wird bei wesentlichen Infrastruktur-, Auth-, Retention- oder Anbieteränderungen überprüft.
Nächste Owner-Aktionen: Backup-Policy in Coolify/Hetzner aktivieren und dokumentieren; Incident-Runbook freigeben; Retention-Lücken entscheiden.
Stand: 29.10.2026 · Version 2026-10-29