Dersom du jobber med programvareutvikling som utvikler, leder eller tester, vil du bli påvirket av den nye personvernforordningen (GDPR – general data protection regulation) fra EU. Men GDPR byr på mange overraskelser – og potensielt mange gevinster.
På mange måter vil lovverket GDPR ha større påvirkning enn Y2K, år 2000-problemet, og du kan ikke ignorere reglene ettersom bøtene som ligger i lovverket, kan knekke ryggen på en organisasjon. Men denne gangen gjøres endringene av gode grunner.
Da jeg først ble oppmerksom på forordningen, opplevde jeg den som forvirrende og skremmende, og jeg har forstått at mange føler det slik. I denne artikkelen forsøker jeg å bøte på dette.
Først og fremst: Hvordan forholder jeg meg til selve lovteksten? Jeg vil gå gjennom noen konkrete ting du kan starte med.
Da jeg først satte meg ned og startet å lese lovteksten, syntes jeg den var overraskende velskrevet, men jeg skulle ønske jeg hadde hatt et kart over hvordan jeg skulle angripe teksten. Den offisielle teksten er publisert som en PDF med veldig liten font på http://ec.europa.eu, og en norsk oversettelse er ute til høring. Lovteksten starter med 173 «betraktninger» («recitals» på engelsk) som belyser bakgrunnen for forordningen. Selv om disse inneholder veldig gode betraktninger, så er de ikke veldig konkrete, og de har lange setninger og litt tungt språk (ta en titt på Recital 38 som omhandler barns rettigheter som et eksempel). Etter betraktningene kommer de 99 artiklene som utgjør selve regelverket. Disse er mye enklere å forholde seg til og lese. De er delt opp kapitler hvor de siste kapitlene for det meste omhandler institusjonene som skal håndheve regelverket. Dette er ikke essensielt for de fleste.
I stedet for å lese PDF-dokumentet, anbefaler jeg at du bruker en hyperlinket fremstilling av forordningen. Denne siden organiserer lovteksten på web på en måte der strukturen i lovteksten kommer tydelig frem. Dersom du er ansvarlig for et IT-system, bør du lese artikkel 1 til 50, med spesielt fokus på artikkel 5 til 35. Start her.
La oss ta en titt på noen momenter ved regelverket som kan overraske deg.
Overraskelse #1: Samtykke og testdata
For å ha lov til å samle inn og behandle persondata må du ha et lovlig grunnlag for dette (artikkel 6). For de fleste betyr dette enten at lov eller forskrift pålegger deg å behandle informasjonen (for eksempel i helsesektoren), at du har innhentet samtykke fra den registrerte, eller at dataene er en nødvendig forutsetning for å levere en tjeneste den registrerte bestiller. Dette har vært tilfelle med dagens personvernlov, men forordningen setter mer spesifikke krav til samtykke: Et samtykke må være frivillig, spesifikt, aktivt og utvetydig.
Et vanlig scenario er at organisasjoner benytter produksjonsdata fra sine kunder som hovedkilde for testdata for nye versjoner av systemet. Dette bør du glemme nå. Du kan be kundene dine om samtykke til å benytte deres data for å understøtte vedlikehold og forvaltning av løsningen, men du kan ikke kreve dette samtykket for å behandle kunden. Du må gjøre samtykket valgfritt og ikke-standard. Så det betyr at du i beste fall trenger å kunne splitte ut testdata fra kunder som har gitt samtykke, fra kunder som ikke har gitt samtykke. Lykke til! Du har også mulighet til å anonymisere data, men du kan ha brutt loven dersom det er en risiko for reidentifisering. (Det er mulig, men gjenstand for diskusjon, at man kan påberope seg «berettiget interesse» for noe testing med produksjonsdata.)
I stedet vil jeg anbefale at du investerer i andre teststrategier. Spesielt tror jeg at testorganisasjoner bør bli flinkere til å skape syntetiske testdata. Syntetiske testdata kan også hjelpe til å gjennomføre stresstester av store volumer og uvanlige verdier. En annen testmetode er å sette en ny versjon ut i produksjon til et kontrollert subset av brukerne og gradvis slippe på flere brukere.
Denne type teknikker vil kunne forbedre leveransesyklusen deres generelt. Nå har dere en god unnskyldning for å gjøre investeringen i bedre test!
Overraskelse #2: Funksjonalitet for å understøtte den registrertes rettigheter, inkludert dataportabilitet
Dersom du samler inn persondata, må du planlegge å utvikle funksjonalitet eller rutiner for at den registrerte kan utføre sine rettigheter. Mange av kravene gjelder også under personvernloven, men den registrertes rettigheter har blitt styrket. I lovteksten er dette omhandlet i artikkel 12 til 23. Bare ta hver artikkel og putt det på din produkt-backlog som funksjonalitet, eller som rutiner som må utvikles. Du må la dine kunder se hvilke data du lagrer om dem, inkludert hvem som har hatt / vil få tilgang til denne dataen. De må kunne korrigere feil i dataene og kreve at dataene skal slettes.
En ny og veldig spennende rettighet er retten til dataportabilitet (artikkel 20). Kundene dine har rett til å eksportere data fra deg og ta det med til dine konkurrenter i et portabelt format («strukturert, alminnelig anvendt og maskinleselig format»). Slik jeg tolker det: Dersom kundene dine kan eksportere en fil i JSON-, XML- eller CSV-format med alle data som omhandler dem, så er det ok. Om du lurer: PDF er garantert ikke bra nok.
Dataportabilitet er en av de tøffeste tingene med GDPR, og det ser ut til å være begrunnet i et ønske om å understøtte innovasjon. Bare tenk på mulighetene! Tenk deg en app som lar deg importere kjøpshistorikken din fra alle butikkjeder og lar deg analysere dine egne kjøpsvaner. Dette er et eksempel jeg har drømt om lenge, men dataene var låst inne og utilgjengelige for meg. Inntil nå!
Eller som bedrift kan du bruke denne retten til å holde konkurrentene dine ærlige! Gi kundene dine bonuser eller premier for å gi samtykke til at du kan bruke deres data fra dine konkurrenter. Du må være forberedt på at kundene dine må kunne trekke tilbake samtykket, men du kan fortsatt beholde aggregerte data. Og dersom konkurrentene dine ikke tar forordningen alvorlig, har du nå mulighet til å tenne et bål under føttene deres!
Overraskelse #3: Sikring av data under transport og lagring – overalt!
Det siste momentet jeg vil ta opp som kommer fra personvernforordningen er kravet om å holde persondata sikre og under kontroll (artikkel 32 – se også artikkel 25 som krever innebygget personvern). Du er lovpålagt å beskytte data under transport og lagring i henhold til den teknologiske utviklingen. Du er også påkrevd å informere Datatilsynet (i Norge) dersom du oppdager et sikkerhetsbrudd.
En viktig aksjon for alle organisasjoner er å kartlegge hvor du lagrer og overfører persondata. Har du kontroll på mellomlagring? På backups? På logger? Overfører du data til tredjepart eller eksterne systemer? Har du kontroll på hvordan de behandler dataene?
De fleste organisasjoner har mindre tilgangskontroll på applikasjonslogger enn på annen data. Og ofte logger man uten å vurdere innholdet av det som logges. Jeg pleide å logge alt innhold av meldinger som går ut og inn av systemene i applikasjonslogger. Dette kan bli problematisk.
Den enkleste måten å beskytte data på er å aldri samle den inn i første omgang. Den nest beste måten er å unngå å lagre den unødig. Du er nødt til å spore hver personopplysning du samler inn gjennom alle dine systemer, og finne ut hvem som har tilgang til den. Dersom du samler inn mindre, blir jobben enklere.
Tre konkrete tips for GDPR
Det er flere problemstillinger i personvernforordningen GDPR enn de jeg har nevnt i denne artikkelen. Spesielt inneholder personvernombudrollen noen overraskelser.
Formålet med denne artikkelen er å gi IT-organisasjoner en pekepinn om hvor de kan begynne. Det er stor sjanse for at du har en jobb foran deg, men du kan også hente ut noen gevinster.
Her er tre konkrete forslag:
- Utvikle nye testrutiner som unngår bruk av produksjonsdata.
- Legg til utviklingsoppgaver for å støtte den registrertes rettigheter i planen – start gjerne med dataportabilitet (og tenk på hvordan du kan benytte deg av konkurrenters data).
- Analyser flyten av personopplysninger gjennom systemet med spesielt blikk på usikrede lagringsplasser som logger og midlertidige filer.
Det er ikke lenge til personvernforordningen trer i kraft, og du må bli klar nå! De tre områdene jeg beskriver, viser deg de fleste stedene IT-systemer berøres av forordningen, og er et godt grunnlag for å forstå, implementere og dra fordel av våre alles nye rettigheter som borgere og individer.
Dette innlegget var først på trykk i Digi.no 4. oktober