Må dere gjøre en DPIA før lansering?

Før en ny digital tjeneste lanseres, dukker spørsmålet ofte opp for sent: Må vi gjøre en DPIA? En vurdering av personvernkonsekvenser (DPIA) er verktøyet i personvernforordningen (GDPR) for å fange opp personvernrisikoer før de bygges inn, og for noen tjenester er den et lovkrav. Gjøres den i tide, er den en støtte som former en bedre tjeneste. Gjøres den for sent, blir den en stressende formalitet. Denne guiden hjelper deg å avgjøre om tjenesten din utløser kravet, og hvordan du gjennomfører vurderingen slik at den gjør reell nytte.

Kriteriene som utløser kravet

Grunnregelen i GDPR er at en DPIA kreves når en behandling av personopplysninger sannsynligvis innebærer høy risiko for folks rettigheter og friheter. Det høres abstrakt ut, men i praksis finnes det en rekke konkrete kriterier som veier tungt, og jo flere som slår til, desto tydeligere er kravet.

• Sensitive opplysninger. Behandling av opplysninger om helse, etnisitet, religion, seksuell orientering eller lignende særlig beskyttelsesverdige kategorier.
• Kartlegging og profilering. Systematisk evaluering av personer, for eksempel poengsetting, atferdsanalyse eller automatiserte avgjørelser.
• Behandling i stor skala. Store mengder opplysninger eller et stort antall registrerte.
• Overvåking. Systematisk overvåking av offentlige eller halvoffentlige områder.
• Sårbare grupper. Opplysninger om barn, pasienter eller andre i et avhengighetsforhold.
• Ny teknologi. Løsninger der konsekvensene for personvernet er vanskelige å overskue på forhånd.

Gjelder bare ett av kriteriene, og bare delvis, kan en enklere vurdering være nok. Kombineres flere, for eksempel i en app som profilerer brukere i stor skala eller en tjeneste med sensitive opplysninger om barn, er en DPIA nesten alltid nødvendig. Er dere usikre, er utgangspunktet enkelt: Gjør en overordnet vurdering av risikoen, og havner den høyt, gjør en full DPIA.

Prosessen steg for steg og hvem som skal være med

En DPIA er ikke ett enkelt skjema, men en gjennomgang i flere steg. Målet er å forstå behandlingen, vurdere risikoene og bestemme hvordan de skal reduseres. Alt dette skjer før noe bygges.

1. Beskriv behandlingen. Hvilke opplysninger samles inn, hvorfor, hvor går de, og hvor lenge lagres de?
2. Vurder nødvendighet og forholdsmessighet. Trengs virkelig alle opplysningene for formålet, eller kan mindre samles inn?
3. Identifiser risikoene. Hva kan gå galt for de registrerte: lekkasje, misbruk, uønsket kartlegging?
4. Bestem tiltak. Hvordan reduseres risikoene: mindre data, kortere lagring, kryptering, strengere tilgangsstyring?
5. Rådfør dere ved gjenværende høy risiko. Hvis risikoen fortsatt er høy etter tiltakene, skal dere rådføre dere med Datatilsynet før oppstart, såkalt forhåndsdrøfting.

Like viktig som stegene er hvem som deltar. Den behandlingsansvarlige leder arbeidet, personvernombudet gir råd og kontrollerer, virksomheten forklarer formålet, og de teknisk ansvarlige beskriver hvordan opplysningene faktisk håndteres. Uten det tekniske perspektivet blir vurderingen lett et skrivebordsprodukt som ikke gjenspeiler virkeligheten. En DPIA er heller ikke et engangsdokument. Endres tjenesten vesentlig, må den oppdateres.

Hvordan resultatet styrer designbeslutninger

Det som skiller en meningsfull DPIA fra en hyllevarmer, er når den gjøres. Gjennomføres den tidlig, mens tjenesten fortsatt er på tegnebrettet, blir den et designverktøy. Gjennomføres den etter at systemet er bygget, blir den i beste fall en bekreftelse på problemer det nå er dyrt å rette opp.

En tidlig DPIA fører ofte til konkrete valg: Kanskje trenger dere ikke å samle inn et bestemt felt i det hele tatt, kanskje holder det med pseudonymiserte data til formålet, kanskje bør lagringstiden kortes ned eller tilgangen begrenses strengere. Slike beslutninger er trivielle å ta på tegnebrettet, men kostbare å bygge om i etterkant. Det er selve tanken bak innebygd personvern: at personvernet bygges inn i tjenesten fra starten av i stedet for å lappes på til slutt. En vanlig misforståelse er at en DPIA bare er juss og papirarbeid. I virkeligheten er den en av de beste anledningene til å ta smartere tekniske beslutninger nettopp fordi den tvinger frem spørsmålet «trenger vi virkelig denne opplysningen?» før koden skrives.

Et konkret scenario

En organisasjon planla en tjeneste som skulle følge brukernes aktivitet over tid for å gi personlige anbefalinger. Behandlingen innebar profilering i et visst omfang, og en overordnet risikovurdering havnet høyt. En full DPIA var berettiget, og den ble gjort før utviklingen startet.

Vurderingen førte til flere endringer i designet. Noen opplysninger som opprinnelig skulle samles inn, viste seg å være unødvendige for formålet og ble strøket. Det som trengtes, ble pseudonymisert, lagringstiden ble kortet ned, og tilgangen ble begrenset til noen få roller. Endringene ble gjort på tegnebrettet, uten kostnader til ombygging. Hvis DPIA-en først hadde blitt gjort etter lansering, ville de samme funnene i stedet ha betydd å bygge om en ferdig tjeneste: dyrere, tregere og med en periode med unødvendig risiko imellom.

Gjør vurderingen i tide

En DPIA er ikke noe å skyve foran seg til like før lansering. Avgjør tidlig om tjenesten utløser kravet, involver juss, virksomhet og teknologi, og la konklusjonene forme designet mens det fortsatt er billig. Da blir vurderingen ikke en brems, men en støtte som gir både bedre personvern og smartere tekniske valg.

Vi i Weapp bygger med innebygd personvern som utgangspunkt og bidrar gjerne med det tekniske perspektivet i en DPIA, som en del av tjenestene våre. Planlegger dere en tjeneste som behandler personopplysninger? Ta kontakt, så drøfter vi om en DPIA trengs, og hvordan den best kan vevs inn tidlig i prosjektet.