Why “Data in Switzerland” Is Not Enough

Moving from Residency to Control in Microsoft 365

Every conversation about data sovereignty in regulated industries tends to start the same way:

“We use Multi-Geo. The data stays in Switzerland.”

It’s the right starting point. Microsoft 365 Multi-Geo allows organizations to place selected workloads - SharePoint sites, OneDrive accounts, Teams data, or Exchange mailboxes - into specific regions, including Switzerland, while maintaining a single global tenant. This makes it possible to align sensitive data with regulatory or customer requirements without fragmenting the overall environment.

But it only answers one question:

Where is the data stored?

It does not answer who accessed the data, from where, under which conditions, or what happened after access. That is where the real problem begins.

A scenario that happens every day

A Swiss engineering firm stores sensitive project documentation in Switzerland using Multi-Geo. An external contractor - working from an unmanaged device outside Switzerland - is granted access to review a file. The document opens. The data is now on a screen in an unknown location, on a device with no compliance posture, in a session with no restrictions.

From the platform’s perspective, residency was enforced. From a sovereignty perspective, control was lost the moment access was granted without conditions.

The file never left Switzerland. But sovereignty did.

Residency is static. Control is not.

The moment a document is opened, storage location stops being the relevant boundary. The file is no longer just “in Switzerland.” It moves instantly across endpoints and browsers, collaboration tools like Teams, external users and partners, and increasingly AI-driven contexts.

The infrastructure remains unchanged. The data does not. From the platform’s perspective, everything is working as designed - access was granted, residency was enforced - and control was lost.

Most “data in Switzerland” strategies fail at exactly this moment: when the data is used.

The shift: from location to conditions

If data sovereignty is the goal, the question must change. Not “Where is the data stored?” but:

Under which conditions can data be accessed and used?

This shift fundamentally changes the architecture. Control must be applied across three distinct layers - and all three must be connected.

Layer 1: Access is conditional, not static

Conditional Access extends control beyond authentication and turns it into continuous evaluation. Access decisions can depend on:

• Device compliance
• Location (geo-restriction)
• Identity and risk signals

Multi-Geo ensures data is placed correctly. Conditional Access ensures it is reachable only under defined conditions. The two must work together - residency without access governance is an incomplete control.

Layer 2: The session is the real risk surface

Even with strict access controls, risk remains. A session is an exposure surface by design. During an active session, data is viewed, copied, shared, processed by applications, and connected to AI prompts.

The gap does not appear at storage or authentication. It appears during active usage - inside the session. This is the layer most architectures do not explicitly address.

Controls must extend into the session itself: limiting data transfer and replication, restricting interaction patterns, and enforcing policies in real time. Access is no longer a one-time event. It becomes continuously governed.

This becomes even more critical as AI assistants consume content across SharePoint, Teams, Exchange, and other Microsoft 365 services. The question is no longer only where the source document resides - but whether the AI interaction itself is governed by the same access and protection controls as direct access.

Layer 3: The document becomes the control point

The most durable control does not sit in the network or in the session. It sits in the data itself.

In regulated industries, organizations often arrive at this architecture having first evaluated sovereign or national encryption solutions. The decision to rely on native Microsoft 365 Purview encryption rather than a separate layer comes down to integration: AES-256 protection operating natively at file, user, and SharePoint level - including geo-based access restrictions - without an additional system to maintain.

When protection is applied directly to the document through Microsoft Purview:

• Sensitivity labels define classification - automatically assigned based on content
• Encryption enforces access - AES-256, bound to the file itself
• IRM controls usage - view, copy, print, share, and presentation rights
• DLP governs movement across services - preventing data from leaving defined boundaries
• Dynamic watermarking tracks exposure - applied on open, view, or print

At that point, access is enforced by the file, usage restrictions travel with it, and control persists regardless of location.

The document becomes the perimeter.

Platform control: limiting provider access

One dimension often overlooked in sovereignty discussions is platform access itself. Even a perfectly configured tenant is only as sovereign as the controls placed on the operator.

Customer Lockbox ensures that even Microsoft support cannot access customer data without explicit, logged, time-bound approval. Every access request is visible, auditable, and subject to customer veto.

Data control applies not only to users - but also to the platform operating the service.

Enforcement requires an integrated architecture

Most organizations already have the required capabilities: Multi-Geo, Conditional Access, session control, Purview (labels, encryption, DLP, IRM), and monitoring. The issue is not capability. It is fragmentation.

In practice, fragmentation looks like this: residency is configured in one project, Conditional Access policies are managed by a different team, and Purview labels were applied during a compliance initiative that never connected to the access layer. The tools exist. The signals do not flow between them.

When designed as a single architecture:

• Data is placed intentionally - residency aligned to regulatory requirements
• Access is governed by context - device, location, and identity evaluated continuously
• Usage is controlled dynamically - session-level restrictions enforced in real time
• Protection is embedded in the document - encryption and IRM travel with the file
• Signals are connected across the platform - monitoring feeds access policy, not just audit logs

“Data in Switzerland” becomes not just a statement - but an enforceable system property.

Closing thought

Placing data in Switzerland is the right first step. Multi-Geo makes it possible, even in global environments. But residency alone is not control.

Data residency answers where information is stored. Data sovereignty requires proving who can access it, under which conditions, and what controls remain in place after access is granted.

In Microsoft 365, sovereignty is no longer defined by geography alone. It is defined by the ability to enforce control wherever the data travels.