Ashio whistleblowing software

Oct 14, 2026

Whistleblowing-kanavan lokitus ja audit-jälki

Whistleblowing-kanavan lokitus ja audit-jälki

Sisällysluettelo

Keskeiset havainnot

  • Audit-hetkellä whistleblowing kanavan auditointi paljastaa, onko käsittely ollut hallittua vai summittaista — kirjaukset, säilytysajat ja todisteet ratkaisevat.
  • EU-direktiivi 2019/1937 edellyttää 7 päivän kuittaus- ja 3 kuukauden palautemääräaikoja; niiden toteutumisen osoittaminen vaatii aikaleimattua toimintalokia.
  • Ilmoittajan anonymiteetti ei ole ristiriidassa lokituksen kanssa: kirjataan käsittelytapahtumat, ei ilmoittajan tunnisteita.
  • Lokien säilytysaika määräytyy kansallisen lainsäädännön ja EU-direktiivin kautta — tyypillisesti vähintään toimenpiteen keston ajan, usein pidempään.
  • Todistusketju syntyy, kun sama loki yhdistää vastaanoton, käsittelyn, palautteen ja määräaikojen toteutumisen yhdeksi aukottomaksi ketjuksi.

Mitä whistleblowing-kanavan tapahtumia on pakko kirjata ja mitä saa jättää pois?

Whistleblowing-kanavan lokitukseen kirjataan kaikki käsittelytapahtumat, jotka osoittavat ilmoituen käsittelyn olleen lainmukaista ja järjestelmällistä, mutta ilmoittajan tunnistetietoja ei kirjata ollenkaan. Kirjaamisvelvollisuus koskee nimenomaan käsittelijän toimia, määräaikojen seurantaa sekä päätöksenteon polkua, ei ilmoituen sisältöä tai ilmoittajaa itseään.

Käytännössä lokiin dokumentoidaan vähintään seuraavat tapahtumat:

  • Ilmoituen vastaanottohetki aikaleimoineen, jotta 7 päivän kuittausvelvoitteen toteutuminen voidaan todentaa.
  • Kuittauksen lähettäminen ilmoittajalle — päivämäärä sekä kanava, jolla kuittaus annettiin.
  • Ilmoituen tilanmuutokset: siirto käsittelijältä toiselle, priorisointi, luokittelu ja ratkaisu.
  • Vastuuhenkilön nimeäminen tai muuttaminen jokaisessa vaiheessa.
  • Sisäiset muistiinpanot ja päätöksenteon perusteet, jotka liittyvät ilmoituen käsittelyyn.
  • Palautteen antaminen ilmoittajalle 3 kuukauden määräajassa, mukaan lukien päivämäärä ja sisällön tyypillinen luonnehdinta.
  • Määräaikojen ylittyminen tai niiden lähestyminen, jos järjestelmä generoi hälytyksiä.
  • Tietojen luovutukset viranomaisille tai muille tahoille, jos ilmoitus etenee tutkintaan.

Sen sijaan lokiin ei kirjata:

  • Ilmoittajan IP-osoitetta, evästeitä, selaintitunnisteita tai muita teknisiä tunnisteita, jotka paljastaisivat henkilöllisyyden.
  • Ilmoittajan yhteystietoja, jos ne on mahdollinen jättää käsittelemättä anonyymin ilmoituksen tapauksessa.
  • Viestien koko sisältöä, jos viestintä on suojattu päästä päähän -salauksella eikä käsittelijä voi palauttaa sitä myöhemmin.

EU:n ilmoittajansuojeludirektiivin 2019/1937 mukaan jäsenvaltioiden on varmistettava, että ilmoituen käsittely on luottamuksellista ja että ilmoittajan henkilöllisyys suojataan. Direktiivin 7 artiklassa säädetty anonymiteettisuoja ja 9 artiklassa säädetty määräaikojen dokumentointi kulkevat käsi kädessä: kirjaamisvelvollisuus kohdistuu käsittelyprosessiin, ei ilmoittajaan.

Käsittelijä pystyy todistamaan toimineensa säännösten mukaan ilman, että hänen tarvitsee paljastaa ilmoittajan henkilöllisyys.

Pk-yrityksen näkökulmasta tämä tarkoittaa, että loki on suunniteltava kaksitasoiseksi: toisaalta kirjaamurat käsittelyketjun tapahtumat, toisaalta anonymiteettisuoja varmistetaan teknisin keinoin. Näitä ovat muun muassa viestinnän salaus ja tunnisteiden keräämättä jättäminen. Jos nämä kaksi tasoa eivät ole tasapainossa, joko audit-valmius tai anonymiteettisuoja pettää.

Miten lokit ja metadata erotetaan ilmoittajan anonymiteetistä tinkimättä?

Whistleblowing-kanavan anonymiteetti säilyy, kun lokiin kirjataan vain käsittelytapahtumat ja metatiedot, jotka eivät sisällä ilmoittajaan yhdistettävissä olevia tunnisteita. Tämä erottelu ei ole tekninen yksityiskohta vaan juridinen ja toiminnallinen perusvaatimus: ilmoittajansuojadirektiivi edellyttää, että ilmoittajan henkilöllisyys suojataan, ja tämä suoja ulottuu myös lokitietoihin.

Käytännössä erottelu toteutuu kolmella tasolla:

  1. Tapahtumataso: kirjaamurat, kuka käsittelijä teki mitäkin ja missä vaiheessa, mutta ei sitä, kuka ilmoittaja on tai miltä laitteelta ilmoitus tuli.
  2. Viestintätaso: kahdenvälinen viestintä ilmoittajan ja käsittelijän välillä suojataan päästä päähän -salauksella, jolloin viestien sisältö ei joudu lokiin lainkaan.
  3. Tunnistetaso: Teknillä olevat tunnisteet, kuten IP-osoite, evästeet ja selaintiedot, jätetään keräämättä tai anonymisoidaan ennen kuin ne päätyvät mihinkään rekisteriin.

Ilmoittajalle tämä näkyy konkreettisesti siitä, että hän voi lähettää ilmoituksen ilman tiliä tai kirjautumista, ja käy palvelin ei kirjaa hänen IP-osoitettaan. Vastaanottaja puolestaan näkee vain sen, että ilmoitus on vastaanotettu, mihin kategoriaan se kuuluu, kuka sen käsittelee ja missä vaiheessa käsittely on.

Whistleblowing kanavan tietoturva -artikkelissa on kuvattu, miten päästä päähän -salaus ja nolla-pääsy-arkkitehtuuri mahdollistavat sen, että käsittelijä ja vastaanottaja eivät pääse käsiksi viestien raakasisältöön, mutta pystyvät silti dokumentoimaan käsittelyketjun. Tämä on keskeinen ero perinteiseen sähköposti- tai lippujärjestelmään verrattuna, joissa viestit ja niiden metadata ovat yleensä samassa tietokannassa ja yhtä hyvin auditoijan kuin hyökkääjän luettavissa.

Miten anonymiteetti varmennetaan auditoijalle?

Anonymiteettisuoja dokumentoidaan auditoijalle kahdella tavalla: ensinnäkin kirjaamalla järjestelmän konfiguraatio ja tekniset suojaukset osaksi vaatimustenmukaisuusdokumentaatiota, ja toiseksi osoittamalla lokista konkreettisesti, ettei ilmoittajan tunnistetietoja ole kirjattu missään vaiheessa. Audit-valmiudessa ei riitä, että järjestelmä on suunniteltu anonyymiksi, vaan auditoijalle on näytettävä toteen, ettei anonymiteettisuojaa rikkovaa dataa ole kertynyt.

Pk-yrityksen kannalta tämä tarkoittaa, että dokumentaatioon liitetään selvitys siitä, mitä lokitetaan ja mitä ei, sekä periaatteet, joiden mukaan tunnistetietojen keruu on estetty teknisesti. Tämä selvitys on osa laajempaa ilmoittajansuojalain dokumentaatio pk yrityksessa -kokonaisuutta ja toimii todisteena siitä, että anonymiteettisuoja on rakennettu sisään eikä ole sattumanvaraista.

Kuinka kauan whistleblowing-kanavan lokia on säilytettävä ja missä?

Whistleblowing-kanavan lokia on säilytettävä vähintään niin kauan kuin ilmoituen käsittely ja siihen liittyvät oikeudelliset velvoitteet edellyttävät, ja säilytyspaikan on täytettävä EU:n tietosuojalainsäädännön vaatimukset. Käytännössä tämä tarkoittaa tyypillisesti useamman vuoden säilytysaikaa, mutta tarkka kesto riippuu kansallisesta lainsäädännöstä ja ilmoituen luonteesta.

EU:n ilmoittajansuojeludirektiivi ei aseta yksiselitteistä säilytysaikaa lokeille, mutta asettaa reunaehdot: henkilötietoja saa käsitellä vain siinä laukin määrin, mikä on tarpeen ilmoituen käsittelemiseksi ja ilmoittajan suojaamiseksi. Tämä tarkoittaa, että loki ei saa sisältää ylimääräistä dataa, mutta käsittelyketjun kannalta välttämätöntä dataa on säilytettävä riittävän kauan, jotta mahdolliset oikeudelliset vaateet tai viranomaistutkimukset voidaan selvittää.

Kansallinen lainsäätö vaihtelee, mutta tyypillisesti sovelletaan seuraavia periaatteita:

  • Ilmoituen käsittelyn ajan: lokia säilytetään aktiivisesti niin kauan kuin ilmoitus on käsittelyssä.
  • Päätöksen jälkeen: ilmoituen ratkaisun jälkeen lokia säilytetään tyypillisesti 2–5 vuotta, jotta mahdolliset valitukset tai auditoinnit voidaan selvittää.
  • Vakavien ilmoitusten tapauksessa: jos ilmoitus on johtanut oikeudelliseen prosessiin tai viranomaistutkimukseen, lokia voidaan joutua säilyttämään pidempään prosessin keston ajan.

Säilytyspaikan osalta keskeistä on EU:n tietosuojalainsäädäntö. GDPR:n 5 artiklan mukaan henkilötietoja on säilytettävä turvallisesti ja vain tarvittavan ajan. Jos loki sisältää henkilötietoja, se on säilytettävä EU:n alueella tai maassa, jossa on riittävä tietosuojan taso. Pk-yrityksille tämä tarkoittaa käytännössä sitä, että pilvipalvelun tai hosting-palvelun on sijaittava EU:ssa tai vastaavalla tasolla.

Audit lokin sailytysajat -ohjeessa käsitellään tarkemmin säilytysaikojen laskentaa ja niihin vaikuttavia tekijöitä.

Missä lokia saa säilyttää?

Lokin säilytyspaikan on täytettävä kolme ehtoa: EU:n tietosuojavaatimukset, fyysinen ja tekninen turvallisuus sekä saatavuus auditoijalle. Käytännössä tämä tarkoittaa, että loki säilytetään salatuilla palvelimilla EU:n alueella, varmuuskopioidaan säännöllisesti ja on tarvittaessa purettavissa selkeässä muodossa.

ISO 27001 -sertifioidut datakeskukset tarjoavat tähän sopivan infrastruktuurin, sillä sertifiointi kattaa sekä fyysisen turvallisuuden että tiedonhallinnan. Sveitsi ei ole EU:n jäsen, mutta Sveitsin tietosuojalaki (nLPD) asettaa sveitsiläiselle hostingille omat vaatimuksensa, ja sveitsiläinen hosting täyttää käytännössä EU:n tietosuojalainsäädännön vaatimukset.

Pk-yrityksen näkökulmasta tärkeintä on, että hosting-palvelu dokumentoidaan osaksi vaatimustenmukaisuusarkistoa: missä data sijaitsee, miten se on salattu ja miten sen saatavuus varmistetaan. Tämä dokumentaatio on yksi niistä todisteista, joita auditoija kysyy ensimmäisenä.

Miten lokituksesta rakennetaan auditoijalle selkeä todistusketju?

Miten lokituksesta rakennetaan auditoijalle selkeä todistusketju? Whistleblowing-kanavan todistusketju rakennetaan siten, että sama loki yhdistää ilmoituen vastaanoton, käsittelyn, määräaikojen toteutumisen ja palautteen yhdeksi aukottomaksi tapahtumaketjuksi, joka on jäljitettävissä alusta loppuun. Todistusketju ei ole yksi asiakirja, vaan usean lokitapahtuman muodostama kokonaisuus, joka kertoo ilmoituen elinkaaren tapahtuma tapahtumalta.

Todistusketjun rakentaminen etenee neljässä vaiheessa:

  1. Vastaanotto: lokissa näkyy ilmoituen vastaanottohetki, kanava ja alustava luokittelu. Tämä on todiste siitä, että ilmoitus on otettu vastaan ja että 7 päivän kuittausaika on alkanut.
  2. Käsittely: lokissa näkyvät käsittelijän toimet, tilanmuutokset, vastuuhenkilöiden nimeämiset ja sisäiset päätöksentekopisteet. Tämä on todiste siitä, että ilmoitusta on käsitelty asianmukaisesti.
  3. Määräaikojen hallinta: lokissa näkyvät kuittauksen ja palautteen antamisen ajankohdat sekä mahdolliset määräaikojen ylitykset tai lähestymiset. Tämä on todiste siitä, että direktiivin määräajat on täytetty.
  4. Ratkaisu: lokissa näkyy ilmoituen lopputulos, palaute ilmoittajalle ja mahdolliset jatkotoimenpiteet, kuten siirto viranomaisille. Tämä on todiste siitä, että ilmoitus on saatettu päätökseen.

Jotta todistusketju on auditoijalle uskottava, sen on täytettävä kolme ehtoa:

  • Aukottomuus: mikään vaihe ei saa puuttua ketjusta. Jos esimerkiksi kuittaus on annettu, mutta sitä ei näy lokissa, ketju katkeaa.
  • Muuttumattomuus: lokia ei saa voida muokata jälkikäteen. Tämä toteutetaan teknisin keinoin, kuten kirjoittamalla loki vain lisää -tilassa tai käyttämällä kryptografista allekirjoitusta.
  • Aikaleimaus: jokaisella tapahtumalla on oltava tarkka aikaleima, jotta määräaikojen toteutuminen voidaan todentaa.

Todistusketjun rakentamista varten lokijärjestelmän on tuotettava vienti vakiomuotoihin, kuten CSV-muotoon, jotta auditoija voi tarkistaa sen jälkeenpäin. Tämä on erityisen tärkeää silloin, kun auditointi tehdään ulkopuolisen tahon toimesta eikä käsittelijä ole paikalla selittämässä lokia.

Auditni stopa -ohjeartikkeli syventää audit-jalanjäljen rakentamista ja sen esittämistä auditoijalle.

Miten todistusketju esitetään auditoijalle?

Todistusketju esitetään auditoijalle kolmessa kerroksessa: yhteenveto, yksityiskohtainen loki ja tekninen dokumentaatio. Yhteenveto kertoo ilmoituen kokonaiskäsittelyn ja määräaikojen toteutumisen yhdellä silmäyksellä. Yksityiskohtainen loki sisältää kaikki tapahtumat aikaleimoineen ja vastuuhenkilöineen. Tekninen dokumentaatio osoittaa, miten loki on suojattu ja miten sen eheys varmistetaan.

Käytännön auditointitilanteessa auditoija haluaa yleensä nähdä konkreettisen esimerkin: yhden ilmoituen koko elinkaaren lokitapahtumat, määräaikojen toteutumisen ja palautteen antavan dokumentaation. Jos tämä esimerkki on selkeä ja aukoton, se toimii todisteena siitä, että järjestelmä toimii suunnitellusti.

Pk-yrityksen näkökulmasta todistusketjun rakentaminen ei ole erillinen projekti, vaan osa ilmoituen käsittelyprosessia. Jos loki on suunniteltu oikein alusta lähtien, todistusketju syntyy automaattisesti jokaisen ilmoituen kohdalla eikä auditointi vaadi erillistä valmistelua.

Usein kysytyt kysymykset

Mitä eroa on lokituksella ja tapahtumajäljellä?

Lokitus tarkoittaa teknistä kirjaamista järjestelmän tasolla, kuten aikaleimoja ja tilamuutoksia, kun taas tapahtumajälki on laajempi käsite, joka sisältää myös inhimilliset päätökset ja niiden perusteet. Whistleblowing-kanavan audit-valmiudessa tarvitaan molempia, sillä auditoija haluaa nähdä sekä sen, mitä järjestelmässä tapahtui, että sen, miksi käsittelijä toimi kussakin vaiheessa.

Saako ilmoittajan nimi kirjata lokiin, jos ilmoitus ei ole anonyymi?

Jos ilmoittaja antaa henkilöllisyytensä vapaaehtoisesti, nimi voidaan kirjata käsittelyprosessia varten, mutta se on suojattava samalla tavalla kuin muut henkilötiedot. Lokin säilytysaika ja käyttötarkoitus eivät kuitenkaan muutu: tiedot on säilytettävä vain niin kauan kuin käsittely sitä edellyttää, eikä niitä saa käyttää muihin tarkoituksiin ilman ilmoittajan suostumusta.

Kuinka usein loki on tarkistettava?

Loki on tarkistettava säännöllisesti, tyypillisesti kerran kuukaudessa tai neljännesvuosittain, jotta mahdolliset määräaikojen ylitykset tai poikkeamat havaitaan ajoissa. Pk-yritykselle riittää usein kerran kuukaudessa tapahtuva tarkistus, jossa käydään läpi avoimena olevien ilmoitusten tila ja määräajat. Tämä tarkistus dokumentoidaan osaksi vaatimustenmukaisuusarkistoa.

Tarvitseeko loki erillisen tietosuojavaikutusten arvioinnin?

Jos loki sisältää henkilötietoja, GDPR:n 35 artikla voi edellyttää tietosuojavaikutusten arviointia, erityisesti jos käsittely on laajamittaista tai sisältää erityisiä henkilötietoryhmiä. Pk-yrityksen ilmoituskanavassa tämä on harvoin tarpeen, mutta arviointi on hyvä tehdä, jos loki sisältää esimerkiksi terveystietoa tai muita arkaluontoisia tietoja ilmoituen sisällön kautta.

Miten loki suojataan ulkopuolisilta?

Loki suojataan teknisin keinoin, kuten pääsynhallinnalla, salauksella ja muuttumattomuuden varmistavalla tekniikalla. Pk-yritykselle tärkeintä on varmistaa, että vain nimetyt käsittelijät pääsevät lokiin ja että kaikki lokin käsittelytapahtumat kirjataan itse lokiin. Tämä luo sisäisen valvonnan, jossa lokin käsittelyä valvoo lokin oma kirjaus.

Lähteet