KVKK-konforme Software: mit dem Dateninventar beginnen

Organisationen kommen oft mit dem Wunsch nach einer KVKK-konformen Software zu uns. Um zu sehen, wo diese Konformität im Code beginnt, muss man zuerst auf das Inventar schauen. Denn ohne zu wissen, welche Daten wo liegen, lassen sich weder Zugriffsregeln noch Aufbewahrungsfristen richtig aufsetzen.

Geht man zu einer Organisation für eine KVKK-Konformitätsarbeit, findet man meist Folgendes vor. Einen Datenschutzhinweis, ein Formular für die ausdrückliche Einwilligung, eine Aufbewahrungs- und Vernichtungsrichtlinie. Alle drei sind erstellt, unterschrieben und abgeheftet.

Dann wird eine einzige Frage gestellt. Woher stammen die in diesen Texten genannten Datenkategorien?

Die Antwort lautet meist so. Ein im Internet gefundenes Muster wurde übernommen, der Name der Organisation eingesetzt, ein paar Punkte hinzugefügt. Das heißt, die Erklärung stammt nicht aus der Feststellung der Tatsachen, sondern aus einer Vorlage. Das ist der häufigste und teuerste Reihenfolgefehler, den ich in Konformitätsarbeiten sehe.

Warum die Reihenfolge so wichtig ist

Der Datenschutzhinweis ist eine Erklärung. Artikel 10 des Gesetzes verlangt, dass der Verantwortliche die verarbeiteten Datenkategorien, Zwecke, die Empfänger, an die übermittelt wird, und die Rechtsgrundlage mitteilt. Geben Sie eine Erklärung ab, muss diese Erklärung zutreffend sein.

Ein ohne Verzeichnis geschriebener Text kann nicht zutreffend sein. Bestenfalls ist er unvollständig. Wird bei einer Prüfung eine im Text nicht genannte Verarbeitungstätigkeit festgestellt, liegt nicht nur eine technische Lücke vor, sondern eine nicht ordnungsgemäß erfüllte Informationspflicht.

Das Umgekehrte gilt ebenso. Eine Organisation mit vorhandenem Verzeichnis schreibt den Datenschutzhinweis an einem Tag, weil alles, was zu schreiben ist, bereits feststeht.

Wonach im Verzeichnis wirklich gesucht wird

Die Verzeichnistabelle wird meist mit den Spalten Datenkategorie, Zweck und Aufbewahrungsfrist erstellt. Diese drei Spalten reichen nicht.

Die fehlende Spalte lautet: Wo befindet sich dieses Datum physisch? In welcher Datenbank, welcher Tabelle, welchem Feld? Existiert es auch in Backups? Gibt es eine Kopie im System eines Drittanbieters?

Wird diese Frage nicht gestellt, spiegelt das Verzeichnis die Selbsteinschätzung der Organisation wider, nicht die Realität. Kommt es zu einer Datenschutzverletzung, wird die erste Frage lauten: "Welche personenbezogenen Daten befanden sich auf diesem Server." Ein Verzeichnis ohne physische Verortung ist in diesem Moment nutzlos.

Die Wahl der Rechtsgrundlage ist eine architektonische Entscheidung

Artikel 5 des Gesetzes zählt die Verarbeitungsbedingungen auf. In der Praxis wird dieser Artikel oft als Formsache betrachtet, dabei bestimmt die gewählte Rechtsgrundlage unmittelbar, wie das System aufgebaut werden muss.

Bei einer auf ausdrücklicher Einwilligung beruhenden Verarbeitungstätigkeit kann die Einwilligung jederzeit widerrufen werden. Im Moment des Widerrufs muss die Verarbeitung eingestellt werden. Das erfordert im System drei Dinge. Eine Aufzeichnung, zu welcher Textversion die Einwilligung erteilt wurde, eine Oberfläche, die dem Nutzer den Widerruf ermöglicht, und eine Kontrolle, die die betreffende Verarbeitung bei Widerruf stoppt. Fehlt eines von diesen dreien, bringt die Berufung auf Einwilligung die Organisation in eine unhaltbare Position.

Demgegenüber erfordert eine für die Vertragserfüllung notwendige Verarbeitung diese Mechanismen nicht. Dasselbe Datum, mit unterschiedlicher Rechtsgrundlage verarbeitet, erzeugt eine völlig andere technische Last. Deshalb sollte die Wahl der Rechtsgrundlage nicht vom Anwalt allein, losgelöst von der Architektur, getroffen werden.

Aufbewahrungsfrist und die sie umsetzende Komponente

Eine Aufbewahrungsfrist festzulegen, ist der leichteste Teil der Konformitätsarbeit. Ihre Umsetzung sicherzustellen, ist der schwerste Teil.

Eine funktionierende Konstruktion sieht so aus. Jeder Datensatz trägt seine eigene Aufbewahrungsfrist, etwa ein Feld aufbewahrung_ende. Ein Vorgang durchsucht regelmäßig Datensätze mit abgelaufener Frist. Der Vorgang löscht, vernichtet oder anonymisiert den Datensatz und trägt die durchgeführte Maßnahme in eine gesonderte Tabelle ein. Was bei einer Prüfung vorgelegt wird, ist nicht der Richtlinientext, sondern diese Tabelle.

Organisationen, die diese Struktur nicht aufbauen, tun meist Folgendes. Sie schreiben die Frist in die Richtlinie, verschieben die Umsetzung auf ein späteres Datum, und dieses Datum kommt nie. Nach zwei Jahren liegen nicht gelöschte Daten und ein Dokument vor, das besagt, sie hätten gelöscht werden müssen. Dass beides gleichzeitig existiert, ist schlimmer, als gar keine Richtlinie geschrieben zu haben.

VERBİS und die Frage des Anwendungsbereichs

Die Registrierungspflicht im Register der Verantwortlichen unterliegt von der Behörde festgelegten Kriterien. Die jährliche Beschäftigtenzahl, die Größe der Bilanzsumme und die Art der verarbeiteten Daten sind maßgeblich.

Hier ist ein Hinweis nötig. Der Umfang der Befreiung hat sich durch Entscheidungen der Behörde im Laufe der Zeit geändert und kann sich weiter ändern. Eine heute befreite Organisation wird bei steigender Beschäftigtenzahl registrierungspflichtig. Deshalb ist die Befreiung kein Thema, das einmal festgestellt und dann vergessen wird, sondern muss jährlich überprüft werden. Für die aktuellen Schwellenwerte sind die von der Behörde veröffentlichten Bekanntmachungen heranzuziehen.

Der Notfallplan wird im Voraus geschrieben

Absatz fünf von Artikel 12 des Gesetzes verlangt, dass die Verletzung so schnell wie möglich an die Behörde gemeldet wird. Entscheidungen der Behörde haben diese Frist auf zweiundsiebzig Stunden konkretisiert.

Zweiundsiebzig Stunden sind die Gesamtzeit, die nach Erkennen des Vorfalls zur Verfügung steht, um den Umfang festzustellen, die betroffenen Personen zu bestimmen und die Meldung vorzubereiten. Schon der erste dieser Schritte dauert in den meisten Organisationen Tage, weil nicht schriftlich festgehalten ist, welche Daten wo gespeichert sind.

Das heißt, die Vorbereitung auf eine Verletzung beginnt lange vor der Verletzung und führt wieder zum selben Punkt. Zum Verzeichnis.

Was geschieht, wenn die Konformität abgeschlossen ist

Sie endet nicht. Ein neues Feature erzeugt ein neues Datenfeld. Ein neuer Anbieter erzeugt eine neue Übermittlung. Entscheidungen der Behörde verengen den Rahmen.

Deshalb sollte Konformität nicht als Projekt konzipiert werden, sondern in den Produktentwicklungsprozess selbst eingebettet werden. Wird die Aktualisierung des Verzeichnisses beim Hinzufügen eines neuen Feldes Teil der Codeüberprüfung, trägt sich der Prozess von selbst. Andernfalls beginnt man jedes Jahr von vorn, und derselbe Reihenfolgefehler wiederholt sich jedes Mal.