Wie europäische Unternehmen mit Datenhoheit Microsoft 365-Produktivität und Schutz sensibler Daten sichern

Microsoft 365 ist fest in den Geschäftsprozessen europäischer Unternehmen verankert. Teams steuert die tägliche Kommunikation. SharePoint verwaltet Dokumentbibliotheken, die sich über Abteilungen und Partner erstrecken. OneDrive bildet das Rückgrat für hybrides Arbeiten. Outlook verbindet Mitarbeitende mit Kunden und Aufsichtsbehörden.

Diese Infrastruktur zu ersetzen, ist keine realistische Option – und sollte auch nicht notwendig sein. Die eigentliche Frage, vor der europäische IT- und Sicherheitsverantwortliche stehen, ist konkreter: Wie lässt sich die volle Microsoft 365-Produktivität erhalten und gleichzeitig sicherstellen, dass Datenschutzanforderungen nach DSGVO, Schrems II, dem US CLOUD Act und einer zunehmend strengen Durchsetzung tatsächlich erfüllt werden?

Dieser Beitrag beantwortet diese Frage, beleuchtet die Souveränitätslücke, die Microsofts eigene Tools offenlassen, und zeigt, wie ein Souveränitäts-Overlay diese schließt, ohne die für Mitarbeitende essenziellen Arbeitsabläufe zu beeinträchtigen.

Executive Summary

Kernaussage: Microsoft 365 birgt strukturelle Risiken für die Datensouveränität europäischer Unternehmen. Microsoft unterliegt dem US CLOUD Act, und auch wenn Microsofts eigene Sovereign Cloud-Tools einige dieser Risiken adressieren, beseitigen sie diese nicht vollständig. Ein Souveränitäts-Overlay – das Kiteworks Private Data Network als Single-Tenant-Layer über Microsoft 365-Workflows – bietet vom Kunden kontrollierte Verschlüsselung, zugriffslose Zugriffskontrollen und umfassende Audit-Funktionen, die diese Lücken schließen.

Warum das relevant ist: Europäische Datenschutzbehörden prüfen US-Cloud-Lösungen mit wachsender Intensität. TIAs, die CLOUD Act-Risiken identifizieren, sich aber allein auf vertragliche Maßnahmen stützen, genügen den Aufsichtsbehörden nach Schrems II nicht. Organisationen, die keine technisch wirksamen ergänzenden Maßnahmen nachweisen können – etwa vom Kunden kontrollierte Verschlüsselungsschlüssel in EWR-kontrollierter Hardware, nachweislich ausgeschlossener Klartextzugriff des Providers – riskieren Bußgelder, Verarbeitungsverbote und Reputationsschäden.

5 wichtige Erkenntnisse

1. Ein EU-Rechenzentrum löst das CLOUD Act-Risiko für Microsoft nicht. Microsoft ist ein US-Unternehmen und unterliegt US-Gerichtsbeschlüssen, unabhängig vom Standort der Infrastruktur. Der CLOUD Act folgt der Kontrolle des Providers, nicht dem geografischen Speicherort der Daten. Die EU Data Boundary von Microsoft beschränkt die Datenresidenz, verhindert aber keinen US-Zugriff auf diese Daten per Gerichtsbeschluss.
2. Von Kunden verwaltete Schlüssel liegen nicht außerhalb der Reichweite von Microsoft. Azure Key Vault und Purview Customer Key ermöglichen Kunden die Kontrolle über die Schlüsselrotation – aber die Schlüssel verbleiben in Microsofts Azure-Infrastruktur. Ein CLOUD Act- oder FISA-Beschluss gegen Microsoft betrifft diese Infrastruktur. Echte Schlüsselkontrolle erfordert Schlüssel in einer HSM-Integration unter vollständiger Kontrolle des Kunden außerhalb der Provider-Umgebung.
3. Microsoft 365 Copilot schafft eine eigene, ungelöste Souveränitätslücke. Copilot verarbeitet Klartextinhalte – E-Mails, Dokumente, Teams-Chats – zur Generierung von Ergebnissen. Verschlüsselung im ruhenden Zustand schützt nicht, wenn Daten für KI-Prozesse entschlüsselt werden müssen. Unternehmen benötigen eine Governance-Schicht, die steuert, auf welche Daten Copilot zugreifen darf – nicht nur, wo diese gespeichert sind.
4. Multimandantenfähigkeit ist ein unterschätztes Risiko. In Microsofts Standard-Multitenant-Architektur koexistieren verschlüsselte Daten und Schlüssel von Tausenden Unternehmen in gemeinsam genutzter Infrastruktur. Ein einziger Exploit kann mehrere Kunden gleichzeitig kompromittieren. Single-Tenant-Deployment – wie es Kiteworks bietet – eliminiert dieses Vermischungsrisiko vollständig.
5. Ein Souveränitäts-Overlay erhält die volle M365-Produktivität. Kiteworks integriert sich per nativer Plugins in Outlook, Teams, SharePoint, OneDrive, Word, Excel und PowerPoint. Endanwender arbeiten weiter in gewohnten Oberflächen; Zugriffskontrollen, Schlüsselmanagement, Audit-Logging und Geofencing laufen unsichtbar unterhalb der UX-Schicht, ohne Arbeitsabläufe zu stören.

Das Microsoft 365-Souveränitätsproblem: Was Microsofts eigene Tools leisten – und was nicht

Microsoft hat erheblich in Tools für europäische Compliance investiert: Die EU Data Boundary beschränkt die Verarbeitung personenbezogener Daten auf EU- und EFTA-Infrastruktur; Azure Key Vault und Purview Customer Key bieten Kunden Kontrolle über die Schlüsselrotation; Microsoft Cloud for Sovereignty ergänzt Richtlinien für Behördenkunden. Das sind echte Funktionen. IT-Verantwortliche sollten genau verstehen, was diese leisten – und was nicht. Denn genau auf diese Lücke konzentriert sich die regulatorische Prüfung.

Was das EU Data Boundary-Programm löst – und was nicht

Microsofts EU Data Boundary beschränkt, wo personenbezogene Daten gespeichert und verarbeitet werden. Damit werden Anforderungen an die Datenresidenz erfüllt und der erste Layer der Souveränitäts-Compliance unterstützt. Was nicht adressiert wird, ist der Zugriff. Microsoft ist ein US-Unternehmen. Der US CLOUD Act verpflichtet US-Firmen, Daten weltweit auf rechtmäßige Anforderung der US-Regierung bereitzustellen – unabhängig vom Speicherort. DSGVO Artikel 48 verbietet Übermittlungen an Nicht-EU-Behörden allein aufgrund ausländischer Gerichtsbeschlüsse – aber das verhindert weder deren Ausstellung noch zwingt es Microsoft, diese abzulehnen. Der strukturelle Konflikt zwischen CLOUD Act und DSGVO Artikel 48 wird durch Datenresidenz nicht gelöst.

Warum kundenseitig verwaltete Schlüssel in Azure nicht gleichbedeutend mit kundengesteuerter Verschlüsselung sind

Azure Key Vault und Purview Customer Key ermöglichen Kunden die Kontrolle über Schlüsselrotation und -widerruf – das sind relevante Funktionen. Aber Schlüssel, die in Azure verwaltet werden, verbleiben in Microsofts Infrastruktur. Ein CLOUD Act- oder FISA Section 702-Beschluss gegen Microsoft betrifft diese Infrastruktur. Die Empfehlungen 01/2020 des EDPB legen fest: Kundengesteuerte Verschlüsselung bedeutet, dass der Provider niemals Zugriff auf Schlüssel oder unverschlüsselte Daten hat. Schlüssel im Azure Key Vault erfüllen diesen Standard nicht. Echte Schlüsselkontrolle erfordert FIPS-validierte Hardware unter exklusiver Kontrolle des Kunden, vollständig außerhalb der Provider-Umgebung.

Das Microsoft 365 Copilot-Problem: KI-Verarbeitung und Souveränität

Microsoft 365 Copilot stellt eine eigenständige und verschärfte Souveränitätsherausforderung dar. Copilot verarbeitet E-Mail-Inhalte, SharePoint-Dokumente und Teams-Chatverläufe, um Zusammenfassungen, Entwürfe und Antworten zu generieren – dafür müssen Inhalte im Klartext vorliegen. Verschlüsselung im ruhenden Zustand bietet beim KI-Prozess keinen Schutz. Auf alle Daten, auf die Mitarbeitende in M365 zugreifen können, kann auch Copilot und damit Microsofts KI-Infrastruktur zugreifen. Für europäische Unternehmen, die sensible Geschäftsdaten, regulierte personenbezogene Daten oder rechtlich privilegierte Kommunikation verarbeiten, entsteht so eine doppelte Gefährdung: Die zugrunde liegenden Daten unterliegen dem CLOUD Act, und KI-generierte Ausgaben daraus potenziell ebenfalls.

Die Governance-Herausforderung erfordert eine Schicht, die steuert, auf welche Daten Copilot zugreifen darf – Kontrolle auf Inhaltsebene statt allein über Microsofts interne Zugriffssteuerung. Ein AI Data Gateway, das Datenflüsse zu KI-Modellen abfängt und steuert – und sicherstellt, dass nur entsprechend klassifizierte Inhalte in die KI-Verarbeitung gelangen – ist die architekturelle Antwort auf dieses Risiko.

Souveränitätsanforderungen nach europäischem Recht: Was das Gesetz tatsächlich verlangt

Die DSGVO Kapitel V verlangt, dass Übermittlungen in Drittländer einen im Wesentlichen gleichwertigen Schutz wie innerhalb der EU gewährleisten. Schrems II bestätigte, dass Standardvertragsklauseln ergänzende technische Maßnahmen erfordern, wenn das Recht des Empfängerlandes deren Wirksamkeit beeinträchtigt. Bei Übermittlungen an US-Provider reicht SCCs allein wegen CLOUD Act-Risiko nicht aus. Der EDPB ist klar: Wo US-Überwachungsrecht Risiken schafft, die vertraglich nicht gelöst werden können, ist die einzig technisch ausreichende Maßnahme eine vom Kunden gesteuerte Verschlüsselung, bei der der Provider nie Zugriff auf Schlüssel oder Klartext hat.

Der regulatorische Rahmen über die DSGVO hinaus

Für viele europäische Unternehmen reicht das Compliance-Rückgrat weit über die DSGVO hinaus. Die NIS 2-Richtlinie stellt Anforderungen an die Sicherheit der Lieferkette und umfasst Cloud-Provider-Beziehungen. Finanzdienstleister unterliegen DORA und müssen Konzentrationsrisiken bei Cloud-Providern adressieren und Resilienz nachweisen, falls US-Cloud-Daten ausländischen Rechtsansprüchen unterliegen. Gesundheitsorganisationen, Verteidigungsunternehmen und Beratungsfirmen mit privilegierter Kommunikation unterliegen weiteren branchenspezifischen Vorgaben. Eine Souveränitätsarchitektur, die den DSGVO-Standard für ergänzende Maßnahmen erfüllt, genügt in der Regel auch diesen Rahmenwerken – wobei Dokumentationspflichten variieren und jede Regulierung eine eigene Bewertung erfordert.

Transfer Impact Assessments bleiben die Dokumentationsbasis. Ein belastbares TIA für Microsoft 365 muss CLOUD Act- und FISA 702-Risiken identifizieren, deren Auswirkungen auf die Wirksamkeit der SCCs bewerten und nachweisen, dass die eingesetzten ergänzenden Maßnahmen – kundengesteuerte Verschlüsselung mit Schlüsseln außerhalb der Microsoft-Infrastruktur – einen im Wesentlichen gleichwertigen Schutz bieten. TIAs, die vor Einführung eines Souveränitäts-Overlays erstellt wurden, müssen aktualisiert werden; diese Aktualisierung ist selbst ein Nachweis der geforderten Accountability.

Die Souveränitäts-Overlay-Architektur: Wie sie funktioniert, ohne M365 zu beeinträchtigen

Ein Souveränitäts-Overlay ersetzt Microsoft 365 nicht. Es umschließt sensible Datenflüsse mit einer Sicherheits- und Governance-Schicht zwischen Endanwendern und Microsoft-Infrastruktur und stellt sicher, dass Daten, die Microsoft verarbeitet, bereits mit Schlüsseln verschlüsselt sind, die das europäische Unternehmen kontrolliert – Microsoft verarbeitet also nur Ciphertext, keinen Klartext. Mitarbeitende nutzen weiterhin die gewohnten Anwendungen; die Souveränitätskontrollen bleiben für sie weitgehend unsichtbar.

Wie Kiteworks sich in Microsoft 365 integriert, ohne es zu ersetzen

Das Kiteworks Private Data Network integriert sich per nativen Plugins und Konnektoren in alle wichtigen Microsoft 365-Anwendungen und erzwingt Souveränitätskontrollen direkt beim Datenaustausch – ohne Anwendungswechsel.

Für Outlook setzt das Kiteworks-Plugin rollenbasierte Richtlinien für Weiterleitungsrechte, Ablaufdaten und Zugriffskontrollen durch, bevor Nachrichten das Unternehmen verlassen. Administratoren definieren Governance-Regeln zentral; Endanwender arbeiten in ihrem gewohnten Outlook-Workflow. E-Mails werden sicher versendet, ohne Konfigurationsaufwand für Mitarbeitende, und jede Aktion – Senden, Empfangen, Weiterleiten, Herunterladen – wird revisionssicher im Audit-Log erfasst.

Für Teams ermöglicht das Kiteworks-Plugin sicheres Filesharing mit externen Partnern über Kiteworks-gesteuerte Repositories. Rollenbasierte Zugriffskontrolle steuert, wer Dateien aus SharePoint, OneDrive und Windows-Freigaben über die Teams-Oberfläche öffnen kann, und jede Interaktion wird automatisch protokolliert.

Für SharePoint und OneDrive bietet die Kiteworks Sovereign Access Suite ein zentrales Gateway zu internen Repositories – ohne VPN-Abhängigkeit. Die zugriffslose Bearbeitung mit SafeEDIT ermöglicht externen Partnern das Anzeigen und Bearbeiten von Dokumenten, ohne dass Dateien das kontrollierte Umfeld des Unternehmens verlassen – zugriffslose Bearbeitung eliminiert das Exfiltrationsrisiko bei externer Zusammenarbeit, ohne die Zusammenarbeit selbst einzuschränken.

Für Word, Excel und PowerPoint erlauben Kiteworks-Plugins den sicheren Dokumentenaustausch direkt aus den Anwendungen heraus – Dateien werden in Unternehmensrepositories und Kiteworks-Freigabeordnern gespeichert, unter denselben Zugriffs- und Audit-Kontrollen wie alle anderen sensiblen Datenflüsse.

Single-Tenant-Deployment und kundengesteuertes Schlüsselmanagement

Die Basis bildet das Single-Tenant-Deployment – On-Premises, kundengesteuerte Private Cloud oder dedizierte Hosting-Instanz – kombiniert mit vom Kunden verwalteten Verschlüsselungsschlüsseln in einer HSM-Integration unter exklusiver Kontrolle des europäischen Unternehmens. In Microsofts Standard-Multitenant-Architektur koexistieren verschlüsselte Daten und Schlüssel von Tausenden Unternehmen in gemeinsam genutzter Infrastruktur. Kiteworks eliminiert diese Vermischung vollständig: Jede Instanz ist isoliert, und Verschlüsselungsschlüssel verlassen nie das kontrollierte Umfeld des Kunden.

Kiteworks unterstützt FIPS 140-3 Level 1-validierte Verschlüsselung – AES-256 für Daten im ruhenden Zustand, TLS 1.3 für Daten während der Übertragung, mit S/MIME und OpenPGP für E-Mails. Die Schlüssel werden vom europäischen Unternehmen generiert und gehalten. Kiteworks erhält keinen Zugriff darauf, ebenso wenig wie Microsoft, wenn Daten bereits vor Erreichen der M365-Infrastruktur verschlüsselt wurden. Das ist die Architektur, die der EDPB-Standard für ergänzende Maßnahmen verlangt – und die ein TIA unter regulatorischer Prüfung glaubwürdig macht.

Kiteworks erzwingt Datenlokalisierung per Geofencing – Allow- und Block-Listen für IP-Adressbereiche stellen sicher, dass Daten nur in definierten Jurisdiktionen gespeichert werden. Für deutsche Unternehmen nach BDSG, französische Unternehmen mit ANSSI-Anforderungen, niederländische Unternehmen nach AP-Prioritäten oder britische Unternehmen nach UK GDPR bieten länderspezifische Schlüsselbereitstellung und Geofencing die technisch nachweisbare Souveränitätsdokumentation, die Datenschutzbehörden verlangen.

KI steuern: Die Copilot-Lücke und wie sie adressiert wird

Microsoft 365 Copilot wird zum Standard-Produktivitätsfeature, und europäische Unternehmen stehen unter Druck, es zu aktivieren. Die Governance-Herausforderung besteht darin, Copilot Mehrwert bieten zu lassen, ohne dass Inhalte verarbeitet werden, die nicht in Microsofts KI-Infrastruktur gelangen dürfen – das erfordert eine Content-Governance-Schicht, kein pauschales Deaktivieren.

Das Kiteworks AI Data Gateway agiert als Vermittler zwischen Content-Repositories und KI-Verarbeitung und setzt KI-Daten-Governance-Richtlinien durch, die bestimmen, welche Inhaltskategorien KI-Modelle nutzen dürfen. DLP-Scanning, Datenklassifizierung und Zugriffskontrollrichtlinien greifen, bevor Inhalte Copilot erreichen – so werden regulierte personenbezogene Daten, geschäftskritische Dokumente und privilegierte Kommunikation konsistent gesteuert, unabhängig davon, welche KI-Funktion die Verarbeitung auslöst. Unternehmen, die Copilot ohne Content-Governance-Schicht einsetzen, gewähren Microsofts KI-Infrastruktur faktisch Zugriff auf sämtliche für Mitarbeitende sichtbare Inhalte – ein Compliance-Risiko, das Datenschutzbehörden zunehmend erkennen und adressieren.

Compliance-Dokumentation: TIAs, Audit-Logs und DPA-Bereitschaft

Technische Souveränitätsarchitektur ist notwendig, aber nicht hinreichend. Aufsichtsbehörden verlangen dokumentarische Nachweise – Transfer Impact Assessments, Verarbeitungsverzeichnisse, DPIAs für risikoreiche Verarbeitung und Audit-Logs, die kontinuierliche Compliance belegen. Das Kiteworks CISO Dashboard bietet zentrale Transparenz über alle sensiblen Datenbewegungen – wer was, wann, mit welcher Anwendung gesendet hat – und schafft den unveränderbaren Audit-Trail, den das DSGVO-Accountability-Prinzip (Art. 5 Abs. 2) verlangt.

Für Unternehmen mit NIS 2-Meldepflichten oder DORA-Resilienz-Dokumentation unterstützt das umfassende Logging und Reporting von Kiteworks die geforderte Evidenz. Bei DPA-Anfragen zu Microsoft 365 belegt die Kombination aus Single-Tenant-Deployment-Dokumentation, HSM-Schlüsselmanagement, Geofencing-Nachweisen und anwendungsbezogenen Audit-Logs eine glaubwürdige, nicht nur behauptete Compliance.

Wie Kiteworks Microsoft 365-Souveränität ermöglicht – ohne Produktivitätseinbußen

Europäische Unternehmen müssen sich nicht zwischen Microsoft 365-Produktivität und Datensouveränität entscheiden. Die eigentliche Wahl ist: M365 mit einem Souveränitäts-Overlay betreiben, das CLOUD Act-, Multitenancy- und KI-Lücken schließt – oder eine Compliance-Position akzeptieren, die DPA-Prüfungen nicht standhält. Ein Souveränitäts-Overlay auf Basis kundengesteuerter Verschlüsselungsschlüssel, Single-Tenant-Deployment, zugriffsloser Zugriffskontrollen und KI-Content-Governance ist der Standard in der Praxis – und integriert sich auf Anwendungsebene in Microsoft 365, ohne dass Mitarbeitende ihre Arbeitsweise ändern müssen.

Kiteworks liefert das Souveränitäts-Overlay, das europäische Unternehmen für Microsoft 365-Compliance nach DSGVO, Schrems II, NIS 2 und DORA benötigen. Das Private Data Network wird als Single-Tenant-Instanz bereitgestellt – On-Premises, Private Cloud oder von Kiteworks gehostet – mit kundengesteuerten Verschlüsselungsschlüsseln in jurisdiktionskontrollierten HSMs, auf die Kiteworks nie zugreift. Native Plugins für Outlook, Teams, SharePoint, OneDrive und Office-Anwendungen integrieren sich direkt in bestehende Workflows. Die Sovereign Access Suite ermöglicht zugriffslosen Zugriff auf interne Repositories und SafeEDIT-basierte externe Zusammenarbeit, ohne dass Daten das kontrollierte Umfeld verlassen. Umfassende, unveränderbare Audit-Logs und ein zentrales CISO Dashboard liefern die Dokumentation, die Datenschutzbehörden verlangen. Kiteworks unterstützt länderspezifische Bereitstellung in Deutschland, Frankreich, den Niederlanden und Großbritannien – mit integrierter NIS2- und DORA-Compliance-Dokumentation. Erleben Sie die Architektur in Ihrer Umgebung – vereinbaren Sie eine individuelle Demo.

Weitere Ressourcen 

• Blogbeitrag  
  Datensouveränität: Best Practice oder regulatorische Pflicht?
• eBook  
  Datensouveränität und DSGVO
• Blogbeitrag  
  Diese Fallstricke bei der Datensouveränität vermeiden
• Blogbeitrag  
  Best Practices für Datensouveränität
• Blogbeitrag  
  Datensouveränität und DSGVO [Daten­sicherheit verstehen]