# Microsoft 365 datenschutzkonform in der Schweiz betreiben > Microsoft 365 datenschutzkonform betreiben: Rechtsrahmen, EU Data Boundary, Verschlüsselung, Sensitivity Labels, Audit-Logs und Konfiguration. - Quelle: https://www.sidd.swiss/einblicke/microsoft-365-datenschutz-schweiz/ - Sprache: de-CH - Veröffentlicht: 2026-05-24 - Stand: 2026-05-24 - Autor:in: Oliver Stutz - Herausgeber: SIDD Institut für Datenschutz und Datensicherheit, eine Marke der Priverion GmbH, Zugerstrasse 32, 6340 Baar (ZG), Schweiz ## Einleitung Microsoft 365 ist in der Schweiz das mit Abstand am meisten verbreitete Office-Ökosystem – vom Zwei-Personen-KMU bis zum kantonalen Spital. Datenschutzrechtlich ist die Plattform jedoch alles andere als ein konfiguriertes Out-of-the-box-Produkt. Sie ist ein modularer Bauklotz mit dutzenden Diensten (Exchange Online, SharePoint, OneDrive, Teams, Purview, Defender, Copilot), wechselnden Datenresidenzversprechen und einer Konzernstruktur (Microsoft Corporation, Microsoft Ireland Operations Ltd., diverse Subprozessoren), die jedes *Transfer Impact Assessment* (TIA) zu einer eigenen Übung macht. Dieser Artikel zeigt: - welche Rechtsgrundlagen aus dem DSG und der DSGVO für M365 zwingend sind; - was der **EU Data Boundary** verspricht und wo seine Grenzen liegen; - welche Sicherheits- und Datenschutz-Konfigurationen jeder M365-Tenant in der Schweiz mindestens setzen sollte; - wie *Customer Key*, *Double Key Encryption* und *Sensitivity Labels* zusammenspielen; - welche Audit-Log- und Retention-Themen für Auskunfts- und Löschpflichten kritisch sind; - und wie ein praxistauglicher Konfigurations-Baseline für Schweizer Unternehmen aussieht. Rechtsanker: DSG (insb. Art. 6, 8, 9, 16, 22, 24), DSGVO (insb. Art. 28, 32, 44 ff.), Schrems II (EuGH C-311/18), EU-US Data Privacy Framework, Microsoft Products and Services DPA, FINMA-Rundschreiben 2018/3 «Outsourcing» für regulierte Institute. ## Rechtsrahmen – DSG, DSGVO und Schrems II Wenn ein Schweizer Unternehmen Microsoft 365 einsetzt, wird Microsoft zum **Auftragsbearbeiter** im Sinne von Art. 9 DSG und – soweit die DSGVO greift – Art. 28 DSGVO. Die vertragliche Grundlage liefert das Microsoft Products and Services Data Protection Addendum (DPA), das die Standardvertragsklauseln (EU SCC Module 2) und den Swiss Addendum integriert. Drei Punkte sind in der Praxis kritisch: 1. **Verantwortlichkeit:** Sie als Kunde bleiben Verantwortlicher und tragen die volle Beweislast für eine rechtskonforme Bearbeitung – auch wenn Microsoft als Cloud-Anbieter die technische Plattform stellt. 2. **Cross-Border-Transfer:** Nach Schrems II reicht der reine Abschluss von SCC nicht aus, wenn US-Behörden auf die Daten zugreifen können (FISA 702, CLOUD Act). Sie müssen ein dokumentiertes Transfer Impact Assessment führen – auch wenn die Daten primär in EU-Rechenzentren liegen. 3. **Sekundärbearbeitungen:** Microsoft verarbeitet Diagnose- und Telemetriedaten zur Verbesserung seiner Dienste. Hier gilt Microsoft als **eigener Verantwortlicher** – ein Umstand, den der EDÖB und die EDSB der EU mehrfach kritisiert haben. Sie müssen diese Sekundärbearbeitungen in Ihrer Datenschutzerklärung und Ihrem Bearbeitungsverzeichnis abbilden. Für FINMA-regulierte Institute kommt die zusätzliche Outsourcing-Logik nach RS 2018/3 dazu: Risikoanalyse, Audit-Rechte, Exit-Plan und Meldepflichten an die FINMA müssen separat dokumentiert sein. ## EU Data Boundary – Versprechen und Grenzen Mit dem **EU Data Boundary** hat Microsoft seit 2024 die Speicherung und Verarbeitung der wichtigsten Kerndienste (Microsoft 365, Dynamics 365, Power Platform, Azure) für EU- und EFTA-Kunden vollständig auf Rechenzentren innerhalb der EU/EFTA verlagert. Für die Schweiz bedeutet das: Standard-Workloads wie Exchange Online, SharePoint, OneDrive und Teams werden in EU-Rechenzentren (z. B. Dublin, Amsterdam, Frankfurt, Zürich) gespeichert und verarbeitet, inklusive Diagnosedaten und automatisierter Service-Generated Data. Wichtige Einschränkungen, die Sie kennen müssen: - Der EU Data Boundary deckt nicht alle Dienste ab. Bestimmte Funktionen (z. B. globaler Spam-/Malware-Schutz in Exchange Online Protection, Authentifizierungstoken über Entra ID Global, bestimmte AI-Features wie Microsoft 365 Copilot) können weiterhin global verarbeitet werden. - Bei Eskalation eines Microsoft-Support-Falls können Daten an Engineering-Teams ausserhalb der EU übermittelt werden, sofern Sie der Support-Eskalation zustimmen. - Microsoft-Konzerngesellschaften ausserhalb der EU bleiben rechtlich an das DPA gebunden – das schützt vertraglich, ändert aber nichts an der theoretischen CLOUD-Act-Zugriffsmöglichkeit. Die Schweizer Rechenzentrum-Region (Switzerland North/West) ist für viele KMU eine attraktive Option, weil Daten primär in der Schweiz residieren. Für Microsoft 365 ist diese Region jedoch nicht in allen Diensten verfügbar, und auch hier bleibt Microsoft Ireland Operations Ltd. der vertragliche Auftragsbearbeiter. ## Verschlüsselung und Customer Key M365 verschlüsselt Daten standardmässig at rest (BitLocker, Service Encryption) und in transit (TLS 1.2+). Die kritische Frage für Schweizer Unternehmen mit erhöhten Vertraulichkeitsanforderungen lautet: **Wer hält die Schlüssel?** 1. **Microsoft-Managed Keys:** Default. Microsoft verwaltet die Schlüssel, Sie haben keinen technischen Hebel, einen behördlichen Zugriff zu blockieren. 2. **Customer Key:** Sie generieren und verwalten die Verschlüsselungsschlüssel in Azure Key Vault (oder Azure Managed HSM). Microsoft braucht die Schlüssel zum Entschlüsseln im Betrieb, aber Sie können die Schlüssel widerrufen und damit Microsoft den Datenzugriff entziehen. Voraussetzung: Microsoft 365 E5 oder Lizenz *Microsoft 365 E5 Compliance*. 3. **Double Key Encryption (DKE):** Höchste Schutzstufe. Daten werden mit zwei Schlüsseln verschlüsselt: einem von Microsoft und einem von Ihnen lokal gehalten. Microsoft kann die Daten technisch nicht entschlüsseln. Dafür funktionieren bestimmte Cloud-Features (Suche, Copilot, eDiscovery) nicht mehr. Empfehlung für Schweizer KMU: Standardverschlüsselung für die meisten Daten, Customer Key für sensible Personalakten und HR-Daten, DKE nur für besonders schützenswerte Datensätze (Gesundheits-, Strafregister- oder Boardroom-Material) – und das mit klarem Bewusstsein, welche Funktionen Sie damit verlieren. ## Sensitivity Labels und Information Protection Microsoft Purview Information Protection (vormals Azure Information Protection) bietet **Sensitivity Labels**, mit denen Sie Dokumente und E-Mails klassifizieren und automatisch schützen können. Ein gut gepflegtes Label-Schema ist das Rückgrat jeder M365-Datenschutz-Architektur. Typische Label-Hierarchie für Schweizer Unternehmen: - **Öffentlich** – keine Einschränkungen. - **Intern** – nur Mitarbeitende, keine Externen. - **Vertraulich** – nur definierter Personenkreis, AIP-Verschlüsselung, kein Download auf private Geräte. - **Streng vertraulich / besonders schützenswerte Daten** (Art. 5 lit. c DSG) – AIP plus Customer Key oder DKE, Wasserzeichen, Watermark, Zugriff nur über Compliance Workstation. Labels lassen sich mit **Auto-Labeling-Richtlinien** automatisch zuweisen, z. B. wenn ein Dokument AHV-Nummern, Kreditkartendaten oder Diagnosecodes (ICD-10) enthält. Diese Auto-Klassifikation ist heute meist Voraussetzung dafür, dass DLP-Richtlinien (Data Loss Prevention) zuverlässig greifen. Eine pragmatische Reihenfolge bei der Einführung: erst Labels rollout-bereit machen, dann manuelle Klassifikation trainieren, dann Auto-Labeling in Audit-Mode aktivieren, dann nach 4-6 Wochen Tuning in Enforcement-Mode schalten und parallel DLP-Regeln dazuschalten. ## Audit-Logs, Retention und Betroffenenrechte Die Auskunfts- (Art. 25 DSG / Art. 15 DSGVO), Berichtigungs- (Art. 32 DSG / Art. 16 DSGVO) und Löschpflichten (Art. 32 Abs. 2 lit. c DSG / Art. 17 DSGVO) sind in M365 nicht trivial. Daten liegen verteilt über Exchange, SharePoint, OneDrive, Teams-Chats, Yammer/Viva Engage, Planner, To Do und nicht zuletzt in Backup-Versionen. **Audit Logs:** Aktivieren Sie *Unified Audit Log* in Purview von Tag eins an. Standard-Aufbewahrung beträgt 180 Tage (E3) oder ein Jahr (E5); für regulierte Sektoren kann eine 10-Jahres-Aufbewahrung gebucht werden. Logs sind Voraussetzung für Datenpannen-Forensik nach Art. 24 DSG (72-Stunden-Frist ab Kenntnis einer Verletzung mit hohem Risiko). **Retention Policies:** Definieren Sie Aufbewahrungsregeln pro Datenkategorie. Für HR-Akten typischerweise 10 Jahre nach Austritt, für allgemeine Geschäftsmails 5-7 Jahre, für Marketing-Kontakte 2-3 Jahre. Ohne Retention Policy gilt der Microsoft-Standard von *unbegrenzt* – und das ist datenschutzrechtlich heikel. **eDiscovery vs. DSG:** eDiscovery-Suchen können massive Personendatensätze erschliessen. Sie brauchen ein internes Vier-Augen-Prinzip, eine dokumentierte Rechtsgrundlage und – falls Mitarbeitende betroffen sind – eine vorherige Information nach Art. 19 DSG, soweit dies die Untersuchung nicht vereitelt. ## Konfigurations-Baseline für die Schweiz Wir empfehlen jedem Schweizer M365-Tenant einen Mindest-Baseline: 1. **Identity:** Entra ID mit MFA für alle Benutzer (Conditional Access), Phishing-resistente MFA (FIDO2, Windows Hello) für Admins. Privileged Identity Management für Eligible-Roles. 2. **Datenresidenz:** Region *Switzerland North* oder *Europe* bei Provisioning des Tenants. Ein nachträglicher Wechsel ist nicht möglich. 3. **Verschlüsselung:** Customer Key für Exchange, SharePoint, OneDrive (E5-Lizenz vorausgesetzt) für sensible Workloads. 4. **Information Protection:** Sensitivity Labels mit Auto-Labeling für besonders schützenswerte Personendaten (Art. 5 lit. c DSG). 5. **DLP:** Microsoft Purview DLP für Exchange, Teams, SharePoint – Regelsets für AHV-Nummern, IBAN, Kreditkarten, Diagnosecodes. 6. **Audit & Retention:** Unified Audit Log eingeschaltet, Retention Policies pro Datenkategorie, Backup-Strategie mit explizitem Löschverfahren. 7. **Copilot:** Vor dem Roll-out – DPIA durchführen, Datenrahmen klären (welche Daten darf Copilot sehen, welche nicht), Sensitivity Labels sind Voraussetzung. Audit-Mode zuerst. 8. **Drittparteien-Apps:** App-Governance über Entra ID einschalten, OAuth-Zustimmung von Benutzern auf Admin-Approval setzen, regelmässige Reviews durchführen. Diese Baseline ist kein Selbstzweck, sondern direkt aus den Nachweispflichten von Art. 8 und Art. 22 DSG sowie Art. 24, 25, 32 DSGVO ableitbar. Wer sie sauber aufsetzt, hat im Prüfungsfall ein verteidigbares Compliance-Niveau. ## Wie SIDD unterstützt SIDD begleitet Schweizer Unternehmen, NPOs und Verwaltungseinheiten bei der datenschutzkonformen Einführung und dem Betrieb von Microsoft 365. Wir kombinieren juristische Expertise (DSG/DSGVO/FINMA RS 2018/3) mit technischer Tiefe in Entra ID, Purview, Defender und Copilot. Typische Mandate: - Datenschutz-Folgenabschätzung (DPIA) vor dem M365-Roll-out oder vor der Copilot-Einführung; - Erstellung des Auftragsbearbeitungsvertrags und der TIA-Dokumentation; - Tenant-Konfigurations-Review gegen unsere SIDD-Baseline; - Mandate als externer [Datenschutzberater](https://www.sidd.swiss/leistungen/datenschutzberater-schweiz) oder externer [CISO/ISB](https://www.sidd.swiss/leistungen/ciso-isb-iso); - ISO/IEC 27001-Begleitung, in der M365 als Hauptplattform abgedeckt wird ([ISO 27001 / ISMS](https://www.sidd.swiss/leistungen/isms-iso27001)); - Penetrationstests und Phishing-Simulationen gegen M365 ([Penetrationstest](https://www.sidd.swiss/leistungen/penetrationstest)); - Awareness-Workshops für Mitarbeitende und Admins ([IT-Sicherheits-Workshop](https://www.sidd.swiss/leistungen/it-sicherheits-workshop-kmu)). Schreiben Sie uns über das [Kontaktformular](https://www.sidd.swiss/kontakt) oder fordern Sie ein Angebot über das [Offertformular](https://www.sidd.swiss/offerte) an. Wir liefern eine erste Tenant-Diagnose innerhalb von 5 Arbeitstagen. --- Dieses Dokument ist die Markdown-Fassung der oben verlinkten Seite. Zitieren Sie bitte die HTML-URL.