Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein

6    Systemdatenschutz

Die Pflichten des Verantwortlichen erstrecken sich zu einem großen Anteil auf das Treffen geeigneter technischer und organisatorischer Maßnahmen, um das dem Risiko angemessene Schutzniveau zu gewährleisten. Das Recht verlangt eine Gestaltung der Verarbeitung personenbezogener Daten entsprechend der rechtlichen Vorgaben. Aus diesem Grund kommt dem Systemdatenschutz eine besondere Rolle zu.

6.1          Landesebene

6.1.1       Zusammenarbeit mit dem Zentralen IT-Management (ZIT)  und anderen IT-Stellen des Landes

Wie in den vergangenen Jahren wurde das ULD als Gast in der Konferenz der IT-Beauftragten (ITBK) über aktuelle und geplante IT-Projekte informiert. Eine formelle Einbindung in konkrete Verfahren oder in Regelwerke, die eine landesweite Bedeutung haben oder die im Rahmen der Mitbestimmung entstanden sind, gab es in diesem Berichtszeitraum nicht.

Erfolgreich fortgesetzt wurde auch die Zusammenarbeit mit anderen IT-Stellen des Landes, u. a. dem Amt für Informationstechnik (AIT) und im Bereich des Bildungsministeriums, aber auch mit der Justiz-IT. In den regelmäßigen Zusammenkünften und Austauschen geht es um gegenseitige Information: zum einen über Planungen bei der Einführung und Ausgestaltung neuer Verfahren, zum anderen über Ergebnisse und Entwicklungen aus den Arbeitskreisen der Datenschutzbeauftragten des Bundes und der Länder, die von übergreifender Bedeutung sind. So fußen zahlreiche Verfahren auf überregional angebotener Software, häufig in Kombination mit einer Auftragsverarbeitung beim Anbieter. In diesen Fällen gilt es herauszuarbeiten, welche rechtlichen Bewertungen und technischen Konfigurationen aus anderen Bereichen übernommen werden könnten und welche Unterschiede es aufgrund landesrechtlicher Regelungen (insbesondere im Bildungsbereich) gibt, die eine differenzierte Betrachtung erfordern.

Schließlich gibt es auf der Seite der Anbieter im Zeitablauf zahlreiche Änderungen, die Neubewertungen erfordern. So sind Einschätzungen zur Geeignetheit eines Produkts oder zur Zulässigkeit wiederholt zu überprüfen – auch wenn sich Einsatzszenarien ändern oder angepasst werden. Ein typisches Beispiel sind hierbei die Microsoft-Online-Dienste (Tz. 6.2.3).

Insgesamt würden wir uns eine Verstärkung der Einbindung im Vorfeld wünschen – und zwar bevor wir über Zeitung oder Fernsehen davon erfahren, bevor die Landesbeauftragte für Datenschutz dazu interviewt wird und bevor die Beschwerden und Nachfragen von Betroffenen oder Behördenmitarbeitenden eintreffen.

Was ist zu tun?
Die frühzeitige Information und Einbindung des ULD bei neuen bzw. geplanten Verfahren und übergreifenden Regelungen sollten noch intensiviert werden.

 

6.1.2       Update: Sicherheitskonzepte mit SiKoSH

Seit einigen Jahren ist das ULD am „SiKoSH“-Projekt des ITV.SH beteiligt (41. TB, Tz. 6.1.3). Das Hauptziel dieses Projekts besteht darin, Kommunen und kleinere Organisationen bei der Umsetzung der Anforderungen an Informationssicherheit zu unterstützen.

BSI
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat mit dem IT-Grundschutz einen Standard geschaffen, der eine Managementmethodik für Informationssicherheit vorgibt und mit dem Grundschutz-Kompendium auch konkrete technische und organisatorische Sicherheitsmaßnahmen beschreibt. Insbesondere die öffentliche Hand orientiert sich an diesem Standard und ist teilweise auch gesetzlich verpflichtet, ihn umzusetzen.

Hierbei orientiert sich das Projekt eng am IT‑Grundschutz des BSI, das als Rahmenwerk anpassungsfähig, aber konzeptionell für jeden Einzelfall auch anpassungsbedürftig ist.

Diese Anpassung erfolgt u. a. in Abhängigkeit von Faktoren wie der Größe der Organisation, seinem Steuerungs- und Organisationsmodell, den Geschäftsprozessen, der dazu eingesetzten Software und Hardware oder den genutzten Dienstleistern. Dies macht das Modell sehr flexibel, zumal auch eigene Anpassungen und Erweiterungen möglich sind. Diese Flexibilität ist Segen und Fluch zugleich, weil eben die Anpassungsarbeit erforderlich ist, bevor es an die Konzeptionierung und Umsetzung von Sicherheitsmaßnahmen geht.

Für vergleichbare IT-Strukturen und Datenverarbeitungen gibt es im IT-Grundschutz die Möglichkeit, Maßnahmenbündel in sogenannten Profilen zusammenzufassen und hierbei Prioritäten vorzugeben. Das Ziel ist dabei, sich bei jeder Anwendung wiederholende konzeptionelle Arbeiten „vor die Klammer zu ziehen“ und die Nutzung der Ergebnisse auch anderen Organisationen zur Verfügung zu stellen.

Die kommunalen Spitzenverbände haben in der „Arbeitsgruppe kommunale Basis-Absicherung“ (AG koBa) ein solches Profil zur „Basis-Absicherung Kommunalverwaltung“ erstellt. Die an die (jeweils) aktuelle Fassung des IT-Grundschutzes angepasste Version, aktuell die Version 4.0, ist hier abrufbar:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Hilfsmittel/Profile/Basis_Absicherung_Kommunalverwaltung.html
Kurzlink: https://uldsh.de/tb42-6-1-2a

Das Projekt SiKoSH ermöglicht einen Einstieg in das Management der Informationssicherheit, indem es mit Musterkonzepten und -dokumenten unterstützt. Es hebt sich durch bewusste Vereinfachungen von der vollständigen Vorgehensweise des IT-Grundschutzes ab, um Einstiegshürden zu senken. Klar ist damit auch, dass allein damit nicht das umfassende Sicherheitsniveau von IT-Grundschutz erreicht werden kann.

Es ist nicht möglich, sämtliche Konstellation aller kommunalen Datenverarbeitungen und Organisationen zu erfassen – allein schon die unterschiedliche Größe der Kommunen erfordert verschiedene Steuerungsmodelle. Aber auch die jeweils betriebenen IT-Verfahren und Strukturen sind sehr unterschiedlich. Schließlich gibt es im kommunalen Bereich auch Datenverarbeitungen, die außerhalb der klassischen Verwaltung liegen, aber dennoch abzusichern sind, beispielsweise Steuerungen im Bereich der Klärtechnik. Dies macht klar, dass SiKoSH ein Einstieg, aber keine vollständige Implementierung eines Sicherheitsmanagements für alle Facetten der Datenverarbeitung ist. Durch die Anpassungsfähigkeit und Erweiterbarkeit des Modells ist ein „Mehr“ aber immer möglich.

Soweit sinnvoll, können das Organisationsmodell und auch zahlreiche technische Anforderungen zur Umsetzung von Datenschutzvorgaben, insbesondere im technisch-organisatorischen Bereich, verwendet werden. Zu beachten ist, dass bei der Verarbeitung personenbezogener Daten die Maßnahmen der Basis-Absicherung nicht immer ausreichen. Dennoch ist es sinnvoll, mit kleinen Schritten zu beginnen, anstatt angesichts einer (vermeintlich) riesigen Aufgabe zu kapitulieren. Durch das Projekt SiKoSH wird eine Möglichkeit geschaffen, Erfahrungen auszutauschen, die Erstellung von Musterdokumenten zu beschleunigen und eigene Erkenntnisse aus der Praxis direkt mit einfließen zu lassen.

 

6.1.3       Arbeitskreis Rechnungsprüfung

Im vergangenen Jahr war das ULD, wie auch die Prüfgruppe IT des Landesrechnungshofs, wie zuvor am „Arbeitskreis IT der Rechnungsprüfungsämter der Kreise und der Städte Schleswig-Holsteins“ beteiligt.

Bei der IT-Prüfung der Rechnungsprüfungsämter ist auch der ordnungsgemäße Einsatz von Informationstechnik bedeutsam. Daraus ergeben sich Überschneidungen zu Fragen des Datenschutzes und der Informationssicherheit.

Neben einem generellen Interesse an den Vorgaben und Maßstäben des Landesrechnungshofs und der Datenschutzaufsicht spielen immer wieder Einzelfragen eine Rolle. Im Berichtszeitraum waren dies u. a. Fragen zur Passwortsicherheit (Tz. 10.3).

Daneben sind die Treffen der Arbeitsgruppe eine gute Gelegenheit, sich über sogenannte ebenen-übergreifende Verfahren auszutauschen, d. h. Verfahren, in denen Kommunen und Land, teilweise auch der Bund, zusammenarbeiten. Typische Beispiele sind die zahlreichen Verfahren im Bereich Online-Zugangsgesetz (OZG), für die durch das Land technische Komponenten bereitgestellt werden, die dann mit kommunalen Fachverfahren kommunizieren. Hierdurch ergeben sich mittelfristig Herausforderungen im Bereich der IT-Prüfung, sodass eine frühzeitige Einbindung und Information sinnvoll sind.

Auch jenseits konkreter Verwaltungsanwendungen ist ein Austausch über zukünftige Entwicklungen wertvoll, beispielsweise verschiedene Möglichkeiten, Datenverarbeitung durch Dritte erbringen zu lassen. Stichwörter sind hier die klassischen Verfahren der Auftragsverarbeitung bis hin zu künstlicher Intelligenz und Cloud-Anwendungen, zu denen das ULD aus Datenschutzsicht aufklärt. Diese Aspekte spielen zwar häufig noch keine unmittelbare Rolle im Alltag der IT-Prüfung, sind aber als zukünftige Themen relevant und erfordern, dass IT-Prüferinnen und Prüfer sprechfähig sind.

Angeregt werden konnte eine gemeinsame Diskussion über Prüfkriterien für den Einsatz von KI-Systemen in der öffentlichen Verwaltung. Hier ergeben sich neben klassischen Aspekten zum Datenschutz neue Fragestellungen rund um rechtsstaatliche Anforderungen, Diskriminierungsfreiheit sowie Transparenz und Informationsfreiheit.

Was ist zu tun?
Die bisherige gute und vertrauensvolle Zusammenarbeit soll fortgesetzt werden.

 

6.1.4       Künstliche Intelligenz  – neue Fragen zum datenschutzkonformen Einsatz

Seitdem die Firma OpenAI im November 2022 den Chatbot ChatGPT in der Version 3.5 für die Öffentlichkeit kostenlos zur Verfügung gestellt hat, werden weltweit die Möglichkeiten und Risiken sowie die gesellschaftlichen und wirtschaftlichen Effekte von Systemen mit künstlicher Intelligenz diskutiert – und die vielen neuen und in kurzer Zeit weiterentwickelten KI-Systeme ausprobiert.

Die datenschutzrechtliche Perspektive muss vor dem Hintergrund neuer technischer Entwicklungen bei KI-Systemen und vielen Überlegungen zu Einsatzmöglichkeiten laufend neu diskutiert und formuliert werden. Im ULD beschäftigen wir uns schon seit mehreren Jahren mit künstlicher Intelligenz und waren 2019 an der Entwicklung von allgemeinen Positionen der Datenschutzkonferenz (DSK) zu künstlicher Intelligenz maßgeblich beteiligt (siehe Kasten).

In der Taskforce KI der Datenschutzkonferenz werden mit einem Informationsersuchen an OpenAI (siehe Tz. 6.3.1) die datenschutzrechtlichen Fragestellungen rund um das bekannteste KI-System erörtert. Gleichzeitig müssen neben den KI-Systemen mit großen Sprachmodellen (Large Language Models), die die technische Grundlage für viele Chatbots sind, auch viele andere KI-Systeme im Blick behalten werden, die z. B. zum Generieren von Bildern, zur Erkennung von Mustern (Gesichter, Verhalten) oder in der Medizin zum Einsatz kommen können.

Die KI-Systeme haben oft unterschiedliche Nutzungsweisen, sodass sich auch die menschlichen Interaktionen sowie Kontroll- und Eingriffsmöglichkeiten unterscheiden. Beispielsweise werden bei Bildgeneratoren typischerweise mehrere Ausgaben erzeugt, aus denen das beste Ergebnis ausgewählt wird – bei Textgeneratoren wird hingegen mit einem Ergebnis gearbeitet, das aber einfacher an konkreten Stellen korrigiert werden kann. Bei Übersetzungen in Sprachen, die selbst nicht beherrscht werden, oder in fachlich anspruchsvollen Texten können wiederum Fehler versteckt sein, die nur mit entsprechendem Wissen erkennbar sind. In den bekannten Chatbots, die auf großen Sprachmodellen aufbauen, ist eine qualitative Einschätzung der gegebenen Antworten nicht möglich – im Gegenteil wird je nach Programmierung an einer einmal getätigten Aussage stumpf festgehalten und gegebenenfalls eine falsche Information um weitere halluzinierte Aspekte ergänzt oder der Chatbot rudert umfassend zurück, entschuldigt sich und behauptet möglicherweise das genaue Gegenteil – das auch nicht richtig ist.

In einigen KI-Systemen, z. B. in medizinischen Anwendungen oder der autonomen Mobilität, werden Ergebnisse mit einer qualitativen Einschätzung beispielsweise in Form eines Wahrscheinlichkeitswerts ausgegeben. Hier muss für Anwendende klar festgelegt sein, wie diese Werte zu interpretieren sind und was daraus für die weitere Arbeit mit den Ergebnissen folgt.
Verwendet man beispielweise interaktive Bildgeneratoren beim Design von Publikationen zur Erzeugung von Grafiken, so lässt man sich so lange Grafiken erstellen, bis man mit dem Vorschlag zufrieden ist. Nutzt man Textgeneratoren wie ChatGPT interaktiv zur Erzeugung von Texten, etwa von Reden, Dokumentationen, Vermerken o. Ä., ist möglicherweise die menschliche Qualitätskontrolle weniger ausgeprägt und die Vorschläge werden schneller übernommen. Das bedeutet aber auch als Daumenregel für den praktischen Einsatz: Kommen die Systeme bei Anwendungen zum Einsatz, bei der die Antwort durch die Empfangenden nur schwer auf Richtigkeit geprüft werden kann, sind aus Nutzendensicht deutlich höhere Anforderungen an die Korrektheit der Ausgaben zu stellen. KI-Entwicklungsteams sollten bei der Gestaltung die Zielgruppe im Kopf haben und im Falle von Unsicherheiten beispielsweise Meldungen wie „Antwort nicht möglich“ vorzusehen. Beispiele hierfür sind etwa

• Übersetzungen in Sprachen, die selbst nicht beherrscht werden,
• Bilderkennungen im medizinischen Bereich, die gerade über Aspekte hinausgehen sollen, die der menschlichen Wahrnehmung zugänglich sind,
• Chatbots für Fragen mit Antworten, deren Qualität und Korrektheit die Fragenden nicht einschätzen können (etwa zu Details von Verwaltungsverfahren, Fristen usw.) oder
• Bilderkennungsverfahren für Massendaten (etwa Schrifterkennung), die sich aufgrund der Menge einer detaillierten menschlichen Kontrolle entziehen.

Positionen der DSK zu künstlicher Intelligenz
Hambacher Erklärung zur künstlichen Intelligenz (Sieben datenschutzrechtliche Anforderungen)
Entschließung der Datenschutzkonferenz (3. April 2019):
https://www.datenschutzkonferenz-online.de/media/en/20190405_hambacher_erklaerung.pdf
Kurzlink: https://uldsh.de/tb42-6-1-4a
Empfohlene technische und organisatorische Maßnahmen bei der Entwicklung und dem Betrieb von KI-Systemen
Positionspapier der Datenschutzkonferenz (6. November 2019):
https://www.datenschutzkonferenz-online.de/media/en/20191106_positionspapier_kuenstliche_intelligenz.pdf
Kurzlink: https://uldsh.de/tb42-6-1-4b

Grundrechte und Grundfreiheiten natürlicher Personen sind beim Einsatz von KI-Systemen gleich mehrfach betroffen: Personenbezogene Daten können beim Training sowie beim Arbeiten mit der Software verarbeitet werden. Die Ausgaben eines KI-Systems können außerdem falsche personenbezogene Angaben bis hin zur Diskriminierung enthalten. Dabei ist die genaue Funktionsweise von KI-Systemen meist unklar, sodass weder Transparenz bei der Verarbeitung gewährleistet werden kann noch sich Betroffenenrechte, wie z. B. das Recht auf Löschen, umsetzen lassen.

Insgesamt gibt es mit diesen und vielen weiteren ungeklärten Fragestellungen erhebliche Rechtsunsicherheiten. Notwendig ist mehr Forschung zur Sicherheit, Transparenz und Erklärbarkeit von KI-Systemen und eine weitere intensive Diskussion der datenschutzrechtlichen Fragen. Das ULD unterstützt diesen Prozess in verschiedenen Formen und steht auch als Ansprechpartner zur Verfügung.

Im Berichtsjahr wurden Vorarbeiten zu weiteren Materialien der DSK zu künstlicher Intelligenz geleistet, die im Jahr 2024 veröffentlicht werden sollen.

6.2          Deutschlandweite und internationale Zusammenarbeit der Datenschutzbeauftragten

6.2.1       Neues aus dem AK Technik

Der AK Technik der Datenschutzaufsichtsbehörden des Bundes und der Länder ist derjenige Arbeitskreis, der sich mit technischen Fragestellungen beschäftigt. Da technische Fragen meist unabhängig von Staaten und Institutionen sind, beteiligen sich u. a. auch Vertreter des Datenschutzes aus den Bereichen Kirchen und Rundfunk sowie der Datenschutzaufsichtsbehörden im deutschsprachigen Ausland.

Eine sich in den letzten Jahren abzeichnende Tendenz der Spezialisierung hat sich weiter verstärkt: Die Tätigkeit hat sich von der Arbeit im Gesamtgremium hin zu Unterarbeitsgruppen (z. B. UAG SDM, Tz. 6.2.2) und interdisziplinären Taskforces (etwa „Microsoft 365“, Tz. 6.2.3, Taskforce Souveräne Cloud, Tz. 6.2.4, Künstliche Intelligenz, Tz. 6.3.1) verschoben. Diese sind teils zeitlich befristet für ein Einzelprojekt (etwa die Taskforce Souveräne Cloud), teils als dauerhafte Institution (wie die Unterarbeitsgruppe SDM) tätig.

Auch die Zusammenarbeit mit der europäischen Ebene spezialisiert sich weiter: Zwar agiert der AK Technik weiterhin als deutsches Spiegelgremium zur europäischen Technology Expert Subgroup, der Arbeitsgruppe des Europäischen Datenschutzausschusses (EDSA) für Technikaspekte, und die deutschen Vertreter in der Technology Expert Subgroup stimmen die deutsche Position mit dem AK Technik ab. Doch mittlerweile sind bestimmte Fragestellungen und Detailabsprachen bei der Formulierung von europaweiten Dokumenten so spezialisiert und unterliegen oft gleichzeitig einem hohen Zeitdruck, dass eine detaillierte Zuarbeit des AK Technik nicht mehr als Gremium erfolgt, sondern die Expertise einzelner Aufsichtsbehörden in Ad‑hoc-Arbeitsgruppen benötigt wird.

Erwägungsgrund 26 Satz 5 der DSGVO
Die Grundsätze des Datenschutzes sollten daher nicht für anonyme Informationen gelten, d. h. für Informationen, die sich nicht auf eine identifizierte oder identifizierbare natürliche Person beziehen, oder personenbezogene Daten, die in einer Weise anonymisiert worden sind, dass die betroffene Person nicht oder nicht mehr identifiziert werden kann.

Ein Beispiel sind weiterhin die Dokumentenentwürfe zu Pseudonymisierung und Anonymisierung. Diese vermeintlich rein technischen Verfahrensschritte der Pseudonymisierung oder Anonymisierung vor einer weiteren Verarbeitung oder Weitergabe von Daten an Dritte sind deswegen relevant, weil ihre praktische Wirksamkeit grundlegende Rechtsfolgen nach sich ziehen kann: Die DSGVO gilt gemäß Erwägungsgrund 26 nämlich nicht für anonyme Daten.

Einige Verantwortliche wollen genau dies: Die personenbezogenen Daten anonymisieren und anschließend die resultierenden Daten – die möglichst denselben Informationsgehalt aufweisen sollen – außerhalb des Gültigkeitsbereichs der DSGVO verarbeiten. Dies schließt auch die Übermittlung der einer Anonymisierung unterzogenen Daten an Dritte und auch Organisationen außerhalb der EU ein – Verarbeitungen, die häufig im Umfeld medizinischer Forschungen erfolgen. In diesen Fällen muss sichergestellt sein, dass die Anonymisierung wirklich funktioniert hat und die Daten insoweit ohne Datenschutzrisiken für die betroffenen Personen weitergegeben werden können.

Was sich hier leicht als Anforderung benennen lässt, muss für praktische Anwendungen aber noch weiter ausformuliert werden, etwa bei der Frage, inwieweit Zusatzwissen der Daten empfangenden Stellen zu bedenken ist und welche Anforderungen genau an die Berücksichtigung zukünftiger technischer Entwicklungen zu stellen sind, mit denen später Daten erneut betroffenen Personen zugeordnet werden können. Auch die Frage, inwieweit dabei Aussagen, die nur mit einer gewissen Wahrscheinlichkeit zutreffen (etwa statistische Aussagen), in die Rechte und Freiheiten von Personen eingreifen, spielt dabei eine Rolle.

Eines ist aber heute schon klar: Es ist nicht möglich, eine Anonymisierung zu erreichen, wenn der Informationsgehalt der Daten unverändert sein soll. In diesen Fällen ist Anonymisierung nicht die Lösung, sondern es kann ein Personenbezug der Daten nicht ausgeschlossen werden, die Verarbeitung bleibt also innerhalb der DSGVO. Das ist kein Beinbruch – der Verantwortliche benötigt allerdings eine Rechtsgrundlage. Schwieriger ist der Fall der vermeintlichen Anonymisierung: Die Daten sind schon munter weitergegeben worden, insbesondere ohne betroffene Personen zu informieren oder die nötigen technischen und organisatorischen Schutzmaßnahmen zu treffen, als sich herausstellt, dass sie doch einen Personenbezug aufweisen. Dies gehört zu den Punkten, mit denen wir uns in dem Kompetenzcluster AnoMed (Tz. 8.5) beschäftigen.

 

6.2.2       Neues vom Standard-Datenschutzmodell

2023 war das bislang ruhigste Entwicklungsjahr seit Bestehen des Standard-Datenschutzmodells (SDM). Ruhig bedeutet, dass keine Änderungen am Modell vorgenommen und keine weiteren Bausteine veröffentlicht wurden. Stattdessen standen zwei andere Themen im Vordergrund: das Wissen zum SDM und dessen Anwendung zu verbessern und die Entwicklung guter SDM-Tools voranzubringen.

Das ULD wurde bei der Durchführung von ganztägigen Workshops und Coachings zum SDM stark beansprucht, insbesondere bei anderen Datenschutzaufsichtsbehörden. Diese Workshops haben bereits zu einer Standardisierung der Planung einer gemeinsamen Prüfung durch verschiedene Datenschutzbehörden auf der Grundlage des SDM-Würfels (siehe 41. TB, Tz. 6.2.2) geführt.

Speziell auf kommunaler Ebene liegen inzwischen verstärkt weitere Erfahrungen mit Datenschutz-Folgenabschätzungen auf der Grundlage des SDM vor, in einigen Fällen unter Zuhilfenahme von SDM-Tools.

Bei den meisten derzeit verfügbaren SDM-Tools handelt es sich um eine Aufbereitung der in den SDM-Bausteinen genannten Schutzmaßnahmen in Form selbst entwickelter Formulare in Tabellenkalkulationen. Derartige Programme werden inzwischen auch auf dem freien Markt angeboten, in zum Teil allerdings unzureichender Qualität. Diese Beobachtung zur Qualität hatte die Unterarbeitsgruppe SDM (UAG SDM) zum Jahreswechsel 2022/2023 zum Anlass genommen, sich einen Überblick über SDM-Tools zu verschaffen. Über den SDM-Newsletter sowie das SDM-Forum des Bundesbeauftragten für den Datenschutz und die Informationsfreiheit wurden Programmhersteller speziell von SDM-Tools aufgerufen, sich bei der UAG SDM zu melden. Daraufhin bekamen elf Hersteller die Gelegenheit, ihr SDM-Tool eine Stunde lang per Videokonferenz exklusiv den Mitgliedern der UAG SDM vorzustellen.

In diesen Vorstellungen wurde deutlich, dass der Leistungsumfang der Tools breit streut. Weit verbreitet sind derzeit Formulare auf Excel- und Access-Basis, die vornehmlich gestatten, die Umsetzung von Maßnahmen aus den SDM-Bausteinen zu dokumentieren. Mehr Unterstützung bieten sogenannte SDM-Wizards, die beim Ausfüllen von Formularen assistieren. So wurden erste Prototypen gezeigt, die auf der Grundlage des SDM-Würfels eine auf die konkrete Verarbeitung abgestimmte Modellierung von Verarbeitungen vornehmen und dadurch einen programmgestützten Ablauf für Beratung, Prüfung und Controlling bieten. Solche für die Prüfpraxis besonders hilfreichen Wizards sind bisher nach unserer Kenntnis (Stand: Januar 2024) noch nicht auf dem Markt verfügbar, werden aber teilweise schon organisationsintern eingesetzt.

Interessierte an SDM-Tools sollten die Meldungen des SDM-Newsletters des ULD verfolgen.
Link zum Newsletter:
https://www.datenschutzzentrum.de/
mailinglisten/#sdm
Kurzlink: https://uldsh.de/tb42-6-2-2a

Bei der Tool-Sichtung zeigte sich, dass nicht alle Hersteller von Tools für Informationssicherheit ein hinreichendes Verständnis für das spezifische Schutzgut des Datenschutzes ausgebildet hatten. Es reicht nicht aus, wenn lediglich eine bereits bestehende Grundschutzmodellierung im Wesentlichen nur quantitativ um weitere Schutzziele ergänzt wird. Diese Beobachtung veranlasste die UAG SDM, erste Vorschläge zur Kennzeichnung der Art der Assistenz von SDM-Tools zu erarbeiten, um die Beschaffungsteams vor falschen Versprechungen bezüglich der SDM-Orientierung zu schützen:

• SDM-VE: nutzt die drei Verfahrensebenen des SDM,
• SDM-DSP: nutzt die Unterscheidung Daten, Systeme, Prozesse,
• SDM-VV: nutzt die Unterscheidung der neun Verarbeitungsvorgänge,
• SDM-VP: nutzt die Unterscheidung der vier Verarbeitungsphasen,
• SDM-GZ: nutzt das vollständige Set der Gewährleistungsziele,
• SDM-RM: nutzt die Risikomodellierung anhand der Gewährleistungsziele,
• SDM-GM: nutzt den vollständigen Katalog generischer Maßnahmen,
• SDM-BS: nutzt den vollständigen Katalog veröffentlichter SDM-Bausteine,
• SDM*: nutzt alle SDM-Komponenten.

Wie weit der Markt der Datenschutzmodellierungstools diese Kennzeichnungen nutzen wird, ist allerdings offen.

Was ist zu tun?
Die professionellen Anwendenden des SDM sollten ihre Erwartungen an Tools gegenüber den Herstellern kommunizieren.

 

6.2.3       Update Microsoft 365  – Erarbeitung einer Handreichung für Microsoft 365

Im November 2022 hatte die Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder erneut festgestellt, dass Verantwortliche beim Einsatz der Office-Anwendungen von Microsoft 365 den Nachweis einer datenschutzkonformen Verarbeitung auf Basis der damals vorliegenden Materialien nicht erbringen können. Grundlage für diese Feststellung war ein 58-seitiger Abschlussbericht der DSK-Arbeitsgruppe „Microsoft Online-Dienste“, die intensive Gespräche mit Vertreterinnen und Vertretern von Microsoft geführt hatte.

Microsoft 365
Der vom US-amerikanischen Unternehmen Microsoft angebotene Online-Dienst Microsoft 365 (ehemals Office 365) beinhaltet die Online-Versionen von Office-Anwendungen wie Word oder Excel sowie weitere Webanwendungen. Mit Microsoft 365 kann ortsunabhängig und von jedem unterstützten Endgerät aus gearbeitet werden. Die Daten befinden sich in Rechenzentren von Microsoft.

Da sich diese grundsätzliche Feststellung der DSK auf die allgemeinen Vertragsgrundlagen für Microsoft 365 bezog, gab und gibt es bei vielen Verantwortlichen die Frage, inwieweit die Möglichkeit besteht, im konkreten Einsatzszenario einen datenschutzkonformen Betrieb von Microsoft 365 zu erreichen.

Auf Initiative des Landesbeauftragten für den Datenschutz Niedersachsen wurde in einer informellen Arbeitsgruppe mehrerer Aufsichtsbehörden eine Handreichung für Verantwortliche erstellt, die Microsoft 365 einsetzen möchten.

Mit der Handreichung werden die im Abschlussbericht aufgezeigten Problemfelder konkret beschrieben und – wo möglich – Wege aufgezeigt, wie die Vorgaben der DSGVO eingehalten werden können. Der größte Teil der Handlungshinweise umfasst Anpassungen des Vertrags und eine Nachbesserung der Produktdokumentation. Die Verantwortlichen müssen entsprechende Anpassungen und Nachbesserungen beim Auftragsverarbeiter Microsoft einfordern.

Die DSK-Arbeitsgruppe „Microsoft Online-Dienste“ hat einen umfangreichen Bericht über die Untersuchungen erstellt und der DSK vorgelegt. Die beschlossene Festlegung der DSK wurde zusammen mit einer Zusammenfassung des Berichts veröffentlicht. Die Verfahrensweise der Arbeitsgruppe war von einer starken Einbindung von Expertinnen und Experten sowie Verantwortlichen von Microsoft geprägt. In 14 mehrstündigen Gesprächsterminen wurden die Berichtsgegenstände diskutiert.

Abschlussbericht:
https://www.datenschutzkonferenz-online.de/media/dskb/2022_24_11_festlegung_MS365_abschlussbericht.pdf
Kurzlink: https://uldsh.de/tb42-6-2-3a

Handreichung:
https://www.lfd.niedersachsen.de/startseite/infothek/presseinformationen/einsatz-von-microsoft-365-praxis-tipps-fur-vertrage-mit-microsoft-225722.html
Kurzlink: https://uldsh.de/tb42-6-2-3b

Das ULD beobachtet gemeinsam mit den anderen Aufsichtsbehörden die laufenden Änderungen an den Datenschutzbestimmungen und die vielfältigen Bemühungen, individuelle Anpassungen vorzunehmen.

 

6.2.4       Update „souveräne Clouds “

Digitale Souveränität
Digitale Souveränität ist in einem umfassenden Sinne „die Summe aller Fähigkeiten und Möglichkeiten von Individuen und Institutionen, ihre Rollen in der digitalen Welt selbstständig, selbstbestimmt und sicher ausüben zu können“.
(„Digitale Souveränität“, Kompetenzzentrum Öffentliche IT (ÖFIT), November 2017)

Im vergangenen Jahr berichteten wir über Arbeiten der Taskforce Souveräne Cloud der Datenschutzkonferenz, die an einem Positionspapier mit Anforderungen für die Bereitstellung und Nutzung von souveränen Cloud-Angeboten gearbeitet hat (41. TB, Tz. 6.2.4) und an der das ULD beteiligt war.

Zur Erinnerung: Bei „souveränen Clouds“ geht es um Cloud-Angebote, die es Verantwortlichen ermöglichen, bei der Nutzung der Angebote ihren datenschutzrechtlichen Pflichten effektiv und überprüfbar nachzukommen und dies auch dauerhaft sicherzustellen.

Gerade die dauerhafte Sicherstellung erfordert Maßnahmen, die über eine bloße Betrachtung des datenschutzrechtlichen Status quo hinausgehen. So muss es beispielsweise Strategien und vertragliche Festlegungen geben, wie mit zukünftigen Änderungen der Rechtslage, der technischen Angebote und der Anforderungen der Verantwortlichen umzugehen ist. Dies beginnt bei feingranularen Konfigurationsmöglichkeiten für Cloud-Anwendende und endet bei Möglichkeiten des Wechsels vom Ort der Verarbeitung, des Rechtsrahmens (Stichwort Geltungsbereich der DSGVO) oder auch des Cloud-Anbietenden.

Dabei sind auch Aspekte betroffen, die auf den ersten Blick scheinbar nur wenig mit Datenschutz zu tun haben (z. B. Kündigungsfristen oder die Nutzung von Standards bei der Verarbeitung von Daten eines Verantwortlichen), bei näherer Betrachtung aber einen großen Einfluss darauf haben, datenschutzrechtlichen Pflichten dauerhaft nachkommen zu können.

Das Positionspapier betrachtet die Aspekte der souveränen Clouds in fünf Abschnitten:

• Nachvollziehbarkeit durch Transparenz,
• Datenhoheit und Kontrollierbarkeit,
• Offenheit,
• Vorhersehbarkeit und Verlässlichkeit,
• regelmäßige Prüfung der aufgestellten Kriterien.

Darin werden jeweils Anforderungen formuliert, die ein Cloud-Angebot umsetzen muss bzw. sollte, damit es aus Sicht der DSK den Namen „souveräne Cloud“ zu Recht verdient. Unterschieden wird dabei zwischen Cloud-Anbietenden und Cloud-Anwendenden. Zwar handelt es sich dabei typischerweise um IT-Dienstleister auf der einen Seite und ihre Kunden auf der anderen Seite, doch sagt dies noch nichts über eine datenschutzrechtliche Verantwortlichkeit im Sinne der DSGVO aus: Zwar sind Cloud-Anwendende meist Verantwortliche im Sinne der DSGVO und Cloud-Anbietende deren Auftragsverarbeiter, doch es sind auch andere Fälle denkbar, z. B. eine Verantwortlichkeit von Cloud-Anbietenden (etwa gegenüber Privatpersonen) oder eine gemeinsame Verantwortlichkeit von Cloud-Anbietenden und Cloud-Anwendenden. Schließlich kommt auch infrage, dass die Verantwortlichkeit von konfigurativen Einstellungen abhängt, etwa davon, ob bei der Nutzung von Software durch den Auftragnehmer ebenfalls Daten zu eigenen Zwecken erhoben und verarbeitet werden und der Dienstleister zum Verantwortlichen wird.

Anders als in umgangssprachlichen Texten wurde in diesem Positionspapier eine technisch orientierte Sprache gewählt, um den Verbindlichkeitsgrad der Anforderungen zu formulieren. Die Formulierung von „MUSS“- und „SOLL“-Anforderungen orientiert sich dabei an (internationalen) Standards – auch das IT-Grundschutz-Kompendium des BSI (Tz. 10.3), die Untermenge der SiKoSH-Anforderungen (Tz. 6.1.2) oder die Bausteine des Standard-Datenschutzmodells (Tz. 6.2.2) verwenden derartige Kennzeichnungen: Mit „MUSS“ werden Anforderungen gekennzeichnet, die ausnahmslos umzusetzen sind. Bei „SOLL“-Anforderungen ist kein „soll“ im Sinne von „es wäre zweckmäßig oder schön“ gemeint, sondern eine Anforderung, die dringend empfohlen ist und deren Nichtumsetzung zwar möglich, aber genau zu begründen ist. „SOLL“-Anforderungen kann man sich als „grundsätzlich MUSS“ oder „Muss mit Abweichungsmöglichkeit“ vorstellen.

Da es nur diese beiden Abstufungen der Anforderungen geben sollte, war eine enge Abstimmung in der Taskforce und eine entsprechende Sorgfalt bei der Formulierung erforderlich: Eine „MUSS“-Anforderung ist zwar schnell entworfen, hat aber entsprechende Sonderfälle zu berücksichtigen und ist somit präziser zu formulieren. Die Alternative, komplizierte Anforderungen (vor-)schnell und vermeintlich einfach als „SOLL“-Anforderungen zu formulieren, verschöbe die Arbeit zu denjenigen, die das Positionspapier lesen und anwenden. Die Folge wären verschiedene Interpretationen über den Verbindlichkeitsgrad einer SOLL-Anforderung. Die Vergleichbarkeit von Angeboten derjenigen, die von sich behaupten, die DSK-Anforderungen an souveräne Clouds umzusetzen, würde leiden.

Das Positionspapier ist unter dem folgenden Link abrufbar:
https://www.datenschutzzentrum.de/uploads/dsk/2023-05-11_DSK-Positionspapier_Kriterien-Souv-Clouds.pdf
Kurzlink: https://uldsh.de/tb42-6-2-4a

Was ist zu tun?
Anbietende von Cloud-Dienstleistungen können anhand des Positionspapiers überprüfen, welche Kriterien die Datenschutzbehörden an eine dauerhafte und nachhaltige Umsetzung von Datenschutzanforderungen stellen. Cloud-Anwendende können mit dem Positionspapier als Checkliste Cloud-Angebote überprüfen und vergleichen.

 

6.3          Ausgewählte Ergebnisse aus Prüfungen , Beratungen und Meldungen  nach Artikel 33 DSGVO

6.3.1       Künstliche Intelligenz : Informationsersuchen an OpenAI

Das Jahr 2023 war geprägt von einer breiten Diskussion über künstliche Intelligenz. Anstoß war die kostenlose Veröffentlichung des Chatbots ChatGPT in der Version 3.5 im November 2022. Neben einer allgemeinen Diskussion über verschiedene Formen von KI-Systemen (siehe Tz. 6.1.4) haben auch viele öffentliche und nichtöffentliche Stellen Einsatzmöglichkeiten von ChatGPT geprüft.

Die Taskforce KI der Datenschutzkonferenz hat sich daher – aufbauend auf der vorangehenden Auseinandersetzung mit KI-Systemen – gleich mit einer datenschutzrechtlichen Einschätzung der Einsatzmöglichkeiten von ChatGPT und anderen großen Sprachmodellen (Large Language Models, LLM) beschäftigt. Um die Funktionsweise und die Verarbeitung von personenbezogenen Daten beim Training des Sprachmodells sowie bei der Arbeit mit dem Chatbot genauer zu verstehen, wurde gemeinsam ein Fragenkatalog entworfen.

In gut 40 Fragen wurden im April 2023 vom Unternehmen OpenAI mehr Informationen und Transparenz abgefragt. Neben grundsätzlichen rechtlichen Fragestellungen wurden auch mehrere technische Problemstellungen angesprochen und wie betroffene Personen ihre Rechte geltend machen können.

Die Antworten von OpenAI im Sommer 2023 reichten noch nicht für eine datenschutzrechtliche Beurteilung aus. Doch sie konnten als Grundlage genutzt werden, um tiefer gehende Fragen zu erarbeiten. Im Oktober 2023 wurde unter den Aufsichtsbehörden ein zweiter Fragenkatalog mit insgesamt 79 Fragen abgestimmt und an OpenAI gesendet. Insbesondere der Verarbeitung von sensiblen Datenkategorien gemäß Artikel 9 DSGVO und der Umsetzung der Rechte betroffener Personen wurde besondere Aufmerksamkeit gewidmet. Aufschlussreich können auch Antworten und weitere Informationen zu Maßnahmen sein, die beim Training des Sprachmodells getroffen wurden, da an dieser Stelle entschieden wird, ob personenbezogene oder anderweitig sensible Daten zum Lernen verwendet werden.

Die datenschutzrechtliche Bewertung von KI wird auch in naher Zukunft ein komplexes Verfahren sein. Zum einen gibt es eine wachsende Zahl an Einsatzszenarien, die jeweils einzelne Fragestellungen aufwerfen und kontextabhängig bewertet werden müssen. Hinzu kommen immer mehr Anbieterinnen und Anbieter von KI-Dienstleistungen mit neuen KI-Systemen oder unter Nutzung vorhandener Angebote. Zum anderen werden die eingesetzten Technologien in hoher Geschwindigkeit weiterentwickelt, was sich positiv oder negativ auf die Einhaltung der datenschutzrechtlichen Vorgaben auswirken kann. Da laufend neue Funktionalitäten eingeführt und immer wieder neue Angriffsmöglichkeiten oder rechtliche Probleme bekannt werden, wird es nicht einfacher. Es bleibt abzuwarten, ob die europäische KI-Verordnung dazu beiträgt, dass Anwendende einfacher die „Spreu“ vom datenschutzkonformen „Weizen“ trennen können.

Was ist zu tun?
Ob eine Verarbeitung personenbezogener oder personenbeziehbarer Daten datenschutzkonform in aktuellen KI-Chatbots möglich ist, muss im Einzelfall intensiv geprüft und angesichts der Veränderungsdynamik dieser Systeme laufend kontrolliert werden. Empfehlenswert ist daher, zunächst Anwendungsfälle ohne Personenbezug ins Auge zu fassen.

 

6.3.2       Trends bei gemeldeten Cyberangriffen

Wie in den Vorjahren betrafen zahlreiche Meldungen von Datenschutzverletzungen gemäß Artikel 33 DSGVO Cyberangriffe, insbesondere einen Befall mit Schadsoftware, anschließender Verschlüsselung der Datenbestände und ein erpresserisches Angebot, bei Zahlung einer Geldsumme die Entschlüsselung zu ermöglichen – ein klassischer Fall von Ransomware. Häufig war dies kombiniert mit einem unbefugten Datenzugriff und der Drohung, bei Nichtzahlung eines „Lösegelds“ die erlangten Daten zu veröffentlichen.

Während im ersten Fall „nur“ die Verfügbarkeit der Daten betroffen scheint und man durch gute Back-up- und Wiederherstellungsverfahren den Schaden schnell begrenzen kann, muss man bei einer glaubhaften Drohung einer Veröffentlichung mit einem Verlust der Vertraulichkeit rechnen (der sich in vielen Fällen auch bewahrheitet).

Aber auch im Falle der reinen Verschlüsselung ist das IT-System kompromittiert – ein Angreifer hatte ja die Gelegenheit, Schadcode zur Ausführung zu bringen. In beiden Fällen sind daher die IT-Systeme sorgfältig auf weiteren Schadcode und andere Manipulationen zu untersuchen. Ebenso muss untersucht werden, auf welche Weise der Schadcode in das System gelangte und welche Gegenmaßnahmen dies zukünftig verhindern oder zumindest die Wahrscheinlichkeit einer Kompromittierung senken. Daneben sind Härtungsmaßnahmen zu ergreifen, damit eingeschleppter Schadcode möglichst wenig Schaden stiften kann.

Typische Maßnahmen sind hier die Deaktivierung von Makros und anderen Programmbestandteilen in Dateien, die per E-Mail, Download oder Upload in ein System eingespielt werden. Ebenso hilft als Härtungsmaßnahme auf Betriebssystemebene ein sogenanntes „Application Whitelisting“: Nur ausdrücklich benannte und durch die Administration installierte Programme sind zur Ausführung freigegeben – von den Nutzenden heruntergeladene Programme oder unbewusst übertragener Schadcode nicht.

Diese Maßnahmen helfen nicht, wenn der Schadcode Sicherheitslücken ausnutzt, die in regulär installierter Software bestehen. Hier hilft nur der alte (40. TB, Tz. 6.3.3) Grundsatz „Patchen, patchen, patchen“, also die zeitnahe Installation von Sicherheitspatches (d. h. Software-Updates, die Fehler und Sicherheitslücken beheben).

Zu beobachten ist, dass das Zeitfenster zwischen der Entdeckung einer Sicherheitslücke und dem Ausnutzen durch Angreifer immer kleiner wird und folglich auch das Zeitfenster für die Installation von Patches. Dies betrifft nicht nur Betriebssysteme und Software der Bürokommunikation, sondern auch Softwarekomponenten im Hintergrund (etwa Datenbankmanagementsysteme, Webserver und die von ihnen verwendeten Softwarekomponenten wie Java und PHP-Interpreter) und Software für Online-Dienste, etwa Shopsysteme für Webshops.

Ein weiterer Schwerpunkt der Meldungen lag bei unbefugten Zugriffen auf (cloudbasierte) E‑Mail-Konten. Ausgangspunkt der Entdeckung war häufig, dass ein solches E-Mail-Konto unbefugt benutzt wurde, um Werbung oder Spam zu versenden.

Anders als in der Vergangenheit, als in solchen Fällen häufig Werbe-E-Mails bei schlecht gesicherten E-Mail-Servern lediglich unbefugt zum Versand „eingeliefert“ wurden, geht es mittlerweile zunehmend um schreibende Zugriffe auf einzelne E-Mail-Konten. Es muss dann geprüft werden, ob es bei der Benutzung des E-Mail-Kontos zum Spam-Versand geblieben ist: Wer aus einem Konto senden kann, kann auch lesen und kopieren, d. h. Daten unbefugt zur Kenntnis nehmen. Teilweise lässt sich dies anhand einer Protokollierung des E-Mail-Servers feststellen.

Der Zugriff bei webbasierten Konten ist, anders als in der klassischen Welt beim Zugriff mit organisationseigenen Rechnern aus Büroräumen heraus auf den organisationseigenen Server, zunächst von jedem Endgerät und jedem Ort der Welt über das Internet möglich, wenn als Absicherung lediglich auf ein Passwort gesetzt wird. Wird einem Angreifer dieses Passwort bekannt, beispielsweise über einen Phishing-Angriff, kann dieser ebenso wie rechtmäßige Eigentümer auf das Postfach zugreifen. Es sind daher zusätzliche Sicherungsmaßnahmen vorzusehen, beispielsweise eine Zwei-Faktor-Authentifizierung oder die Begrenzung des Zugriffs auf bestimmte Netze (z. B. über ein VPN) oder bestimmte Endgeräte.

Bemerkenswert waren auch zahlreiche Fälle, die auf Datenpannen bei Dienstleistern zurückzuführen sind: Formal richtig informierten diese ihre Auftraggeber, die ihrerseits die Datenschutzverletzung gemäß Artikel 33 beim ULD meldeten. In den meisten Fällen war dies auch inhaltlich geboten, denn die Auftraggeber sind Verantwortliche im Sinne der DSGVO und können, zumeist anders als die Auftragnehmer, die Art der verarbeiteten Daten und Risiken für betroffene Personen einschätzen – die Fälle sind daher einzeln zu betrachten.

Bei rein technisch gelagerten Datenschutzverletzungen ist dies aber nicht immer zielführend, etwa wenn bei einem Dienstleister eine Software-as-a-Service-Anwendung betroffen ist: Hier gibt es eine Ursache, die gleichermaßen auf alle Auftraggeber wirkt, von diesen aber im Einzelfall nicht maßgeblich beeinflusst werden kann – ein typisches Phänomen von Cloud-Angeboten. Es würde mehr Sinn ergeben, auf technischer Ebene die Ursache und Abhilfemaßnahmen direkt mit dem Dienstleister zu klären, als dies jeweils einzeln und dafür mehrfach über Umwege mit den Auftraggebern zu tun.

Im öffentlichen Bereich ist diese Problematik erkannt worden: Bei Verordnungen zu gemeinsamen Verfahren gemäß § 7 Abs. 4 LDSG wird typischerweise vorgesehen, welche der beteiligten Stellen für die Abgabe und Bearbeitung der Meldungen gemäß Artikel 33 DSGVO zuständig ist.

Was ist zu tun?
Bei der Meldung von Datenschutzverletzungen sind insbesondere Maßnahmen vorzusehen und zu benennen, die einer Ausbreitung des Schadens und einer Wiederholungsgefahr entgegenwirken.

 

6.3.3       Prüfung  Videokonferenzsysteme

Im Herbst 2021 begann eine gemeinsame Prüfung von Videokonferenzsystemen, die Dataport, der IT-Dienstleister für die (nord-)deutschen Bundesländer, den dortigen Behörden anbietet. An der Prüfung beteiligten sich die Datenschutzaufsichtsbehörden der Länder Hamburg, Bremen, Sachsen-Anhalt und Schleswig-Holstein (40. TB, Tz. 6.3.5). Prüfmaßstab waren zum einen funktionelle Anforderungen mit Datenschutzrelevanz, zum anderen technische Realisierungen und vertragliche Regelungen mit beteiligten Subunternehmern.

Eine Herausforderung bestand zunächst darin, die unterschiedlichen Angebote Dataports zu klassifizieren und zu unterscheiden: Einige Videokonferenzlösungen sind landesweit unter einem Softwarenamen wie „Jitsi“ bekannt, werden aber durch Dataport in verschiedenen technischen Ausprägungen betrieben und unter entsprechenden Namen bereitgestellt. Schließlich gibt es noch verschiedene Versionen sowie teilweise eine Integration der Videokonferenzlösung in eine übergreifende Plattform.

Die Videokonferenzlösungen werden teils unmittelbar bei und durch Dataport betrieben, teils sind Teile der (technischen) Datenverarbeitung in Form von Containern ausgelagert. Bei Videokonferenzsystemen sind hier verschiedene Ausprägungen möglich, beispielsweise eine Trennung vom Aufbau der Konferenz (einschließlich der Authentifizierung der Nutzenden) einerseits und der technischen Durchführung (Signalübertragung zwischen den Kommunikationspartnern) andererseits. Hintergrund dieser Trennung sind meist technische Aspekte wie Bandbreite der Netzanbindung und benötigte Rechenkapazität: Die gleichzeitige Bereitstellung von Videokonferenzen, etwa für viele Schulklassen an Vormittagen, erfordert Netz- und Serverkapa zitäten, die zu anderen Zeiten nicht genutzt würden – ein klassischer Fall für Cloud-Computing-Ansätze und Auslagerung zu Dienstleistern.

Bei solchen Auslagerungen sind mittlerweile verschiedene Implementierungen möglich. So gibt es – das ist das eine Ende des Spektrums – die Möglichkeit einer vollständigen Software-as-a-Service-Nutzung eines Videokonferenzsystems eines Anbieters (Cloud-Software). In diesem Fall liegt die Hoheit über die Software beim Cloud-Anbieter; es sind allenfalls konfigurative Anpassungen möglich. Das andere Ende des Spektrums ist die Bereitstellung von Softwarecontainern, die lediglich bei einem externen Dienstleister in dessen Cloud-Umgebung ausgeführt werden, hinsichtlich der Programmierung und Konfiguration aber vollständig unabhängig von diesem sind. Einen solchen Weg hat Dataport gewählt.

In der Prüfung werden zwei Gruppen von Videokonferenzdiensten betrachtet:

• Das Produkt „dVideokommunikation“, das vollständig von Dataport betrieben wird, aber auf der Software eines kommerziellen Anbieters aufsetzt und auch (im Einzelfall) dessen Support-Dienstleistungen erfordert.
• Videokommunikationsdienste unter dem Stichwort „dOnlinezusammenarbeit“, die einzeln oder als Bestandteil eines größeren Angebots („dPhoenixSuite“) in verschiedenen Konfigurationen bereitgestellt werden.

Die Überprüfung ist noch nicht abgeschlossen, da noch Dokumentationsbestandteile überarbeitet bzw. fertiggestellt werden. Bisher wurden keine wesentlichen Mängel festgestellt.

Was ist zu tun?
Eine vollständige Dokumentation, die neben den von der DSGVO geforderten Nachweisen auch Dokumente zur Betriebsführung, zur Information für Kunden und Hilfsmittel für die durch Kunden umzusetzenden Sicherheits- und Datenschutzmaßnahmen umfasst, unterstützt alle Akteure beim datenschutzgerechten Einsatz.

 

Zurück zum vorherigen Kapitel

Zum Inhaltsverzeichnis

Zum nächsten Kapitel