EU:n tietosuoja-asetus GDPR edellyttää organisaatioilta varsin tarkkaa tietoa siitä, mitä kaikkia henkilötietoja käsitellään, kuinka kauan ja millä perusteella sekä missä tiedot sijaitsevat. Tämän kaiken selvittäminen on huomattavasti helpompaa, kun kokonaisarkkitehtuuri on käytössä.
Kokonaisarkkitehtuurissa meillä on vähintäänkin inventoituina toiminnan palvelut, toimijat, prosessit, toiminnan tarvitsemat tietoryhmät heidän omalla kielellään ja tietojärjestelmät. Mallinnusvälineissä nämä ovat yleensä kaavioina, joita on helpompi lukea kuin taulukoita. Mistä aloittaa, jos GDPR:ään valmistautumista tehdään arkkitehtuurin avulla?
Henkilötietoja sisältävien tietoryhmien käyttö
Työtä tekevä voi katsoa ensin tietoryhmiä ja tunnistaa sieltä sellaisia, joissa on henkilötietoja. Hän voi aloittaa haastattelemalla toiminnan tuntijoita: ”Käsitelläänkö tässä palvelussa laskutustietoja? Entä asiakastietoja?” Ja merkata vastauksen ylös (kyllä, ei). Hän voi kysyä myös, mihin tiedot tallennetaan tai mistä niitä katsotaan – näin tulevat esiin paitsi järjestelmät, myös levynkulmilla olevat excelit yms. säilytyspaikat. Tässä vaiheessa ei pidä unohtaa henkilöstöhallinnon ja taloushallinnon asiantuntijoita – siellä sitä henkilötietoa vasta liikkuukin.
Tietohallinnon ihmisiltä voi sitten kysyä, missä järjestelmissä näitä samoja tietoja sijaitsee. Ja yllätys, yllätys, esim. asiakastietoja löytyykin monesta eri järjestelmästä… On aivan tyypillistä, että vuosikymmenten aikana on syntynyt eri käyttötarkoituksia varten järjestelmiä, joissa on sitten keskenään osittain päällekkäisiä tietoja.
Tietojen luokittelu tietosuojan ja riskin perusteella
Vaikeimmaksi asiaksi osoittautui tietojen luokittelu tietosuojan perusteella: milloin tiedot ovat julkisia (esim. yritysten yhteyshenkilöt, jotka esiintyvät verkkosivuilla) ja milloin eri tavoin luottamuksellisia – tai peräti arkaluontoisia. Onneksi GDPR antaa arkaluontoisista tiedoista aika hyvän luettelon.
Toinen luokitustapa liittyy riskeihin: kuinka korkea riski on, että henkilötietojen vuotaminen, katoaminen tms. aiheuttaa haittaa kyseiselle henkilölle – ei siis organisaatiolle. Onhan loogista, että henkilötunnuksen ja luottotietojen yhdistelmän katoaminen tai vuotaminen on tosi paha juttu. Pelkän tavallisen Matti Virtasen nimen katoaminen ei välttämättä maata kaada, mutta harvinaisemman nimen kanssa voikin olla eri juttu. Eli esim. kurssin osallistujalistan kierrättäminen luokassa on ihan ok, kunhan siinä ei ole allergioita merkittynä. Eri asia on, jos joku on kieltänyt etukäteen omien tietojensa näyttämisen.
Riskiperustainen lähestymistapa kuvaamiseen
Kun nämä kolme tehtyä asiaa yhdistettiin mallinnusvälineessä, meillä olikin jo aika hyvä tieto siitä, missä palveluissa käytettiin henkilötietoja sisältäviä järjestelmiä ja kuinka luottamuksellisia tiedot olivat. Nyt voitiin keskittyä riskiperustaisesti vain niihin sensitiivisimpiin kohtiin. Ketkä tietoihin pääsevät käsiksi? Ovatko käsittelyprosessit kunnossa? Mihin henkilötietojen käsittely perustuu? Pitääkö jotain korjata tai muuttaa? Ei siis tarvinnut lähteä kuvaamaan kaikkea maan ja taivaan väliltä, vaan voitiin keskittyä oleelliseen.
Uusina prosesseina piti tietysti kuvata tietosuojarikkomuksen ilmoittamisen ja sen käsittelyn prosessit, sillä niitä ei yleensä ole ollut kuvattuina entuudestaan. Samaten piti miettiä, mihin näihin liittyvät tiedot kerätään ja ketkä niihin pääsevät käsiksi.
Jatkuva ylläpito KA:n avulla helpompaa
On hyvä muistaa, että GDPR:ään liittyvät kuvaukset pitää olla jatkuvasti ajan tasalla. Eli jos tulee muutoksia prosesseihin, palveluihin, järjestelmiin jne., kuvaukset tulee päivittää. Jos GDPR-kuvaukset tuli tehtyä exceleihin, niin kannattaa harkita siirtymistä kokonaisarkkitehtuurin käyttöön - sen avulla ylläpito tapahtuu melkein itsestään. Ja onhan meille tulossa ensi vuonna uusi EU-tasoinen ePrivacy-laki. Samoin kansallisen Tietosuojalain voimaantulo voi muuttaa jotakin. Eli ylläpitotarve on jatkuvaa. Jos nyt mallinnusvälineitä ei ole käytössä, niin liittäkää ihmeessä GDPR-kuvaukset osaksi kokonaisarkkitehtuurikuvauksia, missä muodossa ne ovatkin. Näin ne löytyvät ja tulevat päivitetyiksi.
Tätä olemme siis Coalassa tehneet. Jos haluat nähdä ja kuulla tästä lisää, voit käydä kuuntelemassa viime keväänä pidetyn webinaarin Ota GDPR haltuun arkkitehtuurin avulla. GDPR:ään siirtymisen jälkeisestä elämästä kerromme 30.10.2018 webinaarissa Tietosuojaohjelma toimivaksi! – Mitä, eikös GDPR mennyt jo?