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!
Hvordan begrunne overvåkning av egne nettverk? Vi snakker behandlingsgrunnlag!
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
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.
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
Å 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
Metode for vurdere personvernkonsekvenser i en 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.