Sie sind hier: > Start > Tätigkeitsberichte > 33. TB 2023 > 11. Technik und Organisation

Der Bayerische Landesbeauftragte für den Datenschutz; Stand: 31.12.2023

11. Technik und Organisation

11.1. Nutzung von nicht dienstlichen E-Mail-Adressen

Die Nutzung dienstlicher E-Mail-Adressen ist für öffentlicher Stellen grundsätzlich unverzichtbar, weil durch Verwendung von internen E-Mail-Servern ein geschützterer Austausch von Informationen innerhalb der Organisation sichergestellt wird. Ein solches System erleichtert die Implementierung von Verschlüsselungstechnologien, um die Integrität übermittelter Daten auch an externe Empfänger sicherzustellen. Im Gegenzug können externe Empfänger Behördenkontakte leichter verifizieren. Das reduziert die Gefahr von Phishing-Angriffen und anderen betrügerischen Aktivitäten.

Dienstliche E-Mail-Adressen sind damit eine nahezu notwendige Voraussetzung für die Sicherung sensibler Daten bei der Übertragung per E-Mail und der Gewährleistung einer zuverlässigen behördlichen Kommunikation.

Leider erreichten mich auch in diesem Jahr wieder Beschwerden gegen bayerische öffentliche Stellen, bei denen private EMail-Accounts außerhalb der behördlichen Infrastruktur zur Kommunikation dienstlicher Inhalte genutzt wurden. Einzelne Fälle betrafen etwa Lehrkräfte öffentlicher Schulen, sowie Gerichtsvollzieherinnen und Gerichtsvollzieher.

Bei frei verfügbaren, kostenlos angebotenen E-Mail-Accounts ("Freemail-Diensten") sind die Allgemeinen Geschäftsbedingungen (AGB) oft nicht mit dienstlichen Belangen vereinbar. Solche AGB gewähren den Providern zum Teil weitreichende Einsichtsrechte in die E-Mail-Inhalte ihrer Nutzerinnen und Nutzer, um beispielsweise personalisierte Werbung ausbringen zu können. Für eine Verarbeitung der in den E-Mails enthaltenen personenbezogenen Daten zu diesem Zweck fehlt es typischerweise an einer Rechtsgrundlage.

Die Einräumung solcher Einsichtsrechte durch die AGB von Freemail-Diensten birgt erhebliche Risiken für die Vertraulichkeit von behördlichen Informationen; sie kann auch zu einem ernsthaften Sicherheitsrisiko für die behördliche Kommunikation werden.

Darüber hinaus untergräbt die Nutzung privater E-Mail-Dienste die Möglichkeit einer sicheren Kommunikation innerhalb öffentlicher Stellen. Freemail-Anbieter sind oft nicht auf die spezifischen Sicherheitsanforderungen von Behörden ausgerichtet, was die Gefahr von Datenlecks und unautorisiertem Zugriff erhöht.

Unabhängig von solchen Risiken werden private-E-Mail-Accounts häufig auch in einem weniger abgesicherten Umfeld genutzt als dienstliche E-Mail-Accounts, etwa auf privaten Endgeräten wie Laptops oder Smartphones. Diese Geräte sind tendenziell schlechter gesichert als dienstliche und damit insbesondere einem höheren Risiko für Diebstahl oder Kompromittierung ausgesetzt. Zudem werden private E-Mail-Adressen naturgemäß eben auch für die private Kommunikation - etwa mit Shopping- und Social-Media-Plattformen - genutzt. Dadurch sind sie einem erhöhten Risiko für Phishing- und Malware-Angriffen ausgesetzt.

Ich empfehle nachdrücklich allen Bediensteten bayerischer öffentlicher Stellen die Nutzung ihrer in aller Regel standardmäßig bereitgestellten, zumindest auf Wunsch verfügbaren, dienstlichen E-Mail-Adressen für die Kommunikation in der Rolle von Beschäftigten. Selbst wenn im Einzelfall Dienstvereinbarungen oder vergleichbare Regelungen eine freie Wahl des Kommunikationsmittels erlauben, ist die Nutzung privater Accounts - insbesondere von Freemail-Anbietern - mit erheblichen Risiken verbunden. Selbst wenn die "Flucht ins Private" in bestimmten Situationen eine bequeme Lösung sein mag: Wer die IT-Sicherheit und den Datenschutz ernst nimmt, ist mit der behördlichen Kommunikationsinfrastruktur im Zweifelsfall besser bedient.

11.2. E-Mail und Copy & Paste

Dass beim Kopieren und Einfügen von Texten besondere Sorgfalt erforderlich ist, zeigt ein ungewöhnlicher Vorfall aus einer bayerischen Justizvollzugsanstalt: Dort hatte eine Mitarbeiterin vor Urlaubsantritt eine automatische Abwesenheitsbenachrichtigung für ihren dienstlichen E-Mail-Account eingerichtet. Dabei hatte sie jedoch nach dem eigentlich gewollten Benachrichtigungstext versehentlich personenbezogene Daten eines Gefangenen aus einem zuvor bearbeiteten Vorgang miteingefügt ("Copy & Paste").

In der Folge erhielten die Kommunikationspartner durch die Abwesenheitsnotiz aufschlussreiche Angaben zu sozialen Bindungen, Delikten sowie schulischer und beruflicher Laufbahn eines bestimmten Gefangenen. Wenigstens war dieser nur mit seinem im deutschsprachigen Raum verbreiteten Nachnamen bezeichnet.

Nach dem Bekanntwerden des Vorfalls wurde der automatisierte Abwesenheitsassistent unverzüglich deaktiviert, der Vorfall mit der Bediensteten besprochen und auch die übrige Belegschaft sensibilisiert.

Die Verletzung des Schutzes personenbezogener Daten hatte voraussichtlich kein hohes Risiko für die persönlichen Rechte und Freiheiten der betroffenen Person zur Folge, weil eine konkrete Zuordnung anhand der versehentlich preisgegebenen Daten nahezu ausgeschlossen werden konnte. Gleichwohl verweist der Fall auf eine wichtige und gern vergessene "Windows-Routine": Beim Einfügen von kopierten Inhalten muss immer geprüft werden, ob nicht unbeabsichtigt zu viele Daten weitergegeben werden.

11.3. Jugend pentestet

11.3.1. Schulische Netzwerke

An staatlichen Schulen in Bayern werden in der Regel zwei getrennte Netzwerke genutzt, die unterschiedlichen Verarbeitungszwecken dienen. Einerseits soll den Bildungseinrichtungen der Einsatz vielfältiger pädagogischer Methoden für den Unterricht ermöglicht werden - etwa um Inhalte zu teilen, Informationen aus dem Internet abzurufen oder auf interaktiven Tafeln im Klassenzimmer anzuzeigen. Dazu dient das pädagogische Netz. Bei diesem stehen insbesondere die Verfügbarkeit und der leichte Zugang im Vordergrund. Eine Verarbeitung personenbezogener Daten ist dort grundsätzlich nicht vorgesehen. Aus Gründen der Autorisierung beziehungsweise Authentisierung lässt sich jedoch nicht gänzlich vermeiden, dass etwa Benutzernamen oder Geräteadressen geprüft werden, um zu gewährleisten, dass nur befugte Nutzerinnen und Nutzer Zugriff auf das Netzwerk und die darin zu pädagogischen Zwecken vorhandenen Geräte haben. Das Gegenstück dazu bildet das Verwaltungsnetz. Dabei handelt es sich um ein separates und stärker geschütztes Netzwerk. Dieses Netz dient zur Verarbeitung von Personal- und Schülerdaten, hier können also gezielt personenbezogene und teils auch sensible Daten verarbeitet werden. Daher gelten in diesem Bereich auch strikte Sicherheitsrichtlinien.

11.3.2. Ein Schüler als Pentester

Ein Schüler hatte im Rahmen eines Forschungsprojekts unter Aufsicht einer Lehrkraft einen Penetrationstest (kurz: Pentest) im pädagogischen Netzwerk seiner Schule durchgeführt. Solche Tests dienen üblicherweise dem Zweck, einzelne Systeme oder ganze Netzwerke auf Schwachstellen zu prüfen und diese zu dokumentieren, um sie dann - mit dem Ziel einer Behebung - dem Betreiber mitzuteilen. In der Regel werden solche Tests durch spezialisierte IT-Sicherheits-Dienstleister in Absprache mit dem Verantwortlichen durchgeführt.

Dem Schüler, dessen Lehrer zugleich die Rolle des Datenschutzbeauftragten der Schule bekleidete, gelang bei seinem Pentest ein erfolgreicher Angriff: Durch einen nicht ausreichend sicher konfigurierten LDAP-Dienst konnte er Zugriff auf das "historisch gewachsene" pädagogische Netzwerk erhalten. Unsichere Praktiken der Systemadministration (etwa in Scriptdateien im Klartext gespeicherte Zugangsdaten oder einfach zu erratende Passwörter für privilegierte Accounts) waren "Altlasten", die wohl wiederholt übersehen worden waren. Der Schüler konnte seine Systemrechte schrittweise bis hin zum Domänen-Administrator ausbauen (sog. Privilege Escalation) und in der Folge einen Vollzugriff auf die Systeme und Dateien innerhalb der Domäne des pädagogischen Netzes erlangen. Er fand heraus, dass sich dieses Netz nicht nur auf seine Schule beschränkte, sodass der Schüler schließlich auch auf Daten weiterer Schulen zugreifen konnte.

11.3.3. Responsible Disclosure unerwünscht

Der Pentest fand zwar unter Aufsicht einer Lehrkraft statt, allerdings ohne vorherige Rücksprache mit dem technischen Betreiber des pädagogischen Schulnetzes. Immerhin wurden die Ergebnisse dem Dienstleister im Rahmen einer Präsentation vorgestellt. Dieses Vorgehen wird Responsible Disclosure genannt. Dabei soll die Offenlegung einer gefundenen Sicherheitslücke mit dem Hersteller abgestimmt und die breite Öffentlichkeit erst informiert werden, sobald die Sicherheitslücke behoben wurde. Full Disclosure bezeichnet im Gegensatz dazu die Praxis, Informationen über die Sicherheitslücke ohne vorherige Absprache mit den verantwortlichen Stellen zu veröffentlichen. Ziel dieses Vorgehens kann es etwa sein, hohen Druck auf einen Hersteller oder Betreiber auszuüben, die Sicherheitslücke schnellstmöglich zu schließen. Benutzerinnen und Benutzer werden dann zwar gewarnt; Hacker könnten die Schwachstelle allerdings ausnutzen, bevor der Betreiber sie schließen kann.

Die Reaktion des Betreibers auf diese Responsible Disclosure fiel aus Sicht des Schülers und des Lehrers ernüchternd aus: Der offenkundig nicht IT-inkompetente Schülers erhielt weder Anerkennung noch wurde er in einen gemeinsamen Lösungsfindungsprozess eingebunden; der Betreiber wies stattdessen darauf hin, dass ein solches Vorgehen - insbesondere ohne Absprache - zukünftig zu unterlassen sei und Schüler wie Lehrkraft Passwörter absolut vertraulich zu behandeln hätten. Auch mit konkreten Maßnahmen zur Stärkung der Sicherheit seines IT-Systems zögerte der Betreiber zunächst, obwohl die Lücke eklatant erschien - immerhin hatte ein Schüler Adminrechte für die gesamte Domäne erlangt.

11.3.4. Frust und Neugier

Die Reaktion des Betreibers forderte den Schüler nun heraus: Einige Zeit nach der Präsentation verschaffte er sich ohne Absprache mit dem Betreiber oder seiner Lehrkraft nochmals Zugang zum pädagogischen Netz. Dies geschah über seinen eigenen Computer im privaten Umfeld außerhalb der Unterrichtszeit. Der Schüler nutzte einen SSHTunnel zu einem derjenigen Server, auf den er zuvor Zugriff erlangt hatte und auf dem er sich offenbar eine Hintertür eingerichtet hatte. So konnte er mehrere weitere Server kompromittieren, Dienste verändern und Pakete nachinstallieren. Darüber hinaus gelang ihm, Daten des LDAPVerzeichnisses einer anderen Schule sowie von der Softwarepaketierung und Softwarebereitstellung abzuziehen.

11.3.5. Aufarbeitung und Lessons Learned

Ich habe mich im Rahmen der Aufarbeitung des Falls sowohl mit dem Lehrer als auch mit den Betreibern des pädagogischen wie auch des Verwaltungsnetzes der Schule auseinandergesetzt. Entstandene Schäden wurden behoben und Sicherheitslücken geschlossen. Auch Sensibilisierungsmaßnahmen - etwa mit der Schulleitung - wurden ergriffen. Nach meiner derzeitigen Kenntnis fand kein Zugriff auf das Verwaltungsnetz statt. Die Risiken durch die Möglichkeit des Zugriffs auf personenbezogene Daten in den LDAP-Verzeichnissen blieben in Anbetracht der Datenkategorien und der Motivation des Schülers überschaubar.

Aus dem Vorfall lassen sich mehrere Lehren und Empfehlungen für bayerische öffentliche Stellen - insbesondere für öffentliche Schulen - gewinnen:

• Zugangsdaten dürfen nicht im Klartext in Scriptdateien gespeichert werden. Historisch gewachsene Systeme und Netzwerke sollten systematisch einer Prüfung unterzogen werden. Dies gilt insbesondere bei einem Betreiberwechsel, bei dem die vorhandene IT-Infrastruktur beibehalten wird.
• Privilegierte Benutzeraccounts (wie Domänen-Administrationskonten) sollten nicht einfach zu erratende oder in Wörterbüchern gelistete Passwörter verwenden. Gerade im Falle weiterreichender Zugriffsrechte ist die Nutzung einer Zwei-Faktor-Authentifizierung zu prüfen.
• LDAP-Verzeichnisse sollten auf ihre Sicherheit geprüft werden; dies gilt insbesondere für die Lese- und Schreibberechtigungen. Die darin gespeicherten Informationen sollten auf das notwendige Maß beschränkt sein (Grundsätze der Datenminimierung und der Datensparsamkeit).
• Responsible Disclosure ist aus Sicht einer bayerischen Behörde eine als positiv zu beurteilende Vorgehensweise von Dritten, die Sicherheitslücken gefunden haben: Gewiss ist es für Behördenleitungen und IT-Sicherheits-Verantwortliche im ersten Moment unerfreulich, von Lücken im eigenen System zu erfahren. Dennoch ist Responsible Disclosure einem erfolgreichen Cyberangriff vorzuziehen, bei der die Lücke schadhaft ausgenutzt wurde und ihr Bestehen sich erst im Nachhinein bei einer forensischen Untersuchung herausstellt.
• Penetrationstests sind ein wichtiges Mittel zur Absicherung: Betreiber sollten im besten Fall regelmäßig oder auch nach größeren Umstellungen der Infrastruktur oder bei Betreiberwechseln die Systeme und Netze prüfen oder prüfen lassen, insbesondere dann, wenn es sich um komplexe und historisch gewachsene Umgebungen handelt.
• Allerdings möchte ich auch von Laien-Pentests in einer Produktivumgebung abraten. Auch wenn es verlockend sein mag, im Rahmen schulischen oder akademischen Unterrichts kostengünstig Pentests durchführen zu lassen, sind damit Risiken verbunden. Auf Betreiberseite kann die Verfügbarkeit von Diensten gefährdet sein, wenn diese im Zuge eines Angriffsversuchs abstürzen oder überlastet werden. Auch können Daten verloren gehen oder verfälscht werden (etwa bei einer SQL-Injection). Nicht zuletzt besteht ein Risiko für nicht abgesprochene "Einzelgängeraktionen" wie im hier beschriebenen Fall. Auch "gut gemeinte" Angriffe können für Hobbyhackerinnen und Hobbyhacker schwerwiegende Konsequenzen haben: Schon das Vorbereiten des Ausspähens und Abfangens von Daten ist zudem ein Straftatbestand, der nach § 202c Abs. 1 Nr. 1 Strafgesetzbuch mit einer Freiheitsstrafe bis zu zwei Jahren geahndet werden kann.

11.4. Beratungstätigkeit für Datenschutz-Folgenabschätzung (DSFA) und Risikoanalyse

In meinem Beratungsalltag stelle ich fest, dass sich die Datenschutz-Folgenabschätzung (DSFA) sowie die allgemeine datenschutzrechtliche Risikoanalyse von einem einstmals neuen, noch unbekannten Instrument zu gut eingeübten Routinen entwickeln. Diese Entwicklung ist sehr zu begrüßen. Neben Gerichtsentscheidungen, die in bestimmten Konstellationen eine DSFA ausdrücklich fordern, ohne dabei auf die DSFA-Methode näher einzugehen, zeichnen sich mittlerweile wichtige Anwendungsfelder ab. Insbesondere dort, wo innovative technische Betriebsmittel oder die deutliche Ausweitung bestehender Datennutzungsansätze im Raum stehen, ist oft der Ruf nach einer DSFA zu vernehmen, die eine rechtskonforme Verarbeitung nachweisen soll.

Da mein umfangreiches Informationspaket zu DSFA und allgemeiner Risikoanalyse bereits in ganz unterschiedlichen fachlichen Kontexten (zum Beispiel Gesundheitswesen, Personalwirtschaft, Kommunen, Justiz) zur Anwendung gekommen ist, konnten sich sowohl die zugrundeliegende systematisch hergeleitete Methodik als auch die Good-Practice-Empfehlungen in der Praxis bewähren. Dieser gesetzte Rahmen erlaubt den bayerischen öffentlichen Stellen eine Fokussierung auf die eigentlichen Inhalte der einzelnen DSFA oder allgemeinen Risikoanalyse, nachdem der zeitliche Beginn für die jeweilige Durchführung festgelegt wurde.

Der Verantwortliche muss geeignete technische und organisatorische Maßnahmen bereits planen und veranlassen, wenn er die Mittel der Verarbeitung festlegt; wird diese produktiv, müssen die Maßnahmen implementiert, überwacht und erforderlichenfalls ergänzt werden. Bei einer Hochrisikoverarbeitung muss die dann erforderliche DSFA, die auch die zur Bewältigung der Risiken geplanten technischen und organisatorischen Maßnahmen mit umfasst, vorab durchgeführt und nachgewiesen werden (Art. 35 Abs. 1 DSGVO).

Immer wieder wird mir die Frage gestellt, wann eine DSFA oder allgemeine Risikoanalyse begonnen werden muss. Bei der Beschaffung von datenschutzrelevanten Leistungen im Wege der Auftragsvergabe muss regelmäßig bereits als Grundlage für die Bestimmung des Beschaffungsbedarfs geprüft werden, welche Risiken für die Rechte und Freiheiten von betroffenen Personen aus der leistungsgegenständlichen Verarbeitung und gegebenenfalls dem Transfer von personenbezogenen Daten resultieren. Je nach der zu bewertenden Verarbeitung kann eine allgemeine Risikoanalyse ausreichen oder bei einer Hochrisikoverarbeitung eine DSFA erforderlich sein. Beide Instrumente liefern - auch im Hinblick auf die oftmals nur eingeschränkte Möglichkeit der Konkretisierung einer Verarbeitung vor der Beschaffung - wichtige Aspekte, die als funktionale oder nicht-funktionale Anforderungen an den Leistungsgegenstand zu berücksichtigen sind (zum Beispiel Anforderung an die Gestaltung von Zugriffsberechtigung und an die Löschfunktion). Daher ist eine risikobasierte datenschutzrechtliche Betrachtung grundsätzlich bereits vor solchen Beschaffungen durchzuführen, und die relevanten Ergebnisse der Risikoanalyse sind in den Beschaffungsunterlagen zu berücksichtigen. Nach der Beschaffung geht die schrittweise Konfiguration der Betriebsmittel während der Implementierung und der Einführung mit der Konkretisierung der DSFA beziehungsweise der Risikoanalyse einher.

11.5. Umgang mit dem PIA-Tool der CNIL

Digitalisierung erleichtert auch die Erledigung von Datenschutzaufgaben. Die Suche nach einer IT-Anwendung, die bei der Erstellung und der Verwaltung einer Datenschutz-Folgenabschätzung (DSFA) hilft, führt meist rasch zum "PIA-Tool". Die von der französischen Datenschutz-Aufsichtsbehörde - der Commission Nationale de l' Informatique et des Libertés (CNIL) - Software-Unterstützung beruht auf der dortigen DSFA-Methodik, dem "Privacy Impact Assessment" (PIA). Mit dem PIA-Tool kann ein DSFA-Bericht im Bereich der Sicherheit der Verarbeitung erstellt und ausgegeben werden.

Die CNIL stellt unterschiedliche Varianten des PIA-Tools als Open-Source-Software zur Verfügung. Weitere Versionen des PIA-Tools sind in unterschiedlichen Bereichen des Onlinedienstes GitHub verfügbar, auf dem die Entwicklungsprojekte für das PIA-Tool bereitstellt werden. Über diese GitHub-Projekte kann mit den Entwicklern des PIA-Tools kommuniziert und weitergehende Information insbesondere zu den einzelnen Software- und Sprachversionen bezogen werden.

Da bayerische öffentliche Stellen das PIA-Tool zumindest nach meiner Wahrnehmung aus unterschiedlichen Gründen kaum nutzen, sondern meine in der Praxis schon bewährten Arbeitshilfen zu DSFA und allgemeiner datenschutzrechtlicher Risikoanalyse mit "Werkzeugkasten" einsetzen, biete ich das PIA-Tool auf meiner Website nicht mehr an. In meiner Orientierungshilfe "Risikoanalyse und Datenschutz-Folgenabschätzung - Systematik, Anforderungen, Beispiele" ist das Instrument gleichwohl berücksichtigt.

Vor der Beschaffung und dem Einsatz einer IT-Anwendung müssen grundsätzlich im Rahmen des Anforderungsmanagements die fachlichen und technischen Anforderungen an diese IT-Anwendung erhoben, analysiert und bewertet werden. Dieses allgemein angeratene Vorgehen sollte auch vor der Nutzung des PIA-Tools beachtet werden. Dabei zeigt sich unter anderem, dass im PIA-Tool nur die drei Risikobereiche "Unrechtmäßiger Zugriff auf Daten", "unerwünschte Änderung von Daten" und "Datenverlust" behandelt werden. Werden diese drei Bereiche für Verarbeitungsrisiken mit den DSGVO-Anforderungen verglichen, so stellt sich die Frage, ob für eine vollständige DSFA nicht auch weitere Risikobereiche, wie beispielsweise die Bereiche "Datenminimierung", "Transparenz", "Intervenierbarkeit", "Nichtverkettung" und "Richtigkeit", zu betrachten sind.

In meiner Orientierungshilfe "Risikoanalyse und Datenschutz-Folgenabschätzung - Systematik, Anforderungen, Beispiele" wird die Antwort auf diese Frage systematisch auf Basis der Datenschutz-Grundverordnung hergeleitet und die wichtige Frage nach der Vollständigkeit bejaht. Diese Orientierungshilfe erfüllt die Mindestanforderungen an eine rechtskonforme DSFA. Daher sind diese Anforderungen bei jeder IT-Unterstützung für die Erstellung und die Verwaltung einer DSFA von bayerischen öffentlichen Stellen zu beachten.

Feedback bayerischer öffentlicher Stellen zum PIA-Tool lässt zudem erkennen, dass insbesondere auch eine fehlende Benutzerverwaltung, fehlende Unterstützung bei Softwarefehlern sowie eine fehlende Umsetzung von wichtigen Good-Practice-Ansätzen (zum Beispiel eine zweigeteilte DSFA) Schwierigkeiten bei der Verwendung des PIA-Tools bereiten können.

Im Rahmen meiner Beratung zur DSFA konnte ich zudem beobachten, dass bei der erstmaligen Durchführung einer DSFA praxisgerechte Arbeitshilfen mit anschaulichen Beispielen gut geeignet sind, um das Verständnis für das Instrument "DSFA" zu schärfen, die damit verbundene Methodik besser zu verstehen und den Umgang mit der DSFA einzuüben. Regelmäßig erst danach wird für die jeweilige Stelle deutlich, ob und, wenn ja, welche künftige IT-Unterstützung für die DSFA-Erstellung und die DSFA-Verwaltung sinnvoll erscheint.

11.6. Zustellung durch die Post mit Zustellungsurkunde

Die förmliche Zustellung eines Schreibens durch ein Landratsamt veranlasste einen Bürger, sich mit einer Beschwerde an mich zu wenden: Auf dem Briefumschlag seien gut sichtbar Angaben verzeichnet gewesen, die Rückschlüsse auf den Inhalt des Schreibens zuließen und dort aus Datenschutzgründen nicht hätten vermerkt werden dürfen.

Konkret handelte es sich um die Angabe eines Kfz-Kennzeichens des Beschwerdeführers, das ein personenbezogenes Datum darstellt. Auf dem Briefumschlag konnten zudem, die Felder "Versicherungsschutz", "Steuer", "Meldepflicht", "TÜV", "AU" und "SP" angekreuzt werden, was auf Versäumnisse des Briefadressaten in diesen Kontexten hinweisen könnte.

Wird die Zustellung - wie im Beschwerdefall - mit Postzustellungsurkunde bewirkt, sind Art. 3 Verwaltungszustellungs- und Vollstreckungsgesetz in Verbindung mit §§ 177 bis 182 Zivilprozessordnung zu beachten. Auf dem Umschlag, in dem den das zuzustellende Schriftstück eingelegt ist, sowie auf der Zustellungsurkunde dürfen nur die personenbezogenen Angaben angebracht werden, welche die mit der Zustellungsvordruckverordnung eingeführten Muster vorsehen (zu Einzelheiten vgl. meinen 30. Tätigkeitsbericht 2020 unter Nr. 2.5). Die gesetzliche Formulargestaltung stellt in diesem Fall auch sicher, dass die Beschäftigten mit der Zustellung beauftragter Postdienstleistungsunternehmen oder andere Personen, welche die Sendung zu Gesicht bekommen, möglichst wenig über den Inhalt erfahren.

Alle zusätzlichen Angaben auf dem Umschlag, die öffentliche Stellen eigenmächtig hinzufügen, sind im Zweifelsfall ohne Rechtsgrundlage offengelegt: Für die Zustellung dürfen nämlich nur diejenigen Daten verarbeitet werden, die das Zustellungsrecht als erforderlich ansieht.

Im Zusammenhang mit der oben genannten Beschwerde habe ich das betroffene Landratsamt ersucht, zukünftig auf "überschießende" Angaben auf dem Briefumschlag zu verzichten und für Zustellungen nur vorschriftsgemäße Vordrucke zu nutzen.

Ich weise darauf hin, dass die Rechtslage im Anwendungsbereich der Datenschutz-Richtlinie für Polizei und Strafjustiz hiervon abweichen kann.

11.7. Mehrere Beschwerden zur räumlichen Gestaltung von Bürgerbüro und Zulassungsstelle, technisch-organisatorische Prüfung bei einer Kommune

Aufgrund von Beschwerden wurde ich auf die räumliche Gestaltung des Bürgerbüros sowie der Zulassungsstelle einer größeren bayerischen Stadt aufmerksam.

Hier hatte der Stadtrat trotz entsprechender Bedenken des behördlichen Datenschutzbeauftragten beschlossen, im Rahmen eines modernen und vermeintlich bürgerfreundlichen Konzepts das Bürgerbüro im Erdgeschoß des Atriums eines großen mehrstöckigen Bürogebäudes anzusiedeln, so dass es möglich war, die Mitarbeitenden des Bürgerbüros sowie die Bürgerinnen und Bürger rundum aus allen darüberliegenden Stockwerken zu beobachten. Auch bezüglich der Zulassungsstelle musste ich feststellen, dass wegen der engen Platzverhältnisse in den für die Zulassungsvorgänge verwendeten (eigentlich ungeeigneten) Räumlichkeiten sowie wegen der nicht zuletzt dadurch bedingten Personenströme im "Rücken" der dort sitzenden Personen eine datenschutzkonforme Abwicklung der Zulassungsvorgänge in vielen Fällen nicht möglich war.

Speziell kam es im Rahmen eines Zulassungsprozesses und einer damit verbundenen routinemäßigen Überprüfung, ob es sich bei dem Bürger um eine steuerpflichtige Person mit (angeblichen) Zahlungsrückständen handelt, zu einer für die betroffene Person sehr unangenehmen Personenverwechslung. Das Gespräch zu den (angeblichen) Zahlungsrückstände zwischen Bürger und Mitarbeiter war für mehrere weitere Besucher der Zulassungsstelle ohne Weiteres mithörbar.

Leider zeigte sich die Kommune erst nach einer technisch-organisatorischen Vor-Ort-Prüfung einsichtig und sagte zu, die räumliche Ausgestaltung durch Umzüge der entsprechenden Stellen zu ändern. Um bis zur Verlagerung des Bürgerbüros ein Mindestmaß an Vertraulichkeit zu gewährleisten, wurden organisatorische Maßnahmen (unter anderem Aufstockung Sicherheitsdienst, proaktiver Datenschutz durch die Sachbearbeitung) und die Schaffung eines zusätzlichen Ausweichbüros umgesetzt. Auch in der Zulassungsstelle wurden Maßnahmen zum Sicht- und Hörschutz ergriffen.

Wie dieser Fall zeigt, sehen durchaus viele Bürgerinnen und Bürger auch den Datenschutz als ein wichtiges Kriterium hinsichtlich des Aspekts Bürgerfreundlichkeit an. Ich möchte daher noch einmal auf meinen 25. Tätigkeitsbericht 2011/2012 unter Nr. 25.6.2 verweisen; dort sind Details zur datenschutzgerechten Gestaltung von Bürgerbüros aufgelistet.

11.8. Beschwerden zum Verlust einer Patientenakte

Auch im Berichtsjahr erreichten mich wieder zahlreiche Beschwerden zur Verarbeitung von personenbezogenen Daten durch bayerische öffentliche Gesundheitseinrichtungen.

So teilte mir ein Beschwerdeführer mit, dass seine analog geführte Patientenakte in einem Krankenhaus nicht mehr auffindbar, in elektronischer Form dagegen nur teilweise vorhanden sei. Diese Information habe der Beschwerdeführer telefonisch von der Klinik erhalten. Auf meine Nachfrage bei dem Krankenhaus erhielt ich die Auskunft, dass die Akte vorhanden sei.

Auch wenn die Patientenunterlagen offenbar zwischenzeitlich wieder "aufgetaucht" waren, zeigt die Beschwerde exemplarisch einige Probleme der hybriden Aktenführung auf. Werden Akten sowohl analog als auch elektronisch geführt, besteht häufig Unklarheit, welche Akte "führend" ist, vollständig und im Bedarfsfall zugreifbar sein muss. In solchen Fällen muss insbesondere vorher allgemein festgelegt sein, ob beide Akten den gleichen Inhalt haben sollen und entsprechend gepflegt werden müssen, oder ob nur beide Akten zusammen das "Gesamtbild" insbesondere über Gesundheitszustand und Behandlung der betroffenen Person bieten sollen. Fehlt eine solche Festlegung, kann dies zum einen die (Weiter-)Behandlung der Patientin oder des Patienten gefährden. Zum anderen können auch Schwierigkeiten bei der Erfüllung von Betroffenenrechten, insbesondere von Auskunftsansprüchen entstehen

Der Umgang mit "gedoppelten" Patientenakten bedarf einer guten organisatorischen Vorbereitung. Die einschlägigen Vorgaben müssen von vornherein feststehen, klar formuliert sein und handlungsleitend implementiert werden. Sie müssen so "robust" gestaltet sein, dass sie auch im stressigen und auf andere Aspekte als "Rechtsarbeit" fokussierten Klinikalltag zuverlässig funktionieren und das medizinische Personal nicht mehr als nötig von seiner Hauptaufgabe - der Patientenversorgung - abhalten. Die Bewährung entsprechender Vorgaben zur Aktenführung muss effektiv überwacht werden. Diese Empfehlungen gelten auch für das Aufnahme- und Entlassmanagement.

Im Übrigen muss darauf geachtet werden, dass auch bei einer (temporären) Nichtauffindbarkeit einer Papierakte eine Datensicherheitsverletzung vorliegen kann, welche die Meldepflicht nach Art. 33 DSGVO auslöst.

Eine datenschutzgerechte Steuerung des Umgangs mit Patientenakten ist eine wesentliche Aufgabe des Krankenhausmanagements, die zielführend nur gemeinsam mit dem medizinischen Personal bewältigt werden kann. Hier kommt regelmäßigen Schulungen eine wesentliche Bedeutung zu.

11.9. Meldungen von Verletzungen des Schutzes vonpersonenbezogenen Daten

Weiterhin hoch ist die Zahl der Meldungen von Datensicherheitsverletzungen (Art. 33 DSGVO); sie lag 2023 im mittleren vierstelligen Bereich.

• Noch immer ist nicht bei allen bayerischen öffentlichen Stellen bekannt, dass die Meldepflicht gegenüber der Datenschutz-Aufsichtsbehörde bei einem Auftragsverarbeitungsverhältnis den Auftraggeber trifft, während die Meldepflicht des Auftragnehmers grundsätzlich gegenüber dem Auftraggeber zu erfüllen ist. Diese Konstellation hat in letzter Zeit an Bedeutung gewonnen: Cyberangriffe richteten sich zunehmend gegen Rechenzentrendienstleister, in denen auch bayerische öffentliche Stellen ihre Datenbestände hosten. Das Hosting ist typischerweise als Auftragsverarbeitung ausgestaltet - mit der Folge, dass die Rechenzentren ihren Kunden Datensicherheitsverletzungen melden müssen. Leider musste ich immer wieder feststellen, dass betroffene Stellen zwar in den Medien genannt wurden, mir gegenüber jedoch inaktiv blieben. Mitunter wurde auch die Meldung des Auftragsverarbeiters "durchgereicht", wobei eine eigene Risikobewertung in Bezug auf die konkret betroffenen Datensätze unterblieb, die der Auftragsverarbeiter oftmals nicht leisten kann.

Wenngleich Hackerangriffe mittlerweile der zweithäufigste Gegenstand von Meldungen nach Art. 33 DSGVO sind, hielten sich auf dem "Spitzenplatz" weiterhin Datensicherheitsverletzungen durch unbeabsichtigten Fehlversand von personenbezogenen Daten. So gingen im Gesundheitsbereich beispielsweise Abrechnungen oder Arztbriefe unberechtigten Empfängerinnen oder Empfängern zu. Solange Empfängerin oder Empfänger die "falsche" Ärztin oder der "falsche" Arzt, ein Krankenversicherungsträger, eine Reha-Einrichtung oder eine ähnliche Stelle ist, sind diese Unterlagen zwar in der Regel durch dort zu beachtende Verschwiegenheitspflichten geschützt. Das Risiko für betroffene Personen ist dann oft als eher gering zu werten - dennoch kann es auch hier zu einer gravierenden Panne kommen, wenn etwa ein Patient explizit nicht will, dass ein bestimmter Arzt den Arztbrief erhält. Ähnlich verhält es sich beim Fehlversand an Familienangehörige. Auch in scheinbaren "Routinefällen" ist also eine einzelfallspezifische Risikobewertung angezeigt. Auf dieser Grundlage kann der Verantwortliche dann auch entscheiden, ob zusätzlich zur Meldung an die Datenschutz-Aufsichtsbehörde betroffene Personen zu benachrichtigen sind (vgl. Art. 34 DSGVO).

• Probleme bereitet immer wieder die automatisierte Erstellung von Serienbriefen. Hier kommt es - wie die bei mir eingehenden Meldungen von Datenpannen zeigen - recht häufig zu fehlerhaften Adresszuordnungen. Serienbrieffunktionen sollten trotz der auf den ersten Blick eindrucksvollen Arbeitserleichterung nur (strikt) kontrolliert zum Einsatz kommen. Stets geboten ist eine Plausibilitätskontrolle vor dem Versand anhand einer geeignet großen Stichprobe. Der Umfang hängt von der Länge der Adressliste ab - in der Praxis erwies sich eine Stichprobe von 25 Adressierungen bei (nur) rund 150 Empfängern als deutlich zu klein.
• Verletzungspotenzial birgt ferner die Kommunikation per E-Mail, die nach wie vor oftmals unverschlüsselt stattfand. Ich möchte daher noch einmal auf den Beitrag zu diesem Thema in meinem 26. Tätigkeitsbericht 2013/2014 unter Nr. 3.6.6 hinweisen.

Zudem wurden mir weiterhin Fälle bekannt, in denen Verteilerlisten an mehrere Empfängerinnen und Empfänger ohne Blind-Carbon-Copy (BCC) als Adressoption versendet worden sind, wodurch alle Adressatinnen und Adressaten von den Adressen der jeweils anderen Kenntnis nehmen konnten. Mit diesem Thema habe ich mich bereits in meinem 27. Tätigkeitsbericht 2015/2016 unter Nr. 2.1.3 befasst. Verantwortliche sollten stets überlegen, mit welchen Maßnahmen solche Vorfälle vermieden werden können - in Betracht kommt etwa das standardmäßige Einblenden des BCC-Felds im Mail-Client.

• Nicht wenige Datenpannenmeldungen erreichten mich schließlich aus Kliniken, wenn Beschäftigte auf Patientendaten außerhalb ihres Behandlungsrahmens zugegriffen haben. Umfassende weiterführende Hinweise zu solchen Neugierzugriffen, bei denen Zugriffsrechte missbräuchlich genutzt werden, finden sich in meinem 32. Tätigkeitsbericht 2022 unter Nr. 12.8.

Auch Witterungseinflüsse sorgten im Berichtsjahr wieder für eine gemeldete Datenpanne (siehe bereits mein 31. Tätigkeitsbericht 2021 unter Nr. 10.9):

Eine Beschäftigte einer bayerischen öffentlichen Stelle befand sich im Hochsommer auf Dienstfahrt mit einem Kraftwagen. Dabei hatte sie Unterlagen mit personenbezogenen Daten in Form einer losen, mehrseitigen Liste ungesichert auf die Rückbank gelegt. Aufgrund des heißen Wetters fuhr die Beschäftigte mit offenem Fenster. Da sie wegen eines Termins in Eile war, beschleunigte sie so stark, dass durch den entstehenden Luftzug einige Blätter aus der Liste gelöst wurden. Sie konnte zwar beinahe alle Blätter noch auffangen, eines war jedoch bereits durchs Fenster geweht worden und nicht mehr auffindbar.

11.10. Umgang mit Video-/Fotokameras

Sowohl in öffentlichen Krankenhäusern als auch in kommunalen Kindertagestageseinrichtungen kommen immer wieder Kameras abhanden, auf denen Video- und Fotoaufnahmen von Patienten oder Kindern gespeichert sind. Gerade in Kindertagesstätten werden häufiger Aufnahmen der Spielsituation zu pädagogischen Zwecken gemacht. Die Kameras werden leider immer wieder nicht auffindbar verlegt, "im Vorbeigehen" gestohlen oder sogar im Rahmen von Einbrüchen gewaltsam entwendet. In beiden Fällen handelt es sich um Daten, die einen besonderen Schutzbedarf haben.

Diese Vorfälle machen deutlich, wie wichtig ein sorgfältiger Umgang mit diesen Geräten ist. Die technische Ausrüstung, mit der Fotos oder Videoaufzeichnungen zu dienstlichen Zwecken aufgenommen werden, ist mit der gleichen Sorgfalt aufzubewahren wie Laptops oder Dienst-Smartphones. Sie sollte grundsätzlich in einem verschlossenen Raum oder Schrank aufbewahrt werden. Zutritt und Zugriff zu den technischen Geräten und zu gespeicherten Aufzeichnungen darf nur erhalten, wer dies zur Erfüllung seiner Aufgaben benötigt. Insbesondere sollten sie auch nicht kurzzeitig in Bereichen, zu denen auch Besucherinnen und Besucher, Eltern oder Patientinnen und Patienten Zugang haben, offen liegen gelassen werden.

Da diese Maßnahmen allerdings gegen Einbrüche nur einen beschränkten Schutz bieten, ist insbesondere darauf zu achten, dass die Fotos und Videoaufzeichnungen so bald wie möglich von der Kamera gelöscht werden. Dies entspricht auch den Anforderungen and die Datensparsamkeit. Werden Aufzeichnungen über einen längeren Zeitraum benötigt, so sollten die Daten im Idealfall direkt nach der Aufnahme in ein zentrales IT-System übermittelt werden; im Fall eines Krankenhauses etwa an das Krankenhausinformationssystem (KIS) und im Fall der Kindertagesstätte beispielsweise an einen Server des Trägers in einem geschützten Serverraum.

11.11. Anweisung gemäß Art. 58 Abs. 2 Buchst. d DSGVO wegen Defiziten bei einem Rollen- und Berechtigungskonzept

Krankenhäuser verarbeiten in zunehmendem Umfang Patientendaten in elektronischer Form im Krankenhausinformationssystem (KIS) und daran angegliederten Subsystemen. Bereits im Jahr 2014 hat die Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder (DSK) hierzu eine Orientierungshilfe (OH KIS, 2. Fassung) verabschiedet, die Anforderungen an eine datenschutzgerechte rechtliche und technisch-organisatorische Ausgestaltung des KIS formuliert (siehe mein 25. Tätigkeitsbericht 2011/2012 unter Nr. 7.2). In der Folgezeit habe ich die Umsetzung dieser Orientierungshilfe in bayerischen öffentlichen Krankenhäusern immer wieder beratend begleitet und geprüft (siehe mein 26. Tätigkeitsbericht 2013/2014 unter Nr. 2.2.3).

Umfangreiche Mängel musste ich in einem bayerischen öffentlichen Klinikum bereits 2019 im Rahmen einer Vor-Ort-Prüfung feststellen. Hier bestand weder ein schriftlich dokumentiertes noch im KIS in ausreichendem Maße implementiertes Rollen- und Berechtigungskonzept. Dies führe dazu, dass im Klinikum tätiges medizinisches Personal (sowohl Ärztinnen und Ärzte als auch Pflegekräfte) weit über ihren Zuständigkeits- und Fachbereich hinaus Zugriffsrechte auf sensible Patientendaten hatten. Über die für einen weiten Kreis der Mitarbeiterschaft zugängliche Suchfunktion konnten letztlich Daten zu allen seit Einführung des KIS behandelten Patientinnen und Patienten abgerufen werden.

Ich habe das Klinikum - auch in Anbetracht der COVID-19-Pandemie - über einen längeren Zeitraum bei dem Versuch begleitet, die festgestellten Mängel zu beheben. Dabei kam es immer wieder zu Verzögerungen und Problemen bei der Umsetzung eines geeigneten Rollen- und Berechtigungskonzepts, so dass im Berichtszeitraum vermehrt Art. 33 DSGVO-Meldungen zu unbefugten Zugriffen durch Beschäftigte bei mir eingingen. Dabei wurden mehrmals Personen im Verwandten- und Bekanntenkreis ohne deren Kenntnis abgefragt und die gewonnenen Informationen zu eigenen Zwecken verwendet. Mir blieb schließlich nur, das Klinikum nach Art. 58 Abs. 2 Buchst. d DSGVO unter Androhung eines Zwangsgelds zur Umsetzung eines adäquaten Rollen- und Berechtigungskonzepts anzuweisen, um eine Behebung der bestehenden Missstände zu erreichen. Da sich das Klinikum im Wettbewerb mit nicht-öffentlichen Krankenhäusern befindet, wäre auch die Verhängung eines Bußgelds nach Art. 83 DSGVO möglich gewesen. Da es jedoch nicht mein primäres Ziel ist, das Klinikum finanziell zu schädigen, sondern einen datenschutzkonformen Zustand herzustellen, habe ich von dieser Möglichkeit einstweilen noch Abstand genommen, behalte mir dies aber für vergleichbare Fälle ausdrücklich vor.

11.12. Forschungsprojekt RACOON, Anonymisierung/Pseudonymisierung und KI in der medizinischen Forschung

Seit April 2022 habe ich mich im Rahmen meiner Beteiligung an der Taskforce Forschungsdaten der DSK ausführlich mit dem Projekt RACOON (Radiological Cooperative Network) befasst, an dem alle deutschen Universitätsklinika beteiligt sind. Im Rahmen dieses Projekts wurde eine bundesweite Netzwerkinfrastruktur zur strukturierten Erfassung, Bereitstellung und Zusammenführung radiologischer Daten von COVID-19-Fällen geschaffen. Neben der eigentlichen Beantwortung von Forschungsfragen, wie dies auch in der Vergangenheit in multizentrischen Projekten üblich war, steht in diesem Projekt speziell das Thema Maschinelles Lernen (ML)/Künstliche Intelligenz (KI) mit im Zentrum. Im Rahmen des Projekts sollen ML-/KI-Verfahren zur Auswertung von Bilddaten entwickelt (die erhobenen radiologischen Daten werden als Trainingsdaten für ML/KI verwendet) als auch Forschungsfragen unter Hinzuziehung von ML/KI beantwortet werden. Das Projekt wirft eine Vielzahl interessanter Fragen aus Sicht des technisch-organisatorischen Datenschutzes auf, deren Beantwortung auch für andere Projekte in diesem Bereich von Bedeutung ist.

Zentral ist die Frage, ob die im Projekt verarbeiteten Daten anonymisiert sind oder ob nur eine Pseudonymisierung möglich ist. Die Datenschutz-Grundverordnung enthält keine Definition der Anonymisierung; das Verständnis ist uneinheitlich.

Der Europäische Datenschutzausschuss überarbeitet derzeit die Leitlinien zur Anonymisierung und Pseudonymisierung, hinsichtlich der Begrifflichkeit und der praktischen Umsetzung und Bewertung von technisch-organisatorischen Maßnahmen mehr Klarheit zu schaffen.

Allgemein ist beim Einsatz von Anonymisierungstechniken zu beachten, dass eine (Re-)Identifizierung nicht nur dann möglich sein kann, wenn Datensätze die identifizierenden Daten eines Patienten (insbesondere den Namen) enthalten, sondern auch, wenn ein Datensatz in verschiedenen Datenbeständen wiedererkannt werden kann und somit eine Profilbildung möglich wäre. Für die Beurteilung der Frage der Anonymisierung im Rahmen von Projekten wie RACOON spielen daher etwa folgende Kriterien eine Rolle:

• Nutzung großer Datenmengen, Verknüpfung von Datenbeständen: Je umfassender, strukturierter und feingranularer ein Datenbestand zu einer Person ist und je mehr Forscherinnen und Forscher diesen Datenbestand über längere Zeiträume nutzen können, umso wahrscheinlicher wird es, dass Daten über einen Abgleich oder eine Verknüpfung mit anderen Datenbeständen sowie Zusatzwissen aus anderen Quellen reidentifiziert werden können.
• Nutzung von Radiologiedaten: Bilddaten wurden in der Vergangenheit in vielen Fällen als anonymisiert angesehen, wenn gewisse Bereiche wie etwa der Kopf nicht erfasst waren und die Metadaten entfernt wurden. Durch die Verwendungen von ML/KI-Verfahren, deren besondere Stärke das Finden von Korrelationen in großen Datenbeständen ist, muss diese Einschätzung jedoch kritisch hinterfragt werden, gerade wenn derartige Datenbestände auch anderen Forschergruppen (die wiederum Zugang zu weiteren Datenbeständen haben) zugänglich gemacht werden. Dies machen auch erste Forschungsarbeiten im Bereich der Reidentifizierung von Daten deutlich.
• Datennutzung zum Training von ML/KI-Verfahren: ML/KI-Verfahren werden auf Basis von Daten trainiert. Soweit es sich nicht sicher um anonyme oder anonymisierte Daten handelt, besteht ein gewisses Risiko der Extraktion von personenbezogenen Trainingsdaten und somit einer Reidentifizierung, auch wenn die Trainingsdaten eigentlich nicht mit dem ML/KI-Verfahren "mitgeliefert" werden (Schlagwort "memorization"). Dies muss gerade bei sensiblen medizinischen Daten sicher verhindert werden.
• Nutzung von ML/KI-Verfahren im Behandlungszusammenhang zur Beantwortung von Forschungsfragen: Häufig liefern gängige ML/KI-Verfahren zwar ein Ergebnis, die Nutzerin oder der Nutzer hat jedoch keine Möglichkeit zu überprüfen, aufgrund welcher Informationen und Bewertungen das ML/KI-Verfahren auf dieses Ergebnis gekommen ist. Dies entspricht nicht den in der Datenschutz-Grundverordnung verankerten Transparenzanforderungen, die greifen, sobald eine Verarbeitung von personenbezogenen oder personenbeziehbaren Daten nicht sicher ausgeschlossen werden kann, und kann auch aus Sicht der ärztlichen Haftung zu Schwierigkeiten führen. Werden daher im Rahmen von Forschungsprojekten ML/KI-Verfahren entwickelt, sollten die Aspekte der Transparenz und Nachvollziehbarkeit mitberücksichtigt werden.
• Berücksichtigung der Verordnung über Künstliche Intelligenz: Dieser europäische Rechtsakt, der nach dem Berichtszeitraum in Kraft getreten ist, aber noch nicht gilt, sieht Risikoklassen bezüglich ML/KI-Verfahren vor, aus denen sich die erforderlichen Maßnahmen oder auch Nutzungsbeschränkungen ergeben. Auch für Forschungsprojekte im Gesundheitsbereich, die ML/KI-Verfahren nutzen oder entwickeln, sollten daher frühzeitig die Einstufung und ihre Folgen geprüft werden. Dabei ist insbesondere zu beachten, dass auch hier eine Rechtsgrundlage für die Verwendung von personenbezogenen Daten zu Trainingszwecken erforderlich ist: Die Verordnung über Künstliche Intelligenz sieht zukünftig außerdem die Einführung von "KI-Reallaboren" vor, in denen neue Technologien erprobt werden können. Dort sollen auch medizinische Daten verarbeitet werden können, die rechtmäßig erhoben sind.

11.13. Anforderungen an Kontaktinformation zum behördlichen Datenschutzbeauftragten: inkonsistente Information für eine Kontaktaufnahme mit dem Datenschutzbeauftragten

Im Rahmen einer Eingabe habe ich festgestellt, dass eine bayerische Kommune in unterschiedlichen Bereichen ihres Internetauftritts Kontaktdaten für ihren behördlichen Datenschutzbeauftragten auswies. Die Kontaktdaten waren jedoch teilweise veraltet und stimmten nicht überein. Diese inkonsistente Information konnte dazu führen, dass Bürgerinnen und Bürger im Zusammenhang mit datenschutzrechtlichen Fragestellungen zu Personen, die nicht als behördlicher Datenschutzbeauftragter von der Kommune benannt waren, in der Annahme, mit dem Datenschutzbeauftragten zu sprechen, Kontakt aufnahmen. Die oder der aktuelle Datenschutzbeauftragte ist auch nicht immer bei mir gemeldet oder im BayernPortal angegeben. Bayerische öffentliche Stellen sind gemäß Art. 37 Abs. 7 DSGVO verpflichtet, die Kontaktdaten ihrer oder ihres Datenschutzbeauftragten geeignet zu veröffentlichen und an mich zu melden, insbesondere auch im Falle von Änderungen. Genaueres hierzu kann in meiner einschlägigen Orientierungshilfe nachgelesen werden.

169. Siehe die Ausführungen in meinem 32. Tätigkeitsbericht 2022 unter Nr. 12.2. [Zurück]
170. Weitere Details: Bayerischer Landesbeauftragter für den Datenschutz, Datenschutz als Kriterium im Vergabeverfahren, Stand 2/2024, Internet: https://www.datenschutz-bayern.de, Rubrik "Datenschutzreform 2018". [Zurück]
171. Internet: https://www.cnil.fr/en/privacy-impact-assessment-pia (externer Link). [Zurück]
172. Internet: https://www.cnil.fr/en/open-source-pia-software-helps-carry-out-data-protection-impact-assesment (externer Link). [Zurück]
173. Internet: https://github.com/LINCnil/pia (externer Link) und https://github.com/kosmas58/pia-app/ (externer Link) releases. [Zurück]
174. Aktuelles Informationsangebot im Internet: https://www.datenschutz-bayern.de, Rubrik DSFA. [Zurück]
175. Näher Bayerischer Landesbeauftragter für den Datenschutz, Meldepflicht und Benachrichtigungspflicht des Verantwortlichen, Orientierungshilfe, Stand 6/2019, Rn. 88 ff., Internet: https://www.datenschutz-bayern.de, Rubrik "Datenschutzreform 2018". [Zurück]
176. Beispielsweise Packhäuser u. a., Deep learning-based patient re-identification is able to exploit the biometric nature of medical chest X-ray data, Sci Rep 12, 14851 (2022), Internet: https://doi.org/10.1038/s41598-022-19045-3 (externer Link). [Zurück]
177. Siehe etwa Carlini u. a., Extracting Training Data from Large Language Models, Internet: https://www.usenix.org/conference/usenixsecurity21/presentation/carlini-extracting (externer Link). [Zurück]
178. Verordnung (EU) 2024/1689 des Europäischen Parlaments und des Rates vom 13. Juni 2024 zur Festlegung harmonisierter Vorschriften für künstliche Intelligenz und zur Änderung der Verordnungen (EG) Nr. 300/2008, (EU) Nr. 167/2013, (EU) Nr. 168/2013, (EU) 2018/858, (EU) 2018/1139 und (EU) 2019/2144 sowie der Richtlinien 2014/90/EU, (EU) 2016/797 und (EU) 2020/1828 (Verordnung über künstliche Intelligenz) (ABl. L 2024/1689 vom 12. Juli 2024). [Zurück]
179. Bayerischer Landesbeauftragter für den Datenschutz, Der behördliche Datenschutzbeauftragte, Stand 5/2018, Internet: https://www.datenschutz-bayern.de, Rubrik "Datenschutzreform 2018". [Zurück]