TOMs – flowgeist KITA

Version 1.2 · Stand: 08.08.2026

flowgeist ZERO flowgeist KITA flowgeist TOOL flowgeist FOOD CombiJornada

Technische und organisatorische Maßnahmen (TOMs) – flowgeist KITA

Stand: 08.08.2026 Version: 1.0 Geltungsbereich: Art. 32 DSGVO, Art. 28 Abs. 3 lit. c DSGVO

1. Zutrittskontrolle

Die physische Zugangskontrolle zu den Servern und IT-Systemen, auf denen personenbezogene Daten verarbeitet werden, wird durch den Hosting-Anbieter Hetzner Online GmbH sichergestellt.

Maßnahmen:

Rechenzentrum Falkenstein: Die Server werden im Rechenzentrum Falkenstein (Deutschland) von Hetzner Online GmbH betrieben.
24/7 Sicherheitspersonal: Das Rechenzentrum ist rund um die Uhr mit Sicherheitspersonal besetzt.
Zugangskontrolle: Der Zugang zum Rechenzentrum ist durch mehrstufige Zugangskontrollen (Chipkarte, PIN, biometrische Verfahren) gesichert.
Besucher-Protokollierung: Alle Zugänge und Besuche werden protokolliert und sind nachvollziehbar.
Videoüberwachung: Die Außen- und Innenbereiche des Rechenzentrums sind videoüberwacht.
Zutrittsprotokollierung: Sämtliche Zutritte zu sensiblen Bereichen werden lückenlos protokolliert und archiviert.

2. Zugriffskontrolle

Die Zugriffskontrolle stellt sicher, dass nur autorisierte Personen Zugang zu personenbezogenen Daten erhalten und dass Berechtigungen nach dem Prinzip der minimalen Rechtevergabe (Least Privilege) erteilt werden.

Maßnahmen:

MFA/TOTP: Die mehrstufige Authentifizierung (Multi-Factor Authentication) mittels Time-based One-Time Password (TOTP) ist für alle Nutzerkonten verpflichtend.
RBAC (Role-Based Access Control): Die Zugriffskontrolle erfolgt rollenbasiert. Jeder Nutzerrolle werden definierte Rechte zugeordnet, die nur die für die Aufgabenerfüllung notwendigen Berechtigungen umfassen.
Least Privilege: Berechtigungen werden nach dem Prinzip der minimalen Rechtevergabe erteilt. Nutzer erhalten nur die Zugriffsrechte, die für die Ausübung ihrer Tätigkeit zwingend erforderlich sind.
JWT (JSON Web Token): Zugriffstokens haben eine Gültigkeit von 15 Minuten. Nach Ablauf wird ein neues Token durch Refresh-Token-Rotation ausgestellt.
Refresh-Token-Rotation: Bei jeder Token-Erneuerung wird ein neuer Refresh-Token ausgestellt, der vorherige wird ungültig. Dies minimiert das Risiko eines Token-Missbrauchs.
Argon2id: Passwörter werden mit dem Argon2id-Algorithmus gehasht. Die Parameter sind: m=64MiB (Speicher), t=3 (Iterationen), p=4 (Parallelität). Dies bietet einen hohen Schutz gegen Brute-Force- und Rainbow-Table-Angriffe.
Sperrung nach Fehlversuchen: Nach einer definierten Anzahl fehlgeschlagener Anmeldeversuche wird das Konto temporär gesperrt.

3. Übertragungskontrolle

Die Übertragungskontrolle stellt sicher, dass personenbezogene Daten bei der Übertragung vor unbefugtem Zugriff, Manipulation und Verlust geschützt sind.

Maßnahmen:

TLS 1.3: Sämtliche Datenübertragungen zwischen Client und Server erfolgen verschlüsselt über TLS 1.3 (Transport Layer Security). Ältere Protokollversionen (TLS 1.1 und niedriger) werden nicht unterstützt.
HSTS (HTTP Strict Transport Security): Der Server sendet HSTS-Header, um sicherzustellen, dass Browser ausschließlich über HTTPS-Verbindungen kommunizieren.
Let’s Encrypt mit Auto-Rotation: SSL/TLS-Zertifikate werden durch Let’s Encrypt ausgestellt und automatisch rotiert, um eine durchgehende Verschlüsselung sicherzustellen.
Zertifikats-Pinning: Wo anwendbar, wird Certificate Pinning eingesetzt, um Man-in-the-Middle-Angriffe zu verhindern.

4. Eingabekontrolle

Die Eingabekontrolle stellt sicher, dass alle Eingaben und Änderungen an personenbezogenen Daten nachvollziehbar protokolliert werden, um im Falle einer Datenschutzverletzung die Ursache aufklären zu können.

Maßnahmen:

Audit-Trail (ISO 27001 A.12.4): Sämtliche sicherheitsrelevanten Zugriffe und Änderungen werden lückenlos protokolliert gemäß der Norm ISO 27001, Kontrollmaßnahme A.12.4 (Ereignisprotokollierung).
WORM-Logs (Write Once, Read Many): Die Audit-Logs werden als WORM-Logs gespeichert, das heißt, sie können nach dem Schreiben nicht mehr verändert oder gelöscht werden. Dies stellt die Integrität und Unveränderbarkeit der Protokolldaten sicher.
Log-Inhalt: Jeder Log-Eintrag enthält mindestens folgende Informationen:
- Timestamp (Zeitstempel der Aktion)
- User-ID (Identifikation des Nutzers)
- Tenant-ID (Identifikation des Mandanten/Kita-Trägers)
- Aktion (durchgeführte Operation, z.B. CREATE, READ, UPDATE, DELETE)
- Ressource (betroffenes Datenobjekt)
- IP-Adresse (des anfragenden Clients)
- User-Agent (Browser-/Client-Identifikation)
Log-Aufbewahrung: Audit-Logs werden für 3 Jahre aufbewahrt und anschließend gelöscht.

5. Auftragskontrolle

Die Auftragskontrolle stellt sicher, dass personenbezogene Daten nur im Rahmen der erteilten Weisungen und dieses Auftragsverarbeitungsvertrages verarbeitet werden.

Maßnahmen:

Verarbeitung nur im Rahmen des AVV: Die Verarbeitung personenbezogener Daten erfolgt ausschließlich auf Weisung des Verantwortlichen und im Rahmen des abgeschlossenen Auftragsverarbeitungsvertrages.
Keine Weitergabe ohne Genehmigung: Eine Weitergabe von Daten an Dritte erfolgt nicht ohne vorherige Genehmigung des Verantwortlichen.
Weisungsdokumentation: Alle Weisungen des Verantwortlichen werden dokumentiert und nachvollziehbar archiviert.
Vertragsbindung des Personals: Alle mit der Verarbeitung betrauten Personen sind vertraglich zur Vertraulichkeit verpflichtet.

6. Verfügbarkeitskontrolle

Die Verfügbarkeitskontrolle stellt sicher, dass personenbezogene Daten vor versehentlicher Zerstörung oder Verlust geschützt sind und die Plattform jederzeit verfügbar ist.

Maßnahmen:

Tägliche Backups: Vollständige Backups werden täglich um 03:00 UTC erstellt (Hetzner Cloud Backup).
AES-256 at rest: Backups werden mit AES-256 (Advanced Encryption Standard) verschlüsselt gespeichert.
7 Tage rollierend: Backups werden für 7 Tage rollierend aufbewahrt, das heißt, es stehen stets die Backups der letzten 7 Tage zur Wiederherstellung zur Verfügung.
RTO 8h (Recovery Time Objective): Die Wiederherstellungszeit nach einem Ausfall beträgt maximal 8 Stunden.
RPO 24h (Recovery Point Objective): Der maximale Datenverlust im Falle eines Ausfalls beträgt maximal 24 Stunden (entspricht dem letzten erfolgreichen Backup).
Redis als In-Memory-Cache: Redis wird als In-Memory-Cache eingesetzt und ist nicht-persistent. Es werden keine personenbezogenen Daten dauerhaft in Redis gespeichert. Bei einem Redis-Ausfall gehen lediglich Cache-Daten verloren, die aus der PostgreSQL-Datenbank neu aufgebaut werden können.

7. Trennungskontrolle

Die Trennungskontrolle stellt sicher, dass personenbezogene Daten unterschiedlicher Mandanten (Kita-Träger) strikt getrennt verarbeitet werden.

Maßnahmen:

Multi-Tenant mit Tenant-Isolation auf DB-Ebene: Die Daten verschiedener Mandanten (Kita-Träger) werden auf Datenbankebene strikt getrennt. Jeder Mandant hat einen isolierten Datenbereich, auf den andere Mandanten keinen Zugriff haben.
JWT-Claims tenant-scoped: Die JWT-Zugriffstokens enthalten tenant-spezifische Claims, die sicherstellen, dass ein Nutzer nur auf die Daten seines Mandanten zugreifen kann.
Redis-Namespace-Isolation pro Tenant: Im Redis-Cache werden die Daten verschiedener Mandanten durch Namespace-Isolation getrennt. Jeder Mandant hat einen eigenen Namespace, der vor dem Zugriff anderer Mandanten geschützt ist.
Mandantenprüfung bei jeder Abfrage: Jede Datenbankabfrage und jeder Cache-Zugriff wird auf Mandantenzugehörigkeit geprüft.

8. Verschlüsselung

Die Verschlüsselung stellt sicher, dass personenbezogene Daten sowohl bei der Übertragung als auch im Ruhezustand geschützt sind.

Maßnahmen:

AES-256 at rest: Alle gespeicherten Daten einschließlich Backups werden mit AES-256 (Advanced Encryption Standard, 256-Bit-Schlüssellänge) verschlüsselt.
TLS 1.3 in transit: Sämtliche Datenübertragungen erfolgen verschlüsselt über TLS 1.3 (Transport Layer Security).
Anwendungsverschlüsselung für Gesundheitsdaten: Gesundheitsdaten (Art. 9 DSGVO) werden zusätzlich zur Datenbankverschlüsselung auf Anwendungsebene verschlüsselt (siehe auch Abschnitt 12).

9. Pseudonymisierung

Die Pseudonymisierung stellt sicher, dass personenbezogene Daten in Audit-Logs und bei der langfristigen Speicherung so verarbeitet werden, dass sie ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet werden können.

Maßnahmen:

E-Mail SHA-256 Hash mit Salt in Audit-Logs: In Audit-Logs werden E-Mail-Adressen nicht im Klartext, sondern als SHA-256-Hash mit Salt gespeichert. Dies ermöglicht die Nachvollziehbarkeit von Aktionen ohne Speicherung der Klartext-E-Mail-Adresse.
Namen entfernt/gehasht nach Aufbewahrungsfrist: Nach Ablauf der gesetzlichen Aufbewahrungsfristen werden Namen und andere identifizierende Merkmale entfernt oder durch Hash-Werte ersetzt, sofern eine weitere Speicherung zu statistischen oder Nachweiszwecken erforderlich ist.

10. Regelmäßige Überprüfung

Die regelmäßige Überprüfung stellt sicher, dass die technischen und organisatorischen Maßnahmen kontinuierlich an den aktuellen Stand der Technik und an neue Bedrohungslagen angepasst werden.

Maßnahmen:

Jährlicher TOM-Review: Die technischen und organisatorischen Maßnahmen werden jährlich überprüft und bei Bedarf angepasst.
Penetrationstests alle 24 Monate: Es werden regelmäßig Penetrationstests durchgeführt, um Schwachstellen in der Plattform zu identifizieren und zu beheben. Die Tests finden alle 24 Monate statt.
Vulnerability-Scans quartalsweise: Vierteljährlich werden automatisierte Vulnerability-Scans durchgeführt, um bekannte Schwachstellen in Abhängigkeiten und Systemkomponenten zu erkennen.
ISO 27001 angestrebt: Die Zertifizierung nach ISO 27001 wird angestrebt. Die Maßnahmen sind bereits an den Anforderungen der ISO 27001 ausgerichtet.

11. Unter-Auftragsverarbeiter

Als Unter-Auftragsverarbeiter im Sinne des Art. 28 Abs. 2 DSGVO wird ausschließlich eingesetzt:

Hetzner Online GmbH, Industriestr. 12-14, 09224 Chemnitz, Deutschland (Rechenzentrum Falkenstein)

Es werden keine weiteren Unter-Auftragsverarbeiter eingesetzt. Eine Datenübermittlung in Drittstaaten im Sinne von Art. 44 ff. DSGVO findet nicht statt. Sämtliche Verarbeitungsvorgänge erfolgen ausschließlich in Deutschland.

Redis wird als In-Memory-Cache lokal auf dem Server betrieben und stellt keinen Unter-Auftragsverarbeiter dar, da keine personenbezogenen Daten dauerhaft an Redis übertragen werden und Redis integraler Bestandteil der Server-Infrastruktur ist.

12. Besonderheiten bei Kinder- und Gesundheitsdaten

Aufgrund der Verarbeitung besonderer Kategorien personenbezogener Daten gemäß Art. 9 DSGVO (Gesundheitsdaten) und der Verarbeitung von Daten minderjähriger Personen (Kinder) werden zusätzliche Maßnahmen ergriffen, die über die Standard-TOMs hinausgehen.

Maßnahmen:

Verschärfte Zugriffskontrolle für Gesundheitsdaten: Der Zugriff auf Gesundheitsdaten erfolgt über ein separates RBAC-Modul (Role-Based Access Control). Nur Nutzer mit der spezifischen Berechtigung „Gesundheitsdaten-Zugriff” können auf diese Daten zugreifen. Die Standard-Berechtigungen für Kita-Verwaltung reichen nicht aus.
Zusätzliche Audit-Log-Ebene für Zugriff auf Art. 9-Daten: Jeder Zugriff auf Gesundheitsdaten wird auf einer zusätzlichen Audit-Log-Ebene protokolliert. Diese Protokollierung umfasst zusätzlich zu den Standard-Log-Informationen:
- Zweck des Zugriffs (Behandlung, Notfall, Dokumentation)
- Art der Aktion (Lesezugriff, Änderung, Export)
- Rechtfertigung (Einwilligung liegt vor, Notfallsituation)
Verschlüsselung der Gesundheitsdaten-Felder auf Anwendungsebene: Gesundheitsdaten werden zusätzlich zur Datenbankverschlüsselung (AES-256 at rest) auf Anwendungsebene verschlüsselt. Dies bedeutet, dass die Felder, die Gesundheitsdaten enthalten, vor dem Schreiben in die Datenbank mit einem separaten Schlüssel verschlüsselt werden. Bei einem unbefugten direkten Zugriff auf die Datenbank wären die Gesundheitsdaten auch bei Kenntnis des Datenbank-Verschlüsselungsschlüssels nicht lesbar.

13. Änderungshistorie

Version	Datum	Wesentliche Änderungen
1.0	08.08.2026	Erstfassung