TOMs – flowgeist ZERO

Version 1.2 · Stand: 08.08.2026

flowgeist ZERO flowgeist KITA flowgeist TOOL flowgeist FOOD CombiJornada

Technical and Organizational Measures (TOMs) – flowgeist ZERO

As of: 08.08.2026 Version: 1.2 Scope: Art. 32 GDPR, Art. 28(3)(c) GDPR

1. Access Control

Measures to prevent unauthorized access to premises where data processing systems are operated:

Data center: Hosting with Hetzner Online GmbH, Falkenstein data center, Germany
Security personnel: 24/7 on-site security personnel for physical access control
Access control: Access to the data center exclusively for authorized personnel with multi-stage authentication (chip card + PIN/biometrics)
Visitor logging: Complete logging of all persons entering the data center, including date, time, duration, and escort
Video surveillance: CCTV monitoring of the exterior areas and entrances of the data center
Access logging: Electronic recording of all access events with timestamp and personal reference
Emergency power supply: Uninterruptible power supply (UPS) and diesel emergency generators for the entire data center operation
Climate control: Redundant climate control to ensure operating conditions
Fire protection: Early warning systems and automatic fire extinguishing systems

2. Access Control

Measures to prevent unauthorized use of data processing systems:

Multi-Factor Authentication (MFA/TOTP): All administrative and user-related access requires multi-factor authentication using Time-based One-Time Password (TOTP)
Role-Based Access Control (RBAC): Role-based access concept that regulates access to data and functions according to the assigned role
Least Privilege Principle: Each user and system receives only the minimum necessary access rights to fulfill their tasks
JWT (JSON Web Token): Access tokens with a validity of 15 minutes; upon expiry, re-authentication or token renewal is required
Refresh Token Rotation: Regular renewal of refresh tokens upon each use to minimize the risk of misuse; each refresh token can only be used once
Argon2id Password Hashing: Secure storage of passwords using Argon2id with the following parameters:
- Memory (m): 64 MiB
- Iterations (t): 3
- Parallelism (p): 4
Password Policies: Minimum length, complexity requirements, checking against known compromised passwords
Session Management: Secure management of user sessions with automatic timeout on inactivity
Access Logging: Logging of all login attempts (successful and failed) as well as all administrative accesses

3. Transfer Control

Measures to prevent unauthorized reading, copying, alteration, or erasure of personal data during transmission:

TLS 1.3: Encryption of all data transmission between client and server using Transport Layer Security (TLS) version 1.3; older TLS versions are not supported
HSTS (HTTP Strict Transport Security): Enforcement of encrypted transmission via HTTPS; HSTS header with preload directive
Let’s Encrypt TLS Certificates: Automatic issuance and renewal of TLS certificates through Let’s Encrypt
Auto-Rotation: Automatic rotation of TLS certificates before expiry to ensure uninterrupted operation
Perfect Forward Secrecy (PFS): Use of cipher suites with Perfect Forward Secrecy, so that compromise of the private key does not affect the confidentiality of past connections
Encryption of Internal Connections: Encryption of communication between internal services and databases
Secure API Communication: All API endpoints require authentication and encrypted transmission

4. Input Control

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

Audit Trail in accordance with ISO 27001 A.12.4: Complete logging of all security-relevant events and data changes
WORM Logs (Write Once, Read Many): Tamper-proof logging that prevents subsequent alteration or deletion of log entries
Log Content: Each audit log entry contains at least the following fields:
- Timestamp (UTC, ISO 8601 formatted)
- User-ID (identifies the acting user)
- Tenant-ID (identifies the tenant-related assignment)
- Action (type of operation performed, e.g., CREATE, READ, UPDATE, DELETE)
- Resource (affected data object or endpoint)
- IP address (source IP address of the request)
- User-Agent (client identification of the requesting system)
Immutability: Audit logs cannot be modified by users or administrators
Centralized Logging: Collection of all logs in a central, protected log system
Logging of Administrative Actions: Separately recorded logging of all administrative activities and system changes

5. Order Control

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

Processing only within the scope of the DPA: The processing of personal data takes place exclusively on the basis of the concluded Data Processing Agreement (Art. 28 GDPR)
Instruction Binding: All processing operations are carried out on documented instructions from the Controller
No Transfer Without Authorization: Transfer of data to third parties takes place exclusively with prior authorization from the Controller and on the basis of a Sub-processor agreement
Documentation of Instructions: All instructions from the Controller are documented and archived in a traceable manner
Separation of Orders: Data from different clients is processed strictly separately (see Separation Control)
Contractual Binding of Sub-processors: DPAs in accordance with Art. 28(2)–(4) GDPR are concluded with all Sub-processors

6. Availability Control

Measures to ensure the availability of data processing systems and services:

Daily Backups: Automatic daily backup of all databases and system data at 03:00 UTC
Hetzner Cloud Backup: Use of the Hetzner Cloud Backup service for automated, encrypted backups
AES-256 Encryption at Rest: All backups are stored encrypted with AES-256
7 Days Rolling: Backups are retained for a period of 7 days and overwritten on a rolling basis
RTO (Recovery Time Objective): 8 hours – target recovery time after a failure event
RPO (Recovery Point Objective): 24 hours – maximum data loss in the recovery case (corresponds to the daily backup interval)
Risk Notice: An RPO of 24 hours means that in the event of a total failure, data may be up to 24 hours old. For critical data sets, the Controller should consider additional backup measures.
Redundant System Components: Use of redundant server and network components to minimize single points of failure
Monitoring: Continuous monitoring of system availability and performance with automatic alerting in case of disruptions
Emergency Plans: Documented emergency and recovery plans for various failure scenarios

7. Separation Control

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

Multi-Tenant Architecture: The platform supports multiple tenants with strict separation of data sets
Tenant Isolation at DB Level: Data from different tenants is isolated at the database level; one tenant cannot access data from another tenant
JWT-Claims Tenant-Scoped: JSON Web Tokens contain tenant-related claims (tenant-scoped) that strictly restrict access to the data of the tenant’s own organization
Logical Separation: Data from different processing purposes is stored and managed with logical separation
Separation of Production and Test Environments: Strict separation between production and test/development environments; no real personal data is processed in test environments
Tenant-Related Access Control: RBAC roles and permissions are configured on a tenant-related basis; cross-tenant access is technically excluded

8. Encryption

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

AES-256 at Rest: Encryption of all stored data (databases, backups, file systems) with Advanced Encryption Standard (AES) using a key length of 256 bits
TLS 1.3 in Transit: Encryption of all data transmissions with Transport Layer Security (TLS) version 1.3
Key Management: Secure management and rotation of encryption keys; keys are stored separately from the encrypted data
IBAN Encryption: The IBAN is stored encrypted in the database; no storage of complete credit card data
Password Hashing: Passwords are stored hashed using Argon2id (m=64MiB, t=3, p=4); plaintext passwords are never stored
Backup Encryption: All backups are encrypted with AES-256, both at rest and during transfer

9. Pseudonymization

Measures for the pseudonymization of personal data:

Email SHA-256 Hash with Salt in Audit Logs: In audit logs, email addresses are not stored in plaintext but as SHA-256 hash with salt to reduce identifiability
Names Removed/Hashed After Retention Period: After expiry of the respective retention period, names and other identifying features are removed or replaced by hash values
Pseudonymization of Stripe Webhook Logs: Stripe webhook logs with PII (Personally Identifiable Information) are pseudonymized after 30 days; personally identifiable information is replaced by pseudonymous identifiers
Token-Based Referencing: Payment data is referenced via Stripe customer IDs; the actual payment data remains with Stripe and is not stored in plaintext at flowgeist
Tenant-ID as Pseudonym: In logs and records, the Tenant-ID is used to identify tenants, which does not allow direct inference about natural persons

10. Regular Review

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

Annual TOM Review: Annual comprehensive review and update of the technical and organizational measures by the responsible party
Penetration Tests Every 24 Months: Conducting penetration tests by internal or external auditors on a biennial basis to identify vulnerabilities
Vulnerability Scans Quarterly: Quarterly automated vulnerability scans of systems and applications for early detection of security gaps
ISO 27001 Aspired: The implementation of an Information Security Management System (ISMS) according to ISO/IEC 27001 is aspired; current measures are already oriented towards the requirements of ISO 27001
Security Patch Management: Regular and timely installation of security updates and patches for all system components
Incident Response Plan: Documented and regularly practiced emergency plan for security incidents
Employee Awareness: Regular training and sensitization of employees in the area of information security and data protection
Review of Sub-processors: Regular review of the measures taken by Sub-processors

11. Sub-processors

The following Sub-processors are engaged in the processing of personal data:

Sub-processor	Headquarters / Country	Service	Third country transfer	Guarantees
Hetzner Online GmbH	Falkenstein, Germany (DE)	Hosting, server infrastructure, backups	No third country transfer	DPA in accordance with Art. 28 GDPR
Stripe Payments Europe, Ltd.	Ireland (IE) / USA (US)	Payment processing	EU-US DPF + SCC	DPA in accordance with Art. 28 GDPR; DPF certification
Postmark / ActiveCampaign	USA (US)	Email delivery (transactional emails)	EU-US DPF + SCC	DPA in accordance with Art. 28 GDPR; DPF certification
Mistral AI	France (FR)	AI text generation for compliance fields	No third country transfer	DPA in accordance with Art. 28 GDPR
Lexware GmbH	Germany (DE)	Accounting, invoicing	No third country transfer	DPA in accordance with Art. 28 GDPR

Data Processing Agreements in accordance with Art. 28(2)–(4) GDPR have been concluded with all listed Sub-processors, ensuring compliance with the requirements of the GDPR.

12. Change History

Version	Date	Material changes
1.0	02.05.2026	Initial version
1.1	23.06.2026	Finalization; addition of Sub-processors
1.2	08.08.2026	Product-specific adaptation for flowgeist ZERO; expansion of pseudonymization and audit trail measures