EU-dataresidens för byråer: så garanterar du den på riktigt

EU-dataresidens betyder att din kunddata fysiskt ligger i en EU-region och förblir styrd av EU-rätten — och det enda sättet att garantera den på riktigt är att kontrollera var databasen skapas, på ett konto du äger, i stället för att lita på en leverantörs löfte att “hosta i EU” åt dig. Residens och suveränitet är två olika frågor, de flesta SaaS-produkter besvarar bara den första, och gapet mellan dem är där överföringsrisken gömmer sig.

Det här inlägget förklarar vad dataresidens verkligen betyder, varför “hostat i EU” är ett svagare påstående än det låter, hur Schrems II och amerikanska CLOUD Act formar risken, och hur valet av din egen region på ditt eget konto förvandlar residens från ett löfte till en resurs du kan peka på. Det är allmän information, inte juridisk rådgivning — bekräfta dina egna skyldigheter med en jurist.

Vad betyder “EU-dataresidens” egentligen?

Dataresidens är svaret på en fysisk fråga: i vilket land eller vilken region ligger den här datan i vila? För en byrå som hanterar EU-kunddata är det önskade svaret oftast “i en EU-region”, så att personuppgifter stannar inom det Europeiska ekonomiska samarbetsområdet i stället för att kopieras till servrar på annat håll.

Men residens i sig är bara halva bilden. Den andra halvan är datasuveränitet — vems lagar styr datan, och vem kan tvinga fram åtkomst till den? Data kan ligga i Frankfurt och ändå lyda under ett icke-EU-rättsläge om företaget som håller den omfattas av utländsk lag. GDPR är själv byggd kring den här skillnaden: kapitel V (artiklarna 44–50 i förordning (EU) 2016/679) begränsar överföringar av personuppgifter till “tredjeländer” just för att vart datan tar vägen och vem som kan nå den är separata risker från var disken står.

Ett komplett residenspåstående måste alltså besvara tre saker, inte en:

1. Plats — vilken region datan fysiskt ligger i.
2. Jurisdiktion — vems lag som styr den och vem som kan tvinga fram utlämning.
3. Kontroll — vem som valde regionen, och vem som senare i tysthet kan ändra den.

De flesta “hostat i EU”-formuleringar besvarar bara den första.

Varför “hostat i EU” är ett svagt residenslöfte

“Vi hostar i EU” låter betryggande, men som residensgaranti har det tre svaga punkter som spelar roll för en byrå som skriver på ett personuppgiftsbiträdesavtal.

Det är en policy, inte en konstruktion. En leverantör som väljer en EU-region i dag kan välja en annan i morgon, lägga till en USA-failover för robusthet, eller flytta supportverktyg utomlands — oftast utan att fråga dig. Påståendet är bara så hållbart som leverantörens nuvarande konfiguration och goda vilja.

Det täcker sällan hela kedjan. Den primära databasen kan ligga i EU medan säkerhetskopior, loggar, felövervakning, e-postleverans eller AI-funktioner går genom icke-EU-underbiträden. Var och en av dem är en potentiell överföring av personuppgifter. “Hostat i EU” beskriver en komponent; dina skyldigheter enligt artikel 28 om underbiträden täcker dem alla.

Det avgör inte jurisdiktionen. Om leverantören — eller dess moderbolag — omfattas av utländska åtkomstlagar sätter EU-placerade servrar inte datan utom räckhåll för de lagarna. Det är kärnan i överföringsproblemet, och det är där Schrems II och amerikanska CLOUD Act kommer in.

Vi skrev mer ingående om mekaniken i kedjan av underbiträden i dataresidens och GDPR för byråer — kortversionen är att konsolidering utan ägande bara centraliserar risken i en leverantör i stället för att sprida den över tre.

Vad förändrar Schrems II och CLOUD Act för EU-data?

Två utvecklingar förvandlade “var står servern” till “vems lag når datan”, och varje ärlig residensdiskussion måste ta hänsyn till båda.

Schrems II (2020). I mål C-311/18 ogiltigförklarade EU-domstolen ramverket Privacy Shield mellan EU och USA och slog fast att standardavtalsklausuler bara är en giltig överföringsmekanism om datan fortfarande får ett skydd som i allt väsentligt motsvarar EU-rätten i mottagarlandet. Den praktiska effekten: du kan inte överföra personuppgifter utanför EU på pappersarbete allena — du måste bedöma det faktiska rättsläge datan skulle utsättas för. (Ett efterföljande adekvansbeslut, Data Privacy Framework mellan EU och USA, antogs i juli 2023, men det har redan mött rättsliga utmaningar, så att förlita sig på det som permanent är optimistiskt.)

Amerikanska CLOUD Act (2018). Clarifying Lawful Overseas Use of Data Act tillåter amerikanska myndigheter att tvinga företag under amerikansk jurisdiktion att lämna ut data de kontrollerar — oavsett var datan fysiskt lagras. Ett amerikanskt företag (eller ett EU-dotterbolag till ett sådant) kan alltså vara nåbart även när servrarna står i EU. Det är den konkreta anledningen till att “hostat i EU” och “under EU-jurisdiktion” inte är samma mening.

Inget av detta betyder att EU-byråer inte kan använda teknik med någon USA-koppling — det finns gott om regelefterlevande uppsättningar. Det betyder att frågorna om jurisdiktion och kontroll är bärande, och att ett residenspåstående som bara talar om geografi i tysthet lämnar dem obesvarade.

“Hostat i EU” kontra residens på ditt eget konto

Skillnaden är lättast att se sida vid sida. Kolumnerna nedan jämför ett typiskt “hostat i EU”-löfte från en leverantör med en databas som skapas på ditt eget molnkonto, i en region du valt.

Fråga	“Hostat i EU” (leverantörslöfte)	Residens på ditt eget konto
Vem väljer regionen	Leverantören, som en policy	Du, vid provisioneringen
Vem kan ändra den senare	Leverantören, ofta utan förvarning	Du — det är din resurs
Vems konto håller datan	Leverantörens	Ditt
Jurisdiktionsexponering	Beror på leverantörens/moderbolagets rättsliga hemvist	Avgränsad av ditt konto och ditt regionval
Kedja av underbiträden	Leverantörens fullständiga lista, som kan växa	Kortare — infrastruktur du redan avtalar med
Bevis för en granskare	En klausul i en policy	En resurs synlig i din egen panel
Vad som händer vid utträde	Exportera, lita sedan på radering	Databasen förblir din; leverantören tappar åtkomst

Poängen är inte att “hostat i EU” är oärligt — gott om leverantörer menar det uppriktigt. Poängen är att varje rad till vänster är ett löfte du måste lita på, och varje rad till höger är ett faktum du kan granska. För en suveränitetsfråga i byråskala slår det granskbara det förtroendebaserade.

Så garanterar du residens genom att välja din region på ditt eget konto

Det här är designbeslutet bakom sSystm och, mer generellt, BYOC-modellen (Bring Your Own Cloud): det finns ingen central leverantörsdatabas som håller din CRM-data. När din organisation registrerar sig med sitt eget Cloudflare-konto skapar sSystm en dedikerad Cloudflare D1-databas på ditt konto, i regionen du väljer, med ett valfritt hårt löfte om EU-jurisdiktion.

Varför det är ett starkare residenspåstående än “hostat i EU”:

• Du väljer regionen, och det är din resurs. Databasen dyker upp i din egen Cloudflare-panel. Residens är inte en inställning leverantören sköter åt dig — det är ett val du gjorde på infrastruktur du kontrollerar.
• EU-jurisdiktionsgarantin är hård, inte en preferens. Med den påslagen är databasen låst till EU-jurisdiktion i stället för att hamna där som förval och potentiellt flyttas. Det adresserar direkt suveränitetshalvan av frågan, inte bara geografihalvan.
• Kedjan är kortare och närmare dig. Datan ligger på infrastruktur du redan har en direkt relation med, vilket kortar listan över parter med teknisk åtkomst — det dina artikel 30-register måste hålla reda på.
• Utträde flyttar inte datan. Eftersom databasen alltid låg på ditt konto återkallar ett utträde leverantörens åtkomst i stället för att utlösa en migrering. Det finns inget att exportera eftersom det inte finns något att lämna kvar.

Inget av detta tar bort dina skyldigheter som personuppgiftsansvarig. sSystm driver fortfarande mjukvaran och räknas fortfarande som personuppgiftsbiträde under GDPR, så du behöver fortfarande ditt eget biträdesavtal, din egen dokumentation av underbiträden och — om det här är en aktuell efterlevnadsfråga — din egen juridiska genomgång. Det som ändras är styrkan i det underliggande påståendet: du kan visa databasen, kontot och regionen i stället för att citera en policy. Mer om säkerhets- och datamodellen finns på säkerhetssidan.

Så garanterar du EU-dataresidens på riktigt: en checklista

Innan du skriver in ett residenspåstående i ett kundavtal, bekräfta följande om varje verktyg du använder — sSystm inräknat:

1. Ligger databasen på mitt konto eller leverantörens? Dedikerad-men- leverantörsägd är isolering, inte residens du kontrollerar.
2. Kan jag välja regionen — och är det ett riktigt provisioneringsval eller en marknadsföringsrad? Be att få se det i din egen konsol.
3. Är EU-jurisdiktion garanterad eller bara förval? Ett förval kan glida; en garanti är ett åtagande.
4. Hur ser hela listan över underbiträden ut, inklusive säkerhetskopior, loggar, e-post och AI-funktioner? De svaga punkterna ligger oftast utanför den primära databasen.
5. Omfattas leverantören (eller dess moderbolag) av utländska åtkomstlagar? Det är frågan om Schrems II / CLOUD Act — och den överlever en EU-region.
6. Vad händer vid utträde? Rätt svar är: leverantören tappar åtkomst, du behåller datan, utan något exportsteg.

Om en leverantör besvarar de tre första med “på ditt konto, din valda region, garanterad EU-jurisdiktion” har du ett residenspåstående du kan bevisa. Om svaren alla är “lita på vår policy” har du ett löfte — som mycket väl kan hållas, men som inte är samma sak.

Vart det här lämnar dig

EU-dataresidens är inte en kryssruta; det är tre frågor — plats, jurisdiktion och kontroll — och “hostat i EU” besvarar bara en av dem. Schrems II och amerikanska CLOUD Act är anledningen till att de andra två spelar roll, eftersom de visar att var en disk står och vems lag som når den kan gå isär. Det mest robusta svaret som finns tillgängligt för en byrå i dag är att hålla databasen på ditt eget konto, i en region du väljer, under ett hårt löfte om EU-jurisdiktion — så att residens blir en resurs du kan peka på i stället för ett löfte du måste tro på.

Börja med vad ett BYOC agency OS är för den underliggande modellen, läs den djupare genomgången av GDPR och underbiträden, och se säkerhets- och datamodellen för hur kopplingen fungerar i praktiken. Det här inlägget är allmän information om dataresidens, inte juridisk rådgivning; för dina specifika skyldigheter, tala med en jurist.