Innebygd personvern (privacy by design) og personvern som standardinnstilling (privacy by default) innebærer at personvern skal bygges inn i systemer, tjenester og prosesser fra første stund – ikke legges på i etterkant. Kravet følger av artikkel 25 i personvernforordningen (GDPR). Innebygd personvern betyr at den behandlingsansvarlige allerede ved fastsettelsen av midlene for behandlingen skal gjennomføre tekniske og organisatoriske tiltak for å ivareta personvernprinsippene. Personvern som standard betyr at standardinnstillingene skal være de mest personvernvennlige – bare de opplysningene som er nødvendige for hvert formål skal behandles, uten at den registrerte må gjøre noe aktivt.
Denne artikkelen forklarer hva de to prinsippene krever, hvilke konkrete tiltak de innebærer, hvordan de henger sammen med personvernkonsekvensvurdering og de registrertes rettigheter, og hvilke feil som er vanligst. Personvernforordningen gjelder i Norge gjennom personopplysningsloven og EØS-avtalen.
Hva krever innebygd personvern?
Artikkel 25 nr. 1 pålegger den behandlingsansvarlige å gjennomføre egnede tekniske og organisatoriske tiltak – som pseudonymisering og dataminimering – både ved fastsettelsen av midlene for behandlingen og under selve behandlingen. Tiltakene skal utformes for å gjennomføre personvernprinsippene på en effektiv måte og bygge inn nødvendige garantier. Vurderingen skal ta hensyn til teknologiens nivå, kostnadene ved gjennomføring, behandlingens art, omfang, formål og sammenheng, og risikoen for de registrertes rettigheter.
Nøkkelen ligger i tidspunktet: personvern skal vurderes ved fastsettelsen av midlene – altså i planleggings- og designfasen, før systemet bygges eller anskaffes. Å bygge et system først og deretter forsøke å «gjøre det GDPR-kompatibelt» er nettopp det artikkel 25 skal forhindre. Datatilsynet har utviklet praktisk veiledning for programvareutvikling med innebygd personvern.
Hva er personvern som standardinnstilling?
Artikkel 25 nr. 2 krever at standardinnstillingene bare tillater behandling av personopplysninger som er nødvendige for hvert spesifikke formål. Dette gjelder mengden opplysninger, omfanget av behandlingen, lagringstiden og tilgjengeligheten. Konkret betyr det for eksempel at en profil ikke skal være offentlig som standard, at datainnsamling ikke skal gå lenger enn formålet krever, og at opplysninger ikke skal gjøres tilgjengelige for et ubestemt antall personer uten den registrertes medvirkning. Den mest personvernvennlige innstillingen skal være utgangspunktet – den registrerte skal måtte aktivt velge mer deling, ikke mindre.
Konkrete tiltak for innebygd personvern
Prinsippene er abstrakte, men lar seg oversette til konkrete grep:
- Dataminimering. Samle bare inn felter som faktisk trengs. Fjern «nice to have»-felter fra skjemaer. Dette er samme logikk som ligger under lagringsbegrensning.
- Pseudonymisering. Skill identifiserende opplysninger fra øvrige data der det er mulig, slik at et brudd får mindre konsekvens.
- Standard slettefrister. Bygg automatisk sletting inn i systemet, slik at opplysninger fjernes når fristen løper ut uten manuell inngripen.
- Tilgangsstyring. Gi tilgang etter behov (need-to-know), med logging av hvem som ser hva.
- Personvernvennlige standardinnstillinger. Nyhetsbrev av som standard, deling av som standard, sporing av som standard.
- Innebygde rettighetsfunksjoner. Bygg innsyn, sletting og dataportabilitet inn i systemet fra start, ikke som manuelle prosesser.
Hvordan henger artikkel 25 sammen med DPIA?
De to henger tett sammen. En personvernkonsekvensvurdering er verktøyet for å identifisere risiko tidlig, mens innebygd personvern er svaret på den risikoen – de tekniske og organisatoriske tiltakene som reduserer den. I praksis gjennomfører man DPIA i designfasen nettopp for å avdekke hvilke innebygde tiltak som trengs. Der DPIA viser høy risiko, er artikkel 25-tiltak ofte det som bringer risikoen ned til et akseptabelt nivå.
Innebygd personvern i praksis
For norske virksomheter er det praktiske utgangspunktet anskaffelser og utvikling. Ved kjøp av et nytt system bør personvernkrav inn i kravspesifikasjonen og i databehandleravtalen, slik at leverandøren dokumenterer hvordan systemet oppfyller artikkel 25. Ved egenutvikling bør personvern være et fast punkt i design- og kodegjennomgang, ikke noe som vurderes til slutt.
Hvordan stiller man krav om innebygd personvern ved anskaffelser?
Ved kjøp av programvare eller tjenester bør personvernkrav inn allerede i kravspesifikasjonen, ikke først i kontraktsforhandlingen. Konkret kan man kreve at leverandøren dokumenterer hvordan systemet gjennomfører dataminimering, hvilke standardinnstillinger som er personvernvennlige, hvordan sletting og innsyn er bygget inn, og hvordan tilgang styres og logges. Disse kravene følges opp i databehandleravtalen og i eventuelle vedlegg om sikkerhetstiltak. Ved å gjøre innebygd personvern til et tildelingskriterium unngår virksomheten å kjøpe en løsning som må ombygges i etterkant – noe som er langt dyrere enn å stille kravene på forhånd. For utviklingsprosjekter bør personvern være et fast punkt i design- og kodegjennomgang, på linje med sikkerhet og funksjonalitet.
Vanlige feil
- Å tenke personvern til slutt. Artikkel 25 krever vurdering i designfasen, ikke som et tillegg etter lansering.
- Personvernfiendtlige standardinnstillinger. Alt «på» som standard bryter artikkel 25 nr. 2. Standarden skal være det mest personvernvennlige.
- Å samle inn «for sikkerhets skyld». Felter man kanskje trenger senere, bryter dataminimeringskravet.
- Å overlate alt til leverandøren uten å stille dokumenterte krav i kravspesifikasjon og databehandleravtale.
- Å ikke dokumentere tiltakene. Ansvarlighet krever at man kan vise hvordan personvern er bygget inn, ikke bare hevde det.
Ofte stilte spørsmål
Hva er forskjellen på innebygd personvern og personvern som standard?
Innebygd personvern (artikkel 25 nr. 1) handler om å bygge personvern inn i systemer og prosesser gjennom tekniske og organisatoriske tiltak, allerede i designfasen. Personvern som standard (artikkel 25 nr. 2) handler om at standardinnstillingene skal være de mest personvernvennlige, slik at bare nødvendige opplysninger behandles uten aktiv handling fra den registrerte.
Gjelder artikkel 25 bare for programvareutvikling?
Nei. Artikkel 25 gjelder all behandling, også manuelle prosesser og anskaffelser. Ved kjøp av systemer må den behandlingsansvarlige stille krav om innebygd personvern til leverandøren, og ved utforming av rutiner må personvern bygges inn fra start – ikke bare i programkode.
Hvordan dokumenterer man innebygd personvern?
Ved å beskrive de konkrete tekniske og organisatoriske tiltakene per behandling: hvilke felter som samles inn og hvorfor, hvilke standardinnstillinger som gjelder, hvordan sletting skjer, og hvordan tilgang styres. Dokumentasjonen bør knyttes til behandlingsprotokollen og eventuell DPIA, slik at ansvarligheten kan påvises.
Er innebygd personvern det samme som informasjonssikkerhet?
Nei, men de overlapper. Informasjonssikkerhet etter artikkel 32 handler om å beskytte opplysningene mot uautorisert tilgang, tap og endring. Innebygd personvern etter artikkel 25 er bredere og omfatter også dataminimering, formålsbegrensning, personvernvennlige standardinnstillinger og innebygde rettighetsfunksjoner. Et system kan være godt sikret, men likevel bryte artikkel 25 dersom det samler inn mer enn nødvendig eller har deling påslått som standard.
Konklusjon
Innebygd personvern og personvern som standard flytter personvernarbeidet fra etterkontroll til design. Bygg dataminimering, pseudonymisering, slettefrister, tilgangsstyring og personvernvennlige standardinnstillinger inn i systemene fra start, og gjør de registrertes rettigheter til innebygde funksjoner. Prinsippene henger tett sammen med personvernkonsekvensvurdering: DPIA finner risikoen, artikkel 25-tiltak reduserer den. Still dokumenterte krav ved anskaffelser, og knytt tiltakene til behandlingsprotokollen. Personvern bygget inn fra start er både billigere og mer effektivt enn personvern lagt på etterpå.
Denne artikkelen gir generell informasjon om artikkel 25 og utgjør ikke juridisk rådgivning.