Technical and Organizational Measures (TOMs) – flowgeist KITA
Status: 08.08.2026
Version: 1.0
Scope: Art. 32 GDPR, Art. 28 (3) lit. c GDPR
1. Access Control
Physical access control to the servers and IT systems on which personal data is processed is ensured by the hosting provider Hetzner Online GmbH.
Measures:
- Falkenstein data center: The servers are operated in the Falkenstein data center (Germany) by Hetzner Online GmbH.
- 24/7 security personnel: The data center is staffed with security personnel around the clock.
- Access control: Access to the data center is secured by multi-stage access controls (chip card, PIN, biometric methods).
- Visitor logging: All accesses and visits are logged and traceable.
- Video surveillance: The exterior and interior areas of the data center are under video surveillance.
- Access logging: All accesses to sensitive areas are fully logged and archived.
2. Access Control
Access control ensures that only authorized persons gain access to personal data and that permissions are granted according to the principle of least privilege.
Measures:
- MFA/TOTP: Multi-factor authentication using Time-based One-Time Password (TOTP) is mandatory for all user accounts.
- RBAC (Role-Based Access Control): Access control is role-based. Each user role is assigned defined rights that include only the permissions necessary for the fulfillment of tasks.
- Least Privilege: Permissions are granted according to the principle of least privilege. Users receive only the access rights that are strictly necessary for the performance of their activities.
- JWT (JSON Web Token): Access tokens have a validity of 15 minutes. Upon expiry, a new token is issued through refresh token rotation.
- Refresh token rotation: With each token renewal, a new refresh token is issued and the previous one is invalidated. This minimizes the risk of token misuse.
- Argon2id: Passwords are hashed using the Argon2id algorithm. The parameters are: m=64MiB (memory), t=3 (iterations), p=4 (parallelism). This provides a high level of protection against brute-force and rainbow table attacks.
- Lockout after failed attempts: After a defined number of failed login attempts, the account is temporarily locked.
3. Transmission Control
Transmission control ensures that personal data is protected against unauthorized access, manipulation, and loss during transmission.
Measures:
- TLS 1.3: All data transmissions between client and server are encrypted via TLS 1.3 (Transport Layer Security). Older protocol versions (TLS 1.1 and below) are not supported.
- HSTS (HTTP Strict Transport Security): The server sends HSTS headers to ensure that browsers communicate exclusively via HTTPS connections.
- Let’s Encrypt with auto-rotation: SSL/TLS certificates are issued by Let’s Encrypt and automatically rotated to ensure continuous encryption.
- Certificate pinning: Where applicable, certificate pinning is used to prevent man-in-the-middle attacks.
Input control ensures that all entries and changes to personal data are logged in a traceable manner, so that in the event of a data protection breach, the cause can be investigated.
Measures:
- Audit trail (ISO 27001 A.12.4): All security-relevant accesses and changes are fully logged in accordance with the ISO 27001 standard, control measure A.12.4 (event logging).
- WORM logs (Write Once, Read Many): The audit logs are stored as WORM logs, meaning they cannot be modified or deleted after writing. This ensures the integrity and immutability of the log data.
- Log content: Each log entry contains at least the following information:
- Timestamp (time of the action)
- User ID (identification of the user)
- Tenant ID (identification of the tenant/daycare provider)
- Action (performed operation, e.g., CREATE, READ, UPDATE, DELETE)
- Resource (affected data object)
- IP address (of the requesting client)
- User-Agent (browser/client identification)
- Log retention: Audit logs are retained for 3 years and then deleted.
5. Order Control
Order control ensures that personal data is processed only within the framework of the issued instructions and this Data Processing Agreement.
Measures:
- Processing only within the framework of the DPA: The processing of personal data is carried out exclusively on the instructions of the Controller and within the framework of the concluded Data Processing Agreement.
- No disclosure without authorization: Data is not disclosed to third parties without prior authorization from the Controller.
- Instruction documentation: All instructions from the Controller are documented and archived in a traceable manner.
- Contractual confidentiality of personnel: All persons involved in the processing are contractually bound to confidentiality.
6. Availability Control
Availability control ensures that personal data is protected against accidental destruction or loss and that the platform is available at all times.
Measures:
- Daily backups: Full backups are created daily at 03:00 UTC (Hetzner Cloud Backup).
- AES-256 at rest: Backups are stored encrypted with AES-256 (Advanced Encryption Standard).
- 7-day rolling: Backups are retained on a 7-day rolling basis, meaning the backups of the last 7 days are always available for restoration.
- RTO 8h (Recovery Time Objective): The recovery time after a failure is a maximum of 8 hours.
- RPO 24h (Recovery Point Objective): The maximum data loss in the event of a failure is a maximum of 24 hours (corresponding to the last successful backup).
- Redis as in-memory cache: Redis is used as an in-memory cache and is non-persistent. No personal data is permanently stored in Redis. In the event of a Redis failure, only cache data is lost, which can be rebuilt from the PostgreSQL database.
7. Separation Control
Separation control ensures that personal data of different tenants (daycare providers) is strictly separated during processing.
Measures:
- Multi-tenant with tenant isolation at database level: The data of different tenants (daycare providers) is strictly separated at the database level. Each tenant has an isolated data area to which other tenants have no access.
- JWT-claims tenant-scoped: The JWT access tokens contain tenant-specific claims that ensure a user can only access the data of their own tenant.
- Redis namespace isolation per tenant: In the Redis cache, the data of different tenants is separated by namespace isolation. Each tenant has its own namespace, which is protected from access by other tenants.
- Tenant verification on every query: Every database query and every cache access is checked for tenant membership.
8. Encryption
Encryption ensures that personal data is protected both during transmission and at rest.
Measures:
- AES-256 at rest: All stored data, including backups, is encrypted with AES-256 (Advanced Encryption Standard, 256-bit key length).
- TLS 1.3 in transit: All data transmissions are encrypted via TLS 1.3 (Transport Layer Security).
- Application-level encryption for health data: Health data (Art. 9 GDPR) is encrypted at the application level in addition to database encryption (see also section 12).
9. Pseudonymization
Pseudonymization ensures that personal data in audit logs and during long-term storage is processed in such a way that it can no longer be attributed to a specific data subject without the use of additional information.
Measures:
- Email SHA-256 hash with salt in audit logs: In audit logs, email addresses are not stored in plain text but as a SHA-256 hash with salt. This enables the traceability of actions without storing the plain-text email address.
- Names removed/hashed after retention period: After expiry of the statutory retention periods, names and other identifying characteristics are removed or replaced by hash values, provided further storage is necessary for statistical or evidentiary purposes.
10. Regular Review
Regular review ensures that the technical and organizational measures are continuously adapted to the current state of the art and to new threat scenarios.
Measures:
- Annual TOM review: The technical and organizational measures are reviewed annually and adapted as needed.
- Penetration tests every 24 months: Penetration tests are conducted regularly to identify and remediate vulnerabilities in the platform. The tests take place every 24 months.
- Vulnerability scans quarterly: Automated vulnerability scans are conducted quarterly to identify known vulnerabilities in dependencies and system components.
- ISO 27001 aspired: Certification according to ISO 27001 is being pursued. The measures are already aligned with the requirements of ISO 27001.
11. Sub-processors
The following is exclusively engaged as a sub-processor within the meaning of Art. 28 (2) GDPR:
- Hetzner Online GmbH, Industriestr. 12-14, 09224 Chemnitz, Germany (Falkenstein data center)
No other sub-processors are engaged. A transfer of data to third countries within the meaning of Art. 44 et seq. GDPR does not take place. All processing operations are carried out exclusively in Germany.
Redis is operated as an in-memory cache locally on the server and does not constitute a sub-processor, as no personal data is permanently transferred to Redis and Redis is an integral part of the server infrastructure.
12. Specifics for Children’s and Health Data
Due to the processing of special categories of personal data pursuant to Art. 9 GDPR (health data) and the processing of data of minors (children), additional measures are taken that go beyond the standard TOMs.
Measures:
- Enhanced access control for health data: Access to health data is controlled via a separate RBAC module (Role-Based Access Control). Only users with the specific “health data access” permission can access this data. The standard permissions for daycare management are not sufficient.
- Additional audit log level for access to Art. 9 data: Every access to health data is logged at an additional audit log level. In addition to the standard log information, this logging includes:
- Purpose of access (treatment, emergency, documentation)
- Type of action (read access, modification, export)
- Justification (consent given, emergency situation)
- Encryption of health data fields at application level: Health data is encrypted at the application level in addition to database encryption (AES-256 at rest). This means that the fields containing health data are encrypted with a separate key before being written to the database. In the event of unauthorized direct access to the database, the health data would not be readable even with knowledge of the database encryption key.
13. Change History
| Version | Date | Material Changes |
|---|
| 1.0 | 08.08.2026 | Initial version |