DPIA – pakollinen dokumentti vai arvokas prosessi?

Tietosuojan vaikutustenarviointi jakaa mielipiteitä. Toisille se on compliance-rasti, toisille aito johtamisen väline. Tietosuoja-asiantuntijat Jaanaliisa Kuoppa ja Juha Sallinen ovat molemmat tehneet tätä työtä käytännössä – ja heillä on selkeä näkemys siitä, kumpi lähestymistapa kannattaa.

Mitä DPIA tarkoittaa ja miksi se tehdään?

DPIA eli Data Protection Impact Assessment – tietosuojan vaikutustenarviointi – on prosessi, jossa arvioidaan käyttöönotettavan järjestelmän tai toiminnon vaikutukset henkilötietoihin. EU:n tietosuoja-asetus GDPR edellyttää arviointia silloin, kun henkilötietojen käsittely todennäköisesti aiheuttaa korkean riskin rekisteröidyille.

Käytännössä DPIA on monessa kunnassa ja organisaatiossa jo tuttu – mutta tehdäänkö sitä oikeista syistä ja oikealla tavalla?

Dokumentti on vasta lähtökohta – ei maali

Molemmat lähtevät liikkeelle samasta perusajatuksesta: dokumentista on ehdottomasti hyötyä – se on rekisterinpitäjälle konkreettinen tapa todentaa osoitusvelvollisuutensa. Mutta juuri siinä piilee myös vaara.

Sallinen tunnistaa työssään yleistyneen harhan: DPIA mielletään pitkäksi, monimutkaiseksi dokumentiksi, jonka tuottaminen on itseisarvo. Oleellinen kysymys on kuitenkin yksinkertainen – onko käsittelyssä henkilötietoihin liittyviä riskejä, ja voidaanko niitä hallita? Se ei riipu sivumäärästä.

Kuoppa tunnistaa saman ilmiön käytännön työssään: ”DPIA koetaan vain dokumenttina, joka pitää kiikuttaa maaliin mahdollisimman nopeasti.”

Pahimmillaan se ostetaan valmiina ulkopuoliselta – ilman että kukaan omassa organisaatiossa on sitä lukenut tai ymmärtänyt.

Sallinen tiivistää ongelman ytimekkäästi: ”Onhan tästä olemassa DPIA – mutta jos se ei pidä paikkaansa ollenkaan todellisuuden kanssa, niin eihän tässä olla tehty oikeita päätöksiä.”

Kun todellisuus ja dokumentti eivät kohtaa

Sallinen nostaa esiin konkreettisen esimerkin, joka kuvaa ongelmaa osuvasti. Erään kunnan M365-vaikutustenarvioinnissa todettiin, ettei palvelu sisällä viranomaispäätöksiä tai arkaluontoista materiaalia. Todellisuudessa juuri Wordilla kirjoitetaan ne päätökset ennen kuin ne viedään asianhallintajärjestelmään. Sallisen mukaan tällainen dokumentti mennään sellaisella hymistelytasolla, että sitä ei välttämättä kannata lukea lainkaan – se ei kuvaa todellisuutta. Kuoppa jakaa huolen.

Dokumentti, joka on tuotettu ilman organisaation omaa panosta, ei ohjaa päätöksentekoa – se antaa vain väärän turvallisuuden tunteen.

Hyväksyminen pelottaa – ja syystä

Yksi käytännön kipukohta on arvion hyväksyminen – ja se on nimenomaan rekisterinpitäjän vastuulla. Kuopan mukaan arviossa kirjataan usein monenlaisia riskejä, joiden merkitys voi jäädä hyväksyjälle hämäräksi. Siksi sekä arvion tekeminen että hyväksyvän päätöksen tekeminen arveluttaa.

Sallinen tiivistää ongelman: ”Mites se hyväksyjä hyväksyy, jos hänelle laitetaan 50-sivuinen Word tai PDF, jota kukaan ei oikeasti lue ja josta puuttuu ne kolme pointtia, jossa Go tai No-Go?”

Kuoppa yhtyy näkemykseen – hyväksyjän pöydälle ei kannata laskea dokumenttia, josta puuttuu selkeä kokonaiskuva.

Molemmat korostavatkin, että hyvä vaikutustenarviointi palvelee ennen kaikkea päätöksentekijää – ei auditoijaa.

Näin prosessi toimii käytännössä

Toimiva DPIA ei vaadi massiivista byrokratiaa. Sallisen mukaan lähtökohta on aina sama:

  • Ensin tunnistetaan, onko arviointia ylipäätään tarpeen tehdä. Jos käsittely on pieniriskistä, riittää lyhyt merkintä järjestelmäsalkussa – esimerkiksi täppä ”pieniriskinen”. Se oli siinä.
  • Jos tarve tunnistetaan, kootaan oikeat ihmiset: aiheen omistaja tai pääkäyttäjä, tietosuojaosaaja sekä IT. Kaikkien ei tarvitse istua yhtä aikaa, mutta kaikki kulmat tarvitaan todellisuuden hahmottamiseksi.

Kuoppa korostaa, että juuri tässä työskentelyssä syntyy se, mikä tekee DPIA:sta arvokkaan – yhteinen ymmärrys, jonka pohjalta löydetään toimivia ratkaisuja.

Riskien tunnistamisen jälkeen mietitään lievennystoimet ja arvioidaan, voidaanko edetä. Sallinen soveltaa porttiteoriaa: jos ei voida, pohditaan voidaanko hankintaa tehdä muutoksin tai jätetäänkö se kokonaan tekemättä.

Lievennystoimet eivät toteudu itsestään

Kuoppa muistuttaa vielä yhdestä kriittisestä kohdasta, joka usein unohtuu: riskien lievennystoimenpiteet edellyttävät vastuullisen, aikataulun ja resurssien määrittelyä – sekä hyväksyntää. Ja sen jälkeen vielä tarkistamista, että toimenpiteet myös toteutetaan.

Dokumentti, jossa riskit on tunnistettu mutta toimenpiteet jäävät roikkumaan ilmaan, ei suojaa ketään.

Prosessi voi edetä esimerkiksi näin:

Kolme näkökulmaa asiantuntijoilta

Juha Sallinen suosittelee:

  1. Käy läpi tietovirrat ja varmista, että arviointi vastaa todellisuutta – mistä tieto tulee, minne se menee
  2. Priorisoi – uudet järjestelmät porttikäytännöllä, vanhat järjestelmäsalkusta kriittisyysarvioinnilla. Dokumentoi päätös.
  3. Valitse itsellesi sopiva työkalu – Excel, Word, tekoälyavusteinen sovellus tai tietosuojatyökalu. Mikään niistä ei tee päätöksiä puolestasi, vaan tukee työtäsi.

Jaanaliisa Kuoppa suosittelee:

  1. Ota mukaan eri asiantuntijat ja varaa prosessille riittävästi aikaa
  2. Dokumentti on tärkeä, mutta matka on tärkeämpi
  3. Varmista, että lievennystoimille on nimetty vastuuhenkilö, aikataulu ja resurssit – ja seuraa, että ne myös toteutetaan

Haluatko rakentaa organisaatiollesi toimivan DPIA-prosessin?
Ota yhteyttä – autamme viemään tietosuojatyön käytäntöön.

Artikkelissa esiintyvät asiantuntijat:

Jaanaliisa Kuoppa, GDPR-asiantuntija, ulkoistettu tietosuojavastaava. Osa DPO tiimiä.

Juha Sallinen, Yrittäjä, tiedonhallinta- ja teknologia-arkkitehti, ulkoistettu tietosuojavastaava. Osa DPO tiimiä.

Ajankohtaista tietoa

Blogista löydät ajankohtaista tietoa, kiinnostavia artikkeleita sekä paljon yksityiskohtaista infoa liittyen tietosuojaan.

Lue myös nämä artikkelit

Jaa kirjoitus somessa

Pyydä tarjous palveluista