GDPR och dataskydd med Next.js: var hamnar datan?

GDPR handlar i grunden om var personuppgifter finns och vem som kan komma åt dem. Den frågan är inte juridisk i första hand, den är teknisk: vilka system används, var är de driftsatta, och vad händer med datan när en besökare fyller i ett formulär eller accepterar en cookie? Den här guiden visar hur den tekniska uppsättningen av en Next.js-sajt formar de svaren, så att en beslutsfattare kan ställa rätt frågor till sin leverantör.

Varför arkitekturen avgör ert ansvar

Var personuppgifter samlas in, lagras och skickas avgör vilket dataskyddsansvar ni har. En sajt som inte samlar in något har minimal exponering. En sajt med inloggning, formulär och analysverktyg har betydligt mer.

Ofta behandlas GDPR-frågor som något man löser med en integritetspolicy och en cookie-banner. De är nödvändiga, men räcker inte om den bakomliggande tekniken skickar personuppgifter till tjänster utanför EU utan rättslig grund. Arkitekturen är inte ett tekniskt sidospår: den avgör hur stor compliance-uppgiften faktiskt blir och var riskerna sitter.

En viktig konsekvens av detta är att valet av byggmetod och hosting bör tas med GDPR i åtanke från start, inte läggas till som ett lager efteråt.

Var hamnar datan med Next.js?

En statiskt genererad Next.js-sajt utan databas samlar i sig inte in personuppgifter. Sajten serveras som färdiga filer till besökarens webbläsare, ungefär som ett PDF-dokument. Ingen information om besökaren sparas på servern.

Exponeringen uppstår vid de funktioner ni lägger till: kontaktformulär, inloggning, kommentarer, ett kopplat innehållshanteringssystem, analysverktyg. Var och en av dem är en punkt där personuppgifter kan samlas in och skickas vidare.

Jämfört med en typisk WordPress-installation, som alltid har en användardatabas med konton, sessioner och loggdata, krymper en databasfri Next.js-sajt ytan ni behöver skydda. Det är inte ett argument för att strunta i GDPR, men det förenklar kartläggningen när man vet exakt vilka tillägg som finns.

Vercel (USA) kontra egen hosting i EU

Vercel är den vanligaste plattformen för Next.js, och den är byggd i grunden på amerikansk infrastruktur. Personuppgifter som passerar eller lagras på Vercels servrar kan därmed hamna i USA, vilket i GDPR:s mening är en tredjelandsöverföring, det vill säga en överföring av personuppgifter till ett land utanför EU/EES.

Sådana överföringar kräver en giltig rättslig grund. Sedan EU-domstolens dom i Schrems II-målet 2020 har kraven skärpts, och regelverket har förändrats flera gånger sedan dess. I dag hanteras överföringar till USA primärt via Data Privacy Framework, det avtal som EU och USA tecknade 2023, kompletterat med standardiserade avtalsklausuler. Området är aktivt och bör stämmas av med er juridiska rådgivare baserat på aktuellt läge.

Alternativet är att driftsätta sajten på en server eller plattform inom EU. Hetzner och DigitalOcean har båda datacenter i Frankfurt och Amsterdam; svenska och nordiska VPS-leverantörer finns också. På en EU-server sker ingen tredjelandsöverföring enbart av att sajten är tillgänglig.

Avvägningen är reell. Vercel är enklast att komma igång med och driftsätta på, med automatiserade uppdateringar och inbyggd prestandaoptimering. EU-hosting ger tydligare dataskydd och enklare dokumentation, men kräver mer teknisk förvaltning. Mer om de alternativen finns i hosting-guiden.

Cookies och samtycke

Cookies delas i två kategorier: nödvändiga, som krävs för att sajten ska fungera, och icke-nödvändiga, som används för analys, marknadsföring eller spårning. Icke-nödvändiga cookies kräver aktivt samtycke från besökaren innan de sätts, och det samtycket måste inhämtas innan spårning startar, inte efteråt.

Google Analytics är det vanligaste analysverktyget, men det sätter cookies och skickar data till Googles servrar i USA. Det kräver alltså samtycke och utgör en tredjelandsöverföring. Privacy-vänliga alternativ som Plausible och Umami, båda europeiska i ursprung, erbjuder besöksstatistik utan cookies och kan driftsättas på egen server inom EU. Då försvinner behovet av samtycke för analysen, och ingen data lämnar er infrastruktur.

Det är en avvägning mellan bekvämlighet och kontroll. Google Analytics är gratis och kraftfullt. Plausible och Umami kostar något men förenklar compliance påtagligt, särskilt om ni riktar er mot offentlig sektor eller verksamheter med höga dataskyddskrav.

Formulär och tredjepartstjänster

Kontaktformulär är den vanligaste källan till personuppgifter på företagssajter. Frågan är inte om formuläret finns, utan vart datan skickas när någon fyller i det.

En Next.js-sajt kopplas ofta mot externa tjänster för att hantera formulärdata: e-posttjänster som SendGrid eller Mailgun för att vidarebefordra meddelanden, CRM-system för att lagra kontakter, formulärtjänster som Typeform eller Tally, betaltjänster som Stripe, och analysverktyg. Var och en av dessa tjänster behandlar personuppgifter för er räkning och är därmed ett personuppgiftsbiträde i lagens mening.

Med varje personuppgiftsbiträde krävs ett personuppgiftsbiträdesavtal, ett skriftligt avtal som reglerar hur tjänsten får behandla datan. Många stora tjänster tillhandahåller sådana avtal i standardform, men de måste aktivt tecknas och dokumenteras. En lista med alla externa tjänster som tar emot personuppgifter är ett bra ställe att börja.

Ju färre externa tjänster, desto enklare är dokumentationen. Det är inte alltid möjligt att minimera, men det är ett argument för att välja tjänster med tydlig EU-närvaro och färdiga biträdesavtal.

Är er setup förenlig?

En enkel genomgång kan ge svar på de viktigaste frågorna:

Vet ni var datan lagras? Servrar, databaser och externa tjänster bör vara kartlagda. Om ingen kan svara är kartläggningen det första steget.

Har ni biträdesavtal med alla externa tjänster? Varje tjänst som behandlar personuppgifter för er räkning kräver ett avtal. Kontrollera att de finns och är signerade.

Hämtar ni in samtycke för icke-nödvändiga cookies? En cookie-banner räcker inte om den inte faktiskt blockerar icke-nödvändiga cookies tills besökaren godkänner.

Sker överföringar till länder utanför EU/EES? Om ja, finns det giltig rättslig grund och dokumentation för varje sådan överföring?

Kan ni inte svara på någon av de här frågorna bör en genomgång göras, helst innan lansering. En enklare arkitektur, gärna databasfri och driftad inom EU, gör den genomgången kortare och svaren tydligare. Det är inte alltid det billigaste valet på kort sikt, men det minskar den juridiska osäkerheten och förenklar den löpande dokumentationen.