Datenpannen und deren fristgerechter Umgang im Spannungsfeld zwischen IT und rechtlichen Anforderungen

PrintMailRate-it

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 Fehler­kultur.


 


Die zentralen Vorschriften zum Umgang mit Datenpannen sind in Art. 33 DSGVO und in Art. 34 DSGVO ausge­fü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 personenbe­zogener 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üf­schri­tten zu erfolgen hat, welche unter Umständen letztlich zu einer Meldung bei der zuständigen Aufsichts­behö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 ge­wor­den“ 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:


1. Informations- bzw. Kommunikationsschwächen

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 Da­tenschutz bemerkbar.


a) Interne Hinweise durch User/ Mitarbeitende

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.


b) Hinweise seitens Auftragsverarbeiter/gemeinsam Verantwortliche

Beispiel: Im Rahmen eines IT-Projekts werden umfassende Tests vorgenommen. Dabei sind die Tests mit fin­gierten, 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 nach­gekommen, hat aber auch die Möglichkeit, den Sachverhalt der Aufsicht zu melden.


c) Meldungen durch Betroffen

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.


2. Kontroll- bzw. Monitoring-Schwächen

Die Effizienz und Effektivität von Kontrollen hängen auch von der Zielsetzung ab. Und oft sind die eingerich­teten Kontrollen nicht so ausgerichtet, dass sie auch dem Datenschutz zuarbeiten.


a) Kenntniserlangung von unwirksamen Berechtigungskonzepten

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 Rechte­vergaben 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.


b) Dokumentation erfolgter Zugriffe in Log-Files

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 kapazi­tativen Engpässen wurde die regelmäßige und zeitnahe Analyse der Log-Files vernachlässigt. So konnten da­ten­schutzrelevante Sachverhalte – wie die Bereitstellung von Daten in „falschen“ Abteilungen - nicht zeitnah erkannt, aber nachweisbar dokumentiert werden.


c) Hinweise auf kompromittierte Endgeräte

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.


Der Lösungsansatz ist dabei aufgrund der obigen Struktur der Szenarien schon erkennbar

  1. Es bietet sich förmlich an, den Erkennungs- und Meldeprozess für potenzielle Datenpannen auch in Bezug auf die typischen Anlaufstellen (Helpdesk, Eingangskanäle wie Empfang, etc.) klar zu dokumentieren und innerhalb der Schulung/Unterweisung den Mitarbeitenden zu kommunizieren.
  2. Zudem ist es wesentlich, im Sinne eines Internen Kontrollsystems (IKS) auf die Relevanz von Datenschutz­verletzungen – und in diesem Zusammenhang auch der Informationssicherheit – deutlich einzugehen und beim Aufbau von Kontrollen auch die Pflicht aus der DSGVO aufzugreifen, nämlich auch potenzielle Risiken für die Betroffenen in den Prozessen „mitzudenken“.

Kontakt

Contact Person Picture

Hannes Hahn

CISA - CSP - DSB, IT-Auditor IDW

Partner, Rödl IT Secure GmbH

+49 221 9499 092 00

Anfrage senden

Contact Person Picture

Werner Merl

Dipl.-Wirtsch.-Ing., Prokurist

Associate Partner

+49 6196 7611 4711

Anfrage senden

Unternehmer­briefing

Kein Themen­special verpas­sen mit unserem Newsletter!

Befehle des Menübands überspringen
Zum Hauptinhalt wechseln
Deutschland Weltweit Search Menu