GDPR för webbplatser: vad som faktiskt krävs för att bygga en som följer reglerna

De flesta GDPR-råd på nätet är skrivna för jurister eller för den som köper en policygenerator. Väldigt lite är skrivet för den som måste öppna en editor och ändra något.

Den här guiden är av det andra slaget. Den går igenom vad dataskyddsförordningen (GDPR) kräver av en webbplats och systemen bakom den, uttryckt som saker du bygger, konfigurerar eller tar bort. Vi har gjort det här arbetet för företag som verkar i EU sedan förordningen började tillämpas 2018, och mönstret för vad som går fel har knappt förändrats sedan dess.

En sak ska sägas direkt: GDPR blev inte enklare för att nyare regelverk tillkom. Den blev viktigare, eftersom nästan allt i den nuvarande vågen av digitala EU-regler förutsätter att du redan har ordning på dina personuppgifter.

Börja med en ärlig inventering av data

Nästan varje misslyckat GDPR-projekt som vi har tagit över misslyckades på samma ställe. Teamet skrev policyn först och upptäckte datan senare.

Innan något annat, kartlägg vilka personuppgifter din webbplats faktiskt samlar in. Inte vad produktspecifikationen säger att den samlar in. Det som finns i databasen, loggarna, analysplattformen, CRM-systemet, supportverktyget, verktygen för marknadsföringsautomation, felspårningen, CDN-loggarna och tredjepartsskripten på sidan.

I praktiken betyder det:

• Gå igenom schemat med grep. Varje kolumn som kan identifiera en person, direkt eller i kombination med en annan kolumn.
• Läs nätverksfliken vid en verklig sidladdning. Varje utgående anrop till en domän du inte kontrollerar är en möjlig överföring av personuppgifter, eftersom en IP-adress plus en user agent är en personuppgift.
• Kontrollera vad din felspårning fångar. Stackspårningar innehåller rutinmässigt e-postadresser, tokens och anropskroppar.
• Kontrollera hur länge loggar sparas. Åtkomstloggar med IP-adresser som sparas för evigt är ett av de vanligaste fynden och ett av de enklaste att åtgärda.

Skriv ner det som ett register över behandlingar. Artikel 30 kräver det ändå för de flesta organisationer, och den version som är användbar för utvecklare är en tabell med system, data, ändamål, rättslig grund, lagringstid och mottagare.

Välj rättslig grund per ändamål, inte per system

Artikel 6 ger dig sex rättsliga grunder. Det misstag vi ser oftast är att man väljer en för hela produkten.

Du har nästan säkert flera ändamål igång samtidigt. Att fullgöra en order är avtal. Bedrägerikontroller är oftast berättigat intresse eller rättslig förpliktelse. Att spara fakturor under den lagstadgade tiden är rättslig förpliktelse. Marknadsföringsmejl är samtycke i de flesta medlemsstater. Analys som inte är nödvändig är samtycke, på grund av ePrivacy-reglerna om åtkomst till terminalutrustning snarare än GDPR i sig.

Den praktiska konsekvensen är att din datamodell måste veta vilket ändamål varje post tjänar. Om du inte kan skilja marknadsföringsprofilen från orderposten kan du inte respektera en invändning mot marknadsföring utan att förstöra orderhistoriken. Den uppdelningen är ett schemabeslut, och den är plågsam att bygga in i efterhand.

Samtycket måste vara äkta, och det måste registreras

Om du bygger på samtycke måste det vara frivilligt, specifikt, informerat och otvetydigt, och du måste kunna visa det i efterhand.

Konkret:

• Ingenting som inte är nödvändigt körs innan användaren gör ett val. Det gäller analysskriptet, annonspixeln, chattwidgeten, typsnittet som laddas från ett CDN hos tredje part och skriptet för A/B-tester.
• Att avvisa måste vara lika enkelt som att godkänna. Samma lager, samma synlighet, samma antal klick. Tillsynsmyndigheterna behandlar allt annat som ett manipulativt designmönster (dark pattern), och de har varit konsekventa i det.
• Samtycke ges per ändamål. En enda reglage som täcker ”analys och marknadsföring och personalisering” är inte specifikt.
• Att återkalla är lika enkelt som att ge. En länk som alltid finns eller en flytande knapp, inte ett mejl till supporten.
• Spara beviset: en tidsstämpel, samtyckessträngen eller statusen för varje kategori, bannerns version och texten användaren fick se. Utan versionen kan du inte försvara en två år gammal samtyckespost.

Tillsynen här är inte teoretisk. I september 2025 bötfällde den franska dataskyddsmyndigheten samma dag Google med 325 miljoner euro och Shein med 150 miljoner euro för deras hantering av cookies. Båda fallen handlade om mekanik snarare än om policytext: cookies som sattes före all interaktion, och avvisningsknappar som inte faktiskt avvisade.

Reglerna på det här området är också i rörelse. Kommissionens förslag Digital Omnibus skulle flytta samtycket för terminalutrustning in i själva GDPR och göra signaler på webbläsarnivå bindande. Rådet går åt andra hållet: dess utkast till förhandlingstext från 2 oktober 2026 behåller enligt uppgift cookiesamtycket i artikel 5.3 i ePrivacy-direktivet och stryker båda de nya GDPR-artiklarna. Den 10 oktober 2026 hade rådet ännu inte antagit den ståndpunkten, och förhandlingarna med parlamentet hade inte börjat. Vi gick igenom vad kommissionens förslag skulle ändra i cookiesamtycke efter Digital Omnibus.

Bygg maskineriet för de registrerades rättigheter tidigt

Artiklarna 15 till 22 ger människor rätt till tillgång, rättelse, radering, begränsning, dataportabilitet och att invända. Du har en månad på dig att svara, som kan förlängas till tre i komplicerade fall.

Team brukar hantera de första förfrågningarna manuellt, vilket fungerar ända tills det inte gör det. Det du vill ha, i god tid innan volymen kommer:

En sökfunktion som hittar en person i alla system. Ge den en e-postadress och få tillbaka allt: kontot, ordrarna, supportärendena, marknadsföringsprofilen, analysidentifieraren, loggarna. Om en människa måste komma ihåg att det finns en recensionsplattform hos tredje part som har data, kommer någon förr eller senare att glömma det.

En raderingsväg som respekterar lagringsskyldigheter. Rätten till radering är inte absolut. Fakturor måste oftast finnas kvar av skatteskäl. Det du behöver är mjuk radering kombinerad med hård radering per ändamål, så att du kan ta bort marknadsföringsprofilen men behålla bokföringsposten, och så att bokföringsposten i sin tur försvinner enligt schema.

En portabel export. Strukturerad, allmänt använd, maskinläsbar. JSON går bra. En pdf av en renderad HTML-sida gör det inte.

En invändningsflagga som hela systemet läser. En invändning mot profilering måste faktiskt stoppa profileringen, även i batchjobbet som körs klockan tre på natten och inte kontrollerar flaggan.

Lagringstid är ett jobb, inte en rad i en policy

Lagringsminimering är den princip som oftast bryts av system som annars är välbyggda, eftersom det krävs att någon skriver och schemalägger ett jobb som ingen ber om för att data ska raderas.

Ge varje datakategori en bestämd livslängd och genomför den sedan. Åtkomstloggar, sessionsposter, övergivna varukorgar, overifierade registreringar, avslutade supportärenden, gamla säkerhetskopior och rådata från analys behöver alla ett utgångsdatum. Säkerhetskopior förtjänar särskild uppmärksamhet: om din återställningsprocess väcker liv i raderade personuppgifter är din radering ofullständig, och det vanliga svaret är dokumenterad rotation av säkerhetskopior med en maximal ålder plus att raderingarna tillämpas på nytt efter varje återställning.

Överföringar, underbiträden och var din teknikstack faktiskt körs

Överföringar utanför EES kräver en rättslig mekanism, oftast EU-US Data Privacy Framework för certifierade mottagare i USA eller standardavtalsklausuler plus en bedömning av överföringens konsekvenser i övriga fall.

Den tekniska vinkeln är enklare än den juridiska: vet var din data fysiskt finns. Det betyder molnregionen för varje tjänst, var dina säkerhetskopior ligger, regionen för din hanterade databas, konfigurationen av CDN-noderna och, viktigt, supportmodellen för varje SaaS-verktyg du använder. En leverantör med hosting i Frankfurt vars supportteam når produktionsmiljön från ett land utanför EES är fortfarande en överföring.

Vi rekommenderar i allmänhet att hålla personuppgifter i EU-regioner när det inte finns starka skäl att låta bli. Det tar bort en hel kategori av diskussioner, och kostnadsskillnaden är oftast försumbar.

Håll en förteckning över underbiträden och håll den aktuell. Artikel 28 kräver ett skriftligt biträdesavtal med vart och ett, och förteckningen är också det dina kunder kommer att be om vid en due diligence.

Säkerhet som standard, uttryckt som konfiguration

Artikel 32 kräver lämpliga tekniska och organisatoriska åtgärder. Det är medvetet vagt, men grundnivån för en webbplats 2026 är det inte:

• TLS överallt, HSTS aktiverat, inget blandat innehåll.
• Lösenord hashade med en modern minneskrävande funktion, och flerfaktorsautentisering tillgänglig för konton som innehåller personuppgifter.
• Kryptering i vila för databaser och säkerhetskopior.
• Åtkomst till personuppgifter i produktion begränsad efter roll och loggad, med granskningar som faktiskt blir av.
• Pseudonymisering där det går: hasha identifieraren i analysen, håll mappningstabellen separat och åtkomstkontrollerad.
• En testad återställning, inte bara en säkerhetskopia.

Inbyggt dataskydd och dataskydd som standard enligt artikel 25 betyder att det integritetsvänliga alternativet är det du får utan att göra något. Kryssrutan för nyhetsbrev är inte ikryssad. Profilen är privat. Valfria fält är valfria.

Anmälan av personuppgiftsincidenter behöver en körbok

Sjuttiotvå timmar från att du får kännedom till anmälan till tillsynsmyndigheten är inte länge, särskilt om incidenten upptäcks en fredagkväll. Observera att förslaget Digital Omnibus skulle ändra det till nittiosex timmar, även om det ännu inte är lag.

Förbered i förväg: vem som utlyser en incident, vem som bedömer om personuppgifter har påverkats, vem som kontaktar tillsynsmyndigheten, vad anmälan innehåller och hur du informerar de berörda om risken är hög. Skriv det som en körbok med namngivna roller och öva den en gång. Första gången du använder den ska inte vara första gången du läser den.

Själva webbplatsen

En del av GDPR syns på sidan, och det är värt att få detaljerna rätt, eftersom det är sådant som folk anmäler.

Din integritetspolicy måste ange den personuppgiftsansvariges identitet och kontaktuppgifter, ändamål och rättsliga grunder, mottagare och kategorier av mottagare, mekanismer för överföring, lagringstider, hela listan över rättigheter inklusive rätten att klaga hos en tillsynsmyndighet, och om det förekommer automatiserat beslutsfattande. Skriv den på ett språk som en vanlig människa kan följa. Information i flera lager, med en kort version som länkar till detaljerna, fungerar bättre än en vägg av text.

Formulär ska bara samla in det du behöver. Varje fält är en motivering som du kan behöva lämna. Om kryssrutan för samtycke till marknadsföring skickas in tillsammans med ordern måste den vara separat, inte ikryssad och ha en egen formulering.

Inbäddningar från tredje part är det tysta misslyckandet. YouTube i integritetsförbättrat läge, kartor bakom en platshållare som laddas vid klick, typsnitt som ligger på din egen server i stället för att hämtas från ett CDN hos tredje part. Var och en av dessa är en liten ändring, och var och en tar bort ett fynd.

Det vi oftast ser gå fel

Efter tillräckligt många granskningar dyker samma korta lista upp gång på gång:

1. Analys som laddas före samtycke, oftast för att en tagghanterare konfigurerades av marknadsavdelningen och aldrig granskades av utvecklarna.
2. Avvisningsknappar som ändå utlöser samtycke på grund av ett tredjepartsskripts standardbeteende.
3. Inga lagringsjobb alls, i någon tabell.
4. Radering som missar säkerhetskopior, loggar och CRM-systemet.
5. En integritetspolicy som beskriver ett dataflöde som ändrades för arton månader sedan.
6. Förteckningar över underbiträden som slutar vid de tre uppenbara leverantörerna.
7. Samtyckesposter utan version av texten som visades.

Inget av detta är svåra problem. Det är bara arbete som ingen har fått i uppdrag att göra.

Att få hjälp

Om du vill att någon annan ska granska en befintlig webbplats gör vi tekniska GDPR-granskningar som resulterar i en prioriterad backlogg snarare än en rapport: vad som ska åtgärdas, i vilken ordning, med en uppskattning för varje punkt. Om du bygger något nytt är det betydligt billigare att få datamodellen och samtyckesarkitekturen rätt från början.

Vi hanterar också det bredare området för EU-regelefterlevnad, bland annat tillgänglighet och etablering på den europeiska marknaden. Nå oss på office@c9group.dev.

Vi bygger programvara. Vi ger inte juridisk rådgivning, och tolkningen av ett specifikt krav hör hemma hos din jurist. Det vi kan göra är att se till att systemet gör det som din jurist säger att det ska göra.