Metode for DPIA

I denne bloggposten vil jeg blande dagjobben min og.. jeg holdt på å si helgejobben min, men det er ikke helt riktig. Dette er ingen helgejobb. Personvern er på hjernen min hele tiden. Er det for dramatisk å kalle det et kall?

Uansett!

Jeg har lyst til å dele noe vi gjør på dagjobben min som prosjektleder i KS-prosjektet der vi lager en nasjonal DPIA for bruk av Google Workspace for Education i skolen. https://www.ks.no/fagomrader/digitalisering/felleslosninger/skolesec/personvernkonsekvenser-for-googles-produkter-i-skolen-skal-vurderes/

Du kan melde deg på nyhetsbrevet for prosjektet her (for SELVFØLGELIG har jeg et nyhetsbrev der også): https://pub.dialogapi.no/s/MTk4ODA6ZmUyZjg3ZTQtYWZmYS00NGZjLWE2MzItYmNkNjFlNmEyOTBm  

Problemet med metoden for DPIAer

Jeg har aldri sett noen god metode for å faktisk vurdere personvernrisiko. Og jeg tror det skyldes at vi har adoptert informasjonssikkerhetsmetoden uten å se på hvilke særegenheter som personvernrisiko innebærer.

Den enkleste metoden for å vurdere informasjonssikkerhetsrisiko, er en to-faktormodell hvor du vurderer sannsynligheten for at en uønsket hendelse vil skje, og hva konsekvensene vil bli dersom den realiseres.

Og sannsynlighetsvurderingen er den som jeg har syntes er vanskeligst å forholde meg til.

La meg ta et vanlig og overordnet risikoscenario på personvern: «Det er risiko for at den registrerte ikke får oppfylt sin rett til sletting».

La oss se for oss en helt vanlig norsk kommune hvor de har en sletterutine. De aller fleste registrerte har ikke noe forhold til hvilken rettighet de påberoper seg, om det er retten til å protestere, retten til sletting eller en generell klage på at den registrertes rettigheter ikke er oppfylt.

Du kan heller ikke kontrollere hvem den registrerte henvender seg til for å nyttiggjøre seg av disse rettighetene. Selvsagt kan du lage en e-postadresse som du legger opp til at de skal henvende seg til, men en henvendelse om personvern kan komme inn på mange måter.

Men la oss si at en henvendelse om sletting kommer inn til saksbehandleren som har behandlet byggesaken til den registrerte.

Du som kommune plikter å nøste i de henvendelsene som kommer inn. Det betyr at uansett hvordan de kommer inn må du rute de til rett sted, og du må finne ut hvilke rettigheter som den registrerte påberoper seg. Og SÅ må du ta stilling til om du skal etterkomme henvendelsen – skal den registrerte få slettet noen av personopplysningene sine?

Okay. Tilbake til DPIAer og personvernkonsekvenser.

I dette scenarioet kan jeg ikke si at den registrerte ikke vil få oppfylt sin rett til sletting. Men det er mange ting som må skje i denne prosessen for at denne rettigheten skal bli oppfylt. 

(Og med oppfylt sin rett til sletting, mener jeg ikke at den registrerte er garantert å få slettet sine personopplysninger. Kravet er heller at den registrerte skal få behandlet henvendelsen sin om sletting. Hva utfallet faktisk blir er en annen sak.)

Kan det være at e-posten med forespørselen om sletting blir borte i systemet fordi den saksbehandleren som mottar henvendelsen ikke forstår at dette handler om personvern og retten til sletting? Absolutt!

Men her gir det mindre mening å snakke om hvor ofte det vil skje. Der skoen trykker for denne prosessen er at det er mange ting som må klaffe. Og hvordan sikrer du at alle tingene du trenger å sikre retten til sletting faktisk er på plass.  

Skjønnsmessige vurderinger

Jeg har gjort mange DPIAer hvor jeg har brukt to-faktormetoden som vi har fra informasjonssikkerhetsfaget. Og nå som jeg er prosjektleder for en ny DPIA, har jeg anledningen til å gjøre dette annerledes.

Så la meg dele metoden vi bruker i DPIAen for Google Workspace for Education.

Metode for vurdering av personvernkonsekvenser

Som du ser, er ikke dette en matematisk metode hvor du plotter inn sannsynlighet og konsekvens i en risikomatrise på 5x5 for å finne den samlede risikoen. Det er en fullstendig skjønnsmessig vurdering av personvernrisiko.

Jeg har noen kvaler med skjønnsmessige vurderinger. Der kan f.eks. være nokså subjektive. Det krever mye av deg som fagperson. Og du må sånn helt på ekte gjøre disse vurderingene i fellesskap, sammen med andre fagpersoner, slik at din bakgrunn og din forutinntatthet farger hele vurderingen. Det tar tid.

Men grunnen til at jeg foretrekker det de erfaringene jeg har med at den mer matematiske måten å vurdere risiko også er nokså skjønnsmessig. Jeg har vært med på at vi som gjør risikovurderingene, «trikser» kanskje særlig med hvordan vi vurderer sannsynlighet. Rett og slett fordi det er nesten umulig å gjøre noe med konsekvensene av et risikoscenario.

Og det blir også feil.

Hvordan ser dette ut i praksis?

Det jeg deler med deg nå, er et veldig ferskt utkast fra en vurdering av personvernrisiko som vi har gjort i det nasjonale DPIA-prosjektet. Sånn ser det ut, skrivefeil og alt:

Eksempel på personvernkonsekvensvurdering i en DPIA

«Risikotrigger»

Jeg synes det ofte er vanskelig å starte en vurdering av personvernkonsekvenser. Som jurist har jeg en tendens med å starte i personvernprinsippene og rettighetene til den registrerte – er det risiko for at noen av dem brytes?

Men det er ofte et ganske fremmed sted å starte for mine kjære ikke-jurister. (Ja, vi jurister deler verden opp i jurister og ikke-jurister eller lekfolk! Sånn er det bare :P)

Og derfor har vi prøvd oss på en start vi har kalt «risikotrigger» - altså den tingen som gjør at dette kan bli en risiko.

Risikoscenario

Her beskriver vi hva det er som skjer – hva er det som gjør at «dette» kan ha personvernkonsekvenser. Det vi prøver å gjøre her er å beskrive de faktiske forholdene.

Hvis jeg skulle ha vurdert eksempelet ovenfor med sletting, ville jeg ha beskrevet prosessen for å få oppfylt retten til sletting. Og så ville jeg ha understreket alle de tingene som måtte skje for at den registrerte skulle få behandlet forespørselen sin om sletting.  

Beskrivelse av personvernkonsekvenser

Det er her du beskriver hva som kan gå galt. Og det jeg liker med denne metoden er at du kan få frem de konsekvensene som er mest sannsynlige. Det ser du av eksempelet vårt. Vi nevner hva som er de mest sannsynlige personvernkonsekvensen. Vi sier vi også noe om hva som er de personvernkonsekvensene som vi tror vil kunne skje, men i mer sjeldne tilfeller.

For eksempelet med sletting er det her jeg ville ha beskrevet at den registrerte mest sannsynlig vil få oppfylt sin rett til sletting. Her legger jeg f.eks. til grunn at kommunen har gitt alle saksbehandlere opplæring slik at den saksbehandleren som mottar forespørselen vet å rute den til en person i kommunen som kan ta stilling til forespørselen om sletting.

Men så ville jeg også ha pekt på svakhetene i denne prosessen. Og hvis noen av svakhetene betyr at retten til sletting i noen tilfeller ikke vil bli oppfylt, må jeg beskrive det også.

Hele poenget med denne metoden er å finne svakhetene i den forvaltningsriggen du har bygget. Hvis retten til sletting er avhengige av at saksbehandlerne dine klare å identifisere forskjellen på hva som er en klage etter forvaltningsloven og hva som er en forespørsel om sletting etter GDPR, er det her du må sette inn støtet. Kanskje i form av opplæringstiltak.   

Risikonivå og begrunnelse

Så kommer vi til selve vurderingen hvor vi skal bruke de risikonivåene jeg viste deg tidligere på dette scenarioet. Vi har tre risikonivå i denne modellen:

• Lav risiko: Du har så mange tiltak på plass eller en så god prosess for å ivareta personvernprinsippene eller den registrertes rettigheter, at det er lav risiko for personvernbrudd. 

• Middels risiko: Du har en prosess på plass, men den har noen svakheter som gjør at du ikke alltid vil klare å ivareta den registrertes personvern.

• Høy risiko: Det er ting ved det systemet du bruker, de prosedyrene eller prosessen du har, som gjør at de registrertes rettigheter eller personvernprinsippene vil bli brutt.

Jeg liker denne metoden fordi den gir deg fleksibilitet.

For eksempelet vårt med endringshåndtering, ser du at vi har vurdert dette til middels risiko. Ikke fordi du har noen prosedyrer på plass, men pga selve scenarioet: de aller fleste endringene i Google Workspace for Education er ganske harmløse, og vil ikke påvirke hvilke personopplysninger du som behandlingsansvarlig behandler. Endringene omfatter heller brukergrensesnittet ditt.

For eksempelet vårt med sletting, ville jeg nok også ha falt ned på middels. Rett og slett fordi jeg legger til grunn at du HAR drevet med opplæring av ansatte, du HAR et sted de registrerte kan henvende seg for å be om sletting og du HAR interne prosedyrer som hjelper de som skal vurdere sletting å gjøre det.

Men hvis du ikke har noen tiltak på plass, eller hvis det er lenge siden de ansatte har fått opplæring, eller mange har sluttet slik at kunnskapen nå er tapt, hadde jeg justert opp denne risikoen til høy.