Sovereign Workplace
Digital sovereignty for a Microsoft 365 workplace, broken into decisions you can size, sequence and start on.

For years I was a firm believer in the cloud-based Microsoft 365 workplace, and I bet a good part of my career on it. Digital sovereignty looked like a theoretical exercise that no real organisation could afford.
I’m less sure now. Things we took for granted are being questioned, and I’m still working out what that means for the workplaces I help build. I have nothing useful to add to the geopolitical commentary.1 What I can do is help untangle the Microsoft 365 dependencies most organisations are tied into.
There are generally two views. The closer someone works to the platform, the more inevitable it looks: “We’re on M365, there’s not much we can do.” I’ve said that sentence myself. Further away from the platform, it looks simpler than it is: “We just need to get out of the US cloud.” Neither helps you decide what to do on Monday.
Sovereignty is a matter of degree. What matters is whether you can still control, change or replace the dependencies that count. You depend on a provider in four separate ways, and you can reduce each on its own, at very different costs: keeping an independent copy of your data is cheap, running your own identity platform isn’t. And not all data needs the same level: a press release doesn’t need what client data under banking secrecy does.
Most Swiss organisations run on Microsoft 365, so that’s the estate this page starts from. It breaks the topic into decisions you can size, sequence and start on, for architects and workplace leaders who want to start the discussion inside their organisation. It doesn’t recommend a provider, and it’s not about geopolitics. The decisions stay with you.
Why now
The cheapest time to create an alternative is before you need one. Three things usually force the question: a renewal, a regulatory change, or a dependency that turns out to be strategic, such as a critical process that only works on one provider’s platform.
Renewal is the one with a date. It’s when terms, scope and exit clauses can change without breaking anything, and the thinking has to be done before you sign. Most organisations arrive there with the commercial questions prepared and the dependency questions still unasked.
The damage from dependency so far has mostly been about money. In a 2026 study by HSLU and ti&m,2 about 47 of the 200 firms analysed had experienced an incident caused by dependency on a provider. Among them, 61.7% named price increases and only 10.6% loss of control over their data, although data control tops the list of perceived risks. The Microsoft 365 price increase from July 2026 is modest for enterprise plans (roughly +8% for E3 and +5% for E5, more for frontline plans).3 But it lands at renewal, which is when you find out how much room you really have to negotiate. The sovereignty model I use further down, from a study for the digital directors of the French- and Italian-speaking cantons (CLDN), has a dimension for exactly this: change control, meaning whether you can decide if and when a new version, licence or price takes effect.
Most organisations can’t size their exit cost today. In the same study, 30 to 45% answered “don’t know” to the questions on investment and price. Working that out now is cheap. Working it out under pressure isn’t.
Waiting for a clear signal doesn’t help either. When a market-wide shock comes, everyone moves at once and queues for the same few experts, migration partners and hosting capacity. For example, a study for Digital Public Services Switzerland estimates that only 30 to 80 people in Switzerland have hands-on experience with openDesk.4 How you get there comes back to what that queue means for sequencing.
The federal administration is already building a second track. It finished rolling out Microsoft 365 to about 54,000 workplaces in December 2025.5 In September 2026 the Federal Chancellery started a programme for a fallback workplace for about 3,000 staff in critical processes, next to Microsoft 365.6
Sovereignty is a degree
Sovereignty isn’t something a platform has or lacks. You depend on a provider in four separate ways, and you can reduce each of them on its own.
| Dependency | What it means in practice | Typical lever | CLDN dimensions |
|---|---|---|---|
| The provider can read it | Provider staff or a foreign authority could access your content | Own keys (DKE), data placement | AccessData processingData location |
| The provider holds the only usable copy | If the service goes, your data goes with it | Independent backup and archive, readable without the provider | Data extractionExit strategy |
| The provider must operate it | It works only as long as they keep running it for you | Local or partner operation, a second channel for critical processes | System availabilityChange controlAccessContracts |
| You can’t work without their technology | Even if someone else ran it, it would still be their software | Substitution, open standards | System developmentLegal frameworkExpertise |
The first two are the cheaper ones. Keys and backups can be set up for one class of data at a time, inside the estate you already have. The last two get expensive quickly, because they touch how the whole workplace runs.
The four overlap, and they separate control from independence. With Double Key Encryption, Microsoft can’t read the document, but it still runs the service, writes the software and signs in the users who can. You can have control without independence, and independence without a realistic way to replace the provider.
How far you can split shows which parts of the workplace each dependency sits in, using a vendor-neutral workplace capability model with a Microsoft view on top.
Microsoft 365 Local shows how the last two differ. Run disconnected, it moves who operates the service, because Exchange, SharePoint and Skype for Business Server run on infrastructure you own and manage. It doesn’t change whose technology you depend on.7
Reducing the second and fourth dependencies also changes your position at renewal. A provider who knows you could leave negotiates differently.
Where the detail comes from
The four dependencies are my own shorthand. The detail behind them comes from a study by AWK Group for the Conférence latine des directrices et directeurs cantonaux du numérique (CLDN): « Étude d’opportunités pour un cloud souverain » (May 2023).8 It was written for cantonal administrations, but the model works for any organisation.9
The study describes sovereignty along 12 dimensions, grouped by the life of a system:
- Building and evolving it: system development, sustainability
- Using it: data processing, data location, system availability, access to system and data, change control
- Retiring it: exit strategy, data extraction
- Framework: legal framework, expertise, contracts
Each dimension has three levels, from 1 (basic requirements) to 3 (full control and autonomy). The study mentions a level 0 for no requirement and leaves it out; I use it as a target for data that needs nothing special, and as a result when a set-up doesn’t even reach level 1.
Level 3 isn’t the goal. In the study’s own options, a service someone else runs stops at level 2 on 9 of the 12 dimensions. Only data processing, data location and access can reach 3 without running it yourself, and only in a service built or adapted for you, with extra effort. So for anything someone else runs, level 2 is the realistic target, and level 3 is an expensive choice for what you decide to run yourself.
For most of your data, that cost isn’t worth it. For a small part of it, it can be: regulated data, or the few secrets that would seriously damage the company if they leaked and that are worth something to an attacker. For those, the level 3 that matters is mostly about who can read the data. That’s the one exception to running it yourself: a service built or adapted for you can get there. Those don’t have to live on the same platform at the same level as everything else. Telling them apart is the next step: how much, and where.
The study is also honest about the cost. More sovereignty means more of your own effort, including for security. Large cloud providers invest far more in security than most organisations can, and hosting in Switzerland improves your legal position, not your technical security.
How much, and where
Not all data needs the same level, and neither does every process. Two inputs set your target: how sensitive the data is, and how critical the process is that depends on it.
Data class
I use four classes. Your organisation probably has its own names for them.
- Public information: press releases, published reports, the website
- General internal: most day-to-day work
- Company confidential: strategy, contracts, HR, anything that would hurt if it leaked
- Regulated: data where the rules come from outside the company, such as banking secrecy, FINMA requirements or health data
Sensitivity mostly drives the first dependency: who can read it. The higher the class, the more it matters who holds the keys and where the data sits.
Criticality
Criticality is a separate question. A process can handle only internal data and still be critical, for example crisis communication or payment approvals. If a process is critical, you need level 2 for system availability, change control and exit strategy, and a second channel for critical communication that people have practised in an exercise.
What changes your target, and what tests it
Some events raise the level you need. Others test whether your current setup holds. Each one hits a different dependency, which is why the cheap steps from the four dependencies tend to cover several at once.
| Trigger | Dependency it hits | Effect |
|---|---|---|
| Compelled disclosure (CLOUD Act) | The provider can read it | Tests your current state |
| Loss of the transfer basis (Swiss-U.S. Data Privacy Framework10) | The provider can read it, legal framework | Raises your target |
| A regulator or supervisor tightens rules (FINMA, privatim) | Mostly “can read it”, per data class | Raises your target |
| Service denial (sanctions, export controls) | The provider must operate it | Tests your current state |
| Price shock | The provider must operate it (change control), and you can’t work without their technology (exit cost) | Tests your current state; already happening |
I’m not predicting any of these, only showing which dependency each one would hit.
The Day-2 test
The simplest way to make this concrete is one question:
You lose access for 30 days because the provider can’t or won’t serve you any more. What still works?
Thirty days is an illustration. In a real exercise, use the disruption tolerance your organisation sets for each critical process.
Unlike in a normal outage, the provider isn’t working to bring you back. It’s the cause. Public examples exist: in June 2026, US export controls led Anthropic to suspend access to two of its AI models for almost three weeks.11
The CLDN study deliberately covers only a stable situation and leaves this crisis case out of scope. I come back to it in a separate post, Day 2 without Microsoft.
A mature operator is still one operator
Microsoft’s operation is mature and publicly measured. It publishes worldwide uptime per quarter12 and backs a 99.9% SLA financially. For most data that’s a good argument against needing level 3 availability, and it’s the stable case the CLDN study scores.
The record has dips. Q1 2026 came in at 99.526%, the lowest quarter in Microsoft’s published table, before Q2 returned to 99.994%. These are worldwide figures across all workloads, not per region or tenant.
Regulators read the same reliance as concentration risk. In November 2025 the European Supervisory Authorities designated Microsoft Ireland Operations Limited a critical ICT third-party provider under DORA.13 Switzerland isn’t bound by DORA, but a peer regulator clearly sees the risk that when the shared provider fails, everyone fails and queues at once.
For the Day-2 case maturity doesn’t help, because a well-run operator can still be compelled to stop serving you.
Set your target
Open the Sovereign Workplace Map. Pick a data class and whether it supports a critical process, then where the class lives, what you add and how far it is: assumed, configured or tested. The four tiles show what stays open, how many items each is short, and the cheapest next step. Your choices stay in your browser.
What you can do in the estate you have
Several levers work without leaving Microsoft 365. Each moves different dimensions, none moves all of them, and most combine per data class. Treat them as options you pick per class, not as stages.
| Lever | What it moves | What it doesn’t move | Where the cost sits |
|---|---|---|---|
| Independent backup and archive | Recovery after deletion, ransomware or a tenant incident. Data extraction and exit, if the copy sits with another operator, under another legal domain, and is readable without Microsoft 365 | Sovereignty, if the copy stays inside the same provider’s control plane: then it’s resilience only | Storage and a restore test you actually run |
| Double Key Encryption (DKE)14 | Confidentiality of labelled documents, including against the provider | Availability and operation. Copilot, search, eDiscovery and DLP can’t see the content; no co-authoring or web opening. Teams chat, meetings and calendar items can’t be protected | Your own key service, and friction for every user who handles those documents |
| Customer Key15 | Control of the root keys; revoking them leads to cryptographic deletion at exit | Provider access during operation: Microsoft holds an availability key, and service code can fall back to it | Key management; little user impact |
| Data placement per data class | Most dimensions for the class you move out | Identity and device trust, unless you separate them as well (see below) | A second store, the seam between the two, and training for the people who work in it |
| Microsoft 365 Local7 | Data location and who operates the service, if you run it disconnected. Connected, Azure stays the control plane for the infrastructure | Microsoft as software supplier: it runs the same Exchange and SharePoint Server products as on-premises, with Microsoft’s lifecycle, licences and updates. Most cloud features are gone | Your own hardware and operation, through an authorised partner |
| Advanced Data Residency (ADR)16 | Contractual data location in Switzerland for services beyond the core, such as Defender for Office 365, Office for the web and parts of Purview. Exchange, SharePoint, OneDrive, Teams and Microsoft 365 Copilot are already committed for a Swiss tenant | Data in processing, access, availability, the technology. It covers the whole tenant, so it can’t be applied to one data class | An add-on licence for every paid user |
| Second channel for critical communication | Readiness for the Day-2 case in critical processes | The availability score, which rates one system at a time; the day-to-day dependency | Mostly organisational: who switches, the contact lists, the exercises |
Keys move less than they seem to. The DKE key service releases the key to whoever Entra ID authorises, so while sign-in and the device check run through Microsoft, the map caps access at 1. Level 3 for access needs a service built or adapted for you plus an access path you control, or running it yourself.
Two smaller levers are worth a line each: an independent copy of audit and security logs, so you have evidence after an incident without the tenant; and exit readiness (an inventory, tested exports, a written plan). AI has its own subsection below.
I leave Customer Lockbox out of the table. It lets you approve Microsoft engineers’ access in routine support cases. That’s useful comfort in normal operation, but I haven’t seen evidence that it changes anything when access is legally compelled.
None of these levers touches identity. Entra ID still decides who signs in to everything, including a separate store whose sign-in or device check runs through Microsoft. That’s the ceiling the next section is about.
In the map above, pick a data class, where it lives and what you add, and the four tiles show which dependencies stay open and what the cheapest next step is. Its workshop view shows which lever raised which dimension, and the plan across all four classes.
AI across the four dependencies
AI adds no new dependency, but it sharpens the four you already have, and it changes faster than the rest of the estate. The facts below are from Microsoft Learn, checked on 6 November 2026.
| What to look at | Dependency it touches | What to check | Lever |
|---|---|---|---|
| Where prompts are processed | The provider can read it | A Swiss tenant is in scope for the EU Data Boundary,17 which includes the EFTA countries. Inference runs inside the EU and EFTA, not necessarily in Switzerland. With flex routing18 allowed, it can move to the US, Canada or Australia at peak load; tenants created after 25 March 2026 have it on by default. Anthropic models sit outside the EU Data Boundary19 | Turn flex routing off; decide which models are allowed |
| What the assistant can reach | The provider can read it | Copilot sees what the user can see. Oversharing nobody noticed becomes something Copilot surfaces on request. Content encrypted without extraction rights, including DKE, stays out of reach | Clean up permissions before rollout; labels with usage rights; placement per data class |
| Which other services join in | The provider can read it, and now a second party can too | Agents and connectors bring their own terms. Web search sends queries Copilot generates from the prompt to Bing | An allowlist of agents; web search off where a class needs it |
| What it does on your behalf | The provider must operate it; you can’t work without their technology | Agents that act for users move process logic into the provider’s platform. On Day 2 they stop, and the logic rarely moves with you | An inventory of agents that act; a manual fallback for critical processes |
Storage is the easy part. Prompts and responses are stored with the tenant’s other content, under the same residency commitments,20 so in Swiss tenants they’re stored in Switzerland. Retention is set in Purview like for any other content. Processing location is the open question, and it’s a tenant setting, not a contract term: an AI administrator can change it at any time. I couldn’t find Microsoft documentation that commits to processing inside Switzerland.
For Regulated content the cheap answer is the one from How much, and where, keeping it out of reach by placement or encryption. The price is the one from How you get there, because that class loses the AI features built into mail, documents and meetings.
How far you can split
Content can be split per data class. The control plane doesn’t split cheaply. You can separate parts of it, but each part you separate is one you now run yourself, and federation keeps the original operator in the path. That’s the ceiling of any partial exit, and it’s why partial sovereignty usually means sovereign content on a control plane you don’t control.
The workplace capability model shows this as rings around the content. The further out a capability sits, the cheaper it is to move for one data class. The closer to the control plane, the more every class depends on it.
Each ring outward is shared by more of the work and is harder to split for one class. The two cut points are where a split can reach into the control plane without duplicating it.
Pick a data class in the map below and each capability shows what you’d do for it: nothing extra, add a control, or separate it. Up to Company confidential, everything stays on one platform with a few controls. Regulated is where parts get separated, and identity stays shared for every class. Switch to the map’s Microsoft view and point at Entra ID to see why: every capability depends on it.
What a content carve-out changes
Take the common case: regulated data moves to a separate content store, and sign-in stays on Entra ID. For that class, the dimensions move like this.
| Effect for the carved-out class | Dimensions |
|---|---|
| Improves | Data location; data processing (Copilot and other Microsoft AI no longer touch that class); data extraction |
| Improves partly | Exit strategy (the class has left, the identity exit hasn’t); contracts; legal framework; change control (yes for the store, no for identity); access to system and data |
| Unchanged or worse | System availability: two systems now, and an identity outage locks both |
| Depends on the store or on you | System development (a smaller vendor can be the bigger risk); expertise (often worse at first, because security work moves in-house) |
| Outside the dependency view | Sustainability of the store |
Access improves only partly, even with your own keys. Whoever runs identity can issue a valid sign-in for any user. Device trust is a second anchor: if the store checks Intune compliance through Conditional Access, Microsoft is in the access path twice. A full improvement needs an access path that isn’t anchored in Microsoft alone. Whether that threat is realistic for you is your risk call.
In the study’s terms, a store built or adapted for you reaches level 2 on processing and location by default, and 3 with extra effort. Access follows the same scale only once sign-in and the device check no longer run through Microsoft, so the map scores the store at 1 for access until you add that access path. Extraction, legal framework and contracts stop at 2.
Where it splits, and where it doesn’t
Two cut points work well. Key management splits per label (DKE for one class). The virtual workplace splits per user group (a sovereign VDI for the people who handle the class). External collaboration resists splitting, because your partners decide which platform they use.
A counterpoint from the DVS study:4 if your data is classified and stored in open formats, the application layer becomes replaceable. That holds for data extraction and exit. It doesn’t hold for access during operation, where whoever runs identity and the service can still reach the data.
The federal administration draws this line in its own rollout. Its decision paper on data classes in Microsoft 36521 allows INTERNAL data in the cloud, while CONFIDENTIAL data, official secrets and sensitive personal data stay with the local Office apps. That’s a content carve-out by data class, on a shared control plane.
How you get there
Transitions run per data class rather than as one programme for the whole estate, and most carve-outs that exist today are declared rather than enforced.
Two starting points
Most organisations start from a Microsoft 365 estate. Many start from a mixed one, and then it pays to split what’s left on-premises into two groups: what you keep there on purpose, and what simply hasn’t been migrated yet. The first group is already a carve-out. The second is a decision you haven’t made.
Three ways to cut
| Cut | Example | Who pays | Where it leaks |
|---|---|---|---|
| By platform | A whole service moves elsewhere | Everyone who uses it | Little at the seam; the cost is the full switch |
| By process or team | One team handles client files in a separate store | Only that team | At the seam, every time work crosses it |
| By attribute | Client identifiers are pseudonymised; the key to re-identify them stays in the sovereign system | Few people, mostly at the point of re-identification | In the pseudonymisation itself, if it’s weak |
For regulated knowledge work the likely answer is a mix: cut by attribute for drafting, so people keep co-authoring, and by process for formal records.
Whichever cut you choose, it should follow work boundaries such as teams, processes and applications. A label that cuts through everyone’s day gets routed around, and copies drift back. The cut also needs DLP at the seam and a named owner. Much regulated data already sits in business applications. The workplace question is the unstructured rest, the mail and documents about clients, deals and cases.
How mature is the carve-out?
- Declared: a policy says what goes where; users decide at the seam.
- Guided: labels, warnings and an audit trail help them decide.
- Enforced: technical controls block the wrong path at the seam.
- Separated: its own environment and access path. Here the control-plane question comes back.
Most existing carve-outs are probably at level 1. I’ve seen one up close: a regulated company with most mailboxes in the cloud and process-bound shared mailboxes for client data on-premises. There were few technical measures; users judged what to forward. It gave a clean statement to the regulator, not an enforced state. For sovereignty you want level 3.
The cost runs on two lines
On the work surfaces, the cost is mostly retraining and scales with the number of people you move. The DVS study estimates four to five days of training per person for a full replacement. On the control plane, the cost is the security stack, identity and integration, and it doesn’t shrink much for a partial exit. The same study finds licence savings largely offset by an own security stack and integration work. Its figures are indicative and come from the public sector.
That’s why a carve-out by team is cheaper than it looks: you pay retraining only for that team. It’s also what you give up on every work surface you move: the fact that everyone already knows the tools, and the AI features built into mail, documents and meetings.
The exit view of the capability map shows both costs for each capability. Switch between retraining users and technical rebuild to see where each one sits.
The DVS study frames the choice the same way, per functional area and unranked: controlled operation (classification, usage rules, critical use cases deliberately excluded), a second source as fallback, or a partial or full switch by user group, protection need, function or unit.
Sequence before the dam breaks
Some triggers move the whole market at once: documented compelled disclosure at a Swiss institution, the end of the transfer basis to the US, a supervisor tightening rules for a whole sector. When that happens, everyone moves at the same time and competes for the same few people: openDesk specialists, migration partners, people who can implement a DKE key service, hosting capacity. Price increases and targeted service denial don’t work like that; they hit organisations one at a time, usually at renewal.
So whoever has done the thinking moves first, even if the plan hasn’t been carried out yet.
How to start
Start with a desk check and a Day-2 tabletop. After the first month you won’t have a programme plan. You’ll have a qualified basis for estimating one and setting it up.
I once wrote an exit strategy for Microsoft 365 in a regulated organisation. I wrote it alone, mostly in my head. I should have involved far more people. Like a lot of documents in regulated environments, it met the bar for the audit, not more. That’s why the first real step is a room, not a document.
Step 1: desk check
Half a day, done by you. Pick one critical process and walk it through the capability map with the data-class view: which capabilities it uses, which data classes pass through, where the data actually lives. Write a one-page hypothesis of where the dependencies are. Its only job is to get you onto the agenda of whoever owns business continuity.
Step 2: Day-2 tabletop
Run the Day-2 test as a business continuity exercise. Use the levers table and the four dependencies to prepare it. What to look at:
- The only usable copy: ask for the last restore test. When was it, where did the data go, and could anyone read it without Microsoft 365?
- Who must operate it: who decides to switch to the second channel? Usually that’s the crisis staff lead. Does the channel itself depend on Entra sign-in, provisioning or Intune?
- Who can read it: end with this question. If the provider were compelled to disclose your data, what could be read, and would you know?
The fourth dependency, that you can’t work without their technology, belongs to the renewal decision, not to the tabletop.
If you’re FINMA-regulated, you probably don’t need a new exercise. For banks and insurers, Circular 2018/3 already asks for a contingency plan that keeps an outsourced function running in an emergency (margin no. 25).22 Larger banks (FINMA categories 1 to 3) can run the Day-2 case inside the resilience tests that Circular 2023/1 requires.23 Its footnote on those tests already names the scenario: foreign governments prohibiting foreign-based cloud providers from serving Swiss firms.
What comes out
Inputs for an estimate, not cost figures: the scope you looked at, the gaps with an owner each, lever candidates sorted by the two cost lines from How you get there, and the unknowns you couldn’t close. Run the Sovereign Workplace Map with what you found.
Ask the risk owner for a yes or no per open dependency: accepted, or to be reduced. Scoring on the CLDN dimensions stays with architecture. A full rating per dimension is possible and adds precision, but it’s too specific to each organisation for this page to provide.
The first assessment
After the first month, the first assessment is its own piece of work. It covers all four data classes in depth: the critical processes, where the unstructured data lives, the carve-outs that already exist and how mature they are, and proof that restores work. Some things are shared across classes: identity, exit terms, the renewal date. Leave out a full CLDN scoring, platform evaluation, business applications beyond the workplace boundary and detailed cost. Use the exit view of the capability map to prepare the renewal.
This is where other methods pick up. Jesko Ziegler’s talk9 proposes a five-step assessment: scoping, target level, current state, gap analysis, then measures and a roadmap. After the first month you have the inputs for its first two steps (scope and target level) and part of the third (current state).
Sources
- AWK Group for the CLDN, « Étude d’opportunités pour un cloud souverain », 11 May 2023. Tableau 1 (dimensions), Tableau 2 (levels), Tableaux 3–6 (what each type of solution reaches), 4.2 and 5.4.2.
- Eraneos for Digital Public Services Switzerland (DVS), Alternativen zu M365 und Konsequenzen bei einem Wechsel, 18 Sep 2026.
- HSLU and ti&m, Digital Sovereignty Study 2026, 7 Oct 2026 (report behind a registration form).
- Federal Chancellery, Microsoft 365 rollout complete, 18 Dec 2025; programme for a sovereign workplace, 2 Sep 2026; CEBA decision paper on data classes in Microsoft 365.
- FINMA, Circular 2018/3 Outsourcing, 2017 version.
- FINMA, Circular 2023/1 Operational risks and resilience – banks, 7 Dec 2022, in force 1 Jan 2024.
- European Supervisory Authorities, list of designated critical ICT third-party providers under DORA, 18 Nov 2025.
- Microsoft Learn: service health and continuity; DORA; Double Key Encryption; Customer Key availability key; Microsoft 365 Local.
- Microsoft Learn, checked 6 Nov 2026: Data, privacy and security for Microsoft Copilot; Flex routing (EU and EFTA); EU Data Boundary for Microsoft 365; Data residency for Microsoft 365 Copilot.
- Microsoft, Microsoft 365 packaging and pricing updates, 16 Feb 2026.
- Microsoft Learn, checked 6 Nov 2026: Advanced Data Residency.
- Federal Council, Swiss-U.S. Data Privacy Framework, in force since 15 Sep 2024.
- Anthropic, access to Claude Fable 5 and Mythos 5.
- Jesko Ziegler, Cloud und Souveränität – Up- and Downsides, swissICT, Bern, 15 Sep 2026.
Changelog
| Date | Change |
|---|---|
| 6 Nov 2026 | First version |
I know, shocker! ↩︎
ti&m and Lucerne University of Applied Sciences and Arts (HSLU), Digital Sovereignty Study 2026, 200 organisations surveyed. Announcement and download (7 Oct 2026; the full study requires registration). ↩︎
Microsoft, Microsoft 365 packaging and pricing updates (16 Feb 2026). USD list prices: E3 $36 → $39, E5 $57 → $60, F1 $2.25 → $3, F3 $8 → $10. Prices vary by country and currency. ↩︎
Eraneos for Digitale Verwaltung Schweiz, Alternativen zu M365 und Konsequenzen bei einem Wechsel (18 Sep 2026, German, PDF). ↩︎ ↩︎
Federal Chancellery, press release on the completed Microsoft 365 rollout (18 Dec 2025, German). ↩︎
Federal Chancellery, press release on the sovereign workplace programme (2 Sep 2026, German). ↩︎
Microsoft Learn, What is Microsoft 365 Local? ↩︎ ↩︎
AWK Group for the CLDN, « Étude d’opportunités pour un cloud souverain » (11 May 2023, French, PDF). ↩︎
I came across the model in Jesko Ziegler’s talk Cloud und Souveränität – Up- and Downsides at the swissICT Fachgruppe Sourcing & Cloud, Bern, 15 Sep 2026. Thanks, Jesko. ↩︎ ↩︎
Federal Council, press release on the Swiss-U.S. Data Privacy Framework (in force since 15 Sep 2024). ↩︎
Anthropic, statement on the access suspension and restoration. ↩︎
Microsoft Learn, Service health and continuity, including the quarterly uptime table. ↩︎
European Supervisory Authorities, list of designated critical ICT third-party providers under DORA (18 Nov 2025, PDF); Microsoft’s summary on Microsoft Learn. ↩︎
Microsoft Learn, Double Key Encryption. ↩︎
Microsoft Learn, Learn about the availability key for Customer Key. ↩︎
Microsoft Learn, Advanced Data Residency overview and data residency offerings by geography, checked 6 Nov 2026. ↩︎
Microsoft Learn, EU Data Boundary for Microsoft 365, checked 6 Nov 2026. ↩︎
Microsoft Learn, Flex routing (EU and EFTA), checked 6 Nov 2026. ↩︎
Microsoft Learn, Anthropic models in Microsoft Online Services and Copilot in Microsoft 365 apps with Anthropic models, checked 6 Nov 2026. ↩︎
Microsoft Learn, Data residency for Microsoft 365 Copilot and Data, privacy and security for Microsoft Copilot, checked 6 Nov 2026. ↩︎
Federal Chancellery, Informationspapier Entscheid CEBA (German, PDF). ↩︎
FINMA, Circular 2018/3 Outsourcing, margin no. 25 (2017 version, German, PDF). ↩︎
FINMA, Circular 2023/1 Operational risks and resilience – banks (7 Dec 2022, in force 1 Jan 2024, PDF). ↩︎


