Bli GDPR compliant

GDPR är inte svårt för dig som nitiskt och har bejakat ditt – i det här sammanhanget – väl motiverade kontrollbehov. Du har i ditt kontrollbehov inte låtit IT-chefen komma undan med frasen ”klart vi följer PUL” utan denne har varit tvungen att leverera den bevisande dokumentationen. Förtroende är förstås bra, men kontroll är bättre. Nu är det enbart följande nyheter i GDPR som återstår att leva upp till:

Rätten till dataportabilitet, den registrerade ska kunna få ut sin personuppgifter
Rätten att bli glömd, personuppgifter ska kunna tas bort
Alla personuppgifter berörs, oavsett hur dom lagras, även de som förekommer i fritext och på papper
Personuppgiftsincidenter ska anmälas, rutiner måste finnas för att upptäcka och rapportera dem

För er som inte följt PUL nitiskt och kanske saknar lite kontrollbehov så finns mer arbete. Du behöver dokumentera, dokumentera och dokumentera, ta tag i åtgärderna som blir resultatet av dokumentationen och åtgärda nyheterna i GDPR. Här förklaras hur du gör.

Dokumentera verksamheten som berör personuppgifter

Har du inga personuppgifter så berörs du inte av några artiklar i GDPR, inte ens av stora stygga artikel 83. Det et första steget är att fundera över din verksamhet ur ett personuppgiftsperspektiv. Detta gör du genom att sätta organisationen i sitt operativa sammanhang och beskriva hur kommunikationen sker med omvärlden.

Ension har som ett genomgående exempel Lilla Sjukhuset. Sjukhuset är specialiserat och sysslar bara med benbrott.

Man har bara en kund att fakturera, Benförsäkringar AB, och en samarbetspartner, Strålande röntgen. Röntga, gipsa, fakturera är deras melodi, brott lönar sig brukar ekonomiadministratören fru Krona skämtsamt säga! Sjukhuset har ritat följande bild av sitt operativa sammanhang.

Bilden kompletteras med en beskrivning där du berättar hur behandlingen av personuppgifter går till, behandlingens omfattning, sammanhang och ändamål, mottagare av personuppgifter samt vilken rättslig grund du har för att behandla personuppgifterna.

Lilla sjukhuset kan genast konstatera att man både delar och tar emot personuppgifter. Fakturan till Benförsäkringar, behöver den innehålla alla detaljer? Är avtal med patient och försäkringsbolag täckande?

I nästa steg beskriver du vilka register ni har som innehåller personuppgifter samt hur dessa kommunicerar med varandra och omgivningen. Det är mycket viktigt att tänka utanför scoopet IT-system, det kommer visa sig för lilla Sjukhuset senare under informationsriskanalysen. Jobbar du som Lilla Sjukhuset så kommer du upptäcka de missade tillgångarna senare i arbetet, deras modellbaserade arbetssätt gör att det bara är att komplettera modellen vid upptäckten.

Lilla Sjukhuset tog fram följande bild med tillkommande beskrivning

Lilla sjukhuset har gjort livet smidigt, mail från Benero, där man också har sin hemsida. Ekonomisystemet körs i molnet, samma med journalsystem och dokumenten finns på Dropbox.

För varje register beskriver du hur behandlingen av personuppgifter går till, behandlingens omfattning, sammanhang och ändamål m m. Lilla sjukhuset har tagit fram följande inledande beskrivning för ekonomisystemet.

Nu undra du som läsare om Ension verkligen gjort ett bra jobb när de hjälpte Lilla Sjukhuset, det saknas ju fakturahantering för all vård. Detta hanteras i journalsystemet på följande sätt: Herr Simulant söker ofta vård för brutet finger (fru Krona kallar honom Goldfinger), sjukhuset gipsar, från journalsystemet går en faktura till Benförsäkringar och en fakturajournal utan personuppgifter till ekonomisystemet.

Nästa steg är att beskriva varje behandling utifrån de krav GDPR ställer, nedan har Lilla Sjukhuset beskrivit fakturahanteringen.

Rutorna med märkningen <<artifakt>> är referenser till en kravmängd i GDPR, DPIA t ex är den konsekvensanalys som du kan vara tvingad att göra. Som du ser återkommer mycket av informationen på flera sällen i GDPR och det är mycket lönsamt att vara strukturerad i arbetet, att återanvända information i en modell ger effektivitetsvinster.

När Lilla Sjukhuset gjorde analysen kom det upp en hel del frågor, framförallt när det gällde mail och Dropbox. Excelarket med medlemmar i Brottby backhopparförening som syster Berta tänkte använda som marknadsföringsunderlag är också personuppgifter. Sjukhuset identifierade att man både var tvungna att rensa och styra vilken information som ska sparas.

En säkerhetsklassning på register och kommunikation utifrån skyddet av den personliga integriteten är det sista steget i arbetet. Ension har med erfarenhet från flyg, järnväg och medicin med där använder Safety Integrity Level (SIL) skapat en Privacy Integrity Level (PIL) härledd ur GDPR. PIL har som SIL fyra olika nivåer: PIL0 innebär att inga känsliga personuppgifter finns och registret inte berörs av GDPR. PIL3 innebär att känslig information i stora mängder hanteras, t ex de särskilda personuppgifter avseende hälsa m m som definieras i Artikel 9, och GDPR ställer höga krav på behandlingen.

Ekonomisystemet innehåller inga känsliga uppgifter om patienter och berörs inte av Artikel 9. De känsliga personuppgifter som finns är de som berör anställdas löner. Ekonomisystemet bedöms ha PIL1. Journalsystemet innehåller de känsliga personuppgifter som definieras i Artikel 9, dessutom för många individer, registret kategoriseras som PIL2.

Nu har du gjort första steget i dokumentationen, du vet vad du behöver analysera och dokumentera djupare.

Dokumentera säkerheten för personuppgifterna

Nu är det dags för pusselläggande. Du har oftast ett skydd av de personuppgifter du lagrar. Detta skydd skyddar mot risker som någon identifierat. Beskriv för varje register och kommunikation följande:

Behörighets och åtkomststyrning, hur styrs vem som kan och har rätt att ta del av personuppgifter.
Skydd av information, hur skyddas mot obehörig tillgång till, ändring eller förstöring av personuppgifter
Tillgänglighet, hur säkerhetsställs tillgång till uppgifterna för behöriga
Kontroll av åtkomst, hur identifieras att någon obehörig kommit åt personuppgifterna.

Lilla sjukhuset inser direkt att man inte reda ut punkterna 2-4 utan måste kontakta leverantören. Behörighet och åtkomst kan man dock analysera och tar fram följande bild. Det är IT-ansvarige Hacke Hacker som tillsammans med Ension tagit fram bilden.

Det första som händer är att Hacke påpekar att ett användningsfall missats, leverantören administrerar systemet, användningsfallet serveradministration tillkommer. De streckade röda linjerna talar om vem som i vilket användningsfall kommer åt vilken information. IT-specialisten hos leverantören kommer vid serveradministration åt fakturareferens och anställd info.

Nu vet du vad du har tänkt på, nuläget. Nästa steg är att genomföra en riskanalys ur GDPR-perspektiv, vad är det du inte tänkt på, vilka hål finns? Resultatet av en del av riskanalysen, informationsriskanalysen, är incidentscenarior som beskriver hålen som måste täppas till. Så här ser ett ut för Lilla Sjukhuset.

Du behöver sedan täppa till alla hål i ditt skydd genom att först sätta upp säkerhetsmål och säkerhetskrav. Glöm inte att dokumentera argumentationen för varför säkerhetsmålen och säkerhetskraven ger en lämplig säkerhet. Den dokumentationen kommer du ha nytta av senare i arbetet. Vad lämplig är beror enligt GDPR på behandlingens art, omfattning, sammanhang, ändamål samt riskerna du identifierat. Kliver ur din organisation och fundera över vad du skulle ha för krav om någon annan behandlar dina personuppgifter så underlättar det din bedömning.

Identifiera sedan åtgärder som implementerar kraven Åtgärder finns inom fyra kategorier:

Reducering - både konsekvensen av och exponeringen för risken minskas.
Avtal - Avtal för exempelvis genom outsourcing eller försäkring
Undvikande - Möjligheten att ett scenario inträffar undviks, t ex genom att ta bort personuppgifter.
Acceptans - Viss risk är billigare att acceptera än att reducera.

Du prioriterar och genomför åtgärderna så att risken för sanktioner i maj 2018 är så liten som möjligt

Dokumentera beviset för att du följer GDPR.

Nu kommer du till den roliga delen av arbetet, säkerhetsbeviset, det mesta av bevisarbetet är nämligen redan gjort. Ett beprövat sätt att visa säkerheten är Ett Safety Case, en strukturerad argumentation som stöds av bevis för att motivera att ett system är acceptabelt säkert. Bevisen är t ex dokumentation av säkerhetsarbete, systemtester eller granskning av organisationen att säkerhetsåtgärderna fungerar och är implementerade i verksamheten. Argumentationen för att systemet är säker har du dokumenterat när du tidigare identifierade säkerhetsmål och säkerhetskrav.

Ett Safety Case används inom branscher med säkerhetskritiska system som en del av en certifieringsprocess. Certifikat beviljas först när den certifierande myndigheten är nöjd med din argumentation. Här är Safety Caset ditt bevis för att du är GDPR-compliant om du av någon anledning blir granskad av Datainspektionen. Ditt sätt att minimera riskerna för sanktioner enligt artikel 83.