Sweden's cloud policy: digital sovereignty for Azure teams

On 28 May 2026 the Swedish government adopted its first national cloud policy for public administration: En molnpolicy för Sverige – för ökad säkerhet, effektivitet och innovation i den offentliga förvaltningen (Fi2026/01233, Finansdepartementet). It is a short document with a long shadow. There is no ban on American cloud services, and the government was explicit about that. But the policy treats Europe's dependence on non-EU providers as a risk in itself, and it makes jurisdictional exposure and the ability to leave central to how public organisations should evaluate cloud services. If you run public-sector workloads on Azure in Sweden, or sell into organisations that do, this is the document your customers' legal and procurement teams will be quoting for the next several years. Procurement templates have not caught up with it yet. That gap is your preparation window.

What the policy actually says

The policy sets out three headline goals: increased security, efficiency and innovation in public administration. One recurring theme ties them together: digitalt självbestämmande, digital self-determination. Announcing the policy, civil minister Erik Slottner said that Sweden's public organisations need to strengthen the country's digital self-determination. In comments to Computer Sweden he acknowledged openly that the work had been accelerated by geopolitical developments, including the changed political climate in the United States.

Concretely, the document does the following:

Names the dependency problem. Europe's public administrations are heavily dependent on suppliers outside the EU, which the government says can affect competition, security and control over data.
Flags jurisdictional risk without naming names. The policy warns that certain foreign legislation could cause data to end up in the wrong hands. It never says "the United States" or "CLOUD Act", but nobody in Swedish public-sector IT will misread the reference.
Makes portability a first-class requirement. Public actors need to be able to move data quickly to another provider or back to their own operation, and the government explicitly welcomes cloud services built on standards and solutions that promote portability. Switching capability is called out as particularly important in crisis situations.
Pushes risk-based assessment. Agencies are expected to work risk-informed: assess data sensitivity and operational criticality before adopting cloud services, keep meaningful control over data, operations and technology, and put real requirements on suppliers: transparency, clear contracts, exit terms.
Assigns a support role to PTS. Post- och telestyrelsen will support public organisations in applying the policy, balancing efficiency gains against security concerns.
Announces follow-on machinery. The document points to a forum for better coordination of public IT procurement and a study on dynamic purchasing systems for innovative digital solutions. It also promises proposals on procurement rules aimed at protecting Sweden from antagonistic states.

In practice: nothing is forbidden, but every public-sector cloud decision in Sweden is now expected to come with a documented answer to "what is our jurisdictional exposure, and how fast can we leave?"

What it deliberately does not say

Just as important is what is missing. The policy stops short of concrete procurement requirements. There are no mandated certifications, no data-residency thresholds, no list of approved or disapproved providers, no timeline for compliance. Computer Sweden's headline captured it: the government presents a cloud policy, with no ban on American services. Instead, the recommendation is to give priority to Swedish and European solutions where that is reasonable, and to manage the rest through risk assessment and contract design.

That ambiguity is not an accident. A hard residency or EU-ownership requirement would have stranded hundreds of ongoing public-sector programmes overnight. Microsoft 365 alone is deeply embedded across Swedish municipalities. The policy instead sets a direction of travel and defers the hard edges to the announced procurement-rule work. For anyone who lived through the years of eSam legal opinions and post-Schrems II uncertainty, the pattern is familiar: guidance first, requirements later. The practical consequence is that the window between "policy" and "procurement requirement" is exactly the time you have to get your architecture into a defensible position.

Why Azure teams should read this carefully rather than defensively

It is tempting to read the policy as an anti-hyperscaler document. We think that is the wrong reading. The policy's operative demands (risk assessment, data control, portability, exit capability, supplier transparency) are things a well-run Azure estate can demonstrate today, and things a poorly-run estate on any provider, European or American, cannot. The teams that will struggle are the ones who cannot say where their data lives or what moving it would take, whichever provider they run on.

Azure also gives Swedish public-sector customers more residency levers than it did five years ago: the Sweden Central region for keeping data at rest on Swedish soil, the EU Data Boundary commitments for keeping processing of customer data within the EU/EFTA, and customer-managed keys and confidential computing for reducing what a provider, or anyone compelling the provider, can access in usable form. None of this makes the jurisdictional question disappear: Microsoft remains a US-headquartered company subject to US law, and that is precisely the residual risk the Swedish policy asks you to assess honestly rather than wish away. But "assess honestly" is a very different demand from "leave".

A workload-by-workload decision framework

The policy's risk-based language maps naturally onto a per-workload triage. Here is the framework we use in sovereignty discussions with Swedish organisations. It is deliberately boring: the goal is a defensible written record, not a dramatic migration.

Step 1: Classify the workload

Class A (open or low-sensitivity data): public information, anonymised statistics, test environments. The policy gives you no reason to move these anywhere. Document the classification and move on.
Class B (ordinary personal data and internal operations): case handling, HR, collaboration. This is where most workloads live. GDPR discipline plus residency configuration (Swedish or EU regions, EU Data Boundary) plus a written jurisdictional risk assessment is a strong position.
Class C (sensitive personal data or operationally critical systems): health and social-care records, systems whose outage halts a statutory function. Here the policy's crisis-scenario language bites: you need customer-managed keys and a tested exit plan, plus a serious analysis of whether the workload belongs on a hyperscaler at all.
Class D (security-classified information): already governed by säkerhetsskyddslagen and outside the public-cloud conversation entirely. The cloud policy changes nothing here.

Step 2: Assess jurisdictional exposure per class

For each Class B and C workload, write down: which legal entity provides the service; which jurisdictions can compel that entity; what data the provider can technically access in intelligible form; and what contractual and technical mitigations are in place. The point of customer-managed keys in Azure Key Vault (or Managed HSM) is not that they make legal compulsion impossible — it is that they change what a compelled disclosure can actually yield, which changes the risk assessment you are now expected to produce.

Step 3: Engineer for the exit you hope never to use

Portability is where the policy is most concrete, and where most estates are weakest. Practical Azure translation:

Prefer open interfaces at the data layer: PostgreSQL (Azure Database for PostgreSQL) over proprietary stores where the workload allows; Parquet on ADLS Gen2 rather than formats only one vendor can read.
Contain the compute: workloads packaged as containers on AKS move to any CNCF-conformant Kubernetes, at a European provider or on-premises, with days of work rather than months. Deeply serverless designs (Functions bindings, Logic Apps connectors everywhere) are the opposite.
Everything as code: if the environment exists only as portal clicks, you do not have an exit plan, you have an archaeology project. Bicep or Terraform definitions are your rebuild recipe.
Test the export path: an exit plan that has never restored a full dataset outside Azure is a hypothesis. Run the export once a year and time it — the policy's crisis framing is about speed, not theory.

A useful first move is simply making residency visible and enforced. An Azure Policy assignment restricting deployments to Swedish and EU regions costs nothing and turns a promise into a control:

{
  "properties": {
    "displayName": "Allowed locations - Sweden and EU only",
    "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c",
    "parameters": {
      "listOfAllowedLocations": {
        "value": ["swedencentral", "westeurope", "northeurope", "germanywestcentral"]
      }
    }
  }
}

Pair it with an inventory query so you know your current exposure before anyone asks:

az graph query -q "Resources | summarize count() by location, type | order by count_ desc" --output table

Step 4: Put it in writing

The output of steps 1–3 is a short, per-workload sovereignty position: classification, residency configuration, jurisdictional assessment, mitigations, exit plan and its last test date. When the announced procurement-rule proposals arrive, this document is the difference between adapting a template and starting from zero under deadline pressure.

The Swedish and EU procurement angle

Expect the policy to reach you through procurement long before any regulation does. Swedish public buyers copy each other's requirement catalogues, and the policy hands every upphandlare a new vocabulary: jurisdictional risk assessment, portability standards, exit terms, switching capability under crisis conditions. It is reasonable to expect these to start appearing in RFPs from agencies, regions and municipalities well ahead of any formal rule change. Suppliers to the public sector should expect to be asked for their own sovereignty posture, not just their customers'.

Three implications stand out:

For public-sector buyers: the policy is cover to ask harder questions, not an instruction to rip anything out. Use it to fund the classification and exit-planning work that never wins budget on its own.
For suppliers and SaaS vendors selling into Swedish public sector: "hosted in Azure West Europe" will stop being a sufficient answer. Prepare a residency statement, a sub-processor jurisdiction map, and a data-export commitment with a tested format and timeframe.
For Azure platform teams: the announced coordination forum and dynamic purchasing system study suggest more centralised, more standardised requirements over time. Building to the strictest plausible reading of "portability and control" now is cheaper than retrofitting to it later.

The EU backdrop points the same way. The policy explicitly situates itself in the European debate about dependence on non-EU providers, and Brussels has been signalling for some time that cloud sovereignty is moving from white papers toward legislation. Sweden publishing a national policy now is best read as positioning ahead of that wave, which means the direction is unlikely to soften.

A 90-day preparation checklist

Week 1–2: Read the policy (it is short) with legal, security and platform leads in the same room. Agree who owns the sovereignty position.
Week 3–6: Inventory: Azure Resource Graph for regions and services, M365 data-location report, sub-processor lists for every SaaS product touching citizen data.
Week 5–8: Classify workloads A–D. Assign Class C workloads a named owner and a deadline for a jurisdictional assessment.
Week 7–10: Enforce residency with Azure Policy; move customer-managed keys onto the roadmap for Class C data; identify the one workload with the worst lock-in and cost its portability fix.
Week 10–13: Draft the written sovereignty position per Class B/C workload. Run one real export test. Brief the procurement function on what you can now answer.

The takeaway

Sweden's first national cloud policy bans nothing and mandates little, yet it will change how every public-sector cloud decision in the country is made. It turns "digital sovereignty" from a conference slogan into questions about jurisdictional exposure, data control, portability and exit speed that public organisations are now expected to answer in writing, with PTS supporting and procurement-rule proposals explicitly on the way. For Azure teams the sensible response is neither panic nor dismissal. Classify your workloads. Configure and enforce residency. Engineer a tested exit path for what matters, and write the whole position down. Do that work in 2026 and the coming procurement requirements become a template exercise rather than a crisis.