72 Stunden bei einer Datenpanne: wohin die Zeit auf der Softwareseite geht

Die Meldung einer Datenpanne wird meist als rechtlicher Vorgang beschrieben. Wie viel von dieser Frist verloren geht, entscheidet aber, wie das System Monate vor dem Vorfall entworfen wurde.

Ein Alarm erreicht am Montagmorgen den Tisch einer Organisation: Auf einem Server wurde ein ungewöhnlicher Zugriff festgestellt. Von diesem Moment an läuft die Zweiundsiebzig-Stunden-Uhr.

Zweiundsiebzig Stunden klingen nach viel Zeit. Im Folgenden wird stundenweise nachgezeichnet, wohin diese Zeit tatsächlich verstreicht, denn ohne diese Aufschlüsselung ist schwer zu verstehen, warum die Vorbereitung auf eine Datenschutzverletzung Monate vorher erfolgen muss, nicht während sie läuft.

Die ersten acht Stunden: Handelt es sich wirklich um eine Verletzung?

Die erste Aufgabe besteht darin, festzustellen, ob der Alarm real ist. Es könnte ein Fehlalarm, eine Wartungsarbeit oder eine falsch konfigurierte Berechtigung sein.

In dieser Phase prüft das technische Team die Protokolle. Sind die Protokolle nicht gut genug, und in den meisten Organisationen sind sie es nicht, zieht sich das in die Länge. Ohne zu wissen, welches Konto von welcher Adresse auf welche Tabelle zugegriffen hat, lässt sich kein weiterer Schritt unternehmen.

Der erste kritische Punkt liegt hier. Wer keine Protokolle führt, dem läuft die Uhr genau hier ab, und diese Zeit ist nie wieder zurückzugewinnen.

Die nächsten vierundzwanzig Stunden: Welche Daten waren betroffen

Steht fest, dass es sich um eine Datenschutzverletzung handelt, stellt sich eine einzige Frage. Welche personenbezogenen Daten befanden sich auf diesem Server?

Eine Organisation mit einem aktuellen Verzeichnis beantwortet das in zehn Minuten. Eine ohne versucht es herauszufinden, indem sie das Datenbankschema durchsieht, Tabellennamen prüft, Beispieldatensätze zieht, Entwickler befragt. Allein das kann leicht einen ganzen Tag dauern.

Die zweite Hälfte der Frage ist schwieriger. Was befindet sich in den Backups? Gibt es eine Kopie, die für einen Bericht exportiert wurde? Wurde ein Muster in eine Testumgebung geladen? Sind die Antworten nirgends schriftlich festgehalten, landet man bei Vermutungen, und eine auf Vermutungen basierende Meldung muss später korrigiert werden.

Die nächsten zwölf Stunden: Wie viele Personen sind betroffen

Ist der Umfang eingegrenzt, muss eine Zahl ermittelt werden. Wie viele betroffene Personen, welche Datenkategorien, welche geografischen Regionen.

Ein häufiger Fehler ist hier das Runden der Zahl. "Ungefähr zehntausend Personen" zu sagen, führt nicht zur Ablehnung der Meldung, aber wenn später eine deutlich abweichende tatsächliche Zahl auftaucht, schadet das der Glaubwürdigkeit der Angaben der Organisation. Lässt sich keine genaue Zahl ermitteln, sollte man das so sagen und begründen, anstatt eine zu erraten.

Die verbleibende Zeit: Meldung vorbereiten und einreichen

Die Meldung an die Behörde muss abdecken, wann und wie die Datenschutzverletzung geschah, welche Datenkategorien betroffen waren, ihre möglichen Folgen sowie die ergriffenen und geplanten Maßnahmen.

Das von einer leeren Seite aus zu verfassen, verbraucht die verbleibende Zeit. Eine Organisation mit fertiger Vorlage füllt sie in einer halben Stunde aus. Wer zur Unterzeichnung befugt ist, sollte ebenfalls im Voraus geklärt sein, denn beginnt diese Diskussion erst in dieser Phase, bleibt keine Zeit dafür.

Die Benachrichtigung der betroffenen Personen ist eine eigene Aufgabe. Sie erfolgt so bald wie vernünftigerweise möglich, sobald die betroffenen Personen identifiziert sind; ist eine direkte Kontaktaufnahme nicht möglich, wird ein anderes geeignetes Mittel genutzt. Die Sprache ist hier wichtig. Eine in technischen Details vergrabene Nachricht verhindert, dass die Person versteht, was sie tatsächlich tun muss.

Was der Plan wirklich enthalten muss

Die Lehre aus diesem Durchgang lautet: Der Wert eines Notfallplans liegt darin, im Voraus durchdacht zu haben, was im Moment des Vorfalls durchdacht werden müsste.

Er braucht eine klare Rollenverteilung. Wer grenzt den Vorfall ein, wer entscheidet, dass es sich um eine Datenschutzverletzung handelt, wer unterzeichnet. Ein Plan, der von einer einzigen Person abhängt, bricht an dem Tag zusammen, an dem diese Person nicht verfügbar ist.

Er braucht eine definierte Schwelle. Was als Datenschutzverletzung gilt, muss vorab schriftlich festgelegt sein, sonst findet diese Diskussion innerhalb der zweiundsiebzig Stunden statt.

Er braucht eine Regel zur Beweissicherung. Der erste Instinkt ist oft, betroffene Systeme zu bereinigen, was eine ordentliche Untersuchung unmöglich macht. Der Plan muss ausdrücklich festlegen, dass Protokolle unangetastet erhalten bleiben.

Er braucht bereits vorbereitete Kommunikationsvorlagen, sowohl für die Behörde als auch für die betroffenen Personen.

Mit dem Absenden der Meldung ist nichts beendet

Die Meldung ist nicht das Ende der Pflicht. Die Behörde bewertet, ob die getroffenen technischen und organisatorischen Maßnahmen ausreichend waren.

Eine sich in derselben Organisation wiederholende Datenschutzverletzung wird als Beweis dafür gewertet, dass diese Maßnahmen nicht ausreichten. Deshalb müssen die nach einer Datenschutzverletzung ergriffenen Korrekturmaßnahmen dokumentiert und ihre Wirkung gemessen werden. Der Satz "die erforderlichen Maßnahmen wurden ergriffen" ist für sich genommen kein Beweis für irgendetwas.

Das Einzige, was sich heute zu tun lohnt

Das Wirtschaftlichste, was man vor einer Datenschutzverletzung tun kann, ist, das Verzeichnis zusammen mit dem physischen Speicherort der Daten zu erstellen: welche Datenbank, welche Tabelle, welches Feld und welches Backup welche Daten enthält.

Existiert diese Tabelle, sind damit faktisch die ersten rund dreißig der zweiundsiebzig Stunden zurückgewonnen. Existiert sie nicht, reicht die Zeit nicht, so gut der Plan auch formuliert ist.