GDPR-compliance for websites: hvad der reelt skal bygges

De fleste GDPR-råd på nettet er skrevet til jurister eller til folk, der køber en policygenerator. Meget lidt er skrevet til den person, der skal åbne en editor og ændre noget.

Denne guide er af den anden slags. Den gennemgår, hvad databeskyttelsesforordningen kræver af et website og systemerne bag, udtrykt som ting, du bygger, konfigurerer eller sletter. Vi har lavet dette arbejde for virksomheder i EU, siden forordningen begyndte at gælde i 2018, og mønsteret for, hvad der går galt, har næsten ikke ændret sig.

Én ting først: GDPR blev ikke lettere, fordi nyere regler kom til. Den blev vigtigere, fordi næsten alt i den nuværende bølge af EU-digitalregler forudsætter, at dine personoplysninger allerede er i orden.

Start med en ærlig dataoversigt

Næsten hvert mislykket GDPR-projekt, vi har overtaget, fejlede samme sted. Teamet skrev politikken først og opdagede dataene bagefter.

Før alt andet, kortlæg hvilke personoplysninger dit website faktisk indsamler. Ikke hvad produktspecifikationen siger. Det, der ligger i databasen, loggene, analyseplatformen, CRM'et, supportværktøjet, marketingautomatiseringen, fejlsporeren, CDN-loggene og tredjepartsscripts på siden.

I praksis betyder det:

• Gå skemaet igennem. Hver kolonne, der kan identificere en person, alene eller kombineret med en anden.
• Læs netværksfanen ved en rigtig sideindlæsning. Hver udgående forespørgsel til et domæne, du ikke kontrollerer, er en potentiel overførsel af personoplysninger, fordi en IP-adresse plus en user agent er personoplysninger.
• Tjek, hvad fejlsporeren fanger. Stakspor indeholder rutinemæssigt e-mailadresser, tokens og forespørgselsindhold.
• Tjek logopbevaringen. Adgangslogge med IP'er gemt for evigt er et af de mest almindelige fund og et af de nemmeste at rette.

Skriv det ned som en fortegnelse over behandlingsaktiviteter. Artikel 30 kræver det alligevel for de fleste organisationer, og den version, der er nyttig for udviklere, er en tabel med system, data, formål, behandlingsgrundlag, opbevaringstid og modtagere.

Vælg behandlingsgrundlag pr. formål, ikke pr. system

Artikel 6 giver seks behandlingsgrundlag. Den mest almindelige fejl er at vælge ét for hele produktet.

Du har næsten helt sikkert flere formål kørende samtidig. At opfylde en ordre er aftale. Svindelkontroller er som regel legitim interesse eller retlig forpligtelse. At gemme fakturaer i den lovpligtige periode er retlig forpligtelse. Marketingmail er samtykke i de fleste medlemsstater. Ikke-nødvendig analyse er samtykke på grund af ePrivacy-reglerne om adgang til terminaludstyr og ikke på grund af GDPR selv.

Den praktiske konsekvens er, at datamodellen skal vide, hvilket formål hver post tjener. Kan du ikke adskille marketingprofilen fra ordreposten, kan du ikke efterkomme en marketingindsigelse uden at ødelægge ordrehistorikken. Den adskillelse er en skemabeslutning, og den er smertefuld at eftermontere.

Samtykke skal være ægte, og det skal logges

Bygger du på samtykke, skal det være frivilligt, specifikt, informeret og utvetydigt, og du skal kunne dokumentere det senere.

Konkret:

• Intet ikke-nødvendigt udløses, før brugeren handler. Det omfatter analysescriptet, annoncepixlen, chatwidgetten, fonten fra et tredjeparts-CDN og A/B-testscriptet.
• At afvise skal være lige så let som at acceptere. Samme lag, samme synlighed, samme antal klik. Tilsynsmyndigheder behandler alt andet som et mørkt mønster, og de har været konsekvente på det.
• Samtykke er pr. formål. Én kontakt, der dækker «analyse og marketing og personalisering», er ikke specifikt.
• Tilbagetrækning er lige så let som at give. Et permanent link eller en flydende knap, ikke en e-mail til support.
• Gem beviset: tidsstempel, samtykkestrengen eller status pr. kategori, bannerversionen og teksten, brugeren fik vist. Uden versionen kan du ikke forsvare et to år gammelt samtykke.

Håndhævelsen her er ikke teoretisk. I september 2025 gav den franske tilsynsmyndighed Google en bøde på 325 millioner euro og Shein 150 millioner samme dag for cookiepraksis. Begge sager handlede om mekanik snarere end policytekst: cookies sat før nogen interaktion, og afvisningsknapper der ikke faktisk afviste.

Reglerne er også i bevægelse. Digital Omnibus-forslaget ville flytte samtykke til terminaludstyr ind i selve GDPR og gøre browsersignaler bindende. Hvad det ville ændre, dækkede vi i cookiesamtykke efter Digital Omnibus.

Byg maskineriet til de registreredes rettigheder tidligt

Artikel 15 til 22 giver folk ret til indsigt, berigtigelse, sletning, begrænsning, dataportabilitet og indsigelse. Du har én måned til at svare, forlængeligt til tre i komplekse sager.

Teams håndterer gerne de første anmodninger manuelt, hvilket fungerer, lige indtil det ikke gør. Hvad du vil have på plads i god tid før mængden kommer:

En resolver, der finder en person på tværs af systemer. Givet en e-mailadresse, returnér alt: kontoen, ordrerne, supportsagerne, marketingprofilen, analyse-ID'et, loggene. Skal et menneske huske, at der findes en tredjeparts anmeldelsesplatform med data, glemmer nogen det til sidst.

En slettesti, der respekterer opbevaringspligter. Sletning er ikke absolut. Fakturaer skal gerne overleve af skattemæssige grunde. Det, du har brug for, er blød sletning med formålsbundet hård sletning, så du kan fjerne marketingprofilen og beholde bogføringsposten, og så den post selv udløber til tiden.

En portabel eksport. Struktureret, almindeligt anvendt, maskinlæsbar. JSON er fint. En PDF af en gengivet HTML-side er det ikke.

Et indsigelsesflag hele systemet læser. Indsigelse mod profilering skal faktisk stoppe profileringen, også i batchjobbet, der kører klokken tre om natten og ikke tjekker flaget.

Opbevaringstid er et job, ikke en linje i en politik

Opbevaringsbegrænsning er det princip, ellers velbyggede systemer oftest overtræder, fordi sletning kræver, at nogen skriver og planlægger et job, ingen beder om.

Giv hver datakategori en defineret levetid, og implementér den. Adgangslogge, sessioner, forladte kurve, ubekræftede tilmeldinger, lukkede sager, gamle backups og rå analysedata skal alle have en udløbsdato. Backups fortjener særlig opmærksomhed: genopliver gendannelsesprocessen slettede personoplysninger, er sletningen ufuldstændig, og det sædvanlige svar er dokumenteret rotation med maksimal alder plus ny anvendelse af sletninger efter enhver gendannelse.

Overførsler, underdatabehandlere og hvor stakken faktisk kører

Overførsler uden for EØS kræver en retlig mekanisme, som regel EU-USA-databeskyttelsesrammen for certificerede amerikanske modtagere eller standardkontraktbestemmelser plus en overførselsvurdering i øvrigt.

Ingeniørvinklen er enklere end den juridiske: vid hvor dine data fysisk er. Det betyder cloudregionen for hver tjeneste, placeringen af dine backups, regionen for din administrerede database, CDN'ets edge-konfiguration og, vigtigt, supportmodellen for hvert SaaS-værktøj, du bruger. En leverandør hostet i Frankfurt, hvis supportteam tilgår produktion fra uden for EØS, er stadig en overførsel.

Vi anbefaler som regel at holde personoplysninger i EU-regioner, når der ikke er stærke grunde til andet. Det fjerner en hel kategori af diskussion, og omkostningsforskellen er som regel støj.

Hold en liste over underdatabehandlere og hold den opdateret. Artikel 28 kræver en skriftlig aftale med hver enkelt, og listen er også det, dine kunder vil bede om i due diligence.

Sikkerhed som standard, udtrykt som konfiguration

Artikel 32 kræver passende tekniske og organisatoriske foranstaltninger. Det er bevidst vagt, men grundlinjen for et website i 2026 er ikke til forhandling:

• TLS overalt, HSTS slået til, intet blandet indhold.
• Adgangskoder hashet med en moderne hukommelsestung funktion, og multifaktorgodkendelse tilgængelig for konti med personoplysninger.
• Kryptering i hvile for databaser og backups.
• Adgang til personoplysninger i produktion begrænset efter rolle og logget, med gennemgange der faktisk finder sted.
• Pseudonymisering hvor det er muligt: hash identifikatoren i analysen, hold sammenkædningstabellen adskilt og med begrænset adgang.
• En testet gendannelse, ikke bare en backup.

Databeskyttelse gennem design og standardindstillinger i artikel 25 betyder, at den mest beskyttende mulighed er den, du får uden at gøre noget. Nyhedsbrevsfelt ikke afkrydset. Profilsynlighed privat. Valgfrie felter valgfrie.

Bruddindberetning kræver en drejebog

Toogfjerds timer fra kendskab til underretning af tilsynsmyndigheden er ikke længe, især ikke hvis bruddet opdages en fredag aften. Bemærk at Digital Omnibus-forslaget ville flytte det til seksoghalvfems timer, men det er endnu ikke gældende ret.

Forbered på forhånd: hvem erklærer en hændelse, hvem vurderer om personoplysninger er berørt, hvem kontakter tilsynet, hvad underretningen indeholder, og hvordan I informerer berørte, hvis risikoen er høj. Skriv det som en drejebog med navngivne roller, og øv én gang. Første brug bør ikke være første gennemlæsning.

Selve websitefladen

Dele af GDPR er synlige på siden, og det betaler sig at få disse detaljer rigtige, for det er dem, folk anmelder.

Din privatlivspolitik skal angive den dataansvarliges identitet og kontakt, formålene og behandlingsgrundlagene, modtagere og modtagerkategorier, overførselsmekanismer, opbevaringstider, den fulde liste over rettigheder inklusive retten til at klage til en tilsynsmyndighed, og om der findes automatiserede afgørelser. Skriv i et sprog, et almindeligt menneske kan følge. Lagdelte politikker, med en kort version der linker til detaljer, fungerer bedre end en tekstmur.

Formularer bør kun indsamle det nødvendige. Hvert felt er en begrundelse, du måske skal give. Ligger marketingsamtykkefeltet i samme indsendelse som ordren, skal det være separat afkrydset og separat formuleret.

Tredjepartsindlejringer er den stille fejl. YouTube i privatlivsforbedret tilstand, kort bag en klik-for-at-indlæse-pladsholder, fonte selvhostet i stedet for hentet fra et tredjeparts-CDN. Hver af disse ændringer er lille og fjerner ét fund.

Hvad vi oftest ser gå galt

Efter nok revisioner dukker den samme korte liste op:

1. Analyse der indlæses før samtykke, som regel fordi en tag manager blev sat op af marketing og aldrig gennemgået af udvikling.
2. Afvisningsknapper der alligevel udløser samtykke på grund af standardadfærden i et tredjepartsscript.
3. Slet ingen opbevaringsjobs, på nogen tabel.
4. Sletning der glemmer backups, logge og CRM.
5. En privatlivspolitik der beskriver et dataflow, som blev ændret for atten måneder siden.
6. Lister over underdatabehandlere der stopper ved de tre åbenlyse leverandører.
7. Samtykkelogs uden versionen af den viste tekst.

Ingen af disse er svære problemer. Det er blot arbejde, ingen har fået tildelt.

At få hjælp

Vil du have et ekstra par øjne på et eksisterende website, laver vi tekniske GDPR-revisioner, der giver en prioriteret opgaveliste i stedet for en rapport: hvad der skal rettes, i hvilken rækkefølge, med et estimat på hvert punkt. Bygger du noget nyt, er det væsentligt billigere at få datamodellen og samtykkearkitekturen rigtig fra start.

Vi dækker også den bredere EU-complianceflade, inklusive tilgængelighed og markedsindtræden i Europa. Du når os på office@c9group.dev.

Vi bygger software. Vi giver ikke juridisk rådgivning, og fortolkningen af et konkret krav hører til hos jeres jurister. Det, vi kan gøre, er at sikre, at systemet gør det, jeres jurister siger, det skal gøre.