När digital suveränitet slutar vara teori
I samtal med CIO:er och CISO:er på svenska myndigheter och företag med kritisk infrastruktur ser vi samma utveckling under de senaste åren: digital suveränitet har gått från strategidokument till akuta beslut.
Det handlar inte längre om man ska använda publika moln, utan hur man gör det och samtidigt behåller sin handlingsfrihet. Parallellt skärps kravbilden:
- NIS2 och andra regelverk driver upp kraven på kontroll, insyn och rapportering
- Geopolitiska beslut kan över en natt ändra förutsättningarna för molntjänster
- AI, nya dataflöden och ökande automatisering gör beroendena mer komplexa
I det läget blir den klassiska frågan “moln eller egna hallar?” för grov. Sann digital suveränitet handlar mindre om platsen där data körs – och mer om vem som kontrollerar kontrollskiktet.
Två återvändsgränder: Egna hallar vs. “all-in”-moln
Många organisationer upplever att de tvingas välja mellan två extremer:
Retirera till egna datacenter
- Full fysisk kontroll
- Men risk för teknikskuld, kompetensbrist och lägre innovationshastighet
Gå “all-in” i en molnleverantörs ekosystem
- Hög innovationskraft och enkel start
- Men växande beroende till proprietära tjänster och API:er
Vi ser att båda vägarna innebär betydande risker när omvärldsfaktorer ändras snabbt. Lagändringar, sanktioner, ändrade villkor eller nya säkerhetskrav kan plötsligt göra en tidigare rationell strategi svår att bära.
Vår erfarenhet är att den verkliga strategiska frågan är:
Hur designar vi ett kontrollskikt som gör att vi kan använda publika moln fullt ut, men behålla friheten att agera när förutsättningarna ändras?
Suveränitet som risk- och tillitsfråga
Digital suveränitet är i grunden en kombination av risk och tillit. Det handlar inte bara om var workloads körs, utan om:
- Vad händer om en leverantör ändrar villkor eller prismodell?
- Hur påverkas vi om ett land ändrar lagstiftning kring insyn, dataåtkomst eller exportkontroll?
- Hur snabbt kan vi agera om vi behöver flytta, duplicera eller segmentera miljöer?
En organisation som äger sitt kontrollskikt har alternativ:
- Man kan flytta workloads och data mellan miljöer
- Man kan byta leverantör stegvis
- Man kan segmentera känsliga delar av verksamheten
En organisation som sitter djupt integrerad i proprietära API:er, identitetstjänster och dataplattformar har i praktiken outsourcat sin strategiska framtid.
Tre dimensioner av digital suveränitet
För att göra frågan praktiskt hanterbar behöver vi bryta ned digital suveränitet i tydliga dimensioner. Vi använder ofta följande tredelning i dialoger med kunder:
1. Datasuveränitet
Fokus: Vem har juridisk och teknisk åtkomst till data?
- Data residency: Var lagras data, var replikeras den och var körs backuper?
- Jurisdiktion: Vilka lagar kan göra anspråk på data – både nationellt och internationellt? (Här blir även extraterritoriella lagar som CLOUD Act relevanta.)
- Insyn: Loggning, kryptering och nyckelhantering
Här blir frågor om kryptering, egen nyckelhantering (KMS/HSM), samt tydliga dataklassningsmodeller centrala. Vi ser ofta att organisationer har bra kontroll på persondata, men betydligt sämre struktur på systemdata, loggar och metadata – trots att dessa ofta är minst lika känsliga.
2. Operativ suveränitet
Fokus: Kan vi hålla igång verksamhetskritiska system oavsett enskild leverantörs interna processer?
- Kan ni skala upp, återställa eller flytta en tjänst utan manuell handpåläggning från en specifik leverantör?
- Är övervakning, incidenthantering och beredskap beroende av en viss plattform?
- Finns det dokumenterade, testade processer för drift i en alternativ miljö?
Vi ser återkommande att organisationer underskattar hur mycket av driftsförmågan som i praktiken sitter i en leverantörs portaler, verktyg och processer.
3. Mjukvarusuveränitet
Fokus: Insyn och kontroll över den teknik som utgör plattformens fundament.
- Använder ni öppna standarder och öppen källkod där det är möjligt?
- Är plattformens kritiska komponenter utbytbara?
- Kan ni fortsätta utveckla och underhålla plattformen även om en leverantör försvinner?
Öppen källkod är inte ett mål i sig, men ett sätt att minimera risken att teknik “stängs av” utifrån. Kubernetes, Linux och öppna API:er är exempel på där vi kan bygga kontrollskiktet på en gemensam, leverantörsoberoende grund. En bra fingervisning för om mjukvara är lämplig för produktionsmiljöer är att de finns bland CNCF:s Graduated Projects.
Kubernetes som kontrollskikt – inte bara runtime
Kubernetes är idag de facto‑standard för containerorkestrering i moderna it‑miljöer. Men den verkliga styrkan ligger inte enbart i orkestreringen av containers, utan i dess roll som abstraktionslager.
Rätt använt blir Kubernetes:
- En gemensam standard för hur applikationer körs – oavsett om de körs på egna servrar eller i publika moln
- En plattform där policys, nätverk, säkerhet och driftsättning kan uttryckas som kod
- En bas för att standardisera hur applikationer byggs, driftsätts och övervakas
När vi pratar om Kubernetes som styrmodell handlar det om att flytta makten från molnleverantörens kontrollpanel till:
- er egen klusterkonfiguration
- era egna policys (Policy as Code)
- ert eget Git-flöde (GitOps)
Då blir den underliggande infrastrukturen – oavsett leverantör – mer av en utbytbar råvara. Det är här vi börjar närma oss praktisk digital suveränitet.
Vad vi ser hos kunder: typiska mönster och fallgropar
Vanliga risker:
- Applikationer är containeriserade, men djupt bundna till molnspecifika databaser, köer och IAM-tjänster
- Säkerhetspolicys sitter i dokument och processer – inte i plattformen
- Drift och övervakning bygger på proprietära verktyg i ett specifikt moln
Framgångsfaktorer:
- En tydligt definierad Cloud Native-strategi där Kubernetes är gemensamt fundament
- Ett plattformsteam som äger kontrollskiktet: GitOps, policies, registries, observability
- En medveten strategi för var man accepterar beroenden – och var man måste ha exit‑möjlighet
Men hur omsätter ni dessa insikter i en konkret handlingsplan som hela organisationen ställer sig bakom?
Står ni inför en större utmaning där ni behöver förankra lösningar brett eller fatta beslut där olika funktioner bidrar med sina unika perspektiv? Då är en strategisk workshop en kraftfull metod. Det är vårt sätt att säkerställa att ni inte bara får en teknisk plan på plats, utan också den organisatoriska samsyn som krävs för att faktiskt gå från beslut till genomförande.
Från suveränitet till portabilitet och styrmodell
Digital suveränitet är ramen. För att göra den operativ behöver vi två byggstenar:
- Portabilitet – förmågan att faktiskt flytta, duplicera eller återställa tjänster i en annan miljö
- Styrmodell – där policys, säkerhet och efterlevnad är inbyggda direkt i plattformen
I bloggen Kubernetes och portabilitet i praktiken går vi igenom hur ni faktisk blir flyttbara med Kubernetes, GitOps och rätt abstraktioner – och varför data och identitet ofta är den verkliga låsningen.
I bloggen Styrmodell för molnet med Kubernetes & automation fördjupar vi hur styrmodeller (governance) för cloud förändras när vi flyttar kontrollerna in i Kubernetes och automatiserar efterlevnad med Policy as Code.
Sammanfattning: Suveränitet är kontroll över kontrollskiktet
Digital suveränitet i en hybrid värld handlar inte om att välja “moln eller inte moln”. Det handlar om:
- att äga kontrollskiktet – API:er, policys, Git-flöden och plattformskomponenter
- att bygga på öppna standarder och Cloud Native-principer
- att ha reella exit‑alternativ när läget förändras
Kubernetes och Cloud Native är inte magi, men rätt implementerat ger det en teknisk grund för att kombinera innovationstakt och handlingsfrihet.
Vill ni diskutera er suveränitetsstrategi?
Prata med våra experter och ta del av våra konsulttjänster, utbildningar och workshops. Kontakta Conoa här.
