M365 und der Datenschutz

Der eigentliche Kern: sechs Punkte, die jeden Auftragsverarbeiter betreffen

Spannend ist der Bericht aus Hessen weniger wegen Microsoft – sondern wegen der Maßstäbe, die er für jede Auftragsverarbeitung setzt. Die folgenden sechs Anforderungen markieren das, was Aufsichtsbehörden heute von Auftragsverarbeitern erwarten:

• Vollständige Informationen zur Datenverarbeitung. Der Verantwortliche muss in die Lage versetzt werden, sein Verarbeitungsverzeichnis ohne Lücken zu führen. Allgemeine Aussagen reichen nicht.
• Saubere Trennung zwischen Diagnose- und Inhaltsdaten. Log- und Diagnosedaten dürfen für eigene Zwecke des Auftragsverarbeiters nur in anonymisierter und aggregierter Form genutzt werden. Inhaltsdaten sind tabu.
• Verarbeitung ausschließlich auf dokumentierte Weisung. Wer als Auftragsverarbeiter Daten verarbeitet, tut dies nicht aus eigener Initiative – und unterwirft sich auch bei behördlichen Offenlegungsverlangen den Vorgaben der DSGVO.
• Funktionierender Löschprozess. Kunden müssen Daten selbst löschen können oder eine Löschung verbindlich anstoßen können, wenn die Standardlöschfristen nicht ausreichen.
• Transparenz über Unterauftragnehmer. Jeder Subauftragnehmer muss benannt und beschrieben sein. Pauschale Listen ohne Kontext genügen nicht.
• Belastbare Rechtsgrundlage für Drittlandtransfers. Übermittlungen in die USA oder andere Drittstaaten brauchen eine klare Grundlage – Angemessenheitsbeschluss, Standardvertragsklauseln oder eine andere gesetzliche Erlaubnis.

Was das für Sie als Verantwortlichen bedeutet

Der Bericht aus Hessen ist keine generelle Freigabe von Microsoft 365. Er beschreibt einen Rahmen, in dem ein datenschutzkonformer Einsatz möglich ist. Die Verantwortung – und damit auch die Nachweispflicht aus Art. 5 Abs. 2 DSGVO – bleibt beim Unternehmen.

Konkret heißt das: Wer M365 einsetzt, muss weiterhin selbst dokumentieren, prüfen und steuern. Fünf Bausteine entscheiden darüber, ob Sie im Beanstandungsfall vor der Aufsicht bestehen.

1. Das Verarbeitungsverzeichnis: M365 ist nicht ein Eintrag, sondern viele

Ein Fehler, der uns in Mandaten immer wieder begegnet: Microsoft 365 steht als ein Eintrag im Verarbeitungsverzeichnis. Das genügt nicht. Art. 30 DSGVO verlangt eine differenzierte Darstellung nach Zwecken, Datenkategorien, Empfängern und Speicherfristen – und M365 vereint Dienste mit grundlegend unterschiedlichen Verarbeitungsprofilen.

Mindestens diese Verarbeitungen brauchen jeweils einen eigenen Eintrag:

• Exchange Online – Geschäftliche E-Mail-Kommunikation, alle Beschäftigten und externen Kontakte, Aufbewahrung nach Postfachregeln und Retention Policies.
• SharePoint Online – Dokumentenmanagement, Berechtigungsstrukturen, häufig auch externe Gäste.
• OneDrive for Business – Persönliche Arbeitsdateien, Synchronisierung auf Endgeräten.
• Microsoft Teams – Chat, Audio und Video, Aufzeichnungen, Transkripte, externe Meeting-Teilnehmer.
• Microsoft 365 Copilot – KI-gestützte Verarbeitung mit Zugriff auf Mails, Dateien und Chats; in der DSGVO-Bewertung eine eigenständige Verarbeitung mit eigenen Risiken.

Jeder dieser Dienste hat eigene Empfänger – auch interne Rollen –, eigene Aufbewahrungsregeln und eigene Telemetrie-Datenströme an Microsoft. Wer das nicht trennt, kann eine Aufsichtsanfrage zur konkreten Verarbeitung nicht beantworten. Genau diese Detailtiefe fordert das aktuelle DPA, und genau hierfür stellt Microsoft das M365-Kit als Hilfsmittel bereit.

2. Die Datenschutz-Folgenabschätzung: nicht überall Pflicht, aber überall Schwellwertfrage

Eine Datenschutz-Folgenabschätzung (DSFA) nach Art. 35 DSGVO ist nicht für jeden M365-Einsatz vorgeschrieben. Eine dokumentierte Schwellwertanalyse aber schon – und genau die wird im Aufsichtsfall geprüft.

Drei Konstellationen, in denen aus unserer Sicht eine DSFA nicht umgangen werden sollte:

Copilot. KI-gestützte Verarbeitung, breiter Datenzugriff quer über Postfächer und Ablagen, potenziell neue Verarbeitungen ohne klare Zweckabgrenzung – das passt direkt auf die Muss-Liste der DSK für DSFA-pflichtige Verarbeitungen. Hinzu kommt das Risiko, dass Copilot über bestehende, aber unsaubere Berechtigungsstrukturen interne Inhalte offenlegt, die für den Anfragenden eigentlich nicht sichtbar sein sollten.

Beschäftigtenbezug. Audit-Logs, Meeting-Aufzeichnungen, Anwesenheitsindikatoren und Aktivitätsdaten in Teams können – auch wenn sie nicht zur Leistungskontrolle gedacht sind – objektiv geeignet sein, Verhalten oder Leistung zu überwachen. Das löst regelmäßig DSFA-Bedarf aus, und in mitbestimmten Unternehmen kommt der Betriebsrat zwingend ins Spiel.

Besondere Datenkategorien nach Art. 9 DSGVO. Gesundheits-, Sozial-, Personalvertretungs- oder Beschwerdedaten in SharePoint, OneDrive oder Teams-Kanälen sind kein theoretisches Szenario, sondern Praxis. Sobald solche Daten regelmäßig verarbeitet werden, ist eine DSFA fast immer angezeigt.

Wichtig: Auch wenn die Schwellwertanalyse ergibt, dass keine DSFA nötig ist, gehört diese Bewertung dokumentiert. Andernfalls fehlt im Streitfall der Nachweis, dass die Frage überhaupt geprüft wurde.

3. Technische und organisatorische Maßnahmen: die Tenant-Konfiguration entscheidet

Ein M365-Tenant wird ab Werk nicht datenschutzoptimal ausgeliefert. Die meisten Einstellungen, die der HBDI implizit voraussetzt, müssen aktiv konfiguriert werden.

Folgende Stellschrauben gehören in jede TOM-Dokumentation und in jede interne Prüfung:

Diagnose-Datenlevel. Die Microsoft-365-Apps senden Diagnose- und Telemetriedaten in unterschiedlichen Stufen. Wo möglich, sollte das niedrigere Level („Required“) eingestellt und die Wahl dokumentiert werden – sowohl auf Mandanten- als auch auf Geräte-Ebene.

Audit-Logs. Im Standard sind nicht alle Audit-Logs aktiv. Insbesondere für Copilot-Interaktionen ist die Aktivierung der Auditierung eine bewusste Entscheidung. Auch die Aufbewahrungsdauer der Logs ist konfigurierbar und gehört zur dokumentierten TOM.

Conditional Access und MFA. Zugriffskontrollen, die nach Standort, Gerätestatus oder Risikobewertung greifen, sind die technische Klammer um alles Weitere. Ohne sie bleibt jede DPA-Klausel ein Versprechen ohne Absicherung.

Information Protection und DLP. Sensitivity Labels und Data-Loss-Prevention-Richtlinien sind die Werkzeuge, um die im Verarbeitungsverzeichnis dokumentierten Schutzlevel technisch durchzusetzen – insbesondere dort, wo besondere Datenkategorien im Spiel sind.

Externer Zugriff und Gäste. Die Standardeinstellungen für externe Freigaben in SharePoint und Teams sind weit. Wer hier nicht eingreift, erzeugt Subprozessor-ähnliche Datenflüsse, die in keiner AV-Vereinbarung stehen.

Diese Punkte sind nicht abschließend, aber sie bilden den Kern dessen, was eine Aufsicht typischerweise zuerst abfragt. In unseren Mandaten zeigt sich regelmäßig, dass mindestens drei dieser fünf Stellschrauben in der Default-Konfiguration verbleiben – und damit angreifbar werden.

4. Interne Weisungen: ohne Regelwerk keine Compliance

Das beste DPA und der bestkonfigurierte Tenant nützen wenig, wenn Beschäftigte nicht wissen, wie sie M365 nutzen dürfen. Aus aufsichtsrechtlicher Sicht ist die Weisung an die Belegschaft ein wesentlicher Baustein der dokumentierten Verarbeitung – und damit kein „nice to have“, sondern Pflichtbestandteil der Rechenschaft nach Art. 5 Abs. 2 DSGVO.

Eine schriftliche Nutzungsrichtlinie sollte mindestens regeln:

• Welche Daten dürfen in Copilot-Prompts verwendet werden – und welche nicht (Personalakten, Vertragsentwürfe mit Personenbezug, Bewerberdaten, Gesundheitsdaten, Daten Dritter)?
• Wann sind Teams-Aufzeichnungen und -Transkripte zulässig, wer wird wie informiert, wer hat anschließend Zugriff, wann werden sie gelöscht?
• Wie wird externer Zugriff in SharePoint und Teams gehandhabt – anonyme Links, Gastfreigaben, Ablaufdaten, Genehmigungsprozesse?
• Welche Ablageorte sind für welche Datenkategorien vorgesehen (OneDrive vs. SharePoint-Bibliothek, allgemeine Kanäle vs. private Kanäle, klare Strukturen statt Wildwuchs)?

In mitbestimmten Unternehmen sind diese Regelungen häufig zusätzlich Gegenstand einer Betriebsvereinbarung – ein Punkt, der bei Copilot-Einführungen aktuell besonders intensiv diskutiert wird. Wer hier ohne BR-Einbindung produktiv geht, riskiert sowohl arbeitsrechtliche als auch datenschutzrechtliche Beanstandungen.

5. Drittlandtransfers: die EU-Datengrenze ist nicht das Ende der Prüfung

Microsoft hat mit der EU-Datengrenze einen großen Schritt gemacht – aber Restbestände bleiben. Bestimmte Verarbeitungen finden weiterhin außerhalb des EWR statt, etwa im Rahmen von Identity Services, Support-Anfragen, Telemetrie zur Produktverbesserung oder bestimmten Sicherheitsdiensten. Das ist nicht per se ein Problem – aber es ist auch nicht „weg“.

Was Sie dokumentieren sollten:

Die aktuelle Subprozessor-Liste von Microsoft mit Standort und Verarbeitungszweck – als Bestandteil Ihres AVV-Anhangs, mit einer Routine für die Aktualisierung.

Die Rechtsgrundlage für die Restbestände: in der Regel das EU-US Data Privacy Framework als Angemessenheitsbeschluss, ergänzt durch Standardvertragsklauseln für Drittstaaten ohne Angemessenheitsbeschluss.

Ein Transfer Impact Assessment für die wesentlichen Datenflüsse – nicht als Pflichtdokument für jede einzelne Übermittlung, aber als nachvollziehbare Bewertung der Risiken und der ergriffenen zusätzlichen Schutzmaßnahmen (Verschlüsselung, Pseudonymisierung, Customer-Lockbox-Mechanismen).

Mit anderen Worten: Die Aufsicht hat das vertragliche Fundament für tragfähig erklärt. Das Haus muss der Verantwortliche selbst bauen.

AVV-Prüfkriterien