Microsoft 365 is by far the most widespread office ecosystem in Switzerland, from two-person SMEs to cantonal hospitals. From a data-protection point of view, however, the platform is anything but a configured out-of-the-box product. It is a modular set of building blocks with dozens of services (Exchange Online, SharePoint, OneDrive, Teams, Purview, Defender, Copilot), evolving data-residency commitments and a group structure (Microsoft Corporation, Microsoft Ireland Operations Ltd., various sub-processors) that turns each Transfer Impact Assessment (TIA) into its own exercise.

This article shows:

• which legal foundations under the Federal Act on Data Protection (DSG) and the GDPR are mandatory for M365;
• what the EU Data Boundary promises and where its limits lie;
• which security and privacy settings every M365 tenant in Switzerland should set at a minimum;
• how Customer Key, Double Key Encryption and Sensitivity Labels interact;
• which audit-log and retention topics are critical for data-subject access and deletion duties;
• and what a practical configuration baseline for Swiss organisations looks like.

Legal anchors: DSG (Art. 6, 8, 9, 16, 22, 24), GDPR (Art. 28, 32, 44 et seq.), Schrems II (CJEU C-311/18), EU-US Data Privacy Framework, Microsoft Products and Services DPA, FINMA Circular 2018/3 on Outsourcing for regulated institutions.

When a Swiss organisation uses Microsoft 365, Microsoft becomes a data processor within the meaning of Art. 9 DSG and, where the GDPR applies, Art. 28 GDPR. The contractual basis is the Microsoft Products and Services Data Protection Addendum (DPA), which incorporates the EU Standard Contractual Clauses (SCC Module 2) and the Swiss Addendum.

Three points are critical in practice:

1. Accountability: You as the customer remain the controller and bear the full burden of proof for lawful processing, even though Microsoft as the cloud provider runs the technical platform.
2. Cross-border transfer: After Schrems II, signing SCCs is not sufficient if US authorities can access the data (FISA 702, CLOUD Act). You need a documented Transfer Impact Assessment, even when data is primarily stored in EU data centres.
3. Secondary processing: Microsoft processes diagnostic and telemetry data to improve its services. Here, Microsoft acts as independent controller, a situation the FDPIC (EDÖB) and the EDPB have criticised repeatedly. You must reflect this secondary processing in your privacy notice and your record of processing activities.

For FINMA-regulated institutions, the additional outsourcing logic under FINMA Circular 2018/3 applies: risk analysis, audit rights, exit plan and notification duties to FINMA must be documented separately.

Since 2024, Microsoft has used the EU Data Boundary to keep storage and processing of the core services (Microsoft 365, Dynamics 365, Power Platform, Azure) for EU/EFTA customers fully within EU/EFTA data centres. For Switzerland, this means standard workloads like Exchange Online, SharePoint, OneDrive and Teams are stored and processed in EU data centres (Dublin, Amsterdam, Frankfurt, Zurich), including diagnostic and service-generated data.

Important limits you must know:

• The EU Data Boundary does not cover all services. Specific functions (global spam/malware protection in Exchange Online Protection, Entra ID authentication tokens, some AI features like Microsoft 365 Copilot) may still be processed globally.
• When a Microsoft support case is escalated, data may be transferred to engineering teams outside the EU if you consent to support escalation.
• Microsoft group companies outside the EU remain contractually bound by the DPA, that helps contractually but does not change the theoretical CLOUD Act access risk.

The Swiss data-centre region (Switzerland North/West) is attractive for many SMEs because data primarily resides in Switzerland. For Microsoft 365, however, this region is not available for all services, and Microsoft Ireland Operations Ltd. remains the contracting processor.

M365 encrypts data at rest by default (BitLocker, Service Encryption) and in transit (TLS 1.2+). The critical question for Swiss organisations with heightened confidentiality needs is: who holds the keys?

1. Microsoft-Managed Keys: the default. Microsoft manages the keys; you have no technical lever to block official access.
2. Customer Key: you generate and manage the encryption keys in Azure Key Vault (or Azure Managed HSM). Microsoft needs the keys to decrypt during operation, but you can revoke them and thus cut off Microsoft's access. Requires Microsoft 365 E5 or the Microsoft 365 E5 Compliance licence.
3. Double Key Encryption (DKE): the highest level. Data is encrypted with two keys: one held by Microsoft, one held locally by you. Microsoft cannot decrypt the data technically. The trade-off: certain cloud features (search, Copilot, eDiscovery) no longer work.

Recommendation for Swiss SMEs: default encryption for most data, Customer Key for sensitive HR and personnel files, DKE only for the most sensitive datasets (health, criminal-record or boardroom material), and only with a clear understanding of the features you lose.

Microsoft Purview Information Protection (formerly Azure Information Protection) provides sensitivity labels, which let you classify and automatically protect documents and emails. A well-maintained label scheme is the backbone of any M365 data-protection architecture.

Typical label hierarchy for Swiss organisations:

• Public, no restrictions.
• Internal, employees only, no externals.
• Confidential, defined group only, AIP encryption, no download to personal devices.
• Strictly confidential / sensitive personal data (Art. 5(c) DSG), AIP plus Customer Key or DKE, watermarks, access only via Compliance Workstation.

Labels can be assigned automatically with auto-labeling policies, for example when a document contains AHV numbers, credit-card data or diagnostic codes (ICD-10). This auto-classification is today usually a prerequisite for reliable DLP (Data Loss Prevention) enforcement.

A pragmatic rollout sequence: first get labels ready for deployment, train manual classification, activate auto-labeling in audit mode, then after 4-6 weeks of tuning move to enforcement mode and switch in DLP rules alongside.

The rights of access (Art. 25 DSG / Art. 15 GDPR), rectification (Art. 32 DSG / Art. 16 GDPR) and erasure (Art. 32(2)(c) DSG / Art. 17 GDPR) are not trivial in M365. Data is spread across Exchange, SharePoint, OneDrive, Teams chats, Yammer/Viva Engage, Planner, To Do and not least backup versions.

Audit logs: Enable Unified Audit Log in Purview from day one. Default retention is 180 days (E3) or one year (E5); for regulated sectors a 10-year retention can be added. Logs are a prerequisite for breach forensics under Art. 24 DSG (72-hour window once a high-risk breach becomes known).

Retention policies: Define retention rules per data category. Typically 10 years post-exit for HR files, 5-7 years for general business emails, 2-3 years for marketing contacts. Without a retention policy, Microsoft's default is indefinite, which is problematic from a data-protection standpoint.

eDiscovery vs. DSG: eDiscovery searches can surface massive personal datasets. You need an internal four-eyes principle, a documented legal basis and, where employees are concerned, prior notification under Art. 19 DSG, unless that would defeat the investigation.

We recommend a minimum baseline for every Swiss M365 tenant:

1. Identity: Entra ID with MFA for all users (Conditional Access), phishing-resistant MFA (FIDO2, Windows Hello) for admins. Privileged Identity Management for eligible roles.
2. Data residency: select region Switzerland North or Europe when provisioning the tenant. A later change is not possible.
3. Encryption: Customer Key for Exchange, SharePoint, OneDrive (E5 licence required) for sensitive workloads.
4. Information protection: sensitivity labels with auto-labeling for sensitive personal data (Art. 5(c) DSG).
5. DLP: Microsoft Purview DLP for Exchange, Teams, SharePoint, rule sets for AHV numbers, IBAN, credit cards, diagnostic codes.
6. Audit & retention: Unified Audit Log enabled, retention policies per data category, backup strategy with an explicit deletion procedure.
7. Copilot: before rollout, run a DPIA, clarify the data scope (what Copilot may see, what it may not), sensitivity labels are a prerequisite. Audit mode first.
8. Third-party apps: enable App Governance via Entra ID, switch user OAuth consent to admin approval, run regular reviews.

This baseline is not for its own sake, it derives directly from the accountability duties under Art. 8 and Art. 22 DSG as well as Art. 24, 25, 32 GDPR. Whoever sets it up cleanly will be at a defensible compliance level in case of an audit.

SIDD supports Swiss companies, NGOs and administrative bodies with the privacy-compliant rollout and operation of Microsoft 365. We combine legal expertise (DSG/GDPR/FINMA Circular 2018/3) with technical depth in Entra ID, Purview, Defender and Copilot.

Typical mandates:

• Data Protection Impact Assessment (DPIA) before M365 rollout or before introducing Copilot;
• Drafting of the data processing agreement and the TIA documentation;
• Tenant configuration review against our SIDD baseline;
• Mandates as external data-protection advisor or external CISO/ISB;
• ISO/IEC 27001 support, where M365 is covered as the main platform (ISO 27001 / ISMS);
• Penetration tests and phishing simulations against M365 (penetration testing);
• Awareness workshops for staff and admins (IT security workshop).

Write to us via the contact form or request a quote via the quote form. We deliver an initial tenant diagnosis within 5 working days.