Digital suverænitet

De tre lag i digital suverænitet: dataresidens, drift og jura

De tre lag i digital suverænitet: dataresidens, drift og jura

En exit-plan kan se færdig ud, fordi data er flyttet til et datacenter i EU, og alligevel efterlade den største afhængighed urørt. Planen hviler på, at hvert kritisk system vurderes på tre spørgsmål, som hver har sit eget svar.

De tre spørgsmål er, hvor data ligger, hvem der driver og har adgang, og hvilke love ejeren af tjenesten skal følge. Denne artikel forklarer lagene, viser dem i udbydernes egen dokumentation og giver et skema, I kan bruge system for system.

Hvorfor modellen hører hjemme i exit-planen

En exit-plan svarer på, hvad I gør, hvis en tjeneste lukkes, ændres eller bliver for dyr at blive i. Det svar afhænger af, hvor afhængigheden sidder. Sidder den i placeringen, løses den med en flytning. Sidder den i driften eller i ejerens retsforhold, hjælper en flytning ofte lidt.

Modellen med tre lag giver jer et fælles sprog på tværs af direktion, IT og jura. Den gør det tydeligt, hvilket lag en given leverandørløsning faktisk ændrer. Brug den sammen med kortlægningen i → trin 1 i exit-planen.

Lag 1: dataresidens

Dataresidens handler om, i hvilke lande data gemmes og behandles. Det er det lag, kontrakter og markedsføring oftest nævner, fordi det er let at dokumentere med et datacenter og en region.

Selv her er billedet sjældent helt rent. Microsoft meldte i februar 2025, at selskabets EU Data Boundary var gennemført. Microsofts egen dokumentation oplyser samtidig, at forpligtelsen gælder med begrænsede undtagelser, hvor data fortsat overføres ud af området.

Lag 1 vurderes derfor ud fra udbyderens egen liste over undtagelser. Den gennemgang hører til i → EU-lagring med undtagelser.

Lag 2: operationel kontrol

Operationel kontrol handler om de mennesker og selskaber, der passer platformen, yder support og kan komme ind i systemerne. Data kan ligge i EU, mens drift og fejlretning foregår andre steder.

Microsoft beskriver netop det. Ifølge dokumentationen kan medarbejdere uden for EU Data Boundary i nogle tilfælde få fjernadgang til data, der er lagret inden for området. Samme side oplyser, at data til sikkerhedsdrift kan overføres til Azure-regioner i hele verden.

Spørgsmålet i lag 2 lyder derfor, hvem der kan logge ind, fra hvilket land og med hvis godkendelse. Svaret afgør, om I kan se og begrænse adgangen. Det hænger tæt sammen med → trin 4 om at lukke, se og ændre.

Lag 3: juridisk suverænitet

Juridisk suverænitet handler om, hvilke staters love der binder det selskab, som ejer tjenesten. Det lag følger selskabet og dets moderselskab, uanset hvor serveren står.

Lag 3 er det sværeste at ændre, fordi det kræver en anden ejer eller en anden ejerstruktur. Det er også det lag, der afgør, om en myndighed i et andet land kan pålægge udbyderen at udlevere data eller lukke en tjeneste. Ejerskabet slås op i registrene, som beskrevet i → trin 2 om juridisk enhed og moderselskab.

Markedet gør spørgsmålet relevant for næsten alle. Synergy Research opgjorde i juli 2025, at Amazon, Microsoft og Google tilsammen har 70 procent af det europæiske cloudmarked. De to største europæiske udbydere, SAP og Deutsche Telekom, havde hver 2 procent.

Hvad CLOUD Act betyder for lag 3

Den amerikanske CLOUD Act fra marts 2018 indsatte en bestemmelse i 18 U.S.C. § 2713. Den pålægger udbydere af kommunikations- og cloudtjenester at efterkomme amerikanske krav om data, de har i deres besiddelse, varetægt eller kontrol.

Bestemmelsen gælder, uanset om data befinder sig i eller uden for USA. Placeringen i lag 1 ændrer altså ikke pligten, så længe udbyderen har kontrol over data. Den nærmere gennemgang af loven står i → Cloud Act.

Én ændring flytter ét lag

De fleste tiltag, organisationer gennemfører i dag, rammer kun ét af lagene. Det er en god grund til at notere for hvert tiltag, hvilket lag det flytter.

  • Ny region i EU flytter lag 1. Drift og ejer kan være de samme som før.
  • Drift ved europæisk personale flytter lag 2. Ejeren og dens retsforhold er uændrede.
  • Egne krypteringsnøgler styrker kontrollen med indholdet. De holder ikke en tjeneste kørende, hvis den lukkes, jf. → egne nøgler.
  • Skift til en udbyder med en anden ejer er det tiltag, der kan flytte lag 3. Det er også det dyreste og tager længst tid.

En exit-plan, der kun noterer det første punkt, overvurderer typisk, hvor meget handlefrihed organisationen har fået.

Sådan beskriver udbyderne selv lagene

De store udbydere tilbyder i dag løsninger, der adresserer lag 1 og 2 hver på sin måde. Deres egne beskrivelser kan bruges som opslag, når I udfylder skemaet. Den samlede vurdering findes i → de store udbyderes suveræne clouds.

  • Microsoft tilbyder ifølge sin dokumentation Sovereign Public Cloud i egne datacentre og Sovereign Private Cloud i datacentre, kunden eller en partner driver. Microsoft har desuden forpligtet sig til at udfordre ethvert myndighedskrav om data fra offentlige og erhvervskunder i EU.
  • AWS gjorde sin European Sovereign Cloud tilgængelig 14. januar 2026. Ifølge AWS drives den udelukkende af personer bosat i EU gennem selskaber under tysk ret. AWS’ FAQ oplyser, at tillægsaftalen indeholder særlige forpligtelser om håndtering af myndighedsanmodninger.
  • Google beskrev i maj 2025 tre modeller: Data Boundary, Dedicated drevet af lokale partnere og Air-Gapped. I Frankrig leveres Dedicated af S3NS, der ifølge S3NS selv er et fransk selskab med Thales og Google Cloud som moderselskaber.

Alle tre beskrivelser siger meget om placering og drift. Lag 3 skal I selv slå op, fordi ingen af dem giver hele ejerkæden på samme side. Synergy Research noterede i samme opgørelse, at markedets fem største udbydere alle er amerikanske.

EU-Kommissionens ramme: det svageste område afgør

EU-Kommissionen fremlagde sin Cloud Sovereignty Framework i oktober 2025 til et udbud af cloud til EU’s institutioner. Rammen vurderer udbydere på otte områder, blandt andet juridisk og jurisdiktionel suverænitet, data og AI samt operationel suverænitet.

Det juridiske område måler blandt andet udsathed over for love med virkning over grænser, og vejledningen nævner CLOUD Act som eksempel. Vejledningen fastslår også, at det samlede niveau er det laveste niveau, udbyderen opnår på nogen af områderne.

Den regel kan I overføre direkte til exit-planen. Et system er aldrig mere uafhængigt end dets svageste lag. Rammen er skrevet til offentlige indkøb, men Kommissionen lægger den også frem til brug i private virksomheder, og den er beskrevet nærmere i → EU’s suverænitetsramme.

Skema: vurder et system i de tre lag

Udfyld skemaet for hvert kritisk system. Skriv kilden ud for hvert svar, så vurderingen kan efterprøves ved næste gennemgang.

  1. System og leverandør · navn på tjenesten, den juridiske enhed, kontrakten er indgået med, og kontraktens udløb.
  2. Lag 1, placering · lande for lagring og behandling, og udbyderens egen liste over undtagelser.
  3. Lag 1, vurdering · grøn, gul eller rød, med henvisning til den side eller kontraktbilag, svaret bygger på.
  4. Lag 2, drift og adgang · hvem driver, hvem yder support, fra hvilke lande kan der gives adgang, og kan I godkende eller logge adgangen.
  5. Lag 2, vurdering · grøn, gul eller rød, med kilde.
  6. Lag 3, ejer og retsforhold · moderselskab, registreringsland, og hvilke staters love der kan pålægge udbyderen at udlevere data eller lukke tjenesten.
  7. Lag 3, vurdering · grøn, gul eller rød, med kilde.
  8. Samlet niveau · det laveste af de tre, efter samme princip som i Kommissionens ramme.
  9. Hvad et planlagt tiltag ændrer · hvilket lag tiltaget flytter, og hvilke lag der står uændret.
  10. Konsekvens for exit-planen · hvor lang tid og hvor mange midler det kræver at flytte det svageste lag, og hvornår kontrakten giver et vindue.

Skemaet fungerer bedst, når IT udfylder lag 1 og 2, og jura eller indkøb udfylder lag 3. Ledelsen tager stilling til det samlede niveau og til prioriteringen i → trin 6.

Hvad modellen kan og ikke kan vise

Modellen kan vise, hvor afhængigheden sidder, og om et tiltag rammer det rigtige lag. Den kan også afsløre, når en løsning markedsføres med et lag, mens spørgsmålet gælder et andet. Den problemstilling uddybes i → sovereignty washing.

Modellen kan ikke afgøre, om en konkret myndighed vil rette krav mod en bestemt udbyder. Den vurderer heller ikke en kontrakt juridisk. Den kan desuden skjule afhængigheder i leverandørkæden, hvis I kun ser på den første leverandør.

Næste skridt i exit-planen

Vælg de tre til fem systemer, hvor et stop koster mest, og udfyld skemaet for dem først. Notér for hvert planlagt tiltag, hvilket lag det flytter. Bed leverandøren om skriftlige svar på lag 2 og 3, og gem dem sammen med vurderingen.

Når skemaet viser et rødt lag 3 for et forretningskritisk system, kan en uvildig gennemgang give et bedre beslutningsgrundlag. Nielco IT laver en jurisdiktions- og afhængighedsvurdering, der gennemføres på jeres eget materiale.

Kilder

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal afhængigheden kortlægges?

Skriv kort, hvilke systemer eller leverandører det drejer sig om, og hvad anledningen er. Så vender jeg tilbage. Jeg sælger rådgivning, ikke produkter, og har ingen leverandørpartnerskaber.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.