Databeskyttelse gennem design og standardindstillinger betyder, at du skal indbygge beskyttelse af personoplysninger i systemer og processer fra begyndelsen — ikke bagefter — og at standardindstillinger skal begrænse behandlingen til det, der er nødvendigt for hvert konkret formål. 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, hvordan du omsætter kravet i konkrete beslutninger, 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. Tidlige valg om datafelter, adgang og opbevaring er ofte lettere at ændre før udrulning end efter, at oplysninger er spredt til flere systemer. 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.
Syv spørgsmål til projektets design
Følgende spørgsmål er en praktisk projektliste inspireret af privacy by design. De syv punkter er ikke selvstændige lovkrav i artikel 25:
- Hvilke oplysninger er nødvendige til hvert formål?
- Hvilke datafelter og delinger er aktive som standard?
- Hvem kan se oplysningerne, og hvordan begrænses adgangen?
- Hvornår skal oplysningerne slettes?
- Hvordan kan fejl, ændringer og uautoriseret adgang opdages?
- Hvordan får den registrerede forståelig information og udøvet sine rettigheder?
- Hvem revurderer valgene, når system og behandling ændres?
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 vurder passende kryptering i hvile og under transport efter risikoen.
- Adgangsstyring efter behov — kun de medarbejdere, der har brug for oplysningerne, skal have adgang.
- Automatiske slettefrister — indbyg opbevaringsbegrænsning teknisk, så opbevaring kan begrænses og sletning kan gennemføres efter den relevante frist.
- Privatlivsvenlige standardindstillinger — profiler, deling og markedsføring slået fra som udgangspunkt.
- Indbygget håndtering af rettigheder — gør det muligt at identificere oplysninger til rettighedsanmodninger hvor dataportabilitet gælder, og besvare indsigt på en sikker måde.
Foranstaltningerne bør dokumenteres, så du kan påvise, hvordan artikel 25 er efterlevet for hver behandling. En relevant certificeringsordning efter artikel 42 kan indgå som et element i vurderingen efter artikel 25, stk. 3, men er ikke i sig selv garanti for efterlevelse. Knyt beslutninger og foranstaltninger til de konkrete behandlinger i fortegnelsen.
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 gennem en vurderet betalingsløsning, og ordrehistorik håndteres 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 finde de relevante oplysninger, så en indsigtsanmodning kan vurderes og besvares sikkert.
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. Vurder om analysedata kan minimeres eller pseudonymiseres, og hvordan brugerens anmodning om kontolukning og sletning håndteres med de relevante undtagelser.
Ved en spørgeskemaundersøgelse skal designet også omfatte invitationslinks, skjulte identifikatorer og eksporten af besvarelser. Det hjælper ikke at fjerne navnefeltet, hvis svarene stadig kan kobles tilbage via platformen.
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. Hvis behandlingen sandsynligvis indebærer en høj risiko, skal en konsekvensanalyse foretages før behandlingen efter artikel 35. En sådan analyse kan underbygge designvalgene, men artikel 25 gælder også behandlinger uden DPIA-pligt.
Eksempel: et formularfelt, der virker uskyldigt
En serviceafdeling vil tilføje fødselsdato til en kontaktformular for lettere at skelne mellem personer med samme navn. Før feltet indføres, bør den dataansvarlige undersøge, om et sagsnummer eller en mindre indgribende kontrol kan løse det samme problem. Hvis fødselsdato er nødvendig i en bestemt type sag, kan formularen spørge efter den først i den situation, i stedet for hos alle. Standardindstillingen følger dermed det konkrete formål.
Vurder også hvor feltet ender: e-mailnotifikationer, CRM, eksportfiler og backup. Hvis fødselsdato kopieres til mange steder, øges både adgang og opbevaring. Et designvalg om ét felt påvirker derfor flere af artikel 25, stk. 2’s dimensioner. Dokumentér den valgte løsning, og kontrollér den efter lancering med en faktisk prøvehenvendelse.
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: bed leverandøren redegøre for, hvordan produktet kan understøtte jeres krav til dataminimering, adgangsstyring og sletning. 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 relevant certificeringsmekanisme efter artikel 42 kan indgå i vurderingen, men fritager ikke den dataansvarlige for den konkrete pligt.
Artikel 25 gælder også efter lanceringen
Forpligtelsen ligger hos den dataansvarlige både når midlerne til behandlingen fastlægges og når behandlingen udføres. En indstilling, der var passende ved lancering, kan blive utilstrækkelig efter nye integrationer, flere brugere eller et ændret formål. Gennemgå derfor de konkrete valg ved større ændringer: et nyt formularfelt, en eksportfunktion, bredere deling eller længere opbevaring. EDPB’s endelige retningslinjer beskriver artikel 25 som en løbende forpligtelse til at gøre principperne effektive.
Et hypotetisk eksempel: Et supportsystem startede med adgang for et lille team. Efter en reorganisering får alle salgsmedarbejdere adgang til hele historikken. Selv om ingen kode er ændret, er tilgængeligheden af personoplysninger ændret. Den dataansvarlige må vurdere, om denne adgang er nødvendig for formålet, justere roller og dokumentere beslutningen. Standardindstillinger skal også ses i lys af nye brugere: hvad kan de se, før nogen aktivt ændrer deres rettigheder?
Nødvendighed er mere præcis end »maksimal privatliv«
Artikel 25, stk. 2, ser på mængden af personoplysninger, behandlingens omfang, opbevaringstid og tilgængelighed. Standardindstillingen skal begrænse hvert forhold til det, der er nødvendigt for det specifikke formål. Det betyder ikke, at et system altid skal vælge den mindst mulige behandling uanset funktion. En leveringstjeneste kan have brug for leveringsadresse. Spørgsmålet er, om den også skal indsamle fødselsdato, dele adressen med alle afdelinger eller gemme den ubestemt. Forklar, hvorfor hvert nødvendigt felt og hver adgang er valgt.
Bestemmelsen siger også, at personoplysninger som udgangspunkt ikke må gøres tilgængelige for et ubestemt antal fysiske personer uden den registreredes medvirken. En social profil kan derfor være privat i startopsætningen, mens brugeren selv vælger en bredere deling. En intern personaleprofil kræver en anden vurdering: det relevante er hvilke medarbejdere, der skal have adgang for at udføre opgaven, ikke om profilen er offentlig på internettet. Datatilsynets gennemgang giver eksempler på tekniske og organisatoriske foranstaltninger.
Knyt hvert designvalg til et databeskyttelsesprincip
Dataminimering kan føre til færre formularfelter. Formålsbegrænsning kan føre til adskilte adgangsroller og tydelig styring af viderebrug. Rigtighed kan føre til mulighed for berigtigelse og markering af usikre oplysninger. Opbevaringsbegrænsning kan føre til slettefunktioner og påmindelser. Integritet og fortrolighed kan føre til adgangskontrol, logning og relevante tekniske sikkerhedsforanstaltninger. Gennemsigtighed kan føre til en tydelig oplysningstekst ved indsamlingen. En liste med teknologier uden forbindelse til behandlingen viser ikke, om principperne er gennemført effektivt.
Brug et simpelt beslutningsnotat: behandling og formål, risiko for personer, valgte foranstaltninger, hvorfor de passer til risikoen, ansvarlig ejer og dato for næste vurdering. Notatet kan henvise til fortegnelsen, sikkerhedsforanstaltningerne og eventuel DPIA. Det behøver ikke gentage alle dokumenter, men skal gøre valget efterprøveligt, når systemet ændres.
Hvem gør hvad i udvikling og indkøb?
Den dataansvarlige bærer artikel 25-pligten, selv om en leverandør bygger systemet. Et indkøbsteam kan derfor beskrive krav til datafelter, adgang, standarddeling, sletning og eksport, før der vælges produkt. Udviklere og databehandlere kan forklare tekniske muligheder og begrænsninger; de skal ikke alene beslutte, hvilket formål virksomheden lovligt kan forfølge. Hvis leverandøren behandler oplysninger på jeres vegne, skal artikel 28-aftalen beskrive den relevante bistand og sikkerhed, men aftalen erstatter ikke jeres designvurdering.
Ved en ny funktion bør produktejeren vise, hvilke oplysninger funktionen kræver, og hvad der sker, hvis brugeren ikke aktiverer den. En DPO kan rådgive, hvis organisationen har en sådan, men det er ikke automatisk DPO’en, der godkender alle designvalg. Hvis behandlingen sandsynligvis indebærer høj risiko, skal spørgsmålet om konsekvensanalyse tages op før behandlingen. Artikel 35, stk. 9, handler om at indhente registreredes eller repræsentanters synspunkter hvor det er relevant, og uden at tilsidesætte beskyttelsen af kommercielle eller offentlige interesser eller sikkerheden; det er ikke et generelt krav om at høre alle brugere i alle projekter.
Brug ændringsstyring som kontrolpunkt
Når et nyt system installeres, bør ansvarlige kunne se, hvilke standardværdier leverandøren har valgt. Efter en opdatering kan de værdier eller en ny funktion ændre datadeling, opbevaring eller adgang. Gør derfor gennemgang af relevante standardindstillinger til en del af ændringsstyringen. Gem en kort registrering af, hvilke valg der blev undersøgt, hvilke der blev ændret, og hvem der godkendte dem. Det gør det muligt at se, om en senere utilsigtet åbning skyldes en ny version eller en gammel opsætning.
Vurderingen skal passe til risikoen. En mindre ændring i en ufølsom kontaktformular behøver ikke samme analyse som indførelse af et HR-system med helbredsoplysninger. Artikel 25 nævner netop behandlingens karakter, omfang, sammenhæng, formål, omkostninger og tekniske niveau sammen med risikoen for personer. Kravet er passende og effektiv beskyttelse, ikke den samme kontrolpakke for alle projekter.
Kontroller standardindstillinger med en ny konto
Opret en prøvebruger med de rettigheder, en reel ny bruger får. Se hvilke felter der indsamles, hvilke meddelelser der sendes, hvem der kan finde profilen, om analytiske eller sociale delinger er aktive, og hvornår oplysningerne slettes. Gentag for en medarbejderrolle og en administratorrolle. En skærm med gode valgmuligheder hjælper ikke, hvis udgangspunktet åbner adgang til flere oplysninger end nødvendigt. Dokumentér de faktisk aktiverede standarder, ikke blot leverandørens markedsføringsbeskrivelse.
Når brugeren frivilligt vælger en anden indstilling, skal virksomheden stadig vurdere lovlighed, formål og sikkerhed. Artikel 25 er ikke en erstatning for et behandlingsgrundlag eller gyldigt samtykke. Det er en måde at indrette den lovlige behandling, så principper og rettigheder virker i praksis. En senere ændring af standardvalg bør behandles som en ny designbeslutning, især hvis den øger deling eller opbevaring.
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 begrænse standardbehandlingen til det nødvendige for hvert formål, uden at personen først skal ændre indstillinger.
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. Artikel 25 kræver handling ved fastlæggelsen af midlerne og under selve behandlingen. Foretag en konsekvensanalyse før behandlingen, hvis betingelserne i artikel 35 er opfyldt.
Konklusion
Databeskyttelse gennem design og standardindstillinger kræver, at du indbygger beskyttelse i systemer og processer fra start, og at standardindstillingerne ikke behandler eller gør flere oplysninger tilgængelige end nødvendigt for hvert formål. Brug de syv projektspørgsmål som tjekliste, og omsæt dem til konkrete tiltag: dataminimering, pseudonymisering, adgangsstyring, begrundede 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æs videre: