74,99 €
"Das ist alles sehr kompliziert und schwierig" ist ein häufiger Start bei der Darstellung von komplexen juristischen Themen. In diesem Buch soll mit dem entgegengesetzten Ansatz gestartet werden: "Eigentlich ist alles sehr einfach." Denn Datenschutz bei Microsoft 365 und Copilot kann leicht in drei Punkten zusammengefasst werden: – Es gibt keine rechtlich eindeutige und unbestrittene pauschale Antwort auf die Frage, ob Microsoft 365 und Copilot rechtskonform eingesetzt werden können. – Mit dieser Unsicherheit muss man umgehen können und dafür gibt es Lösungen. – Mit einer tragfähigen Begründung und angemessener Dokumentation können Microsoft 365 und Copilot in den meisten Anwendungsfällen mit minimalen Restrisiken eingesetzt werden. Das Buch bietet für alle drei Punkte Lösungen, indem es die Kritik der Aufsichtsbehörden ausführlich aufarbeitet, eine eigene rechtliche Bewertung vornimmt und sich auch ausführlich dem Umgang mit Unklarheiten und Restrisiken widmet – sowohl aus datenschutzrechtlicher Sicht als auch aus Management-Perspektive. Anhand zahlreicher Hinweise und Checklisten lassen sich Risiken erkennen und minimieren, was dazu beiträgt, eine Haftung von Geschäftsführern und Vorständen zu vermeiden. Ergänzend stehen zahlreiche Musterdokumente zur Verfügung, darunter eine Datenschutz-Folgenabschätzung zum Einsatz von Exchange und Outlook, dem Office-Paket, SharePoint, OneDrive und Teams sowie ein Transfer Impact Assessment. Der Autor berät seit über zehn Jahren zum Datenschutz bei Microsoft-Produkten und führt in diesem Buch technisch fundiert und zugleich praxisnah in die Möglichkeiten ein, Microsoft 365 und Copilot trotz der aufsichtsbehördlichen Positionen zu nutzen. Dabei werden auch die Lizenzvarianten und das Microsoft-Vertragswerk, wie Product Terms, Data Protection Addendum und Zusatzvereinbarungen, vorgestellt und erläutert. Auch auf Sonderthemen wird eingegangen, z. B. § 203 StGB sowie Microsoft-Funktionen wie EU Data Boundary und Customer Lockbox. Mit Grußworten von Dr. Stefan Brink, Frederick Richter und Michael Will.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 383
Veröffentlichungsjahr: 2025
Rechtliche Begründung, interne Freigabe, Datenschutz-Folgenabschätzung und Compliance-Prozesse
Dr. Olaf Koglin
Fachmedien Recht und Wirtschaft | dfv Mediengruppe | Frankfurt am Main
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.de abrufbar.
ISBN 978–3–8005–1957–6
© 2025 Deutscher Fachverlag GmbH, Fachmedien Recht und Wirtschaft, Mainzer Landstr. 251, 60326 Frankfurt am Main, [email protected]
www.ruw.de
Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Druck: Beltz Grafische Betriebe GmbH, 99947 Bad Langensalza
Dieses Werk enthält für Ihren konkreten Einsatz von Microsoft 365 Muster, also generische Dokumente. Anpassungen an die eigene individuelle Sach- und Rechtslage, darauf basierende Risikobewertungen und die Festlegung entsprechender Maßnahmen sind vom Verantwortlichen durchzuführen. Zur einfacheren Suche in einem digitalen Format sind hierfür in Mustertexten Bearbeiterhinweise mit einem # markiert und in eckige Klammern gestellt [#Berarbeiterhinweis].
Soweit nicht anders angegeben, wurden URLs zuletzt im Zeitraum Dezember 2024/Januar 2025 aufgerufen. Das Manuskript basiert größtenteils auf dem Stand von Ende Januar 2025. Letzte Aktualisierungen einschließlich der DPA-Fassung vom 01.04.2025 erfolgten bis Anfang April 2025.
Zu unpräzisen Begriffen in diesem Buch: Die weibliche oder männliche Form sowie Formulierungen im Plural schließen hier stets sämtliche Personen (w/m/d) mit ein. Viele rechtliche Pflichten, die Verantwortliche treffen, sind auch von Auftragsverarbeitern zu erfüllen. Letztere werden dabei in diesem Buch nicht zusätzlich genannt. Statt des Begriffs des Verantwortlichen werden häufig auch rechtlich unpräzise Formulierungen wie Unternehmen, Behörde oder Organisation verwendet. Dies erfolgt bewusst und zur anschaulicheren Darstellung. Entsprechendes gilt u.a. für Begriffe wie „Geschäftsführer“ als Synonym für Organe.
Die „Standardvertragsklauseln“ heißen korrekt Standarddatenschutzklauseln. Dennoch wird hier die verbreitete Abkürzung SCC verwendet. Auch wird in diesem Buch bisweilen von einem „europäischen Gesetzgebungsprozess“ gesprochen, obschon es natürlich nicht den Kontinent Europa, sondern die Europäische Union betrifft. Unterabsätze wie in Art. 6 Abs. 1 DSGVO werden z.T. als „S. 1“ oder gar nicht näher zitiert. Es wird gebeten, diese und ähnliche Präzisionsdefizite zugunsten der besseren Lesbarkeit zu entschuldigen.
„Für alle“ – so hatte ich das Vorwort zu meiner ersten Monografie überschrieben. Es war meine Dissertation, in der ich Rechtsfragen von Open Source Software analysiert hatte. Damals waren die Open-Source-Community, zu der ich zählte, und Microsoft Erzfeinde. Das Geschäftsmodell von Microsoft war die Lizenzierung von „proprietärer Software“, und proprietäre Software wurde durch die „Free Software“-Bewegung in Frage gestellt. Damals galten Konzerne als sichere Quelle für Software, und Kollektive, die ohne Bezahlung Freie Software programmierten, als obskure Konstruktion aus Hacker-Kreisen. Ein Großteil meiner persönlichen Arbeit und der des „Instituts für Rechtsfragen der Freien und Open Source Software“ (ifrOSS) bestand darin, Argumentationen gegen diese Bedenken aufzuzeigen und darzulegen, weshalb Open Source Software ohne unangemessene Risiken eingesetzt werden kann.
In den über 20 Jahren, die seitdem vergangen sind, hat sich die Welt verändert: Heute gelten Konzerne und insbesondere die „Hyperscaler“ aus den USA als obskures Feindbild, während nationale Anbieter und Open Source Software von Aufsichtsbehörden gerne als goldener Weg propagiert werden. Das Geschäftsmodell von Microsoft besteht nicht mehr vorrangig aus dem Verkauf von Softwarelizenzen, sondern aus Cloud Services wie Azure und der Software-as-a-Service-Lösung „Microsoft 365“. Ein Großteil meiner persönlichen Arbeit und der meines Startups LegalCheck besteht darin, Argumentationen gegen die Bedenken der Aufsichtsbehörden aufzuzeigen und darzulegen, weshalb Microsoft 365 und Copilot ohne unangemessene Risiken eingesetzt werden können.
Habe ich mich nun vom Saulus vom Paulus gewandelt, oder mag ich es nur, gegen die „herrschende Meinung“ zu argumentieren – vor allem, wenn sie vom Staat vorgetragen wird oder von jenen, die die Deutungshoheit für sich in Anspruch nehmen? Oder versuchte ich in beiden Fällen lediglich, ungeklärte Rechtsfragen rechtswissenschaftlich zu analysieren? Ich weiß es nicht. Zumindest aber hoffe ich, mit diesem Buch die rechtliche Betrachtung des Einsatzes von Microsoft 365 und Copilot auf juristische, datenschutzrechtliche Themen zu begrenzen und von (industrie-)politischen Aspekten wie der „digitalen Souveränität“ zu befreien.
Dabei freue ich mich auf Gegenrede und wissenschaftliche Diskussionen, zu denen viele der in diesem Buch angesprochenen Themen Anlass geben werden – von A bis Z wie der Auftragsvereinbarung und ihren Details, den Grenzen des Telekommunikationsrechts, dem Umgang mit Restrisiken und den (eigenen) Zwecken der Datenverarbeitung. Daher hoffe ich, dass dieses Buch nicht nur von jenen gelesen wird, die ohnehin Microsoft-Produkte einsetzen oder für sie argumentieren, sondern gerade auch von jenen, die andere Auffassungen vertreten. In diesem Sinne ist die Widmung auch dieses Werks wieder: Für alle.
Für alle gleichermaßen? Nicht ganz. An einen Menschen möchte ich speziell erinnern: Herrn Prof. Dr. Spindler hatte ich im Vorwort zu meiner Dissertation besonders gedankt, und dazu hatte ich allen Grund. Er war stets an neuen Themen interessiert, und hat junge Menschen wie damals mich gerne und selbstlos gefördert. Leider ist Gerald Spindler 2023 viel zu früh verstorben. Ich weiß nicht, ob er gewollt hätte, dass ein so produktbezogenes Buch wie dieses ihm gewidmet wird. Zumindest aber möchte ich mit diesem Vorwort seiner gedenken.
Das Buch enthält viele Inhalte und Bewertungen aus meiner Beschäftigung mit Microsoft-Verträgen und -produkten in der Rolle des Inhouse-Datenschützers, als Rechtsanwalt, Autor und durch LegalCheck. Es war mit dem Verlag ursprünglich als knapp 100-seitiges, kleines Praxishandbuch geplant. Mit der Ausarbeitung und ständigen Vertiefung von Manuskriptteilen, der Übernahme von Inhalten aus meinen Vorträgen und Einarbeitung von aktuellen Themen wurde es immer länger. Auch bei Abgabe der Druckfassung denke ich bei fast jedem Absatz und jedem Argument, dass es noch so viel zu vertiefen, produktseitig oder technisch zu ergänzen, an Argumenten und Gegenargumenten zu verfeinern, und mit anderen Produkten oder Rechtsgebieten zu vergleichen gäbe.
Doch an einem bestimmten Punkt muss bei einem Manuskript der „Code Freeze“ stattfinden, und ich möchte jetzt schon beim Verlag und den zahlreichen Kunden, die das Buch vorbestellt hatten, für die Verzögerung um Entschuldigung bitten. Danken möchte ich in diesem Zusammenhang dem dfv Verlag und Torsten Kutschke für die Aufnahme in diese Reihe sowie Patrick Orth für die gute Betreuung und das professionelle Nudging zur baldigen Abgabe. Ein ganz besonderer Dank geht an Nadine Grüttner für das unermüdliche Nachtragen von Ergänzungen oder Änderungen, und für die vielen guten Ideen. Für viele angenehme Veranstaltungen und tiefgehende rechtliche und technische Diskussionen, bei denen ich sehr viel lernen durfte, möchte ich ganz herzlich Dr. Stefan Brink, Dom Côté, Prof. Dr. Alexander Golland, Stephan Hansen-Oest, Prof. Niko Härting, Raphael Köllner, Dr. Kevin Leibold, Johannes Nehlsen, Wiebke Löck, Iris Phan, Dr. Carlo Piltz, Phillip Reck, Frederick Richter, Heiko Roth, Prof. Dr. Kay Schumann, Ralf Wigand und – ganz besonders – Herrn Michael Will danken. Nicht unerwähnt lassen möchte ich an dieser Stelle auch Stefan Hessel und den immer unkomplizierten und offenen Austausch unter uns. Sehr dankbar für die Unterstützung, Anregungen und Korrekturen bin ich Karol Czuba und Josefine Schulte sowie Jessica Preiß.
Vor allem aber möchte ich meinen tollen Mandanten, Kunden und früheren Kollegen danken, mit denen ich zu diesen Themen in immer wieder anders gearteten Projekten zusammenarbeiten konnte. Ohne Euch/Sie hätte dieses Buch nicht diesem Umfang und das breite Spektrum an Unterthemen.
Last but not least geht eine aufrichtige Bitte um Entschuldigung und großer Dank an meine Familie, die ich durch dieses Buchprojekt an viel zu vielen Abenden, Ferientagen und Wochenenden vernachlässigt habe. Love you, EMGI!
Berlin, April 2025
Olaf Koglin
Wer als Datenschützer den Einsatz von Microsoft 365 und Copilot analysiert, der sieht sich mit einer Fülle von Fragen konfrontiert: Was hat sich an der weltweit verbreiteten „Standard-Software“ dadurch verändert, dass sie als Software as a Service aus der Cloud heraus angeboten wird? Welche Datenflüsse sind zu erwarten, welche nicht? Lässt sich das Produkt in einem Sinne beherrschen, der mit dem Anspruch der Datenschutz-Grundverordnung vereinbar ist, Rechenschaft (!) über alle (!) Datenverarbeitungen abzulegen? Und wie gelingt das bei den Anwendungen, die auf Künstliche Intelligenz setzen?
Das sind gebotene Fragen – aber die Aufgabe von uns Datenschützern besteht eben nicht nur darin, die richtigen Fragen zu stellen; vielmehr müssen wir uns auch und sogar vorrangig darum bemühen, gute, vertretbare und vor allem hilfreiche Antworten auf diese Fragen zu finden. Und dass dieses Buch genau dazu beiträgt, gute Antworten auf notwendige Fragen zu finden, zeichnet es aus.
Berlin, im Januar 2025
Dr. Stefan Brink*
*Geschäftsführender Direktor des wissenschaftlichen Instituts für die Digitalisierung der Arbeitswelt wida/Berlin; Landesbeauftragter für den Datenschutz und die Informationsfreiheit Baden-Württemberg a.D.
Suchen Sie ein Buch zu einer komplexen Datenschutzaufgabe, in dem es nicht nur darum geht, was alles für Bedenken bestehen und was alles für Risiken drohen und was alles einer Lösung im Weg stehen mag? Dann sollten Sie sich vielleicht dem vorliegenden Werk nähern. Denn darin wird recht unbeirrt auf ein Ziel zugesteuert: Den Einsatz eines kommerziellen Produkts eines internationalen Anbieters in datenschutzgerechter Weise unter vertretbarem Aufwand zu ermöglichen. Aufwand erfordert das Gehen des Weges zu diesem Ziel unbestritten, doch nimmt der Autor die Ratsuchenden so konkret an die Hand, dass jener sich meistern lässt.
Fallstricke mag es vor einem datenschutzkonformen Einsatz von vernetzten Microsoft-Produkten durchaus ein paar geben. Auch die Warnungen von Aufsichtsbehörden tragen nicht dazu bei, dieses Compliance-Thema beschwingt anzugehen. Doch mit Ratgebern wie dem vorliegenden lassen sich die Aufgaben beherzt in Angriff nehmen: Die Kritikpunkte der Datenschutzbehörden werden alle aufgegriffen und bewertet, um aufzuzeigen, wie mit ihnen in der Praxis umgegangen werden kann. Wer sich mit den Argumenten auseinandersetzt und sodann zeigt, wie der eigene Einsatz des Microsoft-Produkts risikodämpfend vorgenommen wird, sollte gegen Pauschalkritik gut gewappnet sein.
Frederick Richter, LL.M.
Vorstand der Stiftung Datenschutz
Ein ganzes Buch über Microsoft 365, nur zum Datenschutz, noch dazu beachtlichen Umfangs? War das wirklich nötig?
Gute Gründe sich mit diesem Werk und seinem Thema, den nicht wenigen datenschutzrechtlichen Fragen rund um den Einsatz von Microsoft 365 und seine KI-Komponente Copilot zu beschäftigen, gibt es freilich genug. Beginnend mit der fast ubiquitären Verbreitung des Produkts, seinen fast unerschöpflich anmutenden Funktionalitäten bis hin zu den aus Sicht der Datenschutzpraxis natürlich im Mittelpunkt stehenden unterschiedlichsten Verarbeitungstätigkeiten, die mit und manchmal auch erst Dank Microsoft 365 durchgeführt werden, ergibt sich eine Vielzahl von Fragestellungen, die die kommenden Seiten angehen. Dabei handelt es sich fast immer um Prüfpunkte und mitunter gar um Herausforderungen, die zudem Microsoft 365 nicht exklusiv mit sich bringt, sondern die genauso auch die datenschutzrechtliche Beurteilung anderer Software-as-a-Service-Angebote bestimmen.
Es ist deshalb das besondere Verdienst des Autors, mit einem genauen Blick immer wieder auch den systematischen Kontext der jeweiligen Fragestellungen und ihre teilweise bereits umfangreichere Diskussionsgeschichte durch die verschiedenen Akteure des Datenschutzes wie Beratern, Praxisvertretern oder die deutschen und europäischen Datenschutzaufsichtsbehörden mit in den Blick zu nehmen. Für all' die, die sich ihrer datenschutzrechtlichen Verantwortung beim Einsatz von Microsoft 365 für ihre Verarbeitungstätigkeiten entschlossen stellen wollen, versprechen die folgenden Seiten auf diese Weise facettenreiche Erkenntnisse sowie hoffentlich zielführende Hinweise zu guten und alltagstauglichen, datenschutzgerechten Lösungen.
Ansbach, im März 2025
Michael Will
Präsident des Bayerischen Landesamts für Datenschutzaufsicht
Zur Verwendung dieses Buchs
Für alle
Grußwort von Dr. Stefan Brink
Grußwort von Frederick Richter
Grußwort von Michael Will
Abkürzungsverzeichnis
1. Kapitel: Überblick über die zentralen Themen
1.1 Einführung
1.2 Datenschutzrechtlicher Rahmen
1.3 Datenschutzrechtliche Risiken
1.4 Markt und Alternativen zu Microsoft 365
1.5 Entscheidung der Geschäftsleitung und Business Judgment Rule
1.6 Maßnahmen zur Risikominimierung
2. Kapitel: Herangehensweise und Prüfungsumfang beim Microsoft 365-Projekt
2.1 Projektmanagement zum Datenschutz bei der Microsoft 365-Migration
2.2 Eingrenzung der Themen: In Scope/Out of Scope
2.3 Datenklassifizierung zur Bewertung „Out of Scope“
2.4 Umgang mit ausgegrenzten Themen
3. Kapitel: Risiken beim Einsatz von Microsoft 365, insb. aus Sicht der Aufsichtsbehörden
3.1 Grundsätze der DSGVO und Problemfelder bei SaaS
3.1.1 Rechtmäßigkeit der Datenverarbeitung (Art. 5 Abs. 1 lit. a DSGVO)
3.1.2 Transparenz der Datenverarbeitung (Art. 5 Abs. 1 lit. a DSGVO)
3.1.3 Erforderlichkeit der Datenverarbeitung (Art. 5 Abs. 1 lit. c DSGVO)
3.1.4 Integrität und Vertraulichkeit (Art. 5 Abs. 1 lit. f, Art. 32 Abs. 1 lit. a DSGVO)
3.1.5 Rechenschaftspflicht (Art. 5 Abs. 2 DSGVO)
3.2 DSK & Co.: Struktur und Relevanz der Datenschutzaufsicht in EU und DE
3.2.1 Aufbau der Datenschutzaufsicht in der EU: EDSA und EDSB
3.2.2 Aufbau der Datenschutzaufsicht in Deutschland: Zahlreiche Aufsichtsbehörden
3.2.3 Datenschutzkonferenz (DSK), „Berlin Group“ und weitere inoffizielle Gruppierungen
3.2.4 Rechtliche Natur der Aufsichtsbehörden in der Gewaltenteilung
3.2.5 Zusammenfassung zu Aufsichtsbehörden und ihren nichtbehördlichen Gruppen
3.3 Darstellung der Auffassung der Aufsichtsbehörden
3.3.1 Beschluss der Art.-29-Datenschutzgruppe zum Microsoft Online Services DPA (2014)
3.3.2 Der DSK-Beschluss aus 2020
3.3.3 Der DSK-Beschluss aus 2022
3.3.3.1 Kritikpunkte der DSK in der beschlossenen „Festlegung“ (2022)
3.3.3.2 Weitere Kritikpunkte der DSK in der „Zusammenfassung“ (2022)
3.3.4 Stellungnahme des LfDI BW zu M365 an Schulen (2022)
3.3.5 „Praxis-Tipps“: Handreichung einiger Aufsichtsbehörden (8-9/2023)
3.3.5.1 Herausgeber/Beteiligte Behörden
3.3.5.2 Inhalt und Reaktionen
3.3.5.3 Spezifizierung der Daten und betroffenen Personen
3.3.5.4 Nutzung von E-Mail-Adressen ohne Namen
3.3.6 LfD Niedersachsen: Einsatz von Teams im Innenministerium ist akzeptabel
3.3.6.1 Hintergrund
3.3.6.2 Die niedersächsische „Zusatzvereinbarung“
3.3.6.3 Bewertung des LfD Niedersachsen als akzeptabel
3.3.7 Weitere Stellungnahmen deutscher Aufsichtsbehörden
3.3.8 Verfahren des EDSB gegen die EU-Kommission und darauffolgende Klagen
3.3.8.1 Hintergrund: Rechtlicher Rahmen und Rolle des EDSB
3.3.8.2 Kritik des EDSB an Microsoft 365
3.3.8.3 Entgegnung und Relevanz für den derzeitigen Einsatz von M365
3.3.8.4 Klage der EU-Kommission und von Microsoft Irland gegen den Beschluss des EDSB
3.3.8.5 Antwort der EU-Kommission und Pressemitteilung des EDSB vom Dezember 2024
3.3.8.6 Zusammenfassung und Bedeutung für die Praxis
3.3.8.7 Inhalt der Klagen von Kommission und Microsoft gegen den EDSB
3.3.9 Positionen zu Videokonferenzen und Abgrenzung zum Telekommunikationsrecht
3.3.9.1 Überblick über die aufsichtsbehördlichen Stellungnahmen
3.3.9.2 Komplexität und Heterogenität der Anforderungen
3.3.9.3 Beispiel: End-to-End-Verschlüsselung
3.3.9.4 Einheitlicher Bewertungsmaßstab oder zweierlei Maß?
3.3.9.5 Behördenauffassungen betr. Abgrenzung zur Telekommunikation
3.3.9.6 Bewertung und weitere Differenzierung: Connected Experiences, Exchange
3.3.9.7 Folgen falscher Abgrenzung; Zuständigkeit
3.4 Kritik in der rechtswissenschaftlichen Literatur
3.5 Weitere mögliche Kritikpunkte
3.6 Zusammenfassung des Spektrums von Meinungen und Freigaben
3.7 Ergebnis
4. Kapitel: Argumentationslinien für einen Einsatz von Microsoft 365
4.1 Überblick über den Rechtsrahmen von Verfassungen und Datenschutzrecht
4.1.1 Datenschutz-Basics: Verfassungen, Primärrecht und EU-Grundrechte-Charta
4.1.2 Relevanz von Erwägungsgründen
4.1.3 DSGVO als Sekundärrecht unter der EU-GRCh
4.1.4 Weitere, insb. nationale Normen
4.1.5 Zusammenfassung
4.2 Überblick über das Vertragswerk zu Microsoft 365
4.2.1 Product Terms als Rahmen einzelner Dokumente
4.2.2 Privacy & Security Terms: Definition der Core Services und EU Data Boundary
4.2.3 Das Data Protection Addendum
4.2.3.1 Übersicht zum Data Protection Addendum
4.2.3.2 Data Protection Addendum: Vertragspartner, Lizenzen und Abschluss
4.2.3.3 Data Protection Addendum: Neue Versionen und Aktualisierung bei Bestandskunden
4.2.3.4 Data Protection Addendum: Auftragsverarbeitung und Standarddatenschutzklauseln
4.2.3.5 Data Protection Addendum: Rangfolgeregelungen
4.2.3.6 Ausschlüsse vom DPA, sog. eigene Zwecke
4.2.3.7 Relevanz der „Core Online Services“
4.2.3.8 Angaben zu Arten der Daten, Zwecken etc.
4.2.3.9 Änderungen in der DPA-Fassung vom 18.02.2025
4.2.3.10 Änderungen in der DPA-Fassung vom 01.04.2025
4.2.4 Berufsgeheimnisträger Zusatzvereinbarung und § 203 StGB
4.2.5 Weitere Zusatzvereinbarungen und Rahmenverträge
4.3 Einordnung: Wesen der DSK und Relevanz von aufsichtsbehördlichen Positionen
4.3.1 Rechtsnatur und Relevanz der Datenschutzkonferenz
4.3.2 Keine Verbindlichkeit der Positionen von Aufsichtsbehörden
4.3.3 Zusammenfassung
4.4 Bewertung der Hauptkritikpunkte der Aufsichtsbehörden
4.4.1 Kritikpunkt: Einhaltung der Rechtmäßigkeit nicht nachweisbar
4.4.1.1 Inhalt der Kritik
4.4.1.2 Bewertung
4.4.1.3 Ergebnis
4.4.2 Kritikpunkt: Transparenz über „eigene Zwecke“ von Microsoft und eingesetzte Drittanbieter
4.4.2.1 Eigene Tätigkeiten
4.4.2.2 Tätigkeiten zur Leistungserbringung: Connected Experiences, Telemetrie- und Diagnosedaten
4.4.2.3 Die Connected Experiences („verbundene Erfahrungen“)
4.4.2.4 Exkurs: Darstellung von Connected Experiences
4.4.2.5 Exkurs: Darstellung der optionalen Connected Experiences, insb. „Giphy“
4.4.2.6 Telemetrie- und Diagnosedaten
4.4.2.7 Bewertung zu Connected Experiences; Telemetrie und Diagnose
4.4.2.8 Zusammenfassung
4.4.3 Kritikpunkt: Übermittlung von Daten in die USA und Offenlegung an (US-)Sicherheitsbehörden
4.4.3.1 EU-US Privacy Framework
4.4.3.2 Gültigkeit des DPF
4.4.4 Kritikpunkt: „Latente Übermittlung“
4.4.5 Kritikpunkt: Subunternehmer
4.4.5.1 Angebliche Pflicht zur Überprüfung von Unterauftragsverarbeitern
4.4.5.2 Information über Änderungen der eingesetzten Unterauftragsverarbeiter
4.4.6 Besonderheit: Telekommunikationsrecht
4.5 Änderungen durch das EU-US Data Privacy Framework (2023)
4.6 Weitere Änderungen seit dem DSK-Beschluss aus 2022
4.7 Faktisches Argument: Nutzung von M365 durch Behörden
4.8 Sekundäre Argumente gegen die Auffassung der DSK
4.9 Besonderheiten bei speziellen Arten von Verantwortlichen und Branchen
4.9.1 Einsatz von M365 in Behörden und anderen öffentlichen Stellen
4.9.1.1 Kein „berechtigtes Interesse“ bei behördlichen Aufgaben
4.9.1.2 Sensible Daten und Teilnahmezwang
4.9.1.3 Privatrechtliche Gesellschaften in öffentlicher Hand
4.9.2 Gesundheitsdatenschutz und branchenspezifische Regulierung
4.9.3 Datenschutz bei Kirchen und religiösen Vereinigungen (Art. 91 DSGVO)
4.9.4 Datenschutz bei journalistisch-redaktionellen Tätigkeiten
4.10 Zusammenfassung der datenschutzrechtlichen Situation
4.11 Vergleich mit Alternativen zu Microsoft 365 und IT-Governance
4.11.1 Alternative Cloud-Angebote
4.11.2 Digitale Souveränität
4.11.3 Betrieb on premise und IT-Goverance
4.11.4 Datensicherheit und Vermeidung von Datenpannen
4.11.5 Zusammenfassung
4.12 Zusammenfassung: Konkrete Risiken und Maßnahmen bei einem M365-Einsatz
4.13 Maßnahmenplan zur Risikoreduzierung
5. Kapitel: Restrisiken, Prüfungstriefe und Business Judgment Rule
5.1 Verbleibende Unklarheiten
5.2 Erforderliche Prüfungstiefe
5.3 Umgang mit Restrisiken
5.3.1 Handhabung im datenschutzseitigen Projektmanagement
5.3.2 Kommunikative Handhabung; Empfehlungen und „Abraten“
5.3.3 Rechtliche Handhabung von Ungewissheiten
5.4 Management-Entscheidungen und Business Judgment Rule
5.4.1 Die Business Judgment Rule
5.4.2 Business Judgment Rule im deutschen Recht
5.4.3 Inhalt der Business Judgment Rule
5.4.4 Anwendung der Business Judgment Rule auf eine Entscheidung für M365
5.5 Ergebnis
6. Kapitel: Individuelle Projektbeschreibung; Technische und Organisatorische Massnahmen
6.1 Beschreibung des Verantwortlichen und Projektstatus
6.2 Checkliste zur Bestandsaufnahme u. speziellen Risiken beim M365-Einsatz
6.3 In die M365-Migration einbezogene Abteilungen und Daten
6.4 Verwendete Dienste und zur Risikobegegnung vorgesehene Maßnahmen
6.5 Katalog möglicher Maßnahmen
6.6 Beispiel für technische Einstellungen: CIS-Benchmarks
7. Kapitel: Datenschutz-Folgenabschätzung (DSFA)
7.1 Überblick zur Datenschutz-Folgenabschätzung
7.1.1 Inhalt und Zweck der Datenschutz-Folgenabschätzung
7.1.2 Interne Zuständigkeit für die Erstellung der DSFA
7.1.3 Weitere Schritte und „Konsultation“ der Aufsichtsbehörde
7.1.4 Zeitpunkt der DSFA-Durchführung
7.2 Erforderlichkeit der DSFA im konkreten Fall
7.2.1 Vorprüfung: Ist eine DSFA durchzuführen (sog. „Schwellwertanalyse“)?
7.2.2 Ergebnis: Zumindest vorsorgliche DSFA
7.2.3 Ausnahme bei kleinen Organisationen ohne Datenschutzbeauftragten
7.3 Durchführung der Datenschutz-Folgenabschätzung
7.3.1 Vorgehen
7.3.1.1 Gesetzliche Anforderungen an die Durchführung (Art. 35 Abs. 7 DSGVO)
7.3.1.2 Best Practices: Risikomatrix
7.3.1.3 Durchführung der DSFA nach Diensten und Phasen
7.3.1.4 Scope der Risikoanalyse: Beschränkung auf M365-spezifische Aspekte
7.3.2 Besondere Risikofaktoren beim Verantwortlichen
7.3.2.1 Rechtliche Besonderheiten
7.3.2.2 Betriebs-/ Dienstvereinbarung
7.3.2.3 Risikobezogene Besonderheiten
7.3.2.4 Organisatorische Umsetzung und laufende Änderungen
7.3.2.5 Durchführung als fortlaufende Folgenabschätzung: Initial „DSFA light“ plus M365-Gremium
7.3.3 Erfassungs- oder Vorbereitungsphase (Art. 35 Abs. 7 lit. a DSGVO)
7.3.3.1 Exchange/Outlook Online
7.3.3.2 Word/ppt/xls Online
7.3.3.3 OneDrive, SharePoint Online
7.3.3.4 Teams
7.3.4 Bewertungsphase (Art. 35 Abs. 7 lit. b und c DSGVO)
7.3.4.1 Exchange/Outlook Online
7.3.4.2 Word/PowerPoint/Excel Online
7.3.4.3 OneDrive, SharePoint Online
7.3.4.4 Teams
7.3.5 Gesamt-Risikobewertung vor Maßnahmen
7.3.6 Maßnahmenphase (Art. 35 Abs. 7 lit. d DSGVO)
7.3.7 Risikobewertung nach Maßnahmen
7.3.8 Abschließende Bewertung
7.3.9 Dokumentation zur DSFA; Änderungen und Versionskontrolle
7.4 Anhänge zur Datenschutz-Folgenabschätzung
7.4.1 Anhang 1: Vorbereitende Risikoanalyse
7.4.2 Anhang 2: Hilfsmittel und DSFA-Muster für M365
7.4.2.1 Hilfsmittel zur DSFA-Erstellung
7.4.2.2 Muster und Informationen von Microsoft
7.4.2.3 Veröffentlichte DSFA-Muster zu M365
7.4.2.4 Veröffentlichte DSFA-Muster zu Copilot
8. Kapitel: Entscheidung und Rat des Datenschutzbeauftragten
8.1 Rat des Datenschutzbeauftragten im Rahmen der DSFA
8.2 Entscheidung des Verantwortlichen (durch die Geschäftsführung)
9. Kapitel: Transfer Impact Assessment (TIA)
9.1 Notwendigkeit eines Transfer Impact Assessments
9.2 Sinnhaftigkeit eines SCC-TIA für die USA seit Geltung des DPF
9.3 Terminologie: Drittlandtransfer, Standarddatenschutzklauseln, „EU-US“
9.4 Anforderungen an ein Transfer Impact Assessment
9.4.1 Hintergrund: Schrems II-Entscheidung
9.4.2 Neufassung der SCC 2021 und Kodifizierung des Transfer Impact Assessment
9.4.3 Meinungsstand zu Inhalt und Ablauf
9.4.4 Zuständigkeit für das TIA und Parteien der SCC im Microsoft-DPA
9.4.5 Zeitpunkt der Durchführung und regelmäßige Überprüfung
9.4.6 Inhalt der Prüfung laut Klausel 14 SCC
9.5 Vertragswerk
9.6 Durchführung des Transfer Impact Assessments
9.6.1 Beschreibung der Übermittlung
9.6.1.1 Anwendungsbereich des „Microsoft Products and Services Data Protection Addendum“
9.6.1.2 Kategorien der personenbezogenen Daten
9.6.1.3 Zweck der Verarbeitung
9.6.1.4 Speicherort der übermittelten Daten; EU Data Boundary
9.6.2 Identifizierung der Bestimmungen im Drittland
9.6.2.1 Erläuterung der Problematik, insb. FISA 702 und CLOUD Act
9.6.2.2 Datenschutzrechtliche Relevanz der „latenten Zugriffsmöglichkeit“
9.6.3 Identifizierung der technischen, vertraglichen und organisatorischen Maßnahmen zum Schutz der übermittelten Daten
9.6.4 Datenschutzniveau unter Berücksichtigung des EU-US Data Privacy Framework
9.6.4.1 Das EU-US Data Privacy Framework; Executive Order 14086
9.6.4.2 Bestand des DPF; Latombe-Klage/„Schrems III“
9.6.4.3 Bewertung des Datenschutzniveaus im konkreten Fall
9.6.5 Argumentationen jenseits des DPF
9.7 Gesamtbewertung des TIA
10. Kapitel: Eintrag im Verarbeitungsverzeichnis
10.1 Einleitung
10.2 Vorlage Verarbeitungsverzeichnis
11. Kapitel: Copilot-Varianten und Datenschutz
11.1 Einleitung
11.2 Die Copilot-Varianten
11.2.1 Microsoft 365 Copilot Chat
11.2.2 Microsoft 365 Copilot
11.2.3 Umgang mit laufenden Änderungen der Copiloten
11.2.4 Unterscheidung in der Praxis
11.2.5 Zugriff des Microsoft 365 Copilot auf eigene und Unternehmensdaten
11.2.6 Zugriff des Microsoft 365 Copilot Chat auf eigene und Unternehmensdaten
11.2.7 Einstellungen zu Microsoft 365 Copilot (Chat) im Admin-Center und in Teams
11.3 Datenschutzregeln von Microsoft für die Copilot-Varianten
11.3.1 Geltung des Data Protection Addendum (DPA)
11.3.2 Copiloten als „Products and Services“ im Sinne des DPA und der Product Terms
11.3.3 Copiloten als Core Online Services
11.3.4 Copiloten und EU Data Boundary
11.3.5 Bing-Suchanfragen und Verwendung von Web-Daten
11.3.6 Commercial Data Protection und andere Datenschutz-Programme von Microsoft
11.3.7 Terms of Use & AI-Zusagen von Microsoft
11.3.8 Zusammenfassung
11.4 Fallgruppen bei der Verwendung von Copilot
11.4.1 Use Case 1: Unkritische Daten
11.4.2 Use Case 2: Mittelkritische Daten
11.4.2.1 Spezifische Risiken beim Microsoft 365 Copilot
11.4.2.2 Risikoreduzierung bei Microsoft 365 Copilot
11.4.2.3 Datenschutz-Folgenabschätzung für Microsoft 365 Copilot in Use Case 2
11.4.3 Use Case 3: Sehr kritische Daten sowie Hochrisiko-KI i.S.d. Art. 6 KI-VO
11.4.3.1 Bewertung als Hochrisiko-KI
11.4.3.2 Datenschutz-Folgenabschätzung
11.5 Datenschutz-Folgenabschätzungen zu Microsoft (365) Copilot
12. Kapitel: Anlagen
12.1 FAQ für Mitarbeitende und Öffentlichkeitsarbeit
12.2 Links und weiterführende Literatur
12.2.1 DSK-Dokumente zu M365
12.2.2 Weitere Stellungnahmen der Datenschutzaufsicht
12.2.3 Links und Literatur zu Microsoft 365
12.2.4 Berichte über die Nutzung von Microsoft 365 und Azure in öffentlichen Stellen
a.A.
andere(r) Ansicht
a.a.O.
am angegebenen Ort
a.E.
am Ende
a.F.
alte Fassung
Abb.
Abb.
ABl.
Amtsblatt
Abs.
Absatz
AEUV
Vertrag über die Arbeitsweise der Europäischen Union
AktG
Aktiengesetz
allg.
allgemein
Alt.
Alternative
Art.
Artikel
Aufl.
Auflage
AVV
Auftragsverarbeitungs-Vereinbarung
BW
Baden-Württemberg
BayBG
Bayerisches Beamtengesetz
Bay
Bayern
BayLDA
Bayerisches Landesamt für Datenschutzaufsicht
BayLfD
Bayerische(r) Landesbeauftragte für den Datenschutz
BDSG
Bundesdatenschutzgesetz
BeckOK DatenschutzR
Beck'scher Online-Kommentar Datenschutzrecht, hrsg. v. Wolff/Brink
Bln
Berlin
betr.
betreffend
BfDI
Bundesbeauftragte(r) für den Datenschutz und die Informationsfreiheit
BGB
Bürgerliches Gesetzbuch
BGH
Bundesgerichtshof
BlnBfDI
Berliner Beauftragte(r) für Datenschutz und Informationsfreiheit
Bbg
Brandenburg
Brem
Bremen
BSI
Bundesamt für Sicherheit in der Informationstechnik
BT-Drucks.
Bundestagsdrucksache
BVerfG
Bundesverfassungsgericht
BVerfGE
Entscheidungssammlung des Bundesverfassungsgerichts
bzw.
beziehungsweise
c't
Magazin für Computertechnik
ca.
circa
Corp.
Corporation
d.h.
das heißt
ders.
derselbe
dies.
dieselbe(n)
DPA
Data Protection Addendum
DPF
Data Privacy Framework
DPIA
Data Protection Impact Assessment
DSB
Datenschutz-Berater (Zeitschrift)
DSFA
Datenschutz-Folgenabschätzung
DSGVO
Datenschutz-Grundverordnung
DSK
Datenschutzkonferenz
DSRITB
Deutsche Stiftung für Recht und Informatik Tagungsband
E2EE
End-to-End-Encryption
EA
Enterprise Agreement
EAID
Europäische Akademie für Informationsfreiheit und Datenschutz e.V.
EDPS
European Data Protection Supervisor
EDSA
Europäischer Datenschutzausschuss
EDSB
Europäischer Datenschutzbeauftragter
EG
Europäische Gemeinschaft
Einl.
Einleitung
ErwG
Erwägungsgrund
etc.
et cetera
EU
Europäische Union
EuGH
Gerichtshof der Europäischen Union
f./ff.
folgende
FAZ
Frankfurter Allgemeine Zeitung
Fn.
Fußnote
gem.
gemäß
GG
Grundgesetz für die Bundesrepublik Deutschland
ggf.
gegebenenfalls
ggü.
gegenüber
GmbHG
Gesetz betreffend die Gesellschaften mit beschränkter Haftung
GRCh
Charta der Grundrechte der Europäischen Union
grds.
grundsätzlich
Hmb
Hamburg
Hess
Hessen
Hrsg.
Herausgeber
hrsg.
herausgegeben
i.d.F.
in der Fassung
i.d.R.
in der Regel
i.R.d.
im Rahmen des/der
i.R.v.
im Rahmen von
i.S.d.
im Sinne des/der
i.S.v.
im Sinne von
i.V.m.
in Verbindung mit
IAM
Identity & Access Management
ISMS
Informationssicherheits-Managementsystem
IWGDPT
International Working Group on Data Protection in Technology
IWRZ
Zeitschrift für Internationales Wirtschaftsrecht
K&R
Kommunikation und Recht (Zeitschrift)
Kap.
Kapitel
KI-VO
Verordnung über künstliche Intelligenz
KMU
kleine und mittelständische Unternehmen
LfD
Landesbeauftragte(r) für den Datenschutz
LfDI BW
Landesbeauftragte(r) für den Datenschutz und die Informationsfreiheit Baden-Württemberg
LG
Landgericht
lit.
littera (Buchstabe)
Ltd.
Limited
m.w.N.
mit weiteren Nachweisen
M365
Microsoft 365
MV
Mecklenburg-Vorpommern
MIOL
Microsoft Ireland Operations Ltd.
MMR
Zeitschrift für das Recht der Digitalisierung, Datenwirtschaft und IT
MSA
Microsoft Customer Agreement
MSN
Microsoft Network
MüKo-StGB
Münchener Kommentar zum Strafgesetzbuch, herausg. v. Erb/Schäfer
n.F.
neue Fassung
Nds
Niedersachsen
NK-StGB
Nomos Kommentar zum Strafgesetzbuch hrsg. v. Kind-
häuser/Neumann/Paeffgen/Saliger
No.
Number (Nummer)
NRW
Nordrhein-Westfalen
Nr.
Nummer
o.Ä.
oder Ähnliche(s)
OLG
Oberlandesgericht
portable document format
PGP
Pretty Good Privacy
PIA
Privacy Impact Assessment
RDi
Recht Digital (Zeitschrift)
RhPf
Rheinland-Pfalz
RL
Richtlinie
Rn.
Randnummer
S.
Satz/Seite
s.
siehe
s.o.
siehe oben
Saarl
Saarland
SaaS
Software as a Service
Sächs
Sachsen
LSA
Sachsen-Anhalt
SCC
Standard Contractual Clauses
SchlH
Schleswig-Holstein
SDK
Standarddatenschutzklauseln
SGB
Sozialgesetzbuch
SMTP
Simple Mail Transport Protocol
sog.
sogenannt
StGB
Strafgesetzbuch
Thür
Thüringen
TIA
Transfer Impact Assessment
TKG
Telekommunikationsgesetz
TLS
Transport Layer Security
TOMs
Technische und organisatorische Maßnahmen
u.a.
unter anderem
u.Ä.
und Ähnliches
UA
Unterabsatz
ULD
Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein
unstr.
unstrittig
Urt.
Urteil
usw.
und so weiter
v.
von/vom
vgl.
vergleiche
VO
Verordnung
WRV
Weimarer Reichsverfassung
z.B.
zum Beispiel
z.T.
zum Teil
ZD
Zeitschrift für Datenschutz
ZD-Aktuell
Zeitschrift für Datenschutzrecht
ZEuP
Zeitschrift für Europäisches Privatrecht
Ziff.
Ziffer
ZPO
Zivilprozessordnung
1
„Das ist alles sehr kompliziert und ich habe da Bedenken“ ist ein häufiger Start bei der Darstellung von komplexen juristischen Themen.
2
Hier soll mit dem entgegengesetzten Ansatz gestartet werden: „Eigentlich ist alles sehr einfach.“ Denn Datenschutz bei Microsoft 365 und Copilot kann recht übersichtlich in drei Punkten zusammengefasst werden:
Es gibt keine rechtlich eindeutige und unbestrittene pauschale Antwort auf die Frage, ob Microsoft 365 und Copilot rechtskonform eingesetzt werden können. Diese Situation haben Juristen1 nicht nur bei Microsoft-Produkten, sondern bei fast allen Themen, die neue Rechtsgebiete und komplexe Anwendungsfälle betreffen.
Mit dieser Unsicherheit muss man umgehen können. Diese Situation haben Juristen und Unternehmer bei sehr vielen Themen, und dafür gibt es Lösungen.
Mit einer tragfähigen Begründung und angemessener Dokumentation können Microsoft 365 und Copilot in den meisten Anwendungsfällen mit minimalen Restrisiken eingesetzt werden.
3
Dieses Buch soll bei allen drei Punkten Lösungen bieten, indem es die Kritik der Aufsichtsbehörden ausführlich aufarbeitet, eine eigene rechtliche Bewertung vornimmt, und sich auch ausführlich dem Umgang mit Unklarheiten und Restrisiken widmet – sowohl aus datenschutzrechtlicher Sicht als auch aus Management-Perspektive. Zum Überblick und zur konkreten Umsetzung werden zahlreiche Checklisten und Musterdokumente zur Verfügung gestellt, darunter eine Datenschutz-Folgenabschätzung und ein Transfer Impact Assessment.
4
Der Einsatz von Microsoft 365 als SaaS-Produkt eines US-amerikanischen Anbieters begegnet bekanntlich etlichen datenschutzrechtlichen Bedenken und Risiken. Bei der sachlichen Analyse der Vor- und Nachteile ist zwischen Bedenken oder Meinungen einerseits – auch wenn sie von Aufsichtsbehörden vorgebracht werden – und rechtlichen Fakten andererseits zu unterscheiden. Zudem sind neben den rein datenschutzrechtlichen Argumenten auch die möglichen Alternativen sowie die gesetzlichen Anforderungen an Entscheidungen von Geschäftsführern bzw. Vorständen zu berücksichtigen.
5
Bei der Nutzung von Microsoft 365 können Microsoft-Gesellschaften in den USA (und ggf. auch US-amerikanische Behörden) Zugriff auf Teile der in Microsoft 365 gespeicherten Daten haben. Dadurch liegt datenschutzrechtlich die Möglichkeit einer Übermittlung von personenbezogenen Daten in die USA vor. Dies gilt auch dann, wenn als Datenstandort EU-Regionen ausgewählt werden. Unerheblich ist hierbei auch, ob der Vertrag mit einer europäischen oder einer US-amerikanischen Microsoft-Gesellschaft geschlossen wird.
6
Zu trennen ist zunächst zwischen der bloßen Möglichkeit einer Übermittlung in die USA und dem tatsächlichen Vorliegen einer solchen Übermittlung. Für den Fall einer Übermittlung in die USA ist nach Art. 44ff. DSGVO eine entsprechende rechtliche Grundlage erforderlich. Die zentrale Frage beim Transfer von personenbezogenen Daten in sog. Drittländer (also Staaten außerhalb der EU) ist unter der DSGVO, ob im Zielland ein Datenschutzniveau herrscht, das mit dem der DSGVO vergleichbar ist, oder ob ein solches Niveau zumindest durch zusätzliche Garantien erreicht werden kann. Dies wurde mit dem 2023 beschlossenen EU-US Data Privacy Framework („DPF“) geklärt. Weitere Aspekte wurden zusätzlich im Transfer Impact Assessment (Kap. 9, Rn. 582) geklärt.
7
Zwar hat sich die Rechtssicherheit in Bezug auf die USA durch das DPF erhöht, selbst wenn weiterhin die Standarddatenschutzklauseln verwendet werden. Gleichwohl ist zu konstatieren, dass schon die grundsätzliche Frage, ob in der EU die Services von Cloud-Anbietern aus den USA verwendet werden dürfen, nicht mit absoluter rechtlicher Verbindlichkeit beantwortet werden kann. Zusammen mit der Komplexität einer Software-Suite wie Microsoft 365, die neben den zahllosen Produkten (wie Outlook Online für Mails, Teams für Videokonferenzen und „Collaboration“ sowie Copilot-Varianten für AI-Anwendungen) eine große Zahl an Konfigurationsmöglichkeiten und z.T. lizenzabhängigen Sicherheitsfeatures bereitstellt, ist eine pauschale und rechtssichere Bewertung kaum seriös möglich.
8
Seitens der Datenschutz-Aufsichtsbehörden gibt es, wie meist bei Dienstleistern aus den USA, starke Kritik und Bedenken. Insofern muss ausdrücklich und unmissverständlich vor dem realen Risiko von aufsichtsbehördlichen Maßnahmen gegen den Einsatz von Microsoft 365 gewarnt werden.
9
So wendete sich z.B. die Aufsichtsbehörde Baden-Württembergs Ende April 2022 gegen den Einsatz von Teams an Schulen,2 obwohl sie dessen Einführung in den Jahren davor noch kooperativ begleitet hatte. Bei Schulen liegt freilich eine datenschutzrechtlich besonders sensible Situation vor (Schulpflicht, Minderjährige). Und zugleich hält die besagte Aufsichtsbehörde eine Tür offen und äußerte, dass Schulen, die Microsoft 365 dennoch einsetzen wollen, den rechtskonformen Betrieb selbst sicherstellen und dies dokumentieren müssen – es scheint also selbst für Schulen nicht ausgeschlossen zu sein.
10
Im November 2022 veröffentlichte dann die Datenschutzkonferenz (DSK) einen Abschlussbericht, wonach der Einsatz von Microsoft 365 datenschutzkonform kaum möglich sei. Der Bericht kam einer Produktwarnung nahe,3 die Prüfung jedoch wurde in erster Linie auf EDSA-Papiere, Positionen der DSK oder der einzelnen deutschen Aufsichtsbehörden sowie einiger Entscheidungen des EuGH und weniger deutscher Gerichte gestützt. Entgegengesetzte Auffassungen außerhalb des Kosmos der Datenschutzbehörden wurden hierbei weitgehend ignoriert. Ähnlich war es im September 2023 bei einer Positionierung einzelner Aufsichtsbehörden zu Microsoft 365, wo eher praxisferne Ratschläge für umfangreiche Nachverhandlungen gegeben wurden. Doch es gibt auch positive Stellungnahmen: Im Mai 2024 hat die niedersächsische Datenschutzaufsicht den Einsatz von Teams zumindest mit einer Zusatzvereinbarung für akzeptabel gehalten. Nachdem der Europäische Datenschutzbeauftragte der EU-Kommission ihren bisherigen Einsatz von M365 untersagen wollte, liegen nun dem Europäischen Gericht zwei Klagen vor (Kap. 3.3.8, Rn. 113).
11
Dies spiegelt nur einzelne der zahlreichen Äußerungen der Aufsichtsbehörden wider. Letztere vertreten aufgrund ihrer gesetzlichen Rolle eine eher strenge Auslegung des Datenschutzrechts. Die neutrale und rechtlich einzig verbindliche Entscheidung hierüber käme indes von einem Gericht, und eine höchstrichterliche Entscheidung zur Nutzung von Microsoft 365 existiert nicht. Doch selbst eine solche hätte wohl nur begrenzte Aussagekraft: Bis zu einer Entscheidung durch den BGH oder EuGH – und es ist fest davon auszugehen, dass Microsoft ein faktisches Produktverbot bis zur höchsten Instanz anfechten würde – würden sich die Konfigurationsmöglichkeiten, die Sicherheitsfeatures, die AGB und auch die rechtlichen Rahmenbedingungen für den transatlantischen Datentransfer (wie durch das erwähnte EU-US Data Privacy Framework) sicherlich so verändern, dass ein Urteil über die ursprüngliche Rechtslage wenig Aussagekraft über die dann aktuelle Situation hätte. So gesehen wird es wohl niemals eine verbindliche Entscheidung geben, die konkret eine jeweils aktuelle Version von Microsoft 365 untersagt. Hierzu kommt, dass Aufsichtsbehörden nicht ein Produkt, sondern die konkrete Verarbeitung personenbezogener Daten zu bewerten haben.
12
Neben der Frage des Drittlandtransfers werden insb. von den Aufsichtsbehörden etliche weitere Probleme und Risiken aufgezählt. Dies betrifft zum großen Teil Aspekte bei der sog. Auftragsvereinbarung. Die dazu erforderliche Vereinbarung („AVV“) genüge nicht den gesetzlichen Anforderungen des Art. 28 DSGVO, u.a. sei die Dokumentation der zu verarbeitenden Daten nicht ausreichend. Auch diese rechtliche Bewertung ist nicht zwingend; letztendlich hat sogar die niedersächsische Aufsichtsbehörde die Microsoft-Dokumentation für akzeptabel befunden.
13
Somit besteht, vor allem aus Sicht der Aufsichtsbehörden, beim Einsatz von Microsoft 365 eine Reihe von Risiken. Trotz der äußerst kritischen und ablehnenden Stellungnahmen durch Behörden und Berater gibt es auch eine Reihe von Argumenten und juristischen Stellungnahmen, nach denen die Nutzung von US-Clouds unter Berücksichtigung der gesetzlichen Voraussetzung zulässig ist. Denn die Regelungen der Art. 44ff. DSGVO öffnen ja gerade den Weg, Daten nach außerhalb der EU zu übermitteln. Mit der entsprechenden Konfiguration und „EU Data Boundary“ bleiben die Daten ohnehin weitestgehend in der EU. Und selbst Behörden und andere öffentliche Stellen nutzen M365.
14
Die in einer Management Summary abbildbare Zusammenfassung ist daher:
Es gibt keine Rechtssicherheit – weder in die eine noch in die andere Richtung. Keineswegs ist die Nutzung von Microsoft 365 eindeutig zulässig, risikofrei oder unproblematisch. Andererseits steht auch nicht fest, dass der Einsatz eindeutig unzulässig ist.
15
Externen Beratern fällt es angesichts dieser Rechtslage und der Warnungen der Aufsichtsbehörden leicht, von der Nutzung solcher US-Cloud-Dienstleistungen abzuraten. Im Unternehmen (bzw. der Behörde oder anderen Organisation des Verantwortlichen) selbst reicht es hingegen nicht, lediglich von Produkten abzuraten oder Bedenken anzumelden. Hier stellt sich zugleich immer die Frage nach möglichen Alternativen:
16
Andere US-amerikanische Cloud-Anbieter – wie Google Workspace (ehemals G Suite) – unterliegen vergleichbaren datenschutzrechtlichen Bedenken und sind insofern keine problemlösende Alternative zu Microsoft 365. Noch weniger problemlösend wären Angebote aus anderen Nicht-EU-Ländern, etwa das chinesische WPS Office. Mehr Hoffnung macht(e) eine Kooperation zwischen der Deutschen Telekom und Microsoft, bei der die Daten und die SaaS-Software ursprünglich in Rechenzentren der Deutschen Telekom gehostet wurden. Inzwischen werden aber auch hier die Microsoft-Rechenzentren genutzt,4 so dass diese Lösung beim datenschutzrechtlichen Problem des US-Anbieters keinen entscheidenden Vorteil bringt.
17
Somit bliebe zur Umgehung der datenschutzrechtlichen Bedenken nur die Möglichkeit, die benötigten Lösungen klassisch on premise zu hosten und/oder ausschließlich Rechenzentren zu verwenden, die in der EU liegen und bei denen keine US-Unternehmen beteiligt sind. Da es keinen EU-Anbieter mit einem vergleichbaren Produktportfolio gibt, würde sich damit jedoch die IT-Strategie fundamental verändern: Statt einer zentralen Cloud-Lösung für alle Büroanwendungen gäbe es eine Vielzahl von einzelnen Lösungen mit begrenztem Umfang – etwa ein lokal gehosteter Exchange-Server für E-Mails, separat davon für Textverarbeitungen auf den Endgeräten z.B. Open-Office, und für Videokonferenzen eine Lösung wie Jitsi. Dies hätte nicht nur elementaren Einfluss auf die User Experience, sondern auch auf die IT-Sicherheit: Die zentrale Nutzer- und Konfigurationsverwaltung von Microsoft 365 würde ersetzt durch einzelne Systeme, die separat von Experten betreut werden müssten. Die Folge wären Defizite u.a. beim kurzfristigen Einspielen von sicherheitsrelevanten Patches und Updates sowie beim Identity & Access Management (IAM), so dass eine Reduzierung der IT-Sicherheit wahrscheinlich wäre.
18
Anders als externe (Datenschutz-)Berater kann die Geschäftsleitung sich also bei aufsichtsbehördlichen Bedenken nicht einfach folgenlos gegen ein System (wie Microsoft 365) entscheiden, sondern muss auch die Konsequenzen einer etwaigen Ablehnung in Kauf nehmen bzw. diese gestalten. Da der komplette Verzicht auf E-Mails und Office-Software nicht in Betracht kommt, müsste man sich bei einer Ablehnung von Microsoft 365 also zugleich für eine Alternative entscheiden.
19
In diesem Fall erscheint es wie die Wahl zwischen einer IT-seitig sehr professionellen und weltweit verbreiteten, aber mit etlichen datenschutzrechtlichen Bedenken behafteten Cloud-Lösung einerseits oder andererseits einer Vielzahl von einzelnen Systemen, von denen jedes einzelne nicht so in der Kritik der Aufsichtsbehörden steht wie Microsoft 365, aber jedes für sich auch erhebliche, noch zu analysierende Datenschutzfragen aufwirft, und die vor allem in der Gesamtheit zu einer wesentlich weniger professionellen IT-Landschaft führen, die ihrerseits wieder zu Einbußen in der IT-Sicherheit und damit auch im Datenschutz führt.
20
Hier ist es gerade Aufgabe des (Top-)Managements, unternehmerische Entscheidungen zu treffen und auch bei zwei jeweils nicht optimalen Alternativen eine für das Unternehmen gute oder zumindest akzeptable Ausgangslage zu schaffen. Im Rahmen der Business Judgment Rule liegt daher keine Pflichtverletzung von Vorständen und Geschäftsführen vor, wenn ein Entscheider „bei einer unternehmerischen Entscheidung vernünftigerweise annehmen durfte, auf der Grundlage angemessener Information zum Wohle der Gesellschaft zu handeln“ (für die Aktiengesellschaft: § 93 Abs. 1 S. 2 AktG). Voraussetzung hierfür ist u.a., dass die Entscheidung auf angemessenen Informationen basiert und der Weg nicht (eindeutig) rechtswidrig ist (Kap. 5, Rn. 376).
21
Wichtig ist daher, dass eine entsprechende Entscheidung nicht nur auf einem pauschalen Argument wie „das nutzen doch alle“ oder einem uninformierten „Cloud ist so kompliziert, wir nutzen es einfach“ basiert, sondern eine informierte Entscheidung zugunsten des Unternehmens darstellt. Bei einer komplexen und dauerhaften Thematik wie der Cloud-Nutzung sollte dies auch nicht nur eine einmalige und binäre Ja/Nein-Entscheidung sein, sondern in zeitlicher Hinsicht laufend überprüft werden und in inhaltlicher Hinsicht eine möglichst große Reduzierung der Risiken angestrebt werden. Zu letzterem zählen u.a. eine sorgfältige rechtliche Prüfung und Dokumentation, eine detaillierte und angemessene Konfiguration, Reduktion der zu verarbeitenden Daten (Datensparsamkeit) sowie weitere rechtliche, technische und organisatorische Maßnahmen (Kap. 6.5, Rn. 430).
22
Vor diesem Hintergrund werden datenschutzseitig umfangreiche rechtliche, technische und organisatorische Maßnahmen empfohlen. Diese müssen der Organisation und dem konkreten Risiko angemessen sein und werden ab Kap. 6 (Rn. 413) aufgeführt. Da die Hauptkritik der Datenschutzkonferenz in 2022 die angeblich nicht ausreichende Dokumentation betraf, ist auch anzuraten, eine Datenschutz-Folgenabschätzung nicht nur in den zwingend erforderlichen Fällen durchzuführen, sondern mit dem in Kap. 7 (Rn. 437ff.) vorgelegten ausführlichen Muster auch vorsorglich in Fällen unterhalb dieser Erforderlichkeit.
1Die männliche Form und Formulierungen im Plural schließen in diesem Buch stets auch weibliche und diverse Personen mit ein.
2https://www.baden-wuerttemberg.datenschutz.de/nutzung-von-ms-365-an-schulen.
3Vgl. Benedikt/Schwartmann/Kranig, Microsoft 365 – so sollte Datenschutzaufsicht nicht sein, FAZ, 12.12.2022.
4https://geschaeftskunden.telekom.de/hilfe-und-service/cloud-software/microsoft-365/datenspeicherung-microsoft-365.
23
Die einzelfallbezogene datenschutzrechtliche Bewertung basiert auf einer Beschreibung des Verantwortlichen und der konkreten Nutzung von Microsoft 365 (im Folgenden „M365“).
24
Damit stehen Projektverantwortliche häufig bereits vor dem ersten Henne-Ei-Problem: Vor Klärung der datenschutzrechtlichen Fragen kann (oder sollte) nicht entschieden werden, welche M365-Dienste konkret eingesetzt werden dürfen. In ähnlicher Weise wird diese Problematik bei der Datenschutz-Folgenabschätzung nach Art. 35 DSGVO (ab Rn. 437) auftreten. Daher sollte die hier durchzuführende Beschreibung eher als initialer Projektplan – oder auch als Wunschliste – verstanden werden, die im Rahmen der Einführung von M365 u.a. durch das Projektmanagement und die Datenschutz-Folgenabschätzung angepasst werden wird. Nicht nur in der Softwareerstellung, sondern auch beim Projektmanagement für die M365-Einführung empfiehlt sich hierbei eine agile Vorgehensweise. Dabei werden nicht zunächst sämtliche Anforderungen definiert, bewertet und schließlich umgesetzt, sondern im Lauf des Projekts werden aufkommende Probleme und Lösungen abgearbeitet.
25
Dieser Ansatz kann auch für die Datenschutz-Folgenabschätzung selbst angewandt werden, bei der dann laufende Einzelentscheidungen an ein spezielles Gremium delegiert werden (siehe Kap. 7.3.2.5, Rn. 476).
26
Im Rahmen der Einführung einer komplexen SaaS-Lösung wie M365 werden viele interessante Fragen auftreten. Zum (datenschutzseitigen) Projektmanagement gehört daher, sich hierbei nicht von Nebenaspekten ablenken zu lassen und den Fokus auf die relevanten Fragestellungen zu setzen. Damit zusammenhängend gehört zum Datenschutz-Projektmanagement auch entsprechendes Stakeholder Management, damit allen Beteiligten bewusst ist, dass im Rahmen des M365-Projekts nicht sämtliche akademischen Rechtsfragen – vom Drittlandtransfer bis zum Löschkonzept – geklärt sind, und dass der Verantwortliche und seine Projektleitung damit einverstanden sind, hiermit zusammenhängende Randrisiken zu übernehmen oder separat zu klären, um den Projektfortschritt nicht zu gefährden.
27
Die Trennlinie zwischen Datenschutzfragen, die „In Scope“ bzw. „Out of Scope“ sind, sollten die spezifischen Risiken sein, die sich aus einer Cloud-Lösung eines US-amerikanischen Anbieters und aus der Komplexität dieser Lösung ergeben. Dies sind vor allem:
Aspekte der Nutzung „der Cloud“ bzw. von Software as a Service (SaaS);
Drittlandtransfer, insb. in die USA;
Das Vertragswerk mit Microsoft hinsichtlich des Datenschutzes (das sog. Data Protection Addendum, kurz DPA);
Die von der DSK und anderen Aufsichtsbehörden vorgebrachte Kritik an Microsoft 365.
28
Als relevant ist in jedem Fall auch die spezifische Situation des Verantwortlichen einzustufen, etwa:
Anwendbare Regulierung und Spezialnormen;
Verarbeitung von Gesundheits- und/oder Sozialdaten, Bankdaten etc.;
Zwang zur Nutzung, wie bei Schulen und Versorgern;
Jugendliche/Kinder.
29
Hierbei können auch mehrere Kategorien zusammentreffen, etwa der „Nutzungszwang“ durch die Schulpflicht mit der Gruppe der Minderjährigen.
Abbildung 1: Projektmanagement für M365-Rollout mit Abgrenzung „Out of Scope“
Description
Die Grafik beschreibt zum juristischen Projektmanagement beim M365-Rollout, welche Rechtsfragen und Daten In Scope bzw. Out of Scope sein sollen. In Scope sollten nur spezifische Fragen zu M365 sein, wie Aspekte der US-Cloud, die Vertragssituation mit Microsoft und die Kritik der Aufsichtsbehörden. Eingeschlossen ist natürlich auch die spezifische Situation des Verantwortlichen, etwa die Verarbeitung von Gesundheits- oder Sozialdaten. Out of Scope sollten Fragen sein, die z.B. auch bei der Nutzung anderer Videokonferenzsysteme auftreten, oder die Rechtsgrundlage und das Löschkonzept für E-Mails. Out of Scope ist natürlich auch die Verarbeitung in anderen Systemen als M365. Daher muss festgehalten werden, welche Daten nicht oder nicht primär in M365 gespeichert werden.
30
Von den relevanten Aspekten abzugrenzen sind vor allem Fragen, die in sehr ähnlicher Weise auch auftreten, wenn dieselbe Datenverarbeitung nicht in M365, sondern auf einem klassischen „on premise“ betriebenen System durchgeführt würde.
31
Falls sich ein Verantwortlicher bislang keine Gedanken dazu gemacht hat, ob und ggf. welche Rechtsgrundlage er für seine Verarbeitung von E-Mails oder für die Durchführung von Videokonferenzen heranziehen kann, sollte er dies durchaus nachholen. Bei vertiefter Beschäftigung mit diesen Fragen wird er feststellen, dass man sich schon lange mit der Vorfrage aufhalten kann, in welchen Fällen das Telekommunikations(datenschutz)recht anwendbar ist. Der Verantwortliche sollte bis zur abschließenden und rechtssicheren Beantwortung solcher Themen nicht sein Digitalisierungsprojekt stoppen, sondern diese Fragen separat klären. Das Gleiche gilt, wenn Lösch- und Archivierungskonzepte für E-Mail-Konten nicht existieren, oder wenn die Privatnutzung und „Bring Your Own Device“ noch nicht durch Konzernrichtlinien geregelt sind.
32
Auch der Umstand, dass das Tragen einer Brille in einer Videokonferenz ein Gesundheitsdatum i.S.d. Art. 9 Abs. 1 DSGVO darstellt, lässt sich ausführlich erörtern. Mit der Lindenapotheken-Entscheidung des EuGH (C-21/23) dürfte klar sein, dass die Definition und Zuordnung der besonderen Arten personenbezogener Daten nach Art. 9 DSGVO recht weit auszulegen ist. Am Datenschutz-Stammtisch kann man ergänzen, dass schon die an eine Videokonferenz-Teilnehmerin gerichtete und freundschaftlich gemeinte Aussage „Viele Grüße an Deinen Mann“ eine Art.-9-Information enthält: In diesem Fall die heterosexuelle Orientierung der Teilnehmerin und ihres Ehegatten; die Qualifikation als Art.-9-Datum hängt dabei nicht davon ab, ob die betreffende Information zutreffend ist.5 In der Datenschutz-Runde wäre damit fortzufahren, dass bei angeschalteter Kamera ohnehin jede gezeigte Hautfarbe die „rassische und ethnische Herkunft“ i.S.d. Art. 9 Abs. 1 DSGVO signalisiert.
33
Diese Aspekte lenken jedoch von den spezifischen Datenschutzfragen zu M365 ab und sollten daher als „Out of Scope“ für die Bewertung von M365 behandelt werden.
34
Ähnliches gilt für Daten, die in einem anderen System als „führendem System“ verarbeitet werden. Werden sie ausschließlich in anderen Systemen gehalten, sind sie offensichtlich für die M365-Bewertung irrelevant. Häufiger wird es, z.B. bei Behörden oder Krankenhäusern, aber so sein, dass ein anderes Fachsystem das führende ist, aber nicht ausgeschlossen werden kann, dass Bürger bzw. Patienten sich z.B. per E-Mail an Ansprechpartner des Verantwortlichen wenden und auf diesem Weg deren Daten in M365 hineingelangen. Auch muss stets die Möglichkeit in Betracht gezogen werden, dass ein Betroffener sich per E-Mail an die generische Datenschutz-Adresse oder einen Hinweisgeber-Ansprechpartner wendet.
35
Für diese Fallgruppen ist zumindest zu konstatieren, dass es bei Abwägungen und Bewertungen deutlich weniger kritisch ist, wenn Daten nur sporadisch in M365 verarbeitet werden, als wenn M365 für sie das führende System wäre.
36
Die Kategorisierung von bestimmten Daten als „Out of Scope“ der Verarbeitung in M365 kann auch durch die Klassifizierung von Daten in bestimmte Risiko- oder Vertraulichkeitsstufen erfolgen. Die Datenklassifizierung ist grundsätzlich ein professioneller Ansatz, der dem Stand der Technik entspricht. So ist z.B. auch in der Datenschutz-Folgenabschätzung, die die Freie und Hansestadt Hamburg 2023 für den Einsatz von Microsoft 365 durchgeführt hat, eine Datenklassifizierung in fünf Klassen vorgesehen. Ohne persönliche (private) Daten umfasst sie vier, ohne die aus Vertraulichkeitssicht belanglosen öffentlichen Daten nur noch drei Klassen. Die beiden höchsten Klassen – Vertraulich und Streng Vertraulich – dürfen nicht in M365 gespeichert werden:
Abbildung 2: Datenklassifizierung und Vorgaben in Datenschutz-Folgenabschätzung (Auszug).6 © Freie und Hansestadt Hamburg bzw. die jeweiligen Autoren/Rechteinhaber.
Description
Diese Abbildung zeigt einen Auszug aus einer Datenschutz-Folgenabschätzung der Freien und Hansestadt Hamburg zu M365. Hier wird eine Datenklassifizierung vorgenommen, wobei die Daten in Persönlich, Öffentlich, Normal, Vertraulich und Streng Vertraulich aufgeteilt werden sollen.
37