Tre korte formuleringer, der sammenfatter problemet

Amerikansk ejerskab udløser ikke i sig selv et GDPR-forbud; det afgørende er, om persondata gøres tilgængelige uden for EØS, og hvem der juridisk og teknisk kontrollerer dem. (EUR-Lex)
At data ligger på servere i EU er vigtigt, men ikke tilstrækkeligt: man skal også undersøge supportadgang, underleverandører, logdata, krypteringsnøgler og udenlandske myndigheders mulige adgang. (Datatilsynet)
Microsofts EU Data Boundary reducerer dataoverførsler og risiko betydeligt, men skaber ikke en juridisk mur mod amerikansk lovgivning og omfatter fortsat dokumenterede undtagelser. (Microsoft Learn)

Redegørelsen nedenfor er ajourført pr. 4. august 2026 og er en generel juridisk og teknisk analyse. En bestemt kontrakt, behandling eller myndighedsopgave kan kræve en konkret advokat- og databeskyttelsesvurdering.

Den samlede konklusion

Din grundlæggende intuition rammer en reel risiko, men ejerprocenten er ikke den juridiske udløser.

Der findes ikke en GDPR-regel om, at en virksomhed bliver problematisk, så snart Microsoft, Google eller en anden amerikansk investor ejer for eksempel 1, 5 eller 20 procent af den. Der findes heller ikke en regel om, at en 100 procent amerikansk ejet virksomhed automatisk er ulovlig at anvende i Europa.

Det afgørende er i stedet:

hvilken juridisk enhed der behandler data,
om data eller adgang til data gives til en enhed uden for EØS,
hvorfra medarbejdere og underleverandører kan tilgå data,
hvem der har administratoradgang og krypteringsnøgler,
om en amerikansk virksomhed har data i sin »possession, custody or control«,
og om den samlede risiko og de valgte sikkerhedsforanstaltninger er acceptable.

Tre meget enkle eksempler viser forskellen:

1 procent amerikansk ejerskab uden adgang, kontrol eller særlige rettigheder: normalt uden selvstændig GDPR-betydning.
100 procent amerikansk ejerskab, men en reelt afgrænset europæisk løsning uden adgang uden for EØS:ikke automatisk en tredjelandsoverførsel, men amerikansk myndighedsadgang og koncernkontrol skal vurderes.
0 procent amerikansk ejerskab, men drift på amerikansk cloud med support fra USA eller Indien: kan sagtens indebære tredjelandsoverførsler og udenlandsk jurisdiktionsrisiko.

Amerikansk ejerskab er derfor et advarselssignal, ikke en juridisk tænd/sluk-knap.

1. Fem forskellige former for »datasuverænitet«

Meget af forvirringen skyldes, at fem spørgsmål bliver blandet sammen:

1. Geografisk suverænitet

Hvor bliver data fysisk lagret, sikkerhedskopieret og behandlet?

Dette er det, der normalt kaldes data residency. Det er her, Microsofts EU Data Boundary og de europæiske Azure-regioner især gør en forskel.

2. Operationel suverænitet

Hvem kan administrere systemerne og yde support?

Data kan ligge i København, Dublin eller Frankfurt, men stadig kunne ses fra Seattle, Bangalore eller et globalt sikkerhedscenter. Datatilsynet siger udtrykkeligt, at se-adgang fra et tredjeland er behandling og dermed en overførsel. (Datatilsynet)

3. Teknisk suverænitet

Hvem kan dekryptere oplysningerne?

Hvis leverandøren har eller kan bruge krypteringsnøglen, kan leverandøren normalt også producere læsbare data. Almindelig kryptering »at rest« beskytter derfor godt mod tyveri af harddiske og mange hackerangreb, men ikke nødvendigvis mod et lovligt myndighedspåbud til leverandøren.

4. Juridisk suverænitet

Hvilke landes myndigheder kan forsøge at pålægge leverandøren at udlevere data?

Her kommer GDPR, Schrems II, artikel 48, CLOUD Act, FISA 702 og EU-U.S. Data Privacy Framework ind i billedet.

5. Kontinuitetssuverænitet

Kan virksomheden fortsætte, hvis leverandøren bliver ramt af sanktioner, handelskonflikt, nedbrud eller et påbud om at standse tjenesten?

Det er dette problem, Microsofts kodekopier i Schweiz især skal hjælpe med. Det handler langt mere om driftskontinuitet end om GDPR eller myndigheders adgang til kundedata.

En løsning kan være stærk på én dimension og svag på en anden. EU-lagring kan eksempelvis give høj geografisk suverænitet, samtidig med at leverandøren fortsat har global administratoradgang og er underlagt amerikansk lov.

2. GDPR ser ikke på nationaliteten af aktionærerne

GDPR’s artikel 3 fastlægger, hvornår en behandling er omfattet af GDPR. En europæisk virksomheds behandling er omfattet, uanset om behandlingen teknisk foregår inden eller uden for EU. Reglerne fokuserer på behandlingen, etableringen og de involverede roller — ikke på aktionærernes pas eller ejerprocenter. (EUR-Lex)

Det Europæiske Databeskyttelsesråd, EDPB, anvender tre kumulative kriterier for, hvornår der er en tredjelandsoverførsel:

En dataansvarlig eller databehandler er omfattet af GDPR for den pågældende behandling.
Denne part videregiver eller på anden måde gør persondata tilgængelige for en anden dataansvarlig eller databehandler.
Modtageren befinder sig i et land uden for EØS eller er en international organisation.

Hvis de tre betingelser ikke er opfyldt, er der ikke nødvendigvis en overførsel efter GDPR’s kapitel V. Behandlingen kan dog stadig indebære risici, som skal håndteres efter blandt andet artikel 5, 24, 25 og 32. (European Data Protection Board)

Hvad kan amerikansk ejerskab så betyde?

Amerikansk ejerskab kan få indirekte betydning, når det medfører:

faktisk kontrol fra et amerikansk moderselskab,
adgang til data for amerikanske koncernfunktioner,
fælles support-, sikkerheds- eller logningssystemer,
amerikanske administratorer,
fælles krypterings- eller identitetsinfrastruktur,
eller at data må anses for at være under en amerikansk virksomheds kontrol.

En passiv amerikansk minoritetsaktionær uden dataadgang, bestyrelseskontrol eller andre særlige rettigheder gør derimod ikke automatisk den europæiske virksomhed omfattet af CLOUD Act.

Derfor er spørgsmålet ikke blot:

Hvem ejer virksomheden?

Det mere præcise spørgsmål er:

Hvem kan juridisk, organisatorisk eller teknisk bestemme over oplysningerne?

3. »Data ligger i Europa« er ikke en tilstrækkelig beskrivelse

GDPR’s relevante geografiske skel er som udgangspunkt EØS, ikke det geografiske Europa.

EØS består af EU-landene samt Norge, Island og Liechtenstein. Schweiz og Storbritannien er tredjelande, men har tilstrækkelighedsafgørelser fra EU-Kommissionen. En server kan således stå i Europa uden at stå i EØS, mens en overførsel til eksempelvis Schweiz kan være tilladt på grundlag af tilstrækkelighedsafgørelsen. (Datatilsynet)

Når en leverandør siger »data forbliver i EU«, bør man derfor spørge, om det gælder:

kundens dokumenter og databaser,
sikkerhedskopier og disaster recovery,
metadata og systemlogs,
brugeridentiteter og katalogoplysninger,
søgeindeks,
telemetri og diagnosticeringsdata,
supportdata og skærmbilleder,
sikkerheds- og hændelsesdata,
AI-prompts og output,
fakturerings- og licensoplysninger,
samt underleverandørernes behandling.

Det er ikke usædvanligt, at selve dokumentet ligger i EU, mens en hændelseslog, et supportudtræk eller et AI-relateret datastykke behandles globalt.

Remote access tæller også

Datatilsynet er meget tydeligt på dette punkt:

Hvis data ligger i EU, men kan ses fra et tredjeland, er se-adgangen en overførsel.
Hvis leverandøren kan tilgå data fra et tredjeland som led i support eller drift af infrastrukturen, skal reglerne om tredjelandsoverførsler fortsat vurderes.
En amerikansk cloudleverandør kan godt anvendes, hvis oplysningerne ikke overføres, det er aftalt, og kunden er betrygget i, at EU-retten bliver overholdt.
Kunden skal dog stadig vurdere risikoen for en mulig udlevering efter eksempelvis CLOUD Act. (Datatilsynet)

Det er en vigtig sondring:

Faktisk eller planlagt adgang fra USA: tredjelandsoverførsel.
Teknisk mulighed for supportadgang fra USA: skal undersøges og kan kræve overførselsgrundlag.
En rent hypotetisk risiko for et fremtidigt myndighedspåbud: ikke nødvendigvis allerede en overførsel, men en risiko, der skal indgå i leverandør-, sikkerheds- og konsekvensvurderingen.

4. Hvad CLOUD Act faktisk betyder

CLOUD Act bliver ofte enten bagatelliseret eller overdrevet.

Den amerikanske regel i 18 USC § 2713 siger, at en amerikansk udbyder af elektroniske kommunikations- eller cloudtjenester skal kunne pålægges at bevare eller udlevere data, der er i udbyderens possession, custody or control, uanset om oplysningerne fysisk befinder sig i eller uden for USA. (U.S. Code)

Det betyder:

En amerikansk myndighed mister ikke nødvendigvis sin mulighed for at kræve oplysninger alene, fordi serveren står i Danmark, Irland eller Tyskland.
Det afgørende bliver, om den amerikanske tjenesteudbyder juridisk eller praktisk kontrollerer data.
En lokal europæisk kontraktenhed er ikke nødvendigvis nok, hvis det amerikanske moderselskab fortsat har teknisk eller organisatorisk kontrol.

Men CLOUD Act betyder ikke, at amerikanske myndigheder frit kan logge ind på enhver Microsoft-, Google- eller AWS-server. Der skal anvendes en relevant amerikansk retlig proces, og hvad myndighederne kan kræve, afhænger af den konkrete hjemmel og sag. CLOUD Act er således ikke en universel bagdør, men den fjerner forestillingen om, at serverplaceringen alene afskærer amerikansk jurisdiktion.

Det er samtidig vigtigt, at en lille amerikansk aktionær normalt ikke har virksomhedens kundedata i sin besiddelse eller kontrol. CLOUD Act knytter sig til udbyderen og kontrollen over oplysningerne — ikke til en vilkårlig procent amerikanske aktier.

5. Artikel 48: Et amerikansk påbud er ikke automatisk gyldigt i EU

GDPR artikel 48 handler om domme og administrative afgørelser fra tredjelande, som kræver overførsel eller udlevering af personoplysninger.

EDPB præciserer, at et påbud fra en tredjelandsmyndighed ikke automatisk kan anerkendes eller håndhæves i EU. Hvis en europæisk virksomhed besvarer en sådan anmodning og udleverer persondata, er det en overførsel, som både skal have:

et almindeligt behandlingsgrundlag efter GDPR, eksempelvis artikel 6,
og et overførselsgrundlag efter kapitel V.

En international aftale, eksempelvis en retshjælpsaftale, kan i visse tilfælde levere begge dele. (European Data Protection Board)

Problemet for en amerikansk koncern kan derfor være en reel lovkonflikt:

Amerikansk ret kan kræve udlevering.
EU-retten kan begrænse eller forbyde den samme udlevering.
Den europæiske kunde kan have meget begrænset mulighed for at vide, at anmodningen er fremsat, fordi leverandøren kan være underlagt tavshedspålæg.

En kontrakt, hvor leverandøren lover at overholde GDPR, løser ikke i sig selv denne konflikt. Kontrakten kan dog kræve, at leverandøren udfordrer urimelige påbud, prøver at begrænse anmodningen, orienterer kunden hvor lovligt muligt og offentliggør gennemsigtighedsrapporter.

6. CLOUD Act og FISA 702 er ikke det samme

De to regelsæt blandes ofte sammen:

CLOUD Act

Handler primært om retshåndhævelse og indhentning af elektroniske beviser i konkrete efterforskninger. Den bygger videre på Stored Communications Act og princippet om data under udbyderens kontrol.

FISA 702

Handler om udenlandsk efterretning og kan anvendes mod ikke-amerikanske personer, der med rimelighed antages at befinde sig uden for USA. FISA 702 og andre amerikanske overvågningsordninger var centrale i EU-Domstolens Schrems II-vurdering.

I Schrems II-dommen fra 16. juli 2020 underkendte EU-Domstolen Privacy Shield, fordi amerikanske overvågningsmuligheder og klageadgangen for europæere ikke gav et beskyttelsesniveau, der i det væsentlige svarede til EU’s. Domstolen lod standardkontraktbestemmelserne, SCC’erne, bestå, men krævede, at virksomheder vurderede, om de faktisk virkede i det pågældende tredjeland, og om der var behov for supplerende foranstaltninger. (EUR-Lex)

Schrems II siger derfor ikke, at amerikanske cloudtjenester generelt er ulovlige. Den siger, at et kontraktdokument ikke er tilstrækkeligt, hvis modtagerlandets lovgivning i praksis kan sætte kontrakten ud af kraft.

7. Den aktuelle situation: EU-U.S. Data Privacy Framework

Den 10. juli 2023 vedtog EU-Kommissionen EU-U.S. Data Privacy Framework, DPF. Det er en tilstrækkelighedsafgørelse for amerikanske virksomheder, der aktivt har certificeret sig under ordningen.

For en aktivt certificeret amerikansk modtager betyder DPF, at persondata kan overføres fra EØS uden SCC’er eller andre supplerende kapitel V-garantier. Men virksomheden skal kontrollere:

at den præcise amerikanske juridiske enhed er certificeret,
at certificeringen stadig er aktiv og fornys årligt,
at den omfatter den pågældende type data,
og at relevante amerikanske datterselskaber faktisk er omfattet.

DPF løser kun kapitel V-spørgsmålet. Der skal fortsat være behandlingsgrundlag, databehandleraftale, formålsbegrænsning, dataminimering, passende sikkerhed og eventuelt en konsekvensanalyse.

Ikke alle amerikanske organisationer kan certificere sig. Ordningen er primært åben for virksomheder under det amerikanske Federal Trade Commissions eller Department of Transportations kompetence. Blandt andet kan visse banker, forsikringsselskaber, nonprofitorganisationer og teleudbydere falde udenfor.

Er DPF så juridisk sikkert?

DPF er gældende ret i dag.

EU-Retten afviste den 3. september 2025 Philippe Latombes søgsmål mod ordningen og fandt, at USA på tidspunktet for afgørelsens vedtagelse sikrede et tilstrækkeligt beskyttelsesniveau. Latombe ankede dommen den 31. oktober 2025. Ankesagen C-703/25 P står fortsat som verserende ved EU-Domstolen pr. august 2026. (Curia)

En dansk virksomhed kan derfor lovligt basere en overførsel på DPF i dag. Men en fornuftig kontrakt- og exitstrategi bør tage højde for, at DPF kan blive ændret, suspenderet eller underkendt på et senere tidspunkt.

En god kontrakt har derfor en plan B, eksempelvis:

overgang til SCC’er,
mulighed for tekniske ændringer,
mulighed for at flytte data,
og ret til at opsige løsningen.

Men det er vigtigt, at en SCC-plan B ikke blot bliver et bilag i en skuffe. Hvis DPF bortfalder, skal SCC’ernes reelle effektivitet og behovet for supplerende tekniske foranstaltninger vurderes på ny.

8. Har Microsoft så »løst problemet«?

Svaret er:

Microsoft har løst en væsentlig del af datalokaliseringsproblemet, men ikke hele spørgsmålet om juridisk, operationel og teknisk suverænitet.

Hvad EU Data Boundary faktisk lover

Microsoft beskriver EU Data Boundary som en geografisk afgrænsning, inden for hvilken virksomheden har forpligtet sig til at lagre og behandle kundedata og persondata for blandt andet:

Microsoft 365,
Azure,
Dynamics 365,
Power Platform,
samt professionelle servicedata i nærmere angivet omfang.

Grænsen omfatter i Microsofts terminologi EU- og EFTA-områder. Microsoft understreger samtidig selv, at der fortsat findes begrænsede situationer, hvor kundedata, persondata og servicedata overføres uden for grænsen. (Microsoft Learn)

Det er altså ikke blot en tom markedsføringskonstruktion. Microsoft har foretaget reelle arkitektoniske og organisatoriske ændringer og har flyttet store mængder lagring og behandling ind i området.

Men løftet er heller ikke:

Ingen personoplysninger forlader nogensinde Europa.

Microsofts egne dokumenter viser undtagelserne

Microsoft fører en detaljeret ændringslog over EU Data Boundary. Den viser blandt andet, at:

visse Copilot-funktioner i Microsoft 365, Dynamics, Power Platform og Copilot Studio i april 2026 blev føjet til listen over tjenester med løbende overførsel af delmængder af data uden for EU Data Boundary,
Anthropic-modeller blev føjet til dokumentationen om fortsatte overførsler i januar 2026,
og »OpenAI operated models with Microsoft Generative AI Services« blev føjet til listen over tjenester med løbende overførsler i juli 2026.

Der findes også undtagelser vedrørende globale sikkerhedsoperationer, visse logs, konfigurationsdata, support og valgfrie funktioner. (Microsoft Learn)

Det betyder ikke nødvendigvis, at alle disse tjenester overfører alle kundens data til USA. Det betyder, at vurderingen skal foretages tjeneste for tjeneste, funktion for funktion og konfiguration for konfiguration.

Det er ikke tilstrækkeligt, at indkøbsaftalen blot siger »Microsoft 365 i EU«.

Microsoft Data Guardian

Microsoft har i 2026 beskrevet Data Guardian som en funktion i virksomhedens Sovereign Public Cloud. Den kræver, at Microsoft-medarbejderes fjernadgang til systemer i de definerede europæiske områder godkendes og overvåges af autoriserede europæisk bosiddende medarbejdere og logges i et manipulationssikret register. (The Official Microsoft Blog)

Det er en reel forbedring af operationel kontrol og revisionsmuligheder.

Men bemærk forskellen:

Data Guardian siger ikke nødvendigvis, at kun europæiske teknikere kan tilgå systemet.
Den siger, at adgangen skal godkendes og overvåges fra Europa.
Hvis en tekniker uden for EØS faktisk kan se persondata, kan der stadig være tale om en tredjelandsoverførsel efter GDPR.

Det er derfor et risikoreducerende kontrolsystem, ikke en juridisk ophævelse af overførselsreglerne.

9. Det med koden i Schweiz

Det, du husker, er næsten sikkert Microsofts meddelelse fra 30. april 2025.

Microsoft lovede blandt andet, at virksomheden ville:

bestride ethvert udenlandsk påbud om at standse eller suspendere Microsofts cloudtjenester i Europa,
etablere kontinuitetsaftaler med europæiske partnere,
opbevare backupkopier af sin kode i et sikkert depot i Schweiz,
og give europæiske partnere de nødvendige juridiske rettigheder til at anvende koden, hvis det blev nødvendigt for at fortsætte driften. (The Official Microsoft Blog)

Det var ikke en open source-frigivelse.

Det var heller ikke primært en Schrems- eller GDPR-løsning. Det var en drifts- og geopolitisk kontinuitetsordning: Hvad gør Europa, hvis Microsoft på grund af et amerikansk påbud eller en alvorlig konflikt ikke længere må eller kan drive sine europæiske tjenester?

Kodekopierne:

hindrer ikke amerikanske myndigheder i at fremsætte krav om kundedata,
ændrer ikke i sig selv CLOUD Act,
og gør ikke Microsoft europæisk ejet.

De kan derimod forbedre muligheden for at opretholde driften sammen med europæiske partnere i et ekstremt scenarie.

10. Seks typiske leverandørscenarier

Scenario A: Europæisk virksomhed, EØS-servere og kun EØS-personale

Der er normalt ingen tredjelandsoverførsel, hvis ingen uden for EØS får oplysningerne stillet til rådighed.

Det er det enkleste scenario efter kapitel V. Men alle øvrige GDPR-krav gælder stadig, og den europæiske leverandør kan naturligvis have dårlig sikkerhed, utilstrækkelig kapacitet eller andre risici.

Europæisk ejerskab er ikke et sikkerhedscertifikat.

Scenario B: Europæisk virksomhed, men drift på Azure, AWS eller Google Cloud

Den europæiske leverandør kan fortsat være dataansvarlig eller hoveddatabehandler, men den amerikanske hyperscaler indgår i leverandørkæden.

Her skal man undersøge:

den præcise cloudregion,
om hyperscaleren kan tilgå data,
hvor supporten sidder,
hvem der kontrollerer nøglerne,
og hvilke logs og metadata der behandles globalt.

Europæisk ejerskab af den øverste leverandør fjerner ikke automatisk amerikansk eksponering længere nede i kæden.

Scenario C: Amerikansk ejet leverandør med EU-lagring og ingen adgang uden for EØS

Dette er ikke automatisk en tredjelandsoverførsel.

Der skal dog foretages en dokumenteret vurdering af:

om den amerikanske koncern reelt har kontrol,
om amerikansk lov kan anvendes,
om leverandøren teknisk kan producere læsbare data,
og hvordan den vil håndtere eventuelle myndighedspåbud.

Datatilsynet accepterer principielt, at en amerikansk cloudleverandør kan anvendes uden overførsel, men kræver en vurdering af risikoen ved eksempelvis CLOUD Act. (Datatilsynet)

Scenario D: EU-lagring, men support, sikkerhed eller administration uden for EØS

Dette indebærer typisk en tredjelandsoverførsel, når persondata faktisk gøres tilgængelige.

Der skal derfor findes et kapitel V-grundlag, eksempelvis:

DPF for en certificeret amerikansk modtager,
en anden tilstrækkelighedsafgørelse,
bindende virksomhedsregler, BCR,
eller SCC’er kombineret med en konkret vurdering og eventuelle supplerende foranstaltninger.

Scenario E: Direkte behandling hos en DPF-certificeret amerikansk virksomhed

Overførslen kan lovligt baseres på DPF, så længe den præcise enhed og datatypen er omfattet af en aktiv certificering.

Men databehandleraftale, behandlingsgrundlag, sikkerhed, sletning, dokumentation og øvrige GDPR-forpligtelser gælder fortsat.

Scenario F: Leverandøren kan ikke dekryptere oplysningerne

Dette er ofte den stærkeste tekniske beskyttelse mod både uvedkommende medarbejdere og myndighedspåbud til leverandøren.

Det kræver eksempelvis:

reel ende-til-ende-kryptering,
klient-side-kryptering,
eksternt administrerede nøgler,
eller en arkitektur, hvor kun kunden kan producere klartekst.

Men mange SaaS-tjenester skal kunne læse data for at søge, indeksere, analysere, samarbejde eller generere AI-output. De kan derfor ikke uden videre tilbyde fuld funktionalitet, hvis leverandøren aldrig må se klartekst.

11. Hvad danske virksomheder konkret bør gøre

1. Klassificér data og anvendelsen

Man bør ikke vælge cloudpolitik alene efter leverandørens navn. Start med at afgøre, hvad systemet skal indeholde:

almindelige kontakt- og kundedata,
medarbejderoplysninger,
oplysninger efter GDPR artikel 9,
oplysninger om strafbare forhold,
forretningshemmeligheder,
advokat-, læge- eller anden tavshedsbelagt kommunikation,
kritisk infrastruktur,
administrative konti og sikkerhedsnøgler,
eller klassificerede oplysninger.

Risikoen ved Microsoft 365 til almindelig mødeplanlægning er ikke den samme som ved et system med helbredsdata, straffesager eller adgangsnøgler til kritisk infrastruktur.

2. Kortlæg den præcise tjeneste

»Microsoft«, »Azure« eller »Copilot« er alt for upræcise betegnelser.

Kortlæg blandt andet:

produkt og licensvariant,
valgt region og tenant-geografi,
aktiverede tillægsfunktioner,
AI-modeller og modeludbydere,
supportniveau,
backup- og gendannelsesløsning,
sikkerhedsprodukter,
telemetri,
identitetsløsning,
subprocessorer,
og alle kontrolplans- og logstrømme.

Microsofts ændringslog viser netop, hvorfor en godkendelse af hele leverandøren ikke kan erstatte en vurdering af den enkelte tjeneste. (Microsoft Learn)

3. Kortlæg alle dataflows

Medtag ikke kun de egentlige dokumenter. Medtag også:

metadata,
bruger-id’er,
IP-adresser,
logfiler,
supporttickets,
fejldumps,
mødedata,
tale- og videodata,
AI-prompts,
embeddings og søgeindeks,
hændelsesdata,
samt sikkerhedskopier.

EDPB anbefaler som første skridt, at virksomheden kender og kortlægger sine overførsler. Hvis man ikke ved, hvor oplysningerne går hen, kan man heller ikke vurdere overførselsgrundlaget. (European Data Protection Board)

4. Identificér alle juridiske enheder

Find ud af:

hvem kontrakten indgås med,
hvem der er databehandler,
hvilke underdatabehandlere der anvendes,
hvem der er selvstændig dataansvarlig for bestemte oplysninger,
hvilke amerikanske enheder der er DPF-certificerede,
og om certificeringen også omfatter relevante datterselskaber.

Det er ikke tilstrækkeligt, at koncernens logo står på DPF-listen. Den juridiske enhed, der modtager data, skal være omfattet.

5. Fastslå overførselsgrundlaget

For hver dataflow bør virksomheden kunne angive ét af følgende:

ingen tredjelandsoverførsel,
tilstrækkelighedsafgørelse,
EU-U.S. Data Privacy Framework,
SCC’er,
BCR,
andet artikel 46-grundlag,
eller en konkret artikel 49-undtagelse.

Artikel 49-undtagelser er generelt beregnet til særlige og lejlighedsvise situationer og bør ikke anvendes som normal løsning på en løbende cloudtjeneste. (European Data Protection Board)

6. Lav den rigtige type vurdering

Der kan være behov for flere forskellige dokumenter:

almindelig GDPR-risikovurdering,
konsekvensanalyse, DPIA, hvis behandlingen sandsynligvis indebærer høj risiko,
Transfer Impact Assessment ved SCC- eller BCR-baserede overførsler,
informationssikkerhedsrisikovurdering,
leverandør- og koncentrationsrisikovurdering,
samt beredskabs- og exitvurdering.

DPF betyder, at man ikke behøver en TIA for selve kapitel V-overførselsgrundlaget til den certificerede virksomhed. Men DPF fjerner ikke kravet om en almindelig sikkerheds-, leverandør- eller DPIA-vurdering.

7. Brug tekniske foranstaltninger, der passer til risikoen

Relevante tiltag kan være:

dataminimering,
pseudonymisering eller tokenisering,
kryptering under transmission og lagring,
kundekontrollerede eller eksternt administrerede nøgler,
klient-side- eller ende-til-ende-kryptering,
confidential computing,
begrænsning af support til EØS,
just-in-time-adgang,
godkendelse af supportadgang,
dual control,
manipulationssikker logning,
og deaktivering af funktioner med globale dataflows.

Det er vigtigt at skelne mellem:

BYOK, hvor kunden leverer en nøgle, men leverandørens tjeneste stadig kan bruge den til dekryptering,
og en løsning, hvor leverandøren reelt ikke kan få adgang til nøglen eller klarteksten.

Kun den sidste type giver en stærk teknisk barriere mod tvungen udlevering af læsbare data.

8. Stil præcise kontraktkrav

En god databehandler- og cloudaftale bør blandt andet regulere:

præcise lagrings- og behandlingsområder,
fjernadgang fra tredjelande,
brug af underdatabehandlere,
varsel ved ændringer,
ret til at gøre indsigelse og opsige,
leverandørens håndtering af myndighedsanmodninger,
pligt til at udfordre uforholdsmæssige krav,
orientering af kunden, hvor dette er lovligt,
mindst mulig udlevering,
sikkerheds- og revisionsdokumentation,
sletning og returnering,
backup og gendannelse,
forbud mod egen brug og AI-træning,
dataeksport og portable formater,
samt konsekvenser, hvis DPF eller et andet overførselsgrundlag bortfalder.

Formuleringen »leverandøren overholder gældende databeskyttelseslovgivning« er ikke tilstrækkelig.

9. Hav en reel exitplan

Exitplanen bør testes, ikke blot beskrives.

Virksomheden bør vide:

hvor hurtigt alle data kan eksporteres,
i hvilket format,
om metadata, rettigheder og revisionsspor følger med,
hvordan identiteter og krypteringsnøgler flyttes,
om en alternativ leverandør kan overtage,
hvor længe en parallel drift kan opretholdes,
og hvordan data hos den gamle leverandør og underleverandører slettes.

Microsofts schweiziske kodedepot kan være en del af Microsofts egen kontinuitetsmodel, men det erstatter ikke kundens egen exitplan.

10. Overvåg ændringer løbende

En vurdering fra 2024 kan være forkert i 2026, fordi:

en ny AI-model er taget i brug,
en ny underdatabehandler er tilføjet,
supportmodellen er ændret,
nye globale dataflows er introduceret,
DPF-certificeringen er udløbet,
eller en dom har ændret retsgrundlaget.

Microsofts egne 2026-opdateringer vedrørende Copilot-, OpenAI- og Anthropic-funktioner er konkrete eksempler på, hvorfor løbende kontrol er nødvendig. (Microsoft Learn)

12. GDPR er ikke den eneste regulering

For danske organisationer kan blandt andet følgende også være relevante:

NIS 2,
DORA i finanssektoren,
CER-regler,
sektorlovgivning,
tavshedspligt,
regler om journalisering og arkivering,
sikkerhedsbeskyttelse af kritisk infrastruktur,
kontraktlige krav fra kunder eller myndigheder,
og regler om klassificerede oplysninger.

Den danske NIS 2-lov trådte i kraft den 1. juli 2025 og stiller for omfattede enheder krav om cybersikkerhedsforanstaltninger, risikostyring og hændelsesrapportering. DORA stiller tilsvarende omfattende krav til finansielle virksomheders digitale operationelle robusthed og tredjepartsrisici. (Samsik)

Det betyder, at en løsning godt kan være tilladt efter GDPR’s overførselsregler og alligevel være uegnet på grund af:

koncentrationsrisiko,
manglende exitmulighed,
utilstrækkelig driftskontinuitet,
manglende kontrol over administratorer,
eller sektorbestemte krav.

13. En praktisk beslutningsmodel

Almindelige forretningsdata

En amerikansk hyperscaler med:

behandling i EU Data Boundary,
aktiv DPF-certificering, hvor relevant,
en korrekt databehandleraftale,
dokumenterede dataflows,
god sikkerhed,
rimelige myndighedsadgangsgarantier,
og en exitplan

kan være en både lovlig og fagligt forsvarlig løsning.

Følsomme eller regulerede oplysninger

Her bør man normalt kræve mere:

strammere EØS-afgrænsning,
EU-baseret support,
stærkere nøglekontrol,
pseudonymisering,
eksplicit fravalg af globale funktioner,
sovereign cloud-kontroller,
og væsentligt stærkere audit- og exitrettigheder.

Oplysninger, hvor leverandøradgang er uacceptabel

Her bør arkitekturen som udgangspunkt sikre, at leverandøren ikke kan se klartekst.

Det kan pege mod:

klient-side-kryptering,
privat eller lokal cloud,
egen drift,
europæisk kontrolleret udbyder,
partneropereret sovereign cloud,
eller en fuldt isoleret løsning.

Det er især relevant for klassificerede oplysninger, meget følsomme myndighedsdata, kritiske adgangsoplysninger og visse professionelle hemmeligheder.

Den helt korte facitliste

Din antagelse om en amerikansk ejergrænse er ikke juridisk rigtig. Der findes ingen generel procentgrænse.

Din skepsis over for, at EU-servere skulle løse alt, er derimod velbegrundet. Serverplacering løser kun den geografiske del.

Schrems II betyder ikke, at amerikanske tjenester er forbudt. Det betyder, at overførselsgrundlaget og beskyttelsen skal fungere i praksis.

EU-U.S. Data Privacy Framework er gældende og kan anvendes til certificerede amerikanske virksomheder.Ordningen er dog fortsat under juridisk prøvelse.

Microsofts EU Data Boundary er en reel og betydelig forbedring. Men den har undtagelser og ophæver ikke amerikansk lovgivning eller koncernens tekniske og juridiske tilknytning til USA.

Kodekopierne i Schweiz er en kontinuitetsforanstaltning, ikke en GDPR- eller CLOUD Act-løsning.

Den mest holdbare politik for en dansk virksomhed er derfor:

Vurder ikke cloudtjenester alene efter ejerland eller serveradresse. Vurder den konkrete tjeneste efter dataklassifikation, dataflows, fjernadgang, underleverandører, myndighedsjurisdiktion, krypteringskontrol, overførselsgrundlag og exitmuligheder.

EU, AI og alt det umulige i dagens cybersikkerheds-univers: ChatGPT