Å være personvernrådgiver er 20% personvern og 80% psykologi

Photo by Roman Kraft on Unsplash.

Når vi jobber med personvern, pirker vi borti andre mennesker i deres arbeidshverdag. Vi påpeker måter de jobber på som ikke er i tråd med personvernkrav. Rådene våre gjør ofte at folk må jobbe annerledes, at prosesser og systemer må endres.

Ingen liker å bli pirka borti. I det ligger det implisitt at jeg har gjort noe galt, og da vil min første reaksjon være å avvise de masete personverngreiene du kommer med.

Personvern er 20% fag, og 80% å forstå disse psykologiske mekanismene. Og med «psykologiske mekanismer» mener jeg rett og slett at hvis et råd du kommer med får den andre til å føle at de ikke er «bra nok», vil de bli utrygge, og ha vanskeligere for å akseptere rådet ditt.

Dette er en realitet vi som jobber med personvern må ha et bevisst forhold til hvis vi skal gjøre en effektiv jobb Hvordan? Empati og ved å myndiggjøre andre. Her er to ting jeg gjør for å løse dette:

1 Si nei, men gi folk løsninger

«Ok, så er det behandler dere personopplysninger, og GDPR kommer til anvendelse. Men personopplysninger skal behandles etter risiko, så så lenge dere har etterlevelsesdokumentasjon på plass, er det kanskje ikke mange risikoreduserende tiltak dere trenger å iverksette. Og akkurat dette kan jeg hjelpe dere med»

Min erfaring er at man HAR et handlingsrom innenfor personvernregelverket. Men mer spenstige løsninger kan innebære mer jobb på etterlevelsessiden. Det er jo gjerne det som tar tid. Så her handler det om å gjøre oppmerksom på risiko, og hva behandlingsansvarlig må gjøre for å likevel kunne løse det.

Si at noen ønsker å bruke Google Analytics. Det er ikke noe jeg anbefaler lenger, men det finnes mange alternativer (Anette Thorsen skriver mye om alternativer til GA på Linkedin, sjekk f.eks. ut denne Linkedin-posten) https://www.linkedin.com/feed/update/urn:li:activity:7043510238875901952?updateEntityUrn=urn%3Ali%3Afs_feedUpdate%3A%28V2%2Curn%3Ali%3Aactivity%3A7043510238875901952%29

2 Ros der du kan, ofte og uhemmet

Med en gang du kan, ros de du rådgir. Kommer de med en god begrunnelse for hvorfor de kanskje likevel ikke trenger et fritekstfelt, fortell dem at det er en veldig bra personvernrefleks!

Dette er et generelt ledelsesråd, påpek og ros alltid ønsket adferd! Det er MYE mer motiverende enn å måtte pirke borti når noe ikke står så bra til.

En annen fordel er at hvis du har rost nok, bygger du deg en tillitsrelasjon til de du roser. Så når du først må be noen om å justere, vil ikke den beskjeden oppleves som så voldsom.

Viktig forbehold: du skal ikke ta ansvar for andre folks følelser

Jeg sier ikke at du må ta ansvar for andre folks følelser. Ikke gjør det. Som en «people pleaser in recovery», er det viktig for meg å være tydelig på dette.

Noen ganger har du vært så empatisk som overhodet mulig, og de du gir råd til reagerer likevel defansivt. Et godt første skritt er å være klar over disse mekanismene. Og vit at selv om du har gjort alt perfekt, står ikke utfallet av en interaksjon på deg alene.

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.