Der DSGVO-konforme Betrieb von Microsoft 365 in Unternehmen

1.1 Ausgangslage der Cloud-Nutzung in Europa

Microsoft 365 ist in der europäischen Praxis kein Randthema mehr, sondern in Unternehmen, Behörden, Bildungseinrichtungen und freien Berufen vielfach der faktische Standard für moderne Arbeitsumgebungen. Die Plattform umfasst dabei kritische Infrastrukturen:

• Kommunikation: E-Mail (Exchange Online) und Meetings (Teams).
• Kollaboration: Gemeinsame Dokumentbearbeitung (SharePoint/OneDrive).
• Identitätsverwaltung: Zentrales Identity Management (Microsoft Entra ID).

Genau in dieser Allgegenwart liegt das datenschutzrechtliche Spannungsfeld. Häufig begegnen Verantwortliche der Komplexität mit zwei gegensätzlichen Fehlannahmen:

1. Die Legitimations-Annahme: „Da es jeder nutzt, wird es schon zulässig sein.“
2. Die Verbots-Annahme: „Aufgrund der Kritik der Aufsichtsbehörden ist es generell unzulässig.“

Beide Positionen greifen zu kurz. Maßgeblich ist vielmehr, ob der konkrete Verantwortliche die Verarbeitung auf eine tragfähige vertragliche, technische und organisatorische Grundlage gestellt hat und diese gemäß Art. 5 Abs. 2 DSGVO (Rechenschaftspflicht) nachweisen kann. Der Bericht des Hessischen Beauftragten für Datenschutz und Informationsfreiheit (HBDI) vom 15.11.2025 fungiert hierbei nicht als statisches „Produktsiegel“, sondern als strukturierte Bewertungshilfe. Er zeigt auf, wie die bisherigen Einwände adressiert werden können, damit Verantwortliche ihren Pflichten rechtssicher nachkommen.

Der Wandel der Bewertung (2022 vs. 2025)

Die Debatte hat sich seit der Veröffentlichung des kritischen Abschlussberichts der Datenschutzkonferenz (DSK) in der Kausa „Microsoft-Onlinedienste“ im Jahr 2022 (und hier die Stellungnahme dazu) grundlegend gewandelt. Die folgende Tabelle verdeutlicht die veränderte Ausgangslage:

Fazit für die Praxis

Für die Praxis folgt daraus ein nüchterner Ausgangspunkt: Microsoft 365 ist datenschutzrechtlich weder durch seine Marktverbreitung legitimiert noch durch die Kritik aus 2022 pauschal ausgeschlossen. Die Zulässigkeit ist stets an die konkrete Einsatzform gebunden.

Wer Microsoft 365 nutzt, steht vor einer doppelten Aufgabe:

• Administration: Das Produkt technisch lauffähig halten.
• Modellierung: Die Plattform datenschutzrechtlich durch Konfiguration (Privacy by Default) und rechtliche Begleitdokumente (DSFA) absichern.

Genau dort liegt der entscheidende Unterschied zwischen einem bloß produktiven Tenant und einem belastbaren, prüffähigen Tenant.

1.2 Sektorspezifische Relevanz und Schutzdimensionen

Die Relevanz von Microsoft 365 ist in den verschiedenen Sektoren unterschiedlich gewichtet, folgt aber einer vergleichbaren strukturellen Logik. Je nach Anwendergruppe verschieben sich die Schwerpunkte der Compliance-Anforderungen:

• Unternehmen: Fokus auf das integrierte Betriebsmodell (Exchange Online, Teams, SharePoint, OneDrive, Office-Apps, Entra ID, Intune und Purview) und die produktive Skalierbarkeit.
• Behörden: Fokus auf revisionsfeste Governance, Dokumentation der Kontrollfähigkeit und die strikte Minimierung von Drittlandrisiken.
• Berufsgeheimnisträger: (Rechtsanwälte, Steuerberater, Ärzte) Hier tritt zur DSGVO eine weitere Schutzdimension hinzu: die Wahrung des Kernbereichs der privaten Lebensgestaltung und der Schutz des Berufsgeheimnisses.

Die doppelte Hürde: DSGVO vs. § 203 StGB

Gerade für Berufsgeheimnisträger reicht eine Standard-Datenschutzprüfung nicht aus. Es besteht ein fundamentaler Unterschied in der Schutzrichtung:

Daraus folgt nicht, dass Microsoft 365 für Berufsgeheimnisträger unzulässig ist. Es bedeutet jedoch, dass die Schwelle für technische und organisatorische Zusatzmaßnahmen (ZTM) deutlich höher liegt. Standardkonfigurationen oder allgemeine Checklisten genügen hier nicht, um das Restrisiko einer (theoretischen) Kenntnisnahme durch den Cloud-Anbieter oder US-Behörden auszuschließen.

Instrumente zur Risikominimierung

Um die Anforderungen des HBDI-Berichts und des § 203 StGB zu erfüllen, müssen spezifische Schutzinstrumente implementiert werden. Diese sind keine optionalen „Komfortfunktionen“, sondern essenzielle Barrieren gegen Restrisiken:

• Schlüsselhoheit (Customer Key / BYOK): Sicherstellung, dass Daten ohne den vom Kunden verwalteten Schlüssel unlesbar bleiben.
• Customer Lockbox: Explizite Freigabe durch den Kunden, falls Microsoft-Techniker zu Supportzwecken (theoretisch) Zugriff auf Daten benötigen.
• Privileged Access Management: Strikte Zugriffskontrolle und Protokollierung innerhalb des Tenants.
• Belastbare DSFA: Eine detaillierte Datenschutz-Folgenabschätzung, die explizit die Risiken für das Berufsgeheimnis evaluiert.

Diese Einordnung korrespondiert mit der Grundlogik des HBDI-Berichts vom 15.11.2025, der ein positives Gesamtergebnis ausdrücklich an die Bedingung knüpft, dass der Verantwortliche eigene, über den Standard hinausgehende Maßnahmen ergreift.

1.3 Entwicklung der datenschutzrechtlichen Bewertung von 2018 bis 2026

Die heutige Bewertung ist nur verständlich, wenn man die historische Entwicklungslinie sauber trennt. In der frühen Phase standen internationale Datenflüsse, US-Zugriffsmöglichkeiten und die Intransparenz der Microsoft-Servicelogik im Fokus. Nach dem Schrems II-Urteil (2020) und dem Wegfall des Privacy Shield verschob sich der Fokus in Deutschland von der reinen Auftragsverarbeitung hin zu strukturellen Drittlandrisiken und der Frage der Eigenverarbeitung durch Microsoft.

Die Zäsur markierte das Jahr 2022. Die Datenschutzkonferenz (DSK) stellte fest, dass ein Nachweis der Konformität auf Basis des damaligen DPA (Stand 15.09.2022) nicht möglich sei. Die Kritik kristallisierte sich an sieben Kernpunkten entlang von Art. 28 DSGVO heraus:

Der HBDI kommt zu dem Ergebnis, dass ein datenschutzkonformer Betrieb möglich sein kann. Der Bericht stellt jedoch keine technische Prüfung oder generelle Freigabe einzelner Microsoft-365-Dienste dar.

2.1 Rolle des Verantwortlichen und des Auftragsverarbeiters

Der rechtliche Ausgangspunkt ist eindeutig: Nutzt eine Stelle Microsoft 365 für eigene Zwecke, bleibt sie für die durchgeführten Verarbeitungen grundsätzlich Verantwortlicher (Art. 4 Nr. 7 DSGVO). Microsoft fungiert in diesem Modell primär als Auftragsverarbeiter (Art. 4 Nr. 8 DSGVO), sofern personenbezogene Daten weisungsgebunden im Auftrag des Kunden verarbeitet werden.

Auf dieser Rollenverteilung basiert die gesamte Architektur des HBDI-Berichts vom 15.11.2025. Er stellt klar, dass die datenschutzrechtliche Grundlage hierfür das Data Processing Addendum (DPA) ist. Die Bewertung des HBDI konzentriert sich maßgeblich darauf, ob dieser Rahmen den strengen Anforderungen des Art. 28 DSGVO standhält.

Die Dynamik der Auftragsverarbeitung

Diese Zuordnung ist kein statischer Zustand, sondern der Beginn einer fortlaufenden Prüfungspflicht. Wie die DSK-Kritik 2022 und die anschließende HBDI-Aufarbeitung zeigen, reicht ein formaler Vertragsschluss nicht aus, wenn folgende Kernfragen unbeantwortet bleiben:

• Zweckbestimmung: Zu welchen expliziten Zwecken erfolgt die Verarbeitung?
• Eigenverarbeitung: In welchem Umfang beansprucht Microsoft Befugnisse für eigene Geschäftszwecke (z. B. Abrechnung, Sicherheit, Missbrauchskontrolle)?
• Offenlegung: Wie weit reichen die Befugnisse zur Offenlegung gegenüber Dritten oder Behörden?
• Transparenz: Sind die Datenflüsse innerhalb der komplexen Cloud-Infrastruktur ausreichend bestimmt?

Operative Umsetzung der Verantwortlichkeit

Für die Praxis bedeutet dies: Die pauschale Feststellung „Microsoft ist unser Auftragsverarbeiter“ ist rechtlich nicht belastbar. Der Verantwortliche muss diese Einordnung proaktiv mit Inhalten füllen und dokumentieren.

Genau an dieser Stelle setzt das M365-Kit an. Es bietet die notwendige methodische Brücke, um die Anforderungen des Art. 28 DSGVO in operative Artefakte zu übersetzen, wie etwa das Verzeichnis von Verarbeitungstätigkeiten (VVT), die Schwellwertanalyse und die Definition tragfähiger Rechtsgrundlagen. Damit wird die theoretische Verantwortlichkeit in einen prüffähigen Prozess überführt.

2.2 Anforderungen aus Art. 5 DSGVO: Grundsätze der Verarbeitung

Art. 5 DSGVO bildet den materiellen Kern jeder M365-Bewertung. In Cloud-Umgebungen wird häufig zu stark auf die rein vertragliche (Art. 28) oder sicherheitstechnische (Art. 32) Komponente fokussiert, während die materiellen Grundsätze der Verarbeitung vernachlässigt werden. Dabei scheitern viele Konfigurationen bereits an den Basisvorgaben.

Die Grundsätze im M365-Kontext

• Rechtmäßigkeit, Treu und Glauben, Transparenz: Jede M365-Verarbeitung erfordert eine belastbare Rechtsgrundlage. Da „eine Rechtsgrundlage für M365“ in der Praxis nicht existiert, ist workload- und zweckbezogen zu prüfen. Das M365-Kit bietet hierfür differenzierte Muster für Szenarien wie Teams, Copilot oder Defender.
• Zweckbindung: Eine hochintegrierte Plattform verleitet dazu, Zusatzfunktionen (KI-Analysen, Empfehlungsdienste) ohne erneute Zweckprüfung zu aktivieren. Das M365-Kit unterstreicht, dass die dort genannten Rechtsgrundlagen nur Standardtätigkeiten abdecken; jede neue Funktion erfordert eine eigene Bewertung.
• Datenminimierung: Dies ist in M365 ein systemisches Gebot. Es betrifft drei Ebenen:
  1. Die Auswahl der notwendigen Workloads.
  2. Die strikte Konfiguration von Telemetrie-, Diagnose- und Komfortfunktionen.
  3. Die Limitierung von Gastzugriffen, externen Datenflüssen und unnötigen Persistenzen.
• Richtigkeit: Dieser Grundsatz wird besonders bei Verzeichnisdaten (Entra ID), Benutzerrollen und Profilinformationen relevant, die die Basis für Zugriffsberechtigungen bilden.
• Speicherbegrenzung: Die Cloud ist auf Persistenz und Versionskontrolle ausgelegt. Ohne definierte Retention- und Löschkonzepte (Retention Policies) entstehen schnell rechtswidrige Datenbestände. Der HBDI hebt „Löschung und Rückgabe“ explizit als eigene Prüfgruppe hervor.

Rechenschaftspflicht (Art. 5 Abs. 2 DSGVO)

Die Rechenschaftspflicht ist der zentrale Dreh- und Angelpunkt für M365-Nutzer. Der Verantwortliche muss die Einhaltung sämtlicher Grundsätze aktiv belegen können.

Das M365-Kit fungiert hierbei lediglich als methodische Unterstützung. Es entbindet den Verantwortlichen nicht davon, die Muster auf die tatsächliche Nutzung, die gewählten Sicherheitskonfigurationen und die spezifische Risikolage des Unternehmens oder der Behörde anzupassen. Die Rechenschaftspflicht verlangt den Nachweis, dass der Tenant nicht nur „betrieben“, sondern aktiv im Sinne des Datenschutzes modelliert wurde.

2.3 Anforderungen aus Art. 25 DSGVO: Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen

Art. 25 DSGVO ist im Microsoft-365-Umfeld der entscheidende Architektur-Artikel. Während Datenschutz oft fälschlicherweise nur als Vertrags- oder Policy-Thema behandelt wird, erfordert die Cloud-Nutzung zwingend einen Fokus auf die technische Konfigurationsdisziplin.

Datenschutz durch Technikgestaltung (Privacy by Design)

Dieser Grundsatz verlangt, dass der Verantwortliche das technische Betriebsmodell bewusst steuert, anstatt sich auf die herstellerseitigen Standardeinstellungen zu verlassen. Die Gestaltung umfasst:

• Workload-Steuerung: Selektive Aktivierung der Dienste statt „All-in-One“-Freigabe für alle Benutzer.
• Funktionskontrolle: Gezielte Deaktivierung von Diagnose- und Verbundfunktionen, die für den Kernbetrieb nicht zwingend erforderlich sind.
• Datenabfluss-Architektur: Implementierung technischer Kontrollen, die den Datenfluss über Tenant-Grenzen hinweg unterbinden oder einschränken (z. B. Data Loss Prevention Policies).

Der HBDI-Bericht macht deutlich, dass die Standardwerte von Microsoft keinen „Safe Harbor“ darstellen. Vielmehr sind die Handlungsempfehlungen als verbindliche Architekturvorgaben zu verstehen, die den M365-Tenant erst für den konkreten Einsatz datenschutzrechtlich bewertbar machen.

Datenschutzfreundliche Voreinstellungen (Privacy by Default)

Die „Härtung“ des Tenants ist die operative Umsetzung von Privacy by Default. Ein System ist nur dann als datenschutzfreundlich einzustufen, wenn die Voreinstellungen bereits das Schutzniveau maximieren.

Die Kernthese: Architektur vor Administration

Aus Art. 25 DSGVO ergibt sich eine fundamentale Schlussfolgerung für die Praxis: Ein datenschutzfähiger M365-Tenant ist kein reines Vertragsthema mit nachgelagerter Administration. Stattdessen muss der Tenant als ein bewusst restriktiv vorkonfiguriertes System betrachtet werden. Jede Abweichung von diesem restriktiven Status Quo – etwa durch die Aktivierung neuer KI-Features oder erweiterter Kollaborationswerkzeuge – stellt eine Ausnahme dar, die als solche begründet, bewertet und dokumentiert werden muss. Datenschutz in M365 ist somit kein statischer Status, sondern ein kontinuierlicher Prozess der technischen Systemsteuerung.

2.4 Anforderungen aus Art. 28 DSGVO: Auftragsverarbeitung

Art. 28 DSGVO ist der juristische Brennpunkt der gesamten Microsoft-365-Debatte. Die sieben DSK-Kritikpunkte von 2022 bilden das Raster, an dem sich die datenschutzrechtliche Belastbarkeit des Auftragsverarbeitungsverhältnisses (AVV) bemessen lässt.

Die sieben Prüfpunkte des HBDI-Berichts

Der HBDI-Bericht vom 15.11.2025 strukturiert die rechtlichen Erwägungen und Handlungsempfehlungen entlang dieser Problemgruppen:

• Zweck- und Datenkategorien: Präzise Definition dessen, was verarbeitet wird.
• Eigenverantwortung Microsofts: Eingrenzung der Datenverarbeitung für Microsofts eigene Geschäftstätigkeiten.
• Weisungsbindung: Transparenz und Kontrollmöglichkeit bei der Ausführung von Weisungen sowie Regeln zur Offenlegung.
• TOMs: Nachweisbarkeit angemessener technischer und organisatorischer Maßnahmen.
• Löschung und Rückgabe: Verbindliche Verfahren nach Vertragsbeendigung.
• Unterauftragsverarbeiter: Transparenz und Einspruchsrechte bei Sub-Dienstleistern.
• Drittlandübermittlung: Absicherung durch EU Data Boundary und Transfer-Impact-Assessments (TIA).

Die zweistufige Konkretisierung

Die Konformität nach Art. 28 DSGVO wird nicht durch ein einzelnes Dokument erreicht, sondern durch das Zusammenspiel verschiedener Ebenen. Verantwortliche müssen dieses Zusammenspiel aktiv in ihr Verzeichnis von Verarbeitungstätigkeiten (VVT) integrieren.

Wichtige Abgrenzung zur „Freigabe“

Es ist zwingend zu beachten: Der HBDI-Bericht ist keine pauschale „Freigabe“ von Microsoft 365. Bewertet wurde der Rahmenvertrag (DPA) unter Berücksichtigung der von Microsoft zugesagten Praxis. Eine produktscharfe technische Prüfung aller M365-Komponenten war nicht Gegenstand des Berichts.

Für Verantwortliche folgt daraus:

1. Kein Rückzug auf den Vertrag: Wer sich nur auf das DPA stützt, erfüllt die Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO nicht.
2. Aktive Dokumentation: Die vertraglichen Vereinbarungen müssen zwingend mit der konkreten Tenant-Konfiguration (Workload-Auswahl, Zugriffsschutz, Löschlogik) korrespondieren.
3. Ergänzungsbedarf: Produktspezifische Erweiterungen oder KI-Funktionen (wie Copilot) unterliegen einer eigenen, gesonderten Bewertung, da sie über das standardisierte DPA-Rahmenwerk hinausgehen können.

Ein Verantwortlicher, der nur die vertragliche Stufe erfüllt, vernachlässigt die technische Kontrolle; wer nur technisch härtet, ohne den rechtlichen Rahmen sauber abzubilden, ist ebenfalls nicht revisionssicher aufgestellt. Nur die Kombination aus beidem ergibt einen belastbaren Nachweis der Konformität.

2.5 Anforderungen aus Art. 32 DSGVO: Sicherheit der Verarbeitung

Art. 32 DSGVO fungiert im Microsoft-365-Kontext als operativer Maßstab für das sogenannte „Hardening“ des Tenants. Der HBDI-Bericht behandelt die Umsetzung technischer und organisatorischer Maßnahmen (TOMs) als eigenständigen Prüfkomplex, da bei einer globalen SaaS-Plattform die wesentliche Sicherheitsmarge maßgeblich durch kundenseitige Maßnahmen bestimmt wird.

Sicherheit als kundenseitige Architekturaufgabe

Da Microsoft das System bereitstellt, obliegt die sichere Ausgestaltung der spezifischen Nutzung dem Kunden. Der „Stand der Technik“ nach Art. 32 DSGVO stellt hierbei eine dynamische Untergrenze dar, die über einfache Standardeinstellungen weit hinausgeht.

Besondere Anforderungen für Berufsgeheimnisträger

Für Berufsgeheimnisträger (nach § 203 StGB) reicht der allgemeine Sicherheitsstandard der Plattform nicht aus. Hier verschiebt sich die Bewertung: Es genügt nicht mehr, auf die Integrität der Microsoft-Standardfunktionen zu verweisen. Vielmehr ist proaktiv nachzuweisen, dass eine unbefugte Kenntnisnahme durch Dritte – inklusive des Cloud-Anbieters oder Drittstaatsbehörden – technisch und rechtlich maximal erschwert wird.

In diesem Umfeld gewinnen hochspezialisierte Schutzinstrumente an Bedeutung:

• Schlüsselhoheit: Der Zugriff auf Daten muss kryptografisch so abgesichert sein, dass Microsoft ohne den kundenseitigen Schlüssel keine Kenntnis von Inhalten erlangen kann.
• Customer Lockbox: Die organisatorische Absicherung von Supportzugriffen durch eine zwingende manuelle Freigabe („Just-in-Time Access“) durch den Verantwortlichen.
• Support-Governance: Zusätzliche organisatorische Prozesse, die sicherstellen, dass auch bei autorisiertem Support-Zugriff keine unzulässigen Datenabflüsse stattfinden.

Korrespondenz mit der HBDI-Logik

Diese Maßnahmen sind keine optionale „Premium-Konfiguration“, sondern die notwendige Bedingung, um das vom HBDI geforderte Gesamtschutzniveau zu erreichen. Die Logik ist systemisch:

1. Basis-Hardening: Umsetzung der allgemeinen TOMs für alle Nutzer (Art. 32 Abs. 1 DSGVO).
2. Spezifische Zusatzmaßnahmen (ZTM): Erhöhung der Hürden für sensible Datenkategorien (Berufsgeheimnisse, hoheitliche Daten).
3. Risiko-Abschätzung: Dokumentation der Wirksamkeit dieser Maßnahmen im Rahmen der DSFA.

Art. 32 DSGVO ist somit die technische Schnittstelle, in der die rechtlichen Anforderungen an Vertraulichkeit, Integrität und Verfügbarkeit ihre operative Ausprägung finden. Ein Tenant ohne nachweisbare Härtung ist im Lichte des Art. 32 DSGVO als mangelhaft einzustufen, unabhängig davon, welche vertraglichen Zusagen Microsoft im DPA trifft.

2.6 Drittlandübermittlungen nach Art. 44 ff. DSGVO

Die Drittlandübermittlung stellt das datenschutzrechtliche Nadelöhr bei der Nutzung von Microsoft 365 dar. Der HBDI-Bericht adressiert dies explizit, da die Konformität eines Tenants nicht nur an den Speicherort der Inhaltsdaten gebunden ist, sondern an die Gesamtheit aller technisch notwendigen Datentransfers außerhalb des EWR.

Die EU Data Boundary als strukturelle Basis

Die Microsoft EU Data Boundary wird seit Januar 2023 schrittweise umgesetzt. Seit Januar 2024 wurden weitere Datenkategorien einbezogen; die vollständige Implementierung wurde Anfang 2025 abgeschlossen. Sie reduziert Übermittlungen drastisch, eliminiert diese jedoch nicht vollständig. Als verbleibende Fallgruppen für Drittlandübermittlungen identifiziert der HBDI insbesondere:

• Support & Beratung: Übermittlung von Professional-Services-Daten.
• Cybersecurity: Globale Sicherheitsmaßnahmen zum Schutz vor Bedrohungen.
• Infrastruktur: Verzeichnisdaten (Entra ID), Netzwerk-Transit und Routing-Optimierungen.
• Plattformmanagement: Qualitätssicherung und Management-Metadaten.

Zweistufige Prüfungslogik für Verantwortliche

Die rechtliche Bewertung erfolgt in zwei Schritten, wobei die formale Basis (DPF/SCC) durch eine konkrete Risikoanalyse ergänzt werden muss:

1. Stufe I (Regel-Fall): Prüfung der verbleibenden Drittlandrisiken im Lichte der EU Data Boundary und des EU-US Data Privacy Frameworks (DPF).
2. Stufe II (Schutzbedarf-Fall): Durchführung eines Transfer-Impact-Assessments (TIA) bei hochschutzbedürftigen Daten, um zu beurteilen, ob formale Instrumente (DPF/SCC) ausreichen oder zusätzliche Zusatzmaßnahmen (ZTM) erforderlich sind.

Konsequenzen für die Praxis

Verantwortliche können sich nicht allein auf die Existenz der EU Data Boundary oder das DPF entlasten. Insbesondere in hochschutzbedürftigen Umgebungen (Berufsgeheimnisträger, kritische Infrastrukturen) bleibt die rein formale Berufung auf Angemessenheitsbeschlüsse oder Standardvertragsklauseln (SCC) für eine vollständige Rechenschaftspflicht (Art. 5 Abs. 2 DSGVO) unzureichend.

Hier ist eine operative Trennung erforderlich:

• Standard-Tenant: EU Data Boundary und EU-US Data Privacy Framework können wesentliche Voraussetzungen für einen datenschutzkonformen Einsatz schaffen. Die Erfüllung der DSGVO-Pflichten hängt jedoch weiterhin von der konkreten Konfiguration, Nutzung und Risikobewertung durch den Verantwortlichen ab.
• Hochschutz-Tenant: Notwendigkeit zusätzlicher technischer Barrieren (z.B. Verschlüsselung mit kundenseitigem Schlüssel/DKE), um den Zugriff durch Dritte bei notwendigen Support- oder Wartungs-Zugriffen im Drittland technisch auszuschließen.

Das bedeutet im Umkehrschluss: Die Drittlandübermittlung wird in der neuen Bewertung des HBDI vom „pauschalen Ausschlusskriterium“ zum „kontrollierbaren Risikoparameter“. Die operative Herausforderung besteht darin, diese Risiken für den spezifischen Tenant-Einsatz zu identifizieren und die getroffenen Schutzvorkehrungen in der DSFA zu dokumentieren.

2.7 Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO

Die Rechenschaftspflicht bildet das Fundament für die Prüffähigkeit eines jeden Tenants. Sie ist der verbindende Oberbegriff, der die Anforderungen aus Art. 28, Art. 25 und Art. 32 DSGVO in eine operative Struktur überführt. Der HBDI-Bericht und das M365-Kit zielen nicht darauf ab, Verantwortliche von ihrer Pflicht zu entbinden, sondern sie methodisch in die Lage zu versetzen, den datenschutzkonformen Einsatz nachzuweisen.

Die Grundpfeiler der dokumentierten Rechenschaft

Ein „datenschutzfähiger“ Tenant ist zwingend ein „dokumentierter“ Tenant. Die Rechenschaftspflicht erfordert den Nachweis, dass der Verantwortliche die Kontrolle über das System nicht nur de jure (durch Verträge), sondern de facto (durch Konfiguration und Prozesssteuerung) ausübt.

Die folgende Übersicht stellt die Mindestanforderungen an eine prüffähige Dokumentation dar:

Die methodische Brücke: Das M365-Kit

Das M365-Kit fungiert als methodisches Gerüst für die Rechenschaftspflicht, entbindet den Verantwortlichen jedoch nicht von der individuellen Adaption. Es stellt Muster für das Verzeichnis von Verarbeitungstätigkeiten (VVT), Schwellwertanalysen und Rechtsgrundlagen zur Verfügung, die zwingend in den Kontext der jeweiligen Tenant-Konfiguration zu setzen sind.

Von der Administration zur Verteidigungsfähigkeit

Die Umwandlung von „administrativem Betrieb“ in „datenschutzrechtlich verteidigungsfähige Nutzung“ gelingt nur durch die konsequente Zusammenführung dieser Dokumente. Ein Verantwortlicher, der lediglich den Standardzustand (Default) des Tenants beibehält, ohne eine spezifische, auf die eigene Nutzung angepasste Dokumentationslage zu schaffen, verfehlt die Anforderungen des Art. 5 Abs. 2 DSGVO.

Die Rechenschaftspflicht ist daher kein statisches Ziel, das durch einmalige Konfiguration erreicht wird, sondern ein kontinuierlicher Zyklus:

1. Initial-Assessment: Bestandsaufnahme der benötigten Dienste und Daten.
2. Hardening & Konfiguration: Technische Umsetzung der Sicherheitsvorgaben (Art. 25, 32).
3. Dokumentation: Anpassung der Muster an die tatsächliche Konfiguration.
4. Monitoring & Review: Regelmäßige Überprüfung der Konfiguration und Fortschreibung der DSFA bei funktionalen Änderungen.

Erst durch diese Gesamtschau wird der Verantwortliche gegenüber Aufsichtsbehörden rechenschaftsfähig und kann nachweisen, dass der Einsatz von Microsoft 365 nicht auf einem bloßen Vertrauen auf den Anbieter basiert, sondern auf einem kontrollierten und nachvollziehbaren Prozess.

2.8 Besonderheiten für Berufsgeheimnisträger nach § 203 StGB

Für Steuerberater, Rechtsanwälte, Wirtschaftsprüfer, Ärzte und vergleichbare Berufsgeheimnisträger greift das zweistufige Schutzregime: Neben der DSGVO (Schutz der betroffenen Person) ist der Geheimnisschutz nach § 203 StGB (Schutz des anvertrauten Geheimnisses selbst) maßgeblich.

Schutz der Geheimnissphäre im M365-Kontext

Die erhöhte Sensibilität gegenüber potenzieller Kenntnisnahme durch Dritte – inklusive Microsoft oder ausländischer Behörden – erfordert eine spezifische Konfigurations- und Dokumentationsstrategie:

• Verschärfte Vertragslage: Das allgemeine DPA dient nur als Basis. Die Praxis erfordert zusätzliche Vereinbarungen und eine extrem restriktive technische Härtung.
• Fokus auf technische Barrieren: Schutzinstrumente sind keine optionalen Komfortfunktionen, sondern notwendige Barrieren zur Risikominimierung:
  • Schlüsselhoheit: Ausschließlich kundenkontrollierte kryptografische Schlüssel (BYOK).
  • Customer Lockbox: Zwingende manuelle Freigabe für jegliche Support-Zugriffe.
  • Double Key Encryption (DKE): Maximale Absicherung bei hohem Schutzbedarf, bei der nur der Kunde den Schlüssel besitzt.
• Geheimnisschutz-DSFA: Die Datenschutz-Folgenabschätzung muss zwingend um die spezifische Perspektive des § 203 StGB erweitert werden. Die Risikobewertung fokussiert hier nicht auf Datenpannen im klassischen Sinne, sondern auf die Offenbarung von Geheimnissen.

Systematik der Anforderungserhöhung

Die Anforderung an Berufsgeheimnisträger steht nicht im Widerspruch zur HBDI-Linie, sondern ist eine logische Konsequenz. Der HBDI-Bericht definiert den Rahmen, in dem der Verantwortliche seine Einsatzform bewerten muss.

Technische Maßnahmen wie clientseitige Verschlüsselung oder Double-Key-Modelle können bei Berufsgeheimnisträgern ein wesentliches Schutzinstrument darstellen. Ob sie erforderlich sind, hängt jedoch von Risikoanalyse, Datenart und berufsrechtlicher Bewertung im Einzelfall ab.

3.1 DSK-Beschluss und Kritikpunkte 2022

Der Ausgangspunkt der heutigen Bewertung bleibt die Feststellung der Datenschutzkonferenz (DSK) aus dem November 2022. Der HBDI referiert diese Position ausdrücklich: Auf Grundlage des damaligen „Datenschutznachtrags vom 15. September 2022“ könne der Nachweis einer datenschutzrechtskonformen Nutzung von Microsoft 365 nicht geführt werden. Die DSK benannte sieben Kritikpunkte, die nachfolgend als Prüfmaßstab für die heutige Bewertung dienen:

Wer Microsoft 365 2026 bewertet, sollte die Plattform entlang dieser sieben Problemfelder untersuchen, da die hessische Neubewertung 2025 explizit auf diese Punkte referenziert.

3.2 Handreichungen einzelner Landesdatenschutzbehörden 2023

Zwischen der DSK-Feststellung von 2022 und der hessischen Neubewertung von 2025 lag eine Phase erheblicher Unsicherheit. Es entstand kein genereller Freigabekonsens, sondern eine Konditionierungsphase:

• Keine pauschale Freigabe: Es gab keine „Genehmigung“ durch Aufsichtsbehörden.
• Fokus auf Einflussnahme: Verantwortliche wurden angehalten, aktiv auf Vertragsinhalte einzuwirken und zusätzliche Sicherheitsmaßnahmen zu dokumentieren.
• Kompatibilität: Die hessische Linie von 2025 steht nicht im Widerspruch zu 2023, sondern ist die Fortführung einer Entwicklung: Weg von der pauschalen Feststellung struktureller Defizite, hin zu einer präzisen Bedingungslogik für eine zulässige Nutzung.

3.3 Entwicklung des EU-US Data Privacy Framework

Der HBDI nennt die rechtlichen Änderungen seit 2022, insbesondere den Angemessenheitsbeschluss der EU-Kommission zum Data Privacy Framework (DPF), als einen wesentlichen Grund für die Neubewertung. Das DPF entlastet die rechtliche Argumentation für bestimmte Transfers, ersetzt jedoch nicht die konkrete Prüfung der Übermittlungsszenarien.

Für den Fachbetrieb bedeutet das: Das DPF ist ein relevanter rechtlicher Baustein, aber kein Ersatz für Datensparsamkeit, Support-Governance oder workloadbezogene Drittlandprüfungen.

3.4 Bericht des HBDI vom 15.11.2025

Die Kernaussage des HBDI ist präzise: Drei Jahre nach der DSK-Feststellung könne der HBDI nun feststellen, dass ein datenschutzkonformer Betrieb möglich ist – bezogen auf die sieben Kritikpunkte der DSK. Dies beruht auf:

1. Geänderten rechtlichen Vorgaben.
2. Anpassungen Microsofts (insb. DPA-öS).
3. Bereitstellung von Hilfsmitteln wie dem M365-Kit.

Dieses Ergebnis ist an die Erwartung geknüpft, dass Microsoft und die Verantwortlichen proaktiv zusammenwirken, um die Anforderungen zu operationalisieren.

3.5 Grenzen der Aussagekraft des HBDI-Berichts

Gerade weil der Bericht positiv aufgenommen wurde, ist seine Abgrenzung für die tägliche Arbeit essenziell:

• Keine Produktprüfung: Der Bericht bewertet den Rahmenvertrag (DPA), keine spezifischen technischen Implementierungen der einzelnen M365-Dienste.
• Normative Bewertung: Es handelt sich um eine rechtliche Bewertung des Dokumentationsrahmens, nicht um eine technische Zertifizierung von Diensten wie Teams, SharePoint oder Copilot.
• Eigenverantwortung: Die technische Tenant-Härtung verbleibt vollumfänglich beim Verantwortlichen.

3.6 Fortbestehende Risiken und Prüfpflichten

Nach der HBDI-Bewertung verschiebt sich die Verantwortung von einer pauschalen Ablehnung hin zu einem differenzierten Risikomanagement:

Die Entwicklung von 2022 bis 2025 führt somit nicht zur Entwarnung, sondern zu einem präziseren Verantwortungsmodell: Weg von der pauschalen Unmöglichkeit, hin zu einer operativen Pflicht zur konkreten Ausgestaltung.

4.1 Governance-Modell

Governance ist das Fundament der Rechenschaftspflicht (Art. 5 Abs. 2 DSGVO). Sie definiert die Entscheidungsbefugnisse und Verantwortlichkeiten für den gesamten Tenant-Lebenszyklus und überführt die abstrakten HBDI-Handlungsempfehlungen in den operativen Betrieb.

Praktisch muss das Governance-Modell formalisieren, wer für die Bewertung neuer Funktionen, die Sicherheitsbaselines, die Freigabe externer Zusammenarbeit und die Pflege des Verzeichnisses zuständig ist. Ohne dieses Modell bleibt der Tenant technisch administrierbar, aber rechtlich schwer verteidigbar.

4.2 Zero-Trust-Prinzipien

In einer Cloud-Umgebung ist der „Netzwerk-Perimeter“ irrelevant. Zero Trust operationalisiert Art. 25 und Art. 32 DSGVO, indem es dem System untersagt, Vertrauen vorauszusetzen.

• Identität: MFA ist zwingend; Authentifizierung wird kontextabhängig bewertet (Conditional Access).
• Gerät: Zugriff erfolgt nur über konforme (managed) Geräte.
• Privilegien: RBAC/PIM sorgt für „Least Privilege“-Zugriffe, idealerweise zeitlich begrenzt (Just-in-Time).
• Sitzung: Kontinuierliche Validierung des Sitzungskontexts.

4.3 Datenklassifizierungsmodell

Ohne Klassifizierung können DLP-Regeln und Retention-Policies nicht verhältnismäßig greifen. Die Architektur muss zwingend auf einer differenzierten Daten- und Zweckklassifizierung basieren.

Wir empfehlen ein vierstufiges Modell als Mindeststandard:

1. Öffentlich/Gering: Keine personenbezogenen Daten.
2. Intern: Interne Geschäftskommunikation ohne sensiblen Inhalt.
3. Vertraulich: Personenbezogene Daten (Standard DSGVO).
4. Hochvertraulich: Berufsgeheimnisse (§ 203 StGB) / besonders schutzbedürftige Daten.

Erst auf dieser Basis werden Labels, Freigaberegeln, DLP-Muster, Zugriffsregeln und Aufbewahrungsfristen konsistent.

4.4 Zugriffsschutz-Modell

Der Zugriffsschutz verknüpft Identität, Rolle, Gerät und Ressource. Er ist keine fakultative Veredelung, sondern die technische Umsetzung der Vertraulichkeitsgebote.

• Zentral: MFA für 100 % der Identitäten.
• Admin-Härtung: Ausschließlich PIM (Privileged Identity Management) für Administrationszugriffe.
• Gast-Management: B2B-Zugriffe nur nach dokumentiertem Anwendungsfall und unter restriktiver Link-Steuerung.
• Legacy: Konsequente Deaktivierung veralteter Authentifizierungsprotokolle.

4.5 Datenabfluss-Kontrollen

Datenabfluss in SaaS-Umgebungen ist ein Zusammenspiel aus Freigaben, Synchronisation, E-Mail, Teams, Downloads und externen Tenants. Ein wirksames Modell besteht aus mehreren Schichten:

4.6 Nachweis- und Audit-Architektur

Eine datenschutzrechtlich tragfähige Architektur muss nicht nur Schutz ausüben, sondern diesen auch beweisen können.

• Audit-Standard: Tenant-weite Aktivierung von Unified Audit Logs (UAL).
• Revisionssicherheit: Externe Ablage (SIEM/Log-Archiv) von Konfigurations-Snapshots.
• Admin-Audit: Protokollierung aller Änderungen an Sicherheits- und Compliance-Policies.
• Transparenz: Exportierbarkeit von Ist-Konfigurationen zum Vergleich mit den Compliance-Vorgaben (Soll-Ist-Abgleich).

Ohne Auditarchitektur bleibt Governance deklarativ.

4.7 Betriebs- und Support-Modell

Support ist kein bloßer technischer Akt, sondern eine datenschutzrelevante Tätigkeit. Da Microsoft-Support in der Cloud oft globale Ressourcen einbezieht, sind eigene Leitplanken erforderlich:

• Support-Minimierung: Bereitstellung von Daten nur in absolut notwendigem Umfang.
• Customer Lockbox: Nutzung der technischen Kontrollmöglichkeit zur manuellen Freigabe von Supportzugriffen bei kritischen Tenants.
• Dokumentationspflicht: Jedes Ticket mit Datenbezug ist als Vorgang im datenschutzrechtlichen Sinne zu behandeln und zu dokumentieren.

Durch geeignete technische und organisatorische Maßnahmen kann eine IT-Infrastruktur geschaffen werden, die die Einhaltung der DSGVO unterstützt. Die tatsächliche Konformität ist stets im konkreten Einsatzkontext zu prüfen.

5.1 Hierarchie der Compliance-Lizenzen

Die Lizenzwahl entscheidet darüber, ob der Verantwortliche die Anforderungen aus Art. 32 DSGVO (Sicherheit) und Art. 25 DSGVO (Datenschutz durch Technik) operativ umsetzen kann.

5.2 Identitätsschutz: Entra ID P1 & P2

Die Identität ist der neue Sicherheits-Perimeter. Die Lizenzierung steuert hier, wie präzise Identitätsrisiken adressiert werden können.

• Entra ID P1: Die fachliche Mindestschwelle für Conditional Access (CA). Ohne P1 ist eine kontextabhängige Zugriffskontrolle (z. B. IP-Einschränkungen, MFA-Erzwingung bei Anmeldung) kaum möglich.
• Entra ID P2: Erforderlich für risikobasierte Steuerung und Privileged Identity Management (PIM). Für Berufsgeheimnisträger oder Umgebungen mit hohen Privilegierungsschutzanforderungen ist P2 der notwendige Standard für die Auditierung von Admin-Zugriffen.

5.3 Intune: Gerätetreue und Compliance

Intune ist für das Tenant-Hardening unverzichtbar. Es dient nicht nur dem Device Management, sondern der Erzwingung der Sicherheits-Policies auf Endpunkten. Ohne MDM/MAM lässt sich der Zugriff von mobilen Geräten auf sensible Daten kaum rechtssicher auf „konforme Geräte“ beschränken. Business Premium und E3/E5 bilden hier die technologische Grenze zwischen „offenem System“ und „kontrolliertem Tenant“.

5.4 Microsoft Purview: Der Compliance-Motor

Ein häufiger Irrtum in der Praxis ist die Annahme, Purview sei exklusiv E5-Nutzern vorbehalten. Die Realität ist eine funktionale Abstufung:

• Basis-Funktionen: Manuelle Sensitivity Labels, grundlegende Retention-Policies und Basis-DLP sind oft schon in E3- oder Business-Premium-Plänen enthalten.
• Hochschutz-Funktionen: Erst in der Purview-Suite / E5-Klasse werden Funktionen wie Endpoint DLP, Teams-DLP, Information Barrier oder Advanced Audit (mit längerer Vorhaltezeit für Logs) freigeschaltet.

5.5 Customer Lockbox: Kontrolle über den Support

Für Hochschutzbereiche (§ 203 StGB) ist die Customer Lockbox essenziell. Sie überführt Supportzugriffe in einen expliziten, durch den Kunden freigabepflichtigen Prozess.

• Lizenzlage: Verfügbar in E5 oder über Add-ons wie „Microsoft 365 Information Protection and Compliance“.
• Nutzen: Sie eliminiert das Risiko unkontrollierter Zugriffe durch Support-Personal außerhalb des EWR/der EU Data Boundary.

5.6 Strategische Add-on-Logik

Die aktuelle Lizenzarchitektur erlaubt eine gestufte Compliance-Strategie, anstatt pauschal „alle auf E5“ migrieren zu müssen.

1. Baseline setzen: Standardisierung auf Business Premium (SMB) oder M365 E3 (Enterprise).
2. Schutzbedarf identifizieren: Für Benutzergruppen mit Zugriff auf besonders sensible Daten (§ 203 StGB, Personaldaten) gezielte Aufwertung durch Add-ons.
3. Governance-Add-on: Nutzung von „Information Protection and Compliance“ Add-ons, um ohne vollständigen E5-Wechsel spezifische Audit- oder Schutzfunktionen (wie Lockbox) für Teilgruppen zu aktivieren.

Diese Add-on-Strategie ist das effektivste Mittel, um die Kosten-Nutzen-Relation zwischen notwendiger Compliance und technologischer Überdimensionierung zu wahren und gleichzeitig die Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO technisch sauber abzubilden.

Alles klar, ich verstehe. Um die Mastertabelle in ihrer vollen fachlichen Tiefe, wie von dir vorgegeben, präzise und übersichtlich darzustellen, habe ich die Spaltenbezeichnungen und die spezifischen Zuordnungen nochmals exakt auf die von dir gelieferte Struktur ausgerichtet.

Hier ist die Tabelle in der von dir gewünschten, ausführlichen Form:

5.7 Mastertabelle 1: Lizenzkompass für M365-Härtung

Analyse der Lizenzmatrix für die Fachpraxis

Diese Mastertabelle dient als Entscheidungsmatrix für die Konformitätsplanung. Sie verdeutlicht die technische Schwelle, ab der ein Tenant von einem „Produktivitäts-System“ in ein „kontrolliertes Governance-System“ überführt werden kann:

1. Die „Sicherheits-Grundlinie“ (Business Premium / M365 E3): Diese Pläne bilden die essenzielle Basis, da sie die Entra ID P1-Funktionalität für Conditional Access (CA) und die Intune-Integration mitbringen. Ohne diese Funktionen ist eine technisch erzwungene Privacy-Konfiguration (gemäß Art. 25 DSGVO) kaum umsetzbar.
2. Die „Hochschutz-Schwelle“ (Purview / E5): Funktionen wie Audit Premium, Teams-DLP, Endpoint DLP und insbesondere Customer Lockbox stellen die technische Speerspitze dar. Bei sehr hohem Schutzbedarf können zusätzliche technische Maßnahmen erforderlich sein. Die konkrete Auswahl geeigneter Schutzmaßnahmen erfolgt risikobasiert im Rahmen von Art. 32 DSGVO.
3. Governance-Nachweis: Da der HBDI-Bericht explizit auf die Notwendigkeit technischer Nachweisbarkeit abstellt, ist diese Tabelle auch ein Audit-Hilfsmittel. Sie dokumentiert gegenüber Aufsichtsbehörden, dass die Auswahl der Lizenzen zielgerichtet auf Basis der Schutzbedarfsklassen (gemäß Datenklassifizierungsmodell) erfolgt ist und nicht auf rein betriebswirtschaftlichen Erwägungen beruht.

Diese zweite Mastertabelle führt die funktionale Lizenzbetrachtung aus Abschnitt 5.7 konsequent in eine risikoorientierte Kontrolllogik über. Sie ist damit das ideale Werkzeug für Verantwortliche, um die Brücke zwischen der datenschutzrechtlichen Anforderung (DSFA/Risikoanalyse) und der technischen Umsetzung (Lizenzwahl) zu schlagen.

5.8 Mastertabelle 2: Kontrollklassen, Mindestlizenz, empfohlene Lizenz, Add-on-Pfad

Diese Tabelle operationalisiert die Lizenzarchitektur durch die Zuordnung zu konkreten Kontrollklassen, die für die datenschutzrechtliche Rechenschaftspflicht (Art. 5 Abs. 2 DSGVO) von zentraler Bedeutung sind.

Analyse der Kontrollklassen für die Compliance-Praxis

Diese Matrix ermöglicht eine risikobasierte Lizenzsteuerung, die über das reine „Einkaufsmodell“ hinausgeht:

• Fundamentale Kontrollen (Mindeststandard): MFA, Conditional Access und Geräte-Compliance bilden das absolut notwendige Fundament. Ohne diese Kontrollen ist ein datenschutzkonformer Betrieb in der Cloud aus heutiger Sicht faktisch nicht haltbar, da die Identität der einzige Schutzmechanismus bleibt, sobald Daten das Unternehmensnetzwerk verlassen.
• Zentrale Compliance-Steuerung: Sensitivity Labels und DLP sind die operativen Werkzeuge, um den Grundsatz der Zweckbindung und Datenminimierung (Art. 5 DSGVO) innerhalb der M365-Workloads technisch zu erzwingen. Die Klassifizierung ist hierbei der entscheidende Hebel, um die Sensitivität der Daten gegen die Zugriffsrechte abzugleichen.
• Hochschutz-Modul (Der „Berufsgeheimnisträger-Pfad“): Kontrollen wie Customer Lockbox, Audit Premium und Endpoint DLP sind als Modul zu verstehen. Sie müssen nicht flächendeckend für alle Nutzer aktiviert werden, sondern sind gezielt für Nutzergruppen mit hohem Schutzbedarf (z.B. Rechtsabteilungen, HR, Berufsgeheimnisträger nach § 203 StGB) durch die entsprechenden Add-on-Pfade zu ergänzen.

6.1 EU Data Boundary und Datenlokation

Die EU Data Boundary (EUDB) markiert einen Paradigmenwechsel in der Cloud-Architektur, ist jedoch kein rechtlicher „Blankoscheck“. Sie reduziert das strukturelle Risiko der Drittlandübermittlung massiv, befreit den Verantwortlichen aber nicht von seiner Prüfungspflicht (Art. 44 ff. DSGVO).

Die operative Differenzierung der Datenströme

Für die technische Härtung ist die Unterscheidung zwischen dem produktiven Datenfluss und den funktionalen Hintergrundprozessen kritisch:

Wichtiger Hinweis: Die EUDB eliminiert nicht die Notwendigkeit, Support-Szenarien oder Sicherheits-Telemetrie gesondert zu bewerten. Ein „datenschutzfähiger Tenant“ muss diese Szenarien explizit in seiner Risikoanalyse (DSFA) behandeln.

Strategien zur Reduktion von Übermittlungsrisiken

Um die Compliance-Anforderungen des HBDI operativ zu erfüllen, sollte ein Tenant-Hardening-Plan die folgenden Schritte zwingend enthalten:

1. Workload-Mapping: Dokumentation, welche M365-Workloads unter der EUDB stehen und welche spezifischen Datentypen (z. B. Metadaten) global verarbeitet werden.
2. Support-Governance: Etablierung eines Prozesses, der sicherstellt, dass Support-Tickets datensparsam erstellt werden (keine personenbezogenen Daten in Klartext in Ticket-Anhängen).
3. Technische Barrieren: Einsatz von Customer Lockbox bei hochsensiblen Daten, um den Zugriff durch Support-Personal technisch auf explizite, temporäre Freigaben zu beschränken.
4. Operationalisierung: Integration dieser Anforderungen in interne Runbooks und Incident-Prozesse. Datenschutz ist kein statisches Dokument, sondern Teil der täglichen Betriebsführung.

Die Dokumentationsarchitektur als Nachweis

Ein datenschutzfähiger Tenant dokumentiert seine Lokationsannahmen nicht nur abstrakt, sondern verknüpft sie mit der tatsächlichen technischen Konfiguration:

• Soll-Konfiguration: Festlegung, welche Regionen für neue Datenstände zugelassen sind.
• Transparenz: Nachweis für Betroffene (Datenschutzerklärung), welche Drittlandübermittlungen technisch notwendig sind (z. B. für Sicherheitsdienste).
• Risikominimierung: Dokumentation der ergänzenden Maßnahmen (z. B. Verschlüsselungskonzepte wie DKE), falls trotz EUDB ein Zugriff durch Dritte (z. B. durch Support-Personal) aus Drittstaaten nicht technisch ausgeschlossen werden kann.

Fazit für die Tenant-Härtung

Die HBDI-Handlungsempfehlungen sind als operatives Pflichtprogramm zu verstehen. Die EUDB dient hierbei als „Sicherheitsgurt“ – sie fängt den Großteil der Übermittlungsrisiken ab, doch die „Steuerung“ des Tenants (wer greift wann, wo und wie auf Daten zu) verbleibt beim Verantwortlichen. In sensiblen Umgebungen – insbesondere für Berufsgeheimnisträger – muss diese Steuerung technisch (z. B. durch Verschlüsselung mit eigener Schlüsselhoheit) so ausgeprägt sein, dass ein Zugriff außerhalb der EU technisch wirkungslos bleibt.

6.2 Support-Zugriffe und Zugriffskontrollmodell

Der Support-Prozess stellt in der Cloud-Architektur ein signifikantes datenschutzrechtliches Risikopotenzial dar. Der HBDI hebt daher die Customer Lockbox als zentrales technisches Instrument hervor, um das Kontrollverhältnis zwischen Kunde und Anbieter neu zu justieren.

Der Support-Prozess als Kontrollobjekt

Die Customer Lockbox transformiert den Support-Zugriff von einer rein vertraglichen Zusicherung (DPA) in einen technisch erzwingbaren Freigabeprozess. Dies ist für die Compliance-Architektur von entscheidender Bedeutung:

Governance-Regeln für Supportzugriffe

Da Supportzugriffe eine Ausnahme vom Grundsatz der strikten Datentrennung darstellen, ist eine restriktive Governance-Struktur zwingend. Ein datenschutzfähiger Tenant sollte folgende Regeln operativ implementieren:

• Strikte Trennung: Support-Freigaben dürfen nicht als „Standard-Admin-Recht“ vergeben werden. Sie unterliegen einer gesonderten Rechtehierarchie.
• Vier-Augen-Prinzip: Die Freigabe eines Support-Zugriffs via Lockbox sollte im Unternehmen nicht durch den IT-Admin allein, sondern idealerweise in Abstimmung mit dem Datenschutzbeauftragten oder einer explizit autorisierten Person erfolgen.
• Zweckbindung: Vor jeder Freigabe muss der Kontext des Support-Falls dokumentiert werden: Welche Workloads (Exchange, SharePoint, Teams) sind betroffen? Welche Datenkategorien (personenbezogen, vertraulich, Berufsgeheimnis) könnten eingesehen werden?
• Ausschluss-Kriterien: Automatisierte Prozesse wie Schadsoftware-Scans oder Indexierungen unterliegen nicht der Lockbox-Freigabe; dies muss in der Risikoanalyse (DSFA) als „technisch notwendiges Restrisiko“ explizit als solches dokumentiert werden.

Operative Einbettung in die Tenant-Härtung

Für Berufsgeheimnisträger und hochsensible Umgebungen ist die Customer Lockbox kein optionales „Premium-Feature“, sondern Bestandteil des Standard-Zielbilds.

Praxishinweis: Die Architektur muss sicherstellen, dass auch bei einem Ausfall des primären Admins (Urlaub/Krankheit) der Support-Freigabeprozess über einen definierten Notfallplan (Notfall-Admins, Fire-Glass-Verfahren) sichergestellt ist, ohne die datenschutzrechtlichen Schutzschichten aufzuheben.

Implementierungs-Checkliste für den Support-Prozess:

1. Benennung eines Freigabekreises: Wer im Unternehmen ist berechtigt, Customer-Lockbox-Anfragen zu genehmigen? (Rollen-Modell!)
2. Support-Runbook: Erstellung eines kurzen Leitfadens für IT-Mitarbeiter: Was ist bei der Erstellung von Support-Tickets zu beachten (Minimierung personenbezogener Daten)?
3. Audit-Review: Regelmäßige (z.B. quartalsweise) Auswertung der Lockbox-Audit-Logs zur Dokumentation gegenüber der Aufsichtsbehörde.
4. Lizenz-Alignment: Sicherstellung, dass für alle kritischen Workloads (Exchange, SharePoint, Teams) die notwendigen Lizenzvoraussetzungen (M365 E5 oder entsprechende Add-ons) vorliegen.

Integration in die Dokumentationslage

Die Handhabung von Support-Zugriffen muss zwingend Teil des VVT (Verzeichnis von Verarbeitungstätigkeiten) und der DSFA sein. Es genügt nicht, die Funktion technisch zu aktivieren; die Aufsichtsbehörde prüft, ob das Unternehmen in der Lage ist, im Falle eines „Lockbox-Events“ den Vorfall fachgerecht zu bewerten, zu genehmigen und abschließend zu protokollieren.

6.3 Deaktivierung von Self-Service Purchases

Self-Service Purchases (SSP) und Self-Service Trials (SST) stellen für die datenschutzrechtliche Governance eine erhebliche Schwachstelle dar. Während der Einkaufsvorgang selbst meistens legitim ist, unterläuft er die für eine datenschutzkonforme Infrastruktur notwendige zentrale Steuerung.

Die rechtliche Einordnung: Kontrolle als Kern der Verantwortlichkeit

Die Deaktivierung dieser Funktionen ist unmittelbar aus den Art. 24, 25 und 32 DSGVO ableitbar. Ein Verantwortlicher, der die Kontrolle darüber verliert, welche Anwendungen in seinem Tenant verarbeitet werden, verletzt seine Pflicht zur Gewährleistung des Datenschutzes durch Technik (Privacy by Design) und zur Sicherheit der Verarbeitung:

• Schatten-IT: Dienste gelangen in die Umgebung, ohne dass eine Datenschutzprüfung (DSFA), eine Konfigurationskontrolle oder eine Aufnahme in das Verzeichnis von Verarbeitungstätigkeiten (VVT) stattgefunden hat.
• Governance-Lücke: Die technischen Baselines und Compliance-Policies (z. B. DLP, Sensitivity Labels) können auf ungeprüfte Dienste nicht konsistent angewendet werden.
• Dokumentationsverlust: Da die IT-Administration keine Kenntnis über die Aktivierung hat, bleiben notwendige Datenschutzhinweise oder Löschkonzepte unberücksichtigt.

Operative Härtung: Das Kontrollmodell

Microsoft stellt im Microsoft 365 Admin Center unter Settings > Org settings > Services > Self-service trials and purchases die notwendigen Werkzeuge bereit, um diesen Prozess zu unterbinden. Eine datenschutzfähige Härtung sollte hierbei kein „Einmal-Projekt“ sein, sondern einen kontinuierlichen Prozess darstellen:

Implementierung als Teil der Governance

Die Deaktivierung von SSP/SST ist ein zentraler Baustein des Governance-Modells (siehe Abschnitt 4.1). Ohne diesen Schritt ist das Tenant-Management „blind“ gegenüber neuen Datenströmen.

Wichtiger Hinweis für die Praxis: Die Deaktivierung muss produktbezogen im Admin Center erfolgen. Da Microsoft regelmäßig neue Funktionen und Produktlinien in M365 integriert, sollte die administrative Anweisung für die IT-Abteilung lauten, bei jedem neuen Microsoft-Service-Rollout zu prüfen, ob entsprechende Self-Service-Rechte aktiviert oder deaktiviert werden müssen.

Fazit für die Rechenschaftspflicht

Die Kontrolle über das „Software-Portfolio“ innerhalb des Tenants ist eine Grundvoraussetzung für die Erfüllung der Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO. Ein Verantwortlicher kann nicht behaupten, er habe „die Kontrolle über die Datenverarbeitung“, wenn er nicht einmal weiß, welche Applikationen in seiner Infrastruktur lizenziert und in Betrieb genommen wurden. Die konsequente Deaktivierung von SSP/SST ist daher eine der am einfachsten umsetzbaren, aber wirkungsvollsten Maßnahmen zur sofortigen Steigerung des Datenschutzniveaus im M365-Tenant.

6.4 App-Consent-Governance

Die App-Consent-Governance ist eine der kritischsten, aber oft am stärksten unterschätzten Sicherheits- und Compliance-Schwachstellen in Microsoft-365-Umgebungen. Sie entscheidet darüber, ob Drittanwendungen (Third-Party Apps) Zugriff auf unternehmenskritische Daten wie E-Mails, Chats, Dateien oder das Verzeichnis erhalten – oft ohne, dass die IT-Administration dies aktiv steuern oder auch nur einsehen kann.

Das Risiko: Schatten-Integration via OAuth

Ein Benutzer, der einer Drittanwendung Berechtigungen erteilt, schafft eine dauerhafte „Backdoor“ in sein Konto. Dies erfolgt meist über OAuth-Tokens, die es der App erlauben, im Namen des Benutzers zu agieren – unabhängig vom eigentlichen Benutzer-Login.

Rechtliche Einordnung: Warum Consent-Governance zwingend ist

Die Steuerung von App-Berechtigungen ist keine IT-Spielerei, sondern eine direkte Folge aus den Grundprinzipien der DSGVO:

• Art. 25 DSGVO (Privacy by Design/Default): Standardeinstellungen dürfen nicht zulassen, dass ein Anwender Zugriffsberechtigungen erteilt, die der Sicherheit der verarbeiteten personenbezogenen Daten entgegenstehen.
• Art. 32 DSGVO (Sicherheit der Verarbeitung): Der Zugriff durch Drittanwendungen muss technisch kontrolliert und auf das notwendige Maß begrenzt werden.
• Art. 5 Abs. 1 lit. c DSGVO (Datenminimierung): Die Berechtigungsketten müssen das Prinzip der Datensparsamkeit wahren. Eine App darf keine weitergehenden Rechte besitzen, als für den spezifischen Zweck erforderlich.

Das operative Architekturmodell: „Zero-Trust“ für Apps

Um eine datenschutzrechtlich verteidigungsfähige Umgebung zu schaffen, muss das Modell von einer „Offenen Freigabe“ zu einem „Kontrollierten Workflow“ migriert werden.

Operative Umsetzungsschritte

1. Blocking & Scoping: In Microsoft Entra (Azure AD) sollte die Option „Benutzer können App-Berechtigungen erteilen“ für alle Benutzer deaktiviert oder zumindest auf Anwendungen mit geringem Risiko (z. B. Publisher mit verifiziertem Herausgeber) beschränkt werden.
2. Implementierung des Admin Consent Workflows: Die Einrichtung eines offiziellen Prozesses im Entra Admin Center ist für die Rechenschaftspflicht entscheidend. Anträge von Anwendern werden so dokumentiert und von IT-Administratoren geprüft, bevor sie wirksam werden.
3. Audit der Bestandssituation: Mittels der „Enterprise Applications“-Ansicht in Microsoft Entra müssen regelmäßig alle App-Berechtigungen inventarisiert werden. Apps, die nicht mehr aktiv genutzt werden oder zu weit gefasste Berechtigungen (wie offline_access oder weitreichende Directory-Zugriffe) besitzen, müssen entfernt oder eingeschränkt werden.
4. Überwachung von Hochrisiko-Berechtigungen: Besonders Berechtigungen, die den Zugriff auf das gesamte Postfach (Mail.Read), den gesamten Fileserver (Files.Read.All) oder das gesamte Benutzerverzeichnis (User.ReadBasic.All) ermöglichen, müssen einer gesonderten, strengeren Prüfung unterliegen.

Dokumentations-Tipp: Nehmen Sie das Konzept der App-Consent-Governance explizit in Ihre DSFA auf. Es ist der direkteste Nachweis für eine Aufsichtsbehörde, dass Sie die Kontrolle über die Datenweitergabe an Drittanbieter (als Auftragsverarbeiter oder eigenständige Verantwortliche) aktiv ausüben.

Fazit

Eine restriktive App-Consent-Governance transformiert den Tenant von einer offenen Umgebung, in der jeder Nutzer unbeabsichtigt Daten an externe Dienste abfließen lassen kann, zu einer kontrollierten Plattform. Dies ist eine der effektivsten Maßnahmen gegen die ungewollte Exfiltration von Daten und eine Kernanforderung für die Einhaltung der Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO.

6.5 Reporting-Datenschutz

Die Nutzung von Microsoft 365 Reporting-Funktionen ist ein oft unterschätzter datenschutzrechtlicher Hebel. Während IT-Administratoren primär die Systemauslastung und Lizenznutzung im Blick haben, enthalten diese Reports hochgradig personenbezogene Verhaltens- und Leistungsdaten. Ohne entsprechende Härtung werden Mitarbeiterdaten in diesen Berichten standardmäßig im Klartext angezeigt, was ohne arbeitsrechtliche Flankierung oder technische Anonymisierung ein massives Risiko darstellt.

Die rechtliche und regulatorische Dimension

Das Risiko im Bereich Reporting ist doppelt gelagert:

1. Datenschutzrecht (DSGVO): Die Verarbeitung von Nutzer- und Aktivitätsdaten muss dem Grundsatz der Datenminimierung (Art. 5 Abs. 1 lit. c DSGVO) folgen. Die Sichtbarkeit von Benutzernamen, Gruppenmitgliedschaften und Website-Besuchen in Reports stellt eine zusätzliche Verarbeitung dar, die für den reinen IT-Betrieb oft nicht erforderlich ist.
2. Arbeitsrecht: Die Analyse von M365-Nutzungsdaten kann (auch unbeabsichtigt) als Verhaltenskontrolle oder Leistungsmessung interpretiert werden. Hier greifen die Mitbestimmungsrechte von Betriebsräten sowie das allgemeine Persönlichkeitsrecht der Beschäftigten.

Technische Härtung im Admin Center

Microsoft stellt unter Settings > Org Settings > Services > Reports eine zentrale Steuerung bereit. Die Aktivierung der Funktion „Display concealed user, group, and site names in all reports“ ist eine essenzielle Konfigurationsvorgabe für jeden Tenant, der nicht explizit für Analysen der Nutzeraktivität vorgesehen ist.

Governance-Leitplanken für datenschutzfähige Reports

Ein datenschutzfähiger Tenant sollte diese technische Härtung zwingend durch organisatorische Maßnahmen flankieren:

• Zweckbindung und Rollenkonzept: Wer darf auf Reports mit (gelegentlich) sichtbaren Personenbezügen zugreifen? Diese Zugriffsrechte müssen dokumentiert und auf einen minimalen Personenkreis (z. B. IT-Security) beschränkt werden.
• Arbeitsrechtliche Flankierung: Die Nutzung von Nutzungsdaten sollte durch eine Betriebsvereinbarung oder eine interne Arbeitsanweisung geregelt sein. Diese sollte explizit untersagen, dass aus den Daten Verhaltens- oder Leistungsprofile erstellt werden.
• Schwellwertanalyse: In Anlehnung an das M365-Kit sollte jede Form der Reporting-Aktivierung, bei der Personenbezüge sichtbar gemacht werden, eine Schwellwertanalyse durchlaufen, um zu dokumentieren, warum die Anonymisierung für den spezifischen Zweck nicht ausreicht.

Fazit für die Tenant-Härtung

Die Anonymisierung der Reports ist kein „Nice-to-have“, sondern eine „Privacy-by-Default“-Maßnahme gemäß Art. 25 DSGVO. Sie reduziert das Konfliktpotenzial mit Betriebsräten und Aufsichtsbehörden auf ein Minimum, ohne die Stabilität und Wartung des Systems zu gefährden. Für die tägliche Administration sollte das Prinzip gelten: Anonymität als Standard, Klarnamen als Ausnahme mit Dokumentationspflicht.

6.6 Telemetrie-Minimierung auf Tenant-Ebene

Die Telemetrie-Steuerung in Microsoft 365 ist kein reiner IT-Betriebsparameter, sondern ein wesentlicher Bestandteil der Datenschutz-Folgenabschätzung (DSFA). Diagnosedaten, Dienstmetadaten und Connected Experiences sind datenschutzrechtlich als eigenständige Verarbeitungsvorgänge zu qualifizieren, die explizit in das Verzeichnis der Verarbeitungstätigkeiten (VVT) aufzunehmen sind.

Die Dimensionen der Telemetrie

In einem M365-Tenant existieren unterschiedliche Datenströme, die als Telemetrie oder Diagnosedaten eingeordnet werden müssen:

Rechtliche Einordnung: Telemetrie als Verarbeitung

Der HBDI stellt klar, dass Telemetriedaten nicht als „bloße Nebensache“ zu betrachten sind. Da Microsoft diese Daten zur Produktoptimierung und zum globalen Sicherheits-Monitoring verwendet, müssen Verantwortliche:

1. Einordnung als Verarbeitung: Die Übermittlung von Diagnosedaten muss im VVT unter einem eigenen Szenario (z. B. „Produktstabilität und Verbesserung“) dokumentiert sein.
2. Rechtsgrundlage: Es muss geprüft werden, ob diese Übermittlung durch berechtigte Interessen (Art. 6 Abs. 1 lit. f DSGVO) gedeckt ist oder ob sie einwilligungsbedürftig ist.
3. Transparenz: Betroffene (Nutzer) müssen über die Art der erhobenen Daten in der Datenschutzerklärung informiert werden.

Operative Härtungsmaßnahmen

Ein datenschutzfähiger Tenant sollte die Telemetrie-Minimierung konsequent über alle Ebenen – vom Client bis zum Tenant – steuern:

• Client-Ebene (Microsoft 365 Apps): Über Gruppenrichtlinien (GPO) oder Intune-Konfigurationsprofile ist der Umfang der Diagnosedaten auf das erforderliche Minimum zu begrenzen. Optionale Telemetrie („Optional Diagnostic Data“) sollte in produktiven Umgebungen standardmäßig deaktiviert werden.
• Service-Ebene: In den Organization Settings des M365 Admin Centers sind „Connected Experiences“ zu prüfen. Dienste, die für den geschäftlichen Kernbetrieb nicht erforderlich sind, sollten deaktivert werden, um unnötige Datenflüsse zu vermeiden.
• Cloud-Policy-Service: Nutzen Sie diesen Service, um zentralisierte Datenschutz-Policies auf alle Office-Installationen auszurollen. Dies stellt sicher, dass die Konfiguration nicht individuell durch Nutzer auf Endgeräten aufgeweicht wird.

Telemetrie-Minimierung als Standardbetrieb

Die Dokumentation im M365-Kit unterstreicht: Telemetrie-Minimierung ist Teil des Standardbetriebs.

Praxis-Empfehlung: Eine datenschutzfähige Architektur erzwingt die Minimierung technisch (durch Richtlinien), nicht nur durch interne Anweisungen. Ein Tenant, in dem jeder Nutzer per Mausklick optionale Diagnosedaten aktivieren kann, erfüllt die Anforderungen an „Privacy by Design“ (Art. 25 DSGVO) in hochsensiblen Umgebungen nicht.

Durch die konsequente Begrenzung der Telemetrie auf das absolut notwendige Maß reduzieren Sie nicht nur das Datenvolumen, sondern auch die Drittlandübermittlungsszenarien, die für die globale Verarbeitung von Diagnosedaten bei Microsoft typisch sind. Dies entlastet die DSFA maßgeblich, da weniger Datenströme detailliert auf ihr Übermittlungsrisiko hin geprüft und dokumentiert werden müssen.

6.7 Mastertabelle: Tenant-Governance-Kontrollen

7.1 MFA-Strategie: Die Pflicht für jeden Zugriff

Multifaktor-Authentisierung (MFA) ist der Mindeststandard. Ein Passwort allein bietet heute keinen Schutz mehr gegen automatisierte Angriffe.

• Flächendeckende MFA: Jeder Benutzer – vom Praktikanten bis zum Geschäftsführer – muss sich per MFA (z. B. Microsoft Authenticator App oder FIDO2-Token) anmelden.
• Ausschluss unsicherer Methoden: Klassische SMS-Codes oder Anrufe für MFA sind aufgrund von „SIM-Swapping“-Risiken zu deaktivieren.
• Phishing-resistente MFA für Admins: Personen mit Administratorrechten müssen zwingend Verfahren nutzen, die nicht durch Phishing-Seiten abgefangen werden können (z. B. FIDO2-Sicherheitsschlüssel oder Windows Hello for Business).
• Notfall-Konten (Break-Glass): Einrichtung von mindestens zwei administrativen Konten, die von allen automatisierten MFA-Richtlinien ausgenommen sind, jedoch mit extrem komplexen Passwörtern und physischen FIDO2-Tokens gesichert werden. Diese Konten dürfen nicht für das Tagesgeschäft verwendet werden.

7.2 Regeln für den Zugriff (Was, Wann, Wo)

Statt auf starre Richtlinien zu setzen, werden konkrete Bedingungen definiert, unter denen ein Zugriff erlaubt oder verboten wird. Diese Regeln werden zentral in Microsoft Entra festgelegt:

• Regel: Admin-Zugriff nur mit hohem Sicherheitsstandard: Wer administrative Aufgaben im Tenant wahrnimmt, darf dies nur, wenn MFA genutzt wird und das verwendete Gerät als „firmeneigen und konform“ markiert ist.
• Regel: Schutz sensibler Unternehmensdaten: Der Zugriff auf Dokumente mit der Klassifizierung „Vertraulich“ ist nur von Geräten möglich, die einen aktuellen Virenscanner und eine verschlüsselte Festplatte (BitLocker) vorweisen.
• Regel: Standort-Check: Zugriffe aus geographischen Regionen, in denen das Unternehmen keine Standorte hat, werden automatisch blockiert.
• Regel: Legacy-Auth-Block: Protokolle wie POP3, IMAP oder SMTP-Auth, die kein MFA unterstützen, werden tenantweit deaktiviert.

7.3 Sonderrechte für Admins: PIM („Just-in-Time“-Rechte)

Dauerhafte Admin-Rechte („Global Admin“) sind ein massives Compliance-Risiko. Privileged Identity Management (PIM) minimiert diese Risiken:

• Keine Dauerrechte: Ein Admin hat im Normalfall keine erweiterten Rechte. Er ist ein normaler Benutzer.
• Rechte auf Abruf (Just-in-Time): Wenn ein Admin eine Aufgabe erledigen muss, beantragt er die Rolle über das Portal.
• Vier-Augen-Prinzip: Kritische Rollen werden nur nach einer Genehmigung durch einen zweiten berechtigten Administrator freigeschaltet.
• Zeitliche Befristung: Sobald die Aufgabe erledigt ist (maximal z. B. 4 Stunden), entzieht das System die Admin-Rechte automatisch wieder.
• Protokollierung: Jeder Zugriff wird lückenlos aufgezeichnet – wer hat wann warum welche Rechte aktiviert?

7.4 Geräte-Sicherheit und Endpoint-Trust

Identität ist nur ein Teil der Wahrheit. Wenn der Benutzer zwar korrekt ist, das Gerät aber mit Schadsoftware infiziert ist, sind die Daten in Gefahr.

• Geräte-Check: Bevor ein Zugriff gewährt wird, prüft Microsoft Intune: Ist das Betriebssystem aktuell? Ist der Virenscanner aktiv? Ist der Zugriff von einem privaten oder einem geschäftlichen Gerät erfolgt?
• Compliance-Status: Nur Geräte, die alle definierten Sicherheitsregeln erfüllen, erhalten den Status „Konform“.
• Blockade bei Nicht-Konformität: Erfüllt ein Gerät die Bedingungen nicht (z. B. Windows-Update verweigert), verweigert das System den Zugriff auf SharePoint oder Outlook, bis das Gerät repariert wurde.

7.5 Legacy-Auth-Blockierung

Alte Anmeldewege (POP3, IMAP, SMTP-Auth) sind der häufigste Grund für erfolgreiche Angriffe, da diese Protokolle die moderne MFA-Abfrage gar nicht erst anfordern können.

• Hardening-Schritt: Die komplette Blockierung dieser Protokolle ist eine der wirkungsvollsten Maßnahmen. Ein Tenant, der diese Protokolle noch zulässt, ist nach heutigem Standard nicht „datenschutzkonform“ im Sinne von Art. 32 DSGVO, da er ein bekanntes Einfallstor offen lässt.

Fazit für die Dokumentation

Diese fünf Schichten bilden das Fundament der technischen Sicherheit. Für die Rechenschaftspflicht gegenüber dem HBDI oder anderen Aufsichtsbehörden dokumentiert die Organisation diesen Aufbau als ihre „Technisch-Organisatorischen Maßnahmen“ (TOMs). Die Kombination aus Identitätsprüfung (MFA/CA) und Endgerätekontrolle (Intune) belegt, dass der Zugriff auf personenbezogene Daten aktiv und nach dem Stand der Technik gesteuert wird.

Nächster Schritt: Möchtest du im nächsten Abschnitt die Datenklassifizierung (Sensitivity Labels) behandeln, damit Dateien auch außerhalb des Tenants geschützt bleiben?

7.6 Mastertabelle: Identity-Hardening

8.1 Diagnosedaten-Level

Die Steuerung von Diagnosedaten ist kein Komfortfeature, sondern eine datenschutzrechtlich eigenständige Verarbeitung. Das Zielbild ist die strikte Minimierung auf die für den Betrieb zwingend notwendigen Informationen.

• Required Diagnostic Data: Nur diese Daten (z. B. Informationen über Systemstabilität, erfolgreiche Installationen) sind für den Betrieb des Tenants zulässig.
• Optional Diagnostic Data: Diese Daten (z. B. wie Features genutzt werden, detaillierte Fehlerprotokolle) müssen standardmäßig deaktiviert sein.
• Administrative Steuerung: Über den Cloud Policy Service oder Gruppenrichtlinien (GPO) wird ein verbindlicher Standard für alle Clients erzwungen, der durch Nutzer nicht änderbar ist.

8.2 Connected Experiences

„Connected Experiences“ sind Funktionen, die Daten aus dem Web nachladen oder mit Cloud-Diensten kommunizieren (z. B. intelligente Dateivorschläge, Wetter-Add-ins in Excel).

• Standard-Regel: Funktionen, die ohne zwingende Notwendigkeit Inhalte nachladen oder analysieren, müssen standardmäßig auf „aus“ stehen.
• Ausnahmen: Sofern geschäftliche Notwendigkeiten für bestimmte Zusatzfunktionen bestehen, sind diese nur nach expliziter Dokumentation in der Schwellwertanalyse (DSFA) zu aktivieren.

8.3 Inhaltsanalyse-Funktionen

KI-gestützte Funktionen wie Übersetzung, Bildsuche oder Designvorschläge sind im Hinblick auf den Schutz sensibler Daten kritisch. Sie verarbeiten Inhalts- und Kontextdaten in Cloud-Prozessen.

8.4 Cloud Policy Service vs. Intune

Ein häufiger Praxisirrtum ist die Annahme, dass eine umfassende Geräteverwaltung (Intune) zwingend erforderlich ist, um Office-Datenschutzrichtlinien umzusetzen.

• Cloud Policy Service: Für die reine Umsetzung von Privacy-Policies ist der Cloud Policy Service oder eine klassische GPO (Gruppenrichtlinie) völlig ausreichend.
• Wann ist Intune notwendig? Wenn Office-Richtlinien mit dem Compliance-Status des Endgeräts (z. B. BitLocker-Verschlüsselung) verknüpft werden sollen, ist Intune die logische Wahl. Für die bloße Steuerung der Telemetrie ist es nicht die einzige, aber oft die bequemste Option.

8.5 OneDrive-Client-Telemetrie

OneDrive synchronisiert Daten lokal auf das Endgerät. Damit erweitert sich das Risiko von der reinen Cloud-Speicherung hin zum lokalen Endgerät (lokaler Cache, Offline-Verfügbarkeit).

• Sync-Governance: OneDrive-Synchronisation ist nicht neutral. Für Hochschutzbereiche (Berufsgeheimnisse) ist die lokale Synchronisation zu unterbinden, sodass Daten ausschließlich im Browser bearbeitet werden (Web-only Access).
• Gerätebindung: Der Sync-Client muss über Conditional-Access-Regeln zwingend an einen „Trusted Device Context“ gebunden sein.
• Datenabfluss: Die lokale Speicherung durch den Sync-Client muss in der DLP-Strategie (Data Loss Prevention) berücksichtigt werden, da Daten das kontrollierte Cloud-Umfeld in den lokalen Dateisystem-Bereich verlassen.

Zwischenfazit

Datenschutz im Office-Client bedeutet, die „Telemetrie-Freude“ der Standardeinstellungen durch administrative Leitplanken zu ersetzen. Durch die Nutzung des Cloud Policy Service lässt sich dies für alle M365-Apps-Pläne effizient umsetzen. Entscheidend ist, dass die gewählten Einstellungen nicht als „Einmal-Konfiguration“ verstanden werden, sondern als fester Bestandteil des VVT-Workload-Mappings und der Schwellwertanalyse.

8.6 Mastertabelle: Office-Privacy-Hardening

9.1 SharePoint und OneDrive als Datenspeicher

SharePoint und OneDrive sind nicht nur Dateiablagen, sondern hochgradig dynamische Kollaborationsumgebungen. Die Risiken liegen hier in der langfristigen Persistenz, Versionierung, komplexen Freigabeketten und der automatischen Suchindizierung.

Relevante DSGVO-Anforderungen:

• Art. 5 Abs. 1 lit. c (Datenminimierung): Begrenzung der Freigabeweite.
• Art. 25 (Privacy by Design): Standardkonfigurationen, die das Risiko minimieren.
• Art. 32 (Sicherheit): Zugriffsschutz und Schutz vor Exfiltration.
• Art. 5 Abs. 1 lit. e (Speicherbegrenzung): Löschlogik und Lifecycle-Management.

9.2 Externes Teilen: Das „Wie eng“-Prinzip

Die Standardeinstellungen für externe Freigaben sind oft der Ursprung für unkontrollierte Datenabflüsse. Ein belastbares Härtungsmodell basiert auf einer klaren Differenzierung der Zusammenarbeit.

Grundregel: Anonyme „Anyone-Links“ (jeder mit dem Link hat Zugriff) sind in einer datenschutzkonformen Umgebung der Standard-Block-Kandidat.

9.3 Standard-Linktyp: Die Macht des UI-Defaults

Anwender folgen bei der Dateifreigabe fast immer dem voreingestellten Dialog. Ein zu offener Standard-Linktyp führt strukturell zu einer zu weiten Offenlegung von Informationen.

• Administrativ zu setzen: Als Standard für das Link-Verhalten ist „People in your organization“ oder (falls erforderlich) „Specific people“ zu konfigurieren.
• Vermeidung: Die Option „Anyone with the link“ darf unter keinen Umständen als Standard definiert sein.

9.4 Sensibilität durch Labels (Sensitivity Labels)

Die manuelle oder automatische Anwendung von Sensitivity Labels ist die technische Brücke zwischen Klassifizierung und IT-Sicherheit.

• Taxonomie als Basis: Definition einer klaren Struktur (Intern, Vertraulich, Personenbezogen, Personal/HR, Berufsgeheimnis).
• Technisches Enforcement: Labels dienen als Grundlage für DLP-Richtlinien. Ein Dokument, das als „Personal“ gelabelt ist, kann so automatisch für externe Freigaben gesperrt werden.
• Sichtbarkeit: Labels machen dem Anwender den Schutzbedarf visuell bewusst (Klassifizierungs-Banner).

9.5 Zugriff nur von konformen Geräten

Der Identitätsschutz reicht nicht aus, wenn ein kompromittiertes oder ungeschütztes Endgerät auf sensible Daten zugreift.

• Compliance-Check: Über Conditional Access wird der Zugriff auf SharePoint/OneDrive an den Status „konform“ (Managed Device) gekoppelt.
• Download-Restriktionen: Für Hochschutzbereiche kann der Zugriff über den Browser („Web-only“) erzwungen werden, wodurch Downloads oder lokale Synchronisationen (Sync-Client) technisch verhindert werden.

9.6 OneDrive: Mehr als eine „persönliche Ablage“

OneDrive ist hochgradig mit dem lokalen Betriebssystem und Office-Clients integriert. Das bedeutet, dass OneDrive-Inhalte oft lokal auf Endgeräten in Caches oder durch Synchronisation persistent werden.

Notwendige Prüfpunkte für die Workload-Härtung:

1. Synchronisation: Für besonders sensible Daten ist die lokale Synchronisation zu unterbinden.
2. Standard-Speicher: Festlegung, welche Datenklassen in OneDrive (persönlich) und welche in SharePoint (Team/Organisation) abgelegt werden dürfen.
3. DLP-Abdeckung: Die DLP-Strategie muss zwingend den OneDrive-Sync-Pfad umfassen, um zu verhindern, dass sensible Daten auf unsichere lokale Laufwerke abfließen.

Checkliste: Workload-Härtung SharePoint/OneDrive

• [ ] Externes Teilen: Tenant-weit auf „Existing Guests“ oder restriktiver eingeschränkt.
• [ ] Anyone-Links: Global deaktiviert.
• [ ] Standard-Linktyp: Auf „People in your organization“ gesetzt.
• [ ] Sensitivity Labels: Taxonomie definiert und technisch für Sharepoint/OneDrive aktiv.
• [ ] Geräte-Check: Conditional Access erzwingt „Compliant Devices“ für den Zugriff.
• [ ] Hochschutz-Sites: Externe Freigaben für spezifische Sites explizit untersagt.
• [ ] Synchronisation: Für HR/Recht/Finanzen lokal unterbunden (Browser-Only).

9.2 Microsoft Teams: Der Kollaborations-Datenraum

Microsoft Teams ist kein reines Kommunikationswerkzeug, sondern ein hochkomplexes Ökosystem. Es vereint Kommunikationsplattform, Dateiablage (SharePoint/OneDrive), Kollaborations-Hub, Aufzeichnungsumgebung, Transkriptions-KI sowie Schnittstellen für Drittanbieter-Apps. Diese Funktionsvielfalt macht Teams zu einem der sensibelsten Bereiche innerhalb eines Microsoft-365-Tenants.

9.3 Exchange Online: Der kritische Kommunikationskanal

E-Mail bleibt in vielen Organisationen der sensibelste Einzelkanal für personenbezogene Daten. In Exchange Online laufen Ad-hoc-Kommunikation, Vertragsdaten, HR-Inhalte, Anhänge und externe Kontakte zusammen. Da hier oft unstrukturierte Altbestände liegen, ist Exchange aus datenschutzrechtlicher Sicht nicht nur ein technischer Dienst, sondern ein „risikodichter“ Datenbestand.

9.4 Mastertabellen: Workload-Hardening

10.1 Informationsklassifizierung: Das Fundament des Datenschutzes

Die Informationsklassifizierung mittels Sensitivity Labels ist die notwendige Klammer für alle technischen Schutzmaßnahmen. Ohne eine klare Einordnung, welche Daten welchen Schutzbedarf haben, bleibt die IT-Sicherheit eine „Blackbox“. Klassifizierung schafft die Grundlage dafür, dass DLP-Regeln, Verschlüsselungen und Freigabebeschränkungen überhaupt erst zielgerichtet angewendet werden können.

10.1 Informationsklassifizierung

10.2 Data Loss Prevention (DLP)

10.3 Endpoint DLP

Cloud-DLP endet dort, wo die Daten das kontrollierte Cloud-Umfeld auf das lokale Gerät verlassen. Endpoint DLP (E5/Purview-Suite) ist daher die notwendige Erweiterung für Hochschutzumgebungen gegen:

• Kopieren auf USB-Medien,
• unkontrolliertes Drucken,
• Hochladen in nicht genehmigte Cloud-Dienste,
• Lokale Exfiltration trotz legitimem Benutzerzugriff.
• Wichtig: Aufgrund der Tiefe der Eingriffe ist hier kein Vollflächen-Rollout, sondern ein gestuftes Modell (Pilots für Hochrisikogruppen wie HR/Legal) zu empfehlen.

10.4 Teams-DLP

Kommunikation ist dynamischer als Dateispeicherung. Teams-DLP adressiert:

• Spontane Interaktionen mit externen Teilnehmern,
• Sensible Daten in Chats, die im Nachhinein erst als kritisch erkannt werden.
• Governance-Hinweis: Teams-DLP ist eine Hochschutzfunktion, die bei Fehlkonfiguration schnell die Kommunikation lähmt. Sie ist nur bei klarem Schutzbedarf einzusetzen.

10.5 Audit-Architektur und eDiscovery

Audit bildet die Beweisinfrastruktur und den technischen Unterbau der Rechenschaftspflicht.

• Audit Standard: Flächendeckende Basis (Admin-Änderungen, Zugriffsprotokolle). Ein Tenant ohne dies ist nach heutigen Standards kaum belastbar.
• Audit Premium: Forensische Tiefe (z.B. MailItemsAccessed) für kritische Nutzergruppen.
• eDiscovery: Dient der strukturierten Aufarbeitung bei Datenschutzvorfällen oder internen Untersuchungen. Premium-eDiscovery ist für Organisationen mit hohen Anforderungen an Beweissicherung und komplexe Sammlungsprozesse relevant.

Checkliste: Purview & Compliance-Kontrollen

• [ ] Taxonomie definiert: Erstellung einer verbindlichen Label-Struktur basierend auf dem Schutzbedarf (Öffentlich bis Hochschutz).
• [ ] Definitionen hinterlegt: Zu jedem Label gibt es eine klare fachliche Beschreibung der erlaubten Verarbeitungen.
• [ ] DLP-Basis: Implementierung von DLP-Richtlinien für Exchange und SharePoint zur Erkennung personenbezogener Daten.
• [ ] Endpoint DLP: Pilotierung in Hochrisikobereichen (HR, Rechtsabteilung) zur Absicherung gegen lokale Exfiltration.
• [ ] Teams-DLP: Prüfung des Bedarfs bei externer Kollaboration; Implementierung restriktiver Regeln für Hochrisikoinhalte.
• [ ] Audit-Standard: Flächendeckende Aktivierung des Unified Audit Logs für den gesamten Tenant.
• [ ] Audit-Premium: Lizenzierung und Aktivierung der erweiterten Protokollierung (MailItemsAccessed) für sensible Postfächer.
• [ ] eDiscovery: Etablierung eines Prozesses zur strukturierten Untersuchung/Aufarbeitung von Sicherheitsvorfällen.

10.8 Mastertabellen: Purview-Kontrollen

11.1 Warum Verschlüsselung in M365 datenschutzrechtlich nicht mit „ist standardmäßig an“ erledigt ist

In Microsoft 365 ist Verschlüsselung kein singuläres Feature, sondern ein Schichtenmodell. Microsoft beschreibt für seine Cloud-Dienste eine Kombination aus Verschlüsselung auf Datenträgerebene, dienstseitiger Verschlüsselung und – in bestimmten Szenarien – kundengesteuerten Schlüsseln. Customer Key wird dabei ausdrücklich als zusätzliche Schutzschicht beschrieben, die BitLocker und serverseitige Verschlüsselung ergänzt, indem Kunden die Root Keys auf Anwendungsebene kontrollieren.

Für die Datenschutzpraxis ist das entscheidend, da die Frage nicht nur lautet, ob Daten verschlüsselt sind, sondern wer welchen Teil der Schlüsselkette kontrolliert. Standardverschlüsselung schützt in erster Linie gegen physische und infrastrukturelle Risiken im Rechenzentrum. Sie beantwortet jedoch nicht automatisch die Frage, wie eng Supportzugriffe, administrative Einsichtsmöglichkeiten oder regulatorische Hochschutzanforderungen begrenzt werden können. Deshalb ist „Verschlüsselung vorhanden“ kein ausreichender Prüfvermerk. Erst die Einordnung des verwendeten Schlüsselmodells zeigt, welches Schutzniveau tatsächlich erreicht wird.

Für einen datenschutzfähigen Tenant lassen sich vier Reifestufen unterscheiden:

• Standard-Microsoft-Verschlüsselung: Einsatz von Provider-verwalteten Schlüsseln.
• Customer Key / Customer-Managed Root Keys: Kontrolle der Root-Ebene durch den Kunden.
• Double Key Encryption (DKE): Höchste Stufe mit zweitem Schlüssel unter ausschließlicher Kundenkontrolle.
• Organisatorische Schlüsselhoheit: Einbettung in Lifecycle-, Rollen- und Audit-Prozesse.

Diese Stufung ist essenziell, da nicht jede Organisation automatisch die höchste Stufe benötigt. Für Berufsgeheimnisträger, hochsensible Personaldaten, kritische Behördenverfahren oder streng regulierte Branchen ist die einfache Basisschicht jedoch häufig nicht hinreichend.

11.2 Microsoft-Standardverschlüsselung als Basisschicht

Microsoft dokumentiert, dass Customer Key die vorhandene Basisverschlüsselung ergänzt, nicht ersetzt. Daraus folgt im Umkehrschluss, dass bereits ohne Customer Key mehrere Verschlüsselungsschichten im Microsoft-Betrieb vorhanden sind. Für viele Standard-Verarbeitungen ist diese Basisschicht ein legitimer Ausgangspunkt; sie darf jedoch nicht mit einer vollständigen kundenseitigen Schlüsselhoheit verwechselt werden.

Datenschutzfachlich ist diese Basisschicht als notwendige, aber nicht immer hinreichende Maßnahme einzuordnen. Wer in einer DSFA oder in einem internen Kontrollkatalog lediglich „Daten bei Microsoft verschlüsselt“ vermerkt, ohne zwischen Microsoft-kontrollierter und kundenkontrollierter Schlüsselarchitektur zu unterscheiden, dokumentiert zu oberflächlich. Eine belastbare Bewertung muss mindestens festhalten:

• Welche Verschlüsselungsalgorithmen und -ebenen Microsoft standardmäßig einsetzt.
• Welche Datenarten durch diese Basis verschützt sind.
• Ob zusätzliche kundengesteuerte Schlüssel für spezifische Workloads aktiviert sind.
• Ob hochschutzbedürftige Inhalte eine weitergehende, kryptografische Souveränität erfordern.

11.3 Customer Key: Zusätzliche Schutzschicht mit kundenkontrollierten Root Keys

Microsoft beschreibt Customer Key als eine Customer-Managed-Key-Lösung, bei der Kunden Root Keys bereitstellen, während Microsoft die übrigen Schlüssel der Kette verwaltet. Customer Key ist für Exchange, SharePoint, OneDrive for Business und Windows 365 verfügbar. Microsoft führt aus, dass Kunden damit regulatorische oder Compliance-Anforderungen erfüllen können, da sie die Root-Verschlüsselungsschlüssel auf Anwendungsebene kontrollieren.

Diese Architektur ist für den Datenschutz hoch relevant. Customer Key verändert zwar nicht die grundlegende Betriebsarchitektur, aber es verschiebt einen kritischen Punkt der Kontrolle: Die Root Keys liegen nicht mehr vollständig im alleinigen Einflussbereich von Microsoft. Dies ist besonders bedeutsam, wenn eine Organisation nicht nur Standard-Vertraulichkeit wünscht, sondern dokumentierbare Kontrolle über den Zugang zu Daten im Ruhezustand (at rest) nachweisen muss. Für Art. 32 DSGVO ist dies eine starke zusätzliche Maßnahme; für Kontexte mit Berufsgeheimnissen oder erhöhtem Vertraulichkeitsdruck kann es ein wesentliches Argument in der Restrisikobegründung sein.

Wichtig ist dabei die fachlich korrekte Abgrenzung: Customer Key ist keine pauschale Lösung gegen jeden denkbaren Supportzugriff, keine generelle Freigabe für jede Cloud-Konstellation und kein Ersatz für Identity-, DLP- oder Sharing-Härtung. Es handelt sich um eine zusätzliche kryptografische Kontrollschicht, deren Wert sich erst im Zusammenspiel mit restriktiver Administration, Access Governance und Support-Kontrollen (wie Customer Lockbox) vollständig entfaltet.

11.4 Set-up und Betriebsanforderungen von Customer Key

Microsoft beschreibt für Customer Key einen mehrstufigen Einrichtungsprozess. Dazu gehören die Erstellung und Konfiguration der erforderlichen Azure-Ressourcen, die Entscheidung zwischen Azure Key Vault und Managed HSM, die Einrichtung der Schlüsselmaterialien sowie die Zuweisung von Richtlinien, die bestimmen, welche Schlüssel welche Daten in Microsoft 365 verschlüsseln. Microsoft weist ausdrücklich darauf hin, dass sich der Setup-Prozess zwischen Azure Key Vault und Managed HSM unterscheidet und dass die Schritte in einer festen, prozessualen Reihenfolge auszuführen sind.

Damit wird auch die betriebliche Realität sichtbar: Customer Key ist kein einfacher Schalter, den man ohne Vorbereitung aktiviert. Er erfordert:

• Azure-seitige Architekturentscheidungen,
• klare Rollen- und Berechtigungsmodelle innerhalb des Key-Managements,
• ein sauberes Key-Lifecycle-Management,
• dokumentierte Wiederherstellungs- und Rotationsprozesse,
• und die präzise Kopplung an die betroffenen Workloads.

Datenschutzrechtlich folgt daraus, dass Customer Key nur dann als zusätzliche Maßnahme belastbar dokumentiert werden sollte, wenn die Organisation den Betrieb technisch und organisatorisch beherrscht. Ein halb eingerichtetes oder nur nominell vorhandenes Key-Modell schafft in der Praxis eher Scheinsicherheit als tatsächliche Schutzwirkung.

11.5 Azure Key Vault und Managed HSM: Technische Trägersysteme der Schlüsselhoheit

Microsoft beschreibt Azure Key Vault als Cloud-Dienst zum sicheren Speichern und Verwalten von Geheimnissen, Schlüsseln und Zertifikaten. Dabei unterscheidet Microsoft zwischen Standard-Vaults und Managed HSM Pools. Vaults unterstützen sowohl Software- als auch HSM-gestützte Schlüssel; Managed HSM Pools unterstützen ausschließlich hardwarebasierte, nach FIPS 140-2 Level 3 zertifizierte Schlüssel.

Für die Datenschutzpraxis ist diese Unterscheidung nicht rein technischer Natur. Sie berührt die Frage, wie stark Schlüsselhoheit und kryptografische Absicherung tatsächlich ausgeprägt sein sollen. Ein Managed-HSM-Ansatz kann regulatorisch oder organisatorisch sinnvoll sein, wenn besonders hohe Anforderungen an Hardware-gestützte Schlüsselkontrolle, strikte Trennung von Rollen und eine lückenlose Nachweisbarkeit bestehen. Ein Standard-Key-Vault-Ansatz kann für viele Organisationen ausreichend sein, sofern er sauber betrieben und auditiert wird.

Entscheidend ist daher, die Wahl am tatsächlichen Schutzbedarf auszurichten. Für ein datenschutzfähiges Referenzmodell ist zu dokumentieren:

• Welches Trägersystem gewählt wurde und warum dieses System dem Schutzbedarf entspricht.
• Wer die Berechtigung hat, Schlüssel zu erzeugen, zu rotieren, zu deaktivieren oder wiederherzustellen.
• Wie diese kritischen Handlungen revisionssicher protokolliert werden.

11.6 Double Key Encryption: Spezialwerkzeug für hochsensible Daten

Microsoft beschreibt Double Key Encryption (DKE) ausdrücklich als Lösung für hochsensible Daten und besondere regulatorische Anforderungen. DKE verwendet zwei Schlüssel: einen Schlüssel im Einflussbereich des Kunden und einen zweiten Schlüssel, den Microsoft in Azure speichert. Nach Microsofts Beschreibung behalten Kunden die Kontrolle über einen ihrer Schlüssel mithilfe des DKE-Dienstes.

Datenschutzfachlich ist DKE damit kein allgemeiner Tenant-Standard, sondern ein gezieltes Instrument für Ausnahmeszenarien. DKE ist vor allem dann relevant, wenn Inhalte so sensibel sind, dass eine zusätzliche, durch den Kunden beeinflusste Schlüsselkomponente erforderlich ist, um unbefugte Einsicht – etwa durch den Cloud-Provider – praktisch weiter zu erschweren. In der Breite ist DKE jedoch kein Ersatz für Customer Key oder Labels, sondern ein Spezialwerkzeug für ausgewählte Dokumentklassen oder hochsensible Fachbereiche.

Für Kanzleien, medizinische Kontexte, Forschungsumgebungen oder Behörden mit besonders sensiblen Einzelfallakten kann DKE ein zentraler Baustein der Argumentation sein, warum ein verbleibendes Restrisiko vertretbar reduziert wurde. Für die allgemeine Nutzung ist DKE meist zu spezifisch und betrieblich zu aufwendig.

11.7 Schlüsselhoheit als organisatorisches Thema

Die größte Fehlannahme im Markt ist, Schlüsselhoheit sei bereits hergestellt, wenn technisch irgendein kundenseitiger Schlüssel existiert. Fachlich ist das unvollständig. Schlüsselhoheit ist erst dann belastbar, wenn der gesamte Lebenszyklus kontrolliert wird:

• Erzeugung, Hinterlegung, Aktivierung und Zuweisung.
• Rotation, Deaktivierung und Wiederherstellung.
• Protokollierung und Berechtigungstrennung.

Microsoft weist in den Customer-Key-Dokumentationen selbst darauf hin, dass Verwaltung, Wiederherstellung, Berechtigungen und Richtlinien nach dem initialen Setup aktiv gemanagt werden müssen. Datenschutzrechtlich ist daraus eine klare Soll-Vorgabe abzuleiten: Wer Customer Key oder weitergehende Modelle einsetzt, benötigt ein Key Governance Framework. Dazu gehören mindestens dokumentierte Rollen, ein Vier-Augen-Prinzip für kritische Schlüsselaktionen, definierte Notfallverfahren, festgelegte Rotationsintervalle sowie eine explizite Einbettung in das allgemeine Security- und Compliance-Management.

11.8 Customer Lockbox als organisatorische Ergänzung zur Kryptografie

Während Customer Key und DKE die kryptografische Seite adressieren, befasst sich Customer Lockbox mit dem organisatorischen Zugriffskanal im Supportfall. Microsoft dokumentiert Customer Lockbox als Kontrollmechanismus, bei dem der Kunde Supportzugriffe auf seine Daten explizit genehmigen oder ablehnen kann.

Für die Praxis ist diese Ergänzung essenziell, da ein reifes Hochschutzmodell beide Ebenen berücksichtigen muss: die kryptografische Schutzschicht und die organisatorische Freigabeschicht. Gerade in sensiblen Umgebungen ist die Kombination aus restriktiver Supportfreigabe, sauberem Ticketing, Customer Lockbox und einer entsprechenden Customer-Key– oder DKE-Strategie deutlich belastbarer als jede dieser Einzelmaßnahmen für sich.

11.9 Mastertabelle: Kryptografische Schutzmodelle

12.1 Warum technische Härtung ohne Betriebsmodell unvollständig bleibt

Technische Kontrollen machen einen Tenant noch nicht prüfbar. Erst ein belastbares Betriebsmodell verbindet Technik, Recht und Verantwortung. Die aktuellen Aufsichtsempfehlungen (etwa des HBDI oder der DSK) zielen genau auf diese Verbindung: Sie behandeln nicht nur das Auftragsverarbeitungsverhältnis (AVV), sondern formulieren klare Handlungsempfehlungen an die Verantwortlichen, damit einzelne Microsoft-365-Bestandteile für den konkreten Einsatz vertieft bewertet und datenschutzkonform betrieben werden können. Das von Microsoft bereitgestellte Microsoft 365 Compliance-Kit unterstützt diese Rechenschafts- und Dokumentationsseite mit Musterunterlagen für Verzeichnisse, Schwellwertanalysen, Rechtsgrundlagen und Datenschutzerklärungen.

Für die Praxis folgt daraus: Ein datenschutzfähiger Tenant benötigt nicht nur technische Konfigurationen, sondern konsistente betriebliche Artefakte. Diese bilden das Fundament der Rechenschaftspflicht (Art. 5 Abs. 2 DSGVO). Ohne die explizite Dokumentation der betrieblichen Abläufe bleibt selbst ein exzellent gehärteter Tenant bei einer behördlichen Prüfung oder einem internen Audit oft nur schwer nachvollziehbar.

Ein professionelles Betriebsmodell umfasst daher mindestens folgende Artefakte:

• Verzeichnis der Verarbeitungstätigkeiten (VVT): Eine aktuelle Aufstellung aller Datenflüsse innerhalb der M365-Workloads.
• Datenschutz-Folgenabschätzung (DSFA) bzw. Schwellwertanalyse: Die systematische Risikoanalyse für die gewählten Cloud-Szenarien.
• Rechtsgrundlagen-Mapping: Die explizite Zuordnung der Rechtsgrundlage zu jeder Verarbeitung (z. B. Art. 6 Abs. 1 lit. f DSGVO für Kollaboration).
• Datenschutzhinweise: Transparente Information der Betroffenen über Art und Umfang der Verarbeitung.
• Löschkonzept: Ein technisch und organisatorisch durchgesetztes Konzept für die Aufbewahrung und Löschung von Daten.
• Rollen- und Berechtigungskonzept: Definition, wer Zugriff auf welche administrativen und fachlichen Funktionen hat (insbesondere im Bereich der Purview-Compliance-Rollen).
• Schulungs- und Awareness-Modell: Regelmäßige Unterweisung der Anwender in den datenschutzkonformen Umgang mit den gewählten Tools.
• Änderungs- und Freigabeprozess (Change Management): Dokumentation, wie technische Änderungen im Tenant (z. B. Aktivierung neuer Features) auf ihre datenschutzrechtliche Vertretbarkeit geprüft werden.
• Audit- und Kontrollprozess: Ein definierter Rhythmus zur Überprüfung der Wirksamkeit technischer Kontrollen (z. B. regelmäßige Review der Audit-Logs).

12.2 Datenschutz-Folgenabschätzung (DSFA): Mehr als ein Formular

Microsoft unterstreicht in seiner datenschutzrechtlichen Dokumentation konsequent, dass eine Datenschutz-Folgenabschätzung (DSFA/DPIA) gemäß Art. 35 DSGVO nicht durch die Wahl des Produkts „Office 365“ an sichdeterminiert ist. Vielmehr ist die konkrete Ausgestaltung der Verarbeitung – also die spezifische Konfiguration und der operative Einsatz der Workloads – maßgeblich für die Risikobewertung. Die von Microsoft bereitgestellte Guidance for Data Controllers bietet hierfür wichtige methodische Unterstützung, um Verantwortliche bei der Entscheidung zur DSFA-Erstellung zu leiten.

Ein häufiger Fehler in der Praxis ist die Betrachtung der DSFA als rein „formalistisches Hindernis“. Tatsächlich stellt sie jedoch das zentrale Steuerungsdokument dar, um die Risikomanagement-Strategie innerhalb des Tenants zu operationalisieren. Die Schwellwertanalyse aus dem Microsoft 365 Compliance-Kit ist dabei das entscheidende Werkzeug, um von einer abstrakten Cloud-Betrachtung hin zu einer konkreten Risikoanalyse zu gelangen.

Systematische Elemente einer M365-DSFA

Eine belastbare DSFA für einen Microsoft-365-Tenant muss die spezifischen Risikoprofile der Cloud-Nutzung präzise adressieren und folgende Fragestellungen systematisch beantworten:

• Workload-Umfang: Welche Dienste werden aktiv betrieben und wie interagieren diese (z. B. Teams-SharePoint-Exchange-Kopplung)?
• Datenkategorisierung: Welche personenbezogenen Datenarten (insbesondere nach Art. 9 DSGVO) werden in welchen Workloads verarbeitet und welche Betroffenengruppen sind involviert?
• Risikoanalyse der Schutzziele: Wo liegen die spezifischen Gefährdungspunkte? Hierbei sind insbesondere folgende Faktoren zu prüfen:
  • Drittlandtransfer: Risiko bei Support-Zugriffen oder Datenhaltung (auch wenn der Tenant in der EU liegt).
  • Telemetrie: Umfang der Diagnosedaten, die Microsoft zur Dienstverbesserung erhebt.
  • Freigabemodelle: Risiko unkontrollierter externer Datenflüsse (Federation, Gastzugriff).
  • Endgerätesicherheit: Risiken bei unkontrollierten Zugriffen von BYOD-Geräten.
  • Insider-Risiken & Fehlkonfiguration: Gefahr durch administrative Überprivilegierung oder mangelnde Konfigurationsdisziplin.
• Effektivität der Maßnahmen: Welche der in den vorangegangenen Kapiteln beschriebenen Härtungsmaßnahmen (Purview, Verschlüsselung, Identitätsschutz) mindern das Risiko konkret?
• Restrisikobewertung: Welche Risiken verbleiben trotz technischer Härtung und warum sind diese (z. B. durch kompensatorische organisatorische Maßnahmen) vertretbar?

Die DSFA als Steuerungsdokument

Besonders in hochregulierten Kontexten – etwa in Kanzleien, medizinischen Einrichtungen, HR-Systemen oder beim Einsatz von KI-Funktionen wie Microsoft Copilot – fungiert die DSFA als dynamisches Steuerungsdokument. Sie ist kein einmaliges, statisches Formular, sondern eine „lebende“ Dokumentation der Sicherheitsarchitektur. Änderungen an der Tenant-Konfiguration, die Einführung neuer Features oder die Änderung des Schutzbedarfs von Daten erfordern eine regelmäßige Überprüfung und gegebenenfalls Aktualisierung dieses Dokuments. Nur so bleibt die Rechenschaftspflicht (Art. 5 Abs. 2 DSGVO) gegenüber den Aufsichtsbehörden dauerhaft gewahrt und der Betrieb des Tenants wird von einer „reaktiven Konfiguration“ zu einer „proaktiven Governance“.

12.3 Verzeichnis der Verarbeitungstätigkeiten (VVT): Differenzierung statt Pauschalisierung

Die methodischen Vorgaben des Microsoft 365 Compliance-Kits verdeutlichen, dass der Verzeichniseintrag „Microsoft 365“ als pauschaler Sammelbegriff den Anforderungen der DSGVO nicht gerecht wird. Eine rechtssichere Dokumentation muss zwingend workload- und zweckbezogen differenzieren.

Die Differenzierung ist keine bürokratische Überpräzision, sondern eine zwingende Voraussetzung für die Bestimmtheit des VVT. Da Rechtsgrundlagen, Datenkategorien, Betroffenengruppen, technische Schutzmaßnahmen und Aufbewahrungsfristen je nach Szenario massiv voneinander abweichen, muss das VVT diese Nuancen abbilden.

Ein belastbares Verzeichnis sollte daher mindestens die folgenden Workload-Kategorien separat abbilden:

• Kommunikations-Workloads (Exchange/Outlook): Fokus auf E-Mail-Verkehr, externe Empfänger und Archivierung.
• Kollaborations-Workloads (Teams): Fokus auf Chat-Verläufe, externe Gäste, Meeting-Protokollierung und Transkriptionen.
• Speicher-Workloads (SharePoint/OneDrive): Fokus auf unstrukturierte Daten, sensible Dokumente, Freigabestrukturen und Retention-Policies.
• Office-Anwendungen: Verarbeitung durch Desktop- und Web-Applikationen (z. B. Word/Excel), insbesondere bei lokalen Datenanbindungen.
• Diagnosedaten & Produktstabilität: Diese bilden eine eigene Kategorie für die Verarbeitung von Telemetriedaten durch Microsoft zur Aufrechterhaltung des Dienstes.
• Planungs- & Aufgaben-Workloads: Verarbeitungen in Tools wie Planner oder To Do, die oft geringere Schutzbedarfe aufweisen als Kern-Workloads.
• Compliance- & Sicherheitsdienste: Hier erfolgt eine eigene Verarbeitung von Audit-Logs, DLP-Treffern und Identitätsdaten zu Sicherheitszwecken.
• Zusatzdienste & KI (z. B. Copilot): Diese Dienste erfordern aufgrund der Verarbeitung in KI-Modellen oft eine explizite und separate Betrachtung der Datenflüsse.

Diese workload-spezifische Aufgliederung erlaubt es dem Verantwortlichen, die notwendige Transparenz herzustellen. Nur wenn das VVT die tatsächliche Nutzung und die damit verbundenen Zwecke korrekt widerspiegelt, kann im Falle einer behördlichen Prüfung oder eines Audits nachgewiesen werden, dass die spezifischen Anforderungen an Art. 30 DSGVO erfüllt sind. Zudem erleichtert diese Granularität die korrekte Zuordnung der Rechtsgrundlagen (z.B. Art. 6 Abs. 1 lit. f DSGVO für die betriebliche Zusammenarbeit versus andere Rechtsgrundlagen für spezifische HR- oder Compliance-Prozesse) und bildet die Grundlage für die in Kapitel 12.2 beschriebene DSFA.

12.4 Rechtsgrundlagen-Mapping je Workload

Das Microsoft 365 Compliance-Kit stellt ein dediziertes Dokument zur „Rechtmäßigkeit der Verarbeitung“ bereit. Diese methodische Vorgabe ist fachlich konsequent, da sich die Rechtsgrundlage der Verarbeitung nicht sinnvoll „für Microsoft 365 insgesamt“ bestimmen lässt. Die Verarbeitung von E-Mail-Kommunikation in Exchange, die informelle Zusammenarbeit in Teams, die Speicherung in SharePoint, die Erhebung von Diagnosedaten oder die Protokollierung in Sicherheits-Logs weisen grundlegend unterschiedliche Zwecke und Schutzbedarfsprofile auf.

Differenzierte Dokumentationspraxis

Ein rechtskonformer Tenant erfordert ein granular ausgearbeitetes Rechtsgrundlagen-Mapping, das über pauschale Verweise hinausgeht. Die Praxis der „pauschalen Einordnung“ – etwa unter der Annahme, alles sei durch Vertragserfüllung oder berechtigtes Interesse gedeckt – hält einer kritischen Prüfung meist nicht stand.

Für eine rechtssichere Dokumentation sind folgende Aspekte zwingend workload- und zweckbezogen zu adressieren:

• Zweckspezifische Rechtsgrundlagen: Während für die E-Mail-Kommunikation (Exchange) häufig die Vertragserfüllung (Art. 6 Abs. 1 lit. b DSGVO) im Vordergrund steht, erfordern sicherheitsbezogene Verarbeitungen (Audit-Logs, Purview-Compliance-Daten) in der Regel die Berufung auf ein berechtigtes Interesse (Art. 6 Abs. 1 lit. f DSGVO) zur Gewährleistung der IT-Sicherheit.
• Differenzierung der Verarbeitungszwecke: Diagnosedaten zur Gewährleistung der Produktstabilität sind von den eigentlichen fachlichen Verarbeitungen (z. B. Dokumentenbearbeitung) zu trennen. Die Verarbeitung zu betrieblichen Sicherheitszwecken folgt eigenen rechtlichen Logiken und muss von der operativen Datenverarbeitung abgegrenzt werden.
• Einbindung arbeitsrechtlicher Anforderungen: Bei der Verarbeitung von Mitarbeiterdaten (insbesondere bei Verarbeitungen, die eine Überwachung ermöglichen, wie etwa Teams-Chats oder Produktivitätsmetriken) muss die arbeitsrechtliche Flankierung – z. B. durch Betriebsvereinbarungen oder spezifische Dienstvereinbarungen gemäß § 26 BDSG – zwingend in das Mapping einbezogen werden.

12.5 Datenschutzhinweise und Transparenz

Das Microsoft 365 Compliance-Kit enthält als wesentlichen Baustein ein Muster für eine Datenschutzerklärung. Microsoft stellt jedoch zutreffend klar, dass es sich dabei um Platzhalter handelt, die zwingend an die tatsächliche technische Konfiguration und die betriebliche Nutzung des jeweiligen Tenants angepasst werden müssen.

Transparenz als Governance-Instrument

Für den datenschutzkonformen Betrieb bedeutet dies: Transparenztexte dürfen weder generisch noch rein „Microsoft-zentriert“ sein. Sie müssen die tatsächliche operative Wirklichkeit im Unternehmen abbilden, anstatt lediglich die Leistungsbeschreibung des Anbieters zu kopieren.

Eine belastbare Datenschutzerklärung für einen Microsoft-365-Tenant muss folgende Punkte präzise ausarbeiten:

• Workload-Spezifik: Welche Microsoft-365-Dienste werden in welchem Umfang genutzt? (z. B. Einsatz von Teams für Videokonferenzen vs. Nutzung von Planner zur Aufgabenverwaltung).
• Zweckbindung: Zu welchen konkreten betrieblichen Zwecken erfolgt der Einsatz? (z. B. zur internen Kommunikation, zur Mandatsverwaltung, zur Archivierung von Geschäftsunterlagen).
• Datenkategorisierung: Welche personenbezogenen Datenarten (z. B. Stammdaten, Kommunikationsinhalte, Metadaten, Diagnosedaten) sind typischerweise betroffen?
• Empfänger und Auftragsverarbeiter: Wer hat Zugriff (neben Microsoft als Auftragsverarbeiter auch ggf. andere Dienstleister oder verbundene Unternehmen im Konzern)?
• Technische und organisatorische Schutzmaßnahmen (TOMs): Welche Härtungsmaßnahmen (wie in den Kapiteln 10 und 11 beschrieben) kommen zum Einsatz?
• Drittland- und Support-Konstellationen: Welche Risiken bestehen hinsichtlich der Support-Zugriffe oder bei einer möglichen Datenübermittlung in Drittländer (gemäß dem aktuellen Angemessenheitsbeschluss oder den Standardvertragsklauseln)?

Transparenz über das Vertragsverhältnis hinaus

Besonders im Bereich der externen Kommunikation und Kollaboration – etwa bei der Einbindung externer Gäste in Microsoft Teams oder bei der gemeinsamen Bearbeitung von Dokumenten in SharePoint – ist eine abstrakte Datenschutzerklärung oft ungenügend.

Die Transparenzpflicht (Art. 13/14 DSGVO) dient hierbei nicht nur der Erfüllung einer rechtlichen Informationspflicht, sondern ist ein essenzieller Bestandteil des Vertrauens- und Governance-Modells. Mitarbeiter und externe Kollaborationspartner müssen verstehen, dass ihr Handeln innerhalb einer geschützten, durch Governance-Regeln (wie Purview-Labels oder DLP-Richtlinien) flankierten Umgebung stattfindet. Eine spezifische, auf die Konfiguration angepasste Information schafft Akzeptanz für die technischen Leitplanken und verdeutlicht, dass der Schutz der Daten ein aktiver Bestandteil der täglichen Arbeit ist.

Die Qualität der Datenschutzerklärung ist somit ein Spiegelbild der technischen Konfiguration des Tenants: Wer keine präzisen Informationen über die Verarbeitung geben kann, hat meist die technische Kontrolle über die Workloads noch nicht hinreichend in Governance-Strukturen gegossen.

12.6 Löschkonzept und Datenlebenszyklus

Löschkonzepte innerhalb von Microsoft 365 stellen eine erhebliche organisatorische und technische Herausforderung dar. Die Annahme, eine einfache Löschtaste oder die manuelle Archivierung durch den Benutzer reiche aus, ist angesichts der Funktionsweise der Cloud-Dienste fachlich nicht haltbar. Daten liegen nicht an einem isolierten Ort, sondern existieren redundant und verteilt – in Postfächern, Dateiversionen, Teams-Chats, Kanaldateien, OneDrive-Synchronisationen, Audit-Logs, Meeting-Aufzeichnungen sowie in diversen Freigabe- und Archivkontexten.

Die Mehrdimensionalität des Datenlebenszyklus

Die Aufsichtsbehörden, wie beispielsweise der HBDI, behandeln die „Löschung und Rückgabe personenbezogener Daten“ daher nicht ohne Grund als eigenständigen, komplexen Prüfpunkt. Ein konformer Datenlebenszyklus in M365 muss die unterschiedlichen technischen Spezifika der Workloads berücksichtigen:

• Workload-spezifische Zyklen: E-Mails, Chat-Nachrichten, SharePoint-Dokumente und OneDrive-Bestände folgen unterschiedlichen technischen Logiken (z.B. Mailbox Item Retention vs. Document Versioning).
• Konfliktpotential technischer Features: Funktionen wie die automatische Versionierung oder die systemweite Speicherung von Aufzeichnungen können Löschkonzepten entgegenstehen, wenn sie nicht explizit durch Retention-Policies gesteuert werden.
• Rechtliche Sonderanforderungen: Gesetzliche Aufbewahrungspflichten (z. B. nach Handels- oder Steuerrecht), HR-Fristen, Mandatsanforderungen oder Litigation Holds (Beweissicherungspflichten) setzen zwingende Rahmenbedingungen, die manuell kaum zu steuern sind.
• Technik vs. Fachlichkeit: Daten dürfen nicht unbegrenzt fortbestehen, nur weil Microsoft sie technisch leicht vorhält. Die bloße Verfügbarkeit technischer Speicherressourcen entbindet den Verantwortlichen nicht von seiner Pflicht zur regelmäßigen Datenlöschung gemäß Art. 5 Abs. 1 lit. e DSGVO.

Strukturierung der Löschvorgaben

Um ein belastbares Löschkonzept zu etablieren, muss der Lebenszyklus als Zusammenspiel zwischen fachlicher Anforderung und technischer Purview-Steuerung verstanden werden. Die folgende Tabelle verdeutlicht die notwendige Differenzierung nach Schutzbedarf und Workload-Eigenschaften:

Fazit für die Governance

Ein rechtskonformes Löschkonzept ist in einem Cloud-Tenant niemals ein statisches Dokument, sondern ein dynamisches Regelwerk. Es erfordert die enge Abstimmung zwischen:

1. Fachbereich: Definition der fachlichen Aufbewahrungsfristen.
2. Compliance: Integration gesetzlicher Anforderungen (z.B. GoBD, StGB).
3. IT/Technik: Implementierung via Purview Retention Labels und Policies.
4. Audit: Regelmäßige Wirksamkeitskontrolle, ob die automatisierten Löschvorgänge tatsächlich erfolgreich ablaufen (Protokollierung).

Ohne diese Kopplung verbleiben Daten unkontrolliert im Tenant, was nicht nur ein unnötiges Datenschutzrisiko darstellt, sondern auch die Rechenschaftspflicht gegenüber Aufsichtsbehörden schwächt. Der „automatisierte Löschzyklus“ durch Purview ist somit die einzige skalierbare Antwort auf die hohe Komplexität der Cloud-Datenhaltung.

12.7 Betroffenenrechte und DSR-Prozesse (Data Subject Requests)

Microsoft stellt für die Bearbeitung von Betroffenenanfragen – den sogenannten Data Subject Requests (DSR) – umfangreiche Dokumentationen zur Verfügung. Diese Anleitungen verdeutlichen, dass die Wahrung der Betroffenenrechte (Art. 15–22 DSGVO) in einer komplexen Cloud-Umgebung kein theoretisches Konstrukt bleiben darf, sondern ein operativ beherrschter, wiederholbarer Prozess sein muss.

Für den Verantwortlichen ergibt sich daraus die zwingende Anforderung, die Umsetzung nicht erst im Einzelfall zu improvisieren. Ein belastbarer DSR-Prozess muss folgende Komponenten integrieren:

• Systematische Identifikation: Da Daten in M365 über diverse Workloads (Exchange, SharePoint, Teams, Planner, etc.) verstreut sind, müssen die relevanten Datenquellen für jeden Betroffenen bekannt und durchsuchbar sein.
• Workflow-Definition: Auskunfts-, Lösch-, Berichtigungs- und Exportanfragen müssen prozessual in die IT- und Datenschutz-Governance eingebettet sein. Wer nimmt die Anfrage entgegen? Wer führt die Suche durch? Wer prüft die Daten auf Schutzbedürftigkeit Dritter, bevor sie herausgegeben werden?
• Rollen und Zuständigkeiten: Die Zuweisung von Zugriffsrechten für eDiscovery-Werkzeuge oder Purview-Schnittstellen muss strikt nach dem Need-to-know-Prinzip erfolgen. Die technische Durchführung darf nicht ohne fachliche (datenschutzrechtliche) Prüfung der Ergebnisse erfolgen.
• Revisionssichere Dokumentation: Da für die Bearbeitung von Betroffenenrechten strikte gesetzliche Fristen gelten, muss der gesamte Prozess – von der Anfrage bis zur finalen Umsetzung – nachvollziehbar protokolliert werden.

12.8 Schulung und Awareness

Die technische Härtung eines Tenants mittels Purview, DLP und Verschlüsselung ist eine notwendige Bedingung, jedoch keine hinreichende. Die Erfahrung zeigt, dass Sicherheitsvorfälle in Microsoft 365 in der überwiegenden Mehrzahl durch menschliches Fehlverhalten oder falsche Annahmen der Anwender entstehen. Fehlklassifikationen, unbedachte Gastzugriffe, die Verwendung unpassender Applikationen oder das Speichern sensibler Inhalte an falschen Orten sind selten böswillig, sondern meist die Folge einer fehlenden Einordnung in das Sicherheitskonzept.

Ein belastbares Betriebsmodell erfordert daher ein differenziertes Schulungs- und Awareness-Konzept, das über generische „Security-Poster“ hinausgeht und zielgruppenspezifisch aufbereitet ist:

Durch diese zielgerichtete Einbindung der Anwender in das Governance-Modell wandelt sich der Datenschutz von einer IT-Restriktion zu einer gelebten Arbeitsweise. Die Schulung vermittelt dabei nicht nur das Wie, sondern vor allem das Warum der technischen Leitplanken, was die Akzeptanz für Sicherheitsvorgaben maßgeblich steigert und die Fehlerquote in der täglichen Arbeit signifikant reduziert.

12.9 Audit- und Kontrollprozesse: Die Dynamik des Tenants beherrschen

Ein datenschutzfähiger Tenant ist niemals ein statischer Zustand, sondern ein dynamisches System. Microsoft 365 ist ein sich fortlaufend änderndes SaaS-Ökosystem, in dem neue Funktionen, geänderte Standardeinstellungen (Defaults), neue KI-Integrationen (wie Microsoft Copilot), zusätzliche Datenpfade und sich stetig entwickelnde Dokumentationen die Risikolage permanent verschieben. Microsoft betont in seinen Compliance-Unterlagen wiederholt, dass sich Dienste und Features stetig weiterentwickeln und Verantwortliche ihre Risikoanalyse kontinuierlich an den konkreten Einsatz und die tatsächliche Konfiguration anpassen müssen.

Der Tenant als lebender Organismus

Aus dieser Dynamik leitet sich die Notwendigkeit ab, den Betrieb nicht als einmaliges Projekt, sondern als zyklischen Governance-Prozess zu verstehen. Ein belastbares Betriebsmodell muss die Kontrolle über die technische Konfiguration dauerhaft sicherstellen.

Zentrale Kontrollzyklen für den Tenant-Betrieb

Die Governance eines Tenants ist nur dann wirksam, wenn sie in regelmäßigen Abständen auf ihre Aktualität geprüft wird. Das Betriebsmodell sollte daher definierte Review-Zyklen für folgende Bereiche festlegen:

• Konfigurations- und Sicherheits-Reviews: Überprüfung der Tenant-weiten Basiseinstellungen, wie Identitäts-Policies, Conditional Access Rules und externe Freigabemöglichkeiten.
• Feature- und Workload-Releases: Jede Aktivierung eines neuen Workloads oder einer neuen Funktion (z. B. Agents oder neue Copilot-Erweiterungen) muss vor der produktiven Freigabe eine datenschutzrechtliche Bewertung durchlaufen.
• App Consent Governance: Regelmäßige Überprüfung der erteilten Berechtigungen für Drittanbieter-Apps, um das Risiko von „Shadow-IT“ und unkontrollierten Datenabflüssen zu minimieren.
• Gast- und Zugriffs-Rezertifizierung: In einem Tenant mit hoher Fluktuation ist die regelmäßige Überprüfung externer Gastzugriffe und delegierter Administratorrollen zwingend erforderlich, um das Prinzip der geringsten Rechte (Least Privilege) zu wahren.
• Governance-Review (Labels, DLP, Retention): Prüfung, ob die klassifizierten Schutzstufen, die DLP-Regeln und die Löschfristen noch mit den aktuellen Geschäftsprozessen und den Datenbeständen korrespondieren.
• Audit-Log-Auswertung: Die systematische Analyse der Sicherheits-Logs auf Anomalien, administrative Fehlkonfigurationen oder potenzielle Sicherheitsvorfälle bildet die notwendige Rückkopplungsschleife.
• Aktualisierung der Dokumentation: Wesentliche Änderungen am Tenant-Setup müssen unmittelbar dazu führen, dass das Verzeichnis der Verarbeitungstätigkeiten, die DSFA und die Datenschutzhinweise korrigiert werden.

Kontinuität als Nachweis der Rechenschaftspflicht

Diese Kontrollprozesse dienen nicht nur der Fehlervermeidung, sondern sind der unmittelbare Nachweis der Rechenschaftspflicht (Art. 5 Abs. 2 DSGVO). Indem der Verantwortliche nachweist, dass er die Konfiguration seines Tenants aktiv überwacht und auf die ständige Weiterentwicklung des Dienstes reagiert, unterstreicht er seine Rolle als aktiver „Steuermann“ der Verarbeitung. Wer den Tenant-Betrieb hingegen als „Einrichtung und Vergessen“ betrachtet, läuft Gefahr, dass die datenschutzrechtliche Konformität aufgrund von schleichenden Änderungen der Standardeinstellungen oder neuen Funktionalitäten bereits nach kurzer Zeit untergraben wird.

12.10 Mastertabelle: Betriebs-Compliance

12.11 Mastertabelle: Organisationsmaßnahmen für Kanzleien und Hochschutzumgebungen

13.1 Ziel und Funktion eines Prüfungsleitfadens für Microsoft 365

Ein Audit-Leitfaden für Microsoft 365 stellt eine belastbare Nachweisführung eines konkreten Betriebsmodells sicher. Dieser Leitfaden dient als Beispiel für ein Governance-Instrument, das technische Best Practices mit den regulatorischen Anforderungen verknüpft.

Im Microsoft-365-Kontext deckt der Prüfungsleitfaden vier Ebenen ab:

• Vertrags- und Rechtsrahmen: Prüfung der vertraglichen, dokumentarischen und rechtsgrundlagenbezogenen Einordnung der Cloud-Nutzung.
• Technische Kontrollarchitektur: Überprüfung der Konfiguration von Tenant, Identität, Workloads, Purview und Supportpfaden auf die technische Durchsetzung von Datenschutzvorgaben.
• Betriebs- und Organisationsmodell: Bewertung der vorhandenen Prozesse für Rollen, Freigaben, Löschung, Betroffenenrechte (DSR), Auditierung, Schulung, Change Management und Eskalationswege.
• Nachweis- und Restrisikologik: Dokumentation und Belegbarkeit der umgesetzten Maßnahmen sowie die fundierte Begründung verbleibender Restrisiken.

Der HBDI-Bericht, das M365-Kit und die aktuelle Microsoft-Dokumentation bilden hierfür die Grundlage. Während der HBDI die vertraglich-dokumentarische Basis bewertet, liefert das M365-Kit Bausteine für die Rechenschaftspflicht. Die Microsoft-Produktdokumentationen spezifizieren die technisch verfügbaren Kontrollen. Ein Audit für Microsoft 365 integriert diese juristischen, technischen und betrieblichen Aspekte.

13.2 Grundstruktur des Audits

Ein belastbarer Audit-Ansatz für Microsoft 365 gliedert sich in sieben Prüffelder:

13.3 Auditmethodik: Soll-/Ist-Prüfung statt Momentaufnahme

Ein schwerwiegender methodischer Fehler in vielen Microsoft-365-Audits besteht darin, sich auf die reine Abfrage des aktuellen Ist-Zustands einzelner Konfigurationseinstellungen zu beschränken. Dies greift zu kurz, da eine isolierte Momentaufnahme keine Aussage über die Angemessenheit der getroffenen Maßnahmen zulässt. Ein Audit muss zwingend als strukturierter Soll-/Ist-Abgleich aufgebaut sein.

Das Soll-Modell

Das Soll-Modell definiert den Zielzustand, den die Organisation für ihren Schutzbedarf erreichen muss. Es leitet sich ab aus:

• Den rechtlichen Anforderungen: Gesetzliche Vorgaben, die den Datenschutz im Unternehmen definieren.
• Dem Schutzbedarf der Organisation: Die individuelle Einstufung von Daten und Prozessen nach Sensibilität und Kritikalität.
• Der dokumentierten Nutzung: Die spezifischen Workloads und Szenarien, die das Unternehmen aktiv betreibt.
• Der gewählten Lizenz- und Kontrollarchitektur: Die technische Ausgestaltung, die zur Umsetzung des Schutzniveaus gewählt wurde.
• Den betrieblichen Entscheidungen: Festlegungen zu Workloads, Berechtigungsrollen und spezifischen Schutzklassen.

Das Ist-Modell

Das Ist-Modell spiegelt die Realität des operativen Betriebs wider. Es erfasst:

• Die tatsächliche Tenant-Konfiguration: Wie die Systeme in der administrativen Konsole konkret eingestellt sind.
• Die reale Lizenzzuweisung: Welche Features den Benutzern tatsächlich zur Verfügung stehen.
• Die gelebte Nutzung: Wie Anwender die Tools im Arbeitsalltag tatsächlich verwenden.
• Die existierenden Policies: Die aktiv greifenden Regelwerke im Hintergrund.
• Die operativen Prozesse: Wie die tägliche Administration, der Support und das Compliance-Management in der Praxis ablaufen.

Erst die systematische Differenzanalyse zwischen diesem Soll-Modell und dem Ist-Modell ermöglicht ein auditfähiges Ergebnis. Ohne ein klar definiertes Soll-Modell degradiert eine Prüfung zu einem rein administrativen Zustandsbericht.

Methodisches Beispiel

Ein Tenant kann technisch gesehen für Data Loss Prevention (DLP) lizenziert sein. Wenn das dokumentierte Soll-Modell jedoch für den Schutz von Hochschutzdaten zwingend Endpoint DLP vorschreibt, in der Realität aber lediglich eine Exchange-DLP aktiv ist, liegt keine „teilweise Erfüllung“ vor. Vielmehr handelt es sich um eine auditrelevante Abweichung, da die technisch getroffenen Maßnahmen den definierten Schutzbedarf nicht decken.

13.4 Nachweisformen: Die Beweisgrundlage im Audit

Ein M365-Audit besitzt nur dann Aussagekraft, wenn es auf einer belastbaren Nachweisgrundlage basiert. Reine Behauptungen der IT oder Screenshots einzelner Konfigurationsseiten sind als alleinige Belege unzureichend. Für eine fachlich belastbare Prüfung sind folgende Nachweisformen zwingend erforderlich:

13.5 Risiko-Scoring für Auditfeststellungen

Nicht jede Abweichung weist die gleiche Relevanz für die Compliance und Sicherheit des Tenants auf. Ein praxistauglicher Audit-Leitfaden erfordert daher ein differenziertes Risiko-Scoring, um Prioritäten bei der Maßnahmenumsetzung zu setzen. Für Microsoft 365 hat sich ein dreistufiges Modell als Standard etabliert, das sowohl technische Schwachstellen als auch organisatorische Defizite abbildet.

13.6 Typische Fehlkonfigurationen in Microsoft-365-Audits

Ein Prüfungsleitfaden muss die realen Fehlmuster kennen, die in Audits regelmäßig zutage treten. Die Kenntnis dieser „Blinden Flecken“ spart Zeit und schärft den Blick für die essenziellen Schwachstellen.

• „MFA ist eingeschaltet“ – aber nicht erzwungen: In vielen Tenants existieren zwar Möglichkeiten für MFA, aber keine tenantweite Pflicht oder Durchsetzung via Conditional Access. Es muss zwingend zwischen verfügbarer und erzwingbarer MFA unterschieden werden.
• Sharing restriktiv gemeint, aber nicht restriktiv voreingestellt: Viele Organisationen definieren formal restriktive Policies, lassen aber durch Standard-Linktypen oder Site-Ausnahmen (z.B. „Jeder“-Links in Teams) faktisch offene Türen. Das Audit muss daher über die Global Policy hinaus auch Vererbungseffekte und Site-Defaults prüfen.
• Labels vorhanden, aber ohne operative Wirkung: Eine auf dem Papier elegante Taxonomie nützt nichts ohne Kopplung an DLP-Regeln, Freigabe-Policies oder Schulungen. Oft sind Labels nur „Metadaten-Design“ ohne technische Wirkung.
• DLP aktiv, aber fachlich blind: Ein häufiger Fehler ist die Aktivierung von Standardvorlagen, die weder reale, spezifische Datentypen (z.B. Mandantendaten) noch die tatsächlichen Datenflüsse der Organisation abdecken.
• Retention mit Archivierung verwechselt: Die bloße Aufbewahrung ist kein Datenschutz. Eine saubere Speicherbegrenzung erfordert explizite Fristen, dokumentierte Ausnahmen und die technische Durchsetzung der Löschung.
• Office-Privacy-Controls nicht zentral verwaltet: Werden Connected Experiences oder Diagnosedaten nicht zentral durch Policies gesteuert, entscheiden Anwender per Default – was in der Regel dem Ziel einer datenschutzkonformen Konfiguration (Art. 25 DSGVO) widerspricht.
• App Consent komplett übersehen: Viele Datenschutzprüfungen vernachlässigen die Konfiguration von Enterprise Apps. Dabei entstehen gerade hier durch Drittanbieter-Anbindungen massive Datenabflussrisiken und unkontrollierte Zugriffsrechte.
• Support und Customer Lockbox nicht bewertet: In sensiblen Umgebungen wird der Zugriff durch den Cloud-Provider oft ausgeklammert. Das ist eine kritische Lücke, da der Zugriff auf Daten durch den Support ohne Customer Lockbox eine zentrale Restrisikofrage darstellt.

13.7 Priorisierte Umsetzungsstrategie auf Basis des Audits

Ein Audit darf nicht in der reinen Bestandsaufnahme verharren, sondern muss zwingend in eine priorisierte Umsetzungslogik überführt werden. Für Microsoft 365 hat sich dabei eine Vier-Stufen-Strategie bewährt, die den Tenant strukturiert in einen datenschutzkonformen Zustand überführt.

13.8 Mastertabelle: Soll-/Ist-Prüfung für M365-Datenschutzaudits

13.9 Mastertabelle: Reifegradmodell für Auditbewertung

14.1 Einordnung

Die folgenden Tabellen sind keine rechtsverbindliche Freigabe, keine Zertifizierung und keine rechtliche Entlastung. Sie sind eine unverbindliche fachjournalistische Arbeitsfassung der hier diskutierten Anforderungen und dienen als Abarbeitungs-, Audit- und Dokumentationshilfe.

Die Vollständigkeit, Geeignetheit und Anwendbarkeit ist vom jeweiligen Verantwortlichen für den eigenen Tenant, die konkret genutzten Workloads, den tatsächlichen Schutzbedarf, die reale Lizenzlage sowie die einschlägigen rechtlichen und regulatorischen Anforderungen eigenständig zu prüfen und in enger Abstimmung mit qualifizierten IT-, Datenschutz- und Rechtsexperten zu bewerten. Maßgeblich ist nicht eine abstrakte Produktfreigabe, sondern die konkrete, dokumentierte und risikoadäquate Ausgestaltung der Nutzung.

14.2 Anwendungshinweis

Die Tabellen sind so geordnet, dass Administratoren und Projektverantwortliche die Maßnahmen nicht mehr nach Produktfamilien, sondern linear nach Umsetzungsstufe, Schutzbedarf und Priorität abarbeiten können. Damit entfällt das bisherige Springen zwischen mehreren Produktkapiteln.

Die Struktur folgt drei aufeinander aufbauenden Umsetzungsstufen:

• Stufe 1 – Baseline Tenant Security: technisch gehärteter Standardbetrieb als belastbarer Ausgangspunkt.
• Stufe 2 – Erhöhte Schutzanforderungen / gehobene Sicherheitsarchitektur: zusätzliche Governance-, Geräte-, Kollaborations- und Cloud-Schutzmaßnahmen.
• Stufe 3 – Sehr hoher Schutzbedarf / regulierte Umgebung: zusätzliche Maßnahmen für Berufsgeheimnisträger, regulierte Branchen, kritische Prozesse und forensische Nachweisfähigkeit.

Die Tabellen sind nicht so zu verstehen, dass jede Zeile in jedem Tenant zwingend umzusetzen wäre. Es gibt Baseline-Maßnahmen, erweiterte Maßnahmen und Hochschutzmaßnahmen. Jede Abweichung, Nichtanwendbarkeit oder risikobasierte Ausnahme ist gesondert zu dokumentieren.

Die Lizenzspalten unterscheiden, soweit fachlich sinnvoll, zwischen Microsoft 365 Business Basic, Microsoft 365 Business Standard, Microsoft 365 Business Premium, Office 365 E3, Microsoft 365 E3, Office 365 E5, Microsoft 365 E5 sowie erforderlichen Add-ons. Wo eine niedrigere Lizenz nur Teilfunktionen oder keine belastbare Steuerung ermöglicht, wird das ausdrücklich kenntlich gemacht.

14.3 Umsetzungsstufenmodell

14.3.1 Stufe 1 – Baseline Tenant Security

Technisch und organisatorisch gehärteter Standardbetrieb für kleine und mittlere Unternehmen sowie Standard-Workloads mit normalen personenbezogenen Daten. Ziel ist ein belastbarer Ausgangspunkt für sicheren Regelbetrieb mit Privacy-Hardening, Grundhärtung der Identitäten und eingeschränkter externer Kollaboration.

• Abzuarbeiten: Baseline-/Basis-Zeilen aus den Bereichen Tenant-Governance, Identität, Office-Privacy, SharePoint/OneDrive, Teams und Exchange Online.
• Nicht erforderlich als Mindestniveau: Hochschutz-Zeilen, Endpoint DLP, Customer Key, Insider Risk, eDiscovery Premium.

14.3.2 Stufe 2 – Erhöhte Schutzanforderungen / gehobene Sicherheitsarchitektur

Typische Szenarien sind Steuerberater, Gesundheitsdaten, größere Mittelständler, Mandantenportale, hybride Geräteflotten, BYOD und Cloud-first-Betrieb. Ziel ist eine strukturierte Governance mit zusätzlicher Geräte- und Datenzugriffssteuerung, sauberer Kollaborationsbegrenzung und erhöhter Kontrolltiefe.

• Zusätzlich abzuarbeiten: Erweitert-/Erhöht-Zeilen aus Tenant-Governance, Identität, Office-Privacy, SharePoint/OneDrive, Teams und Exchange Online.
• Zusätzlich sinnvoll: PowerShell-präferierte Kontrollen für Massensteuerung, technische Nachweisbarkeit und Verifikation.

14.3.3 Stufe 3 – Sehr hoher Schutzbedarf / regulierte Umgebung

Typische Szenarien sind Berufsgeheimnisträger, kritische Infrastruktur, Industrie-IP, HR-Massendaten, Behörden, internationale Konzernumgebungen und forensische Nachweispflichten. Ziel ist ein besonders restriktiv gehärteter Tenant mit hoher Nachweisfähigkeit und – nur wo begründet – zusätzlicher kryptografischer Kontrolle.

• Zusätzlich zwingend: Hochschutz-Zeilen aus Tenant-Governance, Identität, SharePoint/OneDrive, Teams und Exchange Online.
• Zusätzlich vollständig abzuarbeiten: Purview / Klassifikation / DLP / Nachweisfähigkeit.

14.3.4 Technische Reihenfolge der Implementierung

• Zuerst Tenant-Grundentscheidungen: Datenlokation, Reports, Self-Service-Käufe, App-Consent.
• Danach Identität: MFA, Conditional Access, Blockierung von Legacy Authentication, Adminkonten, Notfallkonten.
• Danach Office-Privacy-Controls: Cloud Policy, Diagnosedaten, Connected Experiences.
• Danach Kollaborationsoberflächen: SharePoint/OneDrive, Teams, Exchange Online.
• Danach Klassifikation, DLP, Aufbewahrung und Audit.
• Erst danach Hochschutzfunktionen: PIM, Teams DLP, Endpoint DLP, eDiscovery Premium, Insider Risk, Customer Key, Double Key Encryption.

14.3.5 Legende

14.4 Setup-Tabelle Stufe 1 – Baseline Tenant Security

Diese Tabelle bündelt alle Baseline- bzw. Basis-Maßnahmen für einen technisch gehärteten Standard-Tenant. Sie bildet den Mindestkern für Identitätsschutz, Kollaborationsbegrenzung, Privacy-Hardening und erste Nachweisfähigkeit.

14.5 Setup-Tabelle Stufe 2 – Erhöhte Schutzanforderungen / gehobene Sicherheitsarchitektur

Diese Tabelle bündelt alle erweiterten bzw. erhöhten Maßnahmen für Mandantenportale, hybride Geräteflotten, BYOD, Cloud-first-Betrieb und vergleichbare Szenarien mit gehobenem Sicherheitsbedarf.

14.6 Setup-Tabelle Stufe 3 – Sehr hoher Schutzbedarf / regulierte Umgebung

Diese Tabelle bündelt alle Hochschutz-Maßnahmen sowie die vollständigen Purview-Maßnahmen für sehr hohe Schutzbedarfe, regulierte Umgebungen und forensische Nachweisfähigkeit.

14.7 Zusätzliche Spalten für die Druck- und Auditversion

Für die echte Abarbeitung sollte die Tabelle intern um diese Spalten ergänzt werden:

14.8 Abschlusshinweis zu Kapitel 14

Diese obenstehenden Tabellen sind als unverbindliches Beispiel für eine operative Prüf- und Umsetzungsgrundlage zu lesen. Sie ersetzen nicht die konkrete Bewertung des tatsächlichen Einsatzes, der Schutzbedarfe, der eingesetzten Microsoft-Dienste, der realen Lizenzierung und der einschlägigen rechtlichen Sonderanforderungen. Sie sind ein Werkzeug zur strukturierten Härtung und Dokumentation, aber keine automatische Konformitätsbescheinigung.

15.1 Tenant-Governance / Datenlokation / Supportzugriffe

• Microsoft 365 Datenresidenz – https://learn.microsoft.com/de-de/microsoft-365/enterprise/m365-dr-overview
• Customer Lockbox – https://learn.microsoft.com/de-de/purview/customer-lockbox-requests
• Self-Service Purchases – https://learn.microsoft.com/de-de/microsoft-365/commerce/subscriptions/manage-self-service-purchases-admins
• User Consent – https://learn.microsoft.com/de-de/entra/identity/enterprise-apps/configure-user-consent
• Admin Consent Workflow – https://learn.microsoft.com/de-de/entra/identity/enterprise-apps/configure-admin-consent-workflow

15.2 Identitätsschutz / Conditional Access / MFA

• Conditional Access Übersicht – https://learn.microsoft.com/de-de/entra/identity/conditional-access/overview
• Legacy Authentication Block – https://learn.microsoft.com/de-de/entra/identity/conditional-access/policy-block-legacy-authentication
• MFA Lizenzierung – https://learn.microsoft.com/de-de/entra/identity/authentication/concept-mfa-licensing
• Privileged Identity Management – https://learn.microsoft.com/de-de/entra/id-governance/privileged-identity-management/pim-how-to-activate-role

15.3 Office Datenschutz / Telemetrie

• Privacy Controls verwalten – https://learn.microsoft.com/de-de/microsoft-365-apps/privacy/manage-privacy-controls
• Privacy Controls Überblick – https://learn.microsoft.com/de-de/microsoft-365-apps/privacy/overview-privacy-controls
• Cloud Policy Service – https://learn.microsoft.com/de-de/microsoft-365-apps/admin-center/overview-cloud-policy

15.4 SharePoint / OneDrive Governance

• Externe Freigabe – https://learn.microsoft.com/de-de/sharepoint/turn-external-sharing-on-or-off
• Freigaben einschränken – https://learn.microsoft.com/de-de/microsoft-365/solutions/microsoft-365-limit-sharing
• Default Sharing Link – https://learn.microsoft.com/de-de/sharepoint/change-default-sharing-link
• Unmanaged Devices Zugriff – https://learn.microsoft.com/de-de/sharepoint/control-access-from-unmanaged-devices

15.5 Microsoft Teams Governance

• Gastzugriff – https://learn.microsoft.com/de-de/microsoftteams/set-up-guests
• External Access – https://learn.microsoft.com/de-de/microsoftteams/trusted-organizations-external-meetings-chat
• Meeting Recording – https://learn.microsoft.com/de-de/microsoftteams/meeting-recording
• Transcription – https://learn.microsoft.com/de-de/microsoftteams/meeting-transcription-captions
• Teams Policy Reference – https://learn.microsoft.com/de-de/microsoftteams/settings-policies-reference

15.6 Exchange Online Datenschutz-Härtung

• Outbound Spam Policies – https://learn.microsoft.com/de-de/defender-office-365/outbound-spam-policies-configure
• External Forwarding – https://learn.microsoft.com/de-de/defender-office-365/outbound-spam-policies-external-email-forwarding
• Remote Domains – https://learn.microsoft.com/de-de/exchange/mail-flow-best-practices/remote-domains/manage-remote-domains

15.7 Microsoft Purview

• Purview Service Description – https://learn.microsoft.com/de-de/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-purview-service-description
• DLP Overview – https://learn.microsoft.com/de-de/purview/dlp-learn-about-dlp
• Auto Labeling – https://learn.microsoft.com/de-de/purview/apply-sensitivity-label-automatically
• Customer Key – https://learn.microsoft.com/de-de/purview/customer-key-overview

15.8 Intune

• Intune Licensing – https://learn.microsoft.com/de-de/intune/intune-service/fundamentals/licenses
• App Protection Policies – https://learn.microsoft.com/de-de/intune/intune-service/apps/app-office-policies