06

Kernpunkte:

  • Dokumentation von IT-Verfahren
  • Standard-Datenschutzmodell V2
  • Abschätzen des Datenschutzrisikos 

 

6    Systemdatenschutz

6.1          Fokus Schleswig-Holstein

6.1.1       Zusammenarbeit mit dem Zentralen IT-Management (ZIT SH)

Wie in den Vorjahren war das ULD Gast bei den Sitzungen der ITBK (IT-Beauftragten-Konferenz), bei der die IT-Beauftragten der Ressorts zusammen mit dem ZIT SH die zentralen und dezentralen IT-Entwicklungen planen sowie Entscheidungen von ressortübergreifender Bedeutung treffen. Durch die Teilnahme wird das ULD über diese Entwicklungen informiert und kann auf datenschutzrechtliche Fallstricke hinweisen oder Empfehlungen zur technisch-organisatorischen Realisierung geben.

Zusätzlich wurde das ULD über einzelne IT-Vorhaben der Ressorts, die eine besondere Bedeutung oder eine große Reichweite haben, direkt durch das ZIT SH informiert.

Die Tendenz zur Zentralisierung von IT-Verfahren setzt sich weiter fort. Dies betrifft in erster Linie das Management der Standard-IT-Verfahren (z. B. für die Bürokommunikation) und die zentrale Bereitstellung von Fachverfahren und Diensten. Eine weitere Rolle spielt die Zentralisierung einzelner Verwaltungstätigkeiten bei gleichzeitig dezentraler Zuarbeit. Ein Beispiel hierfür ist der geplante Prozess der Genehmigung und Abrechnung von Dienstreisen, die nämlich dezentral genehmigt und zentral abgerechnet werden sollen. In einer papierbasierten Welt würden bei solchen Prozessen Schriftstücke zwischen Dienststellen ausgetauscht; in der digitalen Welt werden üblicherweise Plattformen oder Portale verwendet. In dem geschilderten Prozess besteht die Herausforderung darin, dass für die Genehmigungsprozesse in zahlreichen Dienststellen nahezu alle Beschäftigten einschließlich ihrer Vorgesetzten an die Plattform anzubinden wären, die ihrerseits wegen der Sensibilität der Daten und der unmittelbaren finanziellen Auswirkungen bei der Abrechnung besonders zu sichern ist. Dies ist nicht immer einfach, insbesondere wenn Beschäftigte keinen PC-Arbeitsplatz im Landesnetz haben.

Eine zentrale Bereitstellung von Verfahren und Diensten kann Vorteile für einen datenschutzgerechten Betrieb haben, weil die personellen Kapazitäten für die datenschutzgerechte Auswahl und Gestaltung konzentriert werden können. In der Praxis zeigen sich dann aber Probleme, wenn Anbieter von Lösungen oder Softwareprodukten nicht die Besonderheiten der Verwaltung in einer verteilten Umgebung berücksichtigen (können) – eine formelle Behördenhierarchie mit Dienst- und Fachaufsicht ist eben nicht damit gleichbedeutend, dass übergeordnete Behörden stets Zugriffsrechte auf sämtliche Unterlagen der nachgeordneten Behörden haben oder gar in deren Berechtigungsmanagement eingreifen.

 

6.1.2       Dokumentation von IT-Verfahren

Die Datenschutz-Grundverordnung erfordert von Verantwortlichen den Nachweis, dass die Verarbeitung personenbezogener Daten gemäß den rechtlichen Vorgaben erfolgt (Rechenschaftspflicht, Art. 5 Abs. 2 DSGVO). Eine Standardmaßnahme des Nachweises ist die Dokumentation der Verarbeitung.

In Artikel 30 DSGVO ist festgelegt, dass Verantwortliche ein Verzeichnis der Verarbeitungstätigkeiten zu führen haben. Auch der (Mindest-) Inhalt ist dort festgeschrieben. Allerdings sind die dort verwendeten Begriffe hinsichtlich Art und Detaillierungstiefe interpretierbar, sodass Muster und Vorlagen bei den Aufsichtsbehörden nachgefragt werden.

Das ULD stellt auf seiner Webseite ein Muster für ein solches Verzeichnis sowie weitere Unterlagen zur Verfügung, die Verantwortliche bei der Zusammenstellung der Informationen in ihren Organisationen unterstützen (37. TB, Tz. 6.1.3): Eine der Herausforderungen der Praxis besteht nämlich darin, das an vielen Stellen (z. B. Fachabteilung, Organisationsabteilung, IT-Bereich) verteilte Wissen zusammenzuführen und passend zu den Anforderungen der DSGVO zu dokumentieren.

Nur ein Teil dieser Informationen fließt unmittelbar in das Verzeichnis der Verarbeitungstätigkeiten gemäß DSGVO. Viele weitere Aspekte sind ebenfalls zu dokumentieren: etwa die Rechtsgrundlagen der Verarbeitung, der Umgang mit zu löschenden bzw. zu archivierenden Daten bis hin zu technischen Details wie Hardware, Vernetzung oder Betriebssystemen. Hierbei ist der Verantwortliche in der Wahl des Dokumentationsformats frei.

Bei einer initialen Erhebung ist es sinnvoll, auch diese Informationen sofort strukturiert zu erfassen und dann in weiteren Dokumenten abzulegen. Die Herausforderung besteht darin, durch geschickte Verweisungen Dopplungen zu vermeiden, denn anderenfalls lassen sich die Dokumente nur mit großem Aufwand aktuell halten. Dazu dienen u. a. die vorgestellten Dokumentationsmuster. Im Berichtszeitraum gab es dazu mehrere Schulungen und Workshops mit öffentlichen Stellen sowie Prüferinnen und Prüfern, die positive Rückmeldungen über die Brauchbarkeit der Vorlagen gaben.

Im 37. Tätigkeitsbericht wurde die Veröffentlichung von Hinweisen des ULD zur Dokumentation angekündigt, die die zum 31.12.2018 außer Kraft getretene Datenschutzverordnung Schleswig-Holstein (DSVO) ersetzen. Sie nehmen über die reine Dokumentation eines bestehenden Verfahrens auch Aspekte der Planung (Spezifikation) und der Protokollierung auf. Diese Hinweise wurden Anfang des Jahres 2020 veröffentlicht. Anders als bei einer vergleichsweise statischen Landesverordnung können diese Hinweise bei Änderungsbedarfen auch kurzfristig angepasst werden. Daher sind Kommentare zur Praktikabilität sowie Änderungsbedarfe willkommen.

https://www.datenschutzzentrum.de/dokumentation/

 

6.2          Zusammenarbeit der Datenschutzbeauftragten zu Systemdatenschutz

Im Jahr 2019 hat der Arbeitskreis Technik der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder (DSK) eine Reihe von Anwendungshinweisen publiziert, an deren Erarbeitung das ULD vielfach beteiligt war. Drei Themenbereiche sind für die Praxis von besonderer Bedeutung: Windows 10 (Tz. 6.2.1), Messenger-Dienste im Krankenhaus (Tz. 6.2.2) und das Standard-Datenschutzmodell (Tz. 6.2.3).

Neben der Zusammenarbeit auf Bundesebene ist die Kooperation auf Landesebene mit den behördlichen Datenschutzbeauftragten hervorzuheben, beispielsweise zur Durchführung von Schwellwertanalysen und von Datenschutz-Folgenabschätzungen in der Verwaltung (Tz. 6.2.4).

 

6.2.1       Das Windows-10-Prüfschema

Der Arbeitskreis Technik hat unter dem Titel „Datenschutz bei Windows 10“ ein Prüfschema für Windows 10 publiziert, das inzwischen auch von der DSK verabschiedet wurde. Das Prüfschema „soll Verantwortliche, die Windows 10 bereits einsetzen oder dies beabsichtigen, in die Lage versetzen, eigenständig die Einhaltung der rechtlichen Vorgaben der DSGVO in ihrem konkreten Fall zu prüfen und zu dokumentieren“. Adressaten des Prüfschemas sind natürliche oder juristische Personen, Behörden, Einrichtungen oder andere Stellen. Zu berücksichtigen ist, dass diejenigen Stellen, die personenbezogene Daten mithilfe von Windows 10 verarbeiten, Verantwortliche im Sinne des Datenschutzrechts sind. Aber auch Microsoft selbst ist für einige Verarbeitungen Verantwortlicher.

In diesen Hinweisen zu Windows 10 wird betont, dass zum einen ein letztlich nicht kontrollierbares Abfließen zumindest von Telemetriedaten erfolgt und zum anderen durch den Umstand, dass Updates nicht unterbunden werden können, sich die Eigenschaften eines Windows-10-Systems vollständig ändern können. Daraus folgt auch, dass eine Aussage darüber, ob Windows 10 datenschutzkonform sei, nicht pauschal getroffen werden kann.

Nach einem Überblick in Kapitel A werden in Kapitel B mit Hinweisen für die rechtliche Prüfung drei Fallgruppen bezüglich der Übermittlung personenbezogener Daten unterschieden, wobei für eine Übermittlung von Daten an Microsoft eine Rechtsgrundlage im Kontext des internationalen Datenverkehrs bereitstehen muss. Im abschließenden Kapitel C sind die sieben zu durchlaufenden Prüfschritte aufgeführt.

Zu diesem 12-seitigen Text gibt es eine Anlage, in der sowohl allgemeine technische Aspekte als auch Windows-spezifische Sachverhalte angesprochen werden. Dazu gehört ein Überblick über die verschiedenen Editionen von Windows 10 und die jeweils integrierten Funktionen und Applikationen. Ein eigener Abschnitt zu Telemetriedaten beschreibt verschiedene Stufen der Datenübermittlungen an Microsoft. Dieser Abschnitt zeigt zudem auf, welche Maßnahmen getroffen werden können, um die Übermittlung personenbezogener Daten an Microsoft einzuschränken. Im Anschluss werden die verschiedenen Updatekonzepte beschrieben, wobei zu berücksichtigen ist, dass die Mehrzahl der Windows-10-Versionen (wie z. B. Windows 10 Version 1909) nur eine begrenzte Laufzeit von 18 bis 30 Monaten hat und danach nicht mehr mit Sicherheitspatches unterstützt wird. Somit sind Verantwortliche quasi gezwungen, Funktionsupdates in kurzen Zyklen einzuspielen und die Prüfschritte erneut zu durchlaufen.

Zum Schluss finden sich Referenzen auf weitere, vor allem sicherheitstechnische Untersuchungen zu Windows 10, wie die des Bundesamts der Sicherheit in der Informationstechnik (BSI) und der niederländischen Datenschutzaufsichtsbehörde.

https://www.datenschutzkonferenz-online.de/ media/ah/20191106_win10_pruefschema_dsk.pdf [Extern]
Kurzlink: https://uldsh.de/tb38-621

 

6.2.2       Messenger-Dienste im Krankenhaus

Aufgrund der im privaten Bereich weitverbreiteten und etablierten Nutzung wird auf Messenger-Dienste zunehmend auch im Gesundheitsbereich zurückgegriffen, häufig verbunden mit der Nutzung eines privaten Endgeräts. Der berufliche oder gewerbliche Einsatz von Messenger-Diensten unterliegt gesetzlichen Datenschutzvorgaben, denen gängige Messenger-Dienste bislang nicht oder nur bedingt entsprechen. Insbesondere der vielfach genutzte Dienst WhatsApp führt bei einer geschäftlichen Nutzung zu einer Reihe von Problemen, die einen Einsatz im Krankenhaus weitgehend ausschließen. Das sieben Seiten umfassende White Paper „Technische Datenschutzanforderungen an Messenger-Dienste im Krankenhausbereich“ der DSK formuliert konkrete funktionale Anforderungen zu den Themen Messenger-Applikation, zur Sicherung der Kommunikation, zur Sicherheit der Endgeräte sowie zur Sicherung der Plattform und des Betriebs.

https://www.datenschutzkonferenz-online.de/media/oh/20191106_whitepaper_messenger_krankenhaus_dsk.pdf [Extern]
Kurzlink: https://uldsh.de/tb38-622

 

6.2.3       Standard-Datenschutzmodell V2: das SDM wird erwachsen

Die DSK hat im November 2019 das Standard-Datenschutzmodell in der Version 2.0 (SDM-V2) verabschiedet. Das SDM stellt mit einem Umfang von 68 Seiten ein Werkzeug bereit, „[…] mit dem die Auswahl und Bewertung technischer und organisatorischer Maßnahmen unterstützt wird, die sicherstellen und den Nachweis dafür erbringen, dass die Verarbeitung personenbezogener Daten nach den Vorgaben der DSGVO erfolgt“. Es ist nicht mehr wie bisher als Erprobungsfassung ausgewiesen, sondern gilt nunmehr als praxiserprobt und stabil.

Die Entwicklung des SDM begann 2012 im ULD. Bis heute besteht das Modell aus drei wesentlichen Elementen:

1. Gewährleistungsziele:

Normative Anforderungen aus dem Datenschutzrecht werden durch Gewährleistungsziele aufgenommen, die ihrerseits mit konkreten Maßnahmen hinterlegt sind. So beschreibt das Gewährleistungsziel „Intervenierbarkeit“ in SDM-V2 die Anforderung an einen Verantwortlichen, die Rechte von Betroffenen (u. a. Auskunft, Löschung, Berichtigungen, Einschränkungen) auch praktisch umsetzen zu können. Maßnahmen hierzu sind beispielsweise interne Prozesse für die Bearbeitung der Kommunikation mit Betroffenen sowie eine geeignete Gestaltung der Verfahren bis hin zu der Möglichkeit, einzelne Datenfelder oder Verarbeitungsschritte deaktivieren zu können.

2. Risikostufen:

Die Risiken, die von einer Verarbeitungstätigkeit mit personenbezogenen Daten ausgehen, werden in Stufen unterschieden. Die DSGVO gibt hier zwei Stufen vor: geringes/normales Risiko für die Rechte und Freiheiten natürlicher Personen, die grundsätzlich immer bestehen, und hohes Risiko. Diese Abstufung hilft insbesondere, um bei hohem Risiko die Schutzmaßnahmen besonders wirksam auszugestalten. So sollten Protokolldaten, die Inhaltsdaten oder Verfahren mit einem hohen Risiko betreffen, zunächst inhaltlich auf ihre Erforderlichkeit hin überprüft und dann revisionsfest und verschlüsselt gespeichert werden.

3. Daten, IT-Systeme und Prozesse:

Als dritte Komponente empfiehlt das Modell, bei personenbezogenen Verarbeitungstätigkeiten die dafür erforderlichen Daten, die dafür genutzten IT-Systeme und die darin genutzten Teilprozesse einzelner Verarbeitungsschritte zu unterscheiden. Alle Maßnahmen sollten entsprechend ihrer Risikostufe auf jeweils diese Komponenten spezifisch bezogen werden. So sollten Protokolldaten von Programmen und IT‑Systemen sowie von unterschiedlichen Teilaktivitäten eines Verfahrens (z. B. inhaltliche Verarbeitungen) für Prüfungen gespeichert werden.

Was ist in der Version V2 neu hinzugekommen?

Der Text wurde neu gegliedert, er umfasst fünf Hauptkapitel: Kapitel A weist den Zweck und den Anwendungsbereich des SDM aus, Kapitel B versammelt die wesentlichen operativen Anforderungen der DSGVO und Kapitel C bildet die über die DSGVO verstreuten normativen Anforderungen systematisch auf den sieben Gewährleistungszielen ab. Kapitel D listet generische Maßnahmen auf und erläutert darüber hinaus die Abgrenzung von Verarbeitungstätigkeiten, die Bestimmung der Risikostufe und die Struktur eines Datenschutzmanagements. Im Kapitel E wird u. a. der Bezug zum IT-Grundschutz des BSI hergestellt und das Verfahren beschrieben, mit dem Änderungen am Modell initiiert werden können.

Wesentliche Anforderungen aus der DSGVO

In Abschnitt B wurden dreiundzwanzig wesentliche operative Anforderungen zusammengetragen, die sich in der DSGVO, teils wiederholt, an verschiedenen Stellen finden. Beispielhaft sei hier das „Einwilligungsmanagement“ genannt. Es besagt, dass bei der Gestaltung einer Verarbeitung darauf zu achten ist, dass Einwilligungen einzuholen und diese zu speichern sind, dass sie dem Nachweis dienen und vor allem dass sie von den Betroffenen widerrufen werden können. Auf die Umsetzung der Anforderungen ist während der Spezifikationsphase einer Verarbeitung bzw. beim Kauf eines Fachprogramms zu achten.

Katalog generischer Maßnahmen

Der bestehende Katalog mit generischen Maßnahmen wurde um weitere Maßnahmen ergänzt. Verantwortliche sollten sich an diesen Maßnahmen orientieren und diese auf die spezifischen Umstände ihrer Verarbeitungstätigkeiten anpassen.

Die generischen Maßnahmen werden in sogenannten Bausteinen weiter erläutert und in kleinteilige Referenzmaßnahmen zerlegt. So wird beispielsweise die generische Maßnahme „Protokollierung“ im Baustein weiter spezifiziert, und es werden Teilmaßnahmen (etwa Festlegungen der zu protokollierenden Daten, Zugriffsberechtigungen, Auswertungskonzepte bis hin zur Löschung) beschrieben. Eine Unterarbeitsgruppe des AK Technik arbeitet daran, zu den bislang publizierten sieben Bausteinen, die von einigen Bundesländern sowie der Evangelischen Kirche Deutschland publiziert wurden, weitere Bausteine zu veröffentlichen.

Verarbeitungstätigkeit und Zweck

Das für die DSGVO zentrale Konzept der personenbezogenen „Verarbeitung“ oder „Verarbeitungstätigkeit“ wurde mit Bezug zum Zweck praxisnäher erläutert (siehe zur Definition die 14 Subprozesse in Art. 4 Abs. 2 DSGVO).

Wesentlicher Kern zur Beschreibung einer Verarbeitungstätigkeit ist die eng beschränkte Bestimmung des Zwecks. Mit Bezug zum Zweck sind vier Aspekte zu unterscheiden: die Zwecksetzung, die Zweckbeschreibung, die Zwecktrennung und die Zweckbindung. Die Zwecksetzung einer Verarbeitung muss legitim sein. Die Zweckbeschreibung berücksichtigt die Rechtskonformität und idealerweise die Umsetzung der Grundsätze aus Artikel 5 DSGVO. Die Ausführungen zur Zwecktrennung begegnen den absehbaren zweckändernden oder zweckdehnenden Begehrlichkeiten aus benachbarten Bereichen der Verarbeitung. Abschließend ist in Bezug zur Zweckbindung darauf zu achten, dass mit der Nutzung von IT-Komponenten die begrenzenden Eigenschaften, die Teil der Beschreibung des Zwecks und der Trennung zu anderen Zwecken sind, nicht unterlaufen werden.

Risikotypisierung

Von besonderem Wert für die Praxis sind sicher auch die Ausführungen zum „Risiko“ von Verarbeitungstätigkeiten. Hier wurden insbesondere die Ende 2018 von der DSK verabschiedeten Risikopapiere Nr. 5 („Datenschutz-Folgenabschätzung“) und Nr. 18 („Risiko“) sowie das Working Paper 248 („WP 248“) des Europäischen Datenschutzausschusses zur Datenschutz-Folgenabschätzung berücksichtigt. Im Wesentlichen formulieren die Grundsätze aus Artikel 5 der DSGVO die Risiken des Datenschutzes: Wenn die Verarbeitung diesen Grundsätzen nicht oder nicht zumindest ausreichend folgt, resultiert daraus ein Risiko. Drei Konzepte zur Erfassung und Bearbeitung von Risiken sind hervorzuheben: (a) die Typisierung der Risiken, (b) die Einschätzung der Risikohöhe und (c) die Strategie zur Risikominimierung.

(a) Risikotypisierung:

  • Risikotyp 1: Der Grundrechtseingriff wird nicht so milde, wie vom Zweck her bestimmbar, gestaltet. Dieses Risiko wird durch die Ausgestaltung der Verarbeitungstätigkeit und der Vorgaben des Datenschutzes „by Design“ und Datenschutzes „by Default“ (vgl. Artikel 25 DSGVO) primär bearbeitet.
  • Risikotyp 2: Schutzmaßnahmen zur Milderung des Grundrechtseingriffs werden gar nicht, nicht hinreichend oder falsch bestimmt, betrieben und überwacht. Dieses Risiko kann durch ein reifes Datenschutzmanagement verringert werden.
  • Risikotyp 3: Schutzmaßnahmen der IT-Sicherheit werden gar nicht, nicht hinreichend oder falsch betrieben und überwacht. Dieses Risiko kann in Zusammenarbeit mit der IT-Sicherheit verringert werden. Zu beachten ist dabei, dass die Schutzmaßnahmen der IT-Sicherheit ihrerseits datenschutzgerecht umgesetzt werden.

(b) Einschätzung der Risikohöhe:

Zur Einschätzung der Risikohöhe einer Verarbeitungstätigkeit empfiehlt das SDM-V2 eine Abfolge von vier Prüfschritten:

  • die „Muss-Liste“ für Datenschutz-Folgenabschätzungen gemäß Art. 35 Abs. 4 DSGVO,
  • die Kriterien von Art. 35 Abs. 3 DSGVO,
  • die Hinweise des Working Paper 248 zu Datenschutz-Folgenabschätzungen sowie
  • die Anhaltspunkte aus dem Erwägungsgrund 76 der DSGVO.

(c) Strategie zur Risikominimierung:

Zur Bestimmung der Schutzmaßnahmen zur Risikominimierung empfiehlt das SDM-V2 folgende Strategie: Das Risiko der Verarbeitungstätigkeit wird zunächst unter der Annahme betrachtet, dass es keinerlei Schutzmechanismen gibt – das SDM spricht vom Ausgangsrisiko, das die „reine Verarbeitungstätigkeit“, die von einer Organisation zumeist mit IT-Unterstützung betrieben wird, für die Freiheiten und Rechte betroffener Personen erzeugt. Dieses Risiko hat einen Schutzbedarf bei der betroffenen Person zur Folge, der sich aus dem Risiko der Verarbeitungstätigkeit ergibt, bevor technische und organisatorische Maßnahmen bestimmt und umgesetzt werden. Wenn sich in der Schwellwertanalyse herausstellt, dass ein normales Risiko von einer Verarbeitungstätigkeit ausgeht, ist auch der Schutzbedarf der Person normal, ein hohes Risiko erzeugt entsprechend einen hohen Schutzbedarf.

Während der Schutzbedarf der betroffenen Personen im Hinblick auf die Verarbeitungstätigkeit konstant bleibt, können die Risiken der Verarbeitungstätigkeit durch die Gestaltung der Verarbeitung und den Betrieb von Schutzmaßnahmen verringert werden. Die (Rest-)Risiken müssen so weit verringert werden, bis sich ein angemessenes Schutzniveau ergibt, das die Anforderungen der DSGVO erfüllt.

Besteht ein hoher Schutzbedarf, können zusätzliche Schutzmaßnahmen erforderlich sein. Das Modell empfiehlt folgendes Vorgehen:

  1. Es sind die Maßnahmen des Referenzmaßnahmenkatalogs umzusetzen, die bei normalem Ausgangsrisiko bzw. normalem Schutzbedarf zu ergreifen sind.
  2. Zusätzliche Maßnahmen aus dem Referenzmaßnahmenkatalog sind umzusetzen.
  3. Zusätzlich sind individuelle Maßnahmen auszuwählen, etwa bestimmte Vorgänge einer Verarbeitungstätigkeit nur auf Antrag bzw. nach einer expliziten Prüfung freizugeben und diese Tätigkeit dann im Betrieb zu überwachen.
  4. Die Wirksamkeit einer Maßnahme kann erhöht werden, indem Skalierungsmöglichkeiten genutzt werden. Ein Beispiel wäre der Betrieb dedizierter Protokollserver, die an zentraler Stelle sämtliche Protokolldaten speichern und den Zugriff durch Administratoren einschränken.
  5. Auf die getroffenen Maßnahmen können ihrerseits besonders wirksame technische und organisatorische Schutzmaßnahmen (etwa zum Schutz von Trennung, Transparenz, Integrität oder Vertraulichkeit) angewendet werden.

Datenschutzmanagement

Als Datenschutzmanagementsystem bezeichnet man das systematische und organisationsweite Zusammenspiel von Planung, Betrieb und Überwachung von Datenschutzanforderungen und Datenschutzmaßnahmen (vgl. Art. 32 Abs. 1 Buchst. d DSGVO). Es lassen sich vier Komponenten des Datenschutzmanagements identifizieren, die an das Vorgehen beim Qualitätsmanagement (sogenannter PDCA-Zyklus) angelehnt sind:

  • Plan – Es sind Schutzmaßnahmen zu bestimmen, deren Prüffähigkeit zu spezifizieren ist. Das Produkt dieser Phase ist eine Spezifikation bzw. ein Plan, oder es sind Konzepte auf Maßnahmenebene.
  • Do – Die Verarbeitungstätigkeit ist anhand der geplanten Komponenten und Aktivitäten zu gestalten, dabei sind die Schutzmaßnahmen einschließlich deren Prüfbarkeit zu implementieren. In dieser Phase werden Prüfergebnisse erzeugt.
  • Check 1 – Prüfergebnisse funktionaler Soll-Ist-Differenzen werden so aufbereitet, dass sie rechtlich beurteilt werden können.
  • Check 2 – Rechtliche Beurteilungen der funktionalen Prüfergebnisse erzeugen begründete Änderungsbedarfe.
  • Act – Aus diesen Änderungsbedarfen sind Maßnahmen zu erarbeiten und umzusetzen, sodass zyklisch wieder in die konkrete Planung von Verarbeitungstätigkeiten oder von deren gemeinsamen Infrastrukturen eingestiegen werden kann.

Die Teilprozesse „Plan“, „Do“ und „Check“ können für eine einzelne Verarbeitungstätigkeit mit einer Datenschutz-Folgenabschätzung nach Artikel 35 DSGVO weitgehend zusammenfallen. Das Umsetzen der Schutzmaßnahmen („Act“) würde auf eine positiv beendete DSFA folgen.

https://www.datenschutzzentrum.de/sdm/

https://www.datenschutzkonferenz-online.de/media/ah/20191209_sdm-methode_v2.0a.pdf [Extern]
Kurzlink: https://uldsh.de/tb38-623

 

6.2.4       Das Datenschutzrisiko systematisch abschätzen und beurteilen

2019 haben die Kommunen, Kreise und Ministerien damit begonnen, systematisch Schwellwertanalysen durchzuführen. Nach diesen Schwellwertanalysen, die für jede Verarbeitungstätigkeit obligatorisch sind, mussten in den Fällen mit einem hohen Risiko für die Rechte und Freiheiten natürlicher Personen Datenschutz-Folgenabschätzungen (DSFA) gemäß Artikel 35 DSGVO durchgeführt werden. Eine DSFA dient der Bestimmung von angemessenen Schutzmaßnahmen für eine (geplante) Verarbeitungstätigkeit. Artikel 35 DSGVO verlangt neben einem DSFA-Bericht vom Verantwortlichen auch den Nachweis über die Wirksamkeit der aufgrund des Berichts umzusetzenden Schutzmaßnahmen zur Eindämmung des Risikos.

Das ULD war an der Erarbeitung einer systematischen Vorgehensweise zur Durchführung von Schwellwertanalysen und zur methodischen Durchführung von Datenschutz-Folgenabschätzungen im Bereich der öffentlichen Verwaltungen beteiligt. Grundlegende Vorarbeiten wurden durch die DSK in Form der Kurzpapiere Nr. 5 („Datenschutz-Folgenabschätzung“) und Nr. 18 („Risiko“) sowie des Standard-Datenschutzmodells (SDM-V2) zur Bestimmung von Schutzmaßnahmen geleistet. An diesen Vorarbeiten war das ULD ebenfalls maßgeblich beteiligt.

Zusammen mit dem Zentralen IT-Management des Landes Schleswig-Holstein (ZIT SH) wurden Formulare zur Durchführung von Schwellwertanalysen für Verarbeitungstätigkeiten im Bereich der Ministerien erarbeitet. In Zusammenarbeit mit der Datenschutzbeauftragten des Kreises Stormarn wurden außerdem für die Kreise und Kommunen ein Konzept erstellt und ein Programm entwickelt, das Projektleitungen bei der vollständigen Durchführung einer DSFA unterstützt. Erprobt wurde dieses Programm im Rahmen von Datenschutz-Folgenabschätzungen für ein Bewerberportal sowie zur Durchführung von Wahlen (Kommunalwahlen bis zu EU-Wahlen) in den Kreisen Nordfriesland und Schleswig-Flensburg. Bei der DSFA für die Wahlverwaltung wurde methodisch, wie es das Kurzpapier Nr. 5 vorsieht, in vier Phasen vorgegangen. Nach der Vorbereitung folgten eine Erhebungs- und eine Durchführungsphase, die mit dem DSFA-Bericht abschloss. Aktuell befindet sich das Projekt in der Umsetzungsphase.

In der Vorbereitungsphase ist eine Verarbeitungsdokumentation (Art. 5 Abs. 2 und Art. 24 Abs. 1 DSGVO) zu erstellen. Alle zur Bewertung erforderlichen Daten sollen sich aus dieser Dokumentation und dem Verzeichnis der Verarbeitungstätigkeit (Artikel 30 DSGVO) ergeben. In dem vorliegenden Fall war das Programm zur Verwaltung von Wahlverfahren bereits kurzfristig beschafft worden – nachzuholen waren daher die Dokumentation und Beteiligung der behördlichen Datenschutzbeauftragten (Art. 38 Abs. 1 DSGVO). Für die Durchführung der Schwellwertanalyse und der DSFA wurde ein Kernteam bestehend aus einer Moderatorin/Projektmanagerin, einer Anwenderin, Vertretern der Technik und der Datenschutzbeauftragten als Beraterin (Art. 39 Abs. 1 Buchst. a DSGVO) gebildet.

In der Erhebungsphase wurden neben dem Projektteam weitere Anwenderinnen und Anwender, interessierte betriebliche Datenschutzbeauftragte, Vertreter des Rechenzentrums sowie die Wahlleitung beteiligt. Gemeinsam erhoben die Mitwirkenden die datenschutzrechtlich bedeutsamen Eigenschaften anhand der Gewährleistungsziele des Standard-Datenschutzmodells mit Bezug auf Daten, IT‑Systeme und Prozesse. Die Durchführungsphase begann mit der Schwellwertanalyse. Diese endete mit dem gemeinsamen Ergebnis, dass ein hohes Risiko der Verarbeitungstätigkeit vorliegt. Das zur Durchführung einer DSFA verwendete Programm erlaubte es zum Schluss, die Risiken der Verarbeitungstätigkeit einmal ohne Schutzmaßnahmen und einmal mit denkbaren Schutzmaßnahmen zu visualisieren, wodurch eine Priorisierung von zu treffenden Maßnahmen nahegelegt wurde („Quick Wins“).

Das Kernteam erstellte den DSFA-Bericht und übergab ihn dem Verantwortlichen mit Empfehlungen für zu treffende Maßnahmen entsprechend dem SDM. Die Aufgabe der DSFA-Projektmanagerin war damit beendet.

Offengeblieben war vor allem der Aspekt der Klärung der Verwendung von Schnittstellen zu anderen Verarbeitungstätigkeiten. Die Aufgaben der Beratung und der Revision bezüglich der Bearbeitung offener Punkte und der Umsetzung der empfohlenen Maßnahmen durch die Datenschutzbeauftragte läuft gegenwärtig.

Als Fazit zeigte es sich, dass bei der Erhebung und Beurteilung der Risiken möglichst alle an der Verarbeitung beteiligten Institutionen bzw. Fachbereiche zusammenkommen sollten. Es bedarf dann einer erfahrenen Projektleitung, die idealerweise über Kenntnisse auch zur Verarbeitungstätigkeit verfügt, um eine DSFA effektiv und effizient durchführen zu können. Ein Programm kann hier unterstützend eingesetzt werden, um für das Team die aufgedeckten Schwächen bzw. die zu mindernden Risiken nachverfolgbar zu machen und die Ergebnisse festzuhalten. Schon in dieser Phase kann dann Einvernehmen darüber hergestellt werden, in welcher Reihenfolge die zu ergreifenden Maßnahmen geplant und umgesetzt werden. Das eingesetzte Programm zur Unterstützung der Durchführung einer DSFA ist darüber hinaus so gestaltet, dass es auch die Umsetzungsphase unterstützt, deren Ergebnisse dann wiederum typischerweise von der Datenschutzbeauftragten geprüft werden.

 

Was ist zu tun?
Die öffentlichen Verwaltungen in Schleswig-Holstein sollten einen Pool an Expertinnen und Experten zur Durchführung von Datenschutz-Folgenabschätzungen bilden, von denen sich die Verantwortlichen in den Kommunen, Kreisen und Landesverwaltungen unterstützen lassen können.


6.3          Ausgewählte Ergebnisse aus Beratungen und Prüfungen

6.3.1       Zusammenarbeit mit den Spitzenorganisationen der Gewerkschaften

Wie in den Vorjahren war auch im Berichtszeitraum das ULD in die Zusammenarbeit der Landesbehörden, insbesondere des ZIT SH, mit den Spitzenorganisationen der Gewerkschaften eingebunden.

An dieser Stelle geht es zum einen um die Information der Spitzenorganisationen über gegebenenfalls mitbestimmungspflichtige Datenverarbeitungen, zum anderen um die Formulierung sogenannter 59er-Vereinbarungen auf Landesebene, durch die eine Mitbestimmung erfolgen kann.

59er-Vereinbarung
Vereinbarungen gemäß § 59 Mitbestimmungsgesetz zwischen den Spitzenorganisationen der Gewerkschaften und der zuständigen obersten Landesbehörde, die als allgemeine Mitbestimmungsregelungen über den Geschäftsbereich einer obersten Landesbehörde hinausgehen („Dienstvereinbarung auf Landesebene“).

Konkrete Fälle waren u. a. die landesweit zentralisierte Verarbeitung von Personaldaten und dort die zugrunde liegenden IT-Verfahren (KoPers, Permis-V) und ihr Zusammenspiel. Hier ging es um die Aktualisierung und Anpassung einer 59er-Vereinbarung an die tatsächlichen Gegebenheiten.

Ein weiterer Fall betraf die zentrale Organisation des IT-Managements durch das ZIT SH, das mit einem neuen IT-Verfahren die Zusammenarbeit zwischen Dienstleistern (in erster Linie Dataport), zentralen Stellen (z. B. ZIT SH), IT-Verantwortlichen der Ressorts bis hin zu IT-Verantwortlichen vor Ort steuern möchte. Im Mittelpunkt steht dabei die Kommunikation von Arbeitsaufträgen (Tickets) in einem sogenannten Ticketsystem, das den Beteiligten einen gemeinsamen Blick auf die Arbeitsaufträge und den Stand ihrer Erledigung ermöglichen soll.

Dabei stellen sich datenschutzrechtliche Fragen, etwa im Hinblick auf die Daten der handelnden Beschäftigten im IT-Bereich, deren Tätigkeiten in solchen Systemen protokolliert werden. Aber auch Daten von Nutzerinnen und Nutzern, etwa bei Fehlbedienungen von Geräten, finden ihren Weg in solche Systeme, wenn beispielsweise Fehler direkt durch die Nutzenden gemeldet werden oder Fehlerbehebungen oder Gerätetausche mit ihnen koordiniert werden. Die Herausforderung besteht darin, die technische Zusammenarbeit mehrerer Verantwortlicher zu organisieren und Auftraggebern eine Kontrolle über das Ob und Wie der Ausführung eines Auftrags zu erlauben, ohne gleichzeitig eine detaillierte Verhaltens- und Leistungskontrolle über die Beschäftigten der Auftragnehmer zu ermöglichen. Dies kann z. B. durch Beschränkungen von Einsichtsrechten oder Löschungen von nicht mehr erforderlichen Teilinformationen in Tickets erfolgen.

Ein dritter, derzeit laufender Fall betrifft die Vereinbarung zur privaten Nutzung von Internet und E-Mail am Arbeitsplatz. Hier sind keine inhaltlichen Änderungen der Verfahrensweise beim Umgang mit Missbrauchsfällen geplant, aber Anpassungen im Hinblick auf die Speicherdauer von Informationen über Internetzugriffe zu Sicherheitszwecken.

 

Was ist zu tun?
Die vertrauensvolle Zusammenarbeit mit den Spitzenorganisationen sollte fortgesetzt werden.

 

6.3.2       Transparenzportal

Zum Januar 2020 tritt im Informationszugangsgesetz (IZG-SH) eine neue Regelung in Kraft. Diese verpflichtet Landesbehörden nicht nur wie bisher, Informationen und Unterlagen auf Anfrage zugänglich zu machen, sondern diese zukünftig aktiv zu veröffentlichen. Einige Details zu den Veröffentlichungspflichten, z. B. welche Behörden verpflichtet sind und welche Art von Informationen zu veröffentlichen sind, finden sich in § 11 IZG-SH (siehe auch Tz. 12.5).

Das Zentrale IT-Management des Landes (ZIT SH) betreibt eine technische Plattform, mit der die Behörden bei ihrer Veröffentlichungspflicht unterstützt werden: das Transparenzportal. Das Portal ermöglicht eine gleichartige Bereitstellung von Informationen an einem Ort, die Durchsuchbarkeit der Informationen und auch eine gleichartige Anreicherung der Informationen durch Metadaten. So sollen beispielsweise Dokumente, die sich auf örtliche Informationen beziehen, so ergänzt werden, dass nicht nur nach Dokumentennamen, sondern auch nach Orten gesucht werden kann.

Das ULD nimmt beratend an einer Steuerungsgruppe des Projekts zum Transparenzportal teil. Aus Sicht des Datenschutzes und des Informationszugangs ist es wichtig, die gesetzlichen Beschränkungen zu beachten, d. h. insbesondere die personenbezogenen Daten sowie Betriebs- und Geschäftsgeheimnisse vom Informationszugang auszunehmen.

Dazu sind zum einen organisatorische Vorkehrungen und zum anderen technische Maßnahmen zu treffen, damit die jeweiligen Behörden die Veröffentlichungsfähigkeit ihrer Unterlagen prüfen und Teile von Informationen, die nicht zu veröffentlichen sind, mit geeigneten technischen Werkzeugen vor der Veröffentlichung schwärzen können.

Das Ministerium für Energiewende, Landwirtschaft, Umwelt, Natur und Digitalisierung (MELUND) als derzeit zuständiges Ministerium beabsichtigt, die Details in einer Verordnung (Verordnung zur Errichtung des Transparenzportals – TraPortVO) zu regeln. Das ULD wurde zu dem Verordnungsentwurf um Stellungnahme gebeten und hat insbesondere geprüft, inwieweit durch das Transparenzportal personenbezogene Daten verarbeitet werden: In diesem Fall wären der Betreiber des Portals einerseits sowie die veröffentlichenden Behörden andererseits gemeinsam für die Datenverarbeitung verantwortlich und müssten daher datenschutzrechtliche Zuständigkeiten in einer Vereinbarung gemäß Artikel 26 oder einer weiteren Rechtsverordnung regeln (siehe dazu auch Tz. 4.1.2). Eine Verarbeitung personenbezogener Daten ist im Rahmen der Veröffentlichung im Transparenzportal aber nicht geplant, sodass es sich in der zurzeit geplanten Ausgestaltung nicht um ein gemeinsames Verfahren handelt.

 

6.3.3       Gemeinsame Prüfung des Zentralen Meldedatenbestandes (ZMB) – Update

Im letzten Tätigkeitsbericht (37. TB, Tz. 6.3.3) berichteten wir über eine gemeinsame Prüfung des Zentralen Meldedatenbestandes (ZMB), die die Datenschutzbeauftragten aus Hamburg, Sachsen-Anhalt, Schleswig-Holstein und – mit Gaststatus – auch Bremen durchführten. Gegenstand dieser gemeinsamen Prüfung ist der sogenannte Mehrländer-Meldedatenspiegel (MMS), in dem auf einer technischen Plattform die (Einwohner-)Meldedaten aus den drei Bundesländern Schleswig-Holstein, Sachsen-Anhalt und Hamburg verarbeitet werden.

Die genaue Fragestellung der Prüfung ist, ob die derzeitige technische und organisatorische Ausgestaltung einen getrennten Betrieb dreier landesindividueller Länderspiegeldatenbanken darstellt oder ob nicht durch die Art der Implementierung und der Steuerung des Gesamtverfahrens faktisch ein gemeinsames Verfahren aller drei beteiligten Länder betrieben wird, das regelnder Dokumente über die Art der Zusammenarbeit bedarf.

ZMB
ZMB bezeichnet den Zentralen Meldedatenbestand, der bei Dataport als Spiegeldatei betrieben wird und der tagesaktuelle Kopien der örtlichen Meldedaten erhält. Diese können an zentraler Stelle von Verwaltungs- und Sicherheitsbehörden im Rahmen und im Umfang ihrer Aufgaben automatisiert abgefragt werden. Ebenso werden diese Daten für die einfache Melderegisterauskunft an Firmen und natürliche Personen genutzt.

Während zunächst die Absicht bestand, die Verfahren vollständig getrennt zu betreiben (was entsprechende technische und organisatorische Trennungsmaßnahmen erfordert), hat sich mittlerweile die Ansicht durchgesetzt, dass die gemeinsamen Aspekte überwiegen und eine gemeinsame Verantwortlichkeit gemäß Artikel 26 DSGVO vorliegt.

Die zuständigen Innenbehörden haben einen Entwurf einer Vereinbarung gemäß Art. 26 Abs. 1 DSGVO erstellt, in dem die jeweiligen Zuständigkeiten geregelt werden sollen. Dieser Entwurf wird derzeit mit den beteiligten Aufsichtsbehörden diskutiert.

Offen ist weiterhin die genaue Ausgestaltung der Protokollierungen von Abrufen durch Strafverfolgungs- und Sicherheitsbehörden, die gemäß § 40 Abs. 3 Bundesmeldegesetz (BMG) – anders als andere Behörden für deren Abrufe und anders als für die sonstigen Melderegisterauskünfte – die Protokollierung selbst vornehmen müssen. Diese speziellen Abrufe sollen nämlich den einzelnen Meldebehörden nicht bekannt werden. Technisch kann eine solche Protokollierung zwar ebenfalls bei Dataport geschehen – allerdings im Auftrag der jeweiligen Behörde und nicht im Auftrag der Meldebehörden.

 

6.3.4       Artikel-33-Meldungen im öffentlichen und nichtöffentlichen Bereich – die technische Sicht

Im Berichtszeitraum erreichten das ULD zahlreiche Meldungen über Datenschutzvorfälle nach Artikel 33 DSGVO (siehe beispielsweise Tz. 4.1.13 und Tz. 5.4). Meist wurde dazu das vom ULD veröffentlichte Meldeformular verwendet, das die zur Bearbeitung durch das ULD erforderlichen Informationen in strukturierter Form erfasst.

Im überwiegenden Teil der Meldungen, die das ULD erreichten, bestand durch die Datenschutzverletzung tatsächlich ein Risiko für die Betrof-fenen – es erfolgten also keine unnötigen Meldungen oder „Bagatellmeldungen“.

Über die Anzahl der Vorfälle, die nach Artikel 33 meldepflichtig wären, aber fälschlicherweise dem ULD nicht gemeldet wurden (Dunkelziffer), liegen keine Erkenntnisse vor.

Datenschutzvorfall
Eine Meldung eines Datenschutzvorfalls an die zuständige Datenschutzaufsichtsbehörde ist nach Artikel 33 DSGVO erforderlich, wenn ein Risiko für Betroffene durch die Verletzung nicht ausgeschlossen werden kann. Besteht voraussichtlich ein hohes Risiko durch die Datenschutzverletzung, sind die Betroffenen gemäß Artikel 34 zu informieren.

Einige IT-Sicherheits- und Datenschutzvorfälle haben eine solche Tragweite, dass sie presseöffentlich werden. Vergleicht man diese Pressemeldungen mit den dem ULD gemeldeten Vorfällen, so zeigt sich eine Diskrepanz insbesondere bei solchen Vorfällen, die vermeintlich „nur“ die Integrität oder Verfügbarkeit von Daten betreffen – etwa umfassende IT-Ausfälle, Störungen des Netzverkehrs oder festgestellte Fehlberechnungen von Programmen. Hier wurde von den Verantwortlichen wohl häufig entweder kein Risiko für die betroffenen Personen gesehen oder eine Meldung schlicht versäumt.

Derzeit bilden Meldungen über verlorene oder gestohlene Datenträger und IT-Systeme (etwa Smartphones, Notebooks oder externe Speichermedien), Fehlversendungen (Fax, E-Mail, Brief), interne Fehlkonfigurationen sowie Angriffe auf IT-Systeme (z. B. durch Viren, Ransomware) einen Schwerpunkt in technischer Hinsicht.

Ransomware
Mit den Begriffen Ransomware, Erpressungs- oder Verschlüsselungstrojaner bezeichnet man Schadprogramme, die einen Datenbestand so verschlüsseln, dass er für die Verantwortlichen nicht mehr nutzbar ist. Die Entschlüsselung wird gegen die Zahlung eines Lösegeldes versprochen.

Das tatsächliche Risiko für die Rechte und Freiheiten betroffener Personen ist für Verantwortliche nicht immer sofort ersichtlich, insbesondere bei einem Befall der IT-Systeme mit Schadcode: Hier kommt es darauf an, ob der Schadcode die Datenbestände z. B. „nur“ verschlüsselt oder ob es beim Schadcodebefall auch zu einem Datenabfluss oder einer Datenveränderung gekommen ist. Im ersten Fall ist die Verfügbarkeit der Daten betroffen, im zweiten Fall die Vertraulichkeit oder die Integrität. Um diese Frage seriös beantworten zu können, ist eine Bestimmung des Schadcodes oder die Analyse seiner Wirkungsweise und des Infizierungswegs erforderlich.

Bei der Bearbeitung von Meldungen prüft das ULD neben der Vollständigkeit der Meldung auch die Plausibilität der Risikoeinschätzung der Verantwortlichen, eine eventuelle Pflicht zur Information der betroffenen Personen sowie die Frage, ob die in der Meldung dargestellten technisch-organisatorischen Maßnahmen zur Risikoeindämmung und Verhinderung einer Wiederholung ausreichend sind.

In vielen Fällen sind die ersten Meldungen nicht vollständig. Dies ist häufig nachvollziehbar, da innerhalb der geforderten 72-Stunden-Frist der Meldung meist der Sachverhalt noch nicht vollständig aufgeklärt ist. Insbesondere im Fall einer Infizierung durch Ransomware werden zumeist strafrechtliche Ermittlungen eingeleitet, welche die eigene Analyse des Vorfalls verzögern. Eine Ergänzung der Informationen ist daher möglich und wird vom ULD auch häufig angefordert, um eine abschließende Bewertung des Vorfalls vornehmen zu können.

Bei der Beurteilung der Frage, ob durch die Datenschutzverletzung ein hohes Risiko für die betroffenen Personen besteht und diese folglich zu informieren sind, gibt es teilweise abweichende Bewertungen. In diesen Fällen weist das ULD die Verantwortlichen darauf hin, dass die betroffenen Personen zu informieren sind. Ebenso gibt es Abweichungen bei der Beurteilung, inwieweit technisch-organisatorische Maßnahmen zur Eindämmung des aktuellen Risikos ausreichend sind. Ein Beispiel hierfür ist die Ausbreitung von Schadcode, bei der es nicht genügt, den infizierten Arbeitsplatz-PC vom Schadcode zu säubern. Vielmehr ist zu prüfen, ob der Schadcode keine weiteren Veränderungen im Netz, etwa die unbefugte Einrichtung administrativer Konten, vorgenommen hat. In den recht häufig auftretenden Fällen, in denen eine Ransomware durch die Erlangung von administrativen Rechten des Gesamtsystems („Golden Ticket“) diese Systeme vollständig verschlüsselt, ist das System tief greifend kompromittiert. Daher ist bei der Wiederherstellung der Systeme sicherzustellen, dass dieses „Golden Ticket“ nicht mehr verwendet werden kann; eine Beschreibung der Maßnahmen, wie die Gültigkeit dieses „Golden Tickets“ aufgehoben wird, ist daher für das ULD zur Bewertung absolut erforderlich.

Im Fall von verlorenen oder gestohlenen Geräten wird in den Meldungen zumeist angegeben, dass das entwendete Gerät bzw. die Daten verschlüsselt waren. Dabei ist zu bedenken, dass die Meldungen auch von Personen mit wenig Bezug zur technischen Realisierung vorgenommen werden können, die möglicherweise einen einfachen Passwortschutz mit einer Verschlüsselung gleichsetzen. Diese Klarstellung sowie die Informationen zur Verschlüsselungsform (Datenbankfeld, Datei, Container, Partition, gesamtes System) und -qualität gehören zu den häufigsten Nachfragen des ULD.

Auch bei den technisch-organisatorischen Maßnahmen, welche die reguläre Verarbeitung absichern, gibt es in Teilen Nachholbedarf. So weist beispielsweise die Erkenntnis, dass zwar eine Datensicherung eingerichtet, diese aber seit Wochen nicht ausgeführt wurde, auf einen organisatorischen Mangel hin. Technisch-organisatorische Maßnahmen sind nicht nur einmalig einzurichten, sondern ihre Funktionsfähigkeit ist fortlaufend zu überprüfen.

In anderen Fällen waren angemessene Maßnahmen getroffen worden, die durch eine Verkettung von Zufällen im Einzelfall aber nicht ausreichten und zu einem Datenschutzvorfall führten, etwa bei Einbrüchen in gesicherte Büros. In diesen Fällen gab es manchmal keinen Nachholbedarf – es liegt schlicht in der Natur der Sache, dass bei risikobasierten Sicherheitsmaßnahmen, wie sie Artikel 32 DSGVO fordert, in Einzelfällen sich das Restrisiko manifestieren kann (zur Verschlüsselung mobiler Datenträger siehe Tz. 4.5.10 und 5.3.5).

Zusammenfassend lässt sich feststellen, dass das ULD durch die Meldepflicht gemäß Artikel 33 DSGVO weiter gehende Einblicke in die Risikostruktur erhält, die für die Beurteilung der Angemessenheit technisch-organisatorischer Maßnahmen wichtige Hinweise liefert.

 

Zurück zum vorherigen Kapitel Zum Inhaltsverzeichnis Zum nächsten Kapitel