UTVIKLING

Hva betyr GDPR for oss som lager IT-løsninger?

Fra 25. mai 2018 trer den nye personvernforordningen GDPR i kraft i Norge og EU. Dette gir store utfordringer for oss som utvikler IT-løsninger, skriver seniorkonsulent og skribent Bjørn Stærk i denne kronikken.

Web Programming Workstation. Website Developer Concept. Internet and Marketing.
Web Programming Workstation. Website Developer Concept. Internet and Marketing. Bilde: All Rights Reserved.
Bjørn Stærk, Vivende
25. okt. 2017 - 09:32
Bjørn Stærk, seniorkonsulent i Vivende og skribent. <i>Foto:  Privat</i>
Bjørn Stærk, seniorkonsulent i Vivende og skribent. Foto:  Privat

Kort sagt gir GDPR europeere en lang rekke rettigheter når noen vil lagre informasjon om oss: Rett til å vite hva som blir lagret, rett til å gi samtykke før det brukes ut over det som er strengt nødvendig, rett til å korrigere informasjon, rett til å bli glemt, rett til å ta med seg dataene sine, og til å ikke bli automatisk profilert. Mye av dette har vi i Norge allerede, men GDPR strammer inn ytterligere, og legger mer makt bak kravene.

Jeg har skrevet en artikkel i Aftenposten om hva dette betyr for oss som brukere og borgere.

Her vil jeg snakke om noe annet: Hva betyr dette for oss som lager IT-løsninger? I første runde betyr det frykt, kaos og stress. 

Frykt

Frykt, fordi de som ikke følger GDPR kan bli pålagt å fikse systemene sine, og i verste fall få store bøter eller bli saksøkt. Det finnes ingen overgangsperiode hvor vi slipper unna med mildere krav mens vi febrilsk leter etter en utvikler som forstår den gamle VB6-løsningen som har surret og gått i kjelleren siden 1998. Kravene gjelder fra 25. mai. Det eneste lyspunktet er at Datatilsynet nok vil slå ned på de verste overgriperne først, altså de som har lagret mest persondata og gjør minst for å overholde loven. Det er forhåpentligvis ikke deg.

Kaos

Kaos, fordi mye av dette er nytt. Mye er også gammelt, men har ikke blitt tatt på alvor. Kanskje skulle du allerede ha bedt om samtykke for opplysningene du bruker. Alle får et stort løft, og ingen vet helt hva det innebærer. Mange har ikke oversikt over alle persondataene sine. Datamodellene er kanskje ikke dokumentert. Persondata lekker ut i logger og backuper. Tenk for eksempel på besøksloggen til et nettsted, som logger IP-adresse, tidspunkt og hvilken side som ble besøkt. Hvis IP-adressen er personlig, så er den persondata – selv om vi ikke vet navnet på personen. Da er også besøket på nettsiden persondata.

Stress

Stress, fordi det er kort tid igjen, og mange løsninger å grave i. Men dette er ingen unnskyldning for å utsette jobben. De som har begynt vil slippe lettere unna enn de som ikke har det.

Tips #1 : Skaff deg oversikt og lag en plan

Det første skrittet er å få oversikt over alle persondataene vi har i gamle systemer, og legge en plan for hvordan disse kan håndteres lovlig. For hver personopplysning har vi, forenklet, tre muligheter:

  1. Det er essensielt å lagre den, for eksempel fordi en annen lov krever det, eller det er helt nødvendig. En nettbutikk trenger å vite adressen den skal sende varen til. Men likevel må kunden kunne håndheve rettighetene sine. De må kunne vite at vi vet dette. Og selv om det er greit å lagre opplysningen, er det neppe greit å lagre den i all evighet. Personopplysningen må få en utløpsdato, hvor den slettes, pseudonymiseres eller anonymiseres.
  2. Det er ikke essensielt å lagre den, men nyttig likevel. Da må brukeren aktivt gi samtykke før vi lagrer og bruker opplysningen. Samtykket kan ikke gjemmes bort i en lang tekst på advokatspråk, vi må på klart og forståelig norsk spørre om det er greit at vi bruker opplysningen til et spesifikt formå Hvis vi finner et nytt formål å bruke det til må vi få et nytt samtykke. Samtykket må kunne kreves tilbake med umiddelbar virkning.
  3. Det er hverken essensielt eller nyttig å lagre opplysningen. Da er det best å bli kvitt den. Det er ikke verdt bryderiet å ta vare på personopplysninger som ikke er nyttige.

Dette er en forenkling av noe som til syvende og sist er et juridisk spørsmål. I tvilstilfeller vil man trenge juridisk ekspertise, og siden mye av dette er nytt vil det være mange tvilstilfeller.

Tips #2: Pseudonymiser og anonymiser

Kravene til håndtering av personopplysninger blir mildere desto mer anonyme opplysningene er.

Det første man kan gjøre er å pseudonymisere dataene. Da gjør vi dataene mindre identifiserende, for eksempel ved å bytte ut navnet ditt med et token, og lagre koblingen i et adskilt system, eller ved å hashe data. Kravene til pseudonyme data er mildere.

Det neste steget er å anonymisere dataene, for eksempel ved å innføre støy eller aggregere dataene. Anonyme data kan man i teorien gjøre hva man vil med. Men anonymisering er vanskelig. Hvis en angriper får tak i tilstrekkelig med data kan de utlede at det handler om deg, selv om dataene tilsynelatende er anonyme, aggregerte, og fulle av støy.

Tips #3: Lagre mindre data

Det blir tungvint å sitte på personopplysninger. Du får krav til dokumentasjon og sikkerhet. Du må utvikle grensesnitt hvor brukeren kan håndheve rettighetene sine, eller gjøre en innsats for å pseudonymisere og anonymisere data.

Artikkelen fortsetter etter annonsen
annonse
Innovasjon Norge
Store muligheter for norsk design i USA
Store muligheter for norsk design i USA

Du vil helst slippe, hvis du ikke må. Dette er også hensikten. Den dagen noen stjeler databasen din blir skaden mindre hvis du har lagret lite persondata enn hvis du har lagret mye.

Tips #4 : Tenk personvern fra starten

Verst blir dette for de som jobber på gamle systemer, hvor det er vanskelig å oppfylle kravene.

De som utvikler nye løsninger får det lettere. Datatilsynet har laget en veileder for programvareutvikling med innebygd personvern som viser hvordan IT-prosjekter kan bake inn personvern i alle faser av prosjektet. Et av de viktigste kapitlene er om designfasen, hvor de viktigste personvernbeslutningene tas.

Datatilsynet skriver også at prosjektet må ha et gjennomtenkt forhold til hvilke verktøy det bruker, og legge ned forbud mot utrygge komponenter. Man bør drive manuell og automatisk kodeanalyse, med spesiell vekt på alt som har med personopplysninger å gjøre.

Tips #5 : En personvernspesialist i hvert IT-prosjekt

Dette betyr ikke at alle utviklere må bli personvernspesialister, men prosjekter bør ha en spesialist tilgjengelig, og alle må kunne noe. Minimum må vi kunne nok til å vite om prosjektet vårt er berørt eller ikke.

Det blir stress og kaos i begynnelsen, men til gjengjeld kan vi gjøre jobben vår med bedre samvittighet enn før. Vi vet alle at persondata flyter rundt, og at prosjektene sjelden prioriterer å få kontroll på det. Nå vil de forhåpentligvis gjøre det, og det er en god ting.

Siden mye av GDPR allerede er omfattet av norsk personvernlovgivning, men blir ignorert av mange, spør noen om det vil gå likt med de nye reglene. Det kommer an på hvordan myndighetene følger dem opp. Vi IT-folk tenker lett at kode står over loven. Vi har vært bortskjemt med at mye av det vi gjør er så nytt at lovverket ikke henger med. Men loven kommer etter, og tar oss alltid igjen til slutt. Man skal være bra modig for å satse forretningsmodellen sin på at staten ikke gidder å bøtelegge lovbrytere.

I tillegg til Datatilsynets nettsider kan de som vil lære mer om GDPR starte med følgende videoer: 

Forfatter: Bjørn Stærk, senior konsulent i Vivende og skribent

Del
Kommentarer:
Du kan kommentere under fullt navn eller med kallenavn. Bruk BankID for automatisk oppretting av brukerkonto.