Technische und organisatorische Maßnahmen (TOMs)

gemäß Art. 32 DSGVO · Stand: 11. Mai 2026 · Version 1.1

Dieses Dokument beschreibt die technischen und organisatorischen Maßnahmen, die der Verantwortliche gemäß Art. 32 DSGVO umgesetzt hat, um ein dem Risiko angemessenes Schutzniveau für die Verarbeitung personenbezogener Daten zu gewährleisten. Es ist Bestandteil jedes Auftragsverarbeitungsvertrages (AVV).

1. Vertraulichkeit (Art. 32 Abs. 1 lit. b DSGVO)

1.1 Zutrittskontrolle (physische Sicherheit)

Der Produktivserver wird ausschließlich im Rechenzentrum der IONOS SE in Deutschland betrieben.

• ISO-27001-zertifiziertes Rechenzentrum in der Bundesrepublik Deutschland
• Zutritt nur für autorisiertes Personal mit Mehr-Faktor-Authentifizierung (Chipkarte + biometrisch)
• 24/7-Bewachung, Videoüberwachung, Alarmanlage
• Brandfrüherkennung, Inertgas-Löschanlage
• Redundante Stromversorgung (USV + Notstromaggregat)
• Klimatisierte Server-Räume mit Zutrittsprotokollierung

Der Anbieter selbst hat keinen physischen Zugang. Administration erfolgt ausschließlich remote über SSH-Schlüssel. Auftragsverarbeitungsvertrag mit IONOS: vorhanden und unterzeichnet.

1.2 Zugangskontrolle (logische Authentifizierung)

Endbenutzer (Kunden des Dienstes):

• Kein Passwort-Login. Authentifizierung ausschließlich über Magic-Link (per E-Mail, signierter Token, einmalig verwendbar) oder OAuth 2.0 mit RFC-9728-konformer Token-Mint (sha256-gehashter Authorization Code, single-use, TTL 10 Minuten, atomare Einlösung per UPDATE … RETURNING)
• Rate-Limiting auf Auth-Endpunkten: 3 Magic-Links pro Stunde pro E-Mail; 10 Token-Mints pro Stunde pro Account; 120 Requests pro 60 Sekunden pro IP (nginx limit_req)
• Token-Speicherung: Auth-Tokens werden ausschließlich als HMAC-SHA-256-Hash in der Datenbank abgelegt; das Klartext-Token verlässt nach Ausstellung niemals den Server-Speicher

Administrativer Zugang (Anbieter):

• SSH-Zugriff ausschließlich per Public-Key-Authentifizierung (Ed25519), Passwort-Login deaktiviert
• SSH-Port abweichend vom Standard (Port 2222) — reduziert Bot-Traffic
• fail2ban aktiv: automatische IP-Sperre nach fehlgeschlagenen SSH-Versuchen
• 2FA für externe Anbieter-Konten (Git-Repository mit Push-Schutz und Branch-Protection auf main, IONOS, Mollie, Domain-Registrar)

Lexoffice-API-Keys (Kundendaten):

• Speicherung AES-256-GCM-verschlüsselt in PostgreSQL
• Master-Key liegt außerhalb der Datenbank in .env mit Dateirechten chmod 600 (nur durch Service-User lesbar)
• Bei Datenbank-Leak ohne Server-Filesystem-Zugriff sind die Keys nicht entschlüsselbar

Gleiches Verschlüsselungsregime gilt für USt-IdNr. und Steuernummer der Geschäftskunden.

1.3 Zugriffskontrolle (Rollen und Berechtigungen)

Tenant-Isolation:

• Strikte Mandantentrennung über AsyncLocalStorage: jeder Request läuft in einem isolierten Kontext mit fest verknüpfter Tenant-ID
• Sämtliche Datenbank-Queries führen die Tenant-ID als Pflicht-Filter (WHERE tenant_id = $1)
• Cross-Tenant-Zugriffe sind durch das Datenmodell ausgeschlossen — kein Code-Pfad existiert, der ohne Tenant-Kontext Daten lesen kann

Datenbank-Berechtigungen:

• PostgreSQL bindet ausschließlich an 127.0.0.1 (loopback) — von außen nicht erreichbar
• Anwendungs-User besitzt nur die für den Betrieb notwendigen Rechte (kein SUPERUSER, kein CREATEDB)

Redis: Bindung an 127.0.0.1 mit Passwort-Auth, ausschließlich für Rate-Limiting-Counter und Session-State (keine personenbezogenen Daten persistent).

1.4 Trennungskontrolle

• Mandanten-Trennung in der DB: jede Tabelle mit Personenbezug enthält tenant_id mit referentieller Integrität (Foreign Key) und Index
• Im Business- und Kanzlei-Tarif zusätzlich getrennte Lexoffice-Mandanten-Tokens pro Sub-Mandant des Kunden — kein gemeinsamer Token-Pool
• Trennung Dev / Test / Prod: Produktionssystem auf dedizierter Domain (api.lexmcp.365tec.de); eigene .env-Dateien je Umgebung; Mollie: separate Live- und Test-API-Keys

1.5 Pseudonymisierung

• Audit-Log: Request-ID, IP, User-Agent geloggt; PII (E-Mail, Namen) im Log gemaskt (z. B. licence2t@***)
• IP-Anonymisierung: Klartext-IPs werden nach 7 Tagen automatisch durch eine HMAC-pseudonymisierte Form ersetzt (HMAC-SHA256 mit Server-seitigem Schlüssel; Klartext-IP wird gelöscht)
• Audit-Log-Retention: Tool-Call-Events (Noise) 30 Tage, sicherheits- und zahlungsrelevante Events 12 Monate, danach vollständige Löschung — siehe Datenschutzerklärung §6 für Details
• Verschlüsselte Felder (Lex-API-Keys, Steuer-IDs) erscheinen auch im Audit-Log nie im Klartext

2. Integrität (Art. 32 Abs. 1 lit. b DSGVO)

2.1 Weitergabekontrolle

Transportverschlüsselung:

• TLS 1.2 / 1.3 für alle externen Verbindungen, kein HTTP-Fallback (automatischer 301-Redirect von Port 80)
• Zertifikate von Let's Encrypt, automatische Erneuerung via certbot-renew.timer (systemd)
• HSTS-Preload: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload (2 Jahre)
• TLS-Konfiguration nach Mozilla "Intermediate"-Profil; veraltete Cipher-Suites (RC4, 3DES) deaktiviert

HTTP-Sicherheits-Header (Helmet):

• Content-Security-Policy: default-src 'self' (restriktiv)
• X-Frame-Options: DENY (Clickjacking-Schutz)
• X-Content-Type-Options: nosniff
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy minimiert (Kamera, Mikrofon, Geolokation deaktiviert)

Backups: PostgreSQL-Dumps werden vor Übertragung clientseitig verschlüsselt (GPG, AES-256). Off-Site-Speicherung; Schlüssel verbleibt nicht zusammen mit den Backups.

2.2 Eingabekontrolle

• Serverseitige Validierung: sämtliche eingehende Requests mit Zod-Schemata validiert (Typ, Länge, Format, erlaubte Zeichen). Keine Verlassen auf Client-Validierung. Bei Validierungsfehlern: Abbruch 400, kein partielles Persistieren
• Audit-Log: jeder schreibende Request erzeugt einen Log-Eintrag (Request-ID UUID v4, Tenant-ID, User-ID, Endpunkt, Methode, Statuscode, IP, User-Agent, Timestamp UTC). Append-only auf Anwendungsebene
• Code-Integrität: privates Git-Repository, 2FA-Pflicht für Push, Branch-Protection auf main (keine Force-Pushes, keine direkten Commits ohne Pull-Request). Deployment ausschließlich vom geschützten Branch

3. Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b DSGVO)

3.1 Verfügbarkeitskontrolle

Service-Level-Objectives:

• Pro-Tarif: 99,0 % monatliche Verfügbarkeit (max. ca. 7,3 h Downtime/Monat)
• Business-Tarif: 99,5 % monatliche Verfügbarkeit (max. ca. 3,6 h Downtime/Monat)
• Kanzlei-Tarif: 99,5 % monatliche Verfügbarkeit + Telefon-Support werktags Mo–Fr 09:00–17:00 Uhr

Backups:

• Tägliche automatisierte PostgreSQL-Dumps (pg_dump)
• 7 Tage rollierende lokale Backups
• 30 Tage verschlüsselte Off-Site-Backups

Monitoring & Selbstheilung:

• PM2 überwacht Node.js-Prozess: automatischer Restart bei Crash, Memory-Leak-Schutz
• fail2ban sperrt IPs mit verdächtigem Verhalten (Brute-Force, Scanner)
• pm2-logrotate rotiert Logs automatisch (Größenbegrenzung, Komprimierung) — verhindert Disk-Full
• certbot-renew.timer erneuert TLS-Zertifikate automatisch

DDoS-Schutz auf nginx-Ebene:

• limit_req zone=... mit 120 Requests/60 s pro IP
• limit_conn zur Begrenzung gleichzeitiger Verbindungen pro IP
• Vorgelagerte IONOS-Netzwerk-Infrastruktur mit Volumetrik-Schutz

Datenbankebene: PostgreSQL-WAL-Archivierung (Point-in-Time-Recovery), automatische Vakuum- und Reindex-Jobs.

3.2 Wiederherstellbarkeit

• RTO (Recovery Time Objective): ≤ 4 Stunden für vollständige Wiederherstellung nach Totalausfall
• RPO (Recovery Point Objective): ≤ 24 Stunden Datenverlust im Worst-Case (Tages-Backup-Intervall)
• Restore-Tests: stichprobenartig (z. B. vor Major-Releases oder bei Schema-Migrationen) auf einem isolierten System; auf konkrete Anforderung einer Kanzlei führen wir einen dokumentierten Restore durch und stellen den Bericht bereit

Master-Key (AES-256-GCM für Lexoffice-Tokens) ist sicher außerhalb des Produktivsystems hinterlegt — eine Wiederherstellung ohne diesen Schlüssel würde die verschlüsselten Lexoffice-Keys unbrauchbar machen, was als bewusster Sicherheitsmechanismus gewollt ist (Kunden müssten ihren Lexoffice-Key neu eintragen).

4. Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung (Art. 32 Abs. 1 lit. d DSGVO)

4.1 Datenschutz-Management

• Datenschutz-Folgenabschätzung (Art. 35 DSGVO) vor jedem neuen Feature, das eine neue Kategorie personenbezogener Daten verarbeitet
• Verzeichnis von Verarbeitungstätigkeiten (Art. 30 DSGVO) wird gepflegt
• DSGVO-Self-Service-Endpoints für Betroffenenrechte (Art. 15–17, 21 DSGVO):
  • GET /me/export.json — Auskunfts- und Datenübertragbarkeitsrecht (Art. 15, 20)
  • GET /me/delete + POST /me/delete — Recht auf Löschung (Art. 17): vollständige Anonymisierung
  • POST /me/marketing-consent/revoke — Widerruf der Einwilligung (Art. 7 Abs. 3 DSGVO, § 7 UWG)

Self-Service ist sofort wirksam — keine manuelle Bestätigung durch den Anbieter erforderlich.

4.2 Incident-Response-Plan

Eskalationsstufen:

Aufsichtsbehörde: Landesbeauftragter für den Datenschutz und die Informationsfreiheit Baden-Württemberg (LfDI BW), Lautenschlagerstraße 20, 70173 Stuttgart.

Eingangskanal: info@365tec.de (24/7 Eingang — Bearbeitung werktags innerhalb 4 h)

4.3 Auftragskontrolle (Subprozessoren)

Lexware Office GmbH und Anthropic PBC sind keine Subprozessoren des Anbieters, sondern Vertragspartner des Endkunden. Der Dienst leitet API-Anfragen im Auftrag des Kunden weiter bzw. empfängt MCP-Anfragen vom Kunden-eigenen KI-Client.

Aktualisierung der Subprozessoren-Liste: mindestens 30 Tage Vorlauf gegenüber Kunden mit gültigem AVV.

4.4 Mitarbeiter-Sensibilisierung / Eigenverpflichtung

Der Dienst wird als Einzelunternehmen betrieben; keine weiteren Mitarbeiter mit Datenzugriff.

• Schriftliche Verpflichtung auf das Datengeheimnis nach Art. 5 Abs. 1 lit. f und Art. 32 Abs. 4 DSGVO (in Personalakte hinterlegt)
• Jährliche Selbst-Schulung zu DSGVO-Grundlagen, Incident-Response und aktuellen Bedrohungslagen (BSI-Lagebericht)
• Bei künftigen Mitarbeitern: Aufnahmegespräch mit Verpflichtung auf Datengeheimnis und Schulungsnachweis vor erstem Datenzugriff verpflichtend

5. Stand und Aktualisierung

Stand: 11.05.2026 · Version: 1.1 · Nächste reguläre Überprüfung: 04.05.2027 (jährlicher Turnus)

Außerordentliche Aktualisierung erfolgt bei:

• Wesentlichen Änderungen der Verarbeitungstätigkeit (neue Datenkategorien, Zwecke)
• Aufnahme neuer Subprozessoren
• Wesentlichen Änderungen der technischen Infrastruktur (Hosting-Wechsel etc.)
• Erkenntnissen aus Datenschutzvorfällen
• Aktualisierungen der Rechtsgrundlage (DSGVO-Anpassungen, EDSA-Leitlinien, Urteile)

Versionsverlauf:

Verantwortlich: Daniel Ovadia, 365tec, Eugen-Richter-Str. 159, 76187 Karlsruhe, info@365tec.de

Dieses TOM-Dokument ist verbindlicher Bestandteil jedes Auftragsverarbeitungsvertrages mit Kunden des Dienstes lexmcp.365tec.de. Die jeweils aktuelle Version unter https://lexmcp.365tec.de/toms.html ist maßgeblich.