⚖ TOMs – DIRIGENT

TOMs – DIRIGENT

v1.2 · 08.08.2026

TOMs – DIRIGENT

Version 1.2 · Stand: 08.08.2026
flowgeist ZERO flowgeist KITA flowgeist TOOL CombiJornada DIRIGENT flowgeist DMS flowgeist UNI

Technical and Organizational Measures (TOMs) – DIRIGENT

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

1. Access Control to Premises

Measures to prevent unauthorized persons from gaining access to data-processing facilities:

  • Data center: The servers are operated at Hetzner Online GmbH in Falkenstein (Germany). The data center features multi-tier physical access control.
  • Data center access control: 24/7 video surveillance, personnel airlock with ID card and biometric control, access logging.
  • Server rack: Physical locking of server racks. Access only for authorized Hetzner personnel.
  • Office premises: The office premises of flowgeist are equipped with a mechanical locking system. Access only for authorized persons.
  • Key management: Strict key management with documentation of key issuance and return.
  • Visitor control: Visitors are registered and accompanied throughout their entire stay.

2. Access Control to Systems

Measures to prevent unauthorized persons from using data-processing systems and gaining access to personal data:

  • Authentication: Access to systems and applications requires strong authentication using username and password. Passwords are stored hashed using Argon2id (memory 64 MiB, iterations 3, parallelism 4). Legacy bcrypt hashes are transparently migrated to Argon2id upon the next successful login.
  • Password policies: Enforcement of password policies (minimum length, complexity, regular changes).
  • Multi-factor authentication (MFA): Available for all user accounts via TOTP (Time-based One-Time Password). Once MFA is enabled for an account, the second factor is strictly required at login. A role-based MFA requirement (e.g., for administrators) is currently not technically enforced and is planned.
  • Single Sign-On (SSO): SSO support for centralized authentication in B2B environments.
  • Role-based access control (RBAC): Strict role-based access control following the least-privilege principle. Users receive only the rights required for their role.
  • PKCE session with HttpOnly cookies: PKCE (Proof Key for Code Exchange) with server-side session management. Access and refresh tokens are stored in HttpOnly, Secure (in production), SameSite=strict cookies. Refresh tokens are stored server-side in Redis as SHA-256 hash.
  • Refresh token rotation: A new refresh token is issued on each token renewal to prevent token misuse.
  • Multi-tenant isolation: Each customer (tenant) receives an isolated data area. Data sharing between tenants is technically restricted through PostgreSQL Row-Level-Security (RLS). FORCE ROW LEVEL SECURITY is enabled for tables up to migration 68; for newer tables (from migration 69), RLS is enabled but FORCE RLS is pending and planned.
  • Access logging: All accesses to systems and personal data are logged (audit trail aligned with ISO 27001 A.12.4).
  • Session management: Automatic session timeout upon inactivity.
  • ThrottlerGuard: Global rate limiting to protect against brute-force attacks and abuse; repeated login attempts are throttled. An automatic account lockout is currently not implemented.

3. Transmission Control

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

  • Transport encryption: Data transmissions are encrypted using TLS 1.3 (Transport Layer Security). TLS 1.3 is enforced server-side as the minimum version; TLS 1.2 is disabled.
  • HTTPS: All web communication takes place exclusively via HTTPS (HSTS enabled).
  • API encryption: All API endpoints require encrypted connections (HTTPS/TLS 1.3).
  • CORS origin whitelist: In production, strict CORS origin whitelist, no localhost fallback.
  • Swagger/OpenAPI disabled: Swagger/OpenAPI documentation is disabled in production (ISO 27001 A.13.1.1).
  • Certificate management: Use of valid TLS certificates with automatic renewal. Monitoring of certificate validity.
  • Database connections: Connections to the PostgreSQL 18 database are TLS-encrypted in the production environment (sslmode=verify-full).
  • Redis connections: Redis connections are currently unencrypted (plain TCP). TLS for Redis is planned.
  • Backup transmission: Backup transmission is encrypted, provided backups are transmitted.
  • WAF (Web Application Firewall): All API access is filtered through an upstream Web Application Firewall (ModSecurity v3 with OWASP Core Rule Set v4) before reaching the backend.

4. Input Control

Measures to enable subsequent verification and determination of whether and by whom personal data has been entered, altered, or removed in data-processing systems:

  • audit trail aligned with ISO 27001 A.12.4: Logging of all security-relevant actions aligned with ISO 27001, including:
    • Timestamp
    • User ID
    • Tenant ID
    • Action (create, read, update, delete)
    • Resource
    • IP address
    • User-Agent
    • Trace IDs (OpenTelemetry W3C Trace Context)
  • Logging of administrative actions: All administrative actions (user management, role changes, tenant configuration) are logged.
  • Override audit: Manual overrides in the Workflow Engine (transition checklists, quality gates) are fully logged.
  • Integrity protection of logs: Audit logs are stored as a partitioned, cryptographically chained hash chain (SHA-256, sequence/prevHash/hash per entry). Subsequent modification of individual entries is thereby detectable (tamper-evident). Deletion takes place via partition detach after expiry of the retention period.
  • Log retention: Audit logs are stored in partitions and retained for 7 years (configurable).
  • Versioning: Data changes are documented with version levels, where applicable.

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:

  • Contractual binding: Conclusion of Data Processing Agreements (DPA) in accordance with Art. 28 GDPR with all sub-processors.
  • Instruction binding: Processing of personal data exclusively in accordance with the documented instructions of the Controller.
  • Sub-processor control: Careful selection and regular review of sub-processors (Hetzner Online GmbH).
  • Contractual obligations: All employees and sub-processors are contractually bound to confidentiality.
  • Documentation: Complete documentation of processing operations and instructions.
  • No external services (active): The platform currently does not use active external AI services, web analytics, or payment services. Adapters exist for Auth0/Keycloak, SuperOffice, Work4All, Jira, MS365/Graph (Booking/Calendar), AGE, Confluence, FAUST, Handelsregister, MS Dynamics 365, SAP S/4HANA. HTTP calls to external services are disabled by default via *_USE_HTTP flags. Mock connectors exist for SharePoint and Leadinfo (both backlog). Planned integrations: MS365 Booking and MS365 Graph email notifications.

6. Availability Control

Measures to protect personal data against accidental destruction or loss:

  • Backup strategy: Daily automated backups of the PostgreSQL database (pg_dump). The backups are replicated in encrypted form (AES-256) to a separate offsite storage backend (automated via systemd timer). In addition, infrastructure-level snapshots are provided via Hetzner.
  • Backup retention: Tiered retention periods for the offsite backups — daily backups 7 days, weekly 4 weeks, monthly 6 months.
  • Backup testing: Regular verification of backup restoration (restore tests).
  • Redundancy: Use of redundant system components to avoid single points of failure.
  • Monitoring: Continuous monitoring of system availability and performance via OpenTelemetry, Loki, Tempo, and Grafana (internal observability). Automatic alerting in case of disruptions.
  • High availability: The infrastructure at Hetzner Online GmbH provides redundant power supply, cooling, and network connectivity.
  • Emergency plan: Documented disaster recovery plan with defined Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).
  • Fault tolerance: Automatic restart in case of system failures. Monitoring of system integrity.
  • Outbox pattern: State change and event are written in a single transaction to ensure data consistency and availability.

7. Separation Control

Measures to ensure that personal data collected for different processing purposes can be processed separately:

  • Multi-tenant isolation: Strict logical separation of data between different customers (tenants). Each tenant receives an isolated data area. Data sharing between tenants is technically excluded.
  • PostgreSQL Row-Level-Security (RLS): Data of different tenants is separated in the PostgreSQL 18 database through Row-Level-Security. In each transaction, SET LOCAL app.tenant_id is executed. FORCE ROW LEVEL SECURITY is enabled for tables up to migration 68; for newer tables (from migration 69), RLS is enabled but FORCE RLS is pending and planned.
  • Tenant context propagation: The tenant context is propagated via JWT claim and applied consistently in each transaction.
  • Role-based separation: Functional separation through RBAC. Data for different processing purposes (e.g., audit logs, workflow data, notifications) are stored and managed separately.
  • Environment separation: Strict separation of production, staging, and development environments. Production data is not used in non-production environments.
  • Log separation: Audit logs are stored separately from operational data to ensure tamper-proof retention.
  • Module isolation: NestJS modular monolith with strict module isolation. Communication between modules takes place exclusively via internal API routes.

8. Encryption

Measures to ensure the confidentiality and integrity of personal data through encryption:

  • Transport encryption: TLS 1.3 for data transmissions (HTTPS, API). Database connections are TLS-encrypted in the production environment (sslmode=verify-full); Redis connections within the Docker network are currently unencrypted, TLS is planned.
  • Encryption at rest: AES-256 encryption for stored data (database, file systems). Offsite backups are encrypted with AES-256 before transfer.
  • Password hashing: Passwords are stored using Argon2id (memory 64 MiB, iterations 3, parallelism 4). No plaintext passwords are stored. Legacy bcrypt hashes are transparently migrated to Argon2id upon the next successful login.
  • MFA secrets: TOTP secrets for multi-factor authentication are stored encrypted.
  • Key management: Secure management of encryption keys. Keys are stored separately from the encrypted data.

9. Pseudonymization

Measures for the pseudonymization of personal data:

  • Pseudonymization of audit data: IP addresses and other identifying fields in audit logs are fully deleted after the retention period expires (partition detach) — no subsequent pseudonymization of individual fields takes place.
  • Tenant IDs: The attribution of data to a specific customer is made via pseudonymous tenant IDs, which do not allow direct inference of the customer’s identity without access to the mapping table.
  • Trace IDs: OpenTelemetry trace IDs enable pseudonymous correlation of requests across system boundaries, without revealing personal data.

10. Regular Review

Measures for the regular review and assessment of the effectiveness of the technical and organizational measures:

  • Review of TOMs: Regular review and updating of the technical and organizational measures, at least annually.
  • ISO 27001: The platform was developed with the aim of meeting ISO 27001. Regular review of security configurations and access rights within the framework of the ISMS.
  • Security audits: Regular review of security configurations and access rights.
  • Penetration tests: Regular performance of penetration tests and security assessments of the platform.
  • Vulnerability management: Continuous monitoring and remediation of known vulnerabilities (vulnerability management). Regular updates and patch management.
  • Incident response plan: Documented process for responding to security incidents. Definition of responsibilities and escalation paths.
  • Employee awareness: Regular training and sensitization of employees regarding data protection and information security.
  • Monitoring: Continuous monitoring of systems and networks via OpenTelemetry/Loki/Tempo/Grafana to detect anomalies and potential security incidents.
  • Log analysis: Regular analysis of audit logs and access logs to detect misuse.

11. Sub-processors

The following sub-processors are engaged in the processing of personal data for DIRIGENT:

Sub-processorLocationPurposeThird-country referenceDPATOMs
Hetzner Online GmbHGermany (Falkenstein)Hosting, database (PostgreSQL 18), Redis, backup, observability (OpenTelemetry/Loki/Tempo/Grafana)No third countriesYes (Art. 28(4) GDPR)Yes

Hetzner Online GmbH: As a hosting provider, Hetzner Online GmbH processes personal data in Germany (Falkenstein). No transfer to third countries takes place. The internal observability stack (OpenTelemetry, Loki, Tempo, Grafana) runs on the same Hetzner server, so no third-country transfer occurs. A Data Processing Agreement in accordance with Art. 28(4) GDPR has been concluded with Hetzner. Hetzner has its own TOMs in accordance with Art. 32 GDPR, which ensure the level of protection for processing in Germany.

No further active external services: The DIRIGENT platform currently does not use active external AI services, web analytics, payment services, or other external services. Adapters for external systems (Auth0/Keycloak, SuperOffice, Work4All, Jira, MS365/Graph, AGE, Confluence, FAUST, Handelsregister, MS Dynamics 365, SAP S/4HANA) exist; HTTP calls are disabled by default via *_USE_HTTP flags. Mock connectors for SharePoint and Leadinfo (backlog). Planned integrations: MS365 Booking and MS365 Graph email notifications. These will be carried out exclusively on the basis of separate Data Processing Agreements. The list of active sub-processors is complete.

12. Change History

VersionDateMaterial Changes
1.014.08.2026Initial version of the TOMs for DIRIGENT
1.129.08.2026Code alignment: bcrypt instead of Argon2id documented, PKCE session with HttpOnly cookies corrected, FORCE RLS limitation documented, TLS 1.2/1.3 instead of 1.3-only, DB/Redis TLS marked as planned, WAF marked as not implemented, WORM marked as conventional, backup automation marked as planned, external adapters and mock connectors documented
1.222.09.2026Code review (claims matrix): Argon2id verified as primary hash algorithm (legacy bcrypt migration on login); PostgreSQL 18 server-verified (pg18, 18.6); DB connections TLS-encrypted (sslmode=verify-full); audit retention corrected to 7 years
1.322.09.2026Code review (remaining items): FORCE RLS updated to migration 68; WORM/hash chain raised to implemented (partitioned audit table, SHA-256 sequence/prevHash/hash); MFA requirement clarified (available + enforced once enabled, role-based requirement planned); lockout claim replaced by ThrottlerGuard rate limiting; IP pseudonymization replaced by deletion via partition detach; backup section raised to encrypted offsite reality (systemd timer, retention 7d/4w/6m); DB TLS in §8 made consistent with §3
1.422.09.2026Server verification: PostgreSQL 18 confirmed on production server (pg18, 18.6); canonical domain corrected to dirigent.flowgeist.de (digitallydriven.flowgeist.de retired); WAF raised to implemented (ModSecurity v3 + OWASP CRS v4); TLS 1.3-only enforced server-side

© 2026 flowgeist – Ralf Carsjens · All rights reserved