# 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 via `mammoth`, 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._