Hosting i EU: hvad det reelt betyder for compliance

Kunder og partnere spørger oftere, hvor data ligger, end de gjorde for få år siden. Det er legitimt. Personoplysninger i en SaaS, en kundeportal eller en marketing-site er ikke "bare content". Det er ordrer, mails, CPR-lignende identifikatorer, supporttråde og logs, der kan rekonstruere et menneske.

Problemet er, at samtalen ofte ender i et binært valg: dansk hosting eller "cloud i USA". Det er et dårligt kort. En dansk leverandør kan stadig sende backups til et US-værktøj, lade support logge ind fra et tredje land, eller bruge et CDN der cacher sider med persondata. En US-ejet platform kan køre compute og storage i EU, have en DPA og en dokumenteret transfer-mekanisme — og stadig være det forkerte valg, hvis I spejler produktionsdata til et analyseværktøj uden grundlag.

Hvis I tager beslutningen som et flag på et kort, bygger I et system I ikke kan forklare, den dag nogen beder om dokumentation. Hvis I tager den som et datakort — hvad I gemmer, hvor det ligger, hvem der kan åbne det — kan I både vælge stack og sove om natten.

Det her er ikke juridisk rådgivning. Det er den ingeniørsamtale, I skal have, før juristen overhovedet kan sige noget nyttigt. Uden et ærligt kort bliver DPA'en et dokument, I underskriver uden at forstå.

Residency er det simple: de bytes, I kalder primære, ligger på disk i en EU-region. Frankfurt, Amsterdam, Stockholm, Irland. Det er et rigtigt og ofte nødvendigt valg. Det er ikke det samme som, at behandlingen er lovlig, at I har et behandlingsgrundlag, eller at ingen uden for EU kan se dataene.

GDPR spørger først: hvad er formålet, hvad er grundlaget, hvor længe gemmer I det, og kan den registrerede få indsigt og sletning. En server i Herning hjælper jer ikke, hvis I gemmer mere end I behøver, eller hvis I ikke kan slette en bruger fordi backups er evige og umærkede.

Derefter kommer underleverandører. Jeres host er én databehandler. Analytics, email, error-tracking, auth, betalingsgateway, AI-API og supportværktøj er andre. Hver af dem har egne under-underleverandører. "Vi hoster i EU" er et ufuldstændigt svar, hvis jeres fejltracker sender stack traces med e-mails til et US-SaaS uden DPA.

Endelig er der adgang. En database i Frankfurt, som en supportmedarbejder i et tredjeland kan åbne via et admin-panel, er stadig en overførsel. Det samme gælder et CI-system der trækker produktions-dumps, eller et staging-miljø der er en kopi af produktionen. De stier er dem, vi ser teams glemme, mens de skændes om region-dropdownen.

Første spørgsmål: hvilke personoplysninger behandler produktet, og hvorfor? En marketing-site med et kontaktformular er et andet problem end en kundeportal med ordrer, dokumenter og organisationsmedlemmer. Hvis I ikke kan liste kategorierne på én side, er I ikke klar til at vælge host. I er klar til at rydde op i scope.

Andet spørgsmål: hvor ligger den primære kopi, og hvor ligger de sekundære? Primær database, object storage, search-indeks, logs, backups, CDN-cache, preview-databaser. Det er her, "vi kører i EU" ofte smuldrer. CDN'et cacher HTML med navne. Log-platformen ligger i US. Backup-bucket'en blev oprettet i den forkerte region, fordi default var us-east-1.

Tredje spørgsmål: hvem kan læse data uden at gå gennem jeres applikation? Platform-support, jeres eget driftsteam, et bureau, et AI-værktøj der får dumps, en underleverandør med "break-glass". Hvis svaret er "vi ved det ikke", har I et adgangsproblem — ikke et hostingproblem.

Når de tre er besvaret, bliver stack-valget konkret. Så kan I sige: primær data i EU, logs i EU, ingen produktionsdumps i CI, DPA med navngivne underleverandører, og support-adgang kun via jeres eget IdP. Det er et design. "Find en dansk host" er et håb.

En klassisk "dansk host" — managed VPS eller et dansk datacenter — giver jer en kort kontrakt og ofte support på dansk. Det er rigtigt, når workloaden er enkel, og I selv styrer, hvad der sendes ud. Det er forkert, når I tror, at datacenteret erstatter DPA'er på alle de SaaS-værktøjer, appen allerede bruger. Hosting er én linje. Produktet er ti.

AWS, GCP og Azure kan køre primær data i eu-central, eu-north eller tilsvarende. I får region-kontrol, encryption, og en DPA I kan pege på. I får også et katalog af services, der default'er til globale endpoints, og et supportapparat der er globalt. Det er forsvarligt, når I låser region, slår utilsigtede globale features fra, og ved hvordan I håndterer et support-escalation. Det er uforsvarligt, når I klikker "næste" i wizard'en og antager, at EU-konti betyder EU-alt.

Vercel og Cloudflare er oftere det, et Next.js-produkt faktisk kører på. Compute og edge er globale eller regionale efter produkt; storage og databaser (Postgres, R2, KV, blob) kan lægges i EU. Det rigtige spørgsmål er ikke "er Vercel lovligt i Danmark". Det rigtige er: hvor ligger jeres database, hvor ligger uploads, hvad logger platformen, og hvilke underleverandører står i deres DPA. En marketing-site uden konti er et andet risikobillede end en SaaS med brugere.

Hybrid er det, vi oftest anbefaler, når produktet er rigtigt: frontend og cache tæt på brugerne, primær database og filer i en EU-region I kan pege på, og tredjepartsværktøjer valgt bevidst — ikke fordi de lå i start-skabelonen. Sammenligningen mellem Vercel og Cloudflare handler om drift og model, ikke om et magisk compliance-stempel. Ingen af dem fjerner jeres pligt til at kende jeres egne underleverandører.