Data residency-krav i kontrakter efter Schrems II

Data residency som kontraktværktøj (ikke som GDPR‑lokaliseringskrav)

Data residency handler om, hvor data lagres og behandles geografisk, og hvorfor det betyder noget for, hvilke nationale regler der kan give myndigheder adgang—inklusive efterretnings- og sikkerhedslovgivning. Det er vigtigt at skelne mellem residency og data‑lokalisering: sidstnævnte er et hårdt lovkrav om, at bestemte data kun må befinde sig i et bestemt land, og GDPR er ikke en sådan lokaliseringslov.

GDPR fokuserer i stedet på overførsler til tredjelande og kræver, at beskyttelsesniveauet følger med data. Det kan ske via EU‑Kommissionens adekvansbeslutninger, via Standard Contractual Clauses (SCCs) eller mere sjældent Binding Corporate Rules. Derfor er det afgørende ikke kun, hvor serveren fysisk står, men om data i praksis er beskyttet mod uforholdsmæssig adgang.

Alligevel ser man “EU‑only” eller “DK‑only” som kontraktkrav, fordi geografi i praksis påvirker både overførselsmekanismer og kompleksiteten i risikovurderinger. Når du kan undgå tredjelands‑elementer, bliver governance enklere, og du bruger færre kræfter på Transfer Impact Assessments, supplerende foranstaltninger og løbende regulatorisk dialog.

“Det er ikke serverens adresse alene, der afgør risikoen—men hvem der kan tilgå data, fra hvilke jurisdiktioner, og på hvilke vilkår.”

Schrems II: hvorfor cloud-kontrakter blev mere detaljerede

Schrems II‑dommen fra 2020 ændrede udgangspunktet for internationale overførsler: EU‑US Privacy Shield blev kendt ugyldigt, SCCs forblev et gyldigt værktøj, men kun hvis de reelt kan efterleves, og ansvaret for vurderingen blev flyttet ned på virksomhedsniveau. Det betyder, at hver overførsel skal vurderes konkret, og at dokumentation ikke længere er en formalitet, men en forventning.

I praksis er et “EU‑datacenter” ikke nok, hvis leverandøren samtidig har supportpersonale i tredjelande med adgang til produktionsmiljøer. EDPB har gjort det klart, at fjernadgang fra et tredjeland også kan være en international overførsel, så support, monitoring og incident response er blevet juridiske kernepunkter på linje med hosting‑lokation.

Derfor vælger mange EU‑only som risikoreduktion, især ved store mængder persondata, sundhedsoplysninger eller finansielle data, hvor det kan være vanskeligt at dokumentere “essentielt ækvivalent” beskyttelse, hvis data kan tilgås fra lande med vidtgående overvågningsbeføjelser. Samtidig forventer tilsynsmyndigheder, herunder Datatilsynet, ofte mere dokumentation fra offentlige myndigheder og regulerede virksomheder, hvilket også skubber residency‑krav ind i udbud og standardvilkår.

Kontraktstyring bliver afgørende, fordi residency‑klausuler sjældent står alene, men hænger sammen med databehandleraftaler, sikkerhedsbilag og governance. Hvis du samler klausuler, SCC‑henvisninger og underleverandørvilkår ét sted, bliver det lettere at reagere, når leverandøren ændrer setup—et typisk fokusområde i ClearContracts modul til kontraktstyring, hvor metadata kan bruges til at flagge aftaler med tredjelands‑elementer.

Hvornår EU/DK-only giver mening—og hvad du bør regulere

EU‑ eller DK‑residency er sjældent et absolut krav, men ofte et klogt valg, når datatypen er følsom, når leverandøren er underlagt tredjelandslovgivning med vidtgående adgangsbeføjelser, eller når din organisation er underlagt skærpet tilsyn. Derudover kan residency reducere den løbende compliance‑byrde, fordi hver international overførsel ellers kræver vurdering, dokumentation og opfølgning.

Kontraktkrav skal formuleres præcist: “data lagres i EU” er typisk for uklart, hvis du ikke også dækker produktion, test, backup og disaster recovery. Derudover bør du tage stilling til, om leverandøren må flytte data til andre regioner, og hvilke betingelser der gælder, hvis flytning bliver nødvendig af tekniske eller forretningsmæssige årsager.

Fjernadgang er ofte det punkt, der “knækker” et EU‑only setup. Hvis residency er centralt, bør kontrakten enten forbyde fjernadgang fra tredjelande eller stille skrappe krav, for eksempel stærk kryptering, begrænset tidsadgang og fuld logning, så du kan dokumentere, hvem der havde adgang, hvornår og fra hvilken jurisdiktion.

Underleverandører er tilsvarende en skjult risiko i cloud, fordi sub‑processorer kan bruges til hosting, support og drift. Uden ret til at godkende eller gøre indsigelse mod nye underleverandører—og uden et klart flow‑down af residency‑ og overførselskrav—kan data i praksis forlade EU, selv om hovedaftalen siger det modsatte.

• Datacenter‑lokation og miljøer, inklusive produktion, test, backup og disaster recovery
• Regler for fjernadgang og support fra tredjelande, med krav til kontrol og logning
• Indarbejdelse af SCCs og pligt til løbende Transfer Impact Assessments
• Krav til underleverandører og flow‑down af forpligtelser i hele kæden
• Konsekvenser ved manglende overholdelse, herunder suspension og ansvar, samt håndtering når rammerne ændrer sig

Endelig bør du koble kontrakten til governance i praksis, så residency‑krav hænger sammen med fortegnelser, risikovurderinger og tekniske kontroller. Mange organisationer mister overblikket, når cloud‑leverandører løbende ændrer arkitektur og supportmodeller, og her kan AI‑drevet kontraktgennemgang hjælpe med at identificere klausuler om overførsel, residency og underleverandører på tværs af porteføljen.

Når ledelse eller compliance beder om status—hvor mange aftaler indebærer tredjelands‑overførsler, og hvor er risiciene—bliver strukturerede data centrale. Med løbende rapportfunktioner kan du dokumentere udviklingen og stå stærkere i dialog med kunder og tilsyn.

Key Takeaways

For det første er data residency‑krav i kontrakter primært et risikostyringsværktøj efter Schrems II, ikke et generelt GDPR‑krav om at holde data i EU. For det andet er fjernadgang og underleverandører ofte vigtigere end “EU‑datacenter” som enkeltstående løfte, fordi adgang fra tredjelande kan udgøre en overførsel. For det tredje bør kontrakter beskrive miljøer, adgangsmodeller, SCC‑forpligtelser og konsekvenser ved ændrede risici, så du kan handle hurtigt, hvis beskyttelsesniveauet ikke længere er acceptabelt. Næste skridt er at gennemgå jeres cloud‑aftaler for tredjelands‑elementer og sikre, at governance kan følge leverandørens ændringer; hvis I vil se, hvordan det kan understøttes i praksis, kan I overveje at booke en demo eller teste platformen i jeres egne workflows.