Home
Intern
veröffentlicht am 18. Mai 2022 | Lesedauer ca. 3 Minuten
Der richtige Umgang mit Datenpannen setzt deren sichere Erkennung voraus. Dabei ist der entsprechende Meldeprozess sowie die Ausrichtung des internen Kontrollsystems auch auf den Datenschutz ein Schlüssel – einschließlich einer entsprechenden Fehlerkultur.
Die zentralen Vorschriften zum Umgang mit Datenpannen sind in Art. 33 DSGVO und in Art. 34 DSGVO ausgeführt. Die Meldung von Verletzungen des Schutzes personenbezogener Daten an die Aufsichtsbehörde ist in Art. 33 DSGVO geregelt und die Benachrichtigungspflicht der von einer Verletzung des Schutzes personenbezogener Daten betroffenen Person ist in Art. 34 DSGVO statuiert.Weitere Informationen zum generellen Umgang mit Datenschutzverletzungen finden sich im Artikel „Datenschutzrechtliche Compliance beim Umgang mit Datenpannen | Rödl & Partner (roedl.de)“.Artikel 33 DSGVO führt aus, dass bei einer Verletzung des Datenschutzes, umgehend eine Reihe an Prüfschritten zu erfolgen hat, welche unter Umständen letztlich zu einer Meldung bei der zuständigen Aufsichtsbehörde führen können. Dabei ist entscheidend, dass die Meldung binnen 72 Stunden zu erfolgen hat. Eine Frist, die Einzuhalten gerade an Sonn- und Feiertagen schwierig werden kann.
Im Hinblick auf die Risiken für den Verantwortlichen stellt sich die Frage, ab wann der Zustand „bekannt geworden“ tatsächlich greift. Folgende zwei generelle Szenarien gerade im Zusammenspiel mit IT können dabei einen Eindruck verschaffen, welche Besonderheiten zur Einhaltung der Pflicht zu beachten sind:
Informierte und sensible Mitarbeitende sind die Stärke in jedem Managementsystem – so auch im Datenschutz. Noch stärker ist das Managementsystem, wenn aus entstandenen Fehlern nicht Strafen folgen, sondern die offene Kommunikation zu einer Verbesserung führt. Die berühmte „Fehlerkultur“ macht sich besonders im Datenschutz bemerkbar.
Beispiel: Beim Helpdesk gehen Meldungen ein, dass in Systemen, welche für die Zusammenarbeit mit Dritten genutzt werden, Zugriffe falsch eingerichtet wurden. Der Helpdesk betrachtet die Meldung rein technisch und korrigiert die Zugriffe. Ob ggf. durch die potenzielle Zugriffsmöglichkeit eine Datenschutzverletzung begangen wurde, wird nicht weiterverfolgt. Diese Vorgehensweise ist nicht ohne Risiko, denn jene Person, welche den unberechtigten Zugriff hatte, kann diesen Mangel ggf. selbst an die Aufsicht melden.
Beispiel: Im Rahmen eines IT-Projekts werden umfassende Tests vorgenommen. Dabei sind die Tests mit fingierten, nicht realen Daten unterlegt. Im Laufe verschiedener Tests fällt einem mit der Durchführung der Tests beauftragten Fremddienstleister auf, dass dieser auch auf Echt-Daten aus einem ganz anderen Projekt Zugriff hat. Die zuständigen internen Projektteilnehmer korrigieren den Fehler umgehend, betrachten es aber nicht als Datenschutzverletzung. Offiziell ist der Auftragsverarbeiter seiner Pflicht zur Meldung und Mitwirkung nachgekommen, hat aber auch die Möglichkeit, den Sachverhalt der Aufsicht zu melden.
Beispiel: Vereinzelte dritte natürliche Personen haben Post mit fremdem Inhalt aus einem hoch automatisierten Druck- und Versandprozess erhalten und informieren das Unternehmen über den zentralen Empfang bzw. die Poststelle. Diese entschuldigt sich für den Vorfall und bittet um Rücksendung, belässt es aber lediglich bei der Maßnahme, obwohl ggf. ein größerer Schaden nicht auszuschließen wäre. Auch hier steht es den Dritten offen, die Aufsicht zu informieren.
Die Effizienz und Effektivität von Kontrollen hängen auch von der Zielsetzung ab. Und oft sind die eingerichteten Kontrollen nicht so ausgerichtet, dass sie auch dem Datenschutz zuarbeiten.
Beispiel: Durch Hinweise seitens der Anwender wurde deutlich, dass der Prozess der Pflege von Zugriffsrechten sowie die Vergabe der Rechte an die Anwender gerade in einem System, welches auch von Dritten verwendet wird (kollaboratives System) fehlerbehaftet ist. Der Prozess wurde neu „designt“ und die fehlerhaften Rechtevergaben korrigiert. Ob es in diesem Rahmen zu Datenschutzverletzungen gekommen ist, wurde jedoch nicht weiterverfolgt. Auch wurden die fehlerhaften Kontrollen, welche den Zustand bis dahin nicht erkannt haben, nicht korrigiert.
Beispiel: Im Rahmen von ausgelagerten Prozessen wurden zum Zeitpunkt der Konzeption und Produktivsetzung auch zur Überprüfung der Ordnungsmäßigkeit diverse Log-Files angelegt, in welchen Transaktionen (Zugriff, Änderung, Löschung) und besondere Vorfälle (Rechtevergabe, etc.) festgehalten werden. Aufgrund von kapazitativen Engpässen wurde die regelmäßige und zeitnahe Analyse der Log-Files vernachlässigt. So konnten datenschutzrelevante Sachverhalte – wie die Bereitstellung von Daten in „falschen“ Abteilungen - nicht zeitnah erkannt, aber nachweisbar dokumentiert werden.
Beispiel: Aufgrund von Sicherheitsinstrumenten (Virenscanner, Indicator-of-Compromise-Scanner, etc.) wurde ermittelt, dass ein Notebook auffällig ist. Die Reaktion hierauf war, den Rechner neu aufzusetzen. Ob dieses Notebook bzw. der Account des Users schon erfolgreich angegriffen wurde bzw. ob auf dem Rechner Spuren von Hacking vorlagen, wurde nicht weiter untersucht.
Werner Merl
Dipl.-Wirtsch.-Ing., Prokurist
Associate Partner
Anfrage senden
Falk Hofmann
ISO/IEC27001/KRITIS -Auditor
Partner
Datenschutzrechtliche Compliance beim Umgang mit Datenpannen
Kein Themenspecial verpassen mit unserem Newsletter!