Cloud-sikkerhed efter EU’s nye forslag til øget digital suverænitet: Kan I skifte cloud-leverandør?

Kort fortalt

I denne artikel får du et samlet overblik over, hvordan EU’s forslag gør cloudsuverænitet mere konkret, og hvorfor dataplacering alene ikke er nok. Du får fem centrale spørgsmål om data, kontrol, leverandørafhængighed og portabilitet samt en praktisk indgang til at udarbejde og teste en cloud exit-strategi.

Cloud-løsninger er blevet en kritisk del af danske virksomheders drift. Derfor handler cloud-sikkerhed ikke længere kun om adgangskontrol, kryptering og backup. Det handler også om, hvem der reelt kontrollerer tjenesten, hvilke jurisdiktioner leverandøren er underlagt, og om virksomheden kan fortsætte driften, hvis adgangen til en bestemt platform ændres eller forsvinder.

Debatten er blevet mere konkret med Europa-Kommissionens forslag til Cloud and AI Development Act (CADA) fra 3. juni 2026. Forslaget er endnu ikke vedtaget og udgør derfor ikke gældende ret. Men det introducerer et fælles sprog for cloud- og AI-suverænitet og viser, hvilke risici europæiske indkøbere fremover forventes at kunne vurdere.

Det er fristende at reducere datasuverænitet til spørgsmålet: Ligger data i EU? Placeringen er vigtig, men den fortæller ikke hele historien. En tjeneste kan være hostet i Europa og stadig være afhængig af en udenlandsk koncern, et kontrolplan uden for EU, proprietære formater eller en softwareforsyningskæde, som kunden kun har begrænset indsigt i.

EU-Kommissionens forslag peger netop på risici ved strategisk afhængighed, tredjelandes lovgivning og driftsafbrydelser. Folketingets EU-Oplysning gengiver forslaget i HTML, så virksomheder kan orientere sig uden at gøre lovteksten til en teknisk tjekliste.

Pointen er, at cloud-sikkerhed både omfatter fortrolighed, integritet og tilgængelighed samt muligheden for at træffe egne beslutninger under pres. Hvis en kritisk løsning ikke kan flyttes, gendannes eller drives i en reduceret tilstand uden én bestemt leverandør, er afhængigheden en forretningsrisiko.

 

EU’s fire niveauer er et risikosprog, ikke et facit

CADA-forslaget introducerer fire niveauer for offentlige indkøb, der angiver, hvor stor europæisk kontrol der skal være med en cloud- eller AI-løsning. Offentlige myndigheder skal vælge niveau ud fra en konkret risikovurdering. Jo højere niveau, desto strengere er kravene til blandt andet dataplacering, leverandørens uafhængighed af tredjelande, ejerskab og kontrol med softwareforsyningskæden.

Det betyder ikke, at alle virksomhedens løsninger skal opfylde de strengeste krav. Niveauet skal afspejle, hvor kritisk løsningen er, og hvilke konsekvenser et nedbrud, leverandørskifte eller tab af adgang kan få. En samarbejdsplatform og et produktionskritisk system bør derfor ikke nødvendigvis mødes med de samme krav. For virksomheder kan modellen bruges som inspiration til at stille stærkere krav til kontrol, alternativer og exitmuligheder, når en løsning har stor betydning for driften.

KL fremhæver i sit høringssvar, at nye vurderingskrav kan øge kompleksiteten, medføre migrationsbehov og skabe nye leverandørafhængigheder. Det understreger, at digital suverænitet skal vurderes ud fra den kontrol og handlefrihed, organisationen reelt opnår. Et leverandørskifte øger ikke suveræniteten, hvis det blot erstatter én kritisk afhængighed med en anden.

Hvilke data og processer er faktisk kritiske?

Kortlæg forretningsprocesser, data, integrationer og de cloudtjenester, virksomheden afhænger af. Vurder konsekvensen ved tab af adgang, datalæk, uautoriserede ændringer og længerevarende nedbrud. Uden denne prioritering bliver diskussionen om datasuverænitet enten rent ideologisk eller alt for dyr.

Hvem kontrollerer tjenesten og softwareforsyningskæden?

Bed leverandøren beskrive ejerskab, underleverandører, driftslande, privilegeret supportadgang og styring af softwarekomponenter. Afklar også, hvilke ændringer leverandøren kan gennemføre ensidigt, og hvordan virksomheden varsles om nye underdatabehandlere, funktioner eller afhængigheder.

Kan data, konfigurationer og workloads reelt flyttes til en anden løsning?

En effektiv cloud exit-strategi kræver, at data, systemer og centrale funktioner reelt kan flyttes til en anden løsning. Dokumentér formater, API’er, identiteter, nøgler, logdata, automatisering og integrationer. Fastlæg acceptable udtrækstider, omkostninger og datamængder. Test, om eksporten kan bruges et andet sted, og om slettede data kan dokumenteres fjernet hos leverandør og underleverandører.

Hvad sker der under en geopolitisk eller kontraktuel ændring?

Scenarierne bør omfatte ændrede priser, udfasede produkter, konflikt mellem lovgivninger, sanktioner, opkøb og midlertidigt tab af en tjeneste. Målet er ikke at forudsige politik, men at sikre beslutningsmandat, alternative kommunikationsveje og en prioriteret rækkefølge for genopretning.

Hvordan bliver exit-planen testet?

Aftal en fast testfrekvens og mål tidsforbrug, datatab, tekniske fejl og manuelle afhængigheder. En skrivebordsøvelse kan afdække roller og kontraktproblemer; en teknisk prøveflytning viser, om dokumentationen holder. Resultaterne bør indgå i risikovurderingen og næste kontraktforhandling.

Styrelsen for Samfundssikkerhed understreger, at organisationen selv beholder ansvaret for informationssikkerheden, også når it-driften er outsourcet. Derfor bør cloudsuverænitet behandles som en del af den eksisterende leverandørstyring: risikokrav, hændelseskommunikation, revisionsret, kontinuitet og en kontrolleret afslutning af samarbejdet.

Start med de mest kritiske tjenester og forbind arbejdet til virksomhedens IT-beredskabsplan og en eventuelt eksisterende ISO 27001-risikovurdering. Når exit-krav, portabilitet og leverandørkontrol bliver testbare, bliver digital suverænitet mindre en politisk ambition og mere en dokumenteret evne til at holde forretningen i gang.