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.
Når 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.
Når jeg først satt 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 har lange setninger og litt tungt språk (ta en titt på Recital 38 som omhandler barns rettigheter som et eksempel). Etter betrakningene 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 https://gdpr-info.eu/. 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) eller at du har innhentet samtykke fra den registrerte. Dette har vært tilfelle med dagens Personvernlov, men forordningen setter mer spesifikke krav til samtykke: Blant annet må den som gir samtykke kunne forstå hvordan informasjonen skal brukes. Du må også gjøre det valgfritt å gi samtykke til bruk som ikke er påkrevd for å gi den tjenesten den registrerte ønsker.
Et vanlig scenario er at organisasjoner benytter produksjonsdata fra sine kunder for å teste nye versjoner av systemet. Dette kan 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 i beste fall trenger du å 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.
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 er også tilfelle 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 hvilken data du lagrer om dem, inkludert hvem som har hatt 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 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 la deg analysere dine egne kjøpsvaner. Dette er et eksempel jeg har drømt om lenge, men dataene var låst inne og utilgjengelig 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 sikkert 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 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
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 var å gi IT-organisasjoner en pekepinn på 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 tenkt på hvordan du kan benytte deg av konkurrenters data)
- Analyser flyten av personopplysninger gjennom systemet med spesielt blikk etter 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 ta fordel av våre alles nye rettigheter som borgere og individer.
