Die Datenpanne kommt nicht vom Hacker. Sie kommt aus Ihrem eigenen Workflow.
Eine falsche Verknüpfung, und 300 Kunden bekommen fremde Rechnungen. Warum solche Automatisierungspannen meldepflichtig sind und was die 72 Stunden rettet.
300 Rechnungen, 300 falsche Empfänger
An einem Dienstagmorgen rief uns die Buchhalterin eines Kunden an, Stimme dünn. Der monatliche Rechnungsversand war über Nacht gelaufen, automatisch, wie seit anderthalb Jahren. Nur hatte diesmal jemand eine Spalte in der Quelltabelle verschoben. Die Automatisierung nahm brav die Adresse aus Zeile eins und die Rechnung aus Zeile zwei, kombinierte munter weiter, und verschickte rund 300 Rechnungen an die jeweils falschen Empfänger. Kundin A bekam die Zahlen von Kunde B, inklusive Umsatz, Kontostand und offener Posten.
Kein Angreifer. Kein Leak. Keine Sicherheitslücke im klassischen Sinn. Ein verschobenes Feld in einem Google Sheet, ausgeführt von einem Workflow, der genau das tat, was man ihm gesagt hatte.
Das ist eine Datenpanne im Sinne der DSGVO. Und ab dem Moment, in dem die Buchhalterin es gemerkt hat, lief eine Frist von 72 Stunden.
Die gefährlichsten Pannen sind hausgemacht
Wenn Menschen an Datenschutzvorfälle denken, denken sie an Hacker, an Ransomware, an ein Datenleck bei einem großen Anbieter. Die Vorfälle, die wir in Projekten tatsächlich sehen, sehen anders aus. Ein falscher Verteiler im Serienbrief. Eine Testautomatisierung, die versehentlich auf die Produktivdaten zeigte. Ein CRM-Feld, das mit dem falschen Kontakt verknüpft war und in jeder Bestätigungsmail den falschen Namen ausgab.
Automatisierung verstärkt genau diese Art von Fehler. Ein Mensch, der Briefe kuvertiert, merkt beim dritten Umschlag, dass etwas nicht stimmt. Ein Workflow merkt nichts. Er macht den Fehler nicht dreimal, er macht ihn dreihundertmal, in unter einer Minute, und schickt danach eine Erfolgsmeldung.
Das Tückische: Solche Pannen fühlen sich nicht wie Datenschutzvorfälle an. Es ist ja "nur" ein Versandfehler. Genau deshalb werden sie oft verschwiegen, intern kleingeredet oder erst gemeldet, wenn sich ein Empfänger beschwert. Da sind die 72 Stunden meist längst vorbei.
Wann eine Automatisierungspanne gemeldet werden muss
Hier die konkrete Antwort, weil sie in der Praxis dauernd falsch beantwortet wird: Nach Artikel 33 DSGVO muss eine Verletzung des Schutzes personenbezogener Daten binnen 72 Stunden nach Bekanntwerden an die zuständige Aufsichtsbehörde gemeldet werden, es sei denn, die Panne führt voraussichtlich nicht zu einem Risiko für die Betroffenen. Kommen zusätzlich hohe Risiken dazu, etwa Finanzdaten oder Gesundheitsdaten, müssen nach Artikel 34 auch die Betroffenen selbst informiert werden.
Der Fehlversand von 300 Rechnungen mit Umsatzzahlen an fremde Empfänger ist kein Grenzfall. Das ist meldepflichtig, und die Betroffenen sind zu informieren. Die Frage ist nie, ob gemeldet werden muss, sondern ob Sie in 72 Stunden überhaupt sagen können, was passiert ist.
Wichtig ist die Formulierung "nach Bekanntwerden". Die Uhr startet nicht, wenn Ihr Anwalt die Lage bewertet hat, sondern in dem Moment, in dem irgendjemand im Unternehmen von dem Vorfall Kenntnis hat. Die Buchhalterin, die um acht Uhr die erste Beschwerde liest, hat die Frist bereits ausgelöst, auch wenn die Geschäftsführung erst mittags davon erfährt.
Und da fängt das eigentliche Problem an.
Warum ausgerechnet Automatisierungen das Melden schwer machen
Eine Meldung nach Artikel 33 verlangt konkrete Angaben: Welche Kategorien von Daten, wie viele Betroffene ungefähr, welche Folgen, welche Gegenmaßnahmen. Bei einem manuellen Prozess kann jemand rekonstruieren, was er getan hat. Bei einer Automatisierung müssen Sie das Protokoll fragen, und das Protokoll ist oft nicht da, wo Sie es brauchen.
Bei dem Rechnungsfall hatten wir Glück. Der Workflow lief über Make, und die Ausführungshistorie zeigte pro Durchlauf, welche Empfängeradresse mit welcher Rechnung kombiniert worden war. Wir konnten in zwei Stunden eine exakte Liste erstellen: wer was bekommen hatte, 300 Zeilen, sauber. Diese Liste war die Grundlage für die Meldung und für die Information der Betroffenen.
Der Punkt ist: Diese Liste gab es nur, weil die Ausführungshistorie eingeschaltet und lang genug aufbewahrt war. Bei einem anderen Kunden hätten wir denselben Vorfall nicht rekonstruieren können, weil dort die Logs nach 24 Stunden gelöscht wurden und der Fehler erst nach dem Wochenende auffiel. Ohne Protokoll bleibt bei einer Meldung nur die ehrliche, schwache Formulierung: "Betroffen sind vermutlich alle Empfänger des Laufs, die genaue Zuordnung ist uns nicht möglich." Das ist der Satz, den Sie einer Aufsichtsbehörde nicht schreiben wollen.
Was vorher da sein muss
Eine Datenpanne verhindert man nicht mit Vorsätzen, sondern mit drei Dingen, die vor dem Ernstfall existieren müssen.
Ein Not-Aus für jeden Workflow, der nach außen kommuniziert. Wenn der Fehlversand um 3 Uhr nachts startet, wollen Sie ihn um 3:05 Uhr stoppen können, ohne den Anbieter-Support zu brauchen. Ein Schalter, der den Workflow deaktiviert, gehört bei jedem sendenden Prozess zur Grundausstattung.
Eine Ausführungshistorie, die lange genug lebt, um einen Vorfall vom Freitag am Montag noch zu rekonstruieren. Für die Fehlersuche reichen ein paar Tage, für die Nachweispflicht bei Pannen sollten es eher zwei bis vier Wochen sein. Das ist die eine Stelle, an der längere Log-Aufbewahrung dem Datenschutz nützt statt schadet, solange die Logs selbst geschützt liegen.
Eine klare Zuständigkeit, wer im Ernstfall die Uhr startet. Die 72 Stunden laufen ab Bekanntwerden, nicht ab dem Moment, in dem sich das Team einig ist. Es muss vorher feststehen, wer den oder die Datenschutzbeauftragte anruft und wer entscheidet, ob gemeldet wird. Diese Rolle im Vorfall zu klären kostet zehn Minuten. Sie im Vorfall nicht geklärt zu haben, kostet einen halben Tag Panik.
Der kleine Betrieb trifft es genauso
Ein Zwischengedanke, weil sich viele in Sicherheit wiegen: Das betrifft nicht nur große Versender. Eine Physiotherapie-Praxis mit sechs Angestellten hatte eine simple Automatisierung, die Terminerinnerungen per SMS verschickte. Nach einem Update beim SMS-Anbieter rutschten die Telefonnummern um eine Position, und die Erinnerung "Ihr Termin bei der Physiotherapie am Donnerstag" ging an die jeweils falsche Person. Gesundheitsbezug, kleine Zahl, trotzdem meldepflichtig und heikel.
Die Größe des Unternehmens ändert nichts an der Frist. Sie ändert nur, ob jemand da ist, der weiß, was jetzt zu tun ist.
Melden ist unangenehm, Verschweigen ist teurer
Die Versuchung, eine kleine Panne unter den Teppich zu kehren, ist groß. Vielleicht beschwert sich ja niemand. Vielleicht fällt es nicht auf. Aus der Praxis: Es fällt auf, oft Wochen später, wenn ein Empfänger die fremde Rechnung an den falschen Absender zurückschickt und plötzlich zwei Kunden voneinander wissen.
Eine verspätete oder unterlassene Meldung wiegt bei den Aufsichtsbehörden deutlich schwerer als der ursprüngliche Fehler. Eine fristgerechte, ehrliche Meldung mit sauberer Betroffenenliste und der Aussage "wir haben den Workflow gestoppt und folgende Maßnahmen ergriffen" ist ein beherrschbarer Vorgang. Dieselbe Panne, drei Monate später durch eine Beschwerde ans Licht gekommen und ohne rekonstruierbare Datenlage, ist ein Fall, der teuer wird.
Wir raten Kunden deshalb zur unbequemen Variante: im Zweifel melden, sauber dokumentieren, Betroffene informieren. Nicht weil es angenehm ist, sondern weil die Alternative im Ernstfall schlechter altert.
Was wir daraus gelernt haben
Die meisten Datenschutzdiskussionen rund um Automatisierung drehen sich um die Frage, ob man Daten in ein Tool geben darf. Die praktisch relevantere Frage ist: Was passiert, wenn das Tool genau das tut, was Sie eingestellt haben, und die Einstellung war falsch?
Automatisierung entfernt den Menschen aus der Schleife, der sonst gestutzt hätte. Damit verschwindet die letzte Kontrolle vor dem Versand. Wer sendende Workflows baut, baut eine Maschine, die Fehler schneller und vollständiger ausführt als jeder Mensch. Das ist der Sinn der Sache, und es ist zugleich das Risiko.
Der beste Zeitpunkt, sich zu überlegen, wie man eine Panne stoppt und rekonstruiert, ist der Tag, an dem der Workflow gebaut wird. Der schlechteste ist der Dienstagmorgen, an dem die Buchhalterin anruft und die Uhr schon läuft.