Ihre heikelsten Daten liegen in den Logs, und niemand hat ein Löschkonzept dafür

Bei einem Kunden lag der heikelste Datensatz nicht in der Datenbank

Im Frühjahr hat ein Kunde von uns ein Löschbegehren bekommen. Eine ehemalige Bewerberin wollte, dass alle ihre Daten verschwinden. Standardfall, dachte das Team. Datensatz im Bewerbersystem löschen, im CRM nachziehen, das alte Bewerbungspostfach durchsuchen, fertig.

Dann haben wir die Automatisierungen angeschaut.

Die Bewerbung war über ein Formular reingekommen. Ein Webhook hatte sie an ein Make-Szenario übergeben, das den Lebenslauf ausgelesen, eine Slack-Nachricht ans HR-Team geschickt und einen Eintrag in einer Notion-Datenbank angelegt hat. Jeder einzelne dieser Schritte hat eine Spur hinterlassen. Und die saß nicht im Bewerbersystem, sondern in den Execution-Logs des Szenarios. Vollständiger Name, Adresse, Geburtsdatum, der komplette Lebenslauf im Klartext. 90 Tage Aufbewahrung, weil das der Standardwert war, den nie jemand angefasst hat.

Das ist die Lücke, über die in Automatisierungsprojekten fast niemand redet. Alle reden über die Datenbank. Kaum jemand über die Logs.

Warum Logs die unsichtbarste Kopie Ihrer Daten sind

Ein Log fühlt sich nicht wie ein Datenspeicher an. Es fühlt sich wie Technik an, wie etwas, das die Plattform im Hintergrund für sich selbst macht. Genau das ist der Denkfehler.

Wenn ein Workflow läuft, schreibt die Plattform mit, was durch jeden Schritt geflossen ist. Bei Make sind das die Bundles jeder Operation, bei n8n die Ein- und Ausgabedaten jeder Node, bei Zapier die Task-History. Diese Daten sind vollständig. Wenn durch Ihren Workflow eine E-Mail-Adresse, eine Telefonnummer oder eine Kontonummer läuft, dann liegt sie danach im Log. Nicht als Verweis, sondern als Inhalt.

Und es bleibt nicht bei der Plattform selbst. Die heikleren Kopien entstehen oft erst daneben:

Ein Fehler-Tracker wie Sentry bekommt bei jedem Absturz den kompletten Payload mitgeliefert, inklusive der Daten, die den Absturz ausgelöst haben. Ein Slack-Kanal, in den ein Workflow seine Statusmeldungen schreibt, sammelt über Monate jede einzelne verarbeitete Adresse. Ein Logging-Dienst wie Datadog speichert dieselben Nachrichten noch ein zweites Mal. Eine Retry-Queue hält fehlgeschlagene Datensätze tagelang vor, damit sie später erneut verarbeitet werden können.

Am Ende existiert ein personenbezogener Datensatz nicht einmal, sondern vier- oder fünfmal. Die Datenbank ist die Kopie, an die alle denken. Die anderen vier denkt niemand mit.

Die Frage, die fast jedes Team falsch beantwortet

Wenn ich in einem Projekt frage: "Wo überall liegen die Daten dieser einen Person?", bekomme ich fast immer die Antwort "im CRM" oder "in der Datenbank". Die richtige Antwort lautet: überall dort, wo der Workflow sie hingetragen hat, plus überall dort, wo eine Plattform mitprotokolliert hat.

Das ist nicht akademisch. Artikel 17 DSGVO, das Recht auf Löschung, hört nicht an der Datenbankgrenze auf. Wenn Sie personenbezogene Daten in Logs aufbewahren und jemand verlangt seine Löschung, müssen Sie sie auch aus den Logs entfernen, sofern keine gesetzliche Aufbewahrungspflicht dagegen steht. Ein Aufbewahrungswert von 90 Tagen, den niemand bewusst gesetzt hat, ist keine Rechtsgrundlage. Er ist nur ein Standardwert, den Sie geerbt haben.

Dazu kommt die Frage der Auftragsverarbeitung. Jeder Dienst, der Ihre Logs speichert, verarbeitet personenbezogene Daten in Ihrem Auftrag. Make, n8n Cloud, Sentry, Datadog, Slack. Für jeden brauchen Sie einen Auftragsverarbeitungsvertrag, und Sie sollten wissen, wo die Daten physisch liegen. Bei einem US-Anbieter ohne brauchbare Rechtsgrundlage haben Sie genau dort ein Problem, wo Sie es am wenigsten erwartet haben: im Log einer Nebensache.

Was wir konkret machen

Die gute Nachricht: das Problem ist lösbar, und der Aufwand ist überschaubar, wenn man es früh angeht. Wir gehen vier Schritte durch.

Erstens: erfassen, was überhaupt durchläuft

Bevor man etwas reparieren kann, muss man wissen, welche Workflows mit personenbezogenen Daten arbeiten. Wir gehen jedes aktive Szenario durch und markieren, ob Namen, Kontaktdaten, Finanzdaten oder besondere Kategorien wie Gesundheits- oder Bewerbungsdaten durchlaufen. Bei den meisten Kunden sind das weniger Workflows, als sie denken, aber es sind immer mehr als null.

Zweitens: nur loggen, was man braucht

Der häufigste Fehler ist, alles mitzuschreiben, weil es bequem ist. Dabei braucht man für die Fehlersuche selten den vollständigen Datensatz. Eine Bestell-ID reicht, um einen Fall nachzuverfolgen. Der Name des Kunden muss dafür nicht im Slack-Kanal stehen. Wir reduzieren die Daten, die in Logs und Benachrichtigungen landen, auf das, was für den Betrieb wirklich nötig ist. Identifikatoren statt Inhalte.

Drittens: maskieren, wo Inhalte bleiben müssen

Manchmal braucht man den Inhalt doch, etwa um zu sehen, an welchem Feld ein Import scheitert. Dann maskiert man die heiklen Teile. Eine E-Mail wird zu `m***@firma.de`, eine Kontonummer zeigt nur die letzten vier Stellen. Make und n8n erlauben das mit einem zusätzlichen Schritt, der die Daten vor dem Logging oder vor der Slack-Meldung durch eine kleine Funktion schickt. Das kostet zehn Minuten Aufbau und spart später eine unangenehme Diskussion mit dem Datenschutzbeauftragten.

Viertens: Aufbewahrung bewusst setzen

Jeder Standardwert für die Log-Aufbewahrung sollte einmal angefasst und bewusst entschieden worden sein. Wie lange braucht der Betrieb diese Logs wirklich, um Fehler zu finden? Bei den meisten Workflows sind das sieben bis vierzehn Tage, nicht neunzig. Stellen Sie den Wert herunter, und ein großer Teil des Problems löst sich von selbst, weil die Daten gar nicht erst lange genug liegen, um zum Risiko zu werden.

Häufige Frage: Reicht es nicht, einfach die Logs abzuschalten?

Das ist die Reaktion, die ich am häufigsten höre, sobald das Problem auf dem Tisch liegt. Und sie ist falsch. Wer Logs komplett abschaltet, tauscht ein Datenschutzproblem gegen ein Betriebsproblem. Ohne Logs sehen Sie nicht mehr, warum eine Automatisierung fehlschlägt, und genau dann, wenn nachts ein Workflow stillsteht, fehlt Ihnen die Information, die Sie zum Reparieren brauchen.

Das Ziel ist nicht, blind zu fliegen. Das Ziel ist, genug zu sehen, um zu betreiben, ohne mehr zu speichern, als nötig ist. Ein Log, das eine Bestell-ID und eine Fehlermeldung enthält, aber keinen Klarnamen, erfüllt beide Anforderungen. Sie können den Fehler finden, und Sie haben keine Personendaten, die Sie nach 90 Tagen erklären müssen.

Was ich daraus mitgenommen habe

Der Bewerbungsfall hat bei dem Kunden nichts Dramatisches ausgelöst. Wir haben die Logs durchsucht, die betroffenen Einträge gelöscht, die Aufbewahrung von 90 auf 14 Tage gestellt und in zwei Workflows die Namen aus den Slack-Meldungen entfernt. Eine Stunde Arbeit, im Nachhinein.

Was hängen geblieben ist: Datenschutz in Automatisierungen passiert selten an der Stelle, an die man zuerst schaut. Die Datenbank ist sichtbar, also wird sie geschützt. Die Logs sind unsichtbar, also werden sie vergessen. Genau deshalb sind sie das größere Risiko. Eine Datenkopie, von der niemand weiß, kann auch niemand löschen.

Wenn Sie nicht sicher sind, welche personenbezogenen Daten gerade in Ihren Logs, Fehler-Trackern und Benachrichtigungskanälen liegen, lohnt sich ein Blick in unseren kostenlosen Automations-Check. Wir gehen Ihre aktiven Workflows gemeinsam durch und markieren die Stellen, an denen Daten landen, an die bisher niemand gedacht hat.