Praktisk guide til implementering af danske GDPR-krav i web- og appudvikling - med kodeeksempler, et casestudie om cookieless analytics og en compliance-tjekliste, du kan bruge på dit næste projekt.
Juridisk forbehold: Denne artikel giver generel teknisk vejledning til udviklere. Den er ikke juridisk rådgivning. Har du konkrete compliance-spørgsmål, bør du kontakte en advokat med speciale i databeskyttelse. Indholdet afspejler vores forståelse pr. 2025 og kan blive påvirket af fremtidige regelændringer eller ny vejledning fra Datatilsynet.
GDPR i Danmark: Hvad udviklere faktisk skal vide
De fleste GDPR-guides til udviklere er skrevet til et generisk EU-publikum og fokuserer på teoretiske principper. Denne guide er anderledes. Den er skrevet specifikt til udviklere, der bygger webapplikationer og mobilapps til danske virksomheder eller danske brugere, og den fokuserer på praktisk implementering - hvad du konkret skal bygge, og hvordan du bygger det.
I Danmark håndhæves GDPR gennem databeskyttelsesloven og Datatilsynet. Selvom GDPR’s kerneregler er de samme i hele EU, har Danmark særlige fortolkninger og supplerende krav, der påvirker, hvordan du implementerer databeskyttelse i dine applikationer.
Særlige danske forhold:
- Datatilsynet er aktivt: Det danske datatilsyn er en af de mere proaktive tilsynsmyndigheder i EU. De udgiver konkret vejledning og undersøger aktivt klager
- Beskyttelse af CPR-numre: Danske CPR-numre behandles som følsomme personoplysninger efter databeskyttelsesloven og er underlagt yderligere begrænsninger
- Cookie- og samtykkeregler: Cookiebekendtgørelsen implementerer ePrivacy-direktivet med specifikke krav til samtykke
- Overlap med bogføringsloven: Bogføringsloven kræver 5 års opbevaring af regnskabsmateriale, hvilket kan støde sammen med GDPR’s princip om dataminimering - du skal kunne navigere i begge regelsæt
De juridiske rammer: GDPR + databeskyttelsesloven
Som udvikler skal du kende tre overlappende regelsæt, der styrer databeskyttelse i danske webapplikationer:
GDPR (EU-forordning 2016/679)
Kerneforordningen. Gælder direkte i Danmark uden national implementering. Fastlægger principperne om lovlig behandling, dataminimering, formålsbegrænsning og de registreredes rettigheder. Bøder på op til 4 % af den globale årsomsætning eller 20 mio. euro.
Databeskyttelsesloven
Supplerer GDPR med danske særregler. Vigtigste tilføjelser: særlige regler for CPR-numre (§ 11), regler om behandling til journalistiske og forskningsmæssige formål (§§ 8-10) og det retlige grundlag for Datatilsynet som tilsynsmyndighed. Fastsætter desuden aldersgrænsen for digitalt samtykke til 13 år (GDPR lader medlemsstaterne vælge mellem 13 og 16 år).
ePrivacy-direktivet (cookiereglerne)
Implementeret i Danmark gennem cookiebekendtgørelsen (bekendtgørelse om krav til information og samtykke ved lagring af eller adgang til oplysninger i slutbrugeres terminaludstyr). Kræver informeret samtykke, før der placeres ikke-nødvendige cookies eller bruges lignende sporingsteknologier. Det er denne lov, der kræver cookie-samtykkebannere.
For udviklere er den praktiske konsekvens: Du skal tænke databeskyttelse på tre niveauer. Hvilke personoplysninger indsamler du (GDPR)? Gælder der danske særregler for netop den type oplysninger (databeskyttelsesloven)? Og bruger du cookies eller device fingerprinting til at spore brugere (ePrivacy/cookiereglerne)?
Behandlingsgrundlag: En praktisk gennemgang
Enhver personoplysning, du behandler, kræver et behandlingsgrundlag. Det er ikke bureaukrati - det er fundamentet for din dataarkitektur. Behandlingsgrundlaget afgør, hvilke samtykkeflows du skal bygge, hvor længe du må gemme data, og hvilke rettigheder brugerne har over dem. Vælger du det forkerte grundlag, risikerer hele din datapipeline at være i strid med reglerne.
Samtykke
Brugeren accepterer udtrykkeligt databehandlingen
- Hvornår bruges det: Marketingmails, analytics-cookies, tredjepartssporing
- Udviklerens opgave: Implementér samtykkebanner, gem samtykkeregistreringer, respektér tilbagetrækning
Kontrakt
Behandling, der er nødvendig for at opfylde en aftale
- Hvornår bruges det: Levering af en købt ydelse, betalingsbehandling, kontoadministration
- Udviklerens opgave: Intet samtykkebanner nødvendigt, men informér brugerne i privatlivspolitikken
Legitim interesse
Behandling, der er nødvendig af hensyn til legitime forretningsformål
- Hvornår bruges det: Svindelforebyggelse, sikkerhedslogning, grundlæggende analytics uden sporing
- Udviklerens opgave: Dokumentér interesseafvejningen, og tilbyd mulighed for at framelde sig
Retlig forpligtelse
Behandling, der er påkrævet ved lov
- Hvornår bruges det: Skatteoplysninger, regnskabsmateriale (bogføringsloven), hvidvaskkontrol
- Udviklerens opgave: Opbevar de påkrævede data i de lovbestemte perioder - også selvom brugeren beder om sletning
En klassisk udviklerfejl
Mange udviklere vælger pr. automatik “samtykke” som behandlingsgrundlag for alt. Det er forkert og skaber faktisk flere problemer. Bruger du samtykke som grundlag, kan brugerne til enhver tid trække det tilbage, og så skal du straks stoppe behandlingen og potentielt slette alle data. For kernefunktionalitet (kontoadministration, betalingsbehandling, levering af ydelsen) er “kontrakt” som regel det rigtige grundlag. Gem “samtykke” til valgfrie funktioner som marketing og tredjeparts-analytics.
Samtykkemønstre, der faktisk fungerer
Når samtykke er det rette behandlingsgrundlag, sætter GDPR (og Datatilsynets vejledning) barren højt for, hvad der tæller som gyldigt samtykke. Det skal være frivilligt, specifikt, informeret og utvetydigt. Her er, hvad det betyder i praksis:
Mønster: Granulært cookie-samtykke
Brug ikke en enkelt “acceptér alle”-knap. Datatilsynet forventer, at brugerne kan give samtykke til de enkelte kategorier hver for sig. Adskil som minimum: strengt nødvendige (kræver ikke samtykke), funktionelle, statistiske og marketing-cookies.
// Datastruktur for cookie-samtykke
interface CookieConsent {
necessary: true // Altid true, ingen toggle
functional: boolean // Sprogvalg, UI-indstillinger
analytics: boolean // Brugsstatistik, heatmaps
marketing: boolean // Annoncemålretning, pixels fra sociale medier
consentDate: string // ISO-dato for samtykket
consentVersion: string // Version af privatlivspolitikken
}
// Gem samtykket på serveren (ikke kun i en cookie)
async function saveConsent(consent: CookieConsent) {
await db.consentRecord.create({
data: {
...consent,
ipHash: hashIP(request.ip), // Hash - gem aldrig rå IP
userAgent: request.headers['user-agent'],
timestamp: new Date().toISOString()
}
})
}
Mønster: Opbevaring af samtykkeregistreringer
GDPR kræver, at du kan bevise, at samtykket blev givet (ansvarlighedsprincippet). Gem samtykkeregistreringer på serveren med nok detaljer til at dokumentere: hvem der gav samtykke, hvornår, til hvad, og hvilken information de fik vist. Opbevar registreringerne i mindst 2 år, efter at samtykket er udløbet eller trukket tilbage.
Datatilsynet kan kræve dokumentation for samtykke i forbindelse med en undersøgelse
Anti-mønster: Dark patterns
Datatilsynet og Det Europæiske Databeskyttelsesråd har udtrykkeligt advaret mod dark patterns i samtykkeflows. Undgå:
- At gøre “Acceptér alle” visuelt fremtrædende, mens “Afvis alle” eller “Administrér indstillinger” gemmes væk
- Forudafkrydsede samtykkefelter (samtykke kræver en aktiv handling)
- At det kræver flere klik at afvise end at acceptere
- Cookie-walls, der blokerer indholdet, indtil der gives samtykke (medmindre det er reelt nødvendigt)
Casestudie: Cookieless analytics - og hvor samtykkegrænsen faktisk går
Hos TwinCurrent har vi bygget vores eget privacy-first analytics-system (tw.js). Det sætter ingen cookies og bygger ingen profil på tværs af sites, men det er ikke uden lagring: det gemmer et roterende session-id i sessionStorage og en kort kø i localStorage, så events ikke går tabt på en ustabil forbindelse. Den forskel har juridisk betydning, og den er værd at gennemgå ærligt frem for at påstå mere, end koden gør.
Cookieless er ikke det samme som samtykkefri
ePrivacy-direktivet (og den danske cookiebekendtgørelse) kræver samtykke ved “lagring af eller adgang til oplysninger i slutbrugerens terminaludstyr”. Læg mærke til, hvad det dækker: det er ikke en regel om cookies, men om overhovedet at skrive til enheden. localStorage og sessionStorage tæller med. At droppe cookies fjerner altså ikke samtykkespørgsmålet, det fjerner kun én mekanisme. En tracker, der gemmer et session-id i sessionStorage, skriver stadig til terminaludstyret, og medmindre det er strengt nødvendigt for en tjeneste, brugeren selv har bedt om, kræver det samtykke. Vær ærlig om, hvilken side af den grænse jeres eget værktøj ligger på, og sæt en samtykkeløsning foran. Det separate spørgsmål om GDPR-compliance for behandlingen på serversiden kan ofte håndteres under legitim interesse.
Sådan fungerer tw.js
Vores tracker udleder et session-id fra grove browserkarakteristika i stedet for en cookie. Dette id ligger i sessionStorage, så ét besøg ikke tælles mange gange - det er en skrivning til enheden, og derfor behandler vi det som samtykkepligtigt frem for undtaget:
// Forenklet fingerprint-generering (klientside)
// Ingen cookies. Det udledte id ligger i sessionStorage under besøget,
// og fejlede events køer i localStorage, indtil de kan sendes igen.
function generateSessionId() {
const components = [
navigator.language,
screen.width + 'x' + screen.height,
new Date().toDateString(), // Roterer dagligt
// Yderligere entropi fra browserens features
]
// Hash af komponenterne - envejs, kan ikke føres tilbage
return hashComponents(components)
}
// Serverside: kun fingerprint-hashen gemmes,
// aldrig de rå komponenter
// IP-adresser gemmes IKKE - de bruges kun til
// geo-opslag og kasseres derefter
Privacy by design-principperne i praksis
- Intet gemmes på enheden Ingen cookies og ingen vedvarende identifikator. Der skrives to nøgler: et roterende session-id i sessionStorage, som forsvinder, når fanen lukkes, og en kortlivet kø i localStorage til events, der ikke kunne sendes. Begge dele er skrivninger til enheden under ePrivacy og hører derfor hjemme bag samtykke, ikke under en undtagelse
- Ingen sporing på tværs af sites Sessions-ID’er roterer dagligt og er unikke pr. site. En bruger kan ikke spores på tværs af forskellige hjemmesider
- Håndtering af IP-adresser IP-adresser bruges kun til geografisk opslag (lande-/regionsniveau) og kasseres straks derefter. De gemmes aldrig i databasen
- Dataminimering Der gemmes kun aggregerede tal: sidevisninger, sessioner, referrers og browsertyper. Der oprettes ingen individuelle brugerprofiler
- Self-hosted Alle data bliver på vores egne servere. Ingen tredjeparts-databehandlere indgår i analytics-pipelinen, så der kræves ingen databehandleraftaler for analytics
Behandlingsgrundlag: Legitim interesse
For behandlingen af anonyme analysedata på serversiden støtter vi os på legitim interesse (GDPR artikel 6, stk. 1, litra f). Interesseafvejningen:
- Formål: At forstå brugen af hjemmesiden for at forbedre den (sideydelse, populært indhold, fejlsporing)
- Nødvendighed: Grundlæggende analytics er nødvendige for at drive en hjemmeside effektivt. Formålet kan ikke opnås med færre data
- Afvejning: Minimal påvirkning af brugerne (intet gemmes på enheden, ingen sporing, ingen profilering). Brugernes interesser tilsidesættes ikke
Denne tilgang bruges på alle TwinCurrents egne sites og kundesites. Den giver os de analysedata, vi har brug for (sidevisninger, sessioner, referrers, Core Web Vitals, fejlsporing), uden at der kræves et samtykkebanner for analytics. Resultatet: en renere brugeroplevelse og fuld GDPR-compliance.
Krav til opbevaring og sletning af data
GDPR’s princip om dataminimering siger, at du ikke må gemme personoplysninger længere end nødvendigt. Men dansk lovgivning stiller samtidig krav om minimumsopbevaring af visse datatyper, især regnskabsmateriale. At navigere i de overlappende krav er noget af det sværeste i dansk databeskyttelses-compliance.
| Datatype | Opbevaringsperiode | Retsgrundlag | Bemærkninger |
|---|---|---|---|
| Regnskabsmateriale / bogføring | 5 år | Bogføringsloven | Lovpligtig opbevaring - må ikke slettes, selv hvis brugeren beder om det |
| Skatterelaterede dokumenter | 5 år | Skattelovgivningen | Omfatter fakturaer, udgiftsbilag og momsregnskab |
| Personaleoplysninger | 5 år efter ansættelsens ophør | Diverse danske ansættelseslove | Lønoplysninger, kontrakter, indeholdt A-skat |
| Brugerkontodata | Aftaleperioden + 30 dage | Kontrakt / legitim interesse | Slet efter karensperioden ved kontolukning |
| Serverlogs (med IP) | Maks. 90 dage | Legitim interesse (sikkerhed) | Anonymisér eller slet, når sikkerhedsvinduet er udløbet |
| Registreringer af marketing-samtykke | Samtykkeperioden + 2 år | Ansvarlighedsprincippet | Gem dokumentation for, at samtykket blev givet |
| Analysedata (med personoplysninger) | 26 måneder | Legitim interesse / samtykke | Anonymisér efter opbevaringsperioden |
Implementering: Automatiseret datalivscyklus
Stol ikke på manuel sletning. Implementér automatiseret styring af datalivscyklussen:
// Eksempel: Automatiseret håndhævelse af opbevaringsregler
// Køres som et dagligt cron-job
async function enforceDataRetention() {
const now = new Date()
// Slet serverlogs, der er ældre end 90 dage
await db.serverLog.deleteMany({
where: {
createdAt: { lt: subDays(now, 90) }
}
})
// Anonymisér analysedata, der er ældre end 26 måneder
await db.analyticsEvent.updateMany({
where: {
createdAt: { lt: subMonths(now, 26) },
anonymized: false
},
data: {
sessionId: 'anonymized',
fingerprint: 'anonymized',
anonymized: true
}
})
// Slet inaktive brugerkonti efter 30 dages karens
await db.user.deleteMany({
where: {
deletionRequestedAt: { lt: subDays(now, 30) },
status: 'pending_deletion'
}
})
// NB: Regnskabsmateriale slettes ALDRIG automatisk
// Det skal opbevares i 5 år efter dansk lov
}
Konflikten med bogføringsloven
Når en bruger udøver sin ret til sletning (GDPR artikel 17), skal du efterkomme det - undtagen for data, du er retligt forpligtet til at opbevare. Regnskabsmateriale knyttet til brugeren (fakturaer, betalingsoplysninger, udgiftsdata) skal opbevares i 5 år efter bogføringsloven. Løsningen: Slet brugerens konto og personoplysninger, men behold regnskabsmaterialet i anonymiseret form (erstat navnet med et referencenummer, og behold beløb og datoer).
Implementering af de registreredes rettigheder
GDPR giver den enkelte konkrete rettigheder over sine data. Som udvikler skal du bygge de tekniske mekanismer, der gør rettighederne mulige at udøve. Datatilsynet forventer, at du svarer på anmodninger inden for 30 dage. Her er de vigtigste rettigheder, og hvordan du implementerer dem:
Retten til indsigt (artikel 15)
Brugere kan anmode om en kopi af alle de personoplysninger, du har om dem. Byg en eksportfunktion, der samler alle brugerens data i et læsbart format (JSON eller PDF).
Implementering: Eksport-endpoint, der henter data fra alle tabeller med personoplysninger
Retten til sletning (artikel 17)
Brugere kan anmode om at få deres data slettet. Skal efterkommes, medmindre der gælder lovpligtige opbevaringskrav. Implementér som soft delete (markér til sletning) med en karensperiode og derefter endelig sletning efter 30 dage. Behold lovpligtige registreringer i anonymiseret form.
Implementering: Soft delete + 30 dages karens + automatiseret endelig sletning via cron
Retten til dataportabilitet (artikel 20)
Brugere kan anmode om deres data i et maskinlæsbart format (JSON, CSV). Retten overlapper med indsigtsretten, men kræver specifikt et struktureret, almindeligt anvendt og maskinlæsbart format.
Implementering: JSON-/CSV-eksport af brugerens egne data (ikke afledt analytics)
Retten til berigtigelse (artikel 16)
Brugere kan få rettet forkerte oplysninger. I de fleste webapplikationer håndteres det med profilredigering. Sørg for, at rettelser slår igennem i alle systemer, hvor data er replikeret (søgeindekser, caches, backups).
Implementering: Profilredigering + cache-invalidering + politik for opdatering af backups
Compliance-tjekliste for udviklere
Brug denne tjekliste, når du bygger eller auditerer en webapplikation til det danske marked. Den dækker de mest almindelige compliance-krav, vi møder i vores arbejde hos TwinCurrent.
Dataindsamling og -opbevaring
- Dokumentér alle typer personoplysninger, der indsamles, og behandlingsgrundlaget for hver af dem
- Fastlæg opbevaringsperioder for hver datatype, og implementér automatiseret sletning
- Kryptér personoplysninger både i hvile (databasekryptering) og under transport (TLS)
- Hash eller anonymisér data, hvor der ikke er brug for fulde personoplysninger (analytics, logs)
- Hvis du gemmer CPR-numre: Implementér ekstra adgangskontrol efter databeskyttelseslovens § 11
Samtykke og cookie-compliance
- Implementér granulært cookie-samtykke med separate kategorier (nødvendige, funktionelle, statistiske, marketing)
- Indlæs ingen ikke-nødvendige sporingsscripts, før samtykket er givet
- Gør det lige så let at afvise cookies som at acceptere dem
- Gem samtykkeregistreringer på serveren med tidsstempler og samtykkeversion
- Overvej cookieless analytics, så samtykkekravet for basal trafikmåling helt bortfalder
Implementering af brugerrettigheder
- Byg en dataeksportfunktion (JSON/CSV) til indsigts- og portabilitetsanmodninger
- Implementér kontosletning med passende karensperioder
- Sørg for, at profilrettelser slår igennem i alle datalagre
- Etablér en proces, så anmodninger fra registrerede besvares inden for 30 dage
Dokumentation og ansvarlighed
- Vedligehold en fortegnelse over behandlingsaktiviteter (ROPA) - påkrævet, hvis virksomheden har over 250 ansatte eller behandler følsomme oplysninger
- Offentliggør en klar og letforståelig privatlivspolitik på dansk (eller brugerens sprog)
- Bruger du tredjeparts-databehandlere: Indgå databehandleraftaler (DPA) efter GDPR artikel 28
- Dokumentér interesseafvejninger for al behandling baseret på legitim interesse
- Implementér procedurer for brud på persondatasikkerheden (72 timer til Datatilsynet, uden unødig forsinkelse til de berørte personer)
Databeskyttelses-compliance er ikke en engangsopgave. Det er en løbende praksis, der skal vedligeholdes, i takt med at din applikation udvikler sig, nye funktioner kommer til, og reglerne opdateres. Byg disse tjek ind i din udviklingsproces - ikke som noget, der kommer til sidst, men som et krav på linje med sikkerhed, test og performance.
Bygger I til det danske marked?
Vi tænker databeskyttelse ind fra starten: dataminimering, EU-hosting og sletning er en del af arkitekturen, ikke noget, der bliver skruet på til sidst. Om et system overholder reglerne, afhænger også af, hvordan det bruges, så vi dokumenterer valgene og overlader den juridiske vurdering til jer og jeres rådgivere.
