GDPR i praktiken - del 1
Den 25 maj fyllde GDPR ett år och några dagar innan publicerade Datainspektionen sin första nationella integritetsrapport där de konstaterar att: ”Tre av fyra svenskar är oroliga för hur deras personuppgifter används". Samtidigt är det bara hälften av svenska företag och myndigheter som arbetar kontinuerligt och systematiskt med dataskydd. Lagen nämner inte hur system ska byggas eller hur data ska skyddas, utan bara att det ska göras. Hur blir därför en tolkningsfråga och där är det lätt att göra fel. Denna artikel är den första i en artikelserie i tre delar.
Vad innebär GDPR i praktiken?
Det görs ofta feltolkningar, främst på grund av dålig kommunikation mellan jurister och de som hanterar tekniken, vilket kan leda till att man inte sällan bryter mot lagen utan att vara medveten om det. I värsta fall bryter man medvetet mot lagen för man vet inte hur man skall hantera utmaningarna med GDPR. Jag har i flera år jobbat tätt ihop med systemutvecklare, databasexperter, jurister mm och presenterar i denna artikelserie min syn på vad som är viktigt för att skapa GDPR kompatibla system.
Jag hävdar att om man hanterar GDPR-problematiken kommer det oftast att löna sig eftersom vi samtidigt kan rätta till de brister i systemen GDPR problematiken synliggör, varför vi bör se de utgifter som det medför som en investering och inte en kostnad.
De krav som GDPR ställer på våra system kan i många fall ses som ett lackmuspapper som påvisar om systemen är byggda på ”rätt” sätt. GDPR bygger i stora delar på PUL, som röstades igenom 1995. Det är med andra ord svårt att hävda att det inte funnits tillräckligt med tid att rätta till brister. Många företag hanterar GDPR-frågan genom att vänta och se för ”det kommer inte att drabba oss först i alla fall”, men lagen är tämligen klar och är man inte ett jättelitet företag så är det dags att ta tag i frågan och börja agera nu. Jakob Söderbaum, skrev i sin artikel bland annat om hur ett antal stora företag fått mycket höga böter och det är bara en tidsfråga innan det kommer att drabba även mindre företag.
Men det är inte enbart negativt att tvingas ta tag i denna fråga, för det kan samtidigt ses som en chans att betala tillbaka på den tekniska skuld vi har och få mer välbyggda och bättre fungerande system genom att dra nytta av de verktyg och processer som sätts upp för att kunna hantera GDPR.
Hantera data/arkitektur
Enkelt uttryckt är en personuppgift allt som kan identifiera en person, enskilt eller genom att pussla ihop information från flera källor. Skatteverket har en bra artikel om vad en personuppgift är på sin webbplats.
GDPR ställer nedan krav på oss.
Vi behöver veta:
- Varför vi samlar in data
- Vad vi sparat om enskilda personer
- Var uppgifterna är lagrade
- Hur vi använder dem
Vi behöver kunna ge de som personuppgifterna rör möjlighet att:
- Läsa vad som finns om dem
- Rätta felaktigheter
- Dra tillbaka samtycke och därmed bli borttagen ur systemet.
- I vissa fall kan kunden även kräva att uppgifter skall kunna överlämnas till en annan organisation, sk portabilitet.
När vi inte längre har skäl att behålla personuppgifterna så måste de tas bort
- Vill vi ha kvar personuppgifter så behöver de anonymiseras så man inte kan spåra dess ursprung till en specifik person.
När en person begär att få ut uppgifter från alla dessa system och eventuellt begär att data skall rättas eller ta tillbaka medgivande så måste vi ha en process för att se till att det utförs. Det kan vara tekniskt komplicerat då det på grund av andra lagar, såsom bokföringslagen, måste finnas kvar vissa uppgifter. Data som en kund vill ta bort kan även vara mycket värdefull för företaget och kan kanske sparas i en annan form, tex som anonymiserad. För att det i så fall skall vara möjligt är det viktigt att skapa en lösning för det i tid, inte när kunden vill bli borttagen.
Dessa krav påverkar hur ett system byggs/byggs om. Det är därför viktigt att ha en helhetssyn på systemen och dess data. Det är inte ovanligt att personuppgifter är spridda i många system. Dessa kan ligga i såväl den egna serverhallen som i molnlösningar. Data kan även ligga hos leverantörer av en tjänst och i allra värsta fall, ostrukturerat på fildelningsytor, personalens laptops och/eller USB-minnen. Inget av detta behöver vara olagligt i sig, men gör det svårt att uppfylla tidigare nämnda krav. För att göra det extra komplicerat så finns det personuppgifter i utvecklingsmiljöer där det ställs ännu hårdare krav, vilket vi återkommer till i den sista artikeln i denna serie.
Arkitektur
I en artikel är det svårt att skriva vad man ska och inte ska göra då det är många faktorer som skiljer mellan företag och system. Det kommer därför att bli fråga om saker som bör tas hänsyn till vid skapande, ombyggnad och inte minst vid inköp av system. För att kunna hantera GDPR är det viktigt att ha en väl genomtänkt systemarkitektur som gör det enkelt uppfylla dessa krav. I många fall kan det även automatiseras vilket bland andra Facebook gjort. Att automatisera flödet kan vara en stor fördel för att underlätta portabilitet, vilket är ett krav för vissa branscher.
Konsolidera personuppgifter
Uppgiftsminimering samt lagringsminimering är två av de sju grundläggande principerna för att en organisation skall ha rätt (enligt artikel 5 och 6) att behandla personuppgifter. Därför bör dessa lagras på så få platser som möjligt i företagets systempark. Övriga system bör kunna läsa in dessa uppgifter när de behövs, men helst inte lagra dem. Det förenklar skyddet av personuppgifter, och gör det avsevärt enklare att hantera dem när det krävs. Det gör det även enklare att hantera produktionsdata i testmiljöer.
Tänk på att inte använda uppgifter som räknas som personuppgifter som primärnycklar. Detta på grund av att personuppgifter i princip inte får/kan användas i testsyfte och därför måste kunna bytas ut. Personnummer (inklusive, de fyra sista siffrorna) bör heller inte användas för att läsa ut ålder, kön osv. Mer om detta i tredje artikeln.
Kommunikation
Det finns många saker som gör e-post till ett olämpligt verktyg att skicka personuppgifter med. Det är mycket svårt att kontrollera spårbarheten och det är i de flesta fall inte möjligt att garantera att överföringen sker på ett säkert sätt. Man kan inte hävda att e-post är tekniskt olagligt för hantering av personuppgifter men det kan komplicera vårt arbete med att följa lagen. Om man behöver ta emot tex ansökningshandlingar denna väg skall processen vara beskriven och följas. Undvik därför i mesta möjliga mån att skicka uppgifterna i klartext utan dela dem via filer på gemensamma lagringsytor eller system som är avsedda för ändamålet. Detta kan medföra andra utmaningar som man måste vara medveten om, som exempelvis hur säkert personuppgifterna sparas, eller i vilket land data lagras. Om man tagit emot eller skickat personuppgifter via epost bör dessa tas bort och sparas på annan plats, tex i därför avsett system.
Användarupplevelsen
Användarupplevelsen gäller för alla kategorier av användare av systemet och det är lönsamt att tidigt hantera denna fråga. Det är enklare att göra lättanvända system som sparar tid och blir säkrare att använda om man tar in denna kompetens på ett tidigt stadium. Som användare räknas samtliga som hanterar hela eller delar av systemen och deras behov måste alla beaktas. Dvs inte bara de sk slutanvändarna utan även administratörer, systemoperatörer, produktägare osv.
- Det kan krävas utbildning, manualer och hjälptexter för att det skall vara lätt att använda systemet men man bör sträva efter att systemet skall vara självförklarande och feltolerant.
Då uppgifterna kan vara av mycket känslig art så är det viktigt att se till att systemet är så tydligt att det är lätt att göra rätt och svårt att göra fel, bl.a. för att dessa inte skall hamna i händerna på fel personer.
GDPR ställer även hårda krav på skyddet av data vilket jag tar upp i nästa artikel. Personuppgifter är värdefulla data och det kan i vissa fall få ödesdigra konsekvenser om de hamnar i fel händer. Säkerhet är svårt att få till men inte jättesvårt att förstå på ett övergripande plan.
GDPR i praktiken - mer läsning
Detta är första delen i ämnet, men här hittar du även de kommande artiklarna som handlar om hantering av data/arkitektur och del 3 och sista avsnittet som handlar om utvecklings- och testmiljöer.
