Technical and Organisational Measures (TOM) – WorkLogx
Last updated: 29 Oct 2026 · Version 2026-10-29
This document describes the technical and organisational measures for WorkLogx under Art. 32 GDPR and serves as the detailed elaboration of Annex 2 of the Data Processing Agreement (DPA).
Legend
- VERIFIED – evidenced in the repository, live public infrastructure, or checked provider documentation
- OWNER POLICY REQUIRED – organisational commitment; not proven by code alone
- RECOMMENDED – proposed operational measure; not claimed as already implemented
1. Controller / provider
Monadion GmbH
Schönbrunner Straße 181/1
1120 Vienna
Austria
Privacy contact: [email protected]
Support: [email protected]
Where Monadion processes tenant personal data on behalf of customers, the WorkLogx DPA applies. Current sub-processor list: /subprocessors.
2. Infrastructure
VERIFIED (audit date 29 Oct 2026):
| Component | Provider / note | Region / country |
|---|---|---|
Application server (app.worklogx.com, api.worklogx.com) | Hetzner Cloud | Public IP in Hetzner network CLOUD-FSN1, country DE (RIPE) |
| PostgreSQL | On Monadion Hetzner infrastructure (Docker/Coolify per deploy templates) | Operated with the app server on the same Hetzner environment; no separate DB region documented in this repository |
| Object storage | Hetzner Object Storage | Region `fsn1` (bucket naming / storage config, e.g. *-fsn1) |
| Coolify | Deployment/orchestration on the Hetzner host | Location = host FSN1 (DE); Coolify UI backup settings not read in this audit (Coolify unavailable) |
| Cloudflare | DNS for WorkLogx hostnames; marketing site proxied; app/api currently DNS only | No EU-only claim without Regional Services |
Not claimed: encryption at rest for volumes/buckets unless evidenced by active provider configuration or contract extract in this repository.
3. Physical / access protection
VERIFIED (application side):
- Public API/app reachable only via HTTPS endpoints (live check).
- Internal bridge/service routes must be denied on public hostnames (
deploy/ingress/); application also checks bridge/service credentials. - Platform administration only via operator allow-list (
FIELDOPS_OPERATORS), not via tenant roleADMIN.
OWNER POLICY REQUIRED: physical site access is with the infrastructure provider (Hetzner); restrict Monadion Coolify/Hetzner console access to authorised persons.
4. Authentication
VERIFIED:
- Firebase Authentication for user identities (login, tokens).
- Office second factor enforced in production profile (
security.office-second-factor-enforced: true). - Platform Admin requires operator allow-list and second-factor claim (
PlatformAdminGuard). - Roles:
ADMIN,OPERATIONS,EMPLOYEE(noOWNER).
5. Authorisation management
VERIFIED:
- Permissions via
WorklogxPermission/ authorisation service. - Deny-by-default for unknown/missing permissions.
- Feature gates tied to billing/entitlements.
- Cross-tenant access denied (
WRONG_TENANTand related reasons).
6. Tenant isolation
VERIFIED:
- Organisation-scoped membership and permission checks.
- Storage object paths under
org/{organizationId}/with reconciliation against that prefix. - Tenant security matrix and isolation tests (
docs/testing/TENANT_SECURITY_MATRIX.md). - TEST vs PRODUCTION via
WORKLOGX_ENVIRONMENT; PRODUCTION startup fails on clear TEST resources.
7. Transport encryption
VERIFIED:
- Public endpoints served over HTTPS (live check).
- Session cookies configurable/set
secure: truein prod. - Stripe webhooks and similar integrations with signature verification in application code.
Not claimed: detailed TLS termination implementation (reverse proxy / Coolify / edge).
8. Protection of secrets
VERIFIED:
- Secrets via environment variables, not Platform Admin business config.
- Integration token encryption (AES) via
FORM_API_ENCRYPTION_KEY; PRODUCTION refuses to start without the key. - Webhook secrets stored encrypted.
- No secrets in git templates.
9. Logging & audit
VERIFIED:
- Security-relevant audit events (
SecurityAuditWriter). - Platform Admin actions auditable.
- Technical error logging; optional Sentry only if
SENTRY_DSNis set (deploy template default: unset).
RETENTION GAP: no coded retention for security audit events or server/access logs in this repository.
10. Backup / recovery
CURRENT (audit)
| Area | Status | Evidence |
|---|---|---|
| PostgreSQL backup | UNKNOWN / not documented in repo | No pg_dump/Coolify backup policy in deploy/ or docs/; Coolify UI not inspected in this audit |
| Server snapshots | UNKNOWN | No Hetzner snapshot policy in the repository |
| Object storage backup/versioning | UNKNOWN / no app-level backup | Soft-delete + purge is not a backup; object-store versioning not configured in repo |
| RPO / RTO | undefined | — |
| Restore test | not documented | — |
RECOMMENDED (to implement – not current state)
Database: daily PostgreSQL backup; 30-day retention; destination separate from primary volume where practical; encrypted transport; restricted operator access; quarterly documented restore test.
Server: Hetzner snapshots/backups as secondary recovery only.
Object storage: primarily provider durability + app retention/purge; additional cross-bucket backup only after risk decision; not claimed today.
Until implemented, DPA §17.7 / backup retention remains open.
11. Deletion & retention
VERIFIED technical periods:
| Item | Period | Source |
|---|---|---|
| Deleted storage objects (purge) | default 30 days | storage.retentionDays |
| Export archives | default 7 days | storage.exportExpiryDays |
| Smart Builder temporary processing | 7 days | AI form-builder retention default |
| Validation runs (stale) | 60 days | ValidationRunRetentionScheduler |
| Post-contract export window | 30 days | DPA / Terms / Privacy |
RETENTION GAPS: security audit events; server/access/Coolify logs; billing history; absences; released/frozen submissions; backups once configured.
12. Storage security
VERIFIED: organisation quotas; soft-delete + purge; ledger/bucket reconciliation; upload limits; presigned download TTL.
13. AI processing security
VERIFIED: feature-gated AI; store: false where implemented (not a “no training” claim); human decisions for material HR measures; providers listed at /subprocessors.
14. Incident management
CURRENT: no standalone incident-response runbook found in the repository (beyond DPA breach-notification duties).
RECOMMENDED minimal process (OWNER POLICY REQUIRED): detect → contain → preserve evidence → assess → notify customers where required → support Art. 33/34 → remediate → post-incident review. No guaranteed response times.
15. TEST/PROD separation
VERIFIED: environment flag; separate Firebase/buckets/operators/Stripe intended; PRODUCTION startup fails on clear TEST resources.
16. Sub-processors
See /subprocessors.
17. Review of TOMs
Review on material infrastructure, auth, retention or provider changes.
Next owner actions: enable and document backup policy in Coolify/Hetzner; approve incident runbook; decide retention gaps.
Last updated: 29 Oct 2026 · Version 2026-10-29