Ihre Automatisierung ist ein Datenlager, das niemand aufräumt
Nach der Absage sind die Bewerberdaten gelöscht, glauben Sie. In der Ausführungshistorie Ihrer Automatisierung liegen sie oft noch Monate. Warum das ein DSGVO-Problem ist und wie Sie es in zehn Minuten abstellen.
Ein Kunde wollte wissen, wo eine abgelehnte Bewerbung noch auftaucht
Ein Unternehmen mit rund 200 Mitarbeitern hatte seinen Bewerbungsprozess automatisiert. Bewerbung rein, Daten ins Bewerbertool, eine Automatisierung verteilt sie an die zuständige Führungskraft, legt einen Kalendereintrag an, verschickt die Eingangsbestätigung. Nach einer Absage löschte das Bewerbertool die Daten nach sechs Monaten, so wie es die interne Frist vorsah.
Dann kam ein Auskunftsersuchen nach Artikel 15 DSGVO. Ein abgelehnter Bewerber wollte wissen, welche Daten das Unternehmen noch über ihn gespeichert hat. Die Personalleiterin war sich sicher: gelöscht, nichts mehr da. Bis wir gemeinsam in die Automatisierungsplattform geschaut haben. Dort lag die komplette Bewerbung. Name, Anschrift, der Lebenslauf als Anhang, das Anschreiben im Klartext. In der Ausführungshistorie der Workflows, seit acht Monaten.
Jede Ausführung ist eine Kopie, die liegen bleibt
Das ist kein Sonderfall, das ist die Voreinstellung. Make, n8n, Zapier und die meisten anderen Plattformen speichern für jeden Durchlauf, was durch den Workflow geflossen ist. Sinnvoll ist das durchaus, denn ohne diese Historie könnten Sie einen Fehler nicht nachvollziehen. Wenn nachts um drei eine Bestellung schiefläuft, wollen Sie am Morgen sehen, welche Daten reinkamen und an welchem Schritt es hakte.
Der Preis dafür: Jeder dieser Durchläufe enthält die echten Daten, keine Zusammenfassung. Und während Sie die Aufbewahrung im Quellsystem sauber geregelt haben, im CRM, im Bewerbertool, in der Buchhaltung, hat für die Automatisierungsebene niemand eine Frist gesetzt. Sie fällt durchs Raster, weil kaum jemand sie als eigenständigen Ort wahrnimmt, an dem Daten liegen. Sie ist die Brücke zwischen zwei Systemen, und alle vergessen, dass die Brücke mitschreibt.
Ich nenne das den blinden Fleck der Automatisierung. Alle schauen auf die Systeme an den Enden, das CRM, das Postfach, die Datenbank, und niemand auf die Schicht dazwischen, die still jeden Datensatz protokolliert, den sie je verarbeitet hat. Genau dort finde ich in fremden Setups die ältesten Personendaten, manchmal Jahre alt, in Workflows, an die sich längst niemand mehr erinnert.
Wie lange speichern Make, n8n und Zapier?
Kurz, weil die Frage in jedem Projekt kommt: länger, als Sie denken, und es hängt von Plattform und Tarif ab.
Make hält Ausführungsdaten je nach Tarif etwa 30 bis 90 Tage vor, einstellbar pro Szenario. Zapier speichert die Task-Historie über Monate. Bei n8n, das viele selbst hosten, entscheiden Sie es selbst, und genau das ist die Falle. Ohne aktive Konfiguration wächst die Datenbank einfach weiter, bis irgendwann jemand merkt, dass dort zwei Jahre Personendaten liegen, die längst gelöscht sein müssten.
Das trifft nicht nur große Häuser. Ein Einzelunternehmer, der Kontaktformulare per Zapier ins Postfach und in eine Tabelle schreibt, sammelt genauso Personendaten in der Task-Historie, nur ohne Datenschutzbeauftragten, der irgendwann nachfragt. Die ehrliche Antwort lautet also: lange genug, um ein Problem zu sein, solange Sie nichts einstellen.
Warum das mehr ist als ein Formfehler
Man kann das als Kleinigkeit abtun. Ich würde es lassen. Zwei Gründe.
Erstens die Auskunft. Fragt jemand nach Artikel 15, welche Daten Sie über ihn halten, müssen Sie vollständig antworten. Vergessen Sie die Automatisierungsplattform, ist Ihre Auskunft falsch. Und eine falsche Auskunft gegenüber einer Aufsichtsbehörde ist ein anderes Gespräch als eine verspätete.
Zweitens das Risiko. Eine Automatisierungsumgebung mit acht Monaten Bewerbungen, Rechnungen oder Gesundheitsdaten ist ein lohnendes Ziel. Der Zugang läuft oft über einen einzigen API-Schlüssel oder ein geteiltes Login ohne zweiten Faktor. Ich habe Umgebungen gesehen, in denen ein einziges Konto Zugriff auf Verbindungen zu CRM, Postfach und Bank-Export hatte. Wird so ein Zugang kompromittiert, ist nicht nur der aktuelle Datenverkehr betroffen, sondern das ganze Archiv. Sie haben ein Datenleck vorbereitet, ohne es zu wollen.
Was ich vor jedem Go-Live prüfe
Drei Dinge, die kaum Zeit kosten.
Aufbewahrung bewusst setzen. Für jeden Workflow, der Personendaten verarbeitet, legen Sie eine Frist fest, die zur Aufbewahrung im Quellsystem passt. Wird die Bewerbung nach sechs Monaten gelöscht, darf die Ausführungshistorie sie nicht länger halten. Bei Make und Zapier ist das eine Einstellung, bei n8n ein Startparameter plus ein Aufräum-Job.
Weniger durchleiten. Braucht der Workflow wirklich den kompletten Lebenslauf als Anhang, oder reichen eine Referenz-ID und ein Name? Was nie durch die Automatisierung fließt, kann sie auch nicht speichern. Datenminimierung ist hier keine Theorie, sie nimmt Ihnen das halbe Problem ab, bevor es entsteht.
Sensible Felder maskieren. Gute Plattformen erlauben es, einzelne Werte in der Historie zu schwärzen, etwa Passwörter, Zahlungsdaten oder Gesundheitsangaben. Zehn Minuten Konfiguration, und aus einem Datenleck im Ernstfall wird ein Schulterzucken.
Der Satz, der in jede Automatisierungs-Doku gehört
Wenn Sie eine Sache aus diesem Text mitnehmen, dann die: Ihre Automatisierung ist ein Ort, an dem Personendaten liegen. Kein Kabel, kein Durchlauf, ein Speicher. Behandeln Sie sie wie jedes andere System, das unter die DSGVO fällt, mit einer Frist, einem Verantwortlichen und einem Eintrag im Verzeichnis der Verarbeitungstätigkeiten.
Die Personalabteilung von oben hat übrigens nachträglich eine Frist von 30 Tagen gesetzt und den alten Bestand gelöscht. Zehn Minuten Arbeit. Die eigentliche Arbeit war, überhaupt zu merken, dass es das Problem gibt.