Kundendaten in Schnittstellen-Logs: was bleiben darf

Ein Protokoll mit Namen und Anschrift ist eine Verarbeitung personenbezogener Daten wie jede andere. Es gelten dieselben Grundsätze wie für das Kundenkonto im Shop, und zwei davon treffen Schnittstellen-Logs unmittelbar. Personenbezogene Daten müssen dem Zweck angemessen und erheblich sowie auf das für die Zwecke der Verarbeitung notwendige Maß beschränkt sein, die Datenminimierung (Art. 5 Abs. 1 lit. c DSGVO). Und sie dürfen in einer Form, die die Identifizierung erlaubt, nur so lange gespeichert werden, wie es für die Zwecke erforderlich ist, die Speicherbegrenzung (Art. 5 Abs. 1 lit. e DSGVO).

Für ein Schnittstellenprotokoll heißt das: Der Zweck ist die Fehlersuche und der Nachweis, dass eine Nachricht zugestellt wurde. Was diesen Zweck nicht trägt, gehört nicht hinein, und was ihn erfüllt hat, wird gelöscht. Die DSGVO verlangt zusätzlich, dass durch Voreinstellung nur Daten verarbeitet werden, die für den jeweiligen Zweck erforderlich sind, und nennt dabei ausdrücklich die Menge der Daten, den Umfang der Verarbeitung, die Speicherfrist und die Zugänglichkeit (Art. 25 Abs. 2 DSGVO). Eine Protokollierung, die standardmäßig die volle Nutzlast schreibt, verfehlt diesen Maßstab schon in der Grundeinstellung.

Hinzu kommt die Rechenschaftspflicht: Der Verantwortliche muss die Einhaltung der Grundsätze nachweisen können (Art. 5 Abs. 2 DSGVO). Verstöße gegen die Grundsätze des Art. 5 fallen in den oberen Bußgeldrahmen von bis zu 20 Millionen Euro (Art. 83 Abs. 5 DSGVO) oder im Fall eines Unternehmens bis zu 4 Prozent (Art. 83 Abs. 5 DSGVO) des weltweit erzielten Jahresumsatzes des vorangegangenen Geschäftsjahrs, je nachdem, welcher Betrag höher ist. Das ist der Rahmen, keine Vorhersage für den Einzelfall. Im Alltag zählt eher, dass sich die Protokollierung bei einer Beschwerde oder Prüfung in wenigen Sätzen erklären und belegen lässt.

Die Informationssicherheit kommt von der anderen Seite zum selben Ergebnis. Der IT-Grundschutz des BSI fordert für die Protokollierung, die Datenschutzbestimmungen einzuhalten, und verlangt, Protokollierungsdaten nach einem festgelegten Prozess zu löschen (BSI IT-Grundschutz OPS.1.1.5). Als Gefährdung nennt derselbe Baustein ausdrücklich eine falsch konfigurierte Protokollierung, bei der personenbezogene Daten unberechtigt protokolliert und gespeichert werden.

Für jedes Feld, das nicht im Klartext ins Protokoll soll, gibt es mehrere Wege. Sie unterscheiden sich darin, ob der Wert später noch zuzuordnen ist und wer das kann. Pseudonymisierung und Verschlüsselung nennt die DSGVO ausdrücklich als Beispiele für Maßnahmen zur Sicherheit der Verarbeitung (Art. 32 Abs. 1 lit. a DSGVO).

Beim Pseudonymisieren lohnt ein genauer Blick auf den Begriff. Die DSGVO versteht darunter eine Verarbeitung, nach der die Daten ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer bestimmten Person zugeordnet werden können, sofern diese Informationen gesondert aufbewahrt und geschützt werden (Art. 4 Nr. 5 DSGVO). Pseudonymisierte Daten bleiben damit personenbezogen. Der Europäische Datenschutzausschuss stellt das in seinen Leitlinien zur Pseudonymisierung klar und nennt ein Beispiel, das für Logs direkt passt: Ist bekannt, dass die Umwandlung nur ein SHA-256-Hash eines Namens ist, kann jeder mit einer Namensliste dieselben Hashes berechnen und Treffer finden (EDPB Leitlinien 01/2025).

Für Schnittstellen-Logs folgt daraus eine einfache Regel. Wer ein stabiles Kürzel braucht, etwa um wiederkehrende Fehler bei demselben Kundenkonto zu erkennen, nimmt ein Verfahren mit geheimem Schlüssel, zum Beispiel einen HMAC, und verwahrt den Schlüssel außerhalb des Log-Systems. Der EDPB beschreibt für Sicherheitsprotokolle genau diesen Weg: Kennungen wie IP-Adressen, Zugangstoken und Anmeldedaten werden mit einer schlüsselgebundenen kryptografischen Einwegfunktion umgewandelt, sofern sie genügend Zufall enthalten, und andernfalls entfernt (EDPB Leitlinien 01/2025). Werte mit wenig Zufall, etwa Postleitzahlen oder Geburtsdaten, fallen deshalb besser ganz weg.

Die zweite Zeile beantwortet dieselben Fragen wie die erste: welche Bestellung, wann, welcher Fehler, welches Feld. Wer die Anschrift für die Klärung braucht, öffnet die Bestellung im Shop oder den Eintrag in der Fehlerablage. Technisch setzen Sie das sinnvollerweise an einer Stelle um, im Logging-Baustein der Middleware, statt in jedem Konnektor einzeln. Eine Erlaubnisliste je Nachrichtentyp, ein gemeinsamer Filter für bekannte Feldnamen und ein automatischer Test, der eine Bestellung voller Beispieldaten durchschickt und prüft, dass keiner der Werte im Log auftaucht, halten die Regel auch bei späteren Änderungen am Format stabil. Die Beispieldaten dafür gehören in eine eigene Umgebung, wie im Beitrag zu Testumgebungen für ERP-Schnittstellen beschrieben.

Ein einziges Aufbewahrungsdatum für alle Logs ist bequem und passt selten. Ein Erfolgsprotokoll wird gebraucht, bis der Abgleich zwischen Shop und ERP bestätigt hat, dass die Nachricht angekommen ist. Ein Fehlerprotokoll wird gebraucht, bis der Fall geklärt ist, plus einen Nachlauf für Rückfragen. Die Fehlerablage braucht die Nutzlast nur bis zur Entscheidung. Das Standard-Datenschutzmodell verlangt, für Protokolldaten Aufbewahrungsfrist und Löschung festzulegen, und setzt dabei in der Regel mindestens zwei Löschfristen (SDM-Baustein 43) ins Verhältnis: die aus der Fachlichkeit abgeleitete und die aus funktionalen Gründen der jeweiligen Protokollierungsebene. Maßgebend ist die fachlich begründete.

Die Tabelle nennt bewusst keine Tageszahlen. Wie lange ein Nachlauf sinnvoll ist, hängt davon ab, wie schnell Rückfragen aus Kundenservice und Buchhaltung typischerweise kommen und wie oft der Abgleich läuft. Legen Sie den Wert je Ablage fest, begründen Sie ihn in einem Satz und lassen Sie das System das Ende aus dem Ereignis berechnen. Wie ein solches Löschkonzept über Shop, ERP und Buchhaltung hinweg aufgebaut ist, beschreibt der Beitrag zum Löschkonzept über Systemgrenzen.

Die ausführliche Stufe verdient eine eigene Regel, weil sie der häufigste Weg ist, auf dem volle Nutzlasten in den Alltag geraten. Schalten Sie sie nur befristet und nur für eine Schnittstelle frei, mit automatischer Rückstellung und einem Eintrag, wer sie wann aktiviert hat. Die Schwachstellenliste CWE von MITRE führt das Schreiben sensibler Informationen in Logdateien als eigene Schwäche und rät unter anderem, Konfigurationen beim Übergang vom Debug-Zustand in die Produktion anzupassen und Logdateien gegen unbefugtes Lesen zu schützen (MITRE CWE-532).

Ein Einwand kommt oft aus der Buchhaltung: Die Übergabe an das ERP müsse nachweisbar bleiben. Das stimmt, aber der Nachweis braucht keine Kundendaten. Ob ein Übergabeprotokoll zu den sonstigen Unterlagen zählt, die für die Besteuerung von Bedeutung sind (§ 147 Abs. 1 AO), klären Sie mit Ihrer Steuerberatung. Selbst dann genügen in der Regel Belegnummer, Zeitpunkt, Status und Prüfsumme; die Kundendaten stehen im Beleg selbst, der ohnehin im ERP aufbewahrt wird. In die GoBD-Verfahrensdokumentation gehört dann die Beschreibung, wie dieser Nachweis entsteht.

Wenn eine Kundin wissen will, welche Daten über sie gespeichert sind, gehören die Schnittstellen-Logs zur Antwort, sofern sie ihre Daten enthalten. Die Auskunft umfasst unter anderem die geplante Speicherdauer oder, falls das nicht möglich ist, die Kriterien für ihre Festlegung (Art. 15 Abs. 1 lit. d DSGVO). Sie ist unverzüglich, in jedem Fall aber innerhalb eines Monats (Art. 12 Abs. 3 DSGVO) nach Eingang des Antrags zu erteilen; eine Verlängerung ist nur in begründeten Fällen vorgesehen. Das Standard-Datenschutzmodell verlangt, dass das Protokollierungskonzept ausweist, ob und wie Auskünfte aus dem Protokolldatenbestand praktisch erfüllt werden können (SDM-Baustein 43). Wer Kundendaten im Log hat, muss dort also auch nach Personen suchen können, nicht nur nach Bestellnummern.

Bei der Löschung ist es ebenso. Verlangt eine Person die Löschung ihrer Daten und trifft einer der gesetzlichen Gründe zu, sind die Daten unverzüglich zu löschen (Art. 17 Abs. 1 DSGVO). Ein Löschpfad, der Shop, ERP und CRM erreicht, aber Fehlerablage und zentrales Log-System auslässt, ist unvollständig. Mit reinen Verweisen auf die Bestellnummer schrumpft dieser Aufwand, weil der Inhalt an der Quelle bearbeitet wird und in den Logs nur noch Kennungen mit kurzer Frist stehen.

Bleibt die Datenpanne. Ein Log-System bündelt Daten vieler Anwendungen und kann selbst Ziel von Angriffen sein. OWASP weist darauf hin, dass Logs personenbezogene Daten von Nutzern enthalten und Angreifer diese sammeln, um sie zu veröffentlichen oder für weitere Angriffe zu nutzen (OWASP Logging Cheat Sheet). Fließt ein Log mit Kundendaten ab, ist das eine Verletzung des Schutzes personenbezogener Daten, die der Verantwortliche unverzüglich und möglichst binnen 72 Stunden (Art. 33 Abs. 1 DSGVO) der Aufsichtsbehörde meldet, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Betroffenen. Ein Log mit Bestellnummern und Fehlercodes macht diese Abwägung deutlich einfacher als eines mit Anschriften und Bankverbindungen.

Der letzte Schritt wird gern vergessen. Ein neuer Filter schützt nur die Zeilen, die ab heute geschrieben werden. Was in den vergangenen Monaten mit voller Nutzlast angefallen ist, bleibt liegen, bis jemand es aktiv entfernt. Planen Sie dafür einen eigenen Termin, und prüfen Sie danach mit einer Suche nach typischen Mustern wie IBAN-Formaten oder E-Mail-Adressen, ob der Bestand tatsächlich bereinigt ist. Wer ohnehin Änderungen an der Bestellübergabe plant, etwa für Bestelländerungen nach der ERP-Übergabe, stellt die Protokollierung im selben Zug um. Bei eigenen Konnektoren und Schnittstellen unterstützen wir im Rahmen der API-Entwicklung, bei der Anbindung der Warenwirtschaft gehört die Protokollregel von Anfang an in die Planung.