Tietosuoja-asetuksen (GDPR) valmistautumisen hehkuttaminen vaikuttaa olevan konsulttien lempiaihe tänä vuonna, ja painotukset vaihtelevat laki- ja teknologiataustaisten puhujien intressien mukaisesti.
Olennaista tuntuu kuitenkin olevan ensin tunnistaa käsiteltävä henkilötieto, sitten löytää tieto järjestelmistä, ja kohdistaa toimenpiteet näiden perusteella. Tärkeintä on lähteä jostain liikkeelle, eikä takertua liian tarkkoihin yksityiskohtiin ainakaan alkuvaiheessa. Mutta miten Privacy Impact Assessmentit (PIA) ja muut dokumentointivelvoitteet pitäisi käytännössä hoitaa? Entä mistä sitten tietää lopulta olevansa valmis uuden asetuksen voimaantuloon?
Selvitä tärkeimmät henkilötiedon käsittelyn riskialueet
Nykytila-analyysin rinnalla konkreettinen askel tietosuojan kehittämisen alkuvaiheessa on etsiä tärkeimmät henkilötiedon käsittelyn riskialueet, ja tehdä niissä tietosuojan vaikutustenarviointi (Privacy Impact Assessment, PIA). Vaikutustenarvioinnit laaditaan liiketoiminnan ja henkilötiedon käsittelyn kannalta keskeisille prosesseille ja järjestelmille. Yksi tietosuoja-asetuksen määritelmistä on henkilötietojen ”laaja-alainen käsittely”, jonka tulisi siis olla kriteerinä vaikutustenarviointien tekemiselle. Tämän määritelmän tarkemman tulkinnan jätän suosiolla juridiikkaan perehtyneille kollegoilleni.
GDPR ei ole lakitekstinä edes epäselvimmästä päästä.
Vaikutustenarviointi on pohjimmiltaan riskiarvio, jossa tunnistetaan henkilötiedon käsittelyyn liittyviä riskejä ja mahdollisesti niihin liittyviä korjaavia toimenpiteitä. Vaikutustenarvioinnin lähtökohtana on käsiteltävän henkilötiedon tunnistaminen, joka tehdään yleensä käytännössä tietovirtakaavioilla. Nämä puolestaan ovat lähinnä havainnollistamisen apuvälineitä, eli kyseessä ei välttämättä tarvitse olla tussitaulun tikku-ukkopiirustusta perusteellisempi kuvaus. Tyylipisteitä vaatimustenmukaisuudessa ei jaeta. Toki asianmukaisilla työkaluilla on sijansa myös tietovirtakuvausten laatimisessa (varsinkin jos niitä tehdään paljon ja aiotaan hyödyntää muuhunkin kuin GDPR:ään), mutta massiivisia investointeja datan mallinnus-, analytiikka- tai skannaustyökaluihin ei välttämättä tarvita. Oikeilla kysymyksillä (ja kun on houkuteltu oikeat ihmiset kokoukseen) tunnistetaan karkealla tasolla, mistä henkilötieto tulee sisään prosessiin, miten sitä käsitellään, ja miten siitä hankkiudutaan eroon tiedon elinkaaren loppuvaiheessa. Tietovirtojen kuvaamisen lähtökohdaksi otetaan nimenomaan prosessissa käsiteltävä henkilötieto. Tiedon tallennuspaikkoina toimivat järjestelmät tulevat kuvaan vasta sen jälkeen.
Dokumentoi huolellisesti, ole johdonmukainen
Jos tietosuojatyötä lähdetään tekemään liian järjestelmälähtöisesti, vaarana on että koko GDPR-harjoitus muuttuu IT-projektiksi, jota se ei tietenkään pohjimmiltaan ole. Tietosuoja-asetus jättää kuitenkin jonkin verran myös tulkinnanvaraa, esimerkiksi analysoidun tiedon (profilointi) lopputulosten jakamisen suhteen. Jos olen vaikka kerännyt asiakkaani kengännumeron (hyväksyttyä käyttötarkoitusta varten) ja sen perusteella päätellyt hänen kuuluvan ”isokenkäisten” joukkoon, onko minun annettava myös tämä tieto, kun asiakkaani pyytää tietoja itsestään tai välittämään tiedon muille palveluntarjoajille? Entä onko isokenkäisyyden päätelmä poistettava, kun kengännumeron säilytysaika tulee täyteen? Tunnetusti WP29 julkaisee asetustekstin tarkennuksia, mutta erityiskysymyksissä järjestelmien ja prosessien kehitystyötä on edistettävä yrityksen lakiosaston päättämien linjausten mukaisesti. Olennaisinta on, että tämän tyyppisiä linjauksia tehtäessä ne dokumentoidaan huolellisesti. Eli kirjoitetaan ylös, mihin päätös perustui, kuka sen teki ja milloin. Johdonmukaisen kirjausketjun perusteella on ainakin helpompi perustella, miksi sitä isokenkäisyyttä oli päätetty välittää eteenpäin tai jättää kertomatta. Joissain tapauksessa tällaiset yksittäiset linjaukset voivat olla vaikka sähköpostiketjuja tietosuojavastaavan ja operatiivisen johdon välillä. Pääasia on, että nämäkin löytyvät jostain, kun osoitusvelvollisuus astuu voimaan.
Mikä on riittävä tietosuojan taso?
Miten pitkälle uuden tietosuoja-asetuksen valmistautumisen kanssa on mentävä? Mikä on riittävä tietosuojan taso? Hyvän esimerkin GDPR-valmiustason määrittelyn haasteista antaa Nightmare letter, jossa kuvaillaan pahin mahdollinen tietopyyntö, jonka organisaatio voisi asiakkaaltaan tai muulta rekisteröidyltä henkilöltä saada. Tähän kirjeeseen vastattuasi tiedät olevasti valmis ainakin tietopyyntöihin liittyvän kyvykkyyden osalta. Pieni varoituksen sana kuitenkin tällaisen kuvitteellisen tietopyynnön lannistavuudesta, jos GDPR-työ on vasta alkutekijöissään. Kovinkaan moni yritys ei ole vielä valmis vastaamaan asiakkaiden yksityiskohtaisiin kysymyksiin esimerkiksi siitä, onko juuri hänen tietojaan vuotanut menneisyydessä (Minne? Milloin? Mitä tästä opittiin?) tai onko hänen tietojaan kenties varmuuskopioitu jonnekin, kryptattuna tai ilman.
Lohdutuksen sanana mainittakoon, että juristikollegoideni mukaan GDPR ei ole lakitekstinä edes epäselvimmästä päästä. Oikeastaan vaatimukset on kirjoitettu aika selvään sävyyn, ja suurimmasta osasta pystyy muodostamaan suoraviivaisesti kontrolleja, joilla vaatimustenmukaista toimintaa valvotaan. On tässä maailmassa siis monimutkaisempaakin sääntelyä onnistuttu ottamaan käyttöön ja noudattamaan. Olennaista on, että aloitetaan jostain, ja toimitaan tehokkaassa yhteistyössä lakiosaston, riskienhallinnan, tietoturvan ja IT:n välillä!
Timo Valonen
Kirjoitus on alunperin julkaistu EY:n blogissa.
