Hva trenger du å vite om ePrivacy-direktivet og cookies?

Photo by Vyshnavi Bisani on Unsplash

Hva er en cookie? Kort fortalt er det er en liten tekstfil som lastes ned og lagres på PCen din når du åpner en nettside.

Du har kanskje irritert deg over at det kommer opp et banner når du besøker en nettside? Kanskje er du rett og slett lei av dem? Eller kanskje du virkelig ønsker å ta personvernvennlige valg, men er lei det manipulerende designet slike banne ofte har?

Uansett, dette er en veldig kort innføring i hva disse reglene er i Norge, hvorfor dette er ganske rotete, og hva fremtiden kanskje vil bringe.

Litt historikk

ePrivacy-direktivet er et EU-direktiv fra 2002 som regulerer elektronisk kommunikasjon og personvern, inkludert cookies. Du har kanskje hørt om ePrivacy Regulation? Det er en forordning EU har arbeidet med lenge som skulle erstatte ePrivacy-direktivet.

Den forordningen har ligget på is lenge, selv om man håpet at det skulle iverksettes samtidig med GDPR i 2018.  

Fordi ePrivacy er et direktiv, og foreløpig ikke en forordning, kan Norge velge om vi skal inkorporere kravene i det i norsk lov. Og det er inkorporert i norsk rett i flere lover, i all hovedsak ekomloven, men også markedsføringsloven.

Samtykke etter ekomloven for bruk av cookies og GDPR-samtykke

Ekomloven § 2-7b regulerer samtykke for cookies, og hvilken informasjon du må gi til brukerne av nettsiden din.

Kort fortalt sier den norske ekomloven at forhåndsinnstillinger i nettleser om at du som besøker nettsiden aksepterer cookies, er et gyldig samtykke. Og du som kjenner samtykkereglene i GDPR, legger merke til at samtykke etter ekomloven er ganske forskjellig fra samtykke etter GDPR.

For at et samtykke skal være gyldig etter GDPR, må det nemlig være frivillig, spesifikk, informert og utvetydig, jf. GDPR artikkel 4(11).

I 2019 kom en dom fra EU-domstolen (Planet 49-dommen) som tok stilling til om samtykke etter ePrivacy-direktivet (for oss ekomloven), skulle forstås som samtykke etter GDPR. Domstolen kom frem til at det skulle være samme krav til samtykke etter ePrivacy-direktivet, som etter GDPR.  

Problemet i Norge

Jeg hørte en gang en Podcast fra IAPP om cookies i EU/EØS, og eksperten trakk frem ett av de nordiske landene som særlig rotete når det kommer til reguleringen av cookies. Og jeg mistenker at de mente Norge.

Og med god grunn! Hvordan vi har inkorporert ePrivacy-direktivet i norsk rett er, pardon my french, et clusterfuck.

Det organet som er fagansvarlig for ekomloven, er Nasjonal kommunikasjonsmyndighet, tidligere «Post- og teletilsynet». Men det er Datatilsynet som er tilsynsmyndighet for personopplysningsloven og GDPR.

Og den ansvarsfordelingen har ikke fungert.

For etter Planet 49-dommen fra 2019, har det ikke egentlig skjedd noen endring i ekomloven. Vi har fortsatt de samme reglene, og veiledningen fra Nasjonal kommunikasjonsmyndighet er ikke veldig tydelig.

Forslag til ny ekomlov, men usikkert når den trer i kraft

Men, i 2021 ble et forslag til ny ekomlov sendt på høring.

Lovforslaget inneholdt et forslag til ny ekomlov § 3-7 om at et cookie-samtykke må være en frivillig, spesifikk, informert og utvetydig viljesytring.

Forslaget går ut på at samtykke bare kan gis gjennom innstillinger i nettleseren (slik det er ok å gjøre i dag ifølge Nasjonal kommunikasjonsmyndighet) hvis du som bruker selv aktivt gir samtykke.

Altså de samme kravene som etter GDPR!

Men vi er nå i 2023, og vi har ikke en ny ekomlov. Jeg har ikke klart å finne om lovforslaget har vært behandlet i Stortinget, eller når loven eventuelt trer i kraft.

Så foreløpig er dette med cookies og samtykke et rart eksempel der vi i Norge har forskjellige regler fra hele resten av EU fordi vi er et EØS-land og har valgt å ikke prioritere justering på bakgrunn av Planet 49-dommen.

Denne bloggposten er basert på nyhetsbrevet mitt om personvern. Driver du med personvern og kunne tenke deg støtte i form av et ukentlig nyhetsbrev? Meld deg på her!

Disclaimer: No AI Training Use

All content on this blog, including text, images, and other materials, is the intellectual property of the author unless otherwise stated. This content may not be used, copied, stored, or processed in any way for the purpose of training artificial intelligence or machine learning models, including but not limited to large language models (LLMs), without explicit, written permission from the author.

Hva er egentlig forskjellen på personvern og informasjonssikkerhet?

Photo by Franck on Unsplash.

Du har kanskje møtt på dette spørsmålet når du har gjort en DPIA? For hva skiller den egentlig fra en ROS? Og hvilke uønskede hendelser hører hjemme i en DPIA, mens hvilke skal du flytte til en ROS?

Dette er et spørsmål som ofte kommer opp når jeg gjør DPIAer. Og det handler nok om at personvern og informasjonssikkerhet glir mye over i hverandre.

Informasjonsikkerhetsprinsippene (konfidensialitet, integritet og tilgjengelighet) er jo f.eks. en del av personvernprinsippene i GDPR.

Og personopplysninger er jo en informasjonstype man kan prøve å sikre med informasjonsikkerhetsmetodikk.

Hva sier lærerboka?

Det finnes mange definisjoner på dette, og det jeg kommer med her er ikke en absolutt fasit.

Men i The Architecture of Privacy av Bowman, Gesher, Grabt & Slate, foreslår de denne formuleringen som en forklaring på forskjellen mellom personvern og informasjonssikkerhet:

«Designing privacy protections is about limiting harm by authorized users - those that have been explicitly granted access to the data for some purpose.

But what about unautorized access to data? All the privacy controls in the world are meaningsless of they can be circumventee from the start.

Information security, therefore, is about limiting unauthorized access to data, and is fundametal to building a privacy protective system.»

Kort fortalt: Personvern handler om å beskytte mot at folk som har tilgang til systemet ditt ikke gjør personvernbrudd (interne trusler), mens informasjonssikkerhet handler om å beskytte mot at uvedkommende ikke skal få tilgang (eksterne trusler).

Hvorfor er dette relevant?

Jo, det kan noen ganger være vanskelig å skille mellom de uønskede hendelsene som skal vurderes i en DPIA, og de som skal vurderes i en ROS.

I vår europriske kontekst vil det også være relevant å ta med uønskede hendelser knyttet til oppfyllelse av den registrertes rettigheter og friheter i en DPIA, og det dekkes naturlig nok ikke av den amerikanske definisjonen ovenfor. 

Og så ER jo informasjonssikkerhet også en del av GDPR og noe Datatilsynet VIL gi bøter for hvis personopplysninger kommer på avveie…

Og det betyr at det alltid vil være overlapp mellom de risikosecnarioene du tar med i en DPIA og de du legger over i en ROS. Og det tror jeg betyr at svaret på hvilke scenarioer som skal hvor, irriterende nok beror på en «konkret helhetsvurderingvurdering»

Denne bloggposten er basert på nyhetsbrevet mitt om personvern. Driver du med personvern og kunne tenke deg støtte i form av et ukentlig nyhetsbrev? Meld deg på her!

Disclaimer: No AI Training Use

All content on this blog, including text, images, and other materials, is the intellectual property of the author unless otherwise stated. This content may not be used, copied, stored, or processed in any way for the purpose of training artificial intelligence or machine learning models, including but not limited to large language models (LLMs), without explicit, written permission from the author.

Barn er en «sårbar gruppe» i personvernsammenheng, men hva betyr det?

Photo by Piron Guillaume on Unsplash.

Det at barn er en «sårbar gruppe» i personvernsammenheng, betyr blant annet at de trenger særlig beskyttelse. Denne bloggposten handler om hvorfor det er slik, og hvordan det ser ut i praksis.

Sårbar gruppe

Den største og viktigste grunnen til at barn nyter et særlig vern etter personvernlovgivningen vår, er at de ikke er veldig gode på konsekvenstenking.

Og dette er ikke en «diss» av mennesker under 18. Det er allerede vanskelig nok for oss over 18 å vurdere risikoer og konsekvenser ved at noen behandler personopplysningene våre, at det ville være uforholdsmessig strengt å forvente at barn skal kunne gjøre det.

Det er også vanskelig for barn og sette seg inn i hvilke rettigheter de har etter personvernlovgivningen, og hvordan gå frem for å håndheve dem. Igjen tenker jeg på oss voksne som heller ikke alltid vet hvilke rettigheter vi har eller hvordan håndheve dem. Og da er det ganske urealistisk å forvente at barn skal kunne håndheve egne personvernrettigheter.

Dette betyr at vi som behandler barns personopplysninger har et spesielt ansvar for å ivareta barns personvern og ta personvernvennlige valg på deres vegne.

Hva betyr det å «ivareta barns personvern» eller å «ta personvernvennlige valg på deres vegne»? Hvordan kan de se ut?

Ivaretagelse av informasjonsplikten på en måte et barn forstår

Retten til informasjon fremheves stadig vekk av Datatilsynet som en av de mest grunnleggende personvernrettighetene vi har. Dette fordi den er en forutsetning for å kunne gjøre gjeldende alle andre rettigheter etter personvernlovgivningen.

Og overfor barn er fortalen veldig klar på hva det vil si at barn skal ha et ekstra vern:

«Ettersom barn fortjener et særlig vern, bør all informasjon og kommunikasjon, dersom behandlingen gjelder barn, være formulert på et klart og enkelt språk som barnet lett kan forstå»

Retten til å bli glemt gjelder særlig når behandlingsgrunnlaget var samtykke og ble innhentet da den registrerte var barn

Retten til å bli glemt betyr at du kan kreve at personopplysninger om deg slettes. Dette er særlig aktuelt når det ikke lenger er nødvendig å behandle dine personopplysninger for å oppfylle formålet med behandlingen.

Men denne retten er også særlig aktuell hvis noen behandlet dine personopplysninger da du var barn.

La oss si at foreldrene dine samtykket til at bildet ditt ble brukt i kommunen din sitt kommunikasjonsarbeid for å promotere kommunen da du var 6 år. Nå er du 18, og kommunen bruker fortsatt ditt bilde til promotering. Du er ikke lenger veldig gira på å fortsatt være kommunens ansikt utad.

Fortalen til GDPR sier at du kan kreve at kommunen stopper å bruke bildet ditt, og at de sletter det fra hjemmesiden sin.

Helt så tydelig står det ikke i fortalen. Den sier at retten til å bli glemt «er særlig relevant når den registrerte har gitt sitt samtykke som barn og ikke har fullstendig kjennskap til risikoene forbundet med behandlingen, og senere ønsker å fjerne slike personopplysninger, særlig på internett»

Og det går etter min mening ut på det samme!

Denne bloggposten er basert på nyhetsbrevet mitt om personvern. Driver du med personvern og kunne tenke deg støtte i form av et ukentlig nyhetsbrev? Meld deg på her!

Disclaimer: No AI Training Use

All content on this blog, including text, images, and other materials, is the intellectual property of the author unless otherwise stated. This content may not be used, copied, stored, or processed in any way for the purpose of training artificial intelligence or machine learning models, including but not limited to large language models (LLMs), without explicit, written permission from the author.

Hvordan kan du begrunne det at du må overvåke eget nettverk eller iverksette andre tiltak som innebærer behandling av personopplysninger av sikkerhetshensyn? Fortalen oppstiller en løsning!

Photo by Miłosz Klinowski on Unsplash.

Du er en virksomhet i 2023, og det betyr at du må beskytte deg mot IT-trusler. F.eks. må du hindre ulovlig tilgang til elektroniske kommunikasjonsnett, spredning av skadelige koder, du må kunne forhindre «tjenestenektangrep» og stoppe skade på dine datasystemer og elektroniske kommunikasjonssystemer.

Et av tiltakene kan være sikkerhetslogging eller annen type overvåkning av nettrafikken din. Og det betyr at du også fort behandler personopplysninger for sikkerhetsformål.

Hva kan være behandlingsgrunnlaget for det? La meg presentere to alternativer:

1 Berettigede interesser

Fortalen sier i punkt 49 at det å behandle personopplysninger for sikkerhetsformål, utgjør en berettiget interesse.

Dette forutsetter at de tiltakene du iverksetter for å ivareta informasjonssikkerheten er nødvendige og forholdsmessige ut ifra det du ønsker å oppnå. Det setter noen skranker for de sikkerhetstiltakene du kan iverksette, men det betyr også at du som behandlingsansvarlig har stor frihet til å vurdere treffende tiltak selv. 

Og ja, det fremgår direkte av fortalen at også offentlig myndighet kan bruke berettigede interesser som behandlingsgrunnlag her.

Det har nok å gjøre med at «sikkerhetsformål» slik vi forstår dem her, ikke er knyttet til offentlig myndighetsutøvelse. Dette er behandling av personopplysninger som enhver virksomhet må gjøre for å sikre seg selv fra IT-trusler.

2 Artikkel 6(1)c) eller 6(1)e) og GDPR artikkel 32 som supplerende rettsgrunnlag (eller annet relevant regelverk som pålegger deg sikkerhetstiltak)

Der jeg kan, liker jeg å vise til rettslig forpliktelse i GDPR artikkel 6 (1) bokstac c) eller oppgave i almennhetens interesse i GDPR artikkel 6 (1) bokstav e) - alt ettersom hvor tydelig sikkerhetspålegget ditt er i det supplerende rettsgrunnlaget.

Bakdelen med det er at det ikke bare holder å vise til rettslig forpliktelse eller oppgave i almennhetens interesse, du må kunne vise til en konkret lovpålagt forpliktelse aka en bestemmelse, helst i lov eller forskrift som pålegger deg å jobbe risikobasert.

Heldigvis finnes det flere slike lover og forskrifter.

Noen behandlingsansvarlige er bundet av sikkerhetsloven, den inneholder krav til å iverksette sikkerhetstiltak ut ifra risiko. Mens andre kan være bundet av eForvaltningsforskriften eller pasientjournalloven.

Det finnes sikkert spesiallovgivning i andre sektorer, finanssektoren f.eks, men jeg kjenner ikke konkret til de bestemmelsene.

Og om du ikke finner supplerende nasjonal lovgivning, pleier jeg å bruke artikkel 32! Den er generell, og samtidig en forpliktelse som er så konkret at den pålegger deg som behandlingsansvarlig å iverksette risikoreduserende tiltak ut i fra de faktiske forholdene du må forholde deg til.

Ps. Jeg har lest mye i fortalen i det siste. Det er en del av jobben jeg gjør når jeg skal holde meg oppdatert faglig. Og det betyr ikke bare å lese om nye ting, det betyr også å gå tilbake til de mer grunnleggende kildene. Som fortalen!

Denne bloggposten er basert på nyhetsbrevet mitt om personvern. Driver du med personvern og kunne tenke deg støtte i form av et ukentlig nyhetsbrev? Meld deg på her!

Disclaimer: No AI Training Use

All content on this blog, including text, images, and other materials, is the intellectual property of the author unless otherwise stated. This content may not be used, copied, stored, or processed in any way for the purpose of training artificial intelligence or machine learning models, including but not limited to large language models (LLMs), without explicit, written permission from the author.

Upopulær mening: navnet ditt er en særlig kategori personopplysning

Photo by Tim Mossholder Unsplash.

Du vet at en tilsynelatende uskyldig personopplysning om deg, kan avsløre noe mye mer sensitivt enn personopplysningen i seg selv skulle tilsi.

For ganske nøyaktig ett år siden, fikk vi en dom fra EU-domstolen som slo fast noe mange av oss har visst lenge: at navnet på din romantiske partner, kan si noe om kjønnet til vedkommende, og også indikerer din seksuelle orientering.

Du finner dommen her: https://curia.europa.eu/juris/document/document.jsf?text=&docid=263721&pageIndex=0&doclang=en&mode=lst&dir=&occ=first&part=1&cid=1884161

Men kan en så alminnelig personopplysning som ditt eget navn være en særlig kategori av personopplysninger?

Storytime!

En dag da Harvard-professor Latanya Sweeney skulle søke opp en vitenskapelig artikkel hun hadde skrevet, og Googlet sitt eget navn, la hun merke til at hun fikk opp reklame som insinuerte at hun hadde et rulleblad. Google viste nemlig annonser til firmaer som ville vise hva hun hadde vært straffet for til den som søkte opp navnet hennes, for en pris.

Problemet var bare at Sweeney ikke hadde noe rulleblad. Hun er en data-scentist, og hun hadde tidligere forsket på hvor enkelt det er å re-identifisere amerikanere ut ifra noen ganske få og tilsynelatende uskyldige personopplysninger.

Faktisk var det Sweeney som hadde identifisert guvernøren i Massachusetts sin medisinske diagnose og hvilke legemidler han hadde fått tilskrevet, fra tilsynelatende anononymiserte data. Dette klarte hun ved å sammenligne to forskjellige datasett.

Hun er også hjernen bak den nå beviste hypotesen om at 87% av alle amerikanere kan identifiseres hvis du har følgende tre opplysninger om dem: navn, fødselsdato og postnummer (zip-code).

Sweeney ble nysgjerrig på hvorfor hun fikk servert en annonse som indikerte at hun var kriminell. Så hun startet å utforske hvilke annonser som dukket opp hvis hun søkte på forskjellige navn i Google. Etter å ha gjort dette en stund, satt hun igjen med et inntrykk av at søk på navn som ofte blir gitt til svarte amerikanere, oftere ville vise reklame for også få tilgang til rullebladet deres.

Sweeney er også en svart amerikaner. Fornavnet hennes, Latanya, er også et tradisjonelt «svart» navn. Det faglige var plutselig blitt personlig.

Så hva fant hun?

Hva var de faglige konklusjonene etter at hun hadde forsket nærmere på typiske svarte og typiske hvite navn i USA? Var de forskjellige navnene assosiert med ulike typer reklame når man søkte opp navnet i Google?

Ja, det korte svaret er ja. Eller for å bruke Sweeneys egne ord:

“80 percent of the time, if your name was given more often to a Black baby than a white baby, you would get an ad implying you had an arrest record, even if you did not.”

Hun fant også at amerikanske fornavn er en god indikator på om du er en svart eller hvit amerikaner.

Kilde: https://www.hks.harvard.edu/faculty-research/policy-topics/science-technology-data/qa-latanya-sweeney-how-chance-encounters

Hva betyr dette for deg?

At navnet ditt er en god indikator på din etniske tilhørighet, og dermed er en særlig kategori personopplysning.

Jammen Ida, det kan du da ikke mene! Vet du hvilke konsekvenser en slik forståelse vil få? Da er det jo i utgangspunktet forbudt å behandle navn med mindre du finner et behandlingsgrunnlag i artikkel 9! Det er ALT FOR mye stress!

Ja, jeg VET det er stress. Jeg jobber med personvern hver dag, jeg skjønner hva det betyr å si at noe er en særlig kategori av personopplysninger.

Men jeg ser heller ikke noe annet godt argument for å si at navn IKKE er en særlig kategori, enn at det er stress.

For tar jeg feil? Sånn helt ærlig? Hvis forskning viser at vi navnet ditt kan fortelle meg om din etniske opprinnelse, skal det virkelig ikke være en særlig kategori personopplysning?

Ps. Navnet mitt sier forskjellige ting om meg etter hvilket land jeg bor i. Når jeg bor i Norge, forteller det at jeg heter Ida at jeg er en kvinne som mest sannsynlig er født på slutten av 80-tallet eller begynnelsen av 90-tallet.

Mens når jeg bor i USA eller Frankrike, indikerer navnet mitt at jeg er en kvinne på godt over 80 år, og kanskje av tysk avstamning.

Denne bloggposten er basert på nyhetsbrevet mitt om personvern. Driver du med personvern og kunne tenke deg støtte i form av et ukentlig nyhetsbrev? Meld deg på her!

Disclaimer: No AI Training Use

All content on this blog, including text, images, and other materials, is the intellectual property of the author unless otherwise stated. This content may not be used, copied, stored, or processed in any way for the purpose of training artificial intelligence or machine learning models, including but not limited to large language models (LLMs), without explicit, written permission from the author.

Å 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.

Denne bloggposten er basert på nyhetsbrevet mitt om personvern. Driver du med personvern og kunne tenke deg støtte i form av et ukentlig nyhetsbrev? Meld deg på her!

Disclaimer: No AI Training Use

All content on this blog, including text, images, and other materials, is the intellectual property of the author unless otherwise stated. This content may not be used, copied, stored, or processed in any way for the purpose of training artificial intelligence or machine learning models, including but not limited to large language models (LLMs), without explicit, written permission from the author.

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.

Denne bloggposten er basert på nyhetsbrevet mitt om personvern. Driver du med personvern og kunne tenke deg støtte i form av et ukentlig nyhetsbrev? Meld deg på her!

Disclaimer: No AI Training Use

All content on this blog, including text, images, and other materials, is the intellectual property of the author unless otherwise stated. This content may not be used, copied, stored, or processed in any way for the purpose of training artificial intelligence or machine learning models, including but not limited to large language models (LLMs), without explicit, written permission from the author.