Gå til indhold
Legiscope
Menu
Databeskyttelse

Databeskyttelse gennem design (art. 25 GDPR): privacy by design i 2026

Databeskyttelse gennem design og standardindstillinger efter art. 25 GDPR: hvad kravet betyder, de syv principper og konkrete tiltag du kan indføre i 2026.

Databeskyttelse gennem design og standardindstillinger betyder, at du skal indbygge beskyttelse af personoplysninger i systemer og processer fra begyndelsen — ikke bagefter — og at de mest privatlivsvenlige indstillinger skal være aktiveret som standard. Kravet følger af artikel 25 i databeskyttelsesforordningen (GDPR) og består af to dele: “privacy by design” (stk. 1), hvor du gennemfører passende tekniske og organisatoriske foranstaltninger allerede ved fastlæggelsen af midlerne til behandlingen, og “privacy by default” (stk. 2), hvor kun de oplysninger, der er nødvendige til det konkrete formål, som udgangspunkt behandles. Det er en pligt for den dataansvarlige og en forudsætning for at kunne dokumentere ansvarlighed.

Denne guide gennemgår, hvad de to dele af artikel 25 kræver, de syv grundprincipper bag idéen, og konkrete tekniske og organisatoriske tiltag, du kan indføre.

De to dele af artikel 25

Databeskyttelse gennem design (stk. 1)

Du skal — både ved fastlæggelsen af midlerne til behandlingen og under selve behandlingen — gennemføre passende foranstaltninger, der er designet til at implementere databeskyttelsesprincipperne effektivt. Artikel 25, stk. 1, nævner udtrykkeligt pseudonymisering og dataminimering som eksempler. Vurderingen tager hensyn til det aktuelle tekniske niveau, omkostningerne, behandlingens karakter og risiciene for de registrerede.

Pointen er, at beskyttelsen skal tænkes ind, inden systemet bygges. Det er langt billigere og mere effektivt at designe et system, der kun indsamler det nødvendige, end at forsøge at reparere et system, der indsamler for meget. Netop derfor hænger artikel 25 tæt sammen med konsekvensanalysen: analysen er ofte det redskab, der oversætter design-kravet til konkrete foranstaltninger.

Databeskyttelse gennem standardindstillinger (stk. 2)

Standardindstillingerne skal sikre, at der som udgangspunkt kun behandles de oplysninger, der er nødvendige til hvert konkret formål. Det gælder mængden af oplysninger, omfanget af behandlingen, opbevaringsperioden og tilgængeligheden. Et konkret eksempel: en ny brugerprofil bør som standard ikke være offentligt synlig, og markedsføringssamtykke bør som standard ikke være afgivet — det kræver et aktivt tilvalg, jf. reglerne om samtykke.

De syv grundprincipper bag privacy by design

Idéen om privacy by design bygger på syv velkendte principper, som er nyttige som tjekliste, selv om de ikke står ordret i forordningen:

  1. Proaktiv, ikke reaktiv — forebyg problemer, i stedet for at reagere på dem.
  2. Privatliv som standardindstilling — den registrerede skal ikke gøre noget for at blive beskyttet.
  3. Privatliv indbygget i designet — ikke en tilføjelse bagefter.
  4. Fuld funktionalitet — privatliv og funktionalitet på samme tid, ikke et enten-eller.
  5. Sikkerhed i hele livscyklussen — fra indsamling til sletning.
  6. Synlighed og gennemsigtighed — over for de registrerede og myndighederne.
  7. Respekt for brugerens privatliv — brugercentreret design.

Konkrete tiltag du kan indføre

Artikel 25 bliver først operationel, når principperne omsættes til konkrete foranstaltninger. Eksempler:

  • Dataminimering i formularer — spørg kun om det nødvendige. Fjern felter, der “kunne være rare at have”.
  • Pseudonymisering og kryptering — adskil identifikatorer fra oplysninger, og krypter i hvile og under transport.
  • Adgangsstyring efter behov — kun de medarbejdere, der har brug for oplysningerne, skal have adgang.
  • Automatiske slettefrister — indbyg opbevaringsbegrænsning teknisk, så oplysninger slettes automatisk, når fristen udløber.
  • Privatlivsvenlige standardindstillinger — profiler, deling og markedsføring slået fra som udgangspunkt.
  • Indbygget håndtering af rettigheder — gør det muligt at eksportere data (dataportabilitet) og besvare indsigt uden manuelle omveje.

Praktiske eksempler efter behandlingstype

Artikel 25 bliver konkret, når man ser den anvendt på en bestemt behandling. Her er tre gennemgående eksempler:

Webshop. Ved oprettelse af en konto bør formularen kun bede om de oplysninger, der er nødvendige for at gennemføre købet — ikke fødselsdato eller køn “til statistik”. Markedsføringssamtykke er som standard fravalgt (et tomt felt), betalingsoplysninger håndteres af en PCI-DSS-certificeret udbyder, og ordrehistorik slettes automatisk efter den fastsatte slettefrist. Kundens konto er ikke offentligt synlig som standard.

HR-system. Adgang til medarbejderoplysninger begrænses efter behov: en teamleder ser sit eget team, ikke hele organisationen. Følsomme oplysninger (fx helbred i forbindelse med sygefravær) adskilles fra almindelige personaleoplysninger og krypteres. Ansøgninger fra afviste kandidater slettes automatisk efter den fastsatte frist. Systemet gør det muligt at eksportere en medarbejders oplysninger, så en indsigtsanmodning kan besvares uden manuelle omveje.

Mobilapp. Lokationsdata indsamles kun, når funktionen aktivt bruges — ikke i baggrunden som standard. Der spørges om tilladelse på det tidspunkt, hvor funktionen bruges, ikke som et generelt tilvalg ved installation. Analysedata pseudonymiseres, og brugeren kan slette sin konto og data direkte i appen.

Design, standard og dokumentation hænger sammen

De tre elementer forstærker hinanden. Et godt design (stk. 1) gør det let at levere privatlivsvenlige standardindstillinger (stk. 2), og begge dele bliver kun retssikre, hvis du kan dokumentere dem. Dokumentationen er en del af ansvarlighedsprincippet (art. 5, stk. 2): du skal kunne påvise, hvilke foranstaltninger der er valgt for hver behandling, og hvorfor. Knyt derfor design-beslutningerne til de enkelte behandlinger i din fortegnelse over behandlingsaktiviteter, og lad databeskyttelsesrådgiveren rådgive om dem, inden systemet bygges. Ved højrisikobehandlinger er konsekvensanalysen det redskab, der systematisk oversætter kravet til konkrete foranstaltninger — og samtidig leverer dokumentationen.

Ansvar, dokumentation og retsgrundlag

Ansvaret for databeskyttelse gennem design ligger hos den dataansvarlige, men i praksis skal kravet formidles videre til dem, der faktisk bygger systemerne — interne udviklere og eksterne leverandører. Stil derfor krav i indkøb og udbud: en leverandør, der ikke kan redegøre for, hvordan produktet understøtter dataminimering, adgangsstyring og sletning, opfylder ikke dine behov efter artikel 25. Kravene bør afspejles i databehandleraftalen, så leverandøren forpligtes til at levere de nødvendige tekniske foranstaltninger.

Dokumentationen er afgørende: du skal kunne påvise, hvilke design-valg der er truffet for hver behandling, og hvorfor. Det retlige grundlag findes i artikel 25 i databeskyttelsesforordningen, og Datatilsynet har i sin praksis lagt vægt på, at databeskyttelse tænkes ind fra begyndelsen frem for at blive tilføjet bagefter. En certificering efter artikel 42 kan bruges som ét element til at demonstrere overholdelse.

Ofte stillede spørgsmål

Hvad er forskellen på “privacy by design” og “privacy by default”?

“Privacy by design” (art. 25, stk. 1) handler om at indbygge databeskyttelse i systemer og processer fra begyndelsen — fx pseudonymisering og dataminimering. “Privacy by default” (stk. 2) handler om, at de mest privatlivsvenlige indstillinger skal være aktiveret som standard, så der kun behandles de nødvendige oplysninger, uden at den registrerede skal gøre noget.

Gælder artikel 25 kun for it-systemer?

Nej. Artikel 25 gælder tekniske og organisatoriske foranstaltninger. Ud over it-tiltag som kryptering og adgangsstyring omfatter det organisatoriske foranstaltninger som interne politikker, uddannelse, roller og procedurer. Det handler om at indbygge databeskyttelse i hele måden, behandlingen tilrettelægges på.

Hvornår i et projekt skal jeg tænke databeskyttelse gennem design ind?

Så tidligt som muligt — allerede når midlerne til behandlingen fastlægges, dvs. i design- og indkøbsfasen. Det er både lovkravet i artikel 25 og det mest omkostningseffektive. Kombinér det med en konsekvensanalyse for højrisikobehandlinger, så risici identificeres, inden systemet bygges.

Konklusion

Databeskyttelse gennem design og standardindstillinger kræver, at du indbygger beskyttelse i systemer og processer fra start, og at de mest privatlivsvenlige indstillinger er standard. Brug de syv principper som tjekliste, og omsæt dem til konkrete tiltag: dataminimering, pseudonymisering, adgangsstyring, automatiske slettefrister og indbygget håndtering af de registreredes rettigheder. Tænk artikel 25 sammen med konsekvensanalysen og opbevaringsbegrænsning, og dokumentér foranstaltningerne i fortegnelsen — så kan du både beskytte de registrerede og påvise, at du gør det.

L
Skrevet af
Legiscope
Legiscope

Omsæt vejledningen til praksis

Se, hvordan Legiscope forbinder privatlivsregistre, kildemateriale og gennemgangsstyret arbejde.

Book en tilpasset demo
Læs videre

Relaterede artikler

01Databeskyttelse

AI Act-software 2026: værktøjer til AI-forordningen

AI Act-software hjælper danske virksomheder med at opfylde kravene i EU's AI-forordning (forordning (EU) 2024/1689): at kortlægge og klassificere AI-systemer efter risiko, dokumentere…

4. juli 2026
02Databeskyttelse

Anmeldelse af brud på persondatasikkerheden (art. 33-34 GDPR): 72 timer i 2026

Et brud på persondatasikkerheden skal anmeldes til Datatilsynet uden unødig forsinkelse og om muligt senest 72 timer efter, at den dataansvarlige er blevet bekendt med bruddet. Pligten følger af…

4. juli 2026
03Databeskyttelse

Bedste GDPR-software 2026: 6 værktøjer testet + priser

Vi har vurderet hver platform på syv kriterier, der betyder mest for danske virksomheder: automatisering af fortegnelsen efter artikel 30, gennemgang af databehandleraftaler efter artikel 28,…

4. juli 2026
04Databeskyttelse

Databehandleraftale (art. 28 GDPR): de 8 obligatoriske krav i 2026

En databehandleraftale er den skriftlige kontrakt, der skal indgås mellem en dataansvarlig og en databehandler, hver gang en ekstern part behandler personoplysninger på den dataansvarliges vegne.…

4. juli 2026
05Databeskyttelse

Databehandleraftale skabelon 2026: gratis art. 28-template klar til brug

Har du brug for en skabelon til en databehandleraftale efter artikel 28 i GDPR? Her er den — komplet og klar til at tilpasse. En databehandleraftale er obligatorisk, så snart en databehandler…

4. juli 2026
06Databeskyttelse

Databeskyttelse i Danmark 2026: den komplette GDPR-guide

Databeskyttelse i Danmark bygger på to lag: databeskyttelsesforordningen (GDPR), der gælder direkte i alle EU-lande, og den danske databeskyttelseslov, der fastsætter de nationale valg oven på…

4. juli 2026
07Databeskyttelse

Databeskyttelsesrådgiver (DPO): rolle og hvornår den er påkrævet i 2026

En databeskyttelsesrådgiver (DPO, Data Protection Officer) er en uafhængig funktion, der fører tilsyn med, at en organisation overholder databeskyttelsesreglerne. DPO'ens rolle er defineret i artikel…

4. juli 2026
08Databeskyttelse

Dataportabilitet (art. 20 GDPR): retten til at flytte sine data i 2026

Dataportabilitet giver den registrerede ret til at modtage de personoplysninger, vedkommende har givet dig, i et struktureret, almindeligt anvendt og maskinlæsbart format — og ret til at få…

4. juli 2026