Anlage 1 zum AVV: Technische und Organisatorische Maßnahmen (TOMs)
gemäß Art. 32 DSGVO
Auftragnehmer: fmhconsulting · Qognio — Finn Malte Hinrichsen Stand: April 2026
1. Vertraulichkeit (Art. 32 Abs. 1 lit. b DSGVO)
1.1 Zutrittskontrolle
Maßnahmen, die Unbefugten den physischen Zutritt zu Datenverarbeitungsanlagen verwehren.
- Serverinfrastruktur wird in einem dedizierten, physisch gesicherten Rechenzentrum in Schleswig-Holstein betrieben
- Zutritt zum Rechenzentrum nur für autorisiertes Personal mit elektronischer Zugangskontrolle
- Videoüberwachung des Rechenzentrums (24/7)
- Protokollierung aller Zutrittsversuche
- Separate Sicherheitszone für Serverracks (Cage/Cabinet)
- Keine Publikumsverkehr im Rechenzentrumsbereich
1.2 Zugangskontrolle
Maßnahmen, die die Nutzung von Datenverarbeitungssystemen durch Unbefugte verhindern.
- Authentifizierung über individuelle Benutzerkonten mit starken Passwörtern (mind. 16 Zeichen, Komplexitätsanforderungen)
- SSH-Zugang ausschließlich über Ed25519/RSA-Schlüsselpaare (keine Passwort-Authentifizierung)
- Multi-Faktor-Authentifizierung (MFA) für alle administrativen Zugänge
- Automatische Sperrung nach fehlgeschlagenen Anmeldeversuchen (fail2ban)
- Verschlüsselter Zugang zu allen Management-Interfaces (TLS 1.3)
- VPN-Tunnel (WireGuard) für interne Kommunikation zwischen Systemkomponenten
- Regelmäßige Überprüfung und Rotation von Zugangsdaten
- Deaktivierung ungenutzter Benutzerkonten
1.3 Zugriffskontrolle
Maßnahmen, die gewährleisten, dass Berechtigte nur auf die ihrer Zugriffsberechtigung unterliegenden Daten zugreifen können.
- Rollenbasiertes Berechtigungskonzept (Principle of Least Privilege)
- Mandantentrennung: Jeder Auftraggeber erhält eine logisch getrennte Bot-Instanz
- Getrennte Datenhaltung pro Mandant (separate Datenbanken/Container)
- Keine mandantenübergreifende Dateneinsicht möglich
- Administrativer Zugriff auf Kundendaten nur im Rahmen dokumentierter Weisungen oder zur technischen Fehlerbehebung
- Protokollierung aller administrativen Zugriffe auf Kundendaten
1.4 Trennungskontrolle
Maßnahmen, die gewährleisten, dass zu unterschiedlichen Zwecken erhobene Daten getrennt verarbeitet werden.
- Logische Mandantentrennung durch containerisierte Instanzen (Docker)
- Separate Datenbanken pro Mandant
- Getrennte Konfigurationsräume und Dateisysteme
- Keine gemeinsame Nutzung von LLM-Konversationskontexten zwischen Mandanten
- Netzwerksegmentierung zwischen Mandanten-Containern
2. Integrität (Art. 32 Abs. 1 lit. b DSGVO)
2.1 Weitergabekontrolle
Maßnahmen, die gewährleisten, dass personenbezogene Daten bei der Übertragung, dem Transport oder der Speicherung nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können.
- Verschlüsselung aller Daten bei der Übertragung (TLS 1.3, HTTPS)
- Verschlüsselung der internen Kommunikation zwischen Systemkomponenten (WireGuard VPN)
- Verschlüsselung der Daten im Ruhezustand (LUKS Full-Disk Encryption auf allen Servern)
- Sichere Löschung von Datenträgern bei Außerbetriebnahme (NIST SP 800-88)
- Kein unverschlüsselter Datentransfer über öffentliche Netze
2.2 Eingabekontrolle
Maßnahmen, die gewährleisten, dass nachträglich geprüft und festgestellt werden kann, ob und von wem personenbezogene Daten eingegeben, verändert oder entfernt worden sind.
- Vollständiges Audit-Logging aller Datenveränderungen
- Unveränderliche Logdateien (append-only)
- Zeitstempel und Benutzerkennung bei jeder Aktion
- Aufbewahrung der Logs gemäß Löschkonzept (Anlage 3)
- Regelmäßige Überprüfung der Logs auf Anomalien
3. Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b, c DSGVO)
3.1 Verfügbarkeitskontrolle
Maßnahmen, die gewährleisten, dass personenbezogene Daten gegen zufällige Zerstörung oder Verlust geschützt sind.
- Tägliche automatisierte Backups aller Mandantendaten
- Backup-Speicherung an einem geographisch getrennten Standort (ebenfalls innerhalb der EU)
- Regelmäßige Backup-Restore-Tests (mindestens quartalsweise)
- Redundante Stromversorgung (USV) im Rechenzentrum
- Monitoring aller Systeme (24/7) mit automatischer Alarmierung
- Notfallpläne und dokumentierte Wiederherstellungsverfahren
- Recovery Time Objective (RTO): 4 Stunden
- Recovery Point Objective (RPO): 24 Stunden
3.2 Belastbarkeitskontrolle
Maßnahmen zur Sicherstellung der Widerstandsfähigkeit der Systeme.
- Containerisierte Architektur ermöglicht schnelles Failover
- Ressourcenlimitierung pro Mandant (CPU, RAM, Storage)
- DDoS-Schutz durch vorgelagerte Reverse-Proxy-Infrastruktur
- Regelmäßige Lasttests und Kapazitätsplanung
4. Verfahren zur regelmäßigen Überprüfung (Art. 32 Abs. 1 lit. d DSGVO)
4.1 Datenschutz-Management
- Dokumentiertes Datenschutzkonzept
- Regelmäßige interne Datenschutz-Audits (mindestens jährlich)
- Datenschutz-Folgenabschätzung bei wesentlichen Änderungen der Verarbeitung
- Dokumentiertes Verfahren zur Meldung von Datenschutzvorfällen (Incident Response)
- Schulung aller Mitarbeiter zum Datenschutz (mindestens jährlich)
4.2 Incident-Response-Verfahren
- Dokumentierter Incident-Response-Plan (siehe Anlage 5)
- Klassifizierung von Vorfällen nach Schweregrad
- Eskalationspfade und Verantwortlichkeiten definiert
- Benachrichtigung des Auftraggebers innerhalb von 24 Stunden
- Post-Incident-Analyse und Lessons Learned
4.3 Auftragsverarbeitungskontrolle
- Sorgfältige Auswahl von Unterauftragsverarbeitern
- Vertragliche Verpflichtung aller Unterauftragsverarbeiter auf gleichwertige TOMs
- Regelmäßige Überprüfung der Unterauftragsverarbeiter
5. KI-/LLM-spezifische Maßnahmen
5.1 Modellsicherheit
- Das eingesetzte Sprachmodell (aktuell: Qwen 3.5, 122B Parameter) wird auf eigener Infrastruktur betrieben (Self-Hosted)
- Kein Training oder Fine-Tuning mit Kundendaten — das Modell verarbeitet Daten ausschließlich zur Inferenz (Beantwortung von Anfragen)
- Modellgewichte sind statisch und werden nicht durch Nutzereingaben verändert
- Keine Übermittlung von Eingabedaten an Dritte (kein Cloud-API-Aufruf)
5.2 Prompt- und Konversationssicherheit
- Konversationsverläufe werden mandantengetrennt gespeichert
- Kontextfenster des Modells wird nach jeder Session geleert
- Keine Persistenz von Konversationsinhalten im Modell selbst
- Systemkonfigurationen (System Prompts) sind für Endnutzer nicht einsehbar
- Input-/Output-Filterung zur Verhinderung von Prompt Injection und Datenexfiltration
5.3 Transparenz und Nachvollziehbarkeit
- Vollständiges Logging aller Konversationen (Eingaben und Ausgaben)
- Logs sind dem jeweiligen Mandanten zugeordnet und auf Anfrage einsehbar
- Dokumentation des eingesetzten Modells, der Version und der Konfiguration
- Kennzeichnung KI-generierter Inhalte als solche
5a. Content-Connectoren zu Drittdiensten (optional)
Maßnahmen, die bei der Anbindung externer Datenquellen (Cloud-Speicher, E-Mail, Web) durch den Auftraggeber greifen.
5a.1 Schutz der Zugangsdaten
- Access- und Refresh-Token (OAuth2) sowie IMAP-Zugangsdaten werden ausschließlich verschlüsselt in der internen Datenbank gespeichert
- Verschlüsselung: AES-256-GCM mit serverseitigem Master-Key (32 Byte), Implementierung
connector-crypto.ts - Master-Key liegt nicht in der Datenbank und wird nur aus dem Server-Environment gelesen
- Klartext-Credentials existieren nur für die Dauer eines einzelnen Sync-Laufs im Arbeitsspeicher des Prozesses
5a.2 Prinzip der Minimal-Scopes
- OAuth-Scopes werden so eng wie möglich gewählt (Default: Read-Only)
- Für Dropbox wird der App-Folder-Scope als Default verwendet; der Full-Dropbox-Scope ist nicht Default und wird — sofern nötig — nur mit ausdrücklicher Zustimmung des Auftraggebers angefordert
- Für Microsoft Graph (SharePoint) werden ausschließlich Lese-Scopes für die vom Auftraggeber ausgewählten Sites/Drives angefordert; keine Mail-, Kontakt- oder Kalenderscopes
- Für IMAP wird der Zugriff auf vom Auftraggeber benannte Ordner/Labels eingeschränkt
5a.3 Token-Lifecycle
- Access-Tokens werden automatisch über den Refresh-Flow erneuert
- Bei Widerruf der Einwilligung durch den Auftraggeber (Disconnect im Portal) werden sowohl Tokens als auch indexierte Dokumente aus der Bot-Wissensbasis entfernt
- Tokens werden nicht an andere Mandanten, nicht an Dritte und nicht an die LLM-Inferenz weitergereicht
5a.4 Datenfluss-Beschränkung
- Der Crawler-/Sync-Prozess läuft innerhalb des Bot-Manager-Containers im RZ Schleswig-Holstein
- Abrufergebnisse werden ausschließlich in die Bot-spezifische Wissensbasis geschrieben; keine mandantenübergreifende Verwertung
- Text-Extraktion (PDF via
unpdf, DOCX viamammoth, Plain-Text/HTML nativ) erfolgt lokal auf Qognio-Servern ohne Cloud-Konvertierungsdienste
5a.5 Opt-In und Audit
- Jeder Connector wird pro Bot aktiv durch den Auftraggeber eingerichtet (OAuth-Consent-Flow bzw. Eingabe von IMAP-Zugangsdaten)
- Verbindungsaufbau, -trennung, Sync-Läufe und Fehlerfälle werden im Audit-Log erfasst
- Der Auftraggeber kann jederzeit im Portal einsehen, welche Connectoren aktiv sind und welche Dokumente zuletzt synchronisiert wurden
6. Infrastruktur-Übersicht
| Komponente | Beschreibung | Standort |
|---|---|---|
| LLM-Inferenz (Qwen 3.5) | Self-Hosted, 8× GPU, 128K Kontextfenster | DE (Schleswig-Holstein) |
| Bot-Runtime (OpenClaw) | Containerisiert, mandantengetrennt | DE (Schleswig-Holstein) |
| Datenbank | PostgreSQL, verschlüsselt, mandantengetrennt | DE (Schleswig-Holstein) |
| Reverse Proxy | Traefik v3 mit TLS 1.3 | DE (Schleswig-Holstein) |
| Backup-Speicher | Verschlüsselt, geographisch getrennt | DE |
| VPN-Backbone | WireGuard | DE |
| Monitoring | 24/7 Systemüberwachung | DE |
Letzte Überprüfung: April 2026 Nächste planmäßige Überprüfung: Oktober 2026
Diese Anlage ist Bestandteil des Auftragsverarbeitungsvertrages (AVV) zwischen den Parteien.