Wer Windows 11 in einer deutschen oder europäischen Organisation einsetzt, agiert zwangsläufig in einem Spannungsfeld. Auf der einen Seite steht der Anspruch der DSGVO an datenschutzfreundliche Voreinstellungen (Art. 25), an Transparenz (Art. 13/14) und an angemessene technische Maßnahmen (Art. 32). Auf der anderen Seite liefert Microsoft ein Betriebssystem aus, dessen Standardkonfiguration weitreichende Telemetrie, Cloud-Sync und KI-Funktionen vorsieht — Funktionen, die für den Privatnutzer als Komfortgewinn gedacht sind, im Unternehmenseinsatz aber bewertet, dokumentiert und meist beschränkt werden müssen.
Dieses Kapitel ordnet die wichtigsten rechtlichen Bezugspunkte ein, fasst die offiziellen Stellungnahmen der Aufsichtsbehörden zusammen und beschreibt die operative Bedrohungslage, gegen die der weitere Leitfaden technisch arbeitet. Wer aus der Datenschutz-Welt kommt, findet hier die nötigen Quellenverweise; wer aus dem IT-Betrieb kommt, erhält die Begründung, warum jede einzelne der späteren Konfigurationsempfehlungen kein Komfortverlust ist, sondern eine Pflicht.
Drei Datenflüsse, drei Risikokategorien
Aus datenschutzrechtlicher Sicht zerfallen die Funktionen eines modernen Windows-Clients in drei Kategorien, die jeweils eigene Pflichten auslösen.
| Kategorie | Beispiele | Rechtliche Einordnung | Operative Konsequenz |
|---|---|---|---|
| Diagnostische Daten an Microsoft | Required und Optional Diagnostic Data, Connected User Experiences, Activity History |
Microsoft tritt für diese Telemetrie-Datenströme (in der Microsoft-Learn-Dokumentation unter „Required service data for Windows" beschrieben — in der Products-and-Services-DPA selbst nicht als Eigenbegriff definiert) als eigenständiger Verantwortlicher auf; die DSK sieht hierin einen Konflikt mit Art. 28 DSGVO | Auf Required beschränken; in Enterprise/Education ggf. auf Off (Wert 0) |
| Verarbeitung in Microsoft-Cloud-Diensten | OneDrive, Microsoft 365 Connected Experiences, Bing-Suche im Startmenü | Microsoft als Auftragsverarbeiter nach Art. 28 — Auftragsverarbeitungsvertrag erforderlich; EU Data Boundary erfasst „Customer Data", nicht alle Datenflüsse | DPA aktiv akzeptieren, EU Data Boundary in der Tenant-Konfiguration nachweisen, Connected Experiences je nach Risiko deaktivieren |
| Lokale KI-Verarbeitung | Recall-Snapshots, Click to Do, Cocreator, Generative Erase | Verantwortung verbleibt beim Verantwortlichen; potenzielle Verarbeitung besonderer Kategorien (Art. 9) durch Screenshot-Inhalte | DSFA erforderlich; in den meisten Unternehmen flächendeckend deaktivieren oder eng begrenzen |
Die saubere Trennung dieser drei Kategorien ist die Grundlage für jede Bewertung. Maßnahmen, die in einer Kategorie wirken, ersetzen nicht die Maßnahmen in den anderen — die EU Data Boundary für M365 ändert nichts an der Telemetrie-Bewertung; ein deaktiviertes Recall ändert nichts an der Notwendigkeit, die OneDrive-Synchronisation mit privaten Konten zu unterbinden.
DSK-Befund zu Microsoft 365 und Windows-Telemetrie
Die Datenschutzkonferenz (DSK) der unabhängigen deutschen Datenschutzbehörden hat zu Microsoft 365 mehrere Bewertungen veröffentlicht. Die zentrale Stellungnahme aus November 2022 — von Microsoft kritisiert, von Microsoft jedoch nie vollständig widerlegt — beanstandete drei Punkte, die für Windows 11 unverändert relevant sind. Erstens erkennt die DSK eine fehlende Transparenz und Steuerbarkeit der von Microsoft als „Required Service Data" bezeichneten Datenströme; diese werden von Microsoft als Verantwortlicher (nicht als Auftragsverarbeiter) verarbeitet und entziehen sich damit teilweise der Steuerung durch den Kunden. Zweitens kritisiert die DSK, dass die Standardkonfiguration der Connected Experiences in Microsoft 365 Apps zu Drittlandübermittlungen führt, deren Erforderlichkeit nicht durchgehend dokumentiert ist. Drittens stellt die DSK fest, dass die Microsoft-Auftragsverarbeitungsbedingungen (DPA) und die zugehörigen technisch-organisatorischen Maßnahmen ohne kundenseitige Härtung allein nicht für den datenschutzkonformen Einsatz ausreichen.
Microsoft hat in mehreren Schritten reagiert — durch die Einführung der EU Data Boundary (Phase 2 mit System-Logs und pseudonymisierten personenbezogenen Daten im Januar 2024, Phase 3 mit Professional Services Data im Februar 2025), durch eine in ihrer jeweils aktuellen Fassung gepflegte Microsoft Products and Services Data Protection Addendum (DPA) und durch eine ausgeweitete Transparenz-Tooling-Suite (Datenzugriffsanträge, Transparency Reports, Subprocessor-Listen). Die DSK-Vorbehalte sind damit teilweise adressiert, aber nicht vollständig aufgehoben. Der praktische Konsens unter deutschen Aufsichtsbehörden — pragmatischer geworden, aber weiterhin anspruchsvoll — lautet: Microsoft 365 und Windows 11 sind einsetzbar, wenn der Verantwortliche die DPA aktiv akzeptiert, die EU Data Boundary konfiguriert, die Telemetrie auf das technisch erforderliche Maß reduziert und eine vollständige DSFA für die ergänzenden Risiken (insbesondere KI-Funktionen) durchführt.
DPC-Verfahren und Bundeskartellamt
Über die DSK hinaus prägen zwei weitere Verfahrenslinien das Bild. Die irische Datenschutzbehörde DPC, die als „Lead Supervisory Authority" für Microsoft-Konzerngesellschaften zuständig ist, führt seit 2022 mehrere Verfahren — insbesondere zu LinkedIn-Werbeprofilen und zu Sub-Processor-Strukturen. Die DPC hat am 24. Oktober 2024 ein Bußgeld in Höhe von 310 Millionen Euro gegen LinkedIn Ireland verhängt; in der Begründung verwirft die Behörde sämtliche von LinkedIn geltend gemachten Rechtsgrundlagen — Einwilligung (Art. 6 Abs. 1 lit. a), Vertragserforderlichkeit (lit. b) und berechtigtes Interesse (lit. f) — für die Profilbildung zu Zwecken behavioraler Werbung. Das Verfahren betrifft formal nur die LinkedIn-Mitglieder-Verarbeitung. Analog wirkt die Risikoabwägung aber auf die LinkedIn-Integration in der Microsoft-365-Suite (z. B. „LinkedIn-Informationen" in Outlook-Profilen): Wer diese Integration in Windows-/Office-Standardkonfigurationen aktiv lässt, sollte für die zugrunde liegende Verarbeitung eine eigene Rechtsgrundlage dokumentieren oder die Integration per ADMX-Policy unterbinden.
Das Bundeskartellamt hat mit Beschluss vom 27. September 2024 (B6-26/23) festgestellt, dass Microsoft der erweiterten Missbrauchsaufsicht nach § 19a Abs. 1 GWB unterliegt („Normadressaten-Feststellung"). In der Begründung adressiert die Behörde unter anderem die Verschränkung von Windows-Diensten mit dem persönlichen Microsoft-Konto und mit Werbe-Identifiern; konkrete Untersagungen folgen erst in nachgelagerten § 19a Abs. 2 GWB-Verfahren. Aus der bisherigen Entscheidung resultieren keine direkten Konfigurationspflichten — der Befund stützt aber die in der Aufsichtspraxis bereits etablierte Linie, dass der Einsatz eines persönlichen Microsoft-Kontos (MSA) an Stelle eines unternehmensgesteuerten Entra-Kontos im professionellen Umfeld nur schwer zu rechtfertigen ist.
Die Recall-Kontroverse
Wenige Funktionen haben die Datenschutz-Diskussion um Windows so verdichtet wie Windows Recall. Microsoft hatte Recall im Mai 2024 als „fotografisches Gedächtnis" für Copilot+ PCs angekündigt — kontinuierliche Snapshots des Bildschirms, lokal indiziert, durchsuchbar per natürlicher Sprache. Innerhalb von Tagen wiesen Forschende (insbesondere Kevin Beaumont und das TotalRecall-Werkzeug von xaitax) nach, dass die ursprüngliche Implementierung Snapshots in einer SQLite-Datenbank ablegte, die lediglich per DPAPI im Nutzerkontext geschützt war — extrahierbar ohne UAC-Prompt aus jedem Prozess, der im Kontext des angemeldeten Benutzers lief. Microsoft zog die Funktion zurück und überarbeitete die Architektur grundlegend; die neu gebaute Variante mit VBS-Enclaves, Windows-Hello-ESS-Authentifizierung und sensitiver-Inhalt-Filterung erschien ab Ende 2024 zunächst im Insider-Preview-Programm und wurde im Lauf des Jahres 2025 schrittweise auf Copilot+ PCs ausgerollt.
Aus aufsichtsrechtlicher Sicht bleibt Recall auch in der überarbeiteten Form eine Funktion mit hoher Eingriffsintensität. Mehrere deutsche Aufsichtsbehörden — und auf europäischer Ebene Stellungnahmen einzelner Datenschutzberater — haben 2024 und 2025 darauf hingewiesen, dass eine produktive Nutzung von Recall in der Regel eine DSFA nach Art. 35 DSGVO auslöst und dass das Filtermodell für sensitive Inhalte keine vollständige Garantie gegen die Aufzeichnung besonderer Datenkategorien gibt. Für Verantwortliche bedeutet das in der Praxis: Recall wird im Default-Härtungspfad deaktiviert; eine Aktivierung erfolgt nur in eng definierten Anwendungsfällen mit dokumentierter DSFA, klarem Datenschutzhinweis und einer organisatorischen Kontrolle, die das Risiko der Aufzeichnung besonderer Kategorien begrenzt.
DSGVO-Pflichten im Klartext
Aus den vorgenannten Befunden und der allgemeinen DSGVO-Systematik ergeben sich vier Pflichten, die jede Windows-11-Härtungsstrategie tragen sollten.
Art. 5 Abs. 1 lit. c (Datenminimierung) verlangt, dass nur diejenigen Daten verarbeitet werden, die für den Zweck erforderlich sind. Optional Diagnostic Data, Activity History oder OneDrive-Backups privater Ordner sind für die meisten Unternehmenszwecke nicht erforderlich — sie müssen abgeschaltet werden, sofern kein dokumentierter Anwendungsfall sie rechtfertigt.
Art. 25 (Privacy by Default) verpflichtet den Verantwortlichen, Voreinstellungen so zu wählen, dass standardmäßig nur die für den jeweiligen Zweck erforderlichen Daten verarbeitet werden. Die ausgelieferte Windows-11-Konfiguration genügt dem nicht; sie muss durch zentrale Härtung (GPO/Intune) in einen Privacy-by-Default-Zustand überführt werden, bevor das erste Gerät an einen Mitarbeiter ausgegeben wird.
Art. 32 (Sicherheit der Verarbeitung) verlangt angemessene technisch-organisatorische Maßnahmen, einschließlich Verschlüsselung, Pseudonymisierung und Verfügbarkeit. In Verbindung mit dem Boot-Chain-Härtungs-Leitfaden und dem AD-Tiering-Leitfaden decken wir die technische Seite dieser Pflicht ab.
Art. 35 (DSFA) ist auszulösen, wenn eine Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten der Betroffenen hat. Bei produktiver Nutzung von Recall, beim flächendeckenden Einsatz von Copilot mit Zugriff auf Personaldaten oder bei der Verarbeitung besonderer Datenkategorien im Microsoft-365-Tenant ist die Schwelle in der Regel erreicht.
BSI, NIS2 und Versicherer
Außerhalb der DSGVO-Linie wirken weitere Rahmen. Das BSI veröffentlicht mit der SiSyPHuS-Win10-Studie eine systematische Analyse der Windows-Telemetrie und Konfigurationsempfehlungen, deren Befunde weitgehend auf Windows 11 übertragbar sind; ergänzend bestehen der IT-Grundschutz-Baustein SYS.2.2.3 „Clients unter Windows" und die Telemetry-Monitoring-Framework-Auswertungen, in denen das BSI Windows-11-spezifische Datenflüsse fortlaufend dokumentiert. Die Empfehlungen sind nicht bindend, dienen Aufsichtsbehörden und Auditoren aber als Bewertungsmaßstab.
Die NIS2-Richtlinie verlangt in Art. 21 unter anderem Maßnahmen zum Identitäts- und Zugriffsmanagement, zur Sicherheit der Lieferkette und zur Asset-Verwaltung. Eine Windows-Flotte ohne zentrale Konfigurationssteuerung und ohne dokumentierte Härtungsbasis ist im NIS2-Audit kaum zu verteidigen.
Cyberversicherer fragen im Underwriting-Fragebogen zunehmend nach „MDM-/GPO-gesteuerter Konfiguration", „deaktivierter unkontrollierter Cloud-Synchronisation", „LAPS oder vergleichbarem lokalen Admin-Passwort-Management" und „dokumentierter Mitarbeiterhärtung". Wer den Härtungsstand pro Gerät reproduzierbar nachweisen kann, fährt günstigere Prämien — und ist im Schadensfall in einer deutlich besseren Verhandlungsposition.
Nächster Schritt
Die rechtliche Grundlage ist gelegt, der Druck zur Umsetzung benannt. In Kapitel 2 entscheiden wir die zwei wichtigsten Architekturfragen, die alle nachfolgenden Schritte tragen: Welche Edition wählen wir für welche Geräteklasse, und welches Identitäts- und Verwaltungsmodell setzen wir darüber? Beides bestimmt, welche Härtungs-Hebel überhaupt verfügbar sind — und welche Edition-Klassen Sie in einer datenschutzkonformen Flotte gar nicht erst einsetzen sollten.