Technische und Organisatorische Maßnahmen (TOMs) nach Art. 32 DSGVO: Anlage 2 zum AVV

Anlage 2 zum Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO

Stand: Juni 2026

Dieser Katalog beschreibt die Maßnahmen, die mailorga zum Schutz der im Rahmen des AVV verarbeiteten personenbezogenen Daten umsetzt (Art. 32 Abs. 1 DSGVO). Er ist Bestandteil des AVV und wird bei wesentlichen Änderungen aktualisiert; der Kunde wird vorab informiert (AVV § 6 Abs. 3).

1. Vertraulichkeit

1.1 Zugangskontrolle (Wer darf die Konsole öffnen?)

Der Zugang zur Betriebskonsole von mailorga ist ausschließlich über einen einmaligen Anmelde-Link möglich, den das System per E-Mail an die hinterlegte Adresse verschickt. Es gibt kein Passwort. Der Link ist zeitlich begrenzt; nach Aktivierung gilt eine Sitzung für maximal 30 Tage (mit automatischem Ablauf bei Inaktivität nach 4 Stunden). Jede Sitzung kann sofort widerrufen werden; der Widerruf wirkt bei jeder Anfrage in Echtzeit. Das Zugangstoken wird serverseitig nur als Prüfsumme gespeichert; ein Abfluss des gespeicherten Werts ergibt keinen nutzbaren Token.

1.2 Zugriffskontrolle (Wer sieht welche Daten?)

Die Konsole zeigt ausschließlich Daten des angemeldeten Kunden. Die Datenpfad-Auflösung erfolgt serverseitig anhand der verifizierten Sitzung, nicht anhand von Parametern in der Web-Adresse. Ist die Datenzuordnung eines Kunden nicht eindeutig auflösbar (etwa bei einem Konfigurationsfehler), verweigert das System den Zugriff vollständig, anstatt auf Fremddaten auszuweichen (Fail-Closed-Prinzip).

1.3 Trennung der Kundendaten

Jeder Kunde erhält einen eigenen, abgegrenzten Datenbereich auf dem Server. Die Zuordnung eingehender Mails zum richtigen Kunden erfolgt über fest konfigurierte Regeln im Code, nicht über die Absenderangaben in der Mail (die manipulierbar wären). Öffentlich geteilte E-Mail-Anbieter (zum Beispiel Gmail, GMX) können nicht als alleiniges Kundenmerkmal dienen, sodass keine unbeabsichtigte Zusammenführung von Daten verschiedener Nutzer derselben Domain möglich ist.

1.4 Systemhärtung

Alle Dienste von mailorga laufen in Containern ohne erhöhte Systemrechte. Linux-Systemberechtigungen sind vollständig entzogen; Prozesse laufen als eingeschränkte Systembenutzer. Arbeitsspeicher- und Prozesszahlgrenzen sind auf Container-Ebene gesetzt.

2. Integrität

2.1 Schutz vor E-Mail-Manipulation und Spoofing

Absender-Authentifizierung (SPF/DKIM/DMARC): Eingehende Mails werden auf Absender-Authentizität geprüft. Aktuell wird das Ergebnis protokolliert und bei Nichtbestehen als Warnsignal gewertet; die automatische Aussonderung nicht authentifizierter Mails (Durchsetzungsmodus) ist vorbereitet und wird nach interner Freigabe aktiviert.

Versand nur für eigene Domains: Das System versendet Antworten ausschließlich im Namen der für den jeweiligen Kunden vordefinierten Absenderdomains. Abweichungen werden vom Code abgewiesen, nicht von einer KI-Anweisung.

Schutz vor RFC-reservierten Testadressen: Ein Versand an reservierte Testadressen (etwa example.com) wird vom Code verhindert, um Reputationsschäden zu vermeiden.

2.2 Geld- und Verbindlichkeits-Schutz

Bevor eine Antwort automatisch versendet wird, prüft ein fest verdrahteter Code-Filter, ob die Mail Beträge, Bankverbindungen, Zahlungsziele oder Verbindlichkeiten enthält. Trifft der Filter zu, wird die Mail zur menschlichen Prüfung zurückgehalten und nicht automatisch beantwortet.

2.3 Sende-Richtlinie als Code-Schalter

Ob das System automatisch antwortet, einen Entwurf zur menschlichen Freigabe ablegt oder gar nicht sendet, ist je Postfach in einer versionierten Konfigurationsdatei festgelegt. Diese Entscheidung liegt nicht im KI-Prompt (der angreifbar wäre), sondern im Code. Die Voreinstellung für neue Postfächer ist Entwurfsmodus (kein automatischer Versand ohne menschliche Freigabe).

2.4 Idempotenz (jede Mail genau einmal)

Jede eingehende Mail erhält beim Eingang eine unveränderliche interne Kennung. Das System stellt durch einen zweistufigen Mechanismus sicher, dass dieselbe Mail auch nach einem Neustart oder Verbindungsabbruch nur einmal verarbeitet wird.

2.5 Eingabe- und Pfad-Validierung

Absenderdaten werden vor dem Speichern bereinigt. Pfad-Traversal-Versuche (Angriffe, die versuchen, aus dem Kundendatenbereich auszubrechen) werden durch Eingabe-Validierung im Code abgewiesen. Freigabe-Aufträge werden nur mit streng geprüften Vorgangskennungen angenommen.

2.6 Quarantäne für fehlerhafte Mails

Mails, die nach drei Verarbeitungsversuchen nicht verarbeitet werden können, werden in eine separate Warteschlange verschoben. Der laufende Betrieb wird dadurch nicht unterbrochen.

3. Verfügbarkeit und Belastbarkeit

3.1 Sicherung

Kundendaten (E-Mails, Notizen, Wissensbasis) werden täglich gesichert. Das Sicherungsziel ist ein privates Repository beim Unterauftragsverarbeiter GitHub Inc. / Microsoft (USA) unter dem EU-US Data Privacy Framework (Art. 45 DSGVO). Zugangsdaten und Sitzungstoken werden von der Sicherung ausgenommen. Schlägt die Sicherung fehl, löst das System automatisch einen Alarm aus. Vor jedem Sicherungsvorgang wird geprüft, ob der Vorgang versehentlich Kundendaten löschen würde; trifft das zu, bricht der Vorgang ab.

3.2 Rollback bei fehlerhaftem Update

Software-Updates werden erst eingespielt, wenn die automatisierten Tests grün sind. Nach einem Update prüft das System seine eigene Betriebsfähigkeit; schlägt die Prüfung fehl, wird automatisch auf die zuletzt funktionierende Version zurückgekehrt.

3.3 Liveness-Überwachung

Der Agent schreibt nach jeder Verarbeitungsrunde einen Liveness-Marker. Bei Konfiguration eines externen Wachdienstes wird dieser regelmäßig angepingt; bleibt der Ping aus, kann ein externer Alarm ausgelöst werden. Speicherplatzbelegung wird alle 15 Minuten geprüft; bei kritischer Füllung erfolgt ein Alarm vor einem möglichen Schreibausfall.

3.4 Belastungsgrenzen

Um unkontrollierte Kosten und Missbrauch zu begrenzen, sind folgende Grenzen fest im Code verankert:

• Pro Postfach können maximal 30 KI-Schritte pro Stunde ausgelöst werden.
• Pro Absenderadresse werden maximal 3 automatische Antworten pro Stunde versendet.
• Neu eingehende Erstkontakte sind auf 20 pro Stunde begrenzt (Schutz vor Massenanfragen).
• Der tägliche Ausgangs-Versand ist auf 200 Mails begrenzt; Überschreitungen werden sichtbar zurückgestellt und nicht still verworfen.

3.5 Bounce- und Beschwerde-Überwachung

Ausgehende Zustellfehler (Bounces) und Beschwerdeanzeigen von Empfängern werden zusammengefasst ausgewertet. Bei Überschreiten eines Schwellenwerts erfolgt ein Alarm.

3.6 Betriebsunterbrechungs-Schutz (Circuit-Breaker)

Bei mehreren aufeinanderfolgenden Infrastruktur-Fehlern in einem Verarbeitungsdurchgang wird der laufende Durchgang abgebrochen; Mails bleiben unbearbeitet in der Warteschlange und werden beim nächsten Lauf neu versucht. So wird verhindert, dass eine kurze Störung zu massenhaften Fehleinträgen führt.

4. Nachvollziehbarkeit

4.1 Betriebssicht ohne Mailinhalte

Die Betriebskonsole zeigt Betriebsstatus, Quellstatus je Postfach und Quarantäne-Zähler im Browser. Mailinhalte oder Klartextadressen sind in der Betriebssicht nicht zugänglich.

4.2 PII-Schutz im Betriebsprotokoll

E-Mail-Adressen und Absender werden in den Betriebsprotokollen ausschließlich als kurze Prüfsummen gespeichert; kein Klartext-Personenbezug ist im Protokoll enthalten.

4.3 Mail-Trace-Kennung (ohne Inhaltsbezug)

Jede eingehende Mail erhält beim Eingang eine 8-stellige interne Trace-Kennung. Diese verbindet alle Verarbeitungsschritte einer Mail im Protokoll, ohne Inhalt oder Adresse zu enthalten.

4.4 Quarantäne-Nachvollziehbarkeit

Abgewiesene Mails sind mit Grund und Zeitstempel in der Betriebskonsole einsehbar; Inhalte und Adressen werden dabei nicht angezeigt.

4.5 DMARC-Prüfprotokoll

Fehlschläge bei der Absender-Authentifizierung (DMARC) werden protokolliert (ohne Mailadresse). Dies dient der nachträglichen Nachvollziehbarkeit von Zustellversuchen nicht authentifizierter Absender.

4.6 Fehlerdigest (im Aufbau)

Eine automatische nächtliche Fehlerzusammenfassung ohne Inhalt oder Adresse ist technisch vorbereitet; die regelmäßige Einbindung in den Betrieb wird gerade abgeschlossen.

5. Verschlüsselung

5.1 Transportverschlüsselung

• Postfach-Empfang (IMAP): Der Abruf eingehender Mails vom Postfach-Server erfolgt ausschließlich über SSL (Port 993). Ein Rückfall auf unverschlüsselte Verbindungen ist technisch ausgeschlossen.
• Versand (SMTP): Ausgehende Mails werden ausschließlich über verschlüsselte Verbindungen (STARTTLS, Port 587) versendet.
• Webzugang: Die Betriebskonsole ist ausschließlich über HTTPS erreichbar. Das Verschlüsselungszertifikat wird automatisch durch Caddy / Let's Encrypt erneuert.

5.2 Zugangsdaten außerhalb der Sicherung

Live-Zugangsdaten (Postfach-Passwörter, API-Schlüssel, Sitzungstoken) sind von der täglichen Sicherung ausgenommen und liegen nicht im Backup-Repository.

5.3 Ruhende Daten (at rest)

Kunden-Postfachinhalte, Notizen und die Wissensbasis liegen im laufenden Betrieb auf einem Server der Hetzner Online GmbH in einem physisch gesicherten deutschen Rechenzentrum. Eine anwendungsseitige Verschlüsselung dieser ruhenden Postfachdaten ist derzeit nicht umgesetzt; der Schutz ruhender Daten beruht auf Zugriffskontrolle, den eingeschränkten Berechtigungen des Container-Betriebssystems (Nicht-Root-Ausführung) und der anwendungsseitigen Mandantentrennung (eigener, abgegrenzter Datenbereich je Kunde) sowie der physischen und betrieblichen Sicherheit des Rechenzentrums. (Die zusätzlich vom Betriebssystem erzwungene Mandantentrennung ist gesondert unter "Zum Go-Live vorbereitet" beschrieben.)

6. Datenort und Unterauftragsverarbeiter

Alle Stammdaten und Postfachinhalte werden auf einem Server der Hetzner Online GmbH in Deutschland gespeichert und dort verarbeitet. Für die KI-gestützte Erstellung von Antwort-Entwürfen werden Mailinhalte an Anthropic PBC (USA) übermittelt; Grundlage sind EU-Standardvertragsklauseln nach Art. 46 Abs. 2 lit. c DSGVO. Anthropic verwendet über die API übermittelte Daten nicht zum Training von Modellen. Tägliche Datensicherungen von Kundendaten erfolgen in ein privates Repository bei GitHub Inc. / Microsoft (USA) unter dem EU-US Data Privacy Framework (Art. 45 DSGVO). Der Empfang und Versand von Mails läuft über Zoho (zohomail.eu, smtp.zoho.eu) in EU-Rechenzentren; ergänzend gelten die Auftragsverarbeitungsbedingungen des Anbieters mit Standardvertragsklauseln für etwaige Zugriffe aus Drittländern.

Die vollständige Unterauftragsverarbeiter-Liste ist in Anlage 1 des AVV enthalten.

Zum Go-Live vorbereitet

Die folgenden Maßnahmen sind im Code vollständig umgesetzt, aber noch nicht im laufenden Standardbetrieb aktiv. Sie werden mit der nächsten Infrastruktur-Stufe (Mehrkunden-Betrieb) scharf geschaltet. Bis dahin ist das Onboarding neuer Fremdkunden technisch gesperrt.

Betriebssystem-erzwungene Mandantentrennung (OS-uid-Isolation): Jede Postfach-Verarbeitung wird in einem eigenen Systemprozess mit separater Benutzer-ID ausgeführt. Der Zugriff auf fremde Kundendaten ist damit auf Betriebssystem-Ebene strukturell ausgeschlossen, unabhängig von Anwendungscode oder KI-Verhalten. Die Aktivierung erfolgt durch Setzen eines Betriebs-Parameters beim Start des Dienstes.

Speicherplatz-Begrenzung je Kunde (Disk-Cap): Im Mehrkunden-Betrieb erhält jeder Kunde eine konfigurierbare Speicherplatzobergrenze; Überschreitungen werden abgewiesen.

Arbeitsspeicher- und CPU-Grenzen je Verarbeitungsauftrag (RLIMITs): Für jeden Verarbeitungsprozess sind Arbeitsspeicher- und CPU-Limits auf Betriebssystem-Ebene gesetzt.

Zeitliche Begrenzung je Verarbeitungsauftrag (Timeout + Prozess-Abbruch): Jeder Verarbeitungsauftrag läuft maximal 300 Sekunden. Bei Überschreitung wird der Prozess und seine Untergruppe vom Betriebssystem zwangsweise beendet.

Verschlüsselte Speicherung von Direktanbindungs-Zugangsdaten (AES-256-GCM): Für Kunden mit direkter Kalender- oder Systemanbindung (OAuth) ist die verschlüsselte Speicherung des Zugangs-Tokens mit AES-256-GCM und kundenseitigem Trennschlüssel umgesetzt. Diese Funktion wird aktiviert, sobald die Direktanbindung in Betrieb geht.

Dieses Dokument ist Anlage 2 zum Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO. Es ersetzt oder ändert keine Bestimmungen des AVV.