⚖ TOMs – flowgeist FOOD

TOMs – flowgeist FOOD

v1.2 · 08.08.2026

TOMs – flowgeist FOOD

Version 1.2 · Stand: 08.08.2026
flowgeist ZERO flowgeist KITA flowgeist TOOL flowgeist FOOD CombiJornada

Technical and Organizational Measures (TOMs) – flowgeist FOOD

Status: 08.08.2026 Version: 1.0 Scope: Art. 32 GDPR, Art. 28(3)(c) GDPR

1. Access Control to Premises

Physical access control to the server infrastructure and the business premises of flowgeist is ensured by the following measures:

(1) Data Center (Hetzner Online GmbH, Falkenstein)

  • Access control by the data center in accordance with Hetzner’s ISO 27001 certification
  • Multi-tier access control (badge, biometrics, personnel airlock)
  • Video surveillance of access routes and server rooms
  • 24/7 security personnel on site
  • Logging of all accesses

(2) Business Premises flowgeist

  • Access to business premises only for authorized persons
  • Locking system with logging
  • No physical server infrastructure in the business premises (cloud-only)

(3) Devices

  • Access to work devices (laptops, mobile phones) protected by password/biometrics
  • Disk encryption (BitLocker / FileVault) on all work devices
  • Automatic screen lock after inactivity (5 minutes)

2. Access Control to Systems

Access control ensures that only authorized persons gain access to personal data and that access rights are granted according to the need-to-know principle.

(1) Authentication

  • Authentication via JWT (JSON Web Tokens) with refresh token rotation
  • Apple Sign-In and Google Sign-In as authentication methods
  • No password-based authentication (avoidance of password risks)
  • MFA (Multi-Factor Authentication) optional for administrative accesses

(2) Role-Based Access Control (RBAC)

  • Granting of access rights according to the Role-Based Access Control (RBAC) model
  • Differentiation between user role and administrator role
  • Least-privilege principle: Each role is assigned only the minimum required rights
  • Regular review of access rights (at least annually)

(3) Administrative Access

  • Access to production environment only via encrypted connections (SSH with key-based authentication)
  • MFA for all administrative accesses
  • Logging of all administrative accesses (audit trail)
  • Separation of development, staging, and production environments

(4) User Isolation

  • Each user has access only to their own data
  • Database queries are isolated on a per-user basis (multi-tenant with Row-Level Security in PostgreSQL)
  • No cross-user access possible

3. Transmission Control

Transmission control ensures that personal data is protected against unauthorized access, alteration, and disclosure during transmission.

(1) Transport Encryption

  • TLS 1.3 for all data transmissions (client-server, server-server)
  • Disablement of older TLS versions (TLS 1.0, 1.1, 1.2 disabled)
  • Perfect Forward Secrecy (PFS) through ECDHE key exchange

(2) HSTS (HTTP Strict Transport Security)

  • HSTS enabled for all connections to the flowgeist FOOD App
  • Include-Subdomains and Preload list enabled
  • Minimum TLS version 1.3

(3) Certificates

  • TLS certificates through Let’s Encrypt
  • Automatic certificate renewal (90-day cycle)
  • Certificate pinning in the Native App (iOS/Android)

(4) API Security

  • All API endpoints via TLS 1.3
  • Authentication required for all API calls (JWT)
  • Rate limiting to protect against brute-force attacks
  • CORS restrictions (Cross-Origin Resource Sharing)

4. Input Control

Input control ensures that all inputs and changes to personal data are logged in a traceable manner.

(1) Audit Trail

  • Complete logging of all accesses to and changes to personal data
  • Logging of: user ID, timestamp, action (Create, Read, Update, Delete), affected data category, IP address
  • Audit logs are stored in a separate, read-only database

(2) WORM Logs (Write Once, Read Many)

  • Audit logs are stored as WORM logs (writable once, thereafter read-only)
  • Tamper protection through cryptographic methods (hash chain)
  • Logs cannot be subsequently altered or deleted

(3) Enhanced Logging for Health Data

  • Additional logging for all accesses to Health data (Art. 9 GDPR)
  • Separate audit logs for Art. 9 data with extended level of detail
  • Alerting on unusual access patterns to Health data

(4) Retention

  • Audit logs are retained for 3 years
  • WORM logs are automatically deleted after the retention period expires

5. Order Control

Order control ensures that data processed on behalf of the Controller is processed only in accordance with the Controller’s instructions.

(1) Instruction Binding

  • All processing operations are carried out exclusively in accordance with documented instructions
  • Instructions are documented and archived in text form
  • No processing outside the issued instructions

(2) Sub-processors

  • Engagement of sub-processors only with prior consent
  • DPA with all sub-processors in accordance with Art. 28(4) GDPR
  • Regular review of sub-processors for compliance with the TOMs

(3) Separation of Environments

  • Strict separation of development, staging, and production environments
  • No production data in development or test environments
  • Anonymized or synthetic test data for development

(4) Documentation

  • Complete documentation of all processing operations
  • Record of processing activities in accordance with Art. 30 GDPR is maintained and kept up to date

6. Availability Control

Availability control ensures that personal data is protected against accidental destruction or loss and that the availability of the App is guaranteed.

(1) Backups

  • Daily full backups of the PostgreSQL 16 database
  • Incremental backups hourly
  • Backup retention: 30 days (daily backups), 12 weeks (weekly backups)
  • Backup verification through regular restore tests (monthly)

(2) Encrypted Backups

  • All backups are encrypted with AES-256
  • Backup keys are stored separately from the backup data (Key Management)
  • Backups are stored in a separate data center / separate storage

(3) MinIO Object Storage

  • Photo data is stored in MinIO Object Storage
  • MinIO with Server-Side Encryption (SSE-S3 compatible, AES-256)
  • Bucket versioning enabled (protection against accidental deletion)
  • Lifecycle policies for automatic cleanup

(4) Redis Cache

  • Redis as in-memory cache for session management and performance
  • Redis persistence enabled (AOF - Append Only File)
  • Redis data does not contain Health data (only session/caching data)
  • Automatic failover in case of Redis failure

(5) High Availability

  • Redundant server infrastructure at Hetzner
  • Load balancing for app servers
  • Automatic failover in case of server failure
  • Monitoring and alerting 24/7

(6) Disaster Recovery

  • Disaster recovery plan documented
  • Recovery Time Objective (RTO): 4 hours
  • Recovery Point Objective (RPO): 1 hour
  • Regular disaster recovery tests (semi-annually)

7. Separation Control

Separation control ensures that data processed for different purposes can be processed separately.

(1) Multi-Tenant (User Isolation)

  • Strict isolation of individual users’ data (multi-tenant architecture)
  • Row-Level Security (RLS) in PostgreSQL 16 at table level
  • Each database query is restricted on a per-user basis
  • No cross-user access possible

(2) MinIO Bucket Isolation

  • Photo data is stored in separate MinIO buckets per user
  • Bucket policies prevent access to other users’ buckets
  • Access only via authenticated and authorized API calls

(3) Separation by Data Categories

  • Health data (Art. 9 GDPR) is stored in separate database schemas
  • Additional application-layer encryption for Health data fields
  • Separation of audit logs and production data (separate database)
  • Separation of development, staging, and production data

(4) Log Separation

  • Audit logs are stored separately from application logs
  • Sentry error tracking does not receive Health data (PII minimization)
  • System logs do not contain personal master data

8. Encryption

Encryption ensures that personal data is protected both during transmission and at rest.

(1) Transport Encryption

  • TLS 1.3 for all data transmissions
  • Perfect Forward Secrecy (PFS)
  • HSTS enabled
  • Certificates through Let’s Encrypt with automatic renewal

(2) Encryption at Rest – Database

  • PostgreSQL 16 with Transparent Data Encryption (TDE) or Volume-Level Encryption
  • AES-256 encryption for database volumes
  • Database backups AES-256 encrypted

(3) Encryption at Rest – MinIO Object Storage

  • MinIO Server-Side Encryption (SSE) with AES-256
  • Photo data is stored encrypted
  • Bucket versioning and lifecycle policies

(4) Encryption at Rest – Redis

  • Redis data stored on encrypted volume
  • Redis does not contain Health data (only session/caching data)

(5) Key Management

  • Central key management (Key Management System)
  • Regular key rotation (at least annually)
  • Separation of keys and encrypted data
  • Access to keys only by authorized administrators (MFA)

(6) Password Hashing

  • Argon2id as hashing method for passwords (where password-based methods are used)
  • Parameters: memory cost, time cost, and parallelism in accordance with current OWASP recommendations

9. Pseudonymization

Pseudonymization ensures that personal data can no longer be attributed to a specific data subject without the use of additional information.

(1) Token-based Authentication

  • JWT-based authentication without storage of plaintext passwords
  • Apple/Google Sign-In token as pseudonym
  • No direct linking of authentication tokens and master data

(2) Sentry Error Tracking

  • PII minimization: Sentry does not receive personal master data or Health data
  • Error reports contain only minimized, pseudonymized data
  • IP addresses are masked or removed before transmission to Sentry

(3) Audit Logs

  • Audit logs use user IDs (pseudonyms) instead of plaintext names
  • Attribution of user ID to master data only possible by authorized administrators

(4) Data Separation

  • Health data is stored separately from master data
  • Linking only via pseudonymized IDs
  • Additional application-layer encryption for Health data

10. Regular Review

Regular review ensures that the effectiveness of the technical and organizational measures is continuously evaluated and improved.

(1) Review Cycle

  • Annual review of the TOMs for currency and effectiveness
  • Review after material changes to the system architecture
  • Review after security incidents

(2) Security Audits

  • Regular security audits (at least annually)
  • Penetration testing by external service providers (annually)
  • Vulnerability scanning (automated, weekly)

(3) Patch Management

  • Regular updates and patches for all system components
  • Security patches are prioritized and applied without delay
  • Monitoring of security advisories (CVE databases)

(4) Incident Response

  • Documented incident response plan
  • Security incidents are classified and handled according to severity
  • Post-incident review after every security incident
  • Documentation and reporting in accordance with Art. 33 GDPR

(5) Employee Training

  • Regular data protection and security training for all employees
  • Awareness training for social engineering and phishing
  • Training upon material changes to the system architecture

(6) ISO 27001 Alignment

  • The TOMs are aligned with the requirements of ISO 27001
  • Continuous improvement in the sense of the PDCA cycle (Plan-Do-Check-Act)

11. Sub-processors

The following sub-processors are engaged in the context of the flowgeist FOOD App:

Sub-processorLocationPurposeThird-country transferProtection mechanism
Hetzner Online GmbHFalkenstein, Germany (DE)Hosting, PostgreSQL 16, MinIO Object Storage, Redis CacheNone (EU)ISO 27001 certification, DPA
Mistral AI SASFrance (FR)Mistral Vision API for photo-based food analysisNone (EU-only)EU Member State, GDPR directly applicable, DPA
Sentry (Functional Software, Inc.)USA (US)Error tracking, fault diagnosisEU-US DPF + SCCEU-US Data Privacy Framework + Standard Contractual Clauses, PII minimization

(1) Hetzner Online GmbH

  • ISO 27001 certified data center in Falkenstein, Germany
  • All databases, Object Storage, and Cache are operated here
  • No third-country transfer
  • DPA concluded in accordance with Art. 28(4) GDPR

(2) Mistral AI SAS

  • Mistral Vision API for photo-based food analysis
  • Headquartered in France (EU Member State), no third-country transfer
  • GDPR is directly applicable
  • DPA concluded in accordance with Art. 28(4) GDPR
  • Photo data is deleted after analysis (no permanent storage at Mistral)

(3) Sentry (Functional Software, Inc.)

  • Error tracking for fault diagnosis and resolution
  • Headquartered in the USA (third country)
  • Protection mechanisms: EU-US Data Privacy Framework (DPF) + Standard Contractual Clauses (SCC)
  • PII minimization: No Health data (Art. 9 GDPR) or personal master data is transmitted to Sentry
  • DPA concluded in accordance with Art. 28(4) GDPR

12. Special Features for Health Data (Art. 9 GDPR)

Due to the processing of Health data within the meaning of Art. 9(1) GDPR (allergies, intolerances, dietary goals, health-related nutrition data), heightened protective measures apply:

(1) Additional Application-Layer Encryption for Health Data Fields

  • Health data is encrypted at the application layer in addition to database encryption (Field-Level Encryption)
  • Method used: AES-256-GCM
  • Keys are stored separately from the encrypted data (Envelope Encryption)
  • Decryption only in the application process with authorized context

(2) Enhanced Audit Logs for Access to Art. 9 Data

  • Separate audit log system for all accesses to Health data
  • Logging of: user ID, timestamp (millisecond precision), action, field, IP address, session ID
  • Real-time alerting on unusual access patterns (e.g., mass export, access outside usage hours)
  • Audit logs as WORM logs (tamper-proof)
  • Retention: 3 years

(3) Consent Logging with Timestamp and Withdrawal Option

  • Every consent to the processing of Health data is fully logged:
    • Timestamp of consent
    • Version of the consent declaration
    • IP address at the time of consent
    • User ID
    • Scope of consent (which data categories)
  • Withdrawal of consent is possible at any time (in-app and via email)
  • Withdrawal is also logged (timestamp, IP address)
  • Upon withdrawal, immediate deletion of the affected Health data takes place

(4) Data Separation

  • Health data is stored in separate database schemas
  • Strict separation of master data and Health data
  • Linking only via pseudonymized IDs

(5) No Transfer to Third Countries

  • Health data is processed exclusively in Germany (Hetzner) and France (Mistral AI, EU)
  • No transfer of Health data to Sentry (USA) or other third countries
  • Sentry error tracking is configured to filter out Health data (Data Scrubbing)

(6) Access Restriction

  • Access to Health data only by authorized roles (least-privilege principle)
  • No administrative access to decrypted Health data without explicit authorization
  • Emergency accesses are separately logged and require justification

13. Change History

VersionDateMaterial Changes
1.008.08.2026Initial version of the TOMs for flowgeist FOOD

© 2026 flowgeist – Ralf Carsjens · All rights reserved