Sie sind hier: > Start > Tätigkeitsberichte > 31. TB 2021 > 10. Technik und Organisation

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

10. Technik und Organisation

10.1. COVID-19-Pandemie, Digitalisierung und Datenschutz

Immer wieder ist aus Politik und Medien zu hören, dass notwendige Digitalisierungen im Gesundheitswesen sowie die Nutzung von Datenbeständen zur Bekämpfung der COVID-19-Pandemie auf Grund des Datenschutzes nicht möglich seien. Zudem wird in diesem Zusammenhang nicht selten darauf verwiesen, dass andere Länder in Europa, wie etwa Spanien oder die skandinavischen Länder, bereits "viel weiter" seien. Schon dieser Hinweis widerlegt die grundsätzliche Kritik, dass zukunftsträchtige Projekte an strengen Datenschutzregeln scheitern: Denn auch in den als Vorbild genannten Ländern gilt die Datenschutz-Grundverordnung.

Gerade bei der Bekämpfung der COVID-19-Pandemie bietet die Digitalisierung große Chancen, die auch aus Datenschutzsicht genutzt werden sollten. Gleichwohl geben Beratungsanfragen aus Anlass einschlägiger Projekte mitunter Gelegenheit, auf eine datenschutzrechtliche Optimierung hinzuwirken. So begegnen mir neben datenschutzrechtlich offenkundig nicht tragfähigen Ansätzen auch immer wieder Projekte, die als Insellösungen ohne eine mir erkennbare Gesamtkonzeption und ohne gründliche Prüfung der Bedarfe sowie der Gegebenheiten vor Ort initiiert werden. In meiner Beratungs- und Prüfungspraxis zeigen sich insbesondere folgende Probleme, die eine übergreifende Digitalisierung im Gesundheitswesen in Deutschland vergleichsweise schwerer machen als in anderen europäischen Ländern:

• Fehlende Nutzung von Synergien und Schnittstellen zum Datenaustausch

  Im Gegensatz zu Ländern mit einer hoch zentralisierten Gesundheitsversorgung existiert in Deutschland, auch in Bayern, eine Vielzahl unterschiedlicher Träger für Krankenhäuser, Pflegeheime und andere Gesundheitseinrichtungen, die alle jeweils selbständig agieren und somit auch selbst über ihre IT-Ausstattung, Prozesse und Methoden der Datenverarbeitung entscheiden. Dies führt beispielsweise dazu, dass selbst bei Verwendung des gleichen Krankenhausinformationssystems in verschiedenen Krankenhäusern Unterschiede in der Auswahl der verwendeten Module, der Gestaltung der Arbeitsumgebung, der Prozesse und somit auch der gespeicherten Daten entstehen. Dies hat zur Folge, dass jedes Krankenhaus selbst Konzepte zur IT-Sicherheit, zum Berechtigungs- sowie Löschmanagement oder ähnlichen Rahmenbedingungen erstellen muss und in den meisten Fällen schon bayernweit über die gesetzlich vorgegebenen Abrechnungsformate hinaus keine einheitlichen Datenaustauschformate vorhanden sind. Dies erschwert es, die notwendigen Daten-sätze für die Forschung, statistische oder auch epidemiologische Auswertungen unkompliziert zur Verfügung zu stellen.

  Im Rahmen der Pandemiebekämpfung wurden zwar Meldepflichten - und damit verbunden elektronische Meldewege und Datenformate - für einzelne Informationen, etwa die Belegung der Intensivbetten oder die Anzahl der behandelten COVID-19 Fälle, festgelegt. Je länger die COVID-19-Pandemie andauert, zeigt sich jedoch, dass deutlich mehr Daten, wie beispielsweise zum Impfstatus oder zum Gesundheitszustand für die Bewertung der Pandemielage, die Einladung zur Impfung oder für Forschungsfragen benötigt würden. Hierzu ist mir bisher kein Vorschlag für ein Gesamtkonzept bekannt geworden, das ich aus Datenschutzsicht hätte prüfen können. Es wäre aus meiner Sicht Aufgabe der Politik sowie der Selbstverwaltung im Gesundheitswesen, einheitliche Datenaustauschformate sowohl semantisch als auch technisch klar zu definieren, so dass diese von den Software-Anbietern und Krankenhäusern einheitlich und standardisiert umgesetzt werden können.

• Fehlende Gesamtstrategie und Integration von Anwendungen zur digitalen Unterstützung der Pandemiebekämpfung

  Bereits in meinem 30. Tätigkeitsbericht 2020 unter Nr. 3.5 habe ich mich zur fehlenden einheitlichen technischen Basis hinsichtlich der Möglichkeit der sicheren elektronischen Kommunikation der an der Pandemiebekämpfung beteiligten Stellen geäußert.

  Im Berichtszeitraum wurden zur IT-technischen Unterstützung der Pandemiebekämpfung zwar einzelne Lösungen wie SORMAS (siehe Nr. 10.2.1) oder Luca (siehe Nr. 10.2.4) eingeführt. Aber auch hier handelt es sich um punktuelle IT-Einzellösungen, ohne dass zuvor eine geeignete Gesamtkonzeption für die Digitalisierung der Gesamtabläufe deutschlandweit, zumindest aber bayernweit, erstellt worden wäre.

  Die Praxis zeigt, dass sich sowohl bei der Einführung von SORMAS als auch von Luca in den Gesundheitsämtern gerade die Integration in die bestehenden Prozesse und IT-Systeme als schwierig erwies und auch vor der politischen Entscheidung zum verpflichtenden Einsatz nicht hinreichend getestet wurde. Die bayerischen Gesundheitsämter erhielten zwar von den Systemanbietern Unterstützung bei der Installation und Inbetriebnahme der Anwendungen selbst, jedoch blieb die Frage der Integration in bestehende Prozesse, Anwendungen und die IT-Landschaften den einzelnen Gesundheitsämtern selbst überlassen. Auch die von den Anbietern mitgelieferten Schnittstellen zwischen beiden Anwendungen erwiesen sich in der Praxis als nur schwer nutzbar. Wie sich herausstellte, wurde für den Export aus Luca und den anschließenden Import in SORMAS in der Praxis hauptsächlich die Microsoft Office-Anwendung Excel ohne ausreichende Sicherheitsmaßnahmen genutzt, so dass es Sicherheitsforscherinnen und Sicherheitsforschern gelang, bei dieser Schnittstelle Schadcode einzuschleusen.

  Des Weiteren musste für den Datenabruf durch die Gesundheitsämter ein gesondertes, von Luca bereitgestelltes Portal genutzt werden, was für die Gesundheitsämter zu zusätzlichem Schulungsaufwand, zur Einrichtung einer gesonderten Benutzerverwaltung und zu weiteren Sicherheitsmaßnahmen geführt hat. Eine direkte Nutzung der Luca-Daten aus SORMAS heraus war nicht möglich.

  Diese Beispiele unterstreichen die Wichtigkeit einer systematischen Gesamtkonzeption für die Digitalisierung von Abläufen. Denn nur so können Systembrüche, Doppelarbeiten aufgrund inkompatibler Einzelanwendungen sowie Sicherheitsprobleme vermieden werden. Derartige konzeptionelle Arbeiten können die einzelnen Gesundheitsämter in der Pandemiesituation nicht leisten. Die bestehenden Synergiepotenziale müssten daher genutzt und die notwendigen Konzepte auf Landes- oder Bundesebene erstellt werden.

• Fehlende einheitliche technische Möglichkeiten zur Kommunikation mit Bürgerinnen und Bürgern

  Wie unter Nr. 10.3 ausführlicher dargestellt, bestehen für die beteiligten Stellen und insbesondere die Gesundheitsämter nach wie vor große Schwierigkeiten, mit Bürgerinnen und Bürgern sicher und rechtzeitig elektronisch in Kontakt zu treten. Üblicherweise muss nach der mittlerweile in der Regel elektronisch erfolgenden "Erstmeldung" beispielsweise durch ein Labor, eine Teststation oder die digitale Einreiseanmeldung die weitere Abwicklung (zum Beispiel Vorlage von weiteren Dokumenten) in jedem Gesundheitsamt selbständig umgesetzt werden, da Luca und SORMAS die gesamten weiteren Kommunikationswege der "Contact Tracing Teams" nicht mit umfassen. Hier wären bayernweit einheitliche Lösungen, etwa auf Basis des schon bestehenden BayernPortals, wichtig, die jedoch nicht auf der Ebene der Gesundheitsämter konzipiert werden können.

Insgesamt ist festzuhalten, dass die Digitalisierung und die Akzeptanz digitaler Anwendungen sowohl im Rahmen der Pandemiebekämpfung als auch sonst nur dann erfolgreich sein werden, wenn hierfür systematische und plausible Gesamtkonzepte erstellt und diese flächendeckend und strukturiert umgesetzt werden. Es wäre wünschenswert, dass die auftraggebenden oder beschaffenden Stellen derartige Aspekte von Anfang an mit berücksichtigen. Denn so können die grundsätzlichen Auswirkungen auf die Datenschutzrechte betroffener Personen wie auch der Aufwand und der Nutzen für die einsetzenden Stellen von Anfang an die notwendige Beachtung finden. Doppelerfassungen, fehlende Schnittstellen und ineffiziente Prozesse könnten dadurch vermieden werden und sich nicht zu Datenschutzproblemen entwickeln. Die Geschwindigkeit bei der Einführung von Verfahren sollte gerade außerhalb kurzfristiger Handlungszwänge der Pandemiebekämpfung nicht das Hauptkriterium für die Beurteilung von neuen Anwendungen und IT-Systemen sowie die Entscheidungsfindung sein.

10.2. IT-Systeme zur Bewältigung der COVID-19-Pandemie

Auf Grund der COVID-19-Pandemie habe ich mich eingehend mit den datenschutzrechtlichen Grundlagen und den technisch-organisatorischen Maßnahmen der Kontaktnachverfolgung bei Infektionsgeschehen sowie dem Impfmanagement beschäftigt. Hierzu wurden im Berichtszeitraum bayernweit neue IT-Systeme für die Gesundheitsämter und Impfzentren eingeführt, die eine intensive Befassung aus Datenschutzsicht erforderlich machten. Solche Systeme verarbeiten Gesundheitsdaten, die nach Art. 9 DSGVO besonderen Schutz genießen (personenbezogene Speicherung von Quarantäne-Anordnungen, Test-Ergebnissen, Impfungen, Vorerkrankungen usw.). In den nächsten Abschnitten kommen zur Sprache:

• die Einführung von SORMAS (Surveillance Outbreak Response Management Analysis System) in allen bayerischen Gesundheitsämtern zur Kontaktverfolgung (siehe Nr. 10.2.1),
• BayIMCO (Bayerisches Impfmanagement gegen Corona) für die Impfzentren zum Impfmanagement und zur Impfanmeldung für die Bürgerinnen und Bürger (siehe Nr. 10.2.2) sowie
• die Luca-App zur elektronischen Kontaktdatenverfassung bei Veranstaltern zum Abruf durch die Gesundheitsämter (siehe Nr. 10.2.4).

Zudem war ich in die technische Bewertung von IT-Systemen auf Bundesebene eingebunden, so bei der Corona-Warn-App (CWA) oder dem digitalen Impfnachweis.

10.2.1. SORMAS

Um die Bearbeitung von COVID-19-Kontaktfällen in den Gesundheitsämtern zu unterstützen und zu vereinheitlichen, wurde im November 2020 von Bund und Ländern der bundesweite Einsatz des elektronischen Verfahrens SORMAS (Surveillance Outbreak Response Management Analysis System) beschlossen. Dies wurde von mir in Hinblick auf die bayerischen Gesundheitsämter ausführlich begleitet.

Ursprünglich wurde das Verfahren vom Robert-Koch-Institut (RKI), dem Helmholtz-Zentrum für Infektionsforschung (HZI) und weiteren Partnern für die Infektionsüberwachung und das Ausbruchsmanagement in den Schwellen-Ländern entwickelt. Eine erste Version kam bereits 2014 in Westafrika beim Ausbruch von Ebola und später 2017 in Nigeria bei Ausbruch der Affenpocken erfolgreich zum Einsatz. Bei diesen Epidemien konnten mit Hilfe des Verfahrens Infektionsherde sowie Infektionsüberträgerinnen und Infektionsüberträger frühzeitig und zeitnah verfolgt und dokumentiert werden. Mittlerweile befindet sich SORMAS weltweit im Einsatz.

Das HZI hat SORMAS speziell für den öffentlichen Gesundheitsdienst in Deutschland angepasst. Da sich SORMAS bereits in der Praxis bewährt hatte, wurde es als Basis gewählt, auf der aufbauend ein gemeinsames Verfahren bundesweit zur Kontaktnachverfolgung entstehen konnte. Bei SORMAS handelt sich jedoch nicht um ein Zentralsystem, bei dem alle Daten nur bei einer Stelle gespeichert werden; vielmehr ist eine dezentrale Datenspeicherung entweder bei den Gesundheitsämtern selbst oder beim Informationstechnikzentrum Bund (ITZBund, zentraler IT-Dienstleister für die deutsche Bundesverwaltung) als Dienstleister möglich. In einem solchen Fall wird für jedes Gesundheitsamt ein eigener Mandant angelegt.

Mit einem einheitlichen Verfahren kann auf den Einsatz unterschiedlicher proprietärer Eigenentwicklungen in den verschiedenen Bundesländern und Gesundheitsämtern verzichtet werden, die untereinander inkompatibel sind und dadurch zu Problemen beim Datenaustausch führen können. Zudem bringen lokale Einzelsysteme häufig Schwierigkeiten hinsichtlich der Datensicherheit mit sich, da bei proprietären Lösungen häufig eine umfassende Betrachtung hinsichtlich der IT-Sicherheit und der erforderlichen Maßnahmen unterbleibt. Für SORMAS wurde dagegen eine zentrale Datenschutz-Folgenabschätzung (DSFA) erstellt, die dem Bundesbeauftragen für den Datenschutz und die Informationsfreiheit und den Datenschutz-Aufsichtsbehörden der Länder zur Beurteilung vorlag.

Aus Datenschutzsicht traten während des schrittweisen Roll-Outs von SORMAS an den bayerischen Gesundheitsämtern insbesondere folgende Fragen auf:

• Die sogenannten Contact-Tracing-Teams (CTT) hatten bereits vor dem Einsatz von SORMAS überwiegend elektronische Verfahren genutzt. Ein wesentliches Werkzeug war hier neben Standard-Bürosoftware (vor allem Microsoft Office-Produkten) insbesondere das bayerische Online-Portal "BaySIM" (Bayerisches System für Infektionskettenmanagement).

  Neben der Einführung von SORMAS stellte sich auch die Frage des Umgangs mit dem bereits vorhandenen Datenbestand. Die Daten wurden weiter benötigt; zugleich mussten Anforderungen an die Datensicherheit erfüllt werden. Hierfür bietet SORMAS spezielle REST-Schnittstellen (Representational State Transfer) zum Datenimport, bei welchen allerdings noch Klärungsbedarf bzgl. der Umsetzung bestand.

  Zudem besteht die Möglichkeit, ein digitales Symptom-Tagebuch für die betroffenen Kontaktpersonen anzubinden. Hierfür hat das Bundesministerium für Gesundheit in Zusammenarbeit mit der Firma Climedo Health GmbH unter Einbezug des RKI, des Bundesamtes für Sicherheit in der Informationstechnik (BSI) und des Bundesbeauftragten für den Datenschutz und die Informationsfreiheit eine Lösung entwickelt. Auch hier war die Schnittstellenbeschreibung zunächst unvollständig.

  Ebenso waren die Schnittstellendefinitionen zum Datenaustausch zwischen den Gesundheitsämtern sowie mit dem RKI nicht von Anfang an verfügbar, so dass aus Datenschutzsicht auch hier Klärungsbedarf bestand.

• Ein weiterer offener Punkt war die zum Einführungszeitpunkt von SORMAS noch unvollständige Datenschutz-Folgenabschätzung. Insbesondere das Risiko- und Zielerfüllungsmanagement entsprach noch nicht vollumfänglich den Anforderungen des Art. 35 DSGVO und musste entsprechend nachgebessert werden.

  Zudem ist bei zentral bereitgestellten Datenschutz-Folgenabschätzungen immer zu beachten, dass diese nicht die örtlichen Gegebenheiten und technisch-organisatorischen Maßnahmen umfassen können, da sich diese von Gesundheitsamt zu Gesundheitsamt unterscheiden. Die entsprechende Analyse der Risiken für die Rechte und Freiheiten der betroffenen Personen musste daher zusätzlich vor Ort durchgeführt werden.

• Schließlich mussten die weiteren von Seiten des HZI vorgelegten Unterlagen, etwa das Datenschutz- und Sicherheitskonzept sowie das Löschkonzept, im Hinblick auf die Vorgaben der Datenschutz-Grundverordnung angepasst werden.

  Beispielweise erweckten diese Unterlagen den Eindruck, dass eine automatisierte Löschung gewisser Daten nicht vorgesehen sein soll. Unter dem Blickwinkel des Grundsatzes der Speicherbegrenzung (Art. 5 Abs. 1 Buchst. e DSGVO) habe ich mich daher dafür eingesetzt, dass systemseitig Voreinstellungen für Löschfristen vorgesehen werden.

Zuletzt rückte SORMAS erneut in den Fokus, als in den Medien Schwachstellen der Software aufgedeckt wurden. Unter anderem seien anfänglich bei jeder Installation des Programms ungesicherte Standard-Test-Accounts angelegt worden, in deren Quellcode nicht änderbare Passwörter gespeichert worden wären. Solche Standard-Accounts mit statischen Passwörtern verstoßen gegen die in Art. 32 DSGVO geforderte Einhaltung der Sicherheit der Verarbeitung, insbesondere wird das in Erwägungsgrund 78 DSGVO als Konkretisierung für "geeignete technische und organisatorische Maßnahmen" empfohlene Mittel der datenschutzfreundlichen Voreinstellung (data protection by default) unterwandert.

Mittlerweile hat das HZI die Konfiguration so geändert, dass keine Default-Logins mehr angelegt werden. Allerdings ändert dies nichts an der Problematik, die bei bereits bestehenden Installationen vorliegt.

Die deutschen Gesundheitsämter wären zudem nach Angaben des HZI von diesem Problem in der Regel gar nicht betroffen, wenn sie die vom Bundesministerium für Gesundheit ausgelieferte und beim ITZBund betriebene SORMAS-Instanz verwenden würden. Diese wird von einem Dienstleister zentral betrieben und verzichtet auf Standard-Accounts.

Da SORMAS nach wie vor weiterentwickelt wird, werde ich das Projekt auch weiterhin kritisch begleiten.

10.2.2. BayIMCO: Software für das Bayerische Impfmanagement

Einen Schwerpunkt sowohl hinsichtlich der technisch-organisatorischen Beratung bayerischer öffentlicher Stellen als auch bezüglich der Beschwerden von Bürgerinnen und Bürgern stellten im Berichtszeitraum die technischen und organisatorischen Maßnahmen rund um das Bayerische Impfmanagement dar.

Als Ende 2020 in den kreisfreien Städten und Landkreisen mit der Planung und Einrichtung von Impfzentren begonnen wurde, gab das Bayerische Staatsministerium für Gesundheit und Pflege die Entwicklung einer einheitlichen bayerischen Softwarelösung für die elektronische Impfanmeldung und die Impfverwaltung (BayIMCO) in Auftrag. Ich begrüße, dass mich das Gesundheitsministerium frühzeitig in die rechtliche wie auch technisch-organisatorische Beurteilung eingebunden und eine ausführliche Datenschutz-Folgenabschätzung vorgelegt hat. Das Gesundheitsministerium erstellte zudem frühzeitig ausführliche Datenschutzinformationen für die Bürgerinnen und Bürger; diese lagen mir rechtzeitig zur Prüfung vor.

Seit dem 11. November 2021 ist BayIMCO in allen bayerischen Impfzentren im Einsatz und somit auch das Portal zur Impfanmeldung (https://impfzentren.bayern (externer Link)) online. Teilweise schon zuvor vorhandene regionale Impfanmeldungssysteme sollten seit diesem Zeitpunkt deaktiviert sein.

Die Impfanmeldung und Impfabwicklung erfolgt aus Datenverarbeitungssicht in zwei Schritten: Beim Anlegen eines Accounts in BayIMCO werden zwar sowohl die Kontaktdaten als auch die Daten, die zur Ermittlung der Impfpriorität erforderlich sind (wie etwa Vorerkrankungen, Wohnsituation, berufliche Situation) erfasst, aber nur die Kontaktdaten tatsächlich gespeichert. Die übrigen zu diesem Zeitpunkt eingegebenen Daten werden aus Gründen der Datensparsamkeit noch nicht gespeichert, da es sich teilweise um Daten mit hohem Schutzbedarf handelt (insbesondere Gesundheitsdaten im Sinne von Art. 4 Nr. 15 DSGVO), die erst erforderlich sind, wenn tatsächlich eine Impfung erfolgt. Dies hat zur Folge, dass diese Daten im Zuge der späteren, konkreten Terminfestlegung noch einmal angegeben werden müssen.

Nach Abschluss beider Impfungen stehen die in BayIMCO gespeicherten Daten nicht mehr zum Abruf durch die Impfzentren zur Verfügung, sondern werden in ein Impfarchiv überführt, in dem die Daten bis zum Ende der Aufbewahrungspflicht für gesetzlich vorgegebene Zwecke (Haftung, Forschung) aufbewahrt werden. Dabei erfolgt eine Trennung zwischen den identifizierenden Daten der Impflinge und den sonstigen Impfdaten, so dass ein Zugriff mit Personenbezug nur unter Beteiligung einer gesonderten Vertrauensstelle nach einem festgelegten Verfahren möglich ist. Für Forschungszwecke darf ein derartiger Zugriff zur Ermöglichung einer anschließenden Kontaktaufnahme mit dem Impfling nur erfolgen, wenn dieser darin bei seiner Impfanmeldung eingewilligt hat. Das Impfarchiv ist organisatorisch dem Bayerischen Landesamt für Gesundheit und Lebensmittelsicherheit zugeordnet, der technische Betrieb liegt beim IT-Dienstleistungszentrum des Freistaats Bayern.

Zudem werden die Daten in pseudonymisierter Form in einer gesonderten Datenbank zum Zweck des Impfmonitorings gespeichert.

Abhängig von der Gesamtentwicklung der COVID-19-Pandemie ist auch zukünftig mit Erweiterungsbedarf bei BayIMCO zu rechnen. Beispielsweise mussten im Juni 2021 Ergänzungen vorgenommen werden, um eine Ausstellung digitaler Impfnachweise zu ermöglichen. Auch hier hat mich das Gesundheitsministerium frühzeitig eingebunden. Weiterer Änderungsbedarf könnte sich beispielsweise aus dem Wegfall der Impfpriorität oder den Erfordernissen weiterer Folgeimpfungen ergeben.

10.2.3. Beschwerden zu technischen Belangen des Bayerischen Impfmanagements

Im Berichtszeitraum sind eine Vielzahl von Beschwerden und Anfragen von Bürgerinnen und Bürgern zum Impfportal eingegangen. Konnten Mängel festgestellt werden, hat das Gesundheitsministerium stets eine rasche Anpassung veranlasst. Im technischen Bereich betrafen Beschwerden insbesondere die folgenden Themen:

10.2.3.1. Vermeintliches Hosting in einem unsicheren Drittstaat

Mehrere Beschwerden vertraten die Auffassung, dass BayIMCO in den Vereinigten Staaten von Amerika (USA) gehostet sei. So wurde der IP-Adresse von BayIMCO über die Geolokation die geographische Herkunft "USA" bescheinigt. Die Datenschutzerklärung von BayIMCO gab allerdings ein Hosting in Deutschland an. Nicht nur dieser Widerspruch, sondern auch die Sorge um die Speicherung von Gesundheitsdaten in einem unsicheren Drittland begründeten die Beschwerden.

Eine von mir eingeholte Stellungnahme des Gesundheitsministeriums hebt hervor, dass personenbezogene Daten in BayIMCO niemals außerhalb Deutschlands gespeichert worden seien. Lediglich die IP-Range, zu der die verwendete IP-Adresse gehört, wurde in den USA erstanden. Inzwischen hat das Gesundheitsministerium veranlasst, dass die Geolokation den korrekten Standort des Rechenzentrums ausweist.

10.2.3.2. Einwilligung zur Weitergabe von Daten an Forschungsstellen

Im Rahmen der Anmeldung zur Impfung über BayIMCO wird die Einwilligung zur Weitergabe von Daten an Forschungseinrichtungen abgefragt. In einer frühen Software-Version wurde wohl nicht eindeutig auf die Freiwilligkeit dieser Einwilligung hingewiesen, so dass es zu Beschwerden beim Gesundheitsministerium kam.

Auch mir teilte ein Beschwerdeführer mit, dass bei der Impfanmeldung die Einwilligung in eine solche Weitergabe in Bezug auf Kontaktdaten bereits vorab ausgewählt war. Da der Petent diesen Umstand bei der Impfanmeldung erkannte, er seine Einwilligung jedoch nicht geben wollte, bat er im Impfzentrum um Entfernung der vorangekreuzten Einwilligung. Das Impfpersonal vor Ort konnte diese Vorauswahl aus technischen Gründen allerdings nicht aus dem Datensatz entfernen. Stattdessen wurde dem Impfwilligen mitgeteilt, dass eine Impfung ohne diese Einwilligung nicht möglich sei, er aber im Nachgang die Einwilligung widerrufen könne.

Die Einwilligung ist allerdings nur dann wirksam, wenn sie die Anforderungen aus Art. 6 Abs. 1 UAbs. 1 Buchst. a, Art. 4 Nr. 11 und Art. 7 Abs. 2 und 3 DSGVO erfüllt. Insbesondere muss die Einwilligung freiwillig erteilt sein. Die Freiwilligkeit war in der konkreten Situation allerdings ausgeschlossen, da auf den Impfling mit der Aussage, sonst keine Impfung zu erhalten, Druck ausgeübt wurde.

In der Folge ließ das Gesundheitsministerium den Anmeldedialog anpassen und die Freiwilligkeit hinsichtlich der Erklärung einer Einwilligung deutlicher hervorheben. Ebenso wurde der Ausdruck des Impfbogens dahingehend verbessert, dass auch dort ein Hinweis zur Freiwilligkeit klar ersichtlich ist. So sollte nun allen Beteiligten verständlich sein, dass kein Zusammenhang zwischen dieser Einwilligung und der Durchführung der Impfung besteht.

10.2.4. Digitales Kontaktnachverfolgungssystem Luca

Für die Luca-App zur Kontaktnachverfolgung wurde Anfang des Jahres 2021 vom Freistaat Bayern eine Landeslizenz beschafft, die es privaten und öffentlichen Stellen in Bayern - insbesondere Veranstalterinnen und Veranstaltern sowie Gesundheitsämtern - ermöglicht, die App kostenlos einzusetzen. Damit sollte zum Ende des "Lockdowns" im Mai 2021 die eigentlich begrüßenswerte Möglichkeit bestehen, die Kontaktverfolgung elektronisch, medienbruchfrei und insbesondere für die Gesundheitsämter leichter zugänglich durchzuführen. Neben den unter Nr. 10.1 dargestellten grundsätzlichen Problemen haben sich hierzu auch einige praktische Schwierigkeiten ergeben, die teilweise den Nutzen der von Luca erfassten Daten in Frage stellen:

• Fehlende technische Detailprüfung, Sicherheitslücken

  Aufgrund des sehr kurz bemessenen zeitlichen Vorlaufs bei der Einführung von Luca und der Komplexität von App und Nutzungsszenario konnte weder von den Datenschutz-Aufsichtsbehörden noch von IT-Sicherheitsbehörden vor Einsatzbeginn eine detaillierte Prüfung hinsichtlich der IT-Sicherheit durchgeführt werden. Dies führte dazu, dass während des schon laufenden Betriebs Schwachstellen und Probleme entdeckt und mit großer Medienwirkung diskutiert wurden. Der Anbieter von Luca musste bezüglich der IT-Sicherheit mehrfach nachbessern. Auch Änderungsforderungen der Datenschutz-Aufsichtsbehörden im technischen Bereich konnten nicht vor dem Einsatz umgesetzt werden, sondern sind Ende 2021 immer noch in Bearbeitung. Die gewählte Herangehensweise führte letztendlich zu einem deutlichen Vertrauensverlust bei den Bürgerinnen und Bürgern, was die Nutzung von Luca betrifft.

• Fragliche Brauchbarkeit der Daten

  Wie in meiner frühzeitig veröffentlichten Sonderinformation zu Luca dargelegt, muss der Personenkreis beim Veranstalter möglichst so raum- und zeitbezogen erfasst werden, dass in Luca nur ansteckungsrelevante Personenkontakte verarbeitet werden. Hierzu sind beispielsweise an mehreren Stellen eines Veranstaltungsorts verschiedene QR-Codes erforderlich. Die Praxis zeigt jedoch, dass QR-Codes häufig mit zu großflächigem "Geltungsbereich" angebracht werden, etwa für ganze Biergärten, große Restaurants oder Kantinen. Damit ist für das Gesundheitsamt nicht mehr ersichtlich, welche Personen sich tatsächlich in infektionstauglicher Nähe befanden und somit als Kontaktpersonen gelten. Stattdessen liefert in diesen Fällen ein Datenabruf aus Luca eine große Anzahl vermeintlicher Kontakte, deren Verfolgung weder vom Aufwand noch vom Ertrag als angemessen erscheint.

• Fehlende Planung des Maßnahmenendes

  Bereits bei der Konzeption und spätestens bei der Einführung neuer Systeme und Anwendungen zur digitalen Pandemiebekämpfung sollte geklärt sein, wie ein "Ausstieg" vonstattengehen soll. So wurde beispielsweise in der 14. Bayerischen Infektionsschutzmaßnahmenverordnung (14. BayIfSMV) mit Wirkung ab dem 15. Oktober 2021 die Pflicht zur Kontaktdatenerfassung auf Schwerpunktbereiche mit einem hohen Risiko von Mehrfachansteckungen, wie zum Beispiel große Veranstaltungen, beschränkt. Trotz dieser wesentlichen Änderung waren noch Ende November 2021 an einer Vielzahl von Stellen - sogar in einer staatseigenen Kantine - QR-Codes zur Luca-Kontaktdatenerfassung angebracht, verbunden mit Hinweisen an die Besucherinnen und Besucher, sich bei Luca zu registrieren. Hierdurch besteht das Risiko, dass auch weiterhin in großem Umfang Daten erhoben werden, die jedoch von den Gesundheitsämtern nicht mehr verarbeitet werden dürfen. Zudem setzt bei den Bürgerinnen und Bürgern ein Gewöhnungseffekt ein, sich beim Zugang zu beliebigen Stellen "einzuchecken".

Wie in vielen anderen Bundesländern stand auch in Bayern zu Jahresbeginn die Frage nach der Verlängerung des Vertrags mit dem Betreiber von Luca um ein weiteres Jahr an. Aufgrund der oben geschilderten Probleme begrüße ich es, dass das Gesundheitsministerium Anfang 2022 entschieden hat, den Vertrag auslaufen zu lassen.

10.3. Elektronische Kommunikation im Rahmen des COVID19-Pandemiemanagements mit Bürgerinnen und Bürgern

Bereits in meinem 30. Tätigkeitsbericht unter Nr. 3.5 habe ich mich mit der elektronischen Kommunikation mit Bezug auf COVID-19-Fälle zwischen öffentlichen Stellen befasst. Gerade die Gesundheitsämter kommunizieren häufig auch mit Bürgerinnen und Bürgern in elektronischer Form, beispielsweise im Rahmen von Testanmeldungen und Ergebnisübermittlungen, des Impfmanagements oder bei Quarantänemaßnahmen.

Inhalte der Kommunikation sind häufig Gesundheitsdaten. Diese stehen nach Art. 9 DSGVO unter besonderem Schutz und müssen insbesondere ausreichend vor unbefugtem Zugriff gesichert werden.

Gesundheitsdaten sind nicht immer auf den ersten Blick als solche zu erkennen. So mag eine Benachrichtigung des Gesundheitsamts, dass sich eine Bürgerin oder ein Bürger auf Grund einer Einreise aus einem Risikogebiet in Quarantäne begeben muss, keine unmittelbaren Informationen über den konkreten Gesundheitszustand der betroffenen Person enthalten. Gleichwohl sind Quarantänebenachrichtigungen als Gesundheitsdaten im Sinne von Art. 4 Nr. 15 DSGVO zu werten, weil sie immerhin mittelbar Rückschlüsse auf den Gesundheitszustand der betroffenen Person ermöglichen, was eine mögliche Infektion mit dem Erreger SARS-CoV-2 betrifft.

10.3.1. Kommunikationsmöglichkeiten

Von Bedeutung sind insbesondere die folgenden Kommunikationswege:

• BayernPortal

  Ist eine Bürgerin oder ein Bürger im BayernPortal registriert, steht ihr oder ihm dort ein Postfach zur verschlüsselten Kommunikation zur Verfügung, das auch für den Austausch mit dem Gesundheitsamt genutzt werden kann.

  Da nicht alle Bürgerinnen und Bürger diese Option nutzen können oder wollen, kommt sie hauptsächlich für individuelle Kommunikationsbeziehungen in Betracht. Soll eine größere Zahl von Bürgerinnen und Bürgern auf einmal angesprochen werden, ist das BayernPortal derzeit noch im Nachteil.

• Cloud-Speicher

  Mehrere Anbieter stellen Cloud-Speicher bereit, in denen Dokumente für Bürgerinnen und Bürger zum Download hinterlegt und dann abgerufen werden können. Ebenso können Bürgerinnen und Bürger dort Dokumente hochladen. Über den Down- oder Uploadlink kann mittels E-Mail informiert werden.

  Downloads, die sensible Daten enthalten, müssen grundsätzlich über ein ausreichend komplexes Passwort geschützt werden. Das Passwort muss auf einem anderen Kommunikationsweg übermittelt werden als die Nachricht, die mit ihm entschlüsselt werden soll. Das Passwort kann bei einem persönlichen Kontakt ausgehändigt werden. Für die Übermittlung von Testergebnissen wäre dies beispielsweise etwa anlässlich der Probenentnahme umsetzbar.

  Auch bei der Auswahl eines Anbieters für Cloud-Speicher ist auf dessen grundsätzliche Eignung sowie ausreichende Sicherheit zu achten. Meine Orientierungshilfe zur Auftragsverarbeitung sowie (für Kommunen) der Leitfaden zum Outsourcing kommunaler IT enthalten dazu wichtige Hinweise. Kommunen, die bereits Kunden von Anbietern kommunaler Software sind, können unter diesen Maßgaben auch ein Cloud-Angebot dieses Anbieters einsetzen. Das IT Dienstleistungszentrum des Freistaats Bayern (IT-DLZ) bietet kommunalen Verwaltungen außerdem die BayernBox als Cloud-Lösung an.

• E-Mail

  Der Versand von Gesundheitsdaten per E-Mail erfordert grundsätzlich eine Verschlüsselung. Im Idealfall kommt eine Ende-zu-Ende-Verschlüsselung zum Einsatz; eine Transportverschlüsselung, die eine öffentliche Einrichtung gemäß der Richtlinie TR 02102-2 des Bundesamts für Sicherheit in der Informationstechnik einzurichten hat, kann im Einzelfall ausreichen.

  Kann auch eine Transportverschlüsselung nicht sichergestellt werden, besteht die Möglichkeit, verschlüsselte Anhänge zu versenden.

  Verschlüsselte Anhänge sind allerdings nicht ganz ohne Tücken. Wurde früher gerne eine Datei in eine verschlüsselte ZIP-Datei gepackt, ist heutzutage damit zu rechnen, dass E-Mails mit derartigen Anhängen häufig durch den SPAM- und Schadcodefilter markiert und somit nicht zugestellt werden. Für Office-Dateien und PDF-Dateien besteht die Möglichkeit der direkten Verschlüsselung in der Anwendungssoftware. Für Office-Dokumente ist zu bedenken, dass der Empfänger die jeweiligen Office-Dokumente auch wieder öffnen können sollte. Daher muss ein Dateiformat gewählt werden, das mit unterschiedlichen Office-Anwendungen kompatibel ist. Dies kann auf Grund der heterogenen Software-Produkte, Empfangsgeräte und Empfangsgerätekonfigurationen zu Schwierigkeiten führen. Auf fast jedem Gerät sollten allerdings PDF-Dateien zu öffnen sein, so dass sich mit einem Passwort verschlüsselte PDF-Dateien für den Versand sensibler Informationen eignen. Allerdings müssen aktuelle und sichere Verschlüsselungsverfahren und ausreichend sichere Passworte zum Einsatz kommen.

  Auch hier muss das Passwort über einen gesonderten Kommunikationskanal mitgeteilt werden. In meiner Prüfpraxis konnte ich feststellen, dass das Passwort mitunter in einer zweiten E-Mail zugeleitet wurde oder die E-Mail mit dem vermeintlich verschlüsselten Anhang die Information enthielt, dass das Geburtsdatum das Passwort sei. Beide Verfahren erhöhen die Sicherheit nicht wesentlich und sind daher zum Schutz sensibler Inhalte ungeeignet.

  Unabhängig vom Einsatz verschlüsselter E-Mails oder verschlüsselter Anhänge ist in jeden Fall darauf zu achten, dass beim E-Mail-Versand immer gewisse Informationen wie etwa der Betreff unverschlüsselt übertragen werden. Diese Teile der E-Mail dürfen daher keine sensiblen Daten enthalten oder Rückschlüsse auf solche Daten zulassen. Das gilt insbesondere auch für "sprechende" Aktenzeichen.

10.3.2. Beschwerden

Im Berichtszeitraum erreichten mich einige Beschwerden zur elektronischen Kommunikation im Rahmen der Coronavirus-Einreiseverordnung.

Beispielsweise teilte mir ein Bürger mit, dass er von einem bayerischen Gesundheitsamt per E-Mail eine Quarantänebenachrichtigung vom zuständigen Gesundheitsamt erhalten habe. Adressat der EMail waren neben ihm ca. 100 weitere betroffene Personen. Dies erkannte er daran, dass die weiteren E-Mail-Adressen im Cc-Feld eingetragen waren.

Das Gesundheitsamt hat hier gleich unter zwei Gesichtspunkten gegen Datenschutzrecht verstoßen:

Bereits unabhängig vom Inhalt der Nachricht dürfen einem Bürger in der Kommunikation mit einer Behörde keine weiteren E-Mailadressen bekannt werden. Eine Adressierung an mehrere Personen ist daher nur im Bcc-Feld möglich.

Als noch kritischer ist aber die unverschlüsselte Kommunikation per E-Mail zu werten, wenn Gesundheitsdaten betroffen sind - das gilt eben auch bei einer Quarantänebenachrichtigung (siehe Nr. 10.3.2). Leider musste ich immer wieder feststellen, dass viele Gesundheitsämter über keine geeignete technische Ausstattung verfügen, um überhaupt verschlüsselt kommunizieren zu können.

Das Gesundheitsamt gab an, dass sie die Versendung der Quarantänebenachrichtigung mit der Adressierung im Cc-Feld sehr bedauere und die Beschäftigten entsprechend erneut sensibilisiert habe. Auf Grund meines Hinweises zur Einordnung der Quarantänebenachrichtigung als Gesundheitsdatum stellte die Behörde zudem auf eine verschlüsselte Versendung per E-Mail mit verschlüsselten Word-Dateien im Anhang um.

Ein anderer Petent teilte mir mit, er sei von einem Gesundheitsamt im Rahmen der Coronavirus-Einreiseverordnung aufgefordert worden, seinen Impfpass oder ein PCR-Testergebnis via E-Mail unverschlüsselt einzusenden.

Eine gezielte Aufforderung zur Einsendung von Gesundheitsdaten per unverschlüsselter E-Mail ist nicht zulässig. Dem Bürger kann die Möglichkeit geboten werden, die geforderten Dokumente via Ende-Zu-Ende-verschlüsselter E-Mail einzusenden. Allerdings muss eine Behörde auch mindestens einen anderen sicheren Kommunikationsweg eröffnen. Hierzu zählt insbesondere der Postweg, der immer als Möglichkeit angeführt werden sollte, da nicht alle Betroffenen über elektronische Zugangsmöglichkeiten verfügen.

10.4. Social Engineering - eine nicht zu unterschätzende Gefahr

Der Blick auf die Sicherheit bei der Verarbeitung von personenbezogenen Daten muss stets umfassend und lückenlos sein. Schon kleinste "blinde Flecken" bei der Analyse von Schwachstellen der Verarbeitung können - wie die Vergangenheit zeigt - Datenschutzverstöße mit nicht unerheblichen Folgen für betroffene Personen zur Folge haben. Nach dem Erfahrungssatz "Gefahr erkannt - Gefahr gebannt" tut man gut daran, neben der immer komplexer werdenden Technik auch den Menschen mit seinen Besonderheiten zu betrachten.

Beim Social Engineering nutzen Angreifer den "Faktor Mensch" als vermeintlich schwächstes Glied der Sicherheitskette aus, um ihre kriminellen Absichten zu verwirklichen. Im Berichtszeitraum wurden mir insbesondere folgende Fallkonstellationen hierzu gemeldet:

Ein Beschäftigter einer bayerischen öffentlichen Stelle arbeitete im Homeoffice und wurde von einem angeblichen Service-Mitarbeiter von Microsoft angerufen. Wegen zahlreicher bei Microsoft eingegangener Fehlermeldungen sowie auslaufender Lizenzen benötige er einen Remote-Zugriff auf den Rechner des Behördenbediensteten. Die Ausführungen des vermeintlichen Microsoft-Mitarbeiters waren so überzeugend, dass sein "Opfer" einen Remote-Zugriff auf seinen Rechner zuließ und dadurch dem unbekannten Angreifer für eine längere Zeit auch Zugriff auf dienstlich verarbeitete personenbezogene Daten gewährte.

Der zweite Fall ereignete sich in einem bayerischen Notariat. Dort rief eine unbekannte Person an und gab sich als Eigentümer einer Wohnung aus, deren Verkauf gerade im Notariat bearbeitet wurde. Der angebliche Eigentümer erbat für seine Unterlagen die Übersendung einer eingescannten Kaufvertragsurkunde per E-Mail. Dazu gab er eine E-Mail-Adresse an. Überzeugt, dass alles mit rechten Dingen zugehe, übersandte die angerufene Notariatsmitarbeiterin ohne weitere Kontrollen die gewünschte Datei an die ihr genannte E-Mail-Adresse.

Nach diesem Anruf erhielt das Notariat eine Nachricht des echten Verkäufers. Der Verkäufer informierte darüber, dass in den vergangenen Wochen mehrfach versucht worden sei, bei unterschiedlichen Institutionen und Behörden telefonisch in seinem Namen auf vertrauliche und persönliche Daten zuzugreifen. Der Anrufer habe eine ähnliche männliche Stimme, kenne Geburtsdatum, Geburtsort, Wohnadresse sowie Handynummer des Verkäufers und verfüge anscheinend über weitere persönliche Daten.

Auf Rückfrage des Notariats gab der Verkäufer an, dass er nicht der Anrufer gewesen sei. Die von der täuschenden Person angegebene E-Mail-Adresse wurde auch bei anderen Institutionen von der Person verwendet, die persönliche Informationen über den Verkäufer zu erlangen suchte.

Die beiden Fälle zeigen, dass auch bayerische öffentliche Stellen Ziele von Social Engineering sind. Daher müssen auch dort Schutzmaßnahmen getroffen werden, die solchen Angriffen wirksam entgegenwirken. Da beim Social Engineering insbesondere Hilfsbereitschaft, Vertrauen, Überraschung, Angst oder Respekt vor Autorität ausgenutzt werden, um Personen geschickt zu manipulieren, reduzieren insbesondere folgende Maßnahmen das datenschutzrechtliche Risiko:

• Klare Handlungsanweisungen

  Insbesondere in Bereichen, die anfällig für Social Engineering sind, sollten klare Handlungsanweisungen erstellt und deren wirksame Umsetzung bedarfsgerecht überprüft werden. Grundlage hierfür können beispielsweise die Handlungsempfehlungen des Bundesamts für Sicherheit in der Informationstechnik sein.

• Sensibilisierung

  Das Vorgehen bei Social Engineering kann sehr vielseitig und für angegriffene Personen unerwartet sein. Daher sollten die Beschäftigten und gegebenenfalls weitere relevante Personen im Allgemeinen und auch speziell hinsichtlich der relevanten und aktuell beobachteten Vorgehensweisen informiert werden.

• Fehlerkultur

  Eine gelebte offene Fehlerkultur wirkt schadensmindernd. Denn je früher ein Social Engineering-Angriff erkannt wird, desto früher können geeignete Gegenmaßnahmen ergriffen werden.

10.5. Einführung einer Ersthelfer-App

Eine bayerische öffentliche Stelle hat sich an mich mit der Bitte gewandt, sie bei der Implementierung einer Ersthelfer-App beratend zu unterstützen. Beabsichtigt war, eine Ersthelfer-App in einer bayerischen Region einzurichten, um damit das sogenannte "therapiefreie Intervall" bis zum Eintreffen des öffentlich-rechtlichen Rettungsdienstes zu überbrücken. Insbesondere in Fällen von Bewusstlosigkeit soll über das "Ersthelfer-System" rasch Hilfe geleistet werden, um dauerhafte gesundheitliche Schäden sowie Todesfälle nach Möglichkeit zu vermeiden. Hierzu werden geeignete freiwillige Helferinnen und Helfer geworben, geschult und mit der Ersthelfer-App auf ihren Smartphones ausgestattet.

Die Alarmierung von Ersthelferinnen und Ersthelfern, die sich örtlich ausreichend nahe bei der hilfsbedürftigen Person befinden, wird durch die Integrierte Leitstelle angestoßen. Die Ermittlung der in der konkreten Einsatzsituation verfügbaren Ersthelferinnen und Ersthelfer, die Anfrage, ob diese einsatzfähig sind, sowie die Beantwortung der Einsatzfrage und die Routenführung zur hilfsbedürftigen Person übernimmt das Ersthelfer-System größtenteils automatisiert.

Bei meiner Beratung standen im Wesentlichen folgende Aspekte im Vordergrund der Betrachtung:

• Datenschutzrechtliche Vereinbarungen

  Bei dem konkreten Projekt haben eine Stadt, ein Rettungszweckverband, Träger der Integrierten Leitstellen sowie ein nicht-öffentliches Unternehmen als Anbieter des Ersthelfer-Systems miteinander kooperiert; auf Seiten des Unternehmens waren zudem Unterauftragsverarbeiter eingebunden. Die Kooperation erforderte ein komplexes Regelwerk. Ein wichtiger erster Schritt bestand darin, die datenschutzrechtlichen Rollen der einzelnen Stellen klar herauszuarbeiten und die Vereinbarung der datenschutzrechtlich notwendigen Vorgaben zu gewährleisten (insbesondere in einem Vertrag zur gemeinsamen Verantwortung nach Art. 26 DSGVO und in einem Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO).

• Standortüberwachung der Ersthelfer

  Für das Funktionieren der Ersthelfer-App sind aktuelle Standortdaten zu den Ersthelferinnen und Ersthelfern unverzichtbar. Nur mit diesen Daten kann das Ersthelfer-System den besten Weg zum jeweiligen Notfall weisen. Allerdings ist es datenschutzrechtlich nicht erforderlich, die Standorte der an der App angemeldeten Ersthelferinnen und Ersthelfer laufend im Ersthelfersystem genau zu erfassen. Daher werden nach Einschaltung der App durch eine Ersthelferin oder einen Ersthelfer die Daten zu ihrem oder seinem Standort vergröbert verarbeitet und nur bei größeren Ortsbewegungen aktualisiert. Bei einer Alarmierung kann auf dieser Datenbasis nur eine erste Auswahl von Ersthelferinnen und Ersthelfern im Alarmierungsradius getroffen werden. Da die vergröberten Standortinformationen nur für die automatisierte Verarbeitung der Notfallalarmierung benötigt werden, haben Anwender des Ersthelfer-Systems keinen Zugriff auf diese Standortdaten.

  Erst bei der Alarmierung und nach der aktiven Annahme des Einsatzes durch eine Ersthelferin oder einen Ersthelfer werden genaue Standortdaten an das System und die Integrierte Leitstelle übermittelt. Ferner erhält die Ersthelferin oder der Ersthelfer erst nach der Annahme die notwendigen Einsatzinformationen. Nach Beendigung des Einsatzes werden die Standortdaten wieder vergröbert verarbeitet und nur bei Bedarf aktualisiert.

• Erforderlichkeit der verarbeiteten Daten

  Ursprünglich geplant war, dass jede Ersthelferin und jeder Ersthelfer nach dem Einsatz einen sogenannten "Notfallbericht" erstellt, der den Erstbefund der Notfallpatientin oder des Notfallpatienten, die durchgeführten Maßnahmen sowie den Patientenbefund bei Übergabe an den Rettungsdienst enthalten sollte. Dieser Bericht sollte im Ersthelfer-System gespeichert werden. Da hierfür jedoch keine datenschutzrechtlich tragfähige Befugnis erkennbar war, wird stattdessen nur noch - nach einer entsprechenden Einwilligung der Ersthelferin oder des Ersthelfers - die Zeitspanne zwischen deren oder dessen Alarmierung und dem Eintreffen am Ort des Notfalls erfasst.

  Die Prüfung der Erforderlichkeit einer Verarbeitung setzt (unter anderem) den Grundsatz der Datenminimierung um. Der Grundsatz der Datenminimierung verpflichtet die Verantwortlichen, bei Verarbeitungen mit personenbezogenen Daten möglichst sparsam umzugehen, insbesondere nur so viele Daten zu erheben, wie für die Wahrnehmung der jeweiligen Aufgabe als dem Verarbeitungszweck benötigt werden.

Anhand dieses Projekts wurde ein weiteres Mal deutlich, wie wichtig es ist, schon zu Beginn einer Verarbeitung die datenschutzrechtlichen Rollen mehrerer beteiligter Stellen zu klären.

Vorhaben dieser Art sollten von Anfang an durch Ansprechpartnerinnen und Ansprechpartner begleitet werden, die das erforderliche datenschutzrechtliche Know-how bereitstellen können. Im Übrigen ist zu bemerken, dass einheitliche Standards für die Organisation und die technische Vernetzung der unterschiedlichen Ersthelfer-Systeme eine zweckgerechte Implementierung erheblich erleichtern könnten. Solche Standards können von regionalen Akteuren allerdings nicht geschaffen werden.

10.6. Beschäftigtendatenschutz bei der Ablage von E-Mails

Eine bayerische öffentliche Stelle hat sich mit der Frage an mich gewandt, was bei einer Ablage von E-Mails hinsichtlich des Beschäftigtendatenschutzes zu beachten ist. Die Stelle druckt relevante E-Mails aus und nimmt diese danach zu den (Papier-)Akten. Dabei können die E-Mail-Ausdrucke Beschäftigtendaten enthalten (etwa in Form von Absender-, Empfängerangaben oder zur Identität der Person, die die E-Mail ausgedruckt hat). Bei einer späteren Einsicht in die Akten können diese Informationen gegebenenfalls offengelegt werden.

In diesem Kontext führte die öffentliche Stelle aus, dass insbesondere ein vollständiger Ausdruck von E-Mails stets die Inhalte der E-Mail-Adressfelder "Von", "An" und "Cc" umfasst. Außerdem ist immer auch der vollständige Benutzername des E-Mail-Systems für die Person angegeben, die die E-Mail ausgedruckt hat. Die Konfiguration des genutzten E-Mail-Systems bietet keine Möglichkeit an, die Ausgabe dieser Informationen zu unterdrücken.

Inhalte der Adressfelder "Von", "An" und "Cc" können auch personalisierte E-Mail-Adressen und Namen von Beschäftigten der Stelle, also personenbezogene Beschäftigtendaten sein. Die Bedenken der anfragenden Stelle konnte ich ausräumen.

Rechtlicher Ausgangspunkt meiner Bewertung war Art. 4 Abs. 1 BayDSG: Eine öffentliche Stelle darf personenbezogene Daten hiernach verarbeiten, soweit dies zur Aufgabenerfüllung erforderlich ist. Diese Befugnis umfasst grundsätzlich auch die Verarbeitung von Beschäftigtendaten in Sachakten. Die Erforderlichkeit einer Datenverarbeitung ließ sich in vorliegendem Zusammenhang mit den nachfolgenden Erwägungen begründen.

Die in den aufgeführten E-Mail-Adressfeldern gespeicherten personenbezogenen Beschäftigtendaten dokumentieren hausinterne Absender und Empfänger der jeweiligen E-Mail und können insbesondere bei internen Weiterleitungen den sonst üblichen sachleitenden Verfügungen, wie sie auf papiergebundenen Schreiben angebracht sind, gleichgestellt werden.

Da E-Mails, die zum Akt verfügt werden, als Teil eines Vorgangs auch die Art der Bearbeitung, die wesentlichen Schritte des Geschäftsgangs und die Erledigung in ihrer zeitlichen Reihenfolge nachvollziehbar, vollständig und dauerhaft erkennen lassen müssen (vgl. § 18 Allgemeine Geschäftsordnung für die Behörden des Freistaates Bayern), sind hinsichtlich der Verarbeitung dieser Adressfelder datenschutzrechtlich keine durchgreifenden Einwände erkennbar.

Bei der anfragenden Stelle werden relevante E-Mails ausgedruckt und zur Papierakte verfügt; danach wird die digitale E-Mail gelöscht. Die Angabe des Namens der Person, die die E-Mail ausgedruckt hat, wird dabei vom verwendeten E-Mail-System auf dem E-Mail-Ausdruck automatisiert mit angebracht.

Die datenschutzrechtliche Zulässigkeit hierfür ergibt sich aus dem Grundsatz des "ersetzenden Druckens", der sich analog zum Grundsatz des ersetzenden Scannens ergibt. Beim sogenannten "ersetzenden Scannen" wird eine digitale Kopie aus Papierdokumenten erzeugt und die Papieroriginale werden nach dem Scannen vernichtet. Da die digitale Kopie mit dem Papierdokument inhaltlich sowie bildlich übereinstimmen und für nutzende Personen lesbar sein muss, kann als typische technische Lösung für die Sicherung der Integrität das Aufbringen einer elektronischen Signatur auf der digitalen Kopie geboten sein.

Beim "ersetzenden Drucken" wird bei einer papiergebundenen Aktenführung die elektronische Form einer E-Mail ersetzend in ihre papiergebundene Form überführt. Dabei muss die öffentliche Stelle analog zum Scannen sicherstellen, dass der Ausdruck inhaltlich mit der E-Mail übereinstimmt. Der auf dem Ausdruck enthaltene Name der ausdruckenden Person ermöglicht es, im Zweifelsfall bei dieser nachzufragen bzw. möglichen Unstimmigkeiten gezielt nachzugehen und stellt dadurch einen wichtigen, mit der E-Mail fest verbundenen Hauptbestandteil des Transfervermerks "ersetzendes Drucken" dar.

Allerdings habe ich der Stelle aufgetragen, risikoorientiert zu prüfen und zu bewerten, ob in den dargestellten Konstellationen die Beschäftigtenangaben in einer datenschutzfreundlicheren, etwa pseudonymisierten Form verarbeitet werden können.

10.7. Beanstandung nach dem Verlust von Bewerbungsunterlagen

Eine bayerische öffentliche Stelle erhielt nach Ausschreibung einer zu besetzenden Stelle über 100 Bewerbungen, in denen sich unter anderem Lokalisationsdaten (Wohnort, Wegstrecke), Daten über die Verfolgung von Straftaten und Ordnungswidrigkeiten, Daten zu religiösen oder weltanschaulichen Überzeugungen sowie Gesundheitsdaten befanden.

Nach zentralen Vorarbeiten sollten die Bewerbungsunterlagen an die im Stellenbesetzungsverfahren beteiligten Organisationseinheiten weitergegeben werden. Hierfür wurden die Bewerbungsunterlagen in einen Transportbehälter gelegt, dieser wurde an eine zentrale Versandstelle adressiert und - wie üblich - gemeinsam mit anderer Hauspost für die Abholung durch den regelmäßigen Fahrdienst im Untergeschoss des Dienstgebäudes bereitgestellt. Seit dieser Bereitstellung ist der Behälter mit den Bewerbungsunterlagen trotz intensiver Nachforschung spurlos verschwunden.

Die in dieser Konstellation notwendige Meldung einer Datenpanne habe ich über das Meldeformular auf meiner Homepage von der verantwortlichen Stelle deutlich verspätet erhalten; die gesetzlich vorgeschriebene Begründung dafür fehlte.

Die Meldung ist nach Art. 33 Abs. 1 Satz 1 DSGVO unverzüglich, mithin ohne schuldhaftes Zögern, zu erstatten. Dies gilt insbesondere für ein - wie in der hier zu beurteilenden Fallkonstellation gegebenes - leicht zu erkennendes und leicht zu beschreibendes Ereignis.

Die in Art. 33 Abs. 1 Satz 1 DSGVO enthaltene 72-Stunden-Frist ist eine Richtgröße, an deren Überschreitung eine Begründungspflicht (Art. 33 Abs. 1 Satz 2 DSGVO) anknüpft. Aus aufsichtsbehördlicher Sicht kann bei Datenschutzverletzungen, die nicht auf den ersten Blick - und sei es auch nur vorläufig - einzuordnen sind, eine Aufklärungsphase von höchstens 24 Stunden ab dem Auftreten hinreichender Anhaltspunkte in Anspruch genommen werden. Die Dauer hängt von den erforderlichen Aufklärungsmaßnahmen ab. Wird mehr Zeit benötigt, ist dies in der Meldung zu erläutern. Art. 33, 34 DSGVO sind in meiner Orientierungshilfe "Meldepflicht und Benachrichtigungspflicht des Verantwortlichen" eingehend erläutert.

Gehen Unterlagen von über 100 Bewerberinnen und Bewerbern auf dem regelmäßig genutzten und üblichen Transportweg verloren, liegt grundsätzlich nahe, dass die gebotenen Schutzmaßnahmen gegen Verlust (vgl. Art. 32 Abs. 1 DSGVO) nicht getroffen waren. Dies und die deutlich verspätete Meldung führten zu einer Beanstandung.

Den offenkundigen Handlungsbedarf hat die öffentliche Stelle erkannt und als Reaktion auf diesen Vorfall insbesondere folgende Abhilfemaßnahmen festgelegt:

• Verschließbare Transportbehältnisse

  Der Aktentransport zwischen einzelnen Dienstgebäuden wird nunmehr in verschließbaren Aluminiumkisten durchgeführt. Die Mitarbeiter des Botendienstes sind angewiesen, die Alukisten auch tatsächlich zu verschließen. Zudem können diese Aluminiumkisten nur von den dazu berechtigten Personen in den einzelnen Dienstgebäuden geöffnet werden.

• Spezialbehälter für Entsorgung

  Das für die Entsorgung bestimmte Schriftgut muss seit dem Vorfall deutlicher gekennzeichnet werden und wird in speziellen, nur für diesen Zweck verwendeten Behältern transportiert.

• Sensibilisierung

  In Schulungen werden die Mitarbeiterinnen und Mitarbeiter bezüglich des Umgangs mit Verletzungen des Schutzes personenbezogener Daten sensibilisiert.

• Aktentransportkonzept

In einem Aktentransportkonzept werden die datenschutzrechtlichen Risiken sowie die umgesetzten Abhilfemaßnahmen dargestellt. Zu diesen Maßnahmen zählen etwa die Absicherung der Ablageorte beim Transport, die Verwendung von Transportbegleitunterlagen für eine Vollständigkeitsfeststellung sowie Kontrollmechanismen, die einen (drohenden) Verlust rasch erkennen und die Ursache vereinfacht aufdecken helfen. Dies ermöglicht eine regelmäßige Kontrolle der entsprechenden Routinen im Verwaltungsalltag.

10.8. Verweigerte Kfz-Ummeldung wegen Personenverwechslung

Eine Bürgerin hat sich an mich gewandt, da ihr bei einer Zulassungsstelle aufgrund von angeblichen Steuerschulden zunächst die Ummeldung ihres Kraftfahrzeuges verweigert worden war. Konkret wurde ihr im Beisein mehrerer anderer Kundinnen und Kunden der Zulassungsstelle mitgeteilt, dass sie ihr Kfz erst ummelden könne, wenn sie ihre Schulden bei der Stadtverwaltung beglichen habe. Eine telefonische Rücksprache der betroffenen Bürgerin mit dem Steueramt der Kommune brachte eine Verwechslung ans Licht, so dass der Ummeldung ihres Fahrzeuges nichts mehr entgegenstand.

Die Bürgerin erlebte eine sehr unangenehme und peinliche Situation, da sie sich zu Unrecht "an den Pranger gestellt" fühlte und andere Personen, die sich in der Zulassungsstelle befanden, den Vorhalt mitbekamen. Wie sich schließlich herausstellte, hatte es die Zulassungsstelle versäumt, die Identität der Bürgerin ausreichend zu überprüfen.

Ich habe die verantwortliche Stelle im Hinblick auf die Datenrichtigkeit gemäß Art. 5 Abs. 1 Buchst. d DSGVO unmissverständlich darauf hingewiesen, dass sie alle ihr zur Verfügung stehenden personenbezogenen Daten nutzen muss, wenn Personen (hier: säumige Steuerschuldner) eindeutig identifiziert und zudem behördlichen Maßnahmen (hier: Verweigerung der Zulassung) ausgesetzt werden sollen. Zwar gilt grundsätzlich immer der Grundsatz der Datenminimierung (Art. 5 Abs. 1 Buchst. c DSGVO), was aber nicht dazu führen darf, dass dadurch der Grundsatz der Datenrichtigkeit ausgehebelt wird.

Für die sachliche Richtigkeit der verarbeiteten personenbezogenen Daten ist nach Art. 5 Abs. 2 DSGVO die zuständige öffentliche Stelle als datenverarbeitende Stelle verantwortlich.

Insbesondere ist auch die Klärung der Frage, ob die bei der Zulassungsstelle vorliegenden personenbezogenen (ggf. falschen, weil unvollständigen) Daten mit denen des von einer Maßnahme betroffenen Bürgers übereinstimmen, nicht Aufgabe der Bürgerinnen und Bürger, sondern der für die Datenverarbeitung zuständigen öffentlichen Stelle. Dies umso mehr, als in Abhängigkeit vom Ausgang der Identitätsprüfung eine für den betroffenen Bürger nicht ganz unerhebliche Maßnahme getroffen wurde.

Daneben habe ich die betroffene Stelle zur Wahrung der Diskretion im Rahmen der Kfz-Zulassung angehalten. Die Kommune hat technische und organisatorische Vorkehrungen zu treffen, damit künftig ähnliche oder vergleichbare Fälle einer beiläufigen Bloßstellung vor anwesenden Personen vermieden werden. Öffentliche Stellen sind nach Art. 32 Abs. 1 DSGVO auch beim Bürgerkontakt verpflichtet, geeignete technische und organisatorische Maßnahmen zu treffen, um ein dem Risiko für die Rechte und Freiheiten natürlicher Personen angemessenes Schutzniveau im Zusammenhang mit der Verarbeitung personenbezogener Daten zu gewährleisten.

10.9. Meldungen von Verletzungen des Schutzes von personenbezogen Daten

Seit Inkrafttreten der Datenschutz-Grundverordnung im Mai 2018 berichte ich über die bei mir eingehenden Meldungen von Datenpannen. Besonders ausführlich habe ich dieses Thema in meinem 30. Tätigkeitsbericht 2020 unter Nr. 12.10 beleuchtet. Da nach wie vor zur Bekämpfung der COVID-19-Pandemie in großem Umfang medizinische Informationen wie Quarantänebescheide, Testergebnisse oder Kontaktlisten versandt werden müssen, stammen zahlreiche Meldungen aus dem Gesundheitsbereich. Insgesamt standen Verletzungen des Schutzes der Vertraulichkeit von personenbezogenen Daten im Vordergrund, doch waren auch zahlreiche Verletzungen der weiteren Schutzziele Integrität und Verfügbarkeit zu verzeichnen. Etwas ärgerlich ist, dass zu den regelmäßig wiederkehrenden Konstellationen auch einige zählen, die ich unter anderem in meinen letzten Tätigkeitsbericht bereits behandelt habe.

Das Aufkommen an Meldungen nach Art. 33 DSGVO hat sich im Vergleich zum letzten Berichtszeitraum noch einmal deutlich erhöht. Dies lässt allerdings nicht ohne Weiteres den Rückschluss auf einen Trend zu mehr Datenpannen zu; nicht wenigen öffentlichen Stellen ist es im Berichtszeitraum gelungen, die Meldung an die Datenschutz-Aufsichtsbehörden in ihre Geschäftsprozesse einzubauen. Hier zahlt sich aus, dass ich gerade bei Stellen, die in großem Umfang sensible Daten verarbeiten, auf ein effektives Datenschutzmanagement hinwirke.

In diesem Jahr möchte ich nur einen etwas skurrilen Fall aufgreifen, der ein spezifisches Risiko der Arbeit im Homeoffice aufzeigt, wenn große bayerische Flüsse im Spiel sind.

Eine kommunale Beschäftigte fuhr mit dem Fahrrad vom Büro ins Homeoffice. Die für die Weiterarbeit benötigten Papierakten hatte sie lose in ihren Fahrradkorb gelegt; sie enthielten personenbezogene Daten von Bürgerinnen und Bürgern. Auf einer Donaubrücke wurde die Beschäftigte samt Fahrrad und Aktenstapel von einem heftigen Windstoß erfasst. Die Meldung nach Art. 33 DSGVO teilt mit: "Ca. 10 Blätter flogen [...] über das Geländer in die Donau, den Rest konnte [die Beschäftigte] mühsam und unter Hilfe zweier Passanten einsammeln und retten." Hinsichtlich der verlorenen Blätter stellt die Meldung nüchtern fest: "Theoretisch können die Papiere im Uferbereich[..] angespült werden. Die Qualität und Lesbarkeit dürfte im Lauf der Zeit erheblich abnehmen."

Dieser Fall zeigt einmal mehr die Notwendigkeit ausreichender Sicherungsmaßnahmen beim Aktentransport. Wie ich bereits in meinem 29. Tätigkeitsbericht 2019 unter Nr. 12.7 dargestellt habe, sollten Papierakten in verschließbaren Behältern transportiert werden; ferner sollte dafür Sorge getragen werden, dass diese Behältnisse nicht unbeaufsichtigt abgestellt oder ganz vergessen werden.

10.10. Exchange-Sicherheitslücke

Durch Informationen von Microsoft sowie des Bundesamts für Sicherheit in der Informationstechnik (BSI) wurde Anfang März 2021 bekannt, dass vier Zero-Day-Sicherheitslücken in Microsoft Exchange-Servern existierten. Diese Lücken machten auch zahlreiche öffentliche Stellen über das Internet angreifbar, sobald sie Microsoft Exchange-Server in einer bestimmten Konfiguration einsetzten. Das BSI stufte die Gesamtsituation als kritisch ein, da bereits eine flächendeckende Ausnutzung stattfand und somit die Wahrscheinlichkeit einer Kompromittierung der verwundbaren Systeme als realistisch anzusehen war. Zudem zeigte die Medienberichterstattung, dass es im Nachgang der Kompromittierung auch zu weiteren Angriffen auf Basis dieser Sicherheitslücke kam.

Mich erreichte im März und April 2021 eine sehr hohe Anzahl an Meldungen nach Art. 33 DSGVO. In diesen Fällen konnte jeweils eine Kompromittierung nachgewiesen werden. Es handelte sich um eine akute Gefährdung, bei der zeitnahes Handeln erforderlich war. Microsoft stellte sowohl Patches zum Schließen der Sicherheitslücken zur Verfügung als auch Anleitungen und Möglichkeiten, die eigenen Server gezielt auf eine Infektion hin zu prüfen. Das BSI fordert für gezielte persistente Angriffe (Advanced Persistent Threat - APT) wie bei der Bedrohungslage für Exchange-Server eine Neuinstallation für betroffene, infizierte oder kompromittierte IT-Systeme. Dieser Forderung habe ich mich uneingeschränkt angeschlossen und allen öffentlichen Stellen in Bayern dringend empfohlen, entsprechende technische Maßnahmen ohne zeitlichenVerzug umzusetzen. Zur Unterstützung der Verantwortlichen in Bayern haben das Bayerische Landesamt für Datenschutzaufsicht und ich umfangreiche Informationen erarbeitet und auf unseren Homepages zur Verfügung gestellt. Diese Dokumente beziehen sich zwar auf spezielle Sicherheitslücken, enthalten aber auch grundlegende Maßnahmen, die unabhängig vom konkreten Vorfall umgesetzt werden sollten.

Die Kompromittierung der Microsoft Exchange-Server hat gezeigt, dass Verantwortliche und Auftragsverarbeiter auch in Anbetracht hochdynamischer digitaler Prozesse ihren gesetzlichen Verpflichtungen nach Art. 32 DSGVO uneingeschränkt nachzukommen haben. Insbesondere vor dem Hintergrund der Exchange-Sicherheitslücke müssen die Verantwortlichen und Auftragsverarbeiter im öffentlichen Sektor die eingesetzten IT-Systeme durch internes oder externes IT-Fachpersonal dauerhaft und regelmäßig auf Schwachstellen überprüfen lassen, diese Systeme unter Berücksichtigung des Stands der Technik aktualisieren (etwa durch bereitgestellte Patches) und erforderlichenfalls alte, angreifbare IT-Systeme durch neue ersetzen.

77. Internet: https://www.datenschutz-bayern.de/corona/sonderinformation-luca.html. [Zurück]
78. Vgl. Petri, in: Simitis/Hornung/Spiecker gen. Döhmann, Datenschutzrecht, 2019, Art. 9 DSGVO Rn. 11; Weichert, in: Kühling/Buchner, Datenschutz-Grundverordnung/Bundesdatenschutzgesetz, 2. Aufl. 2018, Art. 9 DSGVO Rn. 37. [Zurück]
79. Bayerischer Landesbeauftragter für den Datenschutz, Auftragsverarbeitung, Orientierungshilfe, Stand 4/2019, Internet: https://www.datenschutz-bayern.de, Rubrik "Datenschutzreform 2018". [Zurück]
80. Bayerischer Landesbeauftragter für den Datenschutz, Leitfaden zum Outsourcing kommunaler IT, Stand 3/2021, Internet: https://www.datenschutz-bayern.de, Rubrik "Datenschutzreform 2018". [Zurück]
81. Bundesamt für Sicherheit in der Informationstechnik, BSI TR-02102-2 "Kryptographische Verfahren: Verwendung von Transport Layer Security (TLS)", Stand 1/2021, Internet: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.html (externer Link). [Zurück]
82. Internet: https://www.bsi.bund.de/DE/Themen/Verbraucherinnen-und-Verbraucher/Cyber-Sicherheitslage/Methoden-der-Cyber-Kriminalitaet/Social-Engineering/social-engineering_node (externer Link). [Zurück]
83. Vgl. Bundesamt für Sicherheit in der Informationstechnik, Technische Richtlinie 03138 "Ersetzendes Scannen" (RESISCAN), Internet: https://www.bsi.bund.de/DE/Themen/Oeffentliche-Verwaltung/Moderner-Staat/Ersetzendes-ScannenTR-Resiscan/ersetzendes-scannentr-resiscan_node.html (externer Link). [Zurück]
84. Bayerischer Landesbeauftragter für den Datenschutz, Meldepflicht und Benachrichtigungspflicht des Verantwortlichen, Stand 6/2019, https://www.datenschutz-bayern.de, Rubrik "Datenschutzreform 2018". [Zurück]