Technisch-organisatorische Maßnahmen (TOMs) gemäß Art. 32 DSGVO

Stand: 26. September 2026  |  Version: 1.7  |  Verantwortlicher: KYTH. Systems UG (haftungsbeschränkt)

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

1.1 Zutrittskontrolle (physisch)

Maßnahmen, die geeignet sind, Unbefugten den Zutritt zu Datenverarbeitungsanlagen zu verwehren, mit denen personenbezogene Daten verarbeitet oder genutzt werden.

• Hosting in einem nach ISO 27001 zertifizierten Rechenzentrum der IONOS SE in Berlin (Deutschland) — kein eigener Server-Standort des Auftragsverarbeiters.
• Die physische Zutrittskontrolle zum Rechenzentrum liegt bei IONOS. Mit IONOS besteht ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO; IONOS ist nach ISO 27001 zertifiziert und weist die Einhaltung der Art.-28-Pflichten über diese Zertifizierung nach. Die technisch-organisatorischen Maßnahmen von IONOS werden von IONOS selbst dokumentiert und sind dort einsehbar.
• Es werden keine Datenträger an Mitarbeiter oder Dritte übergeben. Die Serververwaltung erfolgt remote: die Betriebssystem-Ebene über schlüsselbasiertes SSH, die Plattformverwaltung (Coolify) über eine passwortgeschützte Weboberfläche.

1.2 Zugangskontrolle (logisch)

Maßnahmen, die verhindern, dass Datenverarbeitungssysteme von Unbefugten genutzt werden können.

• Shopify-Händler-Zugang: OAuth 2.0 (Shopify-Standard) + Shopify Session Token (JWT HS256) — Multi-Tenant-Isolation pro Shop;
• Admin-Zugang: E-Mail/Passwort-Authentifizierung mit PBKDF2-SHA256 (310.000 Iterationen) für Passwort-Hashing; nach der Anmeldung ein HMAC-signiertes Sitzungsmerkmal (siehe 1.3);
• Anmeldung am Packplatz (optional): Versandmitarbeiter des Händlers melden sich mit ihrem Namen und einer selbst gewählten vierstelligen PIN an. Die PIN wird ausschließlich als PBKDF2-Hash gespeichert und gewährt keine Verwaltungsrechte (siehe 2.1);
• Intranet-/Verwaltungszugang: Benutzername und Passwort, Sitzungsverwaltung über HMAC-signierte Cookies (KARL_INTRANET_SECRET), Sperre nach zu vielen Fehlversuchen je IP-Adresse. Zusätzlich ist ein zweiter Faktor (zeitbasiertes Einmalpasswort mit Wiederherstellungscodes) eingerichtet; ist er aktiv, genügt für maschinelle Zugriffe das Passwort nicht mehr, sondern es wird ein eigenes Zugangstoken verlangt;
• Programmierschnittstelle: Zugriffe über die Programmierschnittstelle laufen über je Shop erzeugte Schlüssel, die ausschließlich als Hashwert gespeichert werden;
• Datenbank-Zugang: kein Direktzugang aus dem Internet — der Datenbank-Port ist nicht nach außen veröffentlicht, die Verbindung läuft ausschließlich innerhalb des Container-Netzwerks (Coolify); Zugang zum Host nur schlüsselbasiert per SSH;
• SSH-Zugang zum Server: ausschließlich Schlüssel-basiert (kein Passwort-Login), nur Geschäftsführung;
• HMAC-Verifizierung auf allen Shopify-OAuth-Callbacks und GDPR-Webhook-Endpoints (Schutz vor unauthorisierten Webhook-Calls).

1.3 Zugriffskontrolle (Daten)

Maßnahmen, die gewährleisten, dass die zur Benutzung eines Datenverarbeitungssystems Berechtigten ausschließlich auf die ihrer Zugriffsberechtigung unterliegenden Daten zugreifen können.

• Multi-Tenant-Isolation: Jede Tabelle mit personenbezogenen Daten führt eine shop_id-Spalte, und die zugehörigen Abfragen filtern darauf. Carrier-Stammdaten, Preistabellen, Zuschlagszonen und Tarifdefinitionen enthalten keine personenbezogenen Daten und werden zentral für alle Shops gepflegt; plattformweite Verwaltungs- und Protokollzeilen tragen bewusst keinen Shop-Bezug;
• Per-Request ContextVar: der aktuelle Shop-Kontext wird über Python contextvars.ContextVar isoliert pro Request gehalten — keine globalen Zustandsvariablen;
• Tabellen-Whitelist (_ALLOWED_TABLES): dynamische Tabellennamen sind ausschließlich gegen eine Whitelist zulässig (Schutz gegen SQL-Injection bei generischer GDPR-Löschung);
• Parametrisierte SQL-Queries: ausschließlich %s-Placeholder, niemals f-string-Interpolation für User-Input;
• Zugriffsbeschränkung der Händler-Mitarbeiter: Wer die App im Shopify-Adminbereich öffnen darf, bestimmt der Händler über die Mitarbeiter-Berechtigungen seines Shopify-Kontos; jede Anfrage an KARL wird gegen den von Shopify signierten Session-Token geprüft. Innerhalb dieses Rahmens führt KARL zusätzlich Admin-Konten (admin_users.role „admin"). Den Einstellungsbereich (Absender, Carrier-Zugangsdaten, Abrechnung, Drucker, Mitarbeiterliste) öffnet die Oberfläche nur nach der Anmeldung mit einem Admin-Konto, den Einrichtungsassistenten nach Abschluss der Ersteinrichtung ebenso. Nach der Anmeldung erhält der Browser ein HMAC-signiertes Sitzungsmerkmal, das weder Namen noch Rolle enthält und auf eine serverseitig geführte Sitzung verweist; Konto und Rolle liest der Server bei jeder Prüfung aus der Datenbank. Die Sitzung endet nach einer vom Händler wählbaren Zeit ohne Aktivität (Standard 60 Minuten; wählbar 15, 30, 60 oder 120 Minuten oder aus), spätestens nach 12 Stunden, mit der Abmeldung und bei einem Passwortwechsel. Sobald ein Shop ein Admin-Konto hat, lehnt der Server Verwaltungsanfragen (Einstellungen, Carrier-Zugangsdaten, Abrechnung, Admin-Konten, Mitarbeiter am Packplatz, Zurücksetzen des Shops) ohne gültige Sitzung ab; ausgenommen ist nur der Auto-Druck-Schalter am Packplatz. Das Versenden (Labels erstellen, scannen, drucken) setzt keine Admin-Anmeldung voraus; dafür gilt die Rechtevergabe in Shopify. Die Anbindung externer Carrier- und Marktplatzkonten (UPS, eBay) wird erst in der angemeldeten, eingebetteten App abgeschlossen und nur dem dortigen Shop zugeordnet. Daneben existiert genau eine mandantenübergreifende Betreiber-Rolle (superadmin) ohne Shop-Bindung. Sie wird ausschließlich beim Start der Anwendung aus Umgebungsvariablen angelegt und kann über die Oberfläche nicht vergeben werden. Zugriffe auf Shop-Detaildaten und Löschvorgänge im internen Verwaltungsportal werden in audit_log mit Aktion, Rolle, Zeitstempel und IP-Adresse protokolliert;
• Verschlüsselte Suchfelder: Admin-E-Mail-Adressen liegen verschlüsselt in der Datenbank; gesucht wird über einen deterministischen HMAC-SHA256-Hash (email_lookup_hash) — der Klartext wird dafür nicht zusätzlich gespeichert.

1.4 Trennungskontrolle (separate Verarbeitung)

Maßnahmen, die gewährleisten, dass zu unterschiedlichen Zwecken erhobene Daten getrennt verarbeitet werden können.

• Logische Trennung der Mandanten (Shopify-Händler) auf Datenbankebene über shop_id;
• Sandbox-Modus pro Shop (shop_settings.sandbox_mode): produktive und Sandbox-Aufträge werden auf Anwendungsebene strikt getrennt — Sandbox erzeugt weder echte Versandetiketten noch echte Carrier-API-Calls;

1.5 Pseudonymisierung (Art. 32 Abs. 1 lit. a DSGVO)

• Empfänger-Name, Firma, Straße, Adresszusatz, E-Mail und Telefon werden mit AES-256-GCM verschlüsselt gespeichert. Land, Postleitzahl, Ort und Region bleiben im Klartext, weil Routing, Zuschlagsprüfung und Carrier-Auswahl auf diesen Feldern filtern;
• Carrier-API-Request-/Response-Logs (api_request_json, api_response_json) werden ebenfalls verschlüsselt — Klartext-Adressen sind in diesen Logs nicht zugänglich;
• Lookups erfolgen für ausgewählte Felder über deterministischen HMAC-Hash (z. B. email_lookup_hash) — kein Reverse-Lookup von Pseudonym auf Klartext außerhalb des AES-Keys möglich;
• Anwendungs-Logs durchlaufen vor der Ausgabe einen Filter am Root-Logger, der E-Mail-Adressen, Telefonnummern, Zugangstoken und Portal-Links durch Platzhalter ersetzt. Derselbe Filter greift beim Fehler-Protokoll in der Datenbank und beim Fehler-Tracking. Ergänzend gilt die interne Regel, keine personenbezogenen Daten zu protokollieren.

1.6 Verschlüsselung (Art. 32 Abs. 1 lit. a DSGVO)

Schlüsselverwaltung: Der AES-Schlüssel wird ausschließlich als Umgebungsvariable der Deployment-Plattform gehalten und liegt weder im Quellcode noch in der Datenbank. Im Produktivbetrieb ist er zwingend: fehlt er, bricht der Anwendungsserver den Start mit einem Fehler ab (Fail-Closed). Die Schlüsselrotation erfolgt über ein dediziertes Skript mit Alt-/Neu-Schlüssel-Übergangsphase. Ein rotierter Altschlüssel bleibt mindestens so lange verfügbar wie die längste Backup-Aufbewahrung, damit ältere Sicherungen entschlüsselbar bleiben.

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

2.1 Eingabekontrolle

Maßnahmen, die gewährleisten, dass nachträglich überprüft und festgestellt werden kann, ob und von wem personenbezogene Daten in Datenverarbeitungssysteme eingegeben, verändert oder entfernt worden sind.

• Audit-Log (audit_log-Tabelle): jede datenschutzrelevante Aktion (gdpr.shop_redact, gdpr.customer_redact, gdpr.customer_data_request, Löschläufe sowie Eingriffe über das interne Verwaltungsportal) wird mit Zeitstempel, Aktion, betroffenem Shop, handelnder Person (E-Mail verschlüsselt), Rolle, IP-Adresse und Browserkennung protokolliert (Art. 30 Abs. 2 DSGVO);
• Sub-Processor-Änderungs-Historie: Änderungen der Sub-Processor-Liste werden über die versionierte, datierte Sub-Processor-Übersicht (/sub-processors + maschinenlesbarer /api/sub-processors.json-Feed) sowie die Versionshistorie des Dokuments nachvollziehbar dokumentiert;
• Versand-Audit-Trail: jedes erstellte Versandetikett wird mit über 50 Feldern protokolliert (shipments-Tabelle), inklusive vollständiger Carrier-API-Request- und Response-JSONs (verschlüsselt);
• Kennung am Packplatz (vom Händler einschaltbar): Jede Sendung speichert, wer sie erzeugt hat — den Anzeigenamen des am Packplatz angemeldeten Mitarbeiters oder den automatischen Auslöser (etwa Auto-Druck oder die Programmierschnittstelle mit dem Namen des Schlüssels) — in shipments.created_by, AES-256-GCM verschlüsselt, zusammen mit der Herkunftsart. Mitarbeiter melden sich mit einer selbst gewählten vierstelligen PIN an; gespeichert wird nur deren PBKDF2-Hash. Nach fünf Fehlversuchen ist der Name 15 Minuten gesperrt, je Shop sind zusätzlich höchstens 30 Fehlversuche in 15 Minuten möglich. Jede Anmeldung bildet eine eigene Sitzung. Sie endet nach 60 Minuten ohne Aktivität, spätestens nach 12 Stunden, mit der Abmeldung an diesem Platz und sofort, wenn der Händler den Mitarbeiter deaktiviert oder seine PIN zurücksetzt. Die erstmalige Vergabe einer PIN wird ohne Name und PIN im Audit-Protokoll vermerkt. Retouren-Links erzeugt bei eingeschalteter Kennung nur ein angemeldeter Mitarbeiter; sein Name wird am Link verschlüsselt gespeichert. Die PIN ordnet Sendungen zu und gewährt keine Verwaltungsrechte. Protokolliert wird nur die Sendung — keine einzelnen Bedienschritte, keine Leistungskennzahlen;
• Application-Logs: Server-Anwendungs-Logs (Uvicorn) enthalten Timestamp, Request-ID und Endpoint, jedoch keine PII (siehe 1.5);
• Error-Tracking (GlitchTip): automatisches Logging von Anwendungs-Exceptions inklusive Stack-Trace; PII-Scrubbing über before_send-Hook in app.py.

2.2 Schutz vor SQL-Injection und XSS

• Die kundenseitig gerenderten HTML-Seiten (Retouren-Portal, Tracking-Seite, Dokumente, E-Mails) werden mit Jinja2 bei aktiviertem Autoescape erzeugt; an den wenigen Stellen mit direkt zusammengesetztem HTML wird html.escape() eingesetzt;
• Content-Security-Policy mit default-src 'self' und eingeschränkten Skriptquellen (kein unsafe-inline im Skript-Kontext); zusätzlich HTTP Strict Transport Security, X-Content-Type-Options: nosniff, eine restriktive Referrer-Policy und eine Permissions-Policy. frame-ancestors steuert die Einbettung im Shopify-Adminbereich;
• Regelmäßige interne Security-Reviews (siehe docs/audit/ im Repository).

2.3 Transaktionssicherheit

• autocommit=False in der Datenbankverbindung — atomare Transaktionen mit explizitem Commit (Pflicht für Multi-Statement-DSGVO-Löschung);
• Zeilensperren (SELECT … FOR UPDATE) bei gleichzeitigen Schreibzugriffen auf Shop-Einstellungen, Druck- und Label-Warteschlange.

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

3.1 Verfügbarkeit

• Hosting: IONOS VPS L+ (6 vCores, 8 GB RAM, 240 GB NVMe), Berlin, Deutschland — Multi-Tenant-Coolify-Plattform mit Health-Checks;
• HEALTHCHECK: Docker-Healthcheck via curl auf /health-Endpoint — Coolify überwacht die Verfügbarkeit kontinuierlich;
• Hintergrundjobs: APScheduler (Zeitzone UTC) für die DSGVO-Bereinigung täglich um 03:00 und den stündlichen Abrechnungsabgleich. Sendungsstatus werden nicht periodisch abgefragt, sondern beim Aufruf der Tracking-Seite bedarfsgesteuert aktualisiert.

3.2 Belastbarkeit gegen Angriffe

• Rate-Limiting auf API-Ebene;
• Container-Härtung: die Anwendung läuft im Docker-Container als nicht-privilegierter Benutzer;
• Die Qualitäts- und Sicherheitsprüfungen sind in der Build-Konfiguration hinterlegt: Lint (ruff), TypeScript-Baseline, automatisierte Tests (pytest, vitest) sowie statische Sicherheitsanalyse (bandit; Befunde mit hoher Schwere und hoher Konfidenz sind blockierend). Python-Abhängigkeiten werden zusätzlich per CVE-Scan (pip-audit) ausgewertet.

3.3 Wiederherstellbarkeit (Art. 32 Abs. 1 lit. c DSGVO)

• wal-g WAL-Streaming: fortlaufende, bereits auf dem Server verschlüsselte Übertragung der Transaktionsprotokolle nach IONOS S3 (libsodium AES-256, lz4-Kompression). Sie erlaubt die Wiederherstellung auf einen frei wählbaren Zeitpunkt; die Dauer dieser Wiederherstellung ist noch nicht gemessen;
• wal-g daily base backup: 03:00 UTC, 35-Tage-Retention via wal-g delete retain FULL 35;
• Objektsperre (WORM): Der Backup-Bucket ist mit Object Lock im Modus COMPLIANCE (30 Tage) und Versionierung konfiguriert — Schutz gegen Ransomware und nachträgliche Manipulation. Im Modus COMPLIANCE kann die Sperre von niemandem aufgehoben werden, auch nicht vom Kontoinhaber; ein Angreifer mit vollständigem Serverzugriff kann die Sicherungen daher nicht vernichten;
• pg_dump GPG-encrypted Cron: /opt/karl-backup/backup.sh: pg_dump | gzip | gpg AES256 auf IONOS S3, stündlich;
• Coolify built-in pg_dump-Backup ist deaktiviert (war nicht client-side encrypted) — Reduktion der Angriffsfläche;
• Wiederherstellungs-Tests: Verfahren, Szenarien und Erfolgskriterien sind in einem Wiederherstellungsplan dokumentiert (Restore aus letztem Base-Backup + WAL-Replay auf separater Instanz). Tests sind mindestens halbjährlich vorgesehen und werden mit Datum und Ergebnis protokolliert. Der erste vollständige Durchlauf wurde am 27.07.2026 durchgeführt: Wiederherstellung aus dem verschlüsselten Datenbank-Abzug auf eine separate Instanz, anschließend Stichprobenprüfung der verschlüsselten Felder mit dem produktiven Schlüssel — fehlerfrei, mit protokollierter Wiederherstellungszeit. Am 04.08.2026 wurde der Test gegen eine 15 Tage alte Sicherung wiederholt: 94 Tabellen fehlerfrei eingespielt, Einspieldauer 4 Sekunden, 79 von 79 Stichproben mit dem produktiven Schlüssel entschlüsselbar. Die Protokolle liegen im Repository unter docs/restore-tests/. Der Wiederherstellungsweg über fortlaufende Transaktionsprotokolle (WAL-Replay) ist eingerichtet, aber noch nicht separat durchgespielt; er ist für den nächsten Turnus vorgesehen.

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

4.1 Regelmäßige Überprüfung der TOMs

• Jährliche oder anlassbezogene Überprüfung der TOMs auf Wirksamkeit und Anpassung an den Stand der Technik;
• Wesentliche Änderungen werden im Audit-Log und im Versions-Header dieses Dokuments dokumentiert;
• Auftraggeber werden über wesentliche Änderungen mit angemessener Vorlauffrist informiert.

4.2 Interne Security-Audits

• Regelmäßige interne Security-Audits (Code-Review, Dependency-Audits, GDPR-Sweep);
• Erkenntnisse werden in docs/audit/ als zeitstempelbenannte Audit-Berichte abgelegt (z. B. 2026-04-19-security-gdpr-shopify-audit.md);
• Befunde werden nach Schwere klassifiziert und priorisiert behandelt; kritische Befunde werden vorrangig behoben.

4.3 Auftragskontrolle (Art. 28 DSGVO)

• Mit jedem Unterauftragsverarbeiter wird ein eigener AVV nach Art. 28 DSGVO geschlossen. Nicht erfasst sind Empfänger, die die Daten als eigene Verantwortliche verarbeiten — insbesondere die Carrier (siehe AVV, Anlage 1);
• Sub-Processor-Liste (Sub-Processor-Liste) wird öffentlich geführt;
• Änderungen werden mit 30-Tage-Vorlauffrist und Widerspruchsrecht des Auftraggebers kommuniziert (siehe AVV § 6).

4.4 Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen (Art. 25 DSGVO)

• Datenminimierung: KARL liest aus Shopify ausschließlich die für den Versandprozess erforderlichen Felder (Bestellinhalte, Adressen) — keine Profilbildung, kein Tracking, keine Weitergabe an Dritte zu Werbezwecken;
• Privacy by Design: Pseudonymisierung (Verschlüsselung) ist Default für alle PII-Spalten; ein Opt-out gibt es nicht;
• Privacy by Default: Branded Tracking ist bei Neuinstallation abgeschaltet und muss vom Händler bewusst eingeschaltet werden.

5. Datenträgerverwaltung und Datenträgervernichtung

• Keine physischen Datenträger beim Auftragsverarbeiter — sämtliche Datenhaltung erfolgt auf gemieteten Cloud-Servern (IONOS).
• Bei Außerbetriebnahme der IONOS-Hardware übernimmt IONOS die DSGVO-konforme Datenträgervernichtung (siehe IONOS-AVV).
• Backups im S3-Object-Storage laufen durch die Retention-Policy automatisch aus: die stündlichen verschlüsselten Datenbank-Abzüge nach 30 Tagen; eine zusätzliche lokale Kopie auf dem Server wird nach 7 Tagen gelöscht. Von den täglichen wal-g-Basis-Sicherungen werden die letzten 35 vorgehalten, was bei täglichem Lauf rund 35 Tagen entspricht. Der Bucket ist mit Objektsperre (WORM, Modus COMPLIANCE, 30 Tage) und Versionierung konfiguriert — ein geschriebenes Backup ist in dieser Zeit weder überschreibbar noch löschbar, auch nicht mit gültigen Zugangsdaten und auch nicht durch den Kontoinhaber.

6. Datenpannen-Meldeprozess (Art. 33, 34 DSGVO)

• Bei Bekanntwerden einer Datenpanne wird der betroffene Auftraggeber unverzüglich benachrichtigt — per E-Mail an die E-Mail-Adresse, die in Shopify für seinen Shop hinterlegt ist, und an die E-Mail-Adressen der in KARL angelegten Admins des Auftraggebers; ergänzend wird eine Support-Nachricht im Admin-Bereich der App eingestellt (Art. 33 Abs. 2 DSGVO, siehe AVV § 8 Abs. 2);
• Parallel wird das Ereignis im internen Incident-Response-Plan (docs/incident-response.html) dokumentiert;
• Die Meldung an die Aufsichtsbehörde gemäß Art. 33 Abs. 1 DSGVO erfolgt in der Verantwortung des betroffenen Auftraggebers — der Auftragsverarbeiter unterstützt mit allen nötigen Informationen.

7. Verantwortliche Stellen und Aufsichtsbehörde

• Auftragsverarbeiter: KYTH. Systems UG (haftungsbeschränkt), Prof.-Mederer-Str. 4, 92348 Berg, Deutschland;
• Datenschutz-Kontakt: datenschutz@kyth.systems;
• Zuständige Aufsichtsbehörde: Bayerisches Landesamt für Datenschutzaufsicht (BayLDA), Promenade 18, 91522 Ansbach, www.lda.bayern.de;
• Datenschutzbeauftragter: Aufgrund der Unternehmensgröße besteht keine Pflicht zur Bestellung eines DSB nach § 38 BDSG. Datenschutz-Anfragen werden zentral durch die Geschäftsführung beantwortet.