Microsoft 365 an öffentlichen Hochschulen

Wer Microsoft 365 (M365) in einer öffentlichen Hochschule oder in einer anderen öffentlichen Stelle Sachsen-Anhalts einsetzt, bewegt sich gleichzeitig in mehreren Regelungsschichten: der DSGVO als unmittelbar geltendem Unionsrecht, dem Datenschutz-Grundverordnungs- Ausfüllungsgesetz Sachsen-Anhalt (DSAG LSA), dem Hochschulgesetz Sachsen-Anhalt (HSG LSA) sowie dem Personalvertretungsgesetz Sachsen-Anhalt (PersVG LSA). Hinzu kommt – sehr praxisrelevant – das Telekommunikation- Digitale-Dienste-Datenschutz-Gesetz (TDDDG) für Cookies und vergleichbare Tracking-Mechanismen sowie Kapitel V DSGVO für jeden Datentransfer in Drittländer.

Eine grundlegende Weichenstellung ergibt sich aus dem Status der Hochschule als öffentlicher Stelle: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse) steht für die in Erfüllung ihrer Aufgaben vorgenommene Verarbeitung nicht zur Verfügung (Art. 6 Abs. 1 UAbs. 2 DSGVO). Da der M365-Einsatz an Hochschulen regelmäßig Aufgabenwahrnehmung ist – Lehre, Forschung, Verwaltung –, bleibt praktisch nur Art. 6 Abs. 1 lit. e DSGVO in Verbindung mit der jeweiligen Aufgabennorm.

Welche Norm konkret die Verarbeitungsbefugnis trägt, hängt vom jeweiligen Verfahren ab und ist verfahrensspezifisch zu führen, nicht pauschal: § 119 HSG LSA bildet die hochschulrechtliche Datenverarbeitungs-Norm und ist für hochschulspezifische Verarbeitungen einschlägig; § 3 HSG LSA beschreibt die Aufgaben der Hochschule und liefert damit den Aufgabenbezug, ist aber keine eigenständige Verarbeitungsbefugnis. Ergänzend dient § 4 DSAG LSA als Generalklausel. Für die Personalaktenführung und Eignungsuntersuchungen greift § 26 DSAG LSA („Vorschriften für die Datenverarbeitung im Beschäftigungskontext nach Art. 88 DSGVO"); für Forschungszwecke § 27 DSAG LSA. Spezialnormen aus dem jeweiligen Bereichsrecht – etwa Prüfungs-, Studierenden- oder Bewerbungsdatenrecht – verdrängen die Generalklauseln, soweit sie einschlägig sind.

Beim Einsatz von M365 sind vier Schutzziele gleichzeitig im Blick zu halten. Sie bilden zugleich die Prüfreihenfolge bei jeder Beschaffungs- oder Konfigurationsentscheidung:

Schutzziel	Konkretisierung beim M365-Einsatz
Vertraulichkeit	Verschlüsselung in transit und at rest, Customer Lockbox, Customer Key, Mandantenisolation; Schutz vor unbefugtem Zugriff Dritter (auch Microsoft selbst, Subprocessor, US-Behörden).
Integrität	Auditierbarkeit der Veränderungen, Versionierung, Schutz vor unbefugter Manipulation.
Verfügbarkeit	Service-Level, Backup-Strategie, Exit-Plan, Resilienz im Sinne von Art. 32 Abs. 1 lit. b DSGVO.
Transparenz und Nachweisbarkeit	Art. 5 Abs. 2 DSGVO. An dieser Pflicht hängt die DSK-Bewertung von 2022, und sie bleibt der Dreh- und Angelpunkt jedes Einsatzprojektes.

Bei Verstößen gegen diese Anforderungen scheiden Geldbußen gegen die Hochschule selbst aus. § 31 Abs. 2 DSAG LSA in Verbindung mit Art. 83 Abs. 7 DSGVO schließt Bußgelder gegen öffentliche Stellen des Landes Sachsen-Anhalt aus. Die übrigen Aufsichtsbefugnisse aus Art. 58 DSGVO bleiben unberührt: Anordnungen, Verwarnungen, in der Konsequenz auch eine vorläufige oder endgültige Beschränkung der Verarbeitung. Außerdem bestehen Schadensersatzansprüche Betroffener nach Art. 82 DSGVO sowie Reputationsfolgen.

Art. 5 Abs. 2, Art. 6 Abs. 1 lit. e, Art. 32, Art. 58, Art. 82, Art. 83 Abs. 7 DSGVO; Kapitel V DSGVO; § 4, § 26, § 27, § 31 Abs. 2 DSAG LSA; §§ 3, 119 HSG LSA; TDDDG (vormals TTDSG)

Die DSK hatte im Jahr 2020 eine Arbeitsgruppe unter Federführung Brandenburgs und des Bayerischen Landesamtes für Datenschutzaufsicht (BayLDA) eingesetzt, um den von Microsoft bereitgestellten Datenschutznachtrag mit Microsoft selbst zu verhandeln. Nach 14 Verhandlungsrunden legte die AG ihren Abschlussbericht vor, der die verbliebenen vertraglichen Defizite aufzählte. Auf dieser Grundlage stellte die DSK am 24. November 2022 fest, dass der Nachweis eines datenschutzrechtskonformen Betriebs auf Grundlage des Datenschutznachtrags vom 15. September 2022 nicht geführt werden kann.

Wichtig ist die exakte rechtliche Einordnung dieser Festlegung. Sie ist keine Verstoßfeststellung gegen einzelne Verantwortliche und auch keine Untersagung der Nutzung. Sie ist eine generalisierte Aussage zur Beweisbarkeit der Rechtmäßigkeit auf Grundlage der damaligen Vertragslage – ein Befund zur Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO. Genau dies betont auch der LfD Sachsen-Anhalt in seinem Anschreiben vom 16. Februar 2023, das die Festlegung an die obersten Landesbehörden und die kommunalen Spitzenverbände weitergegeben hat: die Feststellung sei „weder Produktempfehlung noch Produktwarnung".

Der DSK-Bericht arbeitet sieben konkrete Schwachstellen im Datenschutznachtrag 09/2022 heraus. Sie strukturieren bis heute jede Bewertung von Microsoft 365 und werden auch im HBDI-Bericht 2025 als Prüfungsraster fortgeführt:

Die Sieben-Punkte-Gliederung dieser Tabelle folgt der Systematik des AG-DSK-Berichts „Microsoft-Onlinedienste" (Stand 10.10.2022); die Zellinhalte sind eine eigene, gestraffte Synopse mit Quellenangaben.

Kritikpunkt	Worum es geht
1 – Festlegung von Art und Zweck	Verarbeitung sowie Art der personenbezogenen Daten im DPA nur generisch beschrieben, ohne kundenspezifische Konkretisierung.
2 – Eigene Verantwortlichkeit Microsofts	Verarbeitungen „für legitime Geschäftszwecke" (jetzt: „Geschäftstätigkeiten") mit unzureichend eingegrenzten Rechten zu wenig konkretisierten Verarbeitungen.
3 – Weisungsbindung und Offenlegung	Vorbehalte zugunsten von US-Behördenanforderungen (insbesondere CLOUD Act, FISA 702), die nicht den Anforderungen des Art. 28 Abs. 3 UAbs. 1 Satz 2 lit. a DSGVO genügen.
4 – Technische und organisatorische Maßnahmen	Garantien beziehen sich nur auf einen Teil der vertragsgegenständlichen Daten („Customer Data" in „Core Online Services").
5 – Löschung und Rückgabe	Unklarheiten und Widersprüche im Zusammenspiel von automatisierten Löschfristen und Pflichten nach Art. 28 Abs. 3 UAbs. 1 Satz 2 lit. g DSGVO.
6 – Information über Unterauftragsverarbeiter	Fehlende konkrete Vorab-Information bei jeder beabsichtigten Änderung (Art. 28 Abs. 2 DSGVO).
7 – Drittlandtransfer	Nutzung ohne Übermittlungen in die USA nach damaliger Vertragslage nicht möglich; ergänzende Schutzmaßnahmen für den Klartext-Anwendungsfall (EDSA-Empfehlungen 01/2020, Anwendungsfall 6) nach AG-Sicht nicht hinreichend.

Die DSK-Festlegung ist formal nicht zurückgenommen. Sie bezieht sich aber ausdrücklich auf den Datenschutznachtrag vom 15. September 2022. Spätere Vertragsfassungen – insbesondere der DPA-Stand 09/2025 und das DPA für öffentliche Stellen (DPA-öS) – wurden von der DSK als Gremium bislang nicht erneut bewertet. Inwieweit einzelne Kritikpunkte durch die seitdem erfolgten Vertragsänderungen, das EU-US Data Privacy Framework und die EU Data Boundary inhaltlich erledigt sind, beschreibt der HBDI-Bericht 11/2025 – siehe dazu Abschnitt 04 dieser Seite.

DSK, Festlegung der Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder vom 24.11.2022; AG-DSK-Bericht „Microsoft-Onlinedienste", Zusammenfassung Stand 10.10.2022; EDSA, Empfehlungen 01/2020 zu ergänzenden Schutzmaßnahmen, Anhang 2, Anwendungsfall 6; EuGH, Urteil v. 16.07.2020 – C-311/18 „Schrems II"

Mit Schreiben vom 16. Februar 2023 (Az. 1.4-4101/10-8.1) hat der Landesbeauftragte für den Datenschutz Sachsen-Anhalt das DSK-Infopaket zu Microsoft 365 an die obersten Landesbehörden, den Landesrechnungshof, den Städte- und Gemeindebund sowie den Landkreistag verteilt. Inhaltlich wird die DSK-Festlegung übernommen und auf das Infopaket auf der LfD-Webseite verwiesen. Eine eigenständige Untersagung oder eine bindende Handlungsanweisung enthält das Schreiben nicht.

Zwei Sätze des Schreibens haben in der Praxis besonderes Gewicht und prägen die Lage in Sachsen-Anhalt bis heute: zum einen der Hinweis, dass „die Feststellung der DSK … weder Produktempfehlung noch Produktwarnung sein" könne, zum anderen die Zusage, der LfD werde die DSGVO „unter Berücksichtigung der Interessen der Verantwortlichen in Sachsen-Anhalt und der betroffenen Personen sowie dem Gebot der Verhältnismäßigkeit" umsetzen. Beide Aussagen stehen im Original-Schreiben und sind im Volltext über das öffentliche Informationspaket der Behörde abrufbar.

Das ist ausdrücklich kein Freibrief. Es ist auch keine Behauptung, die LfD LSA folge der hessischen Position. Die LfD LSA hat sich öffentlich seit Februar 2023 nicht erneut zu Microsoft 365 positioniert; ob und in welcher Form das geschieht, ist ihr vorbehalten. Die hier umrissene Argumentationslinie ersetzt keine individuelle Rückkopplung mit der Aufsichtsbehörde, wenn der Einsatz besonders sensible Bereiche berührt (besondere Kategorien nach Art. 9 DSGVO, personalbezogene Bereiche, Forschungsdaten mit hoher Re-Identifikationswahrscheinlichkeit).

LfD Sachsen-Anhalt, Schreiben „Informationen des Landesbeauftragten für den Datenschutz zur Nutzung des Cloud-Dienstes Microsoft 365" vom 16.02.2023, Az. 1.4-4101/10-8.1; Infopaket Microsoft 365, abrufbar unter datenschutz.sachsen-anhalt.de/informationen/infopakete/infopaket-microsoft-365

Der Hessische Beauftragte für Datenschutz und Informationsfreiheit (Amtsinhaber: Prof. Dr. Alexander Roßnagel) hat am 15. November 2025 einen 137 Seiten umfassenden Bericht zum Einsatz von Microsoft 365 vorgelegt (Stand: November 2025, Vers. 1.0). Drei Jahre lang hatte der HBDI mit Microsoft verhandelt und das Ergebnis in einem strukturierten Bericht mit Sachverhaltsdarstellung, rechtlichen Erwägungen und Handlungsempfehlungen für Verantwortliche zusammengefasst.

Der zentrale Befund steht auf Seite 14: Bezogen auf die sieben Kritikpunkte der DSK von 2022 ist nach Ansicht des HBDI ein datenschutzkonformer Betrieb möglich. Diese Bewertung beruht ausdrücklich auf einer Doppelvoraussetzung – einerseits den von Microsoft eingeräumten Vertragsänderungen und Klarstellungen (insbesondere im DPA-öS für öffentliche Stellen), andererseits der Erfüllung eines konkreten Pflichtenkatalogs durch die Verantwortlichen selbst. Microsoft kann den Nachweis nicht allein erbringen; die Konformität entsteht erst im Zusammenwirken beider Seiten.

Der HBDI-Bericht stützt seinen Befund auf vier Dokumente, die den DPA inhaltlich konkretisieren oder erläutern. Sie sind gemeinsam zu lesen, sonst fehlt der Bewertung die Tiefe:

Baustein	Funktion und Fundstelle
DPA-öS	Das DPA für öffentliche Stellen; enthält für hessische öffentliche Stellen eine kundenspezifische Anpassung von Anhang B (Beschreibung der betroffenen Personen und Datenkategorien) sowie eine angepasste Klausel zu „Geschäftstätigkeiten".
Interpretationshilfe	Von Microsoft erstellte Zuordnung der DPA-Ausführungen zu den Anforderungen aus Art. 28 Abs. 3 DSGVO (Anlage 1 des Berichts).
M365-Kit	Von Microsoft in Abstimmung mit dem BayLDA und unter Einbindung des HBDI erstelltes Werkzeug; es enthält Beispieleinträge für das Verzeichnis von Verarbeitungstätigkeiten, beispielhafte Schwellwertanalysen, beispielhafte Ausführungen zu Rechtsgrundlagen und eine beispielhafte Datenschutzerklärung. Im Microsoft Service Trust Portal abrufbar; Anlage 2 des HBDI-Berichts enthält den Verweis und die Abruf-Hinweise.
Taxonomie	Vom HBDI selbst entwickelte Übersetzung der Microsoft-eigenen Datenkategorien in eine systematisierte Begriffslandschaft (Anlage 3 des Berichts). Vertieft auf dieser Seite in Abschnitt 06.

Drei externe Entwicklungen tragen den HBDI-Befund zusätzlich. Erstens hat die Europäische Kommission am 10. Juli 2023 mit dem EU-US Data Privacy Framework einen neuen Angemessenheitsbeschluss gefasst (Durchführungsbeschluss (EU) 2023/1795); soweit die Empfänger in den USA dem DPF beigetreten und im DPF-Register gelistet sind, ist der Drittlandtransfer angemessenheitsgestützt zulässig. Der Beschluss ist allerdings angefochten – Klage des EU-Parlaments- Mitglieds Latombe vor dem EuG (T-553/23) – und seine Stabilität ist nicht garantiert; eine fortlaufende Beobachtung der Rechtslage bleibt geboten. Zweitens hat Microsoft die EU Data Boundary fortentwickelt: für „HR and Non-HR Data" findet die Verarbeitung weit überwiegend im EWR statt. Drittens hat der EuGH am 9. Januar 2025 in der Sache C-394/23 (Mousse / SNCF Connect) entschieden; Streitgegenstand war zwar die Pflichtfeld-Anrede beim Online-Bahnticket, das Urteil rezitiert aber zugleich die Drei-Schritt-Prüfung des berechtigten Interesses (Art. 6 Abs. 1 lit. f DSGVO, Rn. 44 ff.) sowie die Informationspflicht aus Art. 13 Abs. 1 lit. d DSGVO. Der HBDI greift diese Passagen für die Bewertung auf, wann Microsoft Logdaten anonymisiert aggregieren darf.

Eine Einschränkung des Berichts ist transparent ausgewiesen: Microsoft hat am 9. Juni 2025 in einer Anhörung vor der Commission d'enquête sur la commande publique des französischen Senats (vertreten durch Anton Carniaux, Direktor für öffentliche und rechtliche Angelegenheiten, und Pierre Lagarde, Technischer Direktor für den öffentlichen Sektor, beide Microsoft France) eingeräumt, dass eine Offenlegung auf Anordnung der US-Regierung ohne ausdrückliche Zustimmung des Verantwortlichen für die Zukunft nicht vollständig ausgeschlossen werden könne, obgleich dies in der Vergangenheit noch nie vorgekommen sei. Der HBDI empfiehlt Verantwortlichen daher eine eigene Risikobewertung der Datenkategorien und ein regelmäßiges Sichten des Microsoft Government Requests Reports.

HBDI, Bericht zum Einsatz von Microsoft 365, Stand: 15.11.2025, Vers. 1.0; HBDI, Pressemitteilung „Microsoft 365 kann datenschutzkonform genutzt werden" vom 15.11.2025; EU-US Data Privacy Framework, Durchführungsbeschluss (EU) 2023/1795 der Kommission vom 10.07.2023; EuGH, Urteil v. 09.01.2025 – C-394/23 (Mousse / SNCF Connect); EuGH, Urteil v. 04.10.2024 – C-621/22 (KNLTB) zur Drei-Schritt-Prüfung des berechtigten Interesses

Der folgende Überblick stellt jeden DSK-Kritikpunkt von 2022 dem HBDI-Befund von 2025 gegenüber. Wichtig: Die Tabelle ist eine kompakte Darstellung – die jeweiligen Pflichten der Verantwortlichen sind in Abschnitt 07 ausführlicher dargestellt, weil ohne ihre Erfüllung der HBDI-Befund nicht trägt.

Die Tabellen-Strukturierung folgt dem Sieben-Punkte-Raster des AG-DSK-Berichts (Stand 10.10.2022) und der Antwort-Systematik des HBDI-Berichts (Stand 15.11.2025, S. 14–16); die Zellinhalte sind eine eigene Synopse der dort dargestellten Befunde.

DSK-Kritikpunkt 2022	HBDI-Antwort 11/2025
1 – Festlegung von Art und Zweck der Verarbeitung, Art der personenbezogenen Daten	Microsoft hat Interpretationshilfe und M365-Kit bereitgestellt; Verantwortliche können daraus ein hinreichend konkretes Bild ihrer Verarbeitung ableiten und ins VVT übernehmen. Im DPA-öS wird Anhang B kundenspezifisch angepasst.
2 – Eigene Verantwortlichkeit Microsofts für „Geschäftstätigkeiten"	Nach Microsoft-Zusicherung erfolgt die Verarbeitung für eigene Geschäftstätigkeiten ausschließlich aus aggregierten, pseudonymisierten Diagnose- und Logdaten (keine Inhaltsdaten); die Aggregationspraxis sei an den Leitlinien der Art.-29-Datenschutzgruppe (WP 216, Opinion 05/2014) ausgerichtet. Der HBDI bewertet die Anonymisierung durch Aggregation insoweit als hinreichend belegt – diese Einschätzung ist Aufsichtspraxis Hessens und bindet andere Aufsichtsbehörden nicht.
3 – Weisungsbindung und Offenlegung	Microsoft verpflichtet sich, personenbezogene Daten nur auf dokumentierte Weisung zu verarbeiten und sich hinsichtlich Offenlegungen der DSGVO zu unterwerfen. Im DPA-öS wurde die Streichung der „Verwendung von Features" als Weisungsdokumentation vereinbart.
4 – Technische und organisatorische Maßnahmen	Microsoft hat zugesagt, die Anforderungen des Art. 32 DSGVO ohne Abstriche einzuhalten; „branchenübliche Systeme" wird nicht als Absenkung des „Stands der Technik" verstanden.
5 – Löschung und Rückgabe	Microsoft bietet einen Löschprozess an und ermöglicht Kunden, Daten selbst zu löschen oder löschen zu lassen, wenn schnellere Löschung erforderlich ist. Verantwortliche müssen ergänzend ein Löschkonzept vorhalten.
6 – Information über Unterauftragsverarbeiter	Microsoft informiert sechs Monate (Customer Data) bzw. 30 Tage (sonstige personenbezogene Daten) im Voraus über jeden Unterauftragsverarbeiter; Liste im Service Trust Portal abrufbar.
7 – Drittlandtransfer	EU-US Data Privacy Framework (Angemessenheitsbeschluss 07/2023); Microsoft DPF-zertifiziert. EU Data Boundary für „HR and Non-HR Data" weit überwiegend im EWR; Standardvertragsklauseln (Modul 3) für verbleibende Übermittlungen.

Der HBDI macht ausdrücklich deutlich: Diese Antworten tragen nur, wenn die Verantwortlichen ihre eigenen Pflichten parallel erfüllen. Das DPA-öS allein heilt nichts. Wer es abschließt, aber Diagnose-Daten nicht konfiguriert, kein Löschkonzept hat oder Audit-Logs ohne Mitbestimmung scharfschaltet, hat den HBDI-Pfad verlassen.

HBDI, Bericht 15.11.2025, S. 14–16 (Zusammenfassung) und S. 76–94 (Handlungsempfehlungen); Microsoft Products and Services Data Protection Addendum (DPA), Stand 09/2025; DPA-öS für öffentliche Stellen; Microsoft Service Trust Portal

Wer Microsoft 365 datenschutzrechtlich bewerten will, kommt um die Microsoft-eigenen Datenkategorien nicht herum. Sie wirken auf den ersten Blick technisch, sind aber rechtlich entscheidend, weil sich Pflichten, Rechtsgrundlagen und Speicherorte je nach Kategorie unterscheiden. Der HBDI hat die Begriffslandschaft in einer Taxonomie systematisiert; vereinfacht zusammengefasst sind vier Hauptkategorien zu unterscheiden.

Kategorie	Was Microsoft sieht	Datenschutzrechtliche Folge
Inhaltsdaten (Content / Customer Data)	Microsoft verhält sich grundsätzlich inhaltsagnostisch – keine Kenntnisnahme der konkreten Inhalte. Verarbeitung erfolgt im Rahmen der Auftragsverarbeitung.	Verantwortlicher bestimmt Einsatzzweck, betroffene Personen und Inhalte; Microsoft als Auftragsverarbeiter nach Art. 28 DSGVO. Bei Customer Lockbox und Professional Services kann ausnahmsweise Zugriff freigegeben werden.
Diagnose-Daten (Service Generated Data)	Telemetriedaten zur Bereitstellung der Dienste; werden systemimmanent erzeugt und an Microsoft übermittelt.	Verantwortlicher konfiguriert Erhebung; nur das tatsächlich Erforderliche, in pseudonymisierter Form. Ist Bestandteil der Auftragsverarbeitung.
Audit-Log-Daten	Protokolldaten über Nutzeraktivitäten – wer hat wann auf was zugegriffen.	Bei nicht pseudonymisierter Form unterscheidet sich die Verarbeitung deutlich von Diagnose-Daten. Mitbestimmung nach § 69 Nr. 2 PersVG LSA ist hier oft einschlägig – ausgeführt in Abschnitt 08 dieser Seite.
„Von MS generierte, abgeleitete oder gesammelte Daten" – aggregiert für Geschäftstätigkeiten Microsofts	Microsoft aggregiert pseudonymisierte Diagnose- und Logdaten (keine Inhaltsdaten) zu eigenen Zwecken: Sicherheit, Produktverbesserung, Abrechnung.	Nach HBDI-Bewertung entspricht die Aggregationspraxis den Leitlinien der Art.-29-Datenschutzgruppe (WP 216); das Ergebnis liege nicht mehr im Anwendungsbereich der DSGVO oder sei datenschutzrechtlich vertretbar. Diese Einschätzung ist hessische Aufsichtspraxis und bindet andere Aufsichtsbehörden nicht. Verantwortliche sollten Konfiguration prüfen und Aggregationsverfahren auditieren.

HBDI, Bericht 15.11.2025, S. 11–13 und Anlage 3 (Taxonomie); Microsoft Products and Services DPA, Stand 09/2025; Art.-29-Datenschutzgruppe, Opinion 05/2014 on Anonymisation Techniques (WP 216)

Der HBDI führt acht Pflichtenblöcke auf, die ein Verantwortlicher zu erfüllen hat, damit der datenschutzkonforme Betrieb tatsächlich erreicht wird. Sie sind das praktische Rückgrat der Bewertung. Im Folgenden sind sie als Decision-Boxen mit den jeweils wichtigsten Pflichten dargestellt – kompakt, aber inhaltsvollständig.

07.1 Auswahl, Bedarfsermittlung und DPA-öS

07.2 Festlegung von Art und Zweck der Verarbeitung

Wer die Datenkategorien-Logik tiefer einsteigen will, findet sie auf dieser Seite in Abschnitt 06 – Datenarten in Microsoft 365 ausgeführt: Inhalts-, Diagnose-, Audit-Log-Daten und die für Microsofts Geschäftstätigkeiten aggregierten Datensätze sind dort jeweils in eigenen Tabellenzeilen erläutert.

07.3 Eigene „Geschäftstätigkeiten" Microsofts

07.4 Weisungsbindung und Government Requests

07.5 Technische und organisatorische Maßnahmen

Eine ausführliche methodische Auseinandersetzung mit den technisch-organisatorischen Maßnahmen nach Art. 32 DSGVO – einschließlich der TOMs-Checkliste des BayLDA und der parallelen Anbindung an die BSI-IT-Grundschutz- Bausteine – findet sich auf der eigenständigen Themenseite Technisch-organisatorische Maßnahmen (TOMs).

07.6 Löschung und Rückgabe

Den methodischen Aufbau eines Löschkonzepts nach DIN EN ISO/IEC 27555 – mit Datenarten- katalog, Löschregeln und drei typischen Startzeitpunkten – beschreibt die Themenseite Datenvernichtung, Abschnitt 03 (Löschkonzept). Sie ergänzt die obigen M365-spezifischen Pflichten um den allgemeinen organisatorischen Rahmen.

07.7 Unterauftragsverarbeiter

07.8 Drittlandtransfer

Die methodische Grundlage – Schrems-II-Drei-Stufen-Modell, Transfer Impact Assessment (TIA), EDSA-Empfehlungen 01/2020 mit Anwendungsfall 6 (Klartextzugriff durch Cloud-Anbieter) – ist auf der Themenseite Drittlandtransfer ausführlich dargestellt. Sie ergänzt die obigen M365-spezifischen Pflichten um den allgemeinen Prüfrahmen für jede Übermittlung in Drittländer.

07.9 Weitere Empfehlungen (HBDI, S. 93–94)

Wer wann frühzeitig einzubinden ist, ist auf dieser Seite in Abschnitt 10 – Stakeholder, ISMS-Schnittstelle und Beschaffung aufgeschlüsselt; die DSFA-Vorprüfung und ihre praxisnahen Auslöser stehen in Abschnitt 09 – DSFA-Pflicht und Eintrag in das VVT.

HBDI, Bericht 15.11.2025, S. 76–94 (Handlungsempfehlungen für Verantwortliche); Art. 5, 13, 17, 25, 28, 30, 32, 35, 49 DSGVO; § 9 ArchivG LSA i. V. m. § 12 Abs. 2 DSAG LSA; DIN EN ISO/IEC 27555:2025-09 (Nachfolger DIN 66398); BSI IT-Grundschutz APP.5.3, OPS.2.2, OPS.1.1.5; Microsoft Service Trust Portal; Microsoft Government Requests Report

In öffentlichen Stellen Sachsen-Anhalts ist die Einführung oder wesentliche Änderung von Microsoft 365 fast immer mitbestimmungspflichtig. Zwei Tatbestände aus § 69 PersVG LSA greifen typischerweise parallel – sie müssen beide geprüft und beide bedient werden.

§ 69 Nr. 1 PersVG LSA – automatisierte Verarbeitung von Beschäftigtendaten

Wortlaut: „Einführung, Anwendung, wesentliche Änderung oder wesentliche Erweiterung von automatisierten Verfahren zur Verarbeitung personenbezogener Daten der Angehörigen der Dienststelle außerhalb von Besoldungs-, Vergütungs-, Lohn- und Versorgungsleistungen."

M365 verarbeitet personenbezogene Daten der Beschäftigten – Anmeldedaten, E-Mail-Inhalte, Kalendereinträge, Kollaborationsdokumente. Damit ist Nr. 1 regelmäßig einschlägig, sobald M365 eingeführt oder wesentlich erweitert wird. Praxisrelevant ist „wesentlich": Nicht jedes Update löst Mitbestimmung aus, aber die Einführung neuer Module (z. B. Copilot, Loop, Stream, Defender for Endpoint) regelmäßig schon. Die im Norm-Wortlaut erwähnten Besoldungs-, Vergütungs-, Lohn- und Versorgungsleistungen sind hier ohne Bedeutung, weil M365 nicht für die Bezügeabwicklung eingesetzt wird; sie sind im Wortlaut nur deshalb genannt, weil dafür eine eigene Mitbestimmungs-Architektur (insbesondere über Tarifverträge) besteht.

§ 69 Nr. 2 PersVG LSA – technische Einrichtungen mit Überwachungseignung

Wortlaut: „Einführung, Anwendung, wesentliche Änderung oder wesentliche Erweiterung von technischen Einrichtungen, die geeignet sind, das Verhalten oder die Leistung der Angehörigen der Dienststelle zu überwachen."

Entscheidend ist die Eignung, nicht der Zweck. Die Mitbestimmung greift schon dann, wenn die technische Einrichtung objektiv geeignet ist, Verhalten oder Leistung zu überwachen – auch wenn der Verantwortliche das gar nicht beabsichtigt. In der M365-Praxis sind insbesondere folgende Komponenten betroffen:

M365-Komponente	Worum es geht
Audit Logs in Microsoft Purview	Nutzerbezogene Aktivitätsprotokolle, die nicht pseudonymisiert ausgewertet werden können.
Microsoft Defender (Endpoint, Identity, Cloud Apps)	Sicherheitsfunktionen, die Verhaltensanalysen auf Endgeräten durchführen.
Insights und Workplace Analytics / Viva Insights	Auswertung von Kommunikations- und Kollaborationsmustern.
Microsoft Teams Call Quality Dashboard und Telemetrie	Pro Nutzer auswertbare Verbindungsqualitäts- und Aktivitätsdaten.
Anwesenheitsstatus und Präsenzanzeige	Kombination mit Kalendern erlaubt Rückschlüsse auf Arbeitszeiten und -muster.

Die saubere Lösung ist regelmäßig eine Dienstvereinbarung nach § 70 PersVG LSA, die die einzelnen M365-Komponenten differenziert: welche Module aktiviert sind, welche Daten in welcher Granularität ausgewertet werden dürfen, durch wen und nach welchen Verfahren, mit welcher Aufbewahrungsdauer und welchen Auskunftsrechten der Beschäftigten. Eine pauschale Vereinbarung „M365 wird genutzt" trägt diese Last in der Regel nicht.

§ 69 Nr. 1, Nr. 2 und § 70 PersVG LSA; vergleiche zur Mitbestimmungsdogmatik BVerwG, Beschluss v. 23.06.2010 – 6 P 8.09; Themenseite Videoüberwachung (Mitbestimmungsstruktur)

M365 ist als technisches Hilfsmittel keine eigene Verarbeitungstätigkeit im Sinne von Art. 30 DSGVO, sondern wird in zahlreichen Verarbeitungstätigkeiten eingesetzt. Das VVT folgt deshalb dem Aufgabenpfad: Pro Verarbeitungstätigkeit (z. B. Personalakte, Lehrveranstaltungsorganisation, Forschungsdatenverwaltung, Bewerbungsverfahren) wird der M365-Einsatz als technisches Hilfsmittel mit Verweis auf eine Produktbeschreibung referenziert. So bleibt die Aufgabe rechtlich greifbar, ohne dass die M365-Komplexität das VVT überlagert.

Inhaltlich besteht ein robuster DSFA-Aufbau aus den vier Standardabschnitten nach Art. 35 Abs. 7 DSGVO – systematische Beschreibung, Notwendigkeits- und Verhältnismäßigkeitsbewertung, Risikobewertung und Maßnahmen. Bei M365 sind die folgenden Inhalte in jeder DSFA praxisrelevant: Datenkategorien nach HBDI-Taxonomie, Konfiguration der Diagnose-Daten, Drittland-Routen pro Datenkategorie, Customer-Lockbox- und Customer-Key-Optionen, Audit-Log-Strategie, Löschkonzept-Anbindung, Abgleich mit dem BSI-IT-Grundschutz-Schutzbedarf des betroffenen Verfahrens. Methodisch bietet sich das Standard-Datenschutzmodell (SDM v3.1a) als Strukturraster an.

Wichtig: Eine pauschale DSFA, die nur „M365 als Ganzes" betrachtet, genügt der Anforderung des Art. 35 Abs. 7 DSGVO nicht. Die DSFA ist verarbeitungs- und kontextbezogen zu führen. Eine M365-Plattform-DSFA kann allerdings als „Mutter-DSFA" für alle nachgelagerten, verfahrensbezogenen DSFAs dienen, sodass nicht jede verfahrensbezogene DSFA die Plattform-Bewertung wiederholen muss.

Art. 30, Art. 35 DSGVO; Art.-29-Datenschutzgruppe, WP 248 rev. 01 (Leitlinien zur DSFA); SDM v3.1a der DSK; LfD Sachsen-Anhalt, Liste der Verarbeitungstätigkeiten, für die eine DSFA durchzuführen ist (Muss-Liste); Themenseite DSFA

M365 ist kein reines Datenschutz-Projekt. Es ist gleichzeitig ein IT-Sicherheits-, Beschaffungs- und Personalvertretungs-Projekt. Wer die Stakeholder zu spät einbindet, baut Friktionen ein, die später unter Zeitdruck kaum mehr aufzulösen sind. Der HBDI hat dieses Thema in seinen „Weiteren Empfehlungen" eigens herausgehoben.

Wer wann an den Tisch gehört, entscheidet darüber, ob die späteren Hürden vermeidbar bleiben. Die folgende Übersicht skizziert die Rollen und ihre Beiträge:

Rolle	Beitrag und Zeitpunkt
Datenschutzbeauftragte:r	Frühestmöglich (Art. 38 Abs. 1 DSGVO). Spätestens bei Bedarfsermittlung und Ausschreibung.
Informationssicherheits­beauftragte:r (ISB)	Schutzbedarfsfeststellung nach BSI 200-2, Bewertung der M365-spezifischen Risiken (Identity, Mandantenisolation, Defender-Konfiguration, Compliance Manager).
Personalrat	Im Bedarfs- und Konzeptstadium informell, formal über das Mitbestimmungsverfahren nach § 69 Nr. 1 und Nr. 2 PersVG LSA spätestens vor Inbetriebnahme.
Rechtsstelle	Vertragsprüfung DPA-öS und etwaige produktspezifische Erweiterungen, Anbindung an Beschaffungs- und Vergaberecht.
Archivverantwortliche	Anbindung an die Anbietungspflicht ans Landesarchiv (§ 9 ArchivG LSA), insbesondere bei der Konfiguration von Retention-Strategien.
Beschaffungsstelle	Lizenzmodell, Tenant-Strategie, EU-Bindung, Exit-Klauseln im Hauptvertrag.

Auf Ebene der Informationssicherheit sind insbesondere die folgenden BSI-Bausteine (IT-Grundschutz-Kompendium Edition 2023) in jeder M365-Bewertung heranzuziehen: APP.5.2 (Microsoft Exchange und Outlook), APP.5.3 (Allgemeiner E-Mail-Client und -Server), APP.5.4 (Unified Communications und Collaboration), OPS.2.2 (Cloud-Nutzung), OPS.1.1.5 (Protokollierung), CON.3 (Datensicherungskonzept), CON.6 (Löschen und Vernichten) sowie ORP.4 (Identitäts- und Berechtigungsmanagement). Einen eigenständigen Microsoft-365-Plattformbaustein enthält das Kompendium derzeit nicht; die Plattform ist über die Kombination aus E-Mail-, UCC-, Cloud- und Identity-Bausteinen abzudecken. Eine doppelt geführte Bewertung – datenschutzrechtlich nach Art. 32 DSGVO und sicherheitstechnisch nach BSI-Grundschutz – vermeidet Lücken und Doppelarbeit.

Art. 32, Art. 35, Art. 38 DSGVO; § 69, § 70 PersVG LSA; § 9 ArchivG LSA; BSI IT-Grundschutz-Kompendium Edition 2023 (APP.5.2, APP.5.3, APP.5.4, OPS.2.2, OPS.1.1.5, CON.3, CON.6, ORP.4); Themenseite TOMs

Der HBDI rückt die digitale Souveränität in seinem Bericht ausdrücklich in den Vordergrund. Hintergrund sind zwei Dinge: zum einen die Fähigkeit zur Betriebskontinuität bei rechtlichen oder tatsächlichen Ausfallszenarien, zum anderen die Reduktion politischer Einwirkungsmöglichkeiten von Drittstaatenakteuren. Für öffentliche Stellen ist das mehr als ein Wirtschaftlichkeits- oder Symbolthema – es ist Bestandteil der pflichtgemäßen Risikoabwägung.

Souveränität lässt sich auf drei Ebenen bewerten, die unabhängig voneinander tragen müssen:

Ebene	Was sie konkret bedeutet
Vertragliche Souveränität	Anhang D des DPA-öS sieht vor, dass Microsoft sich gegenüber geschützten Behördenkunden verpflichtet, gegen Anforderungen oder verbindliche rechtliche Verpflichtungen zur Aussetzung von Onlinediensten anzufechten. Ob und wie das in einem realen Konfliktfall trägt, ist offen.
Technische Souveränität	Customer Key (Encryption with Customer-Managed Keys), Hold Your Own Key, on-prem-Hybridlösungen, Bring-Your-Own-Identity-Provider. Sie verlagern Schlüssel- und Identity-Hoheit auf den Verantwortlichen, lösen aber den Zugriffsprimat von Microsoft nicht vollständig auf.
Strategische Souveränität	Parallelevaluation alternativer Plattformen, dokumentierter Exit-Plan, Single-Vendor-Lock-in vermeiden. Einsatz von offenen Formaten (ODF, OOXML mit Standardelementen) erhält die Migrationsfähigkeit.

Konkrete Alternativen, die in der öffentlichen Verwaltung und im Hochschulbereich in den letzten Jahren erprobt wurden, sind unter anderem:

• Sovereign Cloud / Delos Cloud – ein Microsoft-Cloud-Angebot in der Verantwortung der SAP, das speziell für deutsche Behörden konzipiert ist; Stand und Verfügbarkeit sind regelmäßig zu prüfen, weil das Projekt sich über die letzten Jahre mehrfach umstrukturiert hat.
• Open-Source-basierte Office- und Kollaborationsstacks – Nextcloud Hub, Collabora Online, OnlyOffice, Element/Matrix für Echtzeit-Kommunikation, BigBlueButton für Videokonferenzen.
• Sovereign Workplace – die vom BMI getragene Initiative und mehrere Landesinitiativen erproben modulare Open-Source-Arbeitsplätze.
• Educational-Suites – DFNconf, Hochschulrechenzentren mit eigener Mailinfrastruktur (z. B. zentrale Exchange-on-prem-Cluster) und gemeinsame Cloud-Initiativen wie GWDG.

Der HBDI verlangt keinen Wechsel weg von M365 – er verlangt aber eine bewusste Auseinandersetzung mit Alternativen, ihre Dokumentation und das praktische Ausprobieren in einem überschaubaren Pilotrahmen. Ziel ist die digitale Handlungsfähigkeit im Krisenfall.

HBDI, Bericht 15.11.2025, S. 93 (Weitere Empfehlungen); BMI, Sovereign Workplace; Delos Cloud; Bundesnetzagentur, Marktbeobachtung Cloud-Dienste; Themenseite Drittlandtransfer

• Bewertung auf Stand DSK 2022 stehen geblieben: Wer den DSK-Stand 2022 als alleinigen Maßstab nimmt, berücksichtigt nicht, dass sich seitdem die DPA-Fassung, das EU-US Data Privacy Framework, die EU Data Boundary und die Aufsichtspraxis (HBDI 2025) verändert haben. Die Bewertung gehört regelmäßig fortgeschrieben.
• Standard-DPA statt DPA-öS: Öffentliche Stellen nutzen häufig das allgemeine DPA, obwohl Microsoft für hessische öffentliche Stellen ein eigenes DPA-öS bereithält. Auch außerhalb Hessens lohnt die Nachfrage, ob das DPA-öS angeboten oder gleichwertige Anpassungen vereinbart werden können.
• Diagnose-Daten in der Default-Konfiguration: Die Standardeinstellungen vieler M365-Mandanten aktivieren weitgehende Telemetrie. Datenschutz durch Voreinstellung nach Art. 25 Abs. 2 DSGVO verlangt eine bewusste Reduktion auf das tatsächlich Erforderliche, mit Konfigurationsdokumentation.
• Connected Experiences nicht deaktiviert: Office-Apps senden bei aktivierten „Verbundenen Erfahrungen" Inhalts- und Nutzungsdaten an Microsoft und Drittanbieter. In Behördenkonfigurationen ist die Deaktivierung in der Regel angezeigt; sie erfordert Group-Policy-Einstellungen oder Intune-Profile.
• Audit-Logs ohne Mitbestimmungsklärung: Audit Logs in Microsoft Purview sind technische Einrichtungen mit Überwachungseignung im Sinne von § 69 Nr. 2 PersVG LSA. Wer sie scharf schaltet, ohne Mitbestimmung und ohne klares Auswerteregime, baut sich ein Compliance-Problem ins eigene Haus.
• Copilot-Roll-out ohne DSFA: Microsoft 365 Copilot greift auf eine breite Datenbasis im Tenant zu (E-Mails, Kalender, Dateien, Chat-Verläufe). Die Verarbeitung berührt regelmäßig Beschäftigtendaten und bedarf einer eigenständigen DSFA, einer Mitbestimmung und einer Berechtigungsprüfung; die Plattform-DSFA für M365 reicht hier in aller Regel nicht.
• Schatten-IT durch Add-Ins und private Konten: Office-Add-Ins aus dem Microsoft-Marketplace und private Microsoft-Konten als Single-Sign-On erzeugen Datenflüsse außerhalb der vereinbarten Auftragsverarbeitung. Ein zentrales Genehmigungs- und Sperrverfahren ist Pflicht.
• Löschkonzept fehlt oder ist generisch: Ein Löschkonzept, das nur „Daten werden gelöscht, wenn sie nicht mehr erforderlich sind" sagt, genügt Art. 5 Abs. 1 lit. e DSGVO nicht. Datenarten, Löschregeln und Startzeitpunkte gehören ausgeschrieben – ausführlich auf der Themenseite Datenvernichtung, Abschnitt 03 (Löschkonzept).
• VVT-Eintrag „M365" als Verarbeitungstätigkeit: M365 ist ein technisches Hilfsmittel, keine Verarbeitungstätigkeit. Der VVT-Eintrag gehört zur Aufgabe (z. B. „Lehrveranstaltungsorganisation"), nicht zur Plattform.
• Government Requests Report ungelesen: Microsoft veröffentlicht halbjährlich einen Bericht zu Behördenanfragen. Wer ihn nicht regelmäßig sichtet, verzichtet auf einen leicht zugänglichen Frühindikator für mögliche Risiken.
• Single-Vendor-Lock-in ohne Exit-Plan: Wer keinen dokumentierten und periodisch verprobten Exit-Plan hat, hat im Krisenfall keine Handlungsoptionen. Format-Migration, Identity-Migration und Schulungskonzept gehören in den Plan.

Diese Seite versucht keine Empfehlung pro oder contra Microsoft 365. Wer eine Bewertung treffen will, ist auf die Einzelfallprüfung verwiesen – und darauf, dass ihre Verantwortung beim jeweiligen Verantwortlichen liegt, nicht beim Datenschutzmanagement. Drei Eindrücke aus meiner Arbeit halte ich aber für mitteilenswert.

Erstens: Die DSK-Festlegung von 2022 ist seit dem HBDI-Bericht vom 15. November 2025 nicht aufgehoben, aber inhaltlich überholt. Wer heute eine Bewertung führt und beim DSK-Stand 2022 stehen bleibt, ignoriert drei Jahre Vertragsfortentwicklung, das EU-US Data Privacy Framework und die EU Data Boundary. Eine zeitgemäße Bewertung muss diese Entwicklungen einbeziehen – anders ist die Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO nicht zu erfüllen.

Zweitens: Mit DPA-öS, sorgfältiger Konfiguration der Diagnose-Daten, dokumentierter DSFA, Mitbestimmung des Personalrats und einem belastbaren Löschkonzept lässt sich der Pflichtenkatalog erfüllen. Wer M365 betreibt, hat ein anspruchsvolles, aber nicht aussichtsloses Compliance-Programm vor sich. Dass das Restrisiko einer US-Behördenanfrage nach eigener Aussage Microsofts nicht vollständig auszuschließen ist, ändert an der Erfüllbarkeit der vertraglichen Anforderungen nichts; es ist Bestandteil der Risikobewertung.

Drittens: Es gibt Bereiche, in denen ich auch nach dem HBDI-Bericht zur Zurückhaltung raten würde – besondere Kategorien nach Art. 9 DSGVO, Forschungsdaten mit hoher Re-Identifikationswahrscheinlichkeit, sensible Personalvorgänge und einzelne hochschulspezifische Konstellationen wie Zeugnis- und Promotionsdaten. Hier sollte die Bewertung verfahrensspezifisch geführt werden, und die Tendenz darf durchaus zu on-prem-Verarbeitung, Customer Key oder Hybridmodellen gehen. Eine Plattform-Bewertung ersetzt diese verfahrensbezogene Abwägung nicht.

Eine pauschale „Ja"- oder „Nein"-Empfehlung wäre meiner Rolle als Datenschutzmanager nicht angemessen – und sie wäre der Sache auch nicht angemessen, weil M365 in seinen 300+ Verarbeitungsleistungen kein einheitliches Produkt ist, sondern eine Plattform mit sehr unterschiedlichen Risiken pro Modul. Die Verantwortung trägt der jeweilige Verantwortliche; meine Aufgabe ist, die Prüfung methodisch zu unterstützen und die Argumente sichtbar zu machen, an denen sie sich entlanghangeln kann.

Persönliche fachliche Auffassung des Verfassers; vergleiche die Disclaimer am Seitenanfang.