Ashio whistleblowing software

Aug 17, 2026

Pseudonymisointi whistleblowing-ilmoituksissa: opas johdolle

Kädet lukitsevat asiakirjoja sisältävän turvalaatikon.

Kyllä: pseudonymisointi täyttää GDPR:n ja EU:n whistleblower-direktiivin (2019/1937) vaatimukset, kunhan tekniset ja organisatoriset suojatoimet ovat kunnossa. EDPB pitää pseudonymisointia yhtenä GDPR:n nimeämistä suojatoimista, ei irtiottona vastuusta. ISO 37002:2021 antaa rungon ilmoitusjärjestelmän hallinnalle, ja direktiivi asettaa aikataulut ja luottamuksellisuusvaatimukset ilmoituskanavalle.

Kolme asiaa ratkaisee, toimiiko pseudonymisointi käytännössä:

  • Koodiavain säilytetään erillään pseudonymisoidusta aineistosta, ja sen purkuun on tiukka pääsynrajoitus.
  • Ilmoituslomake kerää vain käsittelyn kannalta välttämättömät tiedot, ei mitään ylimääräistä.
  • Jokainen katselu, muokkaus ja avaimen käyttö jää auditointikelpoiseen lokiin.

Näiden kolmen puuttuessa pseudonymisointi jää muodolliseksi eleeksi, joka ei kestä tarkastusta eikä suojaa ilmoittajaa oikeasti.

Sisällysluettelo

Mitä eroa on pseudonymisoinnilla ja anonymisoinnilla?

Pseudonymisointi tarkoittaa GDPR:n 4 artiklan mukaan tietojen käsittelyä niin, ettei henkilöä voi enää tunnistaa ilman lisätietoa, joka säilytetään erikseen. Anonymisointi taas poistaa tunnistettavuuden pysyvästi, eikä alkuperäistä henkilöä voi enää yhdistää tietoon millään kohtuudella käytettävissä olevalla keinolla.

Ero ei ole vain sanahelinää. Pseudonymisoitu tieto on juridisesti edelleen henkilötietoa, koska koodiavain mahdollistaa palautuksen. Findata muistuttaa, että pseudonymisoitu yksilötasoinen aineisto voidaan palauttaa tunnistettavaksi avaimen avulla, ja siksi käsittely edellyttää turvallisia käyttöympäristöjä. Anonymisoitu aineisto sen sijaan putoaa GDPR:n soveltamisalan ulkopuolelle kokonaan, jos anonymisointi on tehty huolella.

Whistleblower-direktiivi ei vaadi anonyymiä vastaanottoa, mutta se edellyttää luottamuksellisuutta ja ilmoittajan henkilöllisyyden suojaamista koko käsittelyketjussa. Käytännössä tämä tarkoittaa, että organisaation on dokumentoitava, miksi se valitsi pseudonymisoinnin anonymisoinnin sijaan, ja arvioitava tunnistamisen riski jokaisen ilmoituksen kohdalla.

STM:n linjauksen mukaan pseudonymisoinnissa suorat tunnisteet poistetaan ja tilalle luodaan pseudotunniste. Julkaistavan aineiston anonymiteetti pitää silti varmistaa erikseen, sillä pseudonymisointi ja anonymisointi eivät koskaan ole sama asia edes silloin, kun koodiavain hävitetään myöhemmin.

Mitä teknisiä ja organisatorisia vaatimuksia pseudonymisointi asettaa?

Toimiva pseudonymisointiprosessi rakentuu viidestä osasta, jotka kannattaa käydä läpi yksitellen ennen käyttöönottoa.

  1. Koodiavaimen erillinen säilytys. Avain ei saa olla samassa järjestelmässä tai samojen ylläpitäjien hallussa kuin pseudonymisoitu aineisto. Pääsy rajataan nimettyihin rooleihin, ja jokaiselle purkupyynnölle on oltava kirjattu peruste.
  2. Tietojen minimointi sisäänotossa. Lomake kerää vain käsittelyn kannalta pakolliset kentät. Vapaatekstikentät, joissa ilmoittaja saattaa vahingossa paljastaa itsensä tai kolmansia, on tunnistettava ja käsiteltävä erikseen.
  3. Salaus siirrossa ja levossa. Ilmoitus salataan sekä lähetyksen että tallennuksen aikana. Palvelimen sijainnilla on merkitystä: esimerkiksi Ashio ajaa alustansa sveitsiläisessä hostingissa, mikä tuo lisäkerroksen tietosuojaan EU:n vaatimusten päälle.
  4. IP:tä, evästeitä ja fingerprintingiä ei kerätä. Raportointisivun tekninen toteutus voi itsessään vaarantaa anonymiteetin, jos selaimen tai laitteen tunnisteita tallennetaan taustalla huomaamatta.
  5. Auditointikelpoinen loki kaikesta pääsystä. Jokainen katselu, muokkaus ja avaimen käyttö kirjataan niin, että ulkopuolinen tarkastaja voi jälkikäteen todentaa, kuka näki mitä ja milloin.

Ammattilaisen vinkki: Älä anna yhdelle henkilölle sekä pääsyä koodiavaimeen että vastuuta tutkinnasta. Roolien erottaminen on halvin tapa estää sisäinen tunnistamisriski, ja se näkyy hyvin myös auditoinnissa.

Sopimuspuoli jää usein unohduksiin: henkilöstön koulutus, selkeät SLA:t käsittelyajoille ja kirjallinen kuvaus siitä, kuka vastaa mistäkin vaiheesta. Espoon kaupungin sisäisen valvonnan yleisohje listaa juuri tällaiset toimenpiteet, salassapidon, koulutuksen ja säännölliset auditoinnit, osana tietoturvan perusrakennetta. Sama logiikka pätee whistleblowing-kanavaan: tekniikka ei riitä ilman sovittuja prosesseja sen ympärillä.

Miten ilmoitus etenee vastaanotosta tutkintaan?

Pseudonymisointi ei ole yksittäinen tekninen toimenpide, vaan se kulkee mukana koko ilmoituksen elinkaaren.

  1. Vastaanotto. Ilmoittaja jättää tiedot lomakkeelle, joka erottelee mahdolliset tunnistetiedot muusta sisällöstä heti syötön yhteydessä. Järjestelmä luo pseudotunnisteen ja antaa ilmoittajalle anonyymin seurantalinkin, jolla hän voi myöhemmin tarkistaa käsittelyn tilan paljastamatta henkilöllisyyttään.
  2. Koodiavaimen hallinta. Avain tallennetaan erilliseen, rajattuun järjestelmään. Sen purkaminen vaatii yleensä vähintään kahden henkilön hyväksynnän ja dokumentoidun perusteen, esimerkiksi oikeudellisen velvoitteen tai vakavan turvallisuusriskin.
  3. Tutkinta. Tutkintatiimi työskentelee pseudonymisoidun aineiston kanssa ja pyytää lisätietoja seurantalinkin kautta ilman, että ilmoittajan henkilöllisyys paljastuu tutkinnan aikana.
  4. Päätöksenteko ja dokumentointi. Jokainen vaihe kirjataan audit trailiin, ja käsittelylle asetetut määräajat seurataan direktiivin edellyttämällä tavalla: yleensä vahvistus seitsemän päivän kuluessa ja palaute kolmen kuukauden sisällä.
  5. Seuranta johdolle. SLA-mittarit ja lokidata kootaan säännölliseksi raportiksi, joka osoittaa sekä käsittelyn nopeuden että pääsynhallinnan toimivuuden.

Oulun yliopiston whistleblower-kanava on hyvä esimerkki tästä mallista: ilmoittajan henkilöllisyys pysyy suojattuna koko käsittelyn ajan käyttövaltuushallinnan ja rajatun käsittelijäjoukon avulla.

Ammattilaisen vinkki: Kirjaa purkupäätöksen peruste aina ennen avaimen käyttöä, ei jälkikäteen. Jälkikäteinen dokumentointi on tarkastajalle aina epäilyttävämpää kuin etukäteen kirjattu perustelu.

Miten pseudonymisoinnin riittävyys todennetaan?

Riskinarviointi ei ole kertaluontoinen tehtävä. EDPS ja AEPD painottavat, että tunnistettavuutta on arvioitava suhteessa kaikkiin kohtuudella käytettävissä oleviin keinoihin, ja tämä joukko laajenee jatkuvasti teknologian kehittyessä. Sama pätee suoraan pseudonymisoituun whistleblowing-aineistoon: se mikä oli riittävän suojattua vuonna 2023, ei välttämättä ole sitä enää.

Käytännön testaus kannattaa jakaa kolmeen osaan:

  • Penetraatiotestaus järjestelmän tietoturvasta, erityisesti koodiavaimen säilytysympäristöstä.
  • Uudelleentunnistamisskenaariot: voisiko joku yhdistää pseudonymisoidun ilmoituksen muihin saatavilla oleviin tietoihin, esimerkiksi organisaation sisäisiin dokumentteihin.
  • Dokumentaation läpikäynti: audit trail, muutosloki ja koulutusrekisterit on löydyttävä kokonaisina, ei osittain.
Todennuksen osa Mitä tarkistetaan
Pääsynhallinta Kuka pääsee koodiavaimeen ja millä perusteella pääsy on myönnetty
Lokitus Kaikki katselu- ja muokkaustapahtumat aikaleimoineen
Uudelleentunnistamisriski Voiko pseudonymisoidun tiedon yhdistää muihin tietolähteisiin
Koulutus Onko käsittelijöillä dokumentoitu koulutus prosessista

Jos valvontaviranomainen pyytää selvitystä, valmis dokumentaatio (riskinarviointi, testausraportit, pääsynhallinnan lokit) lyhentää käsittelyä merkittävästi verrattuna tilanteeseen, jossa nämä pitää koota jälkikäteen.

Miksi Ashio täyttää pseudonymisoinnin vaatimukset valmiiksi?

Moni näistä vaatimuksista kuulostaa raskaalta rakentaa itse. Ashio on suunniteltu juuri tähän: yrityksen sisäinen ilmoituskanava, jossa pseudonymisointi ja auditointikelpoisuus ovat sisäänrakennettuja ominaisuuksia, ei jälkikäteen lisättyjä paikkauksia.

  • Raportointisivu ei kerää IP-osoitteita, evästeitä eikä laitesormenjälkeä, joten tekninen tunnistamisriski poistuu jo sisäänotosta.
  • Ilmoittaja saa anonyymin seurantalinkin, jolla hän voi seurata käsittelyn etenemistä paljastamatta henkilöllisyyttään.
  • Koodiavain ja pääsynhallinta on erotettu roolien mukaan, ja jokainen tapahtuma kirjautuu auditointikelpoiseen lokiin.
  • Alusta toimii sveitsiläisessä hostingissa ja on rakennettu GDPR-yhteensopivaksi alusta asti, mikä helpottaa myös ISO 37002:2021 mukaisen hallintajärjestelmän rakentamista.

Compliance ei synny siitä, että jotain kutsutaan anonyymiksi. Se syntyy siitä, että koodiavain, pääsynhallinta ja lokitus kestävät ulkopuolisen tarkastuksen, vuodesta toiseen.

Tuon esitän tässä avoimesti esimerkkinä toimivasta ratkaisusta, koska se on sama logiikka, jota koko tämä opas on käynyt läpi vaihe vaiheelta.

Miksi minimointi kannattaa ottaa vakavasti heti alusta

Moni organisaatio rakentaa ilmoituskanavan ensin ja miettii tietosuojan jälkikäteen. Se on väärä järjestys. Kun minimointi ja dokumentointi ovat kunnossa heti käyttöönotosta lähtien, sekä ilmoitusaktiivisuus että auditointikelpoisuus paranevat samaan aikaan, koska ilmoittajat luottavat kanavaan enemmän, kun he näkevät konkreettisia suojatoimia, ei vain lupauksia.

Pseudonymisointi toimii whistleblowing-kanavassa vain, kun koodiavain, pääsynhallinta ja auditointikelpoinen lokitus ovat kaikki kunnossa yhtä aikaa.

Kohta Tiedot
Juridinen asema Pseudonymisoitu tieto on edelleen henkilötietoa, joten GDPR-velvoitteet säilyvät täysimääräisinä.
Koodiavaimen hallinta Avain säilytetään erillään aineistosta, ja purku vaatii dokumentoidun perusteen ja rajatun pääsyn.
Minimointi Lomake kerää vain käsittelyn kannalta välttämättömät tiedot heti sisäänotossa.
Todennettavuus Auditointikelpoinen loki ja säännöllinen riskinarviointi osoittavat suojan riittävyyden ajan mittaan.
Valmis ratkaisu Ashio yhdistää IP:tä ja evästeitä keräämättömän raportointisivun, erillisen koodiavaimen ja auditointikelpoisen lokin yhdeksi kokonaisuudeksi.

Ashio: valmis kanava pseudonymisoituun whistleblowingiin

Ashio poistaa ison osan tästä oppaasta suoraan rakentamisen tarpeesta. Alusta hoitaa pseudonymisoinnin, koodiavaimen erillisen säilytyksen ja auditointikelpoisen lokituksen valmiina palveluna, jolloin HR- ja johtotiimin ei tarvitse pystyttää näitä itse tai valvoa niiden toimintaa käsipelillä.

Ashio

Ashio sopii erityisesti organisaatioille, jotka tarvitsevat lakisääteisen ilmoituskanavan nopeasti mutta eivät halua tinkiä ilmoittajansuojelulain edellyttämästä suojan tasosta. Mukana tulevat monikieliset lomakkeet, deadline-valvonta ja tiimien väliset roolit, joten compliance-, HR- ja lakiosasto voivat työskennellä samassa järjestelmässä ilman, että kukaan näkee enempää kuin oman roolinsa vaatii. Voit tutustua Ashion whistleblowing-alustaan ja aloittaa 14 päivän kokeilun, jonka aikana näet koko työnkulun omalla aineistollasi ennen kuin sitoudut mihinkään.

Usein kysytyt kysymykset pseudonymisoinnista whistleblowing-ilmoituksissa

Riittääkö pseudonymisointi täyttämään GDPR:n vaatimukset whistleblowing-kanavassa?

Kyllä, mutta vain kun koodiavain säilytetään erillään, pääsy on rajattu ja käsittely lokitetaan auditointikelpoisesti. Pelkkä nimien poistaminen lomakkeelta ei riitä, koska tieto on silti palautettavissa.

Voiko ilmoittaja pysyä tuntemattomana koko tutkinnan ajan?

Kyllä, jos tutkintatiimi työskentelee pseudonymisoidun aineiston kanssa eikä koodiavainta pureta ilman erikseen dokumentoitua perustetta. Ilmoittaja voi silti kommunikoida tutkijoiden kanssa anonyymin seurantalinkin kautta.

Mikä ero on pseudonymisoinnilla ja täydellä anonyymillä ilmoittamisella?

Anonyymi ilmoittaminen ei kerää minkäänlaista tunnistetietoa alusta asti, kun taas pseudonymisoinnissa tieto on olemassa, mutta piilotettuna koodiavaimen taakse. Pseudonymisointi mahdollistaa paremman tutkinnan jatkokysymykset, koska ilmoittajaan voi olla yhteydessä turvallisesti.

Kuka saa purkaa koodiavaimen ja nähdä ilmoittajan henkilöllisyyden?

Pääsy rajataan nimettyihin rooleihin, tyypillisesti vain vakavissa tilanteissa kuten oikeudellisen velvoitteen tai turvallisuusriskin yhteydessä. Purku vaatii aina dokumentoidun perusteen ja usein vähintään kahden henkilön hyväksynnän.

Mitä tapahtuu, jos pseudonymisointi tehdään puutteellisesti?

Puutteellinen toteutus, esimerkiksi jaettu pääsy koodiavaimeen tai puuttuva lokitus, jättää organisaation alttiiksi sekä tietosuojarikkomukselle että ilmoittajan luottamuksen menetykselle. Se voi myös vaarantaa koko ilmoitusjärjestelmän uskottavuuden henkilöstön silmissä.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Lähteet

Suositus