GDPR-vaatimusten täyttäminen toiminnan kehittäjänä

Oletettavasti akronyymiä GDPR ei tarvitse kenellekään enempää avata. EU:n tietosuoja-asetuksella on saatu aikaan paljon liikehdintää kaikissa yrityksissä, joissa on rekistereitä. Mutta  jos hieman kuitenkin avataan…

Mitä ja ketä tietosuoja-asetus koskee?

Asetus koskee henkilötietoja. Henkilötiedoksi riittää henkilön nimi, ja vaikkei muuta tallennettaisikaan, tietosuoja-asetuksen vaatimuksien täyttämiseen ei ole kiertoteitä. Varsinaisten henkilötietokenttien lisäksi henkilötietoja voivat olla henkilöön liitetyt tiedot, kuten vaikkapa erilaiset tallennetut kategorisoinnit.

Aikaisemmin varsinkin B2B-liiketoiminnassa asiakasyritysten yhteyshenkilötietoja saattoi tallentaa ja käsitellä vapaammin, mutta nyt sillä ei ole merkitystä – henkilötieto on henkilötietoa, vaikka kyseessä olisi yritysasiakkaan yhteyshenkilö. Kun todistustaakka ja osoitusvelvollisuus tietosuoja-asioiden tilasta on organisaatiolla itsellään, ei liene olemassa monta yritystä tai organisaatiota, joka ei nyt joutuisi panostamaan asiaan.

Henkilötietojen tallentamista ei toki lähtökohtaisesti miltään yritykseltä kielletä, vaan päinvastoin, yrityksen on luvallista tallentaa oman toimintansa ja esimerkiksi asiakaspalvelun hoitamisen kannalta merkityksellinen tieto.

Nyt mukaan tulevat vain entistä suuremmat vaatimukset muun muassa sen suhteen, miten henkilöitä on tiedotettava siitä, että heistä on tallennettu tietoja ja että heillä on läpinäkyvyys omiin tietoihinsa ja mahdollisuus myös korjata tietoja tai myös kieltää niiden säilyttäminen.

Asiaa joudutaan organisaatioissa lähestymään kokonaisvaltaisesti. On dokumentoitava, missä kaikissa järjestelmissä henkilötietoa on, mitä tiedot yksityiskohtaisesti ovat, miten tiedot kulkevat prosessista toiseen ja mikä on tietojen elinkaari. On kartoitettava, miten riskialtista tietoa tallennetaan ja pohdittava sitten riskienhallinnan kannalta erilaisia skenaarioita. Tiedon turvaamisessa on vahvasti tekninen näkökulma läsnä—ja se varmasti parhaillaan teettää eniten töitä ICT-osastoilla, kun selvitetään käytettyjen ratkaisujen teknistä turvallisuutta—mutta vähintään yhtä merkityksellistä on, millaisia käytäntöjä käyttäjät noudattavat, miten heidät on ohjeistettu toimimaan ja mikä heidän osaamisensa ylipäänsä on tiedon turvaamisen kannalta. Puhutaan ”tietotilinpäätöksestä”, joka auttaa kokonaisuuden ymmärtämisessä.

Mitä hyötyä tästä sitten voisi olla?

Monesti ajatellaan, että tietosuoja-asiat ovat niitä, jotka sanktioiden pelossa on pakko laittaa kuntoon ja tästä harjoituksesta syntyy pelkkiä kustannuksia.

Näkökulma sekin, mutta tietosuoja-asetuksen vaatimuksien täyttäminen voidaan ajatella myös ainakin asiakkuudenhallinnan kannalta erinomaiseksi mahdollisuudeksi saattaa asiakashankintaa ja asiakaspalvelua tukeva järjestelmä sellaiseen kuntoon, jossa sen oikeastaan pitäisi muutenkin olla. Usein näin ei vain ole: syystä tai toisesta panostusta ei vain ole saatu aikaan.

Siksi kunnostuksen aloittaminen CRM-järjestelmästä voi olla hyvä idea. Samalla joudutaan todennäköisesti pohtimaan mm. sitä, mikä järjestelmä on henkilötietojen master, ja miten tieto kulkeutuu muihin järjestelmiin.

Järjestelmien valmius

Useimmat laajasti käytetyt tietojärjestelmät ovat todennäköisesti tekniseltä valmiudeltaan riittäviä GDPR-vaatimusten täyttämiseen. Se ei kuitenkaan tarkoita, että asia voitaisiin tällä ohittaa, sillä on varmistettava, että järjestelmän ominaisuudet tiedon suojaamiseen ovat todella käytössä, sitten kun on analysoitu, mitä tietoja järjestelmässä tulee olla ja toisaalta ei saisi olla.

Esimerkki: Tyypillinen CRM-järjestelmä, joka on otettu käyttöön kenties vuosia sitten saattaa sisältää suuren joukon henkilötietokenttiä tai henkilöihin liittyviä tietoja, jotka ovat käyttäjien käytettävissä, vaikka niiden sisältöä ei ole ollut tarkoituskaan ylläpitää. Aikanaan määrittelyissä ei ole tarvinnut kovin paljon ottaa huomioon sitä, mitä tietoa järjestelmässä on sen lisäksi, mitä siellä halutaan ylläpitää.

Ikä, puolison ja lasten nimikentät, harrastukset ja muut vastaavat kentät saattavat olla näkyvissä, kun on ajateltu, ettei maksa vaivaa raivata niitä pois käyttöliittymästä. Joku on voinut niihin jopa syöttää tietoa oma-aloitteisesti. Myöskään ei ole ollut niin tarkkaa, kuka organisaation sisällä mihinkin tietoon pääsee käsiksi. Tietojen poistamista järjestelmästä tai vanhan tiedon oikeellisuutta ei ole juuri mietitty—siivoustalkoita on järjestetty kenties, kun on tehty järjestelmän migraatio toiseen tuotteeseen tai uuteen versioon.

Tiedon riskipitoisuus ja sen tarpeellisuus

Nyt on toisin. Jokainen henkilötietoa tallentava järjestelmä on saatettava sellaiseen tilaan, jossa tarpeelliset tietosuojatoimet on tehty suhteessa tiedon riskipitoisuuteen ja prosesseihin, joissa tietoja tarvitaan. Hyvä periaate olisi, että ellei tietoa tarvita, sitä ei tallenneta tai tarpeeton tieto poistetaan, ja tieto mitä tarvitaan, näkyy vain niille, joille se on prosessin kannalta tarpeen tai hyödyllistä.

Tämä hanke esimerkiksi CRM-järjestelmän kannalta on periaatteessa yksinkertainen, mutta vaatii työtä ja vaivaa. Järjestelmän nykytilan dokumentoinnin jälkeen voidaan suunnitella toimenpiteet, jotka sitten toteutetaan sopivasti vaiheistettuna. Toimenpiteet ovat todennäköisesti sekä järjestelmän mukauttamista, tietosisällön muokkaamista ja tuoreuttamista, ohjeiden kirjoittamista sekä käyttäjien kouluttamista. Toimiva ja liiketoimintaa entistä paremmin tukeva järjestelmä on syntynyt tässä sivutuotteena.

Fenixin vieraskynässä yhteistyökumppani:

Pirjo Rosti
CRM-valmentaja
pirjo.rosti(@)pinassi.fi

Pinassi Oy
www.pinassi.fi

By |2018-03-05T15:47:03+00:0022.8.2017|Blogi, CRM, data, GDPR, Uutiskirje|