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. Utgangspunktet er at bare nødvendige personopplysninger behandles for hvert bestemt formål. Flere valg kan være aktuelle, men de må vurderes mot formål, behandlingsgrunnlag og de øvrige personvernprinsippene.
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.
- Planlagt sletting. Definer utløsende hendelse, frist, ansvar og håndtering av kopier. Automatikk kan brukes når den er teknisk og rettslig egnet, men må testes mot unntak.
- Tilgangsstyring. Gi tilgang etter behov (need-to-know), med logging av hvem som ser hva.
- Personvernvennlige standardinnstillinger. Vurder om deling, synlighet og valgfrie målinger er av som standard for det konkrete formålet; grunnlaget for nødvendige funksjoner vurderes separat.
- Støtte for rettigheter. Sørg for at data kan finnes, avgrenses, eksporteres og slettes når loven krever det. Innsyn, sletting og dataportabilitet har ulike vilkår; alle trenger ikke en egen automatisk knapp.
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. Når artikkel 35 krever en DPIA, bør den gjennomføres før oppstart og brukes til å velge innebygde tiltak. Også uten DPIA må artikkel 25 vurderes. Tiltakene kan redusere risiko, men en DPIA med vedvarende høy risiko kan kreve forhåndsdrøfting med Datatilsynet etter artikkel 36 før behandlingen starter.
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.
En anskaffelse bør derfor vise hvilke personvernvalg som er tatt, hvem som besluttet dem, og hvordan innstillingene kontrolleres etter oppstart. Sanksjoner må knyttes til bestemmelser som faktisk er vurdert i det konkrete vedtaket. Designvalget bør derfor begrunnes gjennom risiko og lovkrav, ikke gjennom en løs henvisning til et gebyr i en annen sak. En funksjon eller dokumentasjon alene gjør ikke den behandlingsansvarliges valg lovlige.
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 anskaffelse av mobiladministrasjon bør kravene konkretisere hvilke opplysninger løsningen viser, skillet mellom arbeid og privat bruk, og hva en fjernsletting faktisk omfatter. Der anskaffelsesreglene åpner for det, kan målbare personvernkrav inngå i evalueringen. Be om demonstrasjon av standardinnstillingene og kostnad ved nødvendige tilpasninger før valg; prisen kan ikke antas uten tilbud. 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.
- For omfattende standardbehandling. Vurder mengde, omfang, lagring og tilgjengelighet mot hvert bestemt formål. En generell «alt av»-regel erstatter ikke vurderingen av hva som er nødvendig.
- Å 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.
Eksempel: nytt system for timebestilling
En tenkt norsk klinikk skal kjøpe et system der pasienter bestiller time. Den behandlingsansvarlige beskriver først formålet: finne ledige timer, sende nødvendig bekreftelse og håndtere endring. Leverandøren foreslår et skjema med fødselsnummer, adresse, diagnose og fritekst. Klinikken spør hvilke felter hvert steg faktisk trenger. Den velger et mindre sett for bestilling og en separat, beskyttet kanal hvis medisinsk informasjon må gis før konsultasjonen. Valget dokumenteres i kravspesifikasjonen med ansvarlig og begrunnelse. Dette er et hypotetisk eksempel; det er ikke en generell regel om hvilke felt alle klinikker kan bruke.
Tilgjengelighet er neste spørsmål. Hvis bekreftelseslenken kan åpnes uten innlogging, bør den ikke vise mer informasjon enn nødvendig. Ansatte som setter opp timeplanen, trenger ikke automatisk tilgang til alle pasientopplysninger. Klinikken ber om demonstrasjon av roller, tilgangslogg, standarddeling og hvordan en feilkonfigurert rolle oppdages. En leverandørpåstand om «GDPR-klar» erstatter ikke slik kontroll. Ved valg av databehandler må avtalen og sikkerhetsvedlegget dessuten samsvare med den versjonen og de tilgangene klinikken faktisk kjøper.
Lagring bør avgjøres av klinikken for hvert formål. Et avbestilt møte kan ha andre behov enn dokumentasjon om behandling som ligger i en annen løsning. Den ansvarlige bestemmer slettetrigger, eventuelle rettslige oppbevaringskrav, og hvordan kopier og logger håndteres. Spør leverandøren hva «slett» gjør i produksjon og sikkerhetskopi, og be om et testresultat. En automatisk frist er bare nyttig dersom den er riktig satt og kan kontrolleres.
Beslutningspunkter gjennom utviklingsløpet
I idéfasen beskriver prosjekteier formål, mulige opplysninger, brukergrupper og alternativer med mindre inngripen. I anskaffelsen oversettes dette til kontrollerbare krav. Under konfigurering velger man startinnstillinger, tilgangsroller, datalagring og informasjonsflyt. Før lansering tester man disse i et miljø som ligner faktisk bruk. Etter lansering kontrollerer man at nye funksjoner og leverandørendringer ikke åpner mer deling eller lengre lagring enn den opprinnelige beslutningen tillot.
Et nytt analyseverktøy i timebestillingen er et godt eksempel på endring. Prosjekteier må spørre om analyse er nødvendig for tjenesten, hvilke identifikatorer som samles inn, om leverandøren får egne formål, og om de registrerte får riktig informasjon. Et gammelt designvedtak dekker ikke automatisk dette. Oppdater behandlingsprotokollen og vurder personvernkonsekvenser dersom risikobildet har endret seg. En DPIA er pliktig når artikkel 35s høyrisikoterskel er oppfylt; den er ikke et obligatorisk skjema for hvert prosjekt.
Vedlikehold krever en eier for hver beslutning. Definer hvem som kan endre standardinnstilling, hvem som godkjenner nye felt, og hvordan avvik meldes. Ta vare på skjermbilder eller konfigurasjonseksport som viser faktisk standardversjon ved lansering, sammen med begrunnelsen. En databehandler kan levere teknisk dokumentasjon, men den behandlingsansvarlige må vurdere om tiltakene passer til egne formål og de registrertes risiko.
Hvordan vurdere «nødvendig» i standardinnstillingen
Artikkel 25 nr. 2 omfatter mengden opplysninger, behandlingens omfang, lagringsperioden og tilgjengeligheten. Still fire konkrete spørsmål ved hvert nytt felt eller tilgangsvalg: Hvilket bestemt formål krever det? Hvem trenger det for å gjennomføre formålet? Hvor lenge er det nødvendig? Hvilken standardvisning møter en ny bruker? Vurder den faktiske brukerreisen, ikke bare administrasjonspanelets liste over mulige innstillinger.
En offentlig profil er for eksempel problematisk som standard hvis formålet kan oppnås med en privat profil. I en intern medarbeiderkatalog kan det derimot være nødvendig å vise navn og arbeidskontakt til kolleger, mens privat mobilnummer eller fødselsdato fortsatt ikke trenger samme tilgjengelighet. Et absolutt krav om «alle valg av» gir ikke en god beskrivelse av artikkel 25. Begrunn hver kategori, og gjør mer omfattende deling til et bevisst valg der rettslig grunnlag og tjenestens formål tillater det.
Pseudonymisering kan redusere koblingen mellom data og person i analyse, men den fjerner ikke nødvendigvis personopplysningskarakteren. Begrens tilgangen til koblingsnøkkelen og vurder om mottaker kan identifisere personer på andre måter. Les mer om pseudonymisering og nøkkelhåndtering. Dersom opplysninger skal deles eksternt, vurder mottakerens rolle, identifiseringsmuligheter og behandlingsgrunnlag særskilt.
Norske kilder og kontroll av praksis
Personopplysningsloven gjør GDPR til norsk rett. Datatilsynets oversikt over virksomhetenes plikter lenker til norsk veiledning om programvareutvikling med innebygd personvern. EDPBs endelige retningslinjer 4/2019 forklarer artikkel 25. Veiledningene hjelper med metode, mens forordningens ordlyd og konkret risiko avgjør hvilke tiltak som er egnet. Datatilsynets DPIA-veiledning understreker vurdering før behandling ved høy risiko.
Et lite kontrollark for en reell beslutning
Skriv én rad per omstridt designvalg, ikke bare et generelt utsagn om at løsningen er «personvernvennlig». For eksempel: «Telefonnummer er valgfritt i skjema for timepåminnelse; e-post er standardkanal; ansvarlig: produktleder; vurdert: 27. september 2026». Neste rad kan beskrive hvem som får se avtalen og når den slettes. Noter både valgt løsning, forkastet alternativ og hvorfor. Dette gir utviklere et konkret krav og gjør senere kontroll mulig.
Test deretter med en ny brukerprofil og en vanlig medarbeiderrolle. Sjekk hvilke felt som faktisk er påkrevd, hvilke data som vises uten valg, og hva som ligger igjen etter avsluttet tjeneste. Hvis skjermbildet og dokumentasjonen avviker, er det faktisk oppsett som må korrigeres. Ta med en representant for tjenesten, sikkerhet og personvern slik at beslutningen dekker både behov og risiko. EDPB understreker at tiltak skal være effektive i praksis, ikke bare finnes som policy.
Den registrertes rettigheter har også designkonsekvenser. Hvis innsyn krever at ansatte gjennomsøker ustrukturert fritekst, bør systemet ha en realistisk søke- og gjennomgangsmåte. Hvis sletting er aktuelt, må teamet kunne skille data som kan slettes fra data som må beholdes etter lov. Krav til disse operasjonene bestemmes av reglene for hver rettighet og behandlingen; artikkel 25 krever egnede designvalg, ikke at alle rettigheter alltid utføres automatisk.
Et særskilt spørsmål oppstår når løsningen er kjøpt ferdig og kunden ikke kan endre kildekoden. Den behandlingsansvarlige kan likevel vurdere om tjenesten er egnet, velge en mer begrenset konfigurasjon, stille krav til leverandøren eller la være å bruke funksjonen. Dokumenter hvilke innstillinger som faktisk kan endres, hvilke begrensninger leverandøren bekrefter, og hvilken risiko som gjenstår. Hvis en nødvendig funksjon bare virker ved å gjøre alle profiler offentlige, må formål og alternativer vurderes før lansering. En databehandleravtale er viktig når leverandøren behandler data på kundens vegne, men den kan ikke alene reparere en designbeslutning som strider mot nødvendighetskravet.
Når leverandøren vil bruke de samme opplysningene til egne analyser, må dere avklare rollene før funksjonen aktiveres. Lag samtidig et kort bevis for beslutningene: formål, nødvendig datamengde, valgt standardinnstilling, alternativet dere avslo og ansvarlig for ny vurdering. Dette gjør artikkel 25 til et kontrollerbart designvalg og gir neste prosjektteam en begrunnelse å bygge videre på.
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
Artikkel 25 krever vurdering både når behandlingsmåtene fastsettes og mens behandlingen pågår. 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. Kontroller valgene på nytt når tjenesten, formålet eller risikoen endres.
Denne artikkelen gir generell informasjon om artikkel 25 og utgjør ikke juridisk rådgivning.