Databeskyttelse gennem design (art. 25 GDPR): privacy by design 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.

Foranstaltningerne bør dokumenteres, så du kan påvise, hvordan artikel 25 er efterlevet for hver behandling. Certificering efter artikel 42 kan bruges som et element til at demonstrere overholdelse. En platform som Legiscope kan knytte design-foranstaltningerne til de enkelte behandlinger i fortegnelsen, så dokumentationen samles ét sted.

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.